Secure Content Automation Protocol (SCAP): How it is increasingly used to automate enterprise security management activities

(1)

Sean Barnum

[email protected]

September 2011

Secure Content Automation

Protocol (SCAP):

How it is increasingly used to automate

enterprise security management activities

(2)

■

What is SCAP?

■

Why SCAP?

■

How can SCAP be leveraged for the Common Criteria?

■

A proposed approach for integrating SCAP into the domain

of Common Criteria

Overview

(3)

(4)

activities:

– vulnerability and patch management

– secure configuration management

– policy compliance evaluation

– asset inventorying

– detecting system compromise

■ Motivating factors:

– Number and variety of systems to secure

– Need to respond quickly to new threats

– Lack of interoperability

– Complexity of guidance

– Number of security-related configuration settings

– Need to verify the security posture regularly

Security Content Automation Protocol

4

“SCAP was created to provide a

standardized approach to

maintaining the security of

enterprise systems, such as

automatically verifying the

presence of patches, checking

system security configuration

settings, and examining systems

for signs of compromise.”

NIST SP 800-117

A protocol leveraging a suite of seven preexisting open specifications that standardize the format and nomenclature by which security software communicates information about software flaws and security configurations.

(5)

CVE

Common Vulnerabilities & Exposures

Standard nomenclature and dictionary of security related software vulnerabilities

CCE

Common Configuration Enumeration

Standard nomenclature and dictionary of software

configurations

CPE

Common Platform Enumeration

Standard nomenclature and dictionary for product naming

XCCDF

eXtensible Checklist Configuration Description Format

Standard XML for specifying checklists and for reporting results of checklist evaluation

OVAL

Open Vulnerability and Assessment Language

Standard XML for system test procedures

OCIL

Open Checklist Interactive Language

Standard XML for expressing questions to an end user

CVSS

Common Vulnerability Scoring System

Standard for measuring the impact of vulnerabilities 5

SCAP Components

Naming

Expressing

Assessing

Scoring

(6)

What?

Assess

Why?

Policy

Layering the Security Automation Standards

6

OCIL

CCSS

(7)

Putting it Together

Inventory Management

– Universal identifiers for software (CPE)

– Language for testing procedures for software presence (OVAL/OCIL)

7

Configuration Policy

– Universal identifiers for configurable controls (CCE)

– Language for testing procedures for

configuration compliance (OVAL/OCIL)

– Language for organized configuration structuring and tailoring (XCCDF) Vulnerability Management – Universal identifiers for vulnerabilities (CVE) – Scoring system for vulnerabilities (CVSS) – Assessment language for checking for vulnerabilities (OVAL)

(8)

SCAP-enabled Tools are Available Today

■

SCAP is not some vague, future

promise

■

Over 40 vendors have tools certified

as SCAP compatible

■

Large amounts of freely available

content exist

■

Widely deployed in U.S. Government

enclaves using a variety of vendors

since 2007

(9)

Current SCAP-Validated Vendors

■

List of validated vendors and products available at

http://nvd.nist.gov/scapproducts.cfm

9

(10)

OVAL Open Vulnerability and Assessment Language CWE Common Weakness Enumeration CVE Common Vulnerabilities and Exposures CPE Common Platform Enumeration CVSS Common Vulnerability Scoring System CWSS Common Weakness Scoring System CCE Common Configuration Enumeration XCCDF eXensible Configuration Checklist Description Format ARF Assessment Result Format CEE Common Event Expression IODEF Incident Object Description Exchange Format CAPEC Common Attack Pattern Enumeration and Classification Application Specific Extensions Events,

Incidents, & Heuristics

W eaknesses, V ulnerabilities, & State

Information Exchange

Schema –

CYBEX context

(11)

OVAL Open Vulnerability and Assessment Language CWE Common Weakness Enumeration CVE Common Vulnerabilities and Exposures CPE Common Platform Enumeration CVSS Common Vulnerability Scoring System CWSS Common Weakness Scoring System CCE Common Configuration Enumeration XCCDF eXensible Configuration Checklist Description Format ARF Assessment Result Format CEE Common Event Expression IODEF Incident Object Description Exchange Format CAPEC Common Attack Pattern Enumeration and Classification Application Specific Extensions

