Amol Sarwate
Amol Sarwate
In the dark ages of vulnerability assessment and system security (only a handful of years ago), rating the risks associated with software vulnerabilities and evaluating secure system configurations were largely subjective endeavors. Essentially, every enterprise was forced to rely on the vague risk rankings of software makers as to how severely a software flaw truly would jeopardize the security of the IT infrastructure. Additionally, when it came to hardening servers, endpoints and application implementations, many organizations created their own security checklists to harden desktops and servers -- pulling the information, the best they could, from various sources such as industry practices and vendor guides.

To bring some objectivity and standardization to the process, the National Institute of Standards and Technology (NIST) recently released its first draft of the Security Content Automation Protocol (SCAP). SCAP, as NIST explains, is a standards-based method to enable automated vulnerability management, measurement and policy compliance evaluation. SCAP is based on a number of existing, well-used, open standards that itemize software flaws, security configurations, and various product names. When brought together, these standards make it possible to rank security flaws, as well as security configurations, so that the impact of security vulnerabilities and misconfigured systems can be measured.

To do so, SCAP leverages the following standards:

  • Common Vulnerabilities and Exposures (CVE). The CVE provides standard vulnerability identifiers (so that various security and software vendor names can be consolidated and rationalized) and a dictionary to define software defects that also create security issues.
  • Common Configuration Enumeration (CCE). Much like the CVE, only the CCE creates standard identifiers and a dictionary for secure system configurations.
  • Common Platform Enumeration (CPE). The CPE creates standard identifiers and a dictionary for platform and product naming.
  • Common Vulnerability Scoring System (CVSS). This standard explains and scores security vulnerability impact.
SCAP content takes these standards, and security checklists that are expressed in XML, to express security configurations. These include the Open Vulnerability Assessment Language (OVAL), which is used for testing configurations, patches, and reporting, and SCAP checklists, written in the Extensible Configuration Checklist Description Format (XCCDF), which specifies specific SCAP security checklists and provides report formatting.

While all of this may seem like a lot of alphabet soup, it really helps to simplify the discussion, assessment, and reporting of security vulnerabilities and system configurations. The SCAP security checklists detail how to harden a wide variety of applications, from Windows, XP and Vista, Windows Server 2003 to Internet Explorer, SharePoint, Office 2007, and even IBM AIX and Red Hat Linux. The entire list of operating systems and platforms security checklists are available here.

http://nvd.nist.gov/ncp.cfm?scap

Also, SCAP makes it much easier for security applications to share system configurations and vulnerability data, which should simplify how security managers can use their SCAP-compliant security applications to more intelligently exchange information (such as among vulnerability assessment data with patch management software) and security information and event management tools. There's a list of SCAP-compliant products available at this NIST site.

http://nvd.nist.gov/scapproducts.cfm

As more security vendors embrace SCAP, expect the adoption of SCAP to broaden throughout the commercial sector as the interoperability benefits grow -- and subjective security makes way for a more measured risk posture.