Scribd
Upload
50 views4 pages

Qualys Asset Tracking Best Practices

The document outlines best practices for asset tracking, emphasizing the transition from DNS to IP scanning, disabling the 'Purge host data when OS has changed' option, and enabling Agent Correlation Identifier and Agentless Tracking. It recommends deploying the Qualys Cloud Agent on all eligible assets and performing fully authenticated scans to ensure accurate asset merging and vulnerability tracking. Additionally, it discusses the implications of Smart Merge for managing agent and non-agent devices within the Qualys platform.

Uploaded by

kulwindersingh915
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
50 views4 pages

Qualys Asset Tracking Best Practices

The document outlines best practices for asset tracking, emphasizing the transition from DNS to IP scanning, disabling the 'Purge host data when OS has changed' option, and enabling Agent Correlation Identifier and Agentless Tracking. It recommends deploying the Qualys Cloud Agent on all eligible assets and performing fully authenticated scans to ensure accurate asset merging and vulnerability tracking. Additionally, it discusses the implications of Smart Merge for managing agent and non-agent devices within the Qualys platform.

Uploaded by

kulwindersingh915
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 4

Best Practices for Asset Tracking

Steps:
1. If DNS scanning exists today, convert all to IP scanning.
2. Ensure Option Profile option to “Purge host data when OS has changed” is disabled.
3. Enable the Agent Correlation Identifier option – Primary user only.
4. Enable Agentless Tracking across the Enterprise – Primary user only.
5. Ensure Agentless Tracking is enabled across all authentication records.
6. Deploy the Qualys Cloud Agent on every asset that can use it.
a. Supported OS have a version under VM and PC here:
https://success.qualys.com/support/s/article/000006675.
7. Perform fully authenticated scans using the scanner appliances for all IP ranges.
a. If a device has an agent, all interfaces/virtual IPs on that device will collapse into
a single asset. You will still be able to view all IPs in Host Details. The agent will
ensure that the main device/interface “wins” the naming rights, so Qualys will
list the actual hostname as the asset hostname.
b. If the device does not have an agent, all interfaces/virtual IPs on that device will
remain separate, keeping current behavior in place. This will prevent the main
asset from being renamed to a virtual hostname or the IP changing.

Explanation of the above:


1. DNS scanning
1.1. This works in Qualys by querying DNS for the current IP, adding the current IP to a
special type of asset group, and then scanning by IP. This mapping will lead to issues
when you rescan as IPs change, and it is generally NOT recommended at this point.
1.2. It is better to scan by IP for all IP ranges, and let the asset tracking methods do the work
for you:
1.2.1. Agentless Tracking – fully authenticated
1.2.2. Agent Correlation Identifier – when agent is present

2. Disable “Purge host data when OS has changed”.


2.1. This option can do more harm than good.
2.1.1. It is typically enabled to eliminate situations where Windows vulns show on
Linux assets, and vice versa.
2.1.1.1. After all fixes in this document have been deployed, the only risk for
vulns appearing on the wrong OS will be on devices where IPs change and the
OS can’t take an agent (non-Linux, non-Windows, etc).
2.1.1.1.1. This “at-risk” fingerprint is extremely small, and shouldn’t be an
issue in practice, since most DHCP assets will have the agent or will not
move (static IPs).
2.1.1.1.2. If you still need to purge host data when OS has changed, do not
do it anywhere were DHCP is running. You can break out static
infrastructure portions of your network, and enable the feature just on
this Option Profile, being careful to choose the correct Option Profile
when running a scan.
2.1.2. This feature can cause host data to purge during ad hoc scans where you scan for
a small subset of QIDs. This happens due to OS fingerprinting not being thorough
enough during those focused scans.
2.1.2.1. Example 1: If you were to run a scan for just port 443/tcp and not include
any other checks, Qualys will fingerprint against what it sees. Since it’s only
looking at 443/tcp, it won’t be able to tell if it’s a Windows asset, Unix, etc.
2.1.2.2. Example 2: A Linux device shows as “HP ILO” or as “A / B / C” because
Qualys isn’t authenticating during this scan. This shows the OS as changing
and trips the feature to remove host data. Upon the next scan, the QIDs are
new to Qualys, even though we have found them before.
2.1.3. If there is an agent on the device, and you are running authenticated scans, we
will always know the asset’s OS, and we will apply the correct tests.
2.2. In a DHCP environment, asset tracking will correctly move the asset around, instead of
relying on purging when things look differently.

