On paper, it only takes minutes to install the latest security patch. In reality, it could be weeks, if not months, before you can apply the patch within your organization. The phenomenon of patch lag used to refer to the length of time between vulnerability discovery and vendor release of the patch.
With some organizations running multiple patch managements systems, and some running no systems at all, how do we accurately and consistently report missing security patches? What if the patch system lists a patch as missing, but the patch was never required due to extenuating circumstances, negating the need for remediation? Why is this patch report listing 100,000 missing patches?
We, as an industry, need to admit that workarounds do remediate vulnerabilities, and that they save time and money. A workaround is defined as mitigating the vulnerability through a means other than a patch. I'm not saying we should attempt to fix all vulnerabilities by workarounds. What I am saying is that we should not require all vulnerabilities to be remediated by patching.
A fortuitous byproduct of implementing the Security Content Automation Protocol (SCAP) within the organization is that we no longer have to rely on tracking security patches to address vulnerabilities. SCAP uses a group of well-defined standards from the National Institute of Standards and Technology to automate the detection and reporting of vulnerabilities. The SCAP process receives vulnerability details through the Common Vulnerabilities and Exposures (CVE) standard, and assesses the impact using the Open Vulnerability and Assessment Language (OVAL) standard. This SCAP process can be implemented through third-party software, open source products, in-house developers, or a combination of the above. Frankly, you cannot download SCAP – you must roll your own.
OVAL is an XML-formatted language that allows users to set the definition of a vulnerable condition. For example, vulnerability CVE-2009-1234 impacting Solaris's autofs, may be represented within the OVAL definition as: missing patch 123456-1, and running the autofs process. This means that if either of these conditions is false – the patch that fixes the vulnerability is present or the autofs process is not running – the server is no longer vulnerable. This brings to light an option other than installing the patch: Stop the autofs process. Just as installing the corrective patch would prompt the OVAL definition to report that the vulnerability has been remediated, so would stopping the autofs process. Just be aware that with a SCAP process, frequency matters – it's not a one-time check. The more you run your OVAL definitions, the better your chance to catch any changes made to previously set workarounds.
This method of defining vulnerable situations within an OVAL definition is only as good as the definition author. If the only variable included within the definition is patch, the SCAP process will not highlight possible workarounds. Even if you do not allow workarounds within your OVAL definitions, you are still not tracking security issues by patch. Remember, OVAL is a standard used to test for the existence of a CVE. Your reports will show results by CVE, not by the contents of the OVAL definition.
So how does this all fit together? With a well-documented SCAP program and properly created OVAL definitions, you can allow your IT team to implement any of the defined methods of remediation for a vulnerability. This allows the business itself to choose the best way to remediate, rather than leaving the decision in the hands of the information security team. As a security professional, your concern is to know that the vulnerabilities are remediated, not how they are remediated.
