Specification for the Extensible Configuration Checklist ...
82
pages
English
Documents
Le téléchargement nécessite un accès à la bibliothèque YouScribe Tout savoir sur nos offres
82
pages
English
Documents
Le téléchargement nécessite un accès à la bibliothèque YouScribe Tout savoir sur nos offres
Publié par
Langue
English
NISTIR 7188
Specification for the Extensible
Configuration Checklist Description Format
(XCCDF)
Neal Ziring, Author,
National Security Agency
John Wack, NIST Editor
NISTIR 7188
Specification for the Extensible
Configuration Checklist Description Format
(XCCDF)
Neal Ziring, NSA Author
Information Assurance Directorate
National Security Agency
Fort Meade, MD 20755-6704
John Wack, NIST Editor
Computer Security Division
Information Technology Laboratory
National Institute of Standards and Technology
Gaithersburg, MD 20988-8930
January 2005
U.S. DEPARTMENT OF COMMERCE
Donald L. Evans, Secretary
TECHNOLOGY ADMINISTRATION
Phillip J. Bond, Under Secretary of Commerce for Technology
NATIONAL INSTITUTE OF STANDARDS AND TECHNOLOGY
Hratch G. Semerjian, Acting Director
Abstract
This document specifies the data model and XML representation for the Extensible
Configuration Checklist Description Format (XCCDF). An XCCDF document is a structured
collection of security configuration rules for some set of target systems. The XCCDF
specification is designed to support information interchange, document generation,
organizational and situational tailoring, automated compliance testing, and compliance scoring.
The specification also defines a data model and format for storing results of benchmark
compliance testing. The intent of XCCDF is to provide a uniform foundation for expression of
security checklists ...
Publié par
Langue
English
NISTIR 7188
Specification for the Extensible
Configuration Checklist Description Format
(XCCDF)
Neal Ziring, Author,
National Security Agency
John Wack, NIST Editor
NISTIR 7188
Specification for the Extensible
Configuration Checklist Description Format
(XCCDF)
Neal Ziring, NSA Author
Information Assurance Directorate
National Security Agency
Fort Meade, MD 20755-6704
John Wack, NIST Editor
Computer Security Division
Information Technology Laboratory
National Institute of Standards and Technology
Gaithersburg, MD 20988-8930
January 2005
U.S. DEPARTMENT OF COMMERCE
Donald L. Evans, Secretary
TECHNOLOGY ADMINISTRATION
Phillip J. Bond, Under Secretary of Commerce for Technology
NATIONAL INSTITUTE OF STANDARDS AND TECHNOLOGY
Hratch G. Semerjian, Acting Directo
r
Abstract
This document specifies the data model and XML representation for the Extensible
Configuration Checklist Description Format (XCCDF).
An XCCDF document is a structured
collection of security configuration rules for some set of target systems.
The XCCDF
specification is designed to support information interchange, document generation,
organizational and situational tailoring, automated compliance testing, and compliance scoring.
The specification also defines a data model and format for storing results of benchmark
compliance testing.
The intent of XCCDF is to provide a uniform foundation for expression of
security checklists, benchmarks, and other configuration guidance, and thereby foster more
widespread application of good security practices.
iii
Purpose and Scope
The Cyber Security Research and Development Act of 2002 tasks the National Institute of
Standards and Technology (NIST) to
“develop, and revise as necessary, a checklist setting forth
settings and option selections that minimize the security risks associated with each computer
hardware or software system that is, or is likely to become widely used within the Federal
Government.”
Such checklists, when combined with well-developed guidance, leveraged with
high-quality security expertise, vendor product knowledge, operational experience, and
accompanied with tools, can markedly reduce the vulnerability exposure of an organization.
To promote the use, standardization, and sharing of effective security checklists, NIST and NSA
have collaborated with representatives of private industry to developed the XCCDF
specification.
The specification is vendor-neutral, flexible, and suited for a wide variety of
checklist applications.
Audience
The primary audience of the XCCDF specification is government and industry security analysts,
and industry security management product developers.
NIST and NSA welcome feedback from
these groups in improving the XCCDF specification.
iv
Table of Contents
1.
Introduction............................................................................................................................. 1
1.1.
Background..................................................................................................................... 1
1.2.
Vision for Use................................................................................................................. 2
2.
Requirements .......................................................................................................................... 3
2.1.
Structure and Tailoring Requirements............................................................................ 4
2.2.
Inheritance and Inclusion Requirements......................................................................... 5
2.3.
Document and Report Formatting Requirements ........................................................... 6
2.4.
Rule Checking Requirements ......................................................................................... 6
2.5.
Metadata and Security Requirements ............................................................................. 7
3.
Data Model.............................................................................................................................. 8
3.1.
Benchmark Structure ...................................................................................................... 9
3.2.
Object Detailed Contents.............................................................................................. 10
3.3.
Processing Models ........................................................................................................ 21
4.
XML
Representation............................................................................................................ 29
4.1.
XML Document General Considerations ..................................................................... 29
4.2.
XML Element Dictionary ............................................................................................. 30
4.3.
Text and String Content................................................................................................ 49
5.
Conclusions........................................................................................................................... 51
6.
Appendix A – XCCDF Schema............................................................................................ 52
7.
Appendix B – Sample Benchmark File ................................................................................ 71
8.
References............................................................................................................................. 76
v
Acknowledgements
The editor would like to acknowledge the following individuals who contributed to the initial
definition of XCCDF and its initial development: David Proulx, Mike Michinikov, Andrew
Buttner, Todd Wittbold, Adam Compton, George Jones, Chris Calabrese, John Banghart,
Murugiah Souppaya, John Wack, Trent Pitsenbarger, and Robert Stafford.
David Waltermire of
the Center for Internet Security was instrumental in supporting the development of XCCDF; he
contributed many important concepts and constructs, performed a great deal of proofreading on
this specification document, and provided critical input based on implementation experience.
Ryan Wilson of Georgia Institute of Technology also made substantial contributions.
Trademark Information
Cisco and IOS are registered trademarks of Cisco Systems, Inc. in the USA and other countries.
Windows is a registered trademark of Microsoft Corporation in the USA and other countries.
Solaris is a registered trademark of Sun Microsystems, Inc.
OVAL is a trademark of The
MITRE Corporation.
Warnings
SOFTWARE IS PROVIDED "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES,
INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE EXPRESSLY
DISCLAIMED. IN NO EVENT SHALL THE CONTRIBUTORS BE LIABLE FOR ANY
DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE
GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY,
WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE
OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE,
EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
vi
1. Introduction
The security of an IT system may be measured in a variety of ways, but one way that has
worked well in practice is conformance of the system configuration to a security
benchmark.
A typical benchmark includes criteria and rules for hardening a system
against the most common forms of compromise and exploitation, and for reducing the
exposed ‘attack surface’ of a system.
Many different companies, government agencies,
and community groups create and disseminate security benchmarks.
While these various
organizations often cooperate on the definition of the rules embodied in these consensus
benchmarks, the underlying specification, test, and report formats used for these
endeavors have been specialized and unique.
Configuring a system into conformance with a benchmark or other security specification
is a highly technical task.
To aid system administrators, commercial and community
developers have created automated tools that can score a system’s conformance and
recommend corrective measures.
Many of these tools are data-driven: they accept a
benchmark specification in some program-readable form, and use it to perform the
checks and tests necessary to measure conformance and generate reports.
However, with
rare exceptions, none of these tools employ the same data formats, thus requiring
duplication of effort and precluding interoperability.
This note describes a data model and processing discipline for supporting secure
configuration and assessment.
The requirements and goals are explained in detail below,
but may be summarized briefly as document generation, expression of policy-aware
configuration rules, support for complex and compound rules, support for compliance
scoring, and support for customization and tailoring.
The model and its XML
representation are intended to be platform-independent and portable, to foster broad
adoption and sharing of rules.
The processing discipline of the format requires, for some
uses, a service layer that can collect and store system information and perform simple
policy-neutral tests against the system information.
These conditions are described in
detail below.
The XML representation is expressed as an XML Schema in Appendix A.
This document 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.
1.1. Background
Today, groups promoting good security practices and system owners wishing to adopt
them face an overload in the size and complexity of their tasks. As systems get larger,
automated tools become a necessity for uniform application of security rules and
visibility into system status. These conditions have created a need for mechanisms that:
•
permit faster, more cooperative, and more automated definition of security rules,
procedures, guidance documents, alerts, advisories, and remediation measures,
•
permit fast, uniform, manageable administration of security checks and audits,
•
permit composition of security rules and tests from different community groups
and vendors,
NISTIR 7188: XCCDF Specification
1
1
•
permit scoring and reporting of security status, both over distributed systems and
over the same systems across their operational lifetimes,
•
foster development of interoperable community and commercial tools for creating
and employing security benchmarks.
Today, such mechanisms exist only in some isolated niche areas (e.g. MS Windows
tm
patch validation) and they support only narrow slices of security benchmark compliance
functionality. This note proposes a data model and format specification for an extensible,
interoperable benchmark ‘language’.
1.2. Vision for Use
XCCDF is designed to enable easier, more uniform creation of security benchmarks, and
allow benchmarks to be used with a variety of commercial and open tools.
The
motivation for this is improvement of security for IT systems, including the Internet, by
better application of known security practices and configuration settings.
The scenarios below illustrate some uses of security benchmarks and tools that XCCDF
will foster.
•
Scenario 1 –
An academic group produces a benchmark for secure configuration of a particular
server operating system version.
A government organization issues a set of rules
extending the academic benchmark to meet more stringent user authorization
criteria imposed by statute.
A medical enterprise downloads both the academic
benchmark and the government extension, tailors the combination to fit their
internal security policy, and applies an enterprise-wide audit using a commercial
security audit tool.
Reports output by the tool include remediative measures
which the medical enterprise IT staff use to bring their systems into full internal
policy compliance.
•
Scenario 2 –
A federally-funded lab issues a security advisory about a new Internet worm.
In
addition to a prose description of the worm’s attack vector, they include a set of
short benchmarks in a standard format that assess vulnerability to the worm for
various operating system platforms.
Organizations all over the world pick up the
advisory, and use installed tools that support the standard format to check their
status and fix vulnerable systems.
•
Scenario 3 –
An industry consortium wants to produce a security checklist for a popular
commercial server.
The core security settings are the same for all OS platforms
on which the server runs, but a few settings are OS-specific.
The consortium can
craft one checklist in a standard format for the core settings, and then write
several OS-specific ones that incorporate the core settings by reference.
Users
download the core checklist and the OS-specific checklists that apply to their
installations, and run a checking tool to score their compliance with the checklist.
NISTIR 7188: XCCDF Specification
2
2
2. Requirements
The general objective for XCCDF is to allow security analysts and IT experts to create
effective and inter-operable benchmarks, and to support use of benchmarks with a wide
variety of tools.
Figure 1 shows some purposes for which a benchmark might be used.
Benchmark results
pdf
Security
Experts
and
Domain
Experts
Tailoring
Tools
Transform
Engine
Document
Generator
System
Administrator
or
Auditor
Compliance
Benchmarking
Tool
Other
Reporting
Tools
html
xsl
xml
xccdf
Security Status
Monitor or
Vulnerability Tester
System
Under
Test
Other
Tools
Benchmark Reports
Web pages
Publication
Documents
XCCDF
benchmark format
Non-compliance or
vulnerability
alerts
Formatting
information
Stylesheets
Fix scripts or updates
1
2
3
4
5
6
7
8
XML
XCCDF
XCCDF
XCCDF
XCCDF
System
tests
Figure 1 – Use Cases for XCCDF Documents
The list below describes some requirements for each of the uses.
1.
Security and domain experts create a benchmark, which is an organized collection
of rules about a particular kind of system or platform.
To support this use,
XCCDF must be an open, standardized format, amenable to generation and
editing with a variety of tools.
It must be expressive enough to represent complex
conditions and relationships about the systems to be benchmarked, and it must
also be able to incorporate descriptive material and remediative measures.
(XCCDF benchmarks may include specification of the hardware and/or software
platforms to which they apply.
The specification should be concrete and granular
enough for compliance checking tools to detect whether a rule is suited for a
target platform.)
NISTIR 7188: XCCDF Specification
3
3
2.
Auditors and system administrators may employ tailoring tools to customize a
benchmark for their local environment or policies.
An XCCDF document must
include the structure and interrogative text needed to guide the user in tailoring a
benchmark, and it must be able to hold or incorporate the user’s tailoring
responses.
3.
In addition to supporting tailoring and security audits, an XCCDF document
should be structured to foster generation of hardcopy benchmark guides.
4.
The structure of a XCCDF document should support transformation into HTML,
for posting the benchmark as a web page.
5.
An XCCDF document should be transformable into (other) XML formats, to
promote portability and interoperability.
6.
The primary use for an XCCDF benchmark is to drive automated security
benchmarking tools.
Such tools should accept one or more XCCDF documents,
and supporting system test definitions, and check whether their rules are satisfied
by some particular target system.
The XCCDF document should support
generation of a compliance report, including a weighted compliance score.
7.
In addition to a benchmark report, some benchmarking tools may be capable of
generating scripts or procedures for helping to bring a system into compliance.
XCCDF must be able to hold or encapsulate the remediation scripts or texts.
8.
XCCDF documents might also be used in vulnerability scanners, to test whether a
target system is vulnerable to a particular kind of attack.
For this purpose, the
XCCDF document would play the role of a vulnerability alert, but with the ability
to both describe the problem and drive automated verification of its presence.
In addition to these use cases, an XCCDF document should be amenable to embedding
inside other documents, and to having data expressed in other formats embedded inside
of it.
Also, as its name implies, XCCDF must be extensible – it must be possible for new
functionality and features to be added to XCCDF-capable tools and data for those new
features stored in XCCDF without breaking other tools.
2.1. Structure and Tailoring Requirements
To support tailoring by users, and generation of documents for users, XCCDF must allow
authors to impose organization on a benchmark.
Benchmark authors will need to arrange
rules in order, and collect them into groups.
For benchmark structure, a benchmark author must be able to designate the order in
which rules or groups are to be processed.
As the simplest case, processing order can be
simply the order in which the rules appear in the XCCDF document.
For tailoring, values, rules and groups will need descriptive and interrogative text to help
a user make tailoring decisions.
Two basic kinds of tailoring will be needed:
•
Selectability – a tailoring action might select or deselect a rule or group of rules
for inclusion or exclusion from the benchmark.
For example, at a site where no
FTP service is used, an auditor might choose to deselect all rules about secure
configuration of the FTP server.
NISTIR 7188: XCCDF Specification
4
4
•
Substitution – a tailoring action might substitute a locally-significant value for a
general value in a rule.
For example, at a site where all logs are sent to a
designated logging host, the address of that log server might be substituted into a
rule about audit configuration.
Once benchmarks can be tailored, the possibility arises that some rules within the same
benchmark might conflict or be mutually exclusive.
In other words, the author of a
benchmark must be able to identify particular tailoring choices as incompatible, so that
tailoring tools can take appropriate actions.
In addition to being able to specify rules, XCCDF must support structures that fosters use
and re-use of rules.
To this end, XCCDF must provide a means for related rules to be
grouped together, and for sets of rules and groups which should be applied in concert to
be designated, named, and applied easily.
Two realizations of this notion are benchmark
levels, as provided in benchmarks distributed by the Center for Internet Security, and
checklist baselines, as described in the NIST security checklist program [11].
For benchmark processing, there are two basic processing modes: rule checking, and
document generation.
It must be possible for a benchmark author to designate the modes
under which a rule may be processed.
2.2. Inheritance and Inclusion Requirements
To support building up benchmarks from parts, XCCDF must support mechanisms for
authors to extend (inherit from) existing rules and rule groups, in addition to expressing
rules and groups in their entirety.
Also, it must be possible for one benchmark to include
all or part of another.
There are a couple of benchmarking use cases where inheritance
and inclusion will be needed.
•
An organization might choose to define a foundational benchmark for a family of
platforms (e.g. Unix
tm
-like operating systems) and then extend them for specific
members of the family (e.g. Solaris
tm
) or for specific roles (e.g. mail server).
•
An analyst might choose to make an extended version of a benchmark, by adding
some new rules and adjusting some others.
•
If the sets of rules that constitute a benchmark come from several sources, it will
be useful to be able to aggregate them using an inclusion mechanism.
•
Within a benchmark, it might be desirable to share some of the descriptive
material among several rules.
With extension, this can be accomplished by
creating a base rule, and then extending it with several different rule checks.
•
For updating a benchmark, it will be convenient to be able to incorporate changes
or additions using extension.
•
To allow broader site-specific or enterprise-specific customization, it should be
possible for a user to override or amend any portion of a benchmark rule.
The XCCDF specification does not include any mechanism for inclusion; instead,
implementations of XCCDF tools should support the XML Inclusion (XInclude) facility
standardized by the W3C [9].
NISTIR 7188: XCCDF Specification
5
5
