During some recent research, I came across two issues in a large vulnerability management (VM) vendor’s public community support forum. The first post described a problem in which their tool reported a different number of network endpoint assets from what was seen on “the console.” The second detailed a user experiencing duplicate assets. After some investigation, I determined that both issues were a product of the vendor’s challenges with what I call “Host Reconciliation.”
One of the challenges faced by VM vendors is tracking changes to network assets that are periodically (perhaps even continuously) assessed over time. Accuracy in a single “scan” or vulnerability assessment is one thing, but accuracy across numerous independent assessments compounded over time is another story. I illustrate this challenge in the following figure.
The diagram shows two different assessments—the first on week one and a second on week two. The real network assets are colored red, yellow and black. The challenge is to correctly match assets that were discovered and assessed at two different points in time. The assets from week one are perfectly matched to those assessed on week two, even though IP addresses for the yellow and red assets have changed from one week to the next.
This challenge exists for two reasons. First, the scanning technology most prevalently used within the industry, “remote network scanning,” does not have a presence on assessed assets. The scanner is remote from the evaluated asset. There is no asset beacon or unchanging characteristic present on the asset to uniquely identify it as exclusive or different from other endpoints. Second, regular IT administration occurs resulting in normal changes to the network endpoint assets. It is not as simple as using an endpoint IP address to solve the problem.
My recent study on network churn reveals that four percent of an organization’s endpoint servers (these are not subject to DHCP) change IP addresses over a three month period. I also found that 46 percent of these servers change their DNS Hostname and 34 percent change their NETBIOS hostname over the same period.
When a VM solution crippled with limited host reconciliation technology experiences a mismatch, it results in “asset duplication,” as it did for the users in the forum posts above. The next figure illustrates a very similar situation.
While this is similar to the forum user’s issue, this is a case in which a VM solution incorrectly concludes that the yellow asset assessed on week two is different from the yellow asset assessed on week one. It realized that it was a new asset and added it to the console. The net result is asset duplication due to a reconciliation mismatch.
This is an unfortunate and, ultimately, costly problem for organizations. Users who are unaware of the issue are making security decisions based on inaccurate network security information reported by their VM solution. Some clients may eventually stumble onto the issue but may not fully understand the root cause before raising questions with their vendor. Others ultimately discover the root cause of the issue after having spent significant time and resources and even then, the VM solution may not provide an easy way to eliminate the duplicate.
I will continue blogging on similar VM shortcomings I’ve discovered as part of this network churn study and invite you to stay tuned.