wp_changing_face_compliance_valid

Protect what you value. The Changing Face of Compliance Validation By Kent Landfield The Changing Face of Compliance Validation www.mcafee.com Table of Contents Compliance Validation Complications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 Standards Emerge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 CVE: Getting Started . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 OVAL: The Next Step . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 XCCDF: Making Security Policy Guidance Usable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 CCE: Dealing With Exposures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 CPE: What’s in a Name? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 NVD: Providing Access to Vulnerability, Configuration, and Guidance Information . . . . . . . . . . . . . . . . . . . . . . . . . . 7 CVSS: Scoring Vulnerabilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 SCAP: Foundation for Compliance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 The Feds Change the Playing Field . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 Today . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 The Immediate Future . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 About the Author . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 The Changing Face of Compliance Validation www.mcafee.com The Changing Face of Compliance Validation This paper will highlight the transformational changes that are now occurring in compliance validation, auditing technologies, and the standards that provide the underlying foundation for the next major evolution in ensuring an organization’s security. Compliance Validation Complications In the past, auditing for compliance has been an expensive and time-consuming operation . Audits typically have a specific focus, such as bringing up a new service that will have public exposure, or conducting a required Federal Deposit Insurance Corporation (FDIC) audit, a Federal Information Security Management Act (FISMA) annual audit, or a Government Accountability Office (GAO) IT security audit . There are many reasons for auditing an organization’s security infrastructure and practices, none of which have been pleasurable or nonintrusive in the past for the organization’s staff and operations . Simply preparing for an IT systems security audit by an external auditor is a major undertaking . Your staff has to research the current set of regulations and best practices that the auditing authority will evaluate . Depending on the type of audit, staffs often need to start preparing for the audit months in advance to be ready to pass . This can involve a great deal of time trying to understand and interpret the changes made to the regulations and requirements since the last audit . Once your staff feels comfortable with what needs to be done to comply with the conditions of the audit, they need to start their own internal audit to see where they stand and to try to make the required changes before the auditor arrives . Meanwhile, your organization is losing valuable productivity from those who are involved in audit preparations . Although all of the remediation work done by your staff helps improve your security and better prepares you for succeeding at the external audit, the very nature of the process of preparing for large-scale audits creates a reactive approach to securing your networks . Instead of integrating systematic security practices into the daily operations of the organization, your staff gears up for the audit and then does not continue the daily process of evaluation and improvement . They know that there will be another audit soon, but they will start working on it only a couple of months in advance . In the meantime, they have “real work” to do and the overall security of your systems begins to regress . Few organizations have real security built into their daily operations . Although they may claim to have it when asked by management, security is seemingly the last thing addressed by the network operations staff . There are never enough resources to manage the networks, and there are always more than enough new user and business requirements that take priority and consume the staff’s time . Then there are the auditors . External auditors vary greatly in their capabilities and qualifications . Some have a great deal of experience and have IT audit certifications such as the internationally recognized Certified Information Systems Auditor, from the Information Systems Audit and Control Association . But more often, the auditors have no certifications and much of their real audit background comes from internal training by their employers or by on-the-job training . As a result, external audits range in size, scope, and professionalism . On the low end, they can consist of an individual who comes in and runs a commercial or freeware network scanner on the network, and then leaves with the results and writes up a report that is little more than reformatted scanner results . Other audits can involve individuals focused on the process and practices who ask the interviewees only about the network environment . These types of paperwork audits rarely give an accurate view of the organization . Then there are external auditors who bring in a team of individuals to interview the staff about security management practices and examine the networked systems to determine the security status at the time of the evaluation . 3 The Changing Face of Compliance Validation www.mcafee.com All this brings us to the conclusion that trying to determine compliance can not only be confusing but it can also be a time-consuming and expensive task . In the end, your audit results are only as good as your auditing process and the knowledge and professionalism of your auditors . The most frustrating part of measuring compliance has been that management gets to see the status of the company’s security posture only at a single point . Gauging progress weekly would be more useful in determining the course of improvements . Initially, CVE was to include vulnerabilities due to software defects and common misconfiguration issues . However, the CVE Editorial Board decided to focus on identifying software defects because that area was easier to address and could provide immediate value . The Board’s intention was to pick up the common misconfiguration issues at some point in the future . CVE is the grandfather of today’s vulnerability and compliance standards and has become the standard by which security tools report and exchange information about software vulnerabilities . CVE can now be found in security tools such as IDS, network intrusion detection systems (NIPS), host intrusion prevention systems (HIPS), firewalls, vulnerability scanners, and patch and remediation management, as well as systems management products . CVE IDs are reported in vendor security bulletins issued by Microsoft as well as by Linux and Unix vendors . They can also be found in United States Computer Emergency Readiness Team (US-CERT) bulletins and those of other alerting organizations; in vulnerability databases, security checklists, and product-hardening guidance documents; and in government system-security configuration guidance such as the Defense Information Systems Agency (DISA) Security Technical Implementation Guides (STIGs) . Standards Emerge The Security Content Automation Protocol (SCAP, pronounced ESS-cap) emerged after the second National Institute of Standards and Technology (NIST)sponsored Security Automation Conference in 2006 . SCAP provides vendors and the community a means to enable standardization and automation throughout security operations . SCAP is not a single protocol but a set of component standards . In order to understand the transformation to validating and auditing compliance that SCAP provides, it is important to understand a little about the standards that have become the foundation enabling the transformation to occur . CVE: Getting Started In 1999, the Mitre Corporation—a nonprofit that provides technical and engineering services to the federal government—initiated the Common Vulnerabilities and Exposures (CVE) effort as a reaction to the inconsistent reporting of security events by intrusion detection system (IDS) products .1 IDS products report when something malicious is detected on a network, yet before CVE, each product vendor reported every event in a different way and by a different name . As you can imagine, that inconsistency caused a great deal of trouble for large U .S . government agencies that used products from multiple vendors . When one vendor reported an issue, most likely another vendor reported the same issue, although it did not look the same on the separate product consoles . Network and system administrators had to research and run down each event separately, even if it was the same event . The intent of the CVE effort was to create a dictionary of common names for publicly known security vulnerabilities . This effort allowed security tools such as IDS products to report using a common identifier (ID) . IDS products using CVE IDs allowed administrators to quickly determine if a detected event was the same event across multiple vendors’ products . The effort provided users of IDS products immediate savings in staffing and frustration levels . 1 “Common Vulnerabilities and Exposures,” The Mitre Corp. http://cve.mitre.org/ OVAL: The Next Step As vulnerability scanning became an increasingly critical process for examining system security, there arose the need for a common structured language for exchanging system state information . Every scanning vendor’s tool had a different set of checks . Some products had very complete checks that accurately detected issues . Other products had serious problems with accuracy and produced incorrect results or false positives . Additionally, there was no reliable way to exchange the results found by one product with those detected by other security products or by network management facilities such as global roll-up reporting servers or remediation servers . Thus the Open Vulnerability and Assessment Language (OVAL)2 effort—also managed by Mitre with extensive security industry involvement—set out to build a foundation for interoperability of system state information . OVAL provides an XML language to define three key areas: • A System Characteristics Schema, for representing specific system information • An OVAL Definition Schema, used in writing checks for determining a specific condition or machine state 2 OVAL Project and Repository, The Mitre Corp. http://cve.mitre.org/ 4 The Changing Face of Compliance Validation www.mcafee.com • A Results Schema, for reporting and exchanging results with other security products OVAL-enabled products can use the Results Schema in a structured way to pass information to other security components on the network . For example, an OVALcompatible scanner can run a scan and show administrators the results of that scan . That data can also be transferred to a remediation product, which imports the results and allows the staff to correct whatever issues are found in the assessment . That same information can also be transferred to a reporting server that integrates the information with the results of other OVAL-compatible products to allow the organization to get a better view of the overall state of the network . The OVAL definitions are the individual checks used to determine if a condition exists on the system being evaluated . The definitions themselves are common structured content that can be used in any OVALcompatible product that consumes definitions . As a part of bootstrapping the OVAL content development, Mitre created the “OVAL Repository .” This has been the main repository for community-generated content . Initially, developers writing OVAL checks contributed their content to the OVAL Repository . As the OVAL language has grown, however, more and more organizations are putting up their own repositories to make their checks available, too . The structured OVAL content provides the community with a common set of content to check systems for certain conditions . This content can be used in multiple vendor and OVAL-compatible products—all producing the same results when the same definitions are used . There are many benefits to having the ability to write and consume common content . One example is operating system vendors reporting software flaws in their products . In the past, if a system vendor released a security bulletin, sites with that vendor’s software had work to do to determine which systems were affected and to schedule the patching of the affected systems . Sites quite often had to wait for their in-house commercial scanners to be updated with the new checks before administrators could assess their level of exposure . It took time for the scanner product to be updated and for the new checks to be distributed to the sites before the scans could be performed . If a site had multiple scanners, then the effort to mitigate the vulnerability was uneven at best, because certain scanner vendors were quicker than others in getting out new checks . On top of that, the checks themselves might be incorrectly written; this would adversely affect the results of the scans . During this time, the site’s exposure to someone’s maliciously exploiting the security flaw continued . Now if the system vendor makes OVAL checks available at the time it issues the patch and security bulletin, sites can immediately begin checking for their level of exposure and begin their patch-related change-management process . This greatly reduces the exposure time for the site . In addition, the operating system vendor is now the definitive source on the proper way to check for a specific problem . There are no misinterpretations or false assumptions that often occur when third parties create checks for another vendor’s product . Today, there is integration with CVE within OVAL definitions, which can be used to create a check for a CVE . With more than 28,000 CVEs as we write this, it will be a while before there is a one-to-one relationship, but that effort is possible as more and more CVEs get OVAL definitions written for them . With the development of OVAL, the precedent of building on existing standards began . XCCDF: Making Security Policy Guidance Usable In the past when the authors of secure configuration guidance wished to document a policy, they wrote the guidance in a prose (text) document . For example, when the Department of Defense (DoD) wanted to publish their STIGs, they did so using Microsoft Word . This allowed them to easily document guidelines for compliance, but it forced those complying to read and try to understand the specific compliance rules and guidelines . Security tool vendors had to take the prose document and then interpret what the guidance authors meant . Quite often there were items listed that were ambiguous or just plain confusing, leaving tool vendors to make their best guesses as to what was intended . This meant “compliance validation” from one vendor’s perspective might not match another vendor’s results . Additionally, when a security-hardening or policyguidance document was published, the targeted community could not use it right away in commercial products . Tool vendors first needed to integrate the documented configuration settings and technical controls into their products . This was often a lengthy process that forced the user to wait potentially months before the guidance was integrated into the product . 5 The Changing Face of Compliance Validation www.mcafee.com To help security-guidance authors accurately specify not only the prose but also the specific technical controls for validating compliance, the National Security Agency (NSA)—with support from the NIST and the security community—created the Extensible Configuration Checklist Description Format (XCCDF) . With this effort, guidance authors could create a single XCCDF document that contained both the documentation about the policy and the means to check its compliance . The XCCDF Specification 1 .1 .4 states, “This document specifies the data model and Extensible Markup Language (XML) representation for the Extensible Configuration Checklist Description Format (XCCDF) Version 1 .1 .4 . 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 security guidance or checklist compliance testing . The intent of XCCDF is to provide a uniform foundation for expression of security checklists and other configuration guidance, and thereby foster more widespread application of good security practices .”3 XCCDF provides guidance authors with the ability to specify the automated compliance-testing checking engine . Although XCCDF supports differing checking engines, OVAL has been the expected or normal checking engine from the early days of XCCDF . Policy guidance authors can now create a single XCCDF document that contains policy documentation which can be printed along with the technical controls needed to validate compliance . This is now possible from an allinclusive document that can be electronically signed to provide authenticity of the policy . This not only takes the vendor interpretation out of the process but allows products that are XCCDF-compliant to read and use the document immediately upon issuance of the XCCDF policy checklist . create CCEs?” turned out to be extremely contentious, and caused the effort to stall at times . But at the 2007 NIST Security Automation Conference, the players finally reached an agreement, and CCEs are currently being produced for Windows, Linux, and Unix environments . The CCE project4 provides unique identifiers for system configuration issues, much like those that CVE provides for software vulnerabilities . CCE provides the ability to automate configuration validation and allows for compatible products to exchange information using the CCE IDs . The first CCEs looked extremely similar to CVEs . After developing different versions, the working group eventually decided to base CCEs on a version of the operating system, such as Windows XP, Solaris 10, or Red Hat RHEL 5 . Once the working group finally decided on the level for which CCE would be defined, the group changed the format to include Luhn check digits in the (now Version 5 .0) CCE IDs . (The check digit helps CCE validation by providing the ability to detect any single-digit error, as well as almost all transpositions of adjacent digits . This was a common problem for CVE identifiers that CCE wanted to avoid . A brief description of this algorithm can be found on Wikipedia, at http://en.wikipedia.org/wiki/Luhn_algorithm .) The CCE effort is managed by Mitre with active community involvement . CCEs will quickly become critical for accurately specifying best practices for system configuration policy guidance and security configurations . CPE: What’s in a Name? During the first OVAL Compatibility Certification Testing, a network scanner product and a remediation management product tried to exchange OVAL results . It was immediately apparent that the exchange wasn’t working, even though both products had gone to great lengths to assure that they were OVAL-compatible . After reviewing the results, it became clear why the two were failing to communicate . The scanner was specifying the type of system on which the OVAL scan was run as “MS Win2K,” while the remediation product did not have that term as a specified environment name for the Windows 2000 system . When the issue was identified, the testers entered “MS Win2K” into the remediation management’s environment table and attempted the exchange again . This time it worked just as intended . At that point, it was obvious there needed to be a formal way to name and identify systems, platforms, and software packages . If there was going to be a real exchange of 4 CCE Project, The Mitre Corp. http://cve.mitre.org/ CCE: Dealing With Exposures Six years after the CVE Board decided to defer dealing with configuration issues, another effort, the Common Configuration Enumeration (CCE), was begun to pick up what was initially the “exposures” piece of CVE . Getting the CCE effort off the ground proved the CVE Editorial Board made a smart decision, as trying to deal with common configuration issues proved to be a hard subject to address . The simple question “At what level do you 3 “XCCDF Specification 1.1.4,” NIST. http://nvd.nist.gov/xccdf.cfm 6 The Changing Face of Compliance Validation www.mcafee.com security state and status, and if devices were going to have the ability to specify what compliance tests apply to what environments, a standard naming specification was needed . To address these needs, Mitre initiated the Common Platform Enumeration (CPE) project,5 which today has two parts: the CPE naming specification and a standard dictionary of official CPE names . Although the requirement was stumbled upon, CPE has become the centerpiece for the way we typically stitch together all of the standards-related information, ensuring we are targeting the appropriate systems and platforms . SCAP: Foundation for Compliance SCAP contains six component standards: CVE, OVAL, CCE, CPE, XCCDF, and CVSS . The SCAP content repository consists of policy guidance written as security checklists in XCCDF using OVAL to check the state of specific technical controls . Although the NIST manages and defines the component standards contained within SCAP, it does not control the individual standards . Today, Mitre manages the CVE, CCE, CPE, and OVAL standards; the NSA manages XCCDF; and CVSS is managed by the Forum of Incident Response and Security Teams (FIRST) . While these organizations manage these individual efforts, they do so with extensive active involvement from the security community including vendors, academia, and others . NVD: Providing Access to Vulnerability, Configuration, and Guidance Information The National Vulnerability Database (NVD) is a U .S . government repository managed by the NIST . The focus of this effort is to provide up-to-date vulnerability-related information using the SCAP component standards . It is proving to be extremely useful in providing the security community, users, and vendors with access to information that once was available only to the largest organizations . And the site provides more than just vulnerability-related information . It is also the home of the SCAP effort, providing security-related checklists that include FISMA and Federal Desktop Core Configuration (FDCC) guidance, to name just two examples . Its SCAP content repository is the cornerstone for the compliance guidance that is available at the national level in the United States . The Feds Change the Playing Field Until March 20, 2007, SCAP and its component standards were quietly making advancements . On that day, Karen Evans of the White House’s Office of Management and Budget (OMB) issued a memorandum to the U .S . Government Agencies Chief Information Officers that federal agencies were going to be required to: • Get Windows XP and Windows Vista systems to meet a secure configuration before February 1, 2008 • Assure that all systems are maintained in that configuration going forward • Put in place the automation and processes needed to maintain secure configurations • Be able to report to the NIST when deviating from the approved configurations and provide reasons for doing so The U .S . DoD had been securing their systems configurations for years using the DoD STIGs . Now federal agencies would be doing the same thing . The OMB memo contained the following remark: “[The] NIST has established a program to develop and maintain common security configurations for many operating systems and applications, and the Security Content Automation Program can help your agency use common security configurations .” SCAP and its component standards were now going mainstream . Two days later, the OMB released another memo, this time describing a joint effort between the DoD, the NIST, and the Department of Homeland Security . It stated that they had reached a consensus on secure configurations for CVSS: Scoring Vulnerabilities Quite often enterprises need to be able to prioritize and direct activities and resources to those items in their network that need to be corrected first . But determining what the most important items are is not always easy . The Common Vulnerability Scoring System (CVSS) provides an open framework that allows organizations to normalize vulnerability scoring across their hardware and software platforms . CVSS provides the foundation that allows organizations to prioritize which issues need to be addressed based on the risk to the business . Common uses of CVSS are calculating the severity of vulnerability-related issues discovered in networked systems, and prioritizing vulnerability remediation actions . The NVD provides CVSS “base scores” for all CVE vulnerabilities . 5 CPE Project, The Mitre Corp. http://cve.mitre.org/ 7 The Changing Face of Compliance Validation www.mcafee.com Windows Vista and Windows XP . These were the specific configurations—now known as the FDCC—that agencies were required to adopt before February 1, 2008 . At the 2007 NIST SCAP Conference and Workshops, it became clear that these memos had had a profound impact . From 250 registered attendees in the previous year, there were 850 registered in 2007 . In addition, the organizational level of the attendees was a step up from the year before . Clearly, agency IT management was taking the mandate seriously . But what was it that the OMB saw that others had not? SCAP provides: • A standardized means for computers to communicate vulnerability, configuration, and state information to enable interoperability among products and services, and to interoperate with compatible products from multiple vendors • Standardized information communicated with common enumerations, vulnerability, and compliance references enabling repeatability across compatible products and services while reducing the content-based differences • A standardized means to implement technical checks that can be written once and shared among policies and communities • Standardized, measurable policy guidance via FDCC requirements—reducing more than 125 standard configurations to just one that needs to be reported • Applicability for many risk management frameworks such as Assess, Monitor, Implement to radically reduce the effort and expense of the risk management process while providing better access to compliance status • The ability to deploy an infrastructure that supports accurate and rapid reporting of the operational status of the networked environment, thus supporting FISMA compliance demonstration and reporting Today, the SCAP initiative has proven that multiple vendors can use the same content and produce the same results from a scan of identical systems . Not only government personnel attended the NIST 2007 conference . Many product vendors were there, too, presenting their plans for incorporating SCAP into their products . Enhancing IT Security Through SCAP Vulnerability Management CVE CVSS OVAL Asset Management OVAL CCE Configuration Management CPE SCAP XCCDF OVAL Compliance Management Figure 1: SCAP ties together critical elements of systems management. 8 The Changing Face of Compliance Validation www.mcafee.com SCAP affects not just compliance management . SCAP also provides integration in other areas: • Vulnerability management • Configuration management • Asset management • Compliance management Figure 1 depicts the use of SCAP component standards in the different areas of information technology . Employing SCAP technologies will allow organizations to take the interpretation out of the compliance equation . By using the official guidance document directly, no interpretation is necessary . The technical checks contained in the guidance dictate what needs to be verified and how it is intended to be checked . Organizations will be able to tailor current policy guidance to meet their specific needs, or they can create their own internal security policy guidance using the archives of existing technical checks . Automation is the keystone of SCAP’s success . In the past, there was no framework that provided for the automation and integration of security content, policy guidance, and results reporting among multiple vendor products . Today, SCAP is providing this . No longer will an organization’s management have to wait for a periodic and expensive audit of their network to determine the company’s security posture . With the transparency that SCAP provides, executives will be able to watch the improvements occur on a weekly or even daily basis . No longer will site staff need to be reassigned simply to prepare for an enterprise audit, distracting them from other important projects . An SCAP-enabled environment will allow security improvements to become an integral part of the IT operation, allowing for continuous incremental improvements . No longer will an organization be surprised by the results of an audit—because those results and the associated view of the organization’s security posture will now be available on demand . Future audits will consist of external auditors arriving at the site and being handed the site’s policy guidance in the form of an XCCDF document . It will include the associated technical checks used to verify compliance, the results of recent SCAP policy audits, and the customization the site uses to make the policy guidance fit local network needs . With the signature capabilities built into SCAP, the auditor will be able to verify that the XCCDF policy document and the technical checks are the appropriate ones to be evaluated and that the results signatures can be validated . They can then verify that these policies are in fact in use on the organization’s policy auditing software . The major focus on the audit thus becomes ensuring that the site’s policy validation is complete and accurate . If the auditors find holes, they can recommend changes to the validation content to properly cover the missing pieces . Sites can then modify their security policy XCCDF file and technical checks, and immediately have a view of the issues the auditor flagged . Today SCAP-enabled products are just now starting to reach the market . The early products are focused on evaluating a single host and are not ready for real enterprise-wide auditing and reporting . The next wave of SCAP-related products will be able to support the enterprise and provide capabilities large companies need to really take advantage of the promise of SCAP and its component standards . The content generation needed to implement many of the policies enterprises have come to expect is just now starting to be developed . The future intent is for the actual guidance authors to take ownership and produce the technical checks at the same time as the textual policy is developed or updated . Today, the initial wave of SCAP content is coming from the security community, but this is starting to change as the SCAP component standards become known by those developing the policy guidance . The federal government is rapidly adopting this approach . Although the security community is bootstrapping the policy content today, the fact that it is XML-based and readable by others aids the community debate on the correctness of the implementation . The Immediate Future SCAP provides a foundation that lets developers build tools that will directly run content written, signed, and issued by the policy guidance authority . For example, sites will be able to download an FDCC benchmark from the NIST SCAP repository and import that into the SCAP-enabled policy-auditing software . The software will then schedule and execute the policy on appropriate systems throughout the enterprise . The results of the automated compliance testing will be aggregated and reported to the next level in the reporting chain . And all this will happen while the site staff sleeps . 9 The Changing Face of Compliance Validation www.mcafee.com With SCAP, the costs to perform a compliance audit will fall dramatically, and sites will no longer be operationally affected by diverting resources to properly report compliance . Automation using SCAP is even now showing how we are on the edge of a real transformation in compliance validation and interoperability among security products that, up to this point, had simply been a pipe dream . About the Author Kent Landfield is Director of Security Research for McAfee® Avert® Labs . He has been involved with the development of security standards since the POSIX working groups in the late 1980s . Landfield has also been involved with standards development for the Internet Engineering Task Force and Trusted System Interoperability Group . He was one of the initial CVE Editorial Board members and is also an OVAL Board member . Landfield is active on the CPE and CCE working groups . McAfee, Avert, and/or other noted McAfee related products contained herein are registered trademarks or trademarks of McAfee, Inc ., and/or its affiliates McAfee, Inc . 3965 Freedom Circle, Santa Clara, CA 95054 888 .847 .8766 www.mcafee.com in the US and/or other countries . McAfee Red in connection with security is distinctive of McAfee brand products . Any other non-McAfee related products, registered and/or unregistered trademarks contained herein is only by reference and are the sole property of their respective owners . © 2008 McAfee, Inc . All rights reserved . 6-cor-cmpl-vld-001-0408 10