3. Enable the Agent Correlation Identifier option


3.1. This feature allows the Cloud Agent to put some obfuscated information on port
10001/tcp or 10002-10005 if lower ports are in use. These ports are customizable
3.2. The scanner picks up this information during a scan and uses it for asset correlation.
3.2.1. This only works for devices that have the Cloud Agent installed.
3.2.2. This prevents IP-tracked duplicates when authentication fails, since the port is
checked during every scan, if it is open.
3.3. Only the Primary User can enable this option.
3.4. Reference:
https://qualysguard.qg2.apps.qualys.com/qwebhelp/fo_portal/host_assets/agent_corr
elation_identifier.htm

4. Ensure Agentless Tracking is also enabled across all authentication records


4.1. The most thorough information you can possibly grab during auth and non-auth scans
is to attempt Agentless Tracking and the Agent Correlation Identifier on every scan.
4.2. During testing we found the following Info-Gathered QIDs for each scenario:
4.2.1. QID 45179 – Agentless Tracking ID
4.2.1.1. Useful for proof that asset has been scanned before.
4.2.1.2. Also, potentially useful for CMDB Sync with SNOW.
4.2.2. QID 45421 – Qualys Cloud Agent Detected
4.2.2.1. Useful to find scenarios where the Agent is there but merging did not
complete for some reason.
4.2.3. QID 48143 – Qualys Correlation ID Detected on port 10001/tcp.
4.2.3.1. Correlation possible during auth and non-auth scans.
4.2.4. QID 48484 – Qualys Correlation Identifier Status
4.2.4.1. Shows that merging was successful, preventing duplicate assets.

5. Deploy the Qualys Cloud Agent on every asset that can use it
5.1. This will allow you to take advantage of the tracking methods above on everything
possible, especially the Agent Correlation Identifier.
5.2. This will keep usage down because Agent-enabled devices will collapse into a single
host.
5.3. This will reduce duplicate vulnerability counts, so your vuln counts reflect the number
of actionable fixes.

6. Perform fully authenticated scans using the scanner appliances for all IP ranges.
6.1. This will allow Qualys scans to pick up all possible information and collapse the hosts
according to your configured merging options.
6.2. If you have authentication issues:
6.2.1. Agent-enabled devices will still pick up the Agent Correlation Identifier and
merge correctly.
6.2.2. Non-Agent devices will create a duplicate asset in Qualys, using IP-tracking, with
the information we could gather.
6.3. You should consistently look for authentication issues and correct them when found.
6.3.1. You can use the Authentication Report in the Qualys UI.
6.3.2. You can also track Authentication-Failed QIDs for various OS to find these assets
quickly.
6.3.2.1. Reference:
https://qualysguard.qualys.com/qwebhelp/fo_portal/authentication/auth_st
at_qids.htm
6.3.2.2. You can dashboard these Auth-Failed QIDs if desired.

Smart Merging is not the best path, however I’ve explained here since it is an option for you:

I suggest reading up on it before selecting it, and would prefer the standard unified view
approach, but the decision is ultimately up to the team.

Please review this as well: Especially options 3 and 4 for clarification

https://qualysguard.qg2.apps.qualys.com/qwebhelp/fo_portal/host_assets/agent_merge_data
.htm

7. Enable Smart Merge across the Enterprise :


7.1. This will treat Agent devices and non-Agent devices differently.
7.2. Agent devices:
7.2.1. All interfaces/virtual IPs on that device will collapse into a single asset.
7.2.2. You will still be able to view all IPs in Host Details.
7.2.3. The agent will ensure that the main device/interface “wins” the naming rights, so
Qualys will list the actual hostname as the asset hostname.
7.2.4. This will lower usage closer to expected levels, since usage is tied to the amount
of assets that you store in Qualys, not actual host count in your environment. Here,
one device with 5 virtual IPs = 1 asset in Qualys (1 license).

7.3. Non-Agent devices:


7.3.1. All interfaces/virtual IPs on that device will remain separate, keeping current
behavior in place.
7.3.2. This will prevent the main asset from being renamed to a virtual hostname or
the IP changing, which was the concern with “single unified view” during testing.
7.3.3. This will keep usage higher than expected levels, since usage is tied to the
amount of assets that you store in Qualys, not actual host count in your
environment. Here, one device with 5 virtual IPs = 6 assets in Qualys (6 licenses).
8. Only the Primary User can enable this option.

You might also like