How to get your Asset Counts Right!
It doesn’t matter who you are, your asset counts in your vulnerability scanner probably don’t match your asset count in Nucleus. And depending on who you are, that’s likely to be either your favorite thing about Nucleus or your least.
Getting your asset counts to match exactly is theoretically possible, but I question whether it’s worth the effort. Having worked for one of the major scanner vendors and now for Nucleus, I can tell you this is a situation you find with any risk aggregator, whether it’s us or one of our competitors. And you’ll find it with any network scanner, whether it’s the one made by the company I used to work for, or one of their competitors.
There are several common reasons for this.
The Nature of Risk Aggregation
The main use case for risk aggregators is their ability to pull in data from multiple tools, correlate the results, consolidate any duplicates, and provide a unified view of your risk. Your scanning tools will have different identifying information about each asset. Some of them have a more complete set than others. Some have their own identifiers, and those identifiers will be unique to that scanner. More on that in a minute.
A risk aggregator must be able to take these findings and figure out how they map to each other. If enough of the attributes match, we merge them.
The same logic that determines that a finding from a network scanner and a finding from a SAST or DAST scanner both live on the same machine and merges them to the same asset, also works for finding and eliminating duplicate assets within a network vulnerability scanner.
Why Duplicate Assets Happen
Network scanners have a tough job. They have to conduct more than 50,000 assessments on every live IP address in a scan with Six Sigma accuracy, and they have to get that done as quickly as possible, with as little disruption as possible. Every finding is going to be questioned without mercy, and every problem that happened that week will get blamed on that scan, regardless of whether that machine even got scanned that week.
How do I know this? Because I supported these scanners running in enterprise environments for about 7 years of my career.
When everything goes right, the major scanner vendors mostly hit their target. The problem is, vulnerability scanners don’t just find vulnerabilities. If there is anything wrong in your infrastructure, they will find that too. If the scanner understands what’s happening, it will drop an informational finding that helps you find the problem and troubleshoot it. If the scanner doesn’t understand what’s happening, it acts weird. What do I mean by weird? The scan might not finish. Or the scan might finish and not really give you any indication anything went wrong until you go to analyze the data. And then you notice, if you look really carefully, some of the assets look funny.
The most common problem happens when authentication is inconsistent. All of the three major scanners are capable of writing an identifier to a system the first time they perform an authenticated scan on it. Sometimes this is automatic. Sometimes you have to enable it. This identifier ensures that the scanner can track the system consistently as long as authentication happens. If authentication fails, or you run an unauthenticated scan either accidentally or on purpose, you end up with duplicate assets.
When the Solution Becomes the Problem
I’ve also seen these identifiers cause the problem they were designed to solve. Sometimes an organization will rebuild a system rather than patch it. Depending on the tools you have to work with, this can be faster than patching. It’s very likely to be more reliable. But if you don’t save that identifier and write it back after the rebuild, guess what the scanner does? It writes a new identifier and treats it as a new system.
Network security products are also notorious for tripping up vulnerability scanners. Avoid scanning through firewalls if at all possible. Whitelist your scanner appliances in your antivirus, your EDR solution, your IDS or IPS, and your firewalls. Vulnerability scans look very suspicious to all of those devices, and if they interfere with that traffic, your scans will be less accurate.
Misbehaving DNS can also trip up scans. I always know when my DNS is misbehaving because my kids start yelling that Roblox isn’t working. Anytime your home Internet acts weird, there’s about an 80% chance it’s DNS. In your vulnerability scans, this shows up in your scan results. Your scanner will scan an IP address, and it will query DNS for that system’s name. If it authenticates, it will ask the system for its host name. If they disagree, the system overrides DNS. If it doesn’t authenticate, the scanner has to go with DNS. If DNS is inconsistent, you get duplicate entries. If authentication is inconsistent, you’ll likely end up with duplicate entries.
If your assets have multiple network cards, that exacerbates the problem. Keep in mind it is very common for a laptop to have both a wired and a wireless card. Most servers have multiple wired network cards. The scanners have to look for exact matches. Their job is to get the scan done as fast as possible and with little disruption as possible. That’s one of the concessions they have to make.
Nucleus has time to try to make sense of the garbage when it encounters it. Under the worst-case scenario, where all we have to work with are unauthenticated scans with mismatched DNS names, we may not deduplicate completely, if at all. Depending on the nature of your DNS issues, Nucleus is able to compensate for mismatched DNS if enough other attributes match.
If the incoming data is bad enough, our cleaned-up data may not be perfect. But it will be an improvement.
Is it a Problem?
If you see asset mismatches as a problem, it may be because someone is using that mismatch to try to discredit your vulnerability management tools. Keep in mind that asset tracking and vulnerability assessment are two separate tasks and two separate evaluations. Just because a vulnerability scanner does a subpar job of tracking assets doesn’t mean it’s bad at its primary job. The tools that specialize in asset tracking don’t always get asset tracking right either, and that’s their only job.
Now from a licensing point of view, it might be a problem. If you see a difference in asset counts between Nucleus and your scanner and the difference is significant, say 40%, that probably means you’re using 40% more licenses than you need. That cost may be significant. If the difference is small, the cost is small and probably not worth it. Note that Nucleus doesn’t charge you for those deduplicated assets, but your scanner vendor probably does.
Preventing Duplicate Assets at the Source
Getting a 100% match between Nucleus and any vulnerability scanner is difficult. At the very least, it requires authenticated scans. And achieving 100% authentication 100% of the time isn’t realistic. When I worked at an MSSP supporting dozens of customers, I was thrilled with an authentication success rate of around 95%.
In addition to using authentication, make sure your scanner is configured to write that identifier to each system the first time it encounters it. Contact your vendor to find out if this happens automatically or is something you need to configure.
Unfortunately, there are also factors outside your security team’s control. If your network infrastructure misbehaves, it will affect your scan. If you see inconsistent DNS names, either in your scanner or in Nucleus, that can be difficult to troubleshoot, depending on whether the problem is on the client side or the server side.
Most modern operating systems will try to register their host name in DNS automatically, but sometimes this is configurable. If that setting isn’t consistent across all of your devices on your network, your DNS is going to be chaotic. In Windows, that setting is configurable. It’s on by default, but it’s easy to disable. If you have a Windows laptop with that disabled, that laptop can grab a DHCP address, but then it won’t update DNS. That’s one way you can end up with Windows laptops with DNS entries like “Bob’s iPhone.” I’m not saying every corporate network has machines with that identity crisis, but many do. In supporting large companies working at an MSSP, I got used to seeing them.
Fixing your DNS and Active Directory problems could end up being a significant and costly project. It will make your vulnerability scanner work better. It will probably also make your patching tool work better, and your asset inventory tool work better. So there is some benefit, but I can’t tell you if those benefits are worth the cost.
Working Around the Issue
The easiest way to work around this issue and minimize the problem is usually to deploy agents. Keep in mind that if you continue to run network scans and use agents, you can still end up with duplicate entries. If you absolutely, positively don’t want duplicates, configure your scanner to tag your agents and exclude that tag from your network scans. That way you can continue to run network scans against devices that can’t run an agent. Those types of devices tend not to move around a lot, which reduces the possibility of duplicates, but some devices have multiple interfaces. To handle those, you may have to use exclusions to ensure you only scan the management interface.
And if your remediation teams ever rebuild a system, make sure they preserve that identifier and write it back before reinstalling the agent.
These are all things your scanner vendors should be able to advise you on and possibly even help improve. Accurate asset and vulnerability data is the foundation of a strong vulnerability management program and makes VM and remediation teams more effective. Program impact can be reported using 4 Golden Metrics in Vulnerability Management to show performance. These metrics will demonstrate continuous improvement at each stage of the VM maturity model as you build the quality and value of your VM program.