Events, Incidents, & Heuristics

W eaknesses, V u lnerabilities, & State SCAP Security Automation Tools

Information Exchange

Schema –

(12)

x-series Title ITU-T Status Planned Determination x.1500 Cybersecurity Information Exchange (CYBEX) Techniques Final Dec 2010 x.1520 Common Vulnerabilities and Exposures Final Dec 2010 x.1521 Common Vulnerability Scoring System Final Dec 2010 x.cwe Common Weakness Enumeration Final Aug 2011 x.oval Open Vulnerability and Assessment Language Draft Aug 2011 x.cce Common Configuration Enumeration Draft Aug 2011 x.capec Common Attack Pattern Enumeration and Classification Draft Feb 2012 x.maec Malware Attribute Enumeration and Classification Draft 2012 x.cwss Common Weakness Scoring System Draft 2012 x.cee Common Event Expression Draft 2012 x.cpe Common Platform Enumeration Draft 2012 x.arf Asset Reporting Format Draft 2012 x.xccdf Extensible Configuration Checklist Description Format Draft 2012

(13)

■

Consumers

– Organizations should use security configuration checklists that are expressed using SCAP to improve and monitor their systems’

security.

– Organizations should take advantage of SCAP to demonstrate

compliance with high-level security requirements that originate from mandates, standards, and guidelines.

– Organizations should use SCAP for vulnerability measurement and scoring.

– Organizations should acquire and use SCAP-validated products.

SCAP For Product Consumers

(SP 800-117)

(14)

• Provide CPE names for all products

Configuration Controls

• Each security relevant configuration control is assigned a CCE through a federated CCE creation process.

Secure Configuration Baselines

• Development of configuration checks to confirm that a system is running under the specified secure configuration.

• Use XCCDF and OVAL to allow for machine interpretable content. • USE CPE and CCE to allow for platform targeting and data correlation.

Security Advisories

• Incorporate CVEs in initial vulnerability alert. • Assign CVSS scores to vulnerabilities.

• Include OVAL Definitions as a standardized machine interpretable check for the issue. • Include CPE Names for affected software

Support Automated System Integrations

• Develop Systems that can be Assessed • Provide OVAL extensions for new platforms

SCAP For Product Vendors

(SP 800-117)

(15)

(16)

SANS: 20 Critical Security Controls

(a.k.a. CAG)

16

“…transform security in government agencies and other large

enterprises by focusing their spending on the key controls that block known attacks and find the ones that get through.”

http://www.sans.org/critical-security-controls/

■

Enabling agreement between those responsible for

compliance and those responsible for security.

■

The Top 20 Controls were developed by a consortium

including:

– US NSA, US Cert, US DoD, the US Department of Energy

Nuclear Laboratories, US Department of State, industry experts

■

Automation of these Top 20 Controls will radically lower the

cost of security while improving its effectiveness.

– US Department of State iPost demonstrated more than 80% reduction in "measured" security risk

(17)

SANS: 20 Critical Security Controls

(a.k.a. CAG)

17 Critical Controls Subject to Automated Collection, Measurement, and Validation:

1. Inventory of Authorized and Unauthorized Devices

2. Inventory of Authorized and Unauthorized Software

3. Secure Configurations for Hardware and Software on Laptops, Workstations, and Servers

4. Secure Configurations for Network Devices such as Firewalls, Routers, and Switches

5. Boundary Defense

6. Maintenance, Monitoring, and Analysis of Security Audit Logs

7. Application Software Security

8. Controlled Use of Administrative Privileges

9. Controlled Access Based on Need to Know

10.Continuous Vulnerability Assessment and Remediation

11.Account Monitoring and Control

12.Malware Defenses

13.Limitation and Control of Network Ports, Protocols, and Services

14.Wireless Device Control

15.Data Loss Prevention

SCAP Enables Automation

(18)

■

SCAP and its targeted use cases are not just driven by US

needs

■

SCAP also supports numerous international drivers as well

