The Security Content Automation Protocol (SCAP) is an attempt to help defenders by providing a collection of XML schemas/standards that allow technical security information to be exchanged between tools. For example, SCAP can help organizations looking for a way to respond appropriately to new vulnerabilities and threats by helping prioritize, allowing the most significant ones to be addressed sooner. It can also benefit those looking to provide interoperability across system security tools. There is even an effort to “encouraging the use of SCAP as a de-facto standard across the ICT industry for deploying trusted cloud computing services.”

Background

To help understand what exactly SCAP is, let us turn to the U.S. National Institute of Standards and Technology (NIST) Special Publications (SP) 800-117, “DRAFT Guide to Adopting and Using the Security Content Automation Protocol (SCAP):”

SCAP comprises a suite of specifications for organizing and expressing security-related information in standardized ways, as well as related reference data, such as identifiers for software flaws and security configuration issues. SCAP can be used for maintain the security of enterprise systems, such as automatically verifying the installation of patches, checking systems security configuration settings, and examining systems for signs of compromise.

NIST this month is looking for public comments on the first public draft of SP 800-126, “The Technical Specification for the Security Content Automation Protocol (SCAP).” Back in May, NIST released the draft for SP 800-117.

SCAP components consists of:

• Common Configuration Enumeration (CCE): provide unique identifiers to system configuration issues in order to facilitate fast and accurate correlation of configuration data across multiple information sources and tools.
• Common Platform Enumeration (CPE): a structured naming scheme for information technology systems, platforms, and packages.
• Common Vulnerability Enumeration (CVE): a dictionary of publicly known information security vulnerabilities and exposures.
• Common Vulnerability Scoring System (CVSS): a vulnerability scoring system designed to provide an open and standardized method of rating IT vulnerabilities. NIST has even provided a calculator for creating CVSS vulnerability severity scores.
• eXtensible Checklist Configuration Description Format (XCCDF): a specification language for writing security checklists, benchmarks, and related kinds of documents. NIST has released the NIST Interagency Report 7275 Revision 3 “Specification for Extensible Configuration Checklist Description Format (XCCDF) Version 1.1.4.”
• Open Vulnerability Assessment Language (OVAL): an information security community standard to promote open and publicaly available security content, and to standardize the transfer of this information across security tools and services.

The National Checklist Program (NCP), outlined in NIST SP 800-70, is the repository for SCAP-expressed checklists. The checklists provide detailed low level guidance on setting the security configuration of operating systems and applications.

In June, MITRE hosted the Security Automation Developer Days conference, which focused on the U.S. National Institute of Standards and Technology’s (NIST) Security Content Automation Protocol (SCAP). MITRE has made the minutes available, which includes discussion on NIST SP 800-126. Michael Smith has provided some great highlights from the conference in his post, “Security Automation Developers Conference Slides.” The problem with Michael is that it is difficult not to quote his whole blog, which is bad web etiquette. Please follow the link for some real insight concerning the slides. You can also view below Michael’s presentation, “Security Content Automation Protocol and Web Application Security:”

Back in September 2008, NIST sponsored the Fourth Annual Security Automation Conference. The Presentations are available. Ian Charters attended and posted his thoughts, “NIST and SCAP; Busting a cap on intruders Part 1.” The 5th Annual IT Security Automation Conference will be held October 26-30th, 2009 at the Baltimore Convention Center.

Make sure to check out below the OWASP video talk from SnowFROC 2009 by Ed Bellis (from Orbits) on vulnerability management titled “Doing more with less? Automate or die.”

Ed’s has also written an article for CSO Online, “How SCAP Brought Sanity to Vulnerability Management.”

Possible Problems

Some may argue that SCAP is overly complicated and people are better off relying solely on their vendor’s products and reports. That assumes that a single vendor product is sufficient to meet tomorrow’s security needs. Some organizations buy into the platform simplification model where basically they purchase a single vendor line of products in order to avoid interoperability problems. The problems is that one vendor frequently only does a few things well. The agility of the organization to adapt to changes in the security world becomes dependent solely on that single vendor. After investing so much into that one vendor, organizations find that they are completely locked in. Probably that is not the best position to be in when facing a very volatile IT environment.

