SCAP技术规范：安全内容自动化协议V1.2

需积分: 0 37 浏览量更新于2024-07-16 收藏 1.32MB PDF 举报

"NIST SP800-126r2.pdf" 是关于Security Content Automation Protocol（SCAP）的详细技术规范，版本1.0。SCAP是一套标准，用于规范安全软件交流软件漏洞和安全配置信息的形式和术语。这份文档涵盖了SCAP组件规范的基本内容、它们之间的相互关系，以及在单独组件规范中未定义的SCAP要求。其范围仅限于SCAP版本1.0，不涉及其他版本或组件规范。 SCAP的主要目标是提高网络安全自动化的能力，它定义了一组开放的标准，使得不同的安全工具和系统能够有效地交换和验证关于系统状态的数据。这些数据包括已知的安全漏洞、配置基准和身份认证信息。通过使用SCAP，组织可以更有效地检测和管理其IT环境中的安全风险，确保符合安全政策，并保持与最新的威胁情报同步。 SCAP由以下几个关键组件构成： 1. **Common Vulnerability Enumeration (CVE)**：一个公开的、唯一的漏洞标识系统，用于识别和追踪已知的安全漏洞。 2. **Common Platform Enumeration (CPE)**：提供标准化的方法来命名和识别硬件、软件和固件平台。 3. **Open Vulnerability Assessment Language (OVAL)**：一种XML语言，用于定义检查系统状态的规则，以确定是否存在特定的安全问题。 4. **Common Configuration Enumeration (CCE)**：定义了系统的安全配置项及其预期状态。 5. **Scalable Vector Graphics (SVG)**：用于表示扫描结果的可视化图形。在SCAP Version 1.2中，这些组件进一步发展和完善，提供了更多的功能和兼容性，以适应不断变化的安全需求。例如，可能增加了对新类型的安全漏洞的识别能力，改进了与不同操作系统和应用程序的集成，以及提高了数据交换的效率和准确性。 NIST（美国国家标准与技术研究院）发布的这份特殊出版物800-126r2，由David Waltermire、Stephen Quinn、Karen Scarfone和Adam Halbardier共同撰写，旨在为IT安全专业人士提供指导，帮助他们理解和实施SCAP技术，以提升其网络防御能力。 SCAP是网络安全领域的一个重要工具，通过标准化的数据交换，促进了安全信息的共享和自动化处理，从而提高了组织对网络安全威胁的响应速度和效率。对于任何需要管理大量设备和应用安全性的大型机构而言，理解和利用SCAP规范是至关重要的。

The Technical Specification for the Security Content Automation Protocol (SCAP): SCAP Version 1.2

1. Introduction

1.1 Authority

The National Institute of Standards and Technology (NIST) developed this document in furtherance of its

statutory responsibilities under the Federal Information Security Management Act (FISMA) of 2002,

Public Law 107-347.

NIST is responsible for developing standards and guidelines, including minimum requirements, for

providing adequate information security for all agency operations and assets; but such standards and

guidelines shall not apply to national security systems. This guideline is consistent with the requirements

of the Office of Management and Budget (OMB) Circular A-130, Section 8b(3), “Securing Agency

Information Systems,” as analyzed in A-130, Appendix IV: Analysis of Key Sections. Supplemental

information is provided in A-130, Appendix III.

This guideline has been prepared for use by Federal agencies. It may be used by nongovernmental

organizations on a voluntary basis and is not subject to copyright, though attribution is desired.

Nothing in this document should be taken to contradict standards and guidelines made mandatory and

binding on Federal agencies by the Secretary of Commerce under statutory authority, nor should these

guidelines be interpreted as altering or superseding the existing authorities of the Secretary of Commerce,

Director of the OMB, or any other Federal official.

1.2 Purpose and Scope

This document provides the definitive technical specification for version 1.2 of the Security Content

Automation Protocol (SCAP). SCAP (pronounced ess-cap) consists of a suite of specifications for

standardizing the format and nomenclature by which software flaw and security configuration information

is communicated, both to machines and humans. This document defines requirements for creating and

processing SCAP source content. These requirements build on the requirements defined within the

individual SCAP component specifications. Each new requirement pertains either to using multiple

component specifications together or to further constraining one of the individual component

specifications. The requirements within the individual component specifications are not repeated in this

document; see those specifications to view their requirements.

The scope of this document is limited to SCAP version 1.2. Other versions of SCAP and its component

specifications, including emerging specifications, are not addressed here. Future versions of SCAP will be

defined in distinct revisions of this document, each clearly labeled with a document revision number and

the appropriate SCAP version number. SCAP revisions are managed through a coordinated process

defined within the SCAP Release Cycle.

The release cycle workflow manages changes related to SCAP

specifications and validation processes including the addition of new specifications or updates to existing

specifications. This process encourages community involvement, promotes transparency and awareness

regarding proposed changes, and affords ample lead time to prepare for pending changes.

1.3 Audience

This document is intended for three primary audiences:

 Content authors and editors seeking to ensure that the SCAP source content they produce operates

correctly, consistently, and reliably in SCAP products.

 Software developers and system integrators seeking to create, use, or exchange SCAP content in their

products or service offerings.

http://scap.nist.gov/timeline.html

The Technical Specification for the Security Content Automation Protocol (SCAP): SCAP Version 1.2

 Product developers preparing for SCAP validation at an accredited independent testing laboratory.

This document assumes that readers already have general knowledge of SCAP and reasonable familiarity

with the SCAP component specifications that their content, products, or services use. Individuals without

this level of knowledge who would like to learn more about SCAP should consult NIST Special

Publication (SP) 800-117, Guide to Adopting and Using the Security Content Automation Protocol.

