S-CAP The Standards Platform

FDCC – The Next Series of Milestones – March 31, 2008 Compliance Reports Due to OMB & NIST

Secure Elements Blog — Mon, 04 Feb 2008 16:31:16 +0000

The next phase of the OMB mandate requires government agencies to submit their FDCC system audit result sets – as exported from their NIST SCAP Validated Tools in SCAP compliant formats – to NIST for statistical analysis and review. The reporting information should be sent to OMB at fisma@omb.eop.gov with a carbon copy to NIST at fdcc@nist.gov by March 31, 2008. An agency or department CIO must report compliance for that organization. Compliance is expressed as a roll-up, of the compliant versus non-compliant computers. For non-compliant computers, CIOs must provide a representative sample of SCAP-based (XCCDF version 1.1.4) assessment reports. The FDCC XML reporting format is located at http://nvd.nist.gov/scap/content/fdcc-reporting_20080108.zip. Submitted by: S. Armstrong

SCAP & FDCC Validation Process – NIST Accredited Lab

Secure Elements Blog — Fri, 01 Feb 2008 22:35:50 +0000

On the eve of the Feb 1, 2008 OMB mandate, Secure Elements C5 Platform went through a detailed technical analysis to attest to its ability to process the SCAP data streams and evaluate the Federal Desktop Core Configuration functionality and report production. The certification is timely in order to support the OMB March 31, 2008 deadline for reporting FDCC compliance. The public-private partnerships developed between government and industry, bringing the SCAP Validated Tools and the FDCC initiatives together, is evidence that progress is being made towards accountability in securing our infrastructure. Industry and government must continue forward with initiatives addressing secure baselines for server technology, network infrastructure equipment and applications. I believe that SCAP based solutions are poised to evolve beyond security configuration compliance - and will include other areas of systems and operational management – such as compliance with energy efficient settings, and other regulatory initiatives such as HIPAA, SOX, PCI, and others.

Submitted by: A Bove

Ask the Expert

Secure Elements Blog — Fri, 01 Feb 2008 13:57:12 +0000

Question: Why did the government mandate the use of the FDCC baseline images and by making the image public knowledge to anyone doesn’t it make them a target for potential attackers?

Answer from Andrew Bove, CTO: The Federal Desktop Core Configuration mandate from the OMB is designed to ensure a minimum secure baseline for stronger IT security and hardened Windows endpoint configurations. The baseline FDCC represents the collective best approach from authoritative sources such as the NSA, DISA, DHS, NIST and Microsoft. Our guidance is to use this as your minimum hardening guideline and build upon it from here. Awareness when it comes to security works both ways.

If you would like to ask a question please email blog@secure-elements.com

Ask the Expert

Secure Elements Blog — Tue, 29 Jan 2008 19:24:07 +0000

Question: What is XCCDF and how does it apply to me?

Answer from Andrew Bove, CTO: That depends on your role. Are you responsible for:

Hardening systems to some standard

Developing a hardening standard

Relating technical and/or soft controls to guidance such as FISMA or DOD 8500

Doing C and A work in order to get an ATO

Reporting on the status of systems relative to vulnerabilities (whether they be introduced through flaws in software or misconfigurations)

Reporting on the status of systems relative to guidance such as NIST SP 800-53 or DOD 8500

All of the above activities share a common aspect, the need to describe and communicate information. The problem is that, even when using a technology like XML there are multiple ways of describing and communicating information. This is commonly referred to as different dialects.