Consider the below list where NIST outlines areas SCAP validation will cover (Source: NIST Interagency Report 7511 “Security Content Automation Protocol (SCAP) Version 1.0 Validation Program Test Requirements (DRAFT)):”

• FDCC Scanner: the capability to audit and assess a target system to determine its compliance with the FDCC requirements.
• Authenticated Configuration Scanner: the capability to audit and assess a target system to determine its compliance with a defined set of configuration requirements using target system logon privileges.
• Authenticated Vulnerability and Patch Scanner: the capability to scan a target system to locate and identify the presence of known vulnerabilities and evaluate the software patch status to determine compliance with a defined patch policy using target system logon privileges.
• Unauthenticated Vulnerability Scanner: the capability of determining the presence of known vulnerabilities by evaluating the target system over the network.
• Intrusion Detection and Prevention System (IDPS): the capability to monitor a system or network for unauthorized or malicious activities. An intrusion prevention system actively protects the target system or network against these activities.
• Vulnerability Remediation: the capability to install patches on a target system in compliance with a defined patching policy.
• Misconfiguration Remediation: the capability to alter the configuration of a target system to bring it into compliance with a defined set of configuration recommendations.
• Asset Scanner: the capability to actively discover, audit, and assess asset characteristics including: installed and licensed products; location within the world, a network or enterprise; ownership; and other related information on IT assets such as workstations, servers, and routers.
• Asset Database: the capability to store and report on asset characteristics including: installed and licensed products; location within the world, a network or enterprise; ownership; and other related information on IT assets such as workstations, servers, and routers.
• Vulnerability Database: a catalog of security-related software flaws labeled with CVEs where applicable. This data is made accessible to users through a search capability or data feed and contains descriptions of software flaws, references to additional information (e.g., links to patches or vulnerability advisories), and impact scores. The user-to-database interaction is provided independent of any scans, intrusion detection, or reporting activities. Thus, a product that only scans to find vulnerabilities and then stores the results in a database does not meet the requirements for an SCAP vulnerability database (such a product would map to a different SCAP capability). A product that presents the user general knowledge about vulnerabilities, independent of a particular environment, would meet the definition of an SCAP vulnerability database.
• Misconfiguration Database: a catalog of security-related configuration issues labeled with CCEs where applicable. This data is made accessible to users through a search capability or data feed and contains descriptions of configuration issues and references to additional information (e.g., configuration guidance, mandates, or other advisories). The user-to-database interaction is provided independent of any configuration scans or intrusion detection activities. Thus, a product that only scans to find misconfigurations and then stores the results in a database does not meet the requirements for an SCAP misconfiguration database (such a product would map to a different SCAP capability). A product that presents the user general knowledge about security-related configuration issues, independent of a particular environment, would meet the definition of an SCAP vulnerability database.
• Malware Tool: the capability to identify and report on the presence of viruses, worms, Trojan horses, spyware, or other malware on a target system.

It is difficult to imagine a single security product that is capable of doing all the above services well. There is a need to be able to share information between various systems performing these functions.

Game Changing Technology

Considering past statements by Aneesh Chopra, the first Chief Technology Officer of the United States, does not SCAP sound like an area that will be getting additional support by the U.S. government? ZDnet has posted a very interesting podcast of Chopra talking at the Computer History Museum. Chopra wrote a few months back:

If confirmed, I would emphasize a research program on “game-changing” ideas in cybersecurity, to find new ideas that might transform the nation’s information infrastructure to be more secure and simpler to understand and use. The goal is to make it “easy to do the right thing, hard to do the wrong things and easy to recover when the wrong thing happens anyway.”

Tim O’Reilly, one of the most insightful person around in respect to IT, wrote back in April “Why Aneesh Chopra is a Great Choice for Federal CTO.” Tim’s points out items that Chopra has accomplished in Virginia:

