Network Security
Vulnerability Management
Privileged Access Management
Endpoint Security
Threat Hunting
Unified Endpoint Management
Email & Collaboration Security
Contents:
Security Content Automation Protocol (SCAP) is a security-centric methodology that enables organizations to automate software vulnerability management, measure and evaluate the policy compliance levels based on specific, industry standards, and opt-in for extra security padding, if necessary. SCAP is a collection of community-accepted security standards, hosted in open-source, online repositories. In this article, we are going to take a closer look at SCAP and discuss specifications, applicability, and organizational benefits.
Security Content Automation Protocol (SCAP) – Definition
According to NIST, SCAP is defined as
(…) a synthesis of interoperable specifications derived from community ideas. Community participation is a great strength for SCAP because the security automation community ensures the broadest possible range of use cases is reflected in SCAP functionality.
What this amount to is that SCAP specs are ‘round-table’ accords, based on empirical data and mid-to-long-term observations. The interoperability argument refers to the fact that all SCAP- derived security policies, procedures, and practices must be consistent across all organization-owned systems, regardless of status, Operating System, machine type, or purpose. To oversimplify things, we can regard the Security Content Automation Protocol as the mother of all security blueprints; regardless of your organizational motricity, all security schemas and workflows must follow SCAP to the proverbial letter.
Another aspect covered by and within SCAP is terminology and format standardization – basically creating a common security vocabulary. This last point is essential to establishing a functional baseline, one that will aid your organization measure performance, pinpoint deviations (e.g., misconfigurations, bugs, subpar Identity-based management, incorrectly applied patches, lack of IPsec, etc.), record changes, and ensure compliance to whatever standard your organization must adhere to.
The Security Content Automation Protocol has two major pillars: the SCAP Content, which contains all community-agreed specifications, and the SCAP toolbox – a collection of open-source and readily available vulnerability scanners that can be used to identify security baseline deviations and correct them. Let’s see SCAP’s specifications.
Security Content Automation Protocol Specifications
Under SCAP version Asset Identification 1.3, the specifications are as follows. Please bear in mind that the items contained in the list below are also called languages and, in some instances – as in the case of CCE – Identification Schema(s).
1. Common Configuration Enumeration (CCE)
CCE or Common Configuration Enumeration is a comprehensive list of identifiers for common and uncommon system configuration issues. This type of approach is useful for the fast retrieval of information, especially in an environment that runs multiple tools and/or information sources. The latest version of CCE is 5.20210407 (v.5) and it was last updated on the 7th of April 2021. Below, you’ll find an excerpt from CCE v.5 concerning Red Hat Enterprise Linux 6 config baseline.
| CCE ID v5 | CCE Title | USGCB Setting | Technical Mechanism | Configuration Details | Rationale | Impact | 800-53 Mapping | Defense Information Systems Agency Security Security Requirements Guide | Configuration Group |
|---|---|---|---|---|---|---|---|---|---|
| CCE-27043-9 | Disable Interactive Boot | disable | via grub | "To disable the ability for users to perform interactive startups, perform both of the following: Edit the file /etc/sysconfig/init. Add or correct the line: PROMPT=noInspect the kernel boot arguments (which follow the word kernel) in /etc/grub.conf and ensure the confirm argument is not present. Both the PROMPT option of the /etc/sysconfig/init file and the confirm kernel boot argument of the /etc/grub.conf file allow the console user to perform an interactive system startup, in which it is possible to select the set of services which are started on boot." | "Using interactive boot, the console user could disable auditing, firewalls, or other services, weakening system security." | medium | CM-6(a),SC-2(1) | SRG-OS-000080 | Protect Physical Console Access |
2. Common Platform Enumeration (CPE)
CPE or Common Platform Enumeration standardizes the process of identifying and describing systems or classes of systems (e.g., applications, operating systems, hardware devices). This Identification Schema is built on top of the CPE Stack, a layered model that describes the system’s capabilities, while streamlining the compartmentalization procedure.
Since the CPE Stack is a layered model, the base – which in this case is Naming – is considered to be the fundamental layer, meaning that all the top levels will be built on top of it, just like in the case of the OSI stack. As for the layers themselves, Naming provides the specs required to create a logical hierarchy for WFNs (Well-formed Names), formatted string bindings, and URI bindings. The second layer (i.e., Name matching) brings forth the specs needed to compare WFNs and, of course, establish if they point to one more or all products. Dictionary is the CPE’s lexical repository, containing all the metadata and names used to identify IT, product classes. The Applicability Language carries all the specs required to create a standard structure when deriving simple or complex logical expressions from Well-formed Names.
3. Open Vulnerability Assessment Language (OVAL)
OVAL (not to be confused with the OVAL Office) is a community-powered framework that standardizes the process of assessing and reporting on the current state of a machine. Written in XML, OVAL definitions can be employed to report vulnerability configurations, and the state of applied patches, and also offer key insights on compliance status and software inventory.
4. Open Checklist Interactive Language (OCIL)
OCIL or Open Checklist Interactive Language is a framework that enables IT security members, to address security-related questions to the end-users and later on to correctly (and automatically) interpret these answers. OCIL can also be used in conjunction with other automatic security frameworks such as OVAL. For instance, under SCAP, security checks fall into two major categories: manual and automatic. Now, in the case of low-level checking, OCIL takes precedence over OVAL since the latter cannot handle non-automated checks. In this type of scenario, OCIL can provide the following conceptual framework.
Ability to define questions (of type Boolean, Choice, Numeric, or String), ability to define possible answers to a question from which the user can choose, ability to define actions to be taken resulting from a user’s answer and the ability to enumerate the result set.
5. Trust Model for Security Automation Data (TMSAD)
All SCAP frameworks, whether we’re talking about OVAL, OCIL, or CPE rely on the Extensible Mark-up Language (XML) in security info exchange. TMSAD is a common trust model that regulates the processing of XML documents. Any TMSAD incorporates recommendations on how certain elements (e.g. key info, identity info, hashes, signatures) are represented within a document written up in the Extensible Mark-up Language and used for security automation purposes.
6. Extensible Configuration Checklist Description Format (XCCDF)
XCCDF is a language used to write benchmarks, checklists, and auxiliary security documents. In addition, this type of framework is used to ensure complete compliance in cases where the organization handles multiple policies, facilitates cooperation, increases the ‘manageability’ rate of audits and security checks, and simplifies the reporting and scoring processes.
7. Software Identification (SWID)
The last item on our list is Software Identification (SWID) – a framework that allows IT Security to easily manage compliance with SLAs, verify that the organizational assets are compliant with your company’s policies, conduct vulnerability management, and, of course, lay out a plan for future software investments.
Conclusion
Security Content Automation Protocol (SCAP) is a complex field, but vital to ensuring a healthy security posture. As I’ve said throughout this article, the scope of SCAP is to automate everything related to security, compliance, and auditing, a facility without which modern organizations can’t keep up with regulations and policies. Hope you’ve enjoyed this article and, as always, don’t forget, share, subscribe, and comment.
If you liked this article, follow us on LinkedIn, Twitter, Facebook, Youtube, and Instagram for more cybersecurity news and topics.
