Next steps in security automation

Building on the success of the U.S. government’s Security Content Automation Protocol (SCAP), an Internet Engineering Task Force working group is developing international standards for automating the job of assessing and monitoring the security of IT systems.

Automation is seen as essential to improving cybersecurity, and ensuring that tools from different vendors can work together in a global online environment requires industry standards. The National Institute of Standards and Technology, together with the Homeland Security Department and the National Security Agency, began the process with SCAP, a suite of interoperable specifications for conveying security information that vendors to government agencies must comply with. The working group is expanding that limited set of specs for international use.

“The end-game here is the logical next step to SCAP,” said Adam Montville, co-chair of the Security Automation and Continuous Monitoring Working Group.

Chartered in September 2012, the IETF Security Automation and Continuous Monitoring (SACM) Working Group initially is charged with developing standardized protocols to “collect, verify and update system security configurations.” This focuses on the “security automation” portion of SACM. Continuous monitoring is expected to be addressed in future phases of the project.

NIST was among the early advocates for the effort.

“That’s what NIST does,” said Dave Waltermire, security automation architect in NIST’s Computer Security Division. “We develop specifications and best practices, and once that work achieves a level of maturity we want to transfer it to industry with international standards.”

SCAP in its present form, version 1.2, deals primarily with endpoint compliance for configuration requirements. The specifications, contained in Special Publication 800-126, support automated configuration, vulnerability and patch checking, technical control compliance and security measurement.

The SCAP specifications are the building blocks used by vendors to provide standards-based tools that can interoperate with each other in automating these processes. They create a common format for developing and enforcing baselines and producing standardized results. This requires common methods of expressing information about hardware, software and vulnerabilities.

SCAP version 1.2 includes 11 component specifications in five categories:

• Languages for expressing security policy, technical check mechanisms, and assessment results: 
• Extensible Configuration Checklist Description Format
• Open Vulnerability and Assessment Language
• Open Checklist Interactive Language
• Reporting formats to express collected information: 
• Asset Reporting Format
• Asset Identification (Although Asset Identification is not explicitly a reporting format, SCAP uses it in identifying the assets.)
• Enumerations, standard nomenclatures and an official dictionary of items expressed using that nomenclature: 
• Common Platform Enumeration
• Common Configuration Enumeration
• Common Vulnerabilities and Exposures
• Measurement and scoring systems for evaluating severity of a security weakness: 
• Common Vulnerability Scoring System
• Common Configuration Scoring System
• Integrity of SCAP content and results: 
• Trust Model for Security Automation Data.

SCAP has been successful, but creating an international standard is more complex than simply approving the protocols.

“With that success came a little bit of pushback,” said Montville, who also is technical product manager at the Center for Internet Security. Several other nations were developing their own automation schemes, and vendors did not want competing standards. 

And although SCAP worked, it is not complete. “SCAP has a lot of good descriptions,” said Montville. “What it doesn’t do today is shuttle that data from place to place.”

“SCAP today is really just a set of data formats,” said NIST’s Waltermire. “It doesn’t say how you move information from point A to point B.”

When a coalition of vendors several years ago talked with NIST, NSA and DHS about an international effort, IETF was settled on as the proper venue.

“We are at the very beginning of the process,” said Waltermire.  

Because of the complexity of the task, the working group’s first job is to address enterprise use cases for assessing the configuration and security state of network endpoints. The use cases will help develop common functional capabilities and requirements for vendor-neutral standards.

Deliverables under the existing charter include:

• A description of the SACM architecture, including protocol requirements.
• A specification for the informational model for endpoints data.
• A specification for retrieving configuration and policy information for driving data collection and analysis.
• A specification for a protocol and data format for collecting actual endpoint data.

The working group’s first milestone is submission of the SACM architecture draft this month, and the final deliverable is due September 2014. But IETF timetables are ambitious, Montville said. “Most working groups slip their deadlines.”

Whatever the final timeline, Waltermire said that future versions of SCAP and its specifications likely will reference the SACM standards.