Every vendor has a different approach to detecting vulnerabilities. In the early days of VM products, this proprietary approach was the primary means of distinguishing one product from another. The ability to be accurate yet fast was essential. However, this has led to a severe lack of sharing of information among product vendors, which threatens the effectiveness and consistency of security as a whole for customers. Since the results of vulnerability assessments may vary from one vendor to another, how can you be sure which results should be used to take remediation action? If one product detects a vulnerability by looking at a registry key, and another misses the vulnerability because it uses file detection, how can the security manager rely on either product since no single, reliable best-practice detection method has been employed? Discrepancies will exist if multiple VM systems are used that can create additional work to resolve them. So, that is not an efficient solution either.
Conversely, similar results can occur when software distribution methods used by organizations do not result in the common footprints on a system that result from a standard local installation. In some cases, applications on the Microsoft Windows® platform can be installed with certain registry keys missing. When the vulnerability scanner looks for these registry keys and does not find them, then the vulnerability status can be misread.
A more global problem is the lack of standard vulnerability identifiers. For example, if the vulnerability management system uses proprietary identifiers for vulnerabilities and the patch management system uses Bugtraq ID numbers, how can the two be reconciled? In some cases, there is no identifier available for a particular vulnerability that was discovered by the VM system vendor, and therefore only a proprietary index is available. Some kind of standard adherence is needed to maximize the effectiveness of the overall VM process and assure consistent identification worldwide.
Solutions are available. If it were agreeable to vendors and MITRE Corporation alike that vulnerabilities they discover can be centrally identified and described, then patch management systems could rely on those identifiers.
Alternatively, some vendors have already integrated functionality such as patch management so that compatibility in vulnerability identification and corresponding remediation is not a concern. However, this limits the choices of products and functionality. The VM systems buyer is committed to the vendor for both functions. As of this writing, no vendor provides comprehensive patch support for all OSs and all vulnerabilities, nor are they likely to do so in the future. Oddly enough, at the time of this writing, there are more than 33,000 Common Vulnerabilities and Exposures (CVEs). Yet, top VM vendors cover less than 75 percent of that number. Why do so many customers tolerate this obvious deficiency? If a vendor told you that his product was no more than 75 percent effective, would that be acceptable? Customers need to recognize this key deficiency and demand more.
Recognizing that they cannot do everything, vendors will build-in the ability to interface with key management and tracking systems such as change management and incident management. The number of compatible vendors may be limited. In that case, vendors have built an API that will allow the creation of a custom connector between the VM and other systems.
We previously discussed technology and the support for standards such as the Common Vulnerability Scoring System (CVSS), CVE, and OVAL®. There are great benefits to adopting a standard for any technology. But, given the rapid proliferation of security technologies and their competitiveness with one another, the adoption of standards should become a more critical requirement. Initially, it would seem foolish for a vendor to “give away” functionality to another vendor. However, by providing the flexibility to choose the needed products, vendors can increase their chance of selection. This creates a chicken-and-egg problem where the vendor must support the open standard and the customer must demand it. OVAL is one of the more specific and important standards that should be seriously considered on a requirements list.
0 comments:
Post a Comment