– Commercial industry mandates such as the Payment Card Industry Data Security Standard (PCI-DSS) Requirement 6

– ISO security process and practices standards such as the 27000 series

– ITU security information structure and exchange

recommendations such as X.1000, X.1100, X.1200 & X.1500 series

– In-development standards and mandates surrounding supply chain security

– Etc.

SCAP Supports International Drivers

(19)

It’s Not Only About Discrete Specification

and Assessment

Inventory Management

– Universal identifiers for software (CPE)

– Language for testing procedures for software presence (OVAL/OCIL)

19

– Universal identifiers for configurable controls (CCE)

– Language for testing procedures for

configuration compliance (OVAL/OCIL)

– Language for organized configuration structuring and tailoring (XCCDF) Vulnerability Management – Universal identifiers for vulnerabilities (CVE) – Scoring system for vulnerabilities (CVSS)

(20)

Continuous Monitoring

20

“Agencies need to be able to continuously monitor security-related information from across the enterprise in a manageable and actionable way. Chief Information Officers (CIOs), Chief Information Security Officers (CISOs), and other agency management all need to have different levels of this information presented to them in ways that enable timely decision making. To do this, agencies need to automate security-related activities, to the extent possible, and acquire tools that correlate and analyze security-related information. Agencies need to develop automated risk models and apply them to the vulnerabilities and threats identified by security management tools.” OMB memo M-10-15

■

A result of numerous events coming together:

– SANS Top 20 Critical Controls (CAG)

– US OMB FISMA Reporting Memo (M-10-15)

– iPost: Implementing Continuous Risk Monitoring at the DoS

■

CM provides a foundation for many IA activities:

– IT Security Reporting, Vulnerability Management, Inventory Management, etc.

Information security continuous monitoring is defined as maintaining

ongoing awareness of information security, vulnerabilities, and threats

to support organizational risk management decisions.

(NIST 800-137)

(21)

21

CAESARS & Standards

CPE, CVE, OVAL, CVSS

CPE, CCE, OVAL, XCCDF

CPE, CCE, CVE OVAL, XCCDF, CVSS CPE, OVAL, XCCDF, CCE, CVE, CVSS CPE, CVE, CVSS Standardized Results Standardized Tasking

CAESARS: Continuous Asset Evaluation, Situational Awareness, and Risk Scoring - Reference Architecture

Database

Sensors

Analytics Presentation

(22)

■

Network Access Control (NAC) is seen as a key enabling

technology for several of the SANS Top 20 Critical Security

Controls.

■

SCAP provides a set of standard data formats that can be

used to describe desired system configurations.

■

Trusted Network Connect (TNC) provides a standards based

NAC solution.

■

SCAP and TNC can be used together to provide a complete

standards based approach.

Comply to Connect – SCAP and TNC Integration

(23)

Coordinated Security

Routing Server or Cloud Security

IDS Switching Wireless Firewalls IPAM SIM / SEM Asset Management System AAA ICS/SCADA Security Physical Security Endpoint Security (via NAC) IF-MAP Protocol MAP

(24)

Coordinated Security & NAC Together

Access

Requestor

(AR)

Policy

Enforcement

Point

(PEP)

Policy

Decision

Point

(PDP)

Metadata

Access

Point

(MAP)

Sensors,

Flow

Controllers

(25)

TNC and SCAP Together

Access

Requestor

(AR)

Policy

Enforcement

Point

(PEP)

Policy

Decision

Point

(PDP)

Metadata

Access

Point

(MAP)

Sensors,

Flow

Controllers

SCAP Client Software SCAP Analysis Software SCAP External Scanner

(26)

(27)

SCAP Value for the Common Criteria

Inventory Management – Evaluators: Clear understanding of 3rd party components in TOE – Consumers: Clear understanding of which systems are deployed and if those systems are the same ones that were evaluated

27

– Vendors: Secure

configuration specification for products to be evaluated

– Evaluators: Ensure product is being evaluated as intended

– Consumers: Secure

configuration compliance to ensure operational system is still the same as the one that was evaluated

Vulnerability Management

