Dec 31 2009

Connecting the Dots

NIST develops an automated approach to help agencies make the jump from security policies and mandates to secure systems.

Establishing traceability from the Federal Information Security Management Act’s high-level requirements down to specific mechanisms to secure hardware and software poses challenges for the government’s systems security managers.

Effectively using security controls hinges on ensuring that an agency’s technology staff can properly establish and enforce their systems’ security configuration settings. At the National Institute of Standards and Technology, we continue to look for ways to help agencies do that.

To make this important linkage from law and policy to the mandatory security requirements and controls described in Federal Information Processing Standard 200 and NIST Special Publication 800-53 — and ultimately to the mechanisms at the systems-implementation level — NIST estab­lished the Security Content Automation Program. SCAP is part of the NIST FISMA Implementation Project, now in Phase II, and the agency’s Information Security Automation Program.

Through the interagency ISAP effort, the government — in cooperation with academia and industry — encourages widespread support for the SCAP, a suite of open standards that provide technical specifications for expressing and exchanging security-related data. These interoperable standards — developed

primarily by the National Security Agency, Mitre and NIST — identify, enumerate, assign and facilitate the measurement and sharing of information-security-relevant data.

The SCAP suite likely will expand over time to include additional standards, such as Common Remediation Enumeration and Open Vulnerability Remediation Language.

How It Works

The primary output from SCAPare security checklists in a standard eXtensible Markup Language format that agencies (and vendors) can use via automated commercial products to help build, operate, measure and maintain secure systems according to official government security recommendations. Each security checklist contains instructions for configuring information technology products for an operational environment or verifying that an information technology product has already been securely configured.

The checklists can take many forms, including files that can automatically set or verify security configurations. Having such automated methods has become increasingly important for several reasons, including the complexity of achieving compliance with various laws, executive orders, directives, policies, regulations, standards and guidance. Another need for such lists arises from the increasing number of vulnerabilities in systems and the growing sophistication of threats against those vulnerabilities.

Help From Everywhere

Because of these needs, the SCAP team encourages development of automated checklists within government and by industry and academic institutions. In particular, it’s seeking lists compliant or compatible with eXtensible Checklist Configuration Description Format (XCCDF) and Open Vulnerability and Assessment Language (OVAL).

These are widely used for automated checklists — XCCDF primarily for mapping policies and other sets of requirements to high-level technical checks, and OVAL for mapping high-level technical checks to the low-level details of executing those checks on the operating systems or applications being assessed.

The SCAP Web site, at, provides automated security configuration and patching information in a standard format for the following checklists: Microsoft Windows Vista, 2003 Server and XP; Office 2007; Internet Explorer 7.0; Symantec AntiVirus; and Red Hat Linux. While NIST is working with vendors to translate the checklist content for other popular operating systems and applications — including Sun Solaris; Netscape Navigator and other versions of Office; Oracle and Microsoft SQL Server databases; and Web servers such as IIS and Apache — the English prose version of these and other security checklists can be found at

Through automation, agencies can ensure they consistently apply security controls and configuration settings within their systems and know that they have a mechanism for effectively verifying those controls and settings.