Best Practices

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

1. 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 configuration of internal inventory network ranges should not overlap between the sensors.

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

   The enterprise network in the above scenario has 2 branches A and B. There are 2 sensors deployed one each in branch A and B. For the enterprise network subnets A and B together make up the range on 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 reports assets A.1 and B.1 causing the same assets to be reported twice to Qualys cloud. This causes an un-necessary burden on the PS services on the Qualys cloud to

   1. merge the same physical asset reported by both sensors into one

   2. keep a track of the asset movement or migration to different locations/sensors.

   This burden multiplies if there are flows from each one of 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 organization would be considered external to 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 meta data 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

2.  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 such replicated IP subnets 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 having many cranes and each crane is a small  network having exactly the same type of devices with the same IPs configured. The overlapping IP address space in each crane can be handled by the Network feature  which the customer can subscribe to. This feature allows the same subscription to uniquely identify IP within a network. 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 uniquely identify the assets for de-duplication. 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

3. 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 will associate meta-data/attributes of all such devices to a single asset which has the Nated IP, making the asset very large, and these slow down the processing pipeline on the cloud. So, it is recommended to add such IPs as internal assets to be excluded.

4. Do not feed multiple copies of the same packet to the sensor
   It is important that the TAPs or SPAN ports that feed the traffic copy to PS do not contain duplicate copies of the same packet. This will result in PS reporting incorrect volumes of traffic flow.
5. Backup and restore of PS VM image
   It is not recommended to backup PS VM images to be restored later. In case the VM fails to  boot due to corruption, contact Qualys support instead of re-deploying the PS VM. The PS  services on Qualys cloud account retains the sensor configuration and applies it to the  appliance on reboot.