Best Practices

This section contains certain best practices to follow when configuring the internal assets in PS appliances.

Avoid configuring overlapping subnets as internal (inventoried) assets on more than one sensor appliance

In deployments that have more than one passive network sensor appliances registered with the same Qualys cloud account, it is recommended that the configuration of internal inventory network ranges should not overlap between the sensors.

To explain this better, let us consider a sample deployment with 2 sensors deployed in different locations registered to the same account.

two_sensor_deployment

The enterprise network in the above scenario has 2 branches A and B. There are 2 sensors deployed, one each in branches A and B. For the enterprise network, subnets A and B together make up the range of IPs for internal assets that have to be inventoried. Assets A.1, A.2, and A.3 belong to subnet A and B.1, B.2, and B.3 belong to subnet B.

Now consider a case where there is intra branch traffic. Each of the sensors in branch A and B see traffic flows from/to assets in subnets A to B.

For example, if A.1 were to initiate a flow to B.1, both sensors would sense this flow. If both sensors are configured with subnet A and B as the internal (inventoried) range, then both sensors report assets A.1 and B.1 causing the same assets to be reported twice to Qualys cloud. This causes additional workload on the cloud services and this may result in delayed or missed updates of the assets or traffic flows as seen in the asset or traffic listing.

This workload multiplies if there are flows from each one of the assets in subnet A to B.1, such as A.1 to B.1, A.2 to B.1, and A.3 to B.1.

So, adding the same subnet into multiple sensors is inefficient and not a recommended configuration.

Desired/Recommended configuration: Detect assets in location specific subnets and provision a "non-inventoried" asset category

A recommended configuration to avoid duplicate processing on the cloud is to configure each sensor with a unique subnet as its inventoried range and add the other subnets internal to the organization as its internal non-inventoried range.

So in the above example, the sensor deployed in Branch A would only consider IPs of subnet A as the internal IPs and treat everything else as external. This means even subnet B which belongs to the universe on internal IPs of the organization would be considered external to the sensor in branch A. However, to track the inter-branch traffic flows so to know which asset in subnet A was talking to which asset in subnet B and vice-versa, it is recommended to add subnet B as internal (non-inventoried) range in sensor of location A. The passive sensor uses the non-inventoried range or IP to create assets whose attributes are not collected just as in the case of External assets but with a difference that its IP is recorded.

Similarly for the sensor in location B, configure subnet B as its internal inventoried range and subnet A as its internal non-inventoried range.

With the above configuration sensor in location A would report A.1, A.2, and A.3 as internal inventoried assets and B.1 as the non-inventoried assets. Similarly, the sensor in location B would report B.1 as its internal inventoried asset and A.1, A.2, and A.3 as its non-inventoried asset.

This configuration saves the PS services from the burden of additional processing. This also conserves the WAN bandwidth needed by sensors to report metadata to Qualys cloud as only one sensor reports the inventoried assets.

To summarize, the configuration of both passive sensors is as follows:

Passive Sensor Appliance Location	Internal (inventoried)	Internal (non-inventoried)
Branch A	Subnet A	Subnet B
Branch B	Subnet B	Subnet A

Avoid mirroring replicated IPs to a single appliance

In topologies more common in OT networks, multiple smaller networks can have the same IP subnet. Each replicated IP subnet has to be mirrored to a separate PS appliance. Avoid mirroring multiple such subnets to one appliance.

For example, consider a site with a yard that has many cranes. Each crane is a small network with exactly the same type of devices and the same IPs configured.

The network feature, which the customer can subscribe to, can handle the overlapping IP address space in each crane. This feature allows the same subscription to identify IP within a network uniquely.

The Network feature is already supported in VM and PC modules and is part of the PS 1.4.0.0 release. PS uses the network feature by de-duplicating passively sensed Unmanaged IPs/assets with managed assets belonging to the same Network. PS exercises the network-based merge to de-duplicate assets only when it has neither MAC nor hostname information to identify the assets for de-duplication uniquely.

So here is what the configuration of PS appliance in each crane would look like

Crane #1

Add Crane#1 IP range R1 in Asset Group AG1 in Network N1 in VM module
Run policy compliance scan for the asset group AG1 in N1 in VM module
Add NPS1 to Network N1 and configure NPS 1 to sense IP range R1 in N1
Crane #2
Add Crane#2 IP range R2 in Asset Group AG2 in Network N2 in VM modules
Run policy compliance scan for the asset group AG2 in N2 in the VM module
Add NPS2 to Network N2 and configure NPS 2 to sense IP range R2 in N2

Add NATed IPs in the excluded list

PS does not yet support the capability to detect NATed devices. All assets behind NAT devices get masqueraded by the NATed IP, and if PS sees this NATed IP, it associates the meta-data/attributes of all such devices to a single asset with the NATed IP, making the asset very large. This slows down the processing pipeline on the cloud. So, it is recommended to add such IPs as internal assets to be excluded.

Do not feed multiple copies of the same packet to the sensor

The TAPs or SPAN ports that feed the traffic copy to PS mustn't contain duplicate copies of the same packet. This results in PS reporting incorrect volumes of traffic flow.

Backup and restore of PS VM image