The open standard OVAL promises to ease the integration of security applications and help organizations develop security checks for highly-customized networks and applications.
The open standard OVAL promises to ease the integration of security applications and help organizations develop security checks for highly-customized networks and applications.
Last month we covered the Common Vulnerability Scoring System (CVSS) open standard and how this standard makes it easier for security managers, vendors and organizations to make more effective judgments when it comes to ranking and fixing software vulnerabilities.
While CVSS is a great tool in its own right, it's by no means the be-all and end-all when it comes to extremely useful open standards. This month, we'll explore the Open Vulnerability Assessment Language (OVAL) from MITRE, which can be used to make it easier for all organizations to better evaluate the security of their systems and enable easier information sharing and tight integration of security applications.
OVAL was launched as an open effort to standardize the way computer vulnerabilities are identified on an organization's systems. Today, OVAL is used to share all types of information that could relate to the security posture of a system. At the end of June, the standard was updated to include a few new tests and to improve a number of Windows component schemas.
The benefits of OVAL are many. For instance, security administrators can develop their own custom security checks, or they can use any of the more than 2,000 OVAL definitions. And security products from different vendors can share information and be integrated more easily through the use of OVAL. By choosing OVAL compatible solutions, organizations can deploy best-of-breed products for vulnerability assessments and policy assessments, and even link results to SIMs and other tools for advanced correlation to better identify where the highest risks lie.
How OVAL Works
OVAL comprises three primary components: OVAL Language, OVAL Interpreter, and the OVAL Repository. The OVAL Language manages three steps of the vulnerability assessment process: ensuring that configuration information for system testing is standardized; a coherent way to analyze systems for their current state, including such attributes as vulnerability and patch levels and overall configuration; and then reporting the results consistently. The OVAL Interpreter is used to demonstrate how information can be collected from a system for testing, and then actually executing OVAL definitions for that system and reporting test results. MITRE developed this interpreter so developers could test the usability of the OVAL Definitions they write, and to make sure the definitions adhere to the OVAL Language. Finally, the OVAL Repository is where you'll find security community-developed OVAL Vulnerability, Compliance, Inventory, and Patch Definitions for supported operating systems. These definitions are free to use. The OVAL definitions are given to the OVAL interpreter which runs the definitions to determine:
1) Vulnerability definitions: If the host machine is at risk of any vulnerabilities (thus acting as a vulnerability scanner.
2) Compliance definitions: If the host adheres to certain security best practices (based on the OS it runs). These are not vulnerabilities but a set of standards that a hardened machine should follow.
3) Inventory definitions: Help customers determine the software inventory on their machines, a list of installed applications and similar attributes.
4) Patch Definitions: Determine if a vendor patch is missing.
Together, all of these tools provide security professionals the power and the flexibility they need to create their own signatures, use pre-existing signatures available in the repository and even develop highly-specific patch and regulatory compliance engines.
But with the availability of so many commercial and open-source products, why would anyone want to develop custom definitions? While readily available tools will do 80 to 95 percent of everything an organization needs, some departments, or even an entire enterprise, may be running highly customized software and system configurations. Through OVAL, you can customize your OVAL compliant tools to get the job done, or develop your own tool.
The federal government sees the value of OVAL, and I believe even more organizations will start using this open standard. This past June, the Office of Management and Budget issued policy memorandum M-07-11, Implementation of Commonly Accepted Security Configurations for Windows Operating Systems, which mandates that all federal agency systems, to improve security throughout the government, must adhere to the Federal Desktop Core Configuration by February 2008. Both the configuration and verification of this standard system implementation rely heavily on the Security Content Automation Protocol (SCAP), which is a checklist that relies on a handful of open standards for naming software flaw conventions and configurations in applications and systems. This move no doubt will make it easier for agencies, vendors and auditors to maintain more secure systems. The use of open standards, combined with a standardized configuration, means fewer mistakes easier enforcement of sound security practices.
As these standards continue to evolve and grow, they'll improve security product integration even further, and give security teams the control necessary to develop the tools they need to keep their infrastructures secure, no matter how customized their networks and applications.
- Amol Sarwate is director of Qualys' vulnerability research labs