1. the first officially-approved open source textbook in the country, the Physics Flexbook;
2. integrating iTunes U with Virginia’s state education assessment framework;
3. the Learning Apps Development Challenge, a competition for the best iPhone and iPod Touch applications for middle-school math teaching;
4. a Ning-based social network to connect clinicians working in small health care offices in remote locations;
5. a state-funded “venture capital fund” to allow government agencies to try out risky but promising new approaches to delivering their services or improving their productivity;
6. a lightweight approval and testing process that allows the government to try out new technologies before making a full, expensive commitment.

Back in April 2007, Chopra was behind Virginia’s 95 agencies opening up their databases to the Google search engine, in order to make them widely accessible to the public. Chopra at that time stated the top priority of the state’s strategic plan for information technology, which was adopted last year, is increased access to government information. A great thing to do, provided security is insuring only the information you want is being accessed in the manner intended.

John Dvorak offers a different opinion of Chopra in his post “Special Report: Is US Chief Information Officer (CIO) Vivek Kundra a Phony?” Dvorak states, “It would be logical to assume that Kundra managed to get his buddy Chopra the CTO job despite the fact that Chopra’s technology background is essentially nil.” Whether O’Reilly or Dvorak is correct, Chopra needs to start reading the Guerilla CISO for great insight into security solutions. Michael outlines a plan on fixing government patch and vulnerability management through SCAP in the post, “Federated Vulnerability Management.” Here are a few of the ideas discussed in the post:

• Every IT asset reports into a patch management system of some sort. Group the assets allowing for identification of who is responsible when something has a problem.
• Do periodic network scanning.
• The orchestrator will correlate network scans with patch management status and gives a ticketing/alert/whatever where unmanaged devices are identified.
• The NVD feed is pushed down to the agencies/departments which are sent out as vulnerability alerts along with the checks to see if systems are vulnerable.
• Hardening guides are pushed from the agencies/departments in SCAP form and audit information is pulled of IT assets. Differences are automatically entered into a workflow and reporting system.

Imagine the additional possibilities when intrusion detection/prevention systems, patch remediation, asset scanner, and malware tools start sharing information.

SCAP and the Cloud

Aneesh Chopra should also read Christofer Hoff’s rational Survivability blog. In Hoff’s post, “Extending the Concept: A Security API for Cloud Stacks“, he considers building on the capabilities of SCAP to embed a “standardized and open API layer into each IaaS, PaaS and SaaS offering (see the API blocks in the diagram below) to provide not only a standardized way of scanning for network vulnerabilities, but also configuration management, asset management, patch remediation, compliance, etc.” Hoff goes on to write, “Further (HT to @davidoberry who reminded me about my posts on the topic) we could use TCG IF-MAP as a comms. protocol for telemetry.”

Hoff is another person who is difficult to quote without including his complete post. He makes the point that you gain “automated audit and security management capability for the customer/consumer and a a streamlined, cost effective, and responsive way of automating the validation of said controls in relation to compliance, SLA and legal requirements for service providers.” By doing so, Hoff points out, you are “not reinventing the wheel and we have lots of technology and standardized solutions we can already use to engineer into the stack.”

Update: Hoff pointed out (see comments area) some of the excellent work done by Iron Frog (Ben) in not only his post “Some thoughts for addressing the Assurance component of A6,” but also his series of post “Can we do the Security Stack API RESTfully? (parts 1, 2, 3, 4, and 5).”

Peter Mell, who recently changed positions at NIST from the SCAP validation program manager to the leader of the agency’s Cloud computing project, will likely agree with Hoff’s points. Expect NIST efforts in the Cloud to take SCAP into consideration.

Final Thoughts

As Michael Smith points out, in the Cloud one faces the same problems as a managed service provider, mainly how to allow the auditing of systems and the underlying infrastructure. An API could allow a managed services environment making security tasks much easier to customers. To quote Michael Smith, “we have in SCAP is Common Platform Enumeration (CPE) which allows you to specify the hardware and software (ie, how the infrastructure that you don’t know about is built) and eXtensible Configuration Checklist Description (XCCDF) which specifies the audit/compliance checks. Package them together and you have a way of describing what the infrastructure looks like and the technical auditing standard to go along with it.” Sounds like some game changing ideas that could transform the nation’s information infrastructure, helping it be more secure. I hope you are listening, Aneesh Chopra.