1.4 Document Structure

The remainder of this document is organized into the following major sections and appendices:

 Section 2 provides the high-level requirements for claiming conformance with the SCAP 1.2

specification.

 Section 3 details the requirements and recommendations for SCAP content syntax, structure, and

development.

 Section 4 defines SCAP content processing requirements and recommendations.

 Section 5 provides additional content requirements and recommendations for particular use cases.

 Appendix A gives an overview of major security considerations for SCAP implementation.

 Appendix B contains an acronym and abbreviation list.

 Appendix C contains a glossary of selected terms used in the document.

 Appendix D lists references and other resources related to SCAP 1.2.

 Appendix E provides a change log that documents significant changes to major drafts of this

specification.

1.5 Document Conventions

The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”,

“SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be

interpreted as described in Request for Comment (RFC) 2119 [RFC2119]. When these words appear in

regular case, such as “should” or “may”, they are not intended to be interpreted as RFC 2119 key words.

When a single term within a sentence is italicized, this indicates that the term is being defined. These

terms and their definitions also appear in Appendix C.

Some of the requirements and conventions used in this document reference Extensible Markup Language

(XML) content [XMLS]. These references come in two forms, inline and indented. An example of an

inline reference is: a <cpe2_dict:cpe-item> may contain <cpe2_dict:check> elements that

reference OVAL Definitions.

In this example the notation <cpe2_dict:cpe-item> can be replaced by the more verbose

equivalent “the XML element whose qualified name is cpe2_dict:cpe-item”.

An example of an indented reference is:

References to OVAL Definitions are expressed using the following format:

<cpe2_dict:check system=

"http://oval.mitre.org/XMLSchema/oval-definitions-5"

href="Oval_URL">[Oval_inventory_definition_id]

http://csrc.nist.gov/publications/PubsSPs.html#800-117

The Technical Specification for the Security Content Automation Protocol (SCAP): SCAP Version 1.2

</cpe2_dict:check>.

The general convention used when describing XML attributes within this document is to reference the

attribute as well as its associated element including the namespace alias, employing the general form

"@attributeName for the <prefix:localName>".

Indented references are intended to represent the form of actual XML content. Indented references

represent literal content by the use of a fixed-length font, and parametric (freely replaceable)

content by the use of an italic font. Square brackets ‘[]’ are used to designate optional content. Thus

"[Oval_inventory_definition_id]" designates optional parametric content.

Both inline and indented forms use qualified names to refer to specific XML elements. A qualified name

associates a named element with a namespace. The namespace identifies the XML model, and the XML

schema is a definition and implementation of that model. A qualified name declares this schema to

element association using the format ‘prefix:element-name’. The association of prefix to namespace is

defined in the metadata of an XML document and varies from document to document. In this

specification, the conventional mappings listed in Table 1 are used.

Table 1. Conventional XML Mappings

Prefix

Namespace

Schema

http://scap.nist.gov/schema/asset-identification/1.1

Asset Identification

arf

http://scap.nist.gov/schema/asset-reporting-format/1.1

ARF

arf-rel

http://scap.nist.gov/vocabulary/arf/relationships/1.0#

ARF relationships

cat

urn:oasis:names:tc:entity:xmlns:xml:catalog

XML Catalog

con

http://scap.nist.gov/schema/scap/constructs/1.2

SCAP Constructs

cpe2

http://cpe.mitre.org/language/2.0

Embedded CPE references

cpe2-dict

http://cpe.mitre.org/dictionary/2.0

CPE dictionaries

cve

http://scap.nist.gov/schema/vulnerability/0.4

NVD/CVE data feed elements and attributes

cvss

http://scap.nist.gov/schema/cvss-v2/0.2

NVD/CVSS data feed elements and attributes

http://purl.org/dc/elements/1.1/

Simple Dublin Core elements

http://scap.nist.gov/schema/scap/source/1.2

SCAP source data stream collection

http://scap.nist.gov/schema/xml-dsig/1.0

Security automation digital signature

extensions

nvd

http://scap.nist.gov/schema/feed/vulnerability/2.0

Base schema for NVD data feeds

ocil

http://scap.nist.gov/schema/ocil/2.0

OCIL elements and attributes

oval

http://oval.mitre.org/XMLSchema/oval-common-5

Common OVAL elements and attributes

oval-def

http://oval.mitre.org/XMLSchema/oval-definitions-5

OVAL Definitions

oval-res

http://oval.mitre.org/XMLSchema/oval-results-5

OVAL results

oval-sc

http://oval.mitre.org/XMLSchema/oval-system-

characteristics-5

OVAL system characteristics

oval-var

http://oval.mitre.org/XMLSchema/oval-variables-5

The elements, types, and attributes that

compose the core schema for encoding OVAL

Variables. This schema is provided to give

structure to any external variables and their

values that an OVAL Definition is expecting.

scap-rel

http://scap.nist.gov/vocabulary/scap/relationships/1.0#

SCAP relationships

sch

http://purl.oclc.org/dsdl/schematron

Schematron validation scripts

xccdf

http://checklists.nist.gov/xccdf/1.2

XCCDF policy documents

xlink

http://www.w3.org/1999/xlink

XML Linking Language

剩余57页未读，继续阅读

艾米的爸爸

粉丝: 821

SCAP技术规范：安全内容自动化协议V1.2

NIST SP800-126.pdf

NIST SP800-153.pdf

NIST SP800-177r1.pdf

NIST SP800-67r2.pdf

NIST SP800-87r2.pdf

NIST SP800-61r2.pdf

NIST SP800-126r3.pdf

NIST SP800-126r1.pdf

NIST SP800-107.pdf

NIST SP800-14.pdf

最新资源