Transitioning to the Security Content Automation Protocol (SCAP) Version 2

Abstract

The Security Content Automation Protocol (SCAP) version 2 (v2) automates endpoint posture information collection and the incorporation of that information into network defense capabilities using standardized protocols. SCAP v2 expands the endpoint types supported by SCAP v1 through the explicit inclusion of network equipment, Internet of Things (IoT), and mobile devices in its scope. To automate self-reporting of posture information from endpoint machines, SCAP v2 will integrate with existing network management protocols that include the Internet Engineering Task Force (IETF) Network Endpoint Assessment (NEA) protocols. SCAP v2 will streamline SCAP content acquisition and reuse through its use of the IETF Resource Oriented Lightweight Information Exchange (ROLIE) protocol. Improvements to software version identification and the incorporation of patch information will be made by transitioning from the Common Platform Enumeration (CPE) to Software Identification (SWID) Tags. SCAP v2 provides component-level interoperability via a modular and extensible architecture. This white paper provides a gap analysis of SCAP v1 and an overview of how SCAP v2 will address these gaps; describes the SCAP 2.0 architecture; and provides a plan for completing the work necessary to finalize SCAP v2.

SCAP composer user guide

“…SCAP Composer's release coincides with a new effort underway to improve upon SCAP version 1.3. Within the proposed scope of this "SCAP 2.0" initiative [22] is improved "SCAP content creation, acquisition, and reuse." SCAP Composer can contribute to this goal by making it easier to combine content into new source data streams.…”

Extending MUD Profiles Through an Automated IoT Security Testing Methodology

“…In particular, XCCDF [11] is used to represent the test results. XCCDF is a NIST specification and one of the main components of the Security Content Automation Protocol (SCAP) [41]. Unlike previous papers that are mainly focused on security testing aspects, this work integrates security testing results to build augmented MUD profiles to restrict the communication of IoT devices.…”

“…It should be noted that XCCDF is intended to be used to automate the verification of checklists using the Open Vulnerability and Assessment Language (OVAL) [69]. While some limitations have been identified for the use of XCCDF in the IoT context [70], the evolution of SCAP [41] aims to enhance different aspects of the current XCCDF specification to be considered in IoT. According to Figure 2, it should be noted that the Extended MUD file is generated based on such Assessment Report and the Original MUD file associated to the device itself.…”

“…Since IANA does not provide numeric identification for application layer protocols, the application protocol is defined though a string representing its name. This application layer protocol is further described with their associated policies (lines [36][37][38][39][40][41][42][43][44][45][46]. Furthermore, since different restrictions can be considered for each application-layer protocol, these fields could be repeated in the extended profile.…”

“…It is a NIST standard, which is supported by SCAP [68]. It should be noted that the next version of SCAP is intended to enhance XCCDF aspects to be considered in IoT scenarios [41] According to the specification, XCCDF documents contain a Benchmark element, which contains one or more elements, such as Rule, Value, TestResult and Group. Optionally it may include the element Profile to customise the benchmarking.…”