Security Content Automation Protocol 1.2 Components
Security Content Automation Protocol 1.2 Components
Learn all about security content automation protocol 1.2 (SCAP) components. Each open specification of SCAP is called a component, and here we'll explore languages, reporting formats, and more.
Join the DZone community and get the full member experience.Join For Free
Container Monitoring and Management eBook: Read about the new realities of containerization.
SCAP uses open specifications and each is known as a SCAP Component. I wanted to highlight the components and provide some reference material. In a follow up article we will look at tools that utilize the SCAP content for Compliance and Assessments.
NIST (National Institute of Standards and Technology) produces the Technical Specificataion for the Security Content Automation Protocol (SCAP) in special publication 800-126 revision 2 for SCAP version 1.2. The publication defines the technical composition of SCAP version 1.2 in terms of its componentspecifications, their interrelationships and interoperation, and the requirements for SCAP content. SCAP is a suite of specifications that standardize the format and nomenclature by which software flaw and security configuration information is communicated, both to machines and humans. It is a multi-purpose framework of specifications that support automated configuration, vulnerability and patch checking, technical control compliance activities, and securitymeasurement. Goals for the development of SCAP include standardizing system security management, promoting interoperability of security products, and fostering the use of standard expressions of security content.
SCAP has two major elements. First, it is a protocol—a suite of open specifications that standardize the format and nomenclature by which software communicates information about software flaws and security configurations. Each specification is also known as an SCAP component. Second, SCAP includes software flaw and security configuration standardized reference data, also known as SCAP content. SCAP has several uses, including automating checks for known vulnerabilities, automating the verification of security configuration settings, and generating reports that link low-level settings to high-level requirements.
SCAP version 1.2 is comprised of eleven component specifications in five categories:
The SCAP languages provide standard vocabularies and conventions for expressingsecurity policy, technical check mechanisms, and assessment results. The SCAP language specifications are:
Extensible Configuration Checklist Description Format (XCCDF) - an XML format specifying security checklists, benchmarks and configuration documentation. (http://scap.nist.gov/specifications/xccdf/index.html)
Open Vulnerability and Assessment Language (OVAL®) - an XML-based language that provides a standard for how to check for the presence of vulnerabilities and configuration issues on computer systems. (http://oval.mitre.org/)
Open Checklist Interactive Language(OCIL™) - defines a framework for expressing a set of questions to be presented to a user and corresponding procedures to interpret responses to these questions. (http://scap.nist.gov/specifications/ocil/)
The SCAP reporting formats provide the necessary constructs to expresscollected information in standardized formats. The SCAP reporting format specifications are:
Asset Reporting Format (ARF) - a data model to express the transport format of information about assets, and the relationships between assets and reports. (http://scap.nist.gov/specifications/arf/)
Asset Identification - provides the necessary constructs to uniquely identify assets based on known identifiers and/or known information about the assets. This specification describes the purpose of asset identification, a data model for identifying assets, methods for identifying assets, and guidance on how to use asset identification. It also identifies a number of known use cases for asset identification. (http://scap.nist.gov/specifications/ai/)
Although Asset Identification is not explicitly a reporting format, SCAP uses it as a key component in identifying the assets that reports relate to.
Each SCAP enumeration defines a standard nomenclature (naming format) and anofficial dictionary or list of items expressed using that nomenclature. The SCAP enumeration specifications are:
Common Platform Enumeration (CPE™) - a standardized method of describing and identifying classes of applications, operating systems, and hardware devices present among an enterprise's computing assets. (http://scap.nist.gov/specifications/cpe/)
Common Configuration Enumeration(CCE™) - provides unique identifiers to system configuration issues in order to facilitate fast and accurate correlation of configuration data across multiple information sources and tools. For example, CCE Identifiers can be used to associate checks in configuration assessment tools with statements in configuration best-practice. (https://nvd.nist.gov/cce)
Common Vulnerabilities and Exposures (CVE®) - a dictionary of publicly known information security vulnerabilities and exposures. (http://cve.mitre.org/)
Measurement and scoring systems
In SCAP this refers to evaluating specific characteristics of asecurity weakness (for example, software vulnerabilities and security configuration issues) and, based on those characteristics, generating a score that reflects their relative severity. The SCAP measurement and scoring system specifications:
Common Vulnerability Scoring System (CVSS) - CVSS version 3 sets out to provide a robust and useful scoring system for IT vulnerabilities that is fit for the future. Its development has been overseen by the CVSS Special Interest Group (SIG) with input from representatives of a broad range of industry sectors, from banking and finance to technology and academia. (http://www.first.org/cvss)
Common Configuration Scoring System (CCSS) - Metrics are organized into three groups: base, temporal, and environmental. Base metrics describe the characteristics of aconfiguration issue that are constant over time and across user environments. Temporal metrics describe the characteristics of configuration issues that can change over time but remain constant across userenvironments. Environmental metrics are used to customize the base and temporal scores based on thecharacteristics of a specific user environment. (http://csrc.nist.gov/publications/PubsNISTIRs.html#NIST-IR-7502)
An SCAP integrity specification helps to preserve the integrity of SCAP content and results. Trust Model for Security Automation Data (TMSAD) is the SCAP integrity specification. (http://scap.nist.gov/specifications/tmsad/)
Some of the content pulled from The Technical Specification for the Security Content Automation Protocol (SCAP): SCAP Version 1.2.
Opinions expressed by DZone contributors are their own.