The fact that there are multiple ways to describe the same information is nothing new. Ask any two people to define a structure for a mailing address and you will get at least two different definitions. XCCDF standardizes the description and communication of information related to the abstract concept of a ‘configuration checklists”. XCCDF is defined by a schema (http://nvd.nist.gov/scap/xccdf/docs/xccdf-1.1.4.xsd.txt) and a specification (http://nvd.nist.gov/scap/xccdf/docs/xccdf-spec-1.1.4-20071102.doc).

At its most basic level XCCDF allows us to describe a rule whose implementation is described elsewhere, a weight for that rule, a value that the rule is to be evaluated against, and context relationships for a rule. It also allows us to make collections of rules and associate those with something called a PROFILE. To date profiles have been used to describe concepts such as system classifications thru hardware platforms. Through these PROFILE associations XCCDF allows us to bind a value to a rule, that is, the same rule can be evaluated for different values through in different PROFILES. For example, an XCCDF benchmark may have 3 profiles, LOW, MEDIUM, and HIGH – each of which ask for the evaluation of the imaginary Maximum-weight-allowed rule – for the profile LOW it is evaluated against the value 100, for the profile MEDIUM the value 250, and for the profile HIGH the value 500. It is important at this point to make clear what the evaluation of a rule means, from a XCCDF perspective a rule can be evaluated as PASS, FAIL, ERROR, UNKNOWN, NOT_APPLICABLE, NOT_CHECKED, NOT_SELECTED, INFORMATIONAL, and FIXED.

Relative to your question “1) Is XCCDF going to be a compliance that a tool can receive or a tool in itself?” — XCCDF is not a tool in the classical sense of the word. Consider the analogy of a program written in a programming language – you have a formal definition of it and a specification for it, but without a compiler, linker, and runtime environment its usefulness as a tool is at best limited. For tools that leverage XCCDF they (and their users) have the benefits of sharing a common, standard way to describe and communicate information and therefore become interoperable – not only from the sharing data perspective but from the sharing of meaning perspective.

Relative to your question “2) Will XCCDF test for compliance, configure, and report the output or do just testing and reporting?” XCCDF in and of itself cannot test for compliance, recall my comment “XCCDF allows us to describe a rule whose implementation is described elsewhere” – the XCCDF documents published by NIST refer to OVAL files that describe how the rules that are referenced in the XCCDF documents are to be implemented. Therefore, a tool that processes an XCCDF document and the documents it refers to can test for compliance and report on the results at the rule level or at context relationships I mentioned earlier. The rich reporting possibilities with XCCDF abound due to the ability to describe and communicate meta data relationships. For example, the XCCDF documents being published by NIST for the Windows XP Federal Desktop Core Configuration contain 246 distinct rules that are evaluated 616 times across 15 controls in 6 control groups distributed as follows;

Access Control (AC) – 156 Evaluations

AC-3, AC-7, AC-8, AC-11, AC-17

Audit and Accountability (AU) – 18 Evaluations

AU-2, AU-4

Configuration Management (CM) – 344 Evaluations

CM-6, CM-7

Identification and Authentication (IA) – 11 Evaluations

IA-2, IA-5

System and Communication Protection (SC) – 83 Evaluations

SC-3, SC-5

System and Information Integrity (SI) – 4 Evaluations

SI-2, SI-3

Although my description may be a bit casual and somewhat ambiguous, the method in which it is described and communicated in XCCDF is not. These meta data relationships allow us to calculate scores for controls and control groups and then aggregate them across like systems (by leveraging another standard, CPE).

If you would like to ask a question please email blog@secure-elements.com

Federal Desktop Core Configuration (FDCC) – Feb 1, 2008 & March 31, 2008 Deadlines

Secure Elements Blog — Mon, 28 Jan 2008 22:02:09 +0000

In March, June & July 2007, Federal Chief Information Officers (CIOs) and Chief Acquisition Officers (CAOs) received policy memos from the Office of Management & Budget (OMB). The message: implement standard security configurations by February 1, 2008 for Windows XP and VISTA images known as the Federal Desktop Core Configuration (FDCC) standards. In addition agencies first reports are to be submitted to NIST by March 31, 2008 on how they have made progress towards meeting the standards. FDCC is designed to provide a single, standard, enterprise-wide managed environment for desktops and laptops running a Microsoft Windows operating system. By using a common configuration developed for the enterprise rather than hundreds of costly locally created configurations, the federal government will improve security, reduce costs, and decrease application-compatibility issues. Implementing the FDCC helps agencies achieve the following:

Enhance security. The FDCC applies and maintains standard security settings on all desktops and laptops in the enterprise. This helps to accomplish what cybersecurity experts praise as one of the most important steps the government can take to enhance network security.
Maintain administrator control. By limiting typical users’ ability to change the configuration, system administrators can regain control of desktop systems. Users can then perform their daily jobs without exposing the network to attacks.
Reduce costs. Experience has shown that agencies can realize significant cost savings by reducing the number of managed configurations from many to one. Also, using a mature, stable, managed configuration sharply decreases help desk calls.
Ease technology adoption. The FDCC positions agencies to rapidly adopt new technologies and software updates. They also position agencies to apply security and feature patches as they become available.
Improve software development. The FDCC makes it easier for developers to create software by providing them with a set of known criteria that their products must meet. The FDCC also provides a proven testing methodology to certify that those products are compatible with FDCC requirements.

