In Part 1 of this series we discussed how discovery tools have some basic problems, that have never been completely resolved. In Part 2 of this series we continue our discussion on the False Promise of Discovery Tools.
Latency
The discovery tools themselves also must be updated and reconfigured for new platforms, such as containers, and how they related to serverless computing (e.g., Azure Functions and AWS Lambda) is currently unknown. At some point, the logical “business” layer – the service and who owns it – must be mapped to the lower-level technology, but that is always initially a manual process.
Dependencies also cause false negatives. If a given feed or interaction only runs sporadically, then the discovery process may have to be running at just the right time to catch it. Examining source code, package repositories or service registries also have limitations, in addition to being tedious to review.
The discovery tool has to run as a batch process. It caches the data, which can then become outdated almost immediately, until the next run of the discovery, when it becomes outdated again almost immediately. Because of this, the discovery repository becomes an untrusted source. Engineers might look at it, but they won’t trust it.
Impact on the environment
The discovery tool runs in two different modes – agentless and agent-based. The agentless mode uses considerable network traffic, and the security team doesn’t like it because it behaves like a security threat. It snoops and scans whole ranges of network addresses, and network monitors must be configured to ignore it since they’ll interpret it as a risk. What if a hacker accessed the discovery server and used it as a gateway to snoop the environment? The agent-based mode requires that software is installed and runs all the time on every device the discovery tool manages. The server engineers and application managers don’t like that because it consumes processing capacity and might also interfere with operating the device. What if the agent requires an incompatible library?
Unclear value
Data is critical because it’s needed for processes that demand it. Discovery tools, however, have always been a supply-side idea. “Just look at all this great data, it must be valuable” is too often the point of view. When you have no idea what’s in your data center, seeing even sub-par discovery data that has been combined can be very impressive. Sooner or later, though, the data must be used in actual processes solving actual business problems; e.g., audit compliance. At that point, the false positives and negatives and complexity will be a tough challenge.
Not cost-effective
The software, finally, is expensive, both in terms of its licensing and also from an operational perspective. Every device to discover is an additional cost, but that’s not all. The fingerprinting process is also both expensive and at risk of failing, as noted. Senior software engineers are needed to define and tune the fingerprints and keep them updated. One senior manager says, “Let me understand. I can hire a $45,000-a-year admin to keep track of my servers and installations. Granted, it’s manual and not pretty, but one person is able to do the job. Is it preferable to a $150,000-a-year software engineer doing this work? Even when his or her best efforts at automation are still leaving some holes? Plus, we must still define the services and who owns them.”
Insufficient reach and effort
Your business architecture, services, products and/or applications (pick your terminology of choice) must still be mapped. Who owns what? Who is called? How do escalation paths work? What about chargebacks? Who is accountable for compliance exceptions? None of this can be discovered; however, non-technical sources, such as accounts payable and supply chain systems, can provide important additional context – if you have the capability to reconcile such data, which is well outside the comfort zone of most discovery tools.
Conclusion
Discovery tools have their place. They are good for spot-checking and validating. An auditor might be helped if manually maintained data says one thing, and automated discovery says something else. When used with robust, commercially maintained fingerprinting data, they are also helpful for software licensing. A complete Asset Management or Configuration Management approach, however, cannot be based on Discovery alone. Its problems are fundamental, and rooted in the complexity of modern systems. Don’t be oversold on this silver bullet.
Blazent has been working with some of the largest and most complex IT infrastructures in the world. During the past 12 years, we have found that on average:
• Servers are missing a discovery agent
• Servers are missing the backup agent
• Windows devices are missing anti-virus software
• Clients are missing patching agent
• Servers are missing patching agent
Apply these numbers to your environment and then ask yourself,
• “Do we rely solely on discovery for our CMDB?”
• “Do these numbers pose a threat to our organization’s security?”
If you answered yes to either question, then contact Blazent to discuss how we can improve your security, increase the value of your IT infrastructure and give you the confidence that you now know what you didn’t know. Please visit us at www.blazent.com, or contact us at sales@blazent.com.