– Vendors: Ensure all TOE 3rd party

components are patched before submitting for evaluation

– Evaluators: Test for known vulnerabilities in TOE 3rd party

(28)

■

Common Criteria evaluated products are trusted to operate

in the deployed environment

■

Standard secure configuration baseline is defined as part of

the CC evaluation

■

Continuously monitor configuration state of deployed

product

■

If configuration changes from standard baseline (i.e. the

product running is no longer the product that was

evaluated), report an alert, revoke operation privileges for

the product and/or remove it from the network

Paralleling the TNC/SCAP Approach for CC

Evaluated Products

(29)

SCAP and NIAP Integration Overview

29

MITRE Developed a white paper that describes the logical ways in which to integrate SCAP into NIAP.

- Shared paper with firewall protection profile group.

- Briefed the firewall protection profile group during RSA.

- Could be added to emerging profiles as they are ready.

■

Motivation:

– SANS Top 20

– Continuous Monitoring

– DHS Cyber Ecosystem

■

Enable automated monitoring of

products

– Faster more accurate identification of issues

– Deliver actionable secure configuration guidance

■

Identified seven areas to utilize

SCAP

■

Aligned with relevant CAG

(30)

1. Standardized Product Names

– Enables fast, accurate correlation across information sources.

2. Standardized configuration item identification

3. Enable automated secure configuration checking

– Enables automated checking during NIAP evaluation.

4. Structured secure configuration guides

– Enables automated checking for adherence to the policy.

5. Inventory/asset management support

– End users can use the asset management tool of choice.

6. Vulnerability identification, disclosure, & response practices

– Faster responses to security advisories by end users.

7. Patch checking

– End users can use the patch management tool of choice.

Seven Areas for Integration Identified

(31)

1. Standardized Product Names

2. Standardized configuration item identification

3. Enable automated secure configuration checking

– Enables automated checking during NIAP evaluation.

4. Structured secure configuration guides

– Enables automated checking for adherence to the policy.

5. Inventory/asset management support

– End users can use the asset management tool of choice.

6. Vulnerability identification, disclosure, & response practices

7. Patch checking

– End users can use the patch management tool of choice.

Areas for Integration Aligned with SCAP

31

Product Names

Configuration Controls

Secure Configuration Baselines

(32)

(33)

■

SCAP covers a wide range of use cases,

practices, standards and content

■

Integrating it all in one big chunk would

likely prove very challenging and make its

practical application less likely

■

We suggest a staged integration approach

that starts out low-effort and builds

capability in a tiered fashion

(34)

Staged Integration

Area Tier 1 Utilize Standard Naming Tier 2 Define Structured Guidance Tier 3

Assess & Validate

Standardized Product Names CPE

SWID*

API for CPE

Standardized Configuration Item Identification

CCE

Enable Automated Secure Configuration Checking

API for CCE Specify OVAL construct for

CCE

Structured Secure Configuration Guides XCCDF, CPE,

CCE

XCCDF, CPE, CCE, OVAL Compliance Definitions

Inventory/Asset Management Support OVAL Inventory Definitions

Vulnerability Identification, Disclosure, and Response Practices

CPE, CVE, CVSS SWID*

OVAL Vulnerability Definitions

Patch Checking CPE, CVE, CVSS

SWID*

OVAL Inventory Definitions

(35)

35

Staged Integration

Tier 1

• Low effort integration of the most mature SCAP components. • Enables correlation across information sources.

• Requires knowledge of CCE, CPE, CVE, and CVSS.

Tier 2

• Structured guidance and published APIs. • Foundation for automated system checking.

• Requires knowledge of XCCDF and exposure of APIs.

Tier 3

• Automated checking of system state (patched, configured securely, vulnerable, etc.).

• Requires knowledge of OVAL.

Define Structured Guidance & Enable Automation Utilize Standard Naming

(36)

■

More information on the standards

–

CVE – Vulnerabilities; http://cve.mitre.org

–

CCE – Configuration controls; http://cce.mitre.org

–

CPE – Platforms/applications; http://cpe.mitre.org

–