Submitted by: Scott Armstrong

Information Security Automation Program (ISAP) & The Security Content Automation Protocol (SCAP)–Evolution or Revolution?

Secure Elements Blog — Wed, 23 Jan 2008 04:36:47 +0000

We all know intuitively that the IT security marketplace will continue to evolve as technology advances and of course the threat landscape widens. That said we also know the security vendor marketplace is not on the same page when it comes to standard methodologies for describing, evaluating and scoring risk or for that matter interoperability between systems. Further adding to the management challenge we can add in the reality regarding the convergence of systems and network management with IT security and the increasing complexity of data analytics and information sharing objectives our customers have in the form of internal policies or external compliance mandates. While we’re adding to the pile one could also throw in physical security integration challenges with IT security for arguments sake.So the question remains is evolution good enough or does the industry need a revolution? Enter ISAP & SCAP into the equation. The National Institute of Standards & Technology (NIST) is leading a revolution. That’s right, our government tax dollars are hard at work and there are those who believe it will change the way our industry works. So what is ISAP? ISAP, pronounced “I Sap”, is a U.S. government multi-agency initiative to enable automation and standardization of technical security operations. While a U.S. government initiative, its standards based design can benefit all information technology security operations. The ISAP high level goals include standards based automation of security checking and remediation as well as automation of technical compliance activities (e.g. FISMA). ISAP’s objectives include enabling standards based communication of vulnerability data, customizing and managing configuration baselines for various IT products, assessing information systems and reporting compliance status, using standard metrics to weight and aggregate potential vulnerability impact, and remediating identified vulnerabilities.ISAP’s technical specifications are contained in the related Security Content Automation Protocol (SCAP, pronounced “S Cap”), see below and at http://nvd.nist.gov/scap.cfm. Also on this web page are vendor compatibility requirements. ISAP’s security automation content is either contained within, or referenced by, the National Vulnerability Database (http://nvd.nist.gov). ISAP is formalized through a trilateral memorandum of agreement (MOA) between Defense Information Systems Agency (DISA), the National Security Agency (NSA), and the National Institute of Standards and Technology (NIST). The Office of Secretary of Defense (OSD) also participates and the Department of Homeland Security (DHS) funds the operation infrastructure on which ISAP relies (i.e., the National Vulnerability Database).Submitted by Ned Miller

SCAP in Action

Secure Elements Blog — Tue, 15 Jan 2008 01:34:57 +0000

Making security measurable; sounds simple enough. Then again those skilled in the art will take that simple statement and give you 1000 reasons why it’s not so simple to implement. The conversation usually starts with talk about a defense-in-depth or network-centric methodology and once you have all the investment you can stand in your “anti-xxx” deployed on your hosts then add in all the perimeter security all you need is a good decision support capability for data analytics and management by deploying SIM/SEIM and your all set, that is assuming you have lots of money, time and access to those skilled in the art resources available. Part of the challenge is choice. That’s right there are more than 700+ IT security technology companies out there all suggesting they can solve a piece to the security puzzle. Integration nightmares, interoperability headaches and by the way each vendor has a proprietary methodology for the measurement, scoring and reporting of IT security risk. Enter the Information Security Automation Program (I-SAP) and Security Content Automation Protocol (SCAP) standards. MITRE, in collaboration with government, industry, and academic stakeholders, is improving the measurability of security through enumerating baseline security data, providing standardized languages as means for accurately communicating the information, and encouraging the sharing of the information with users by developing repositories. The premise is that the only way we’ll ever get a handle on the operational challenges of security management is to automate as many of the processes as possible. SCAP pulls information from a number of standardized information sources, including: the eXtensible Configuration Checklist Description Format (XCCDF), the Open Vulnerability Assessment Language (OVAL), Common Vulnerability Scoring System, (CVSS) and Common Vulnerabilities and Exposures (CVE) database. SCAP in Action. While attending the NIST SCAP Conference in September 2007 BAH and the DoD demonstrated a SOA-based implementation of SCAP, including a mash-up of Google Earth mapping infosec assets and vulnerabilities in real time. The application was developed in man-weeks (based on SOA) as opposed to the man-years invested in commercial Security Incident and Event Manager, or SIEM. What’s exciting about SCAP is that it represents the first move