OVAL – Checking language; http://oval.mitre.org

–

OCIL – Questionnaire language;

http://scap.nist.gov/specifications/ocil

–

XCCDF – Structuring; http://nvd.nist.gov/xccdf.cfm

–

CVSS – Scores severity of vulnerabilities;

http://www.first.org/cvss/

–

NVD – Resources for SCAP users;

http://nvd.nist.gov/home.cfm

–

Making Security Measureable – More resources on SCAP

and beyond; http://measurablesecurity.mitre.org/

For More Information…

(37)

(38)

(39)

■

Vendor Actions:

– Register and maintain a CPE Name for the product

– Ensure that all dependent products have registered CPE Names

– Provide programmatic means to query the product for its CPE Name

– List CPE Names in product documentation

■

Validator Role:

– Verify CPE Name is listed in Official CPE Dictionary

– Verify that CPE “API” is documented and functioning properly

■

Benefit:

– Enables fast, accurate correlation across information sources

– Enables correlation of product and platform information for use in asset management, situational awareness, and continuous monitoring.

1. Standardized Product Names

Register a CPE Name for the product

and its dependencies.

(40)

■

Vendor Actions:

– Identify all security relevant configuration controls

– Assign CCE IDs to all security relevant configuration controls

■

Validator Role:

– CCEs are listed for the product

– Product’s Secure Configuration Guide includes CCE references.

■

Benefit:

– Enables fast, accurate correlation across information sources

– Completes a first step toward supporting automated configuration checking

– Tool vendors understand what the configuration items are, and what to check for

2. Standardized configuration item identification

Assign a CCE to all security relevant

configuration controls in the product.

(41)

■

Vendor Actions:

– For each CCE in the product, provide a programmatic means to check and set the state of that value

– Identify the proper OVAL construct for checking the state of each CCE

■

Validator Role:

– Verify vendor listing of programmatic methods for all CCEs

■

Benefit:

– Enables automated checking during NIAP evaluation

– Provides foundation for automated secure configuration guides

– Product is instrumented for continuous monitoring

3. Enable automated secure configuration checking

Instrument security relevant configuration controls

for automated configuration checking.

(42)

■

Vendor Actions:

– Create an SCAP-expressed benchmark for the secure configuration of the product

■

Validator Role:

Verify that the SCAP-expressed benchmark is available and valid

■

Benefit:

– Enables faster more accurate checking for adherence to the policy.

– End users can use SCAP-validated tool of their choice to determine if a the product is properly configured.

– An evaluator can run automated verification of the secure configuration on all test systems

4. Structured secure configuration guides

Enable standardized automatic software configuration

checking using CPE, OVAL and XCCDF.

(43)

■

Vendor Actions:

– Publish an OVAL Definition for detecting the presence of the product

– Reference the CPE Name for the product in the OVAL Definition

■

Validator Role:

– Verify that an OVAL Inventory Definition has been published

■

Benefit:

– End users can use SCAP-validated tool of their choice to determine if the product is present on their system.

5. Inventory/asset management support

Enable standardized automatic software

inventories using CPE and OVAL.

(44)

■

Vendor Actions:

– Include a CVE ID in all vulnerability alerts

– Include CPE Names for all affected products in all vulnerability alerts

– Provide a CVSS base score for all vulnerabilities

– Publish an OVAL Definition for detecting the presence of the vulnerability

■

Validator Role:

– Verify documented use of SCAP in flaw remediation practices

■

Benefit:

– Vulnerabilities are identified, prioritized, and described in a standardized way.

6. Vulnerability identification, disclosure

and response practices

Enable standardized automatic software vulnerability

checking using CPE, OVAL and CVE.

(45)

■

Vendor Actions:

– Publish standardized patch checks as OVAL definitions

– Include the list of affected products by CPE Name in patch bulletins

– List all vulnerabilities addressed by their CVE ID

■

Validator Role:

– Verify that the documented vendor patch processes include OVAL, CPE. and CVE.

■

Benefit:

– End users can use SCAP-validated tool of their choice to determine if a patch is installed on their system to help keep their system up to date