Maintaining an adequate security level for operating systems and databases is one of the most challenging tasks for security professionals; additionally, in-depth compliance reviews are difficult due to the manual nature and skills limitations. This article presents a simplified approach to IT security management that allows IT auditors and information security professionals to discharge their responsibilities more efficiently.

Background

Before the appearance of current, enterprise-level information security standards and supporting documents (e.g., ISO/IEC 27001, ISO/IEC 27002, ITIL, PCI DSS), there was an absence of common models for defining security within enterprise environments. Many individuals used standards defined by the US military (Rainbow Series of books¹) as a guide to help them define their internal security models. These models were not a perfect fit for civilian environments and in most cases required more resources than there were available to the normal corporation in the late 1980s and early 1990s. However, many professionals used the concepts and ethos of the Rainbow Series of books to shape their own interpretation of what a control environment should look like.

For the latter part of the 1990s and all of the most recent decade, control environments were defined based on the best practices from commercial vendors or international standards that have started to appear that are aimed at closing existing gaps in the available body of knowledge.

One of the effects of the significant increase in the use of technology to support business processes and also the availability of information security standards is that all actors involved in the process of controlling assets are overwhelmed with data and are unable to have complete visibility over the issues affecting the environment. The effect to some of the actors is presented in figure 1.

There are a number of technology solutions available; in most cases, entities have deployed individual systems and applications and are trying to consolidate the information. Recently, there has been an increase in the number of entities deploying correlation engines, vulnerability scanners and intrusion detection systems to gain some visibility over the configuration and vulnerabilities present within the system. Internal audit departments are starting to use scanning software, as well, to validate the control statements received from management—in some cases, using the same tools as the information security department.

The ISAP Information Security Model

In recent years, the US government created a second wave in terms of addressing information security, the aim being to have an end-to-end platform that will allow automatic configuration, verification and auditing of computer systems. This model is based on commercial-off-the-shelf (COTS) components, as opposed to proprietary or classified technologies.

The Information Security Automation Program (ISAP) is aimed at enabling the automation and standardization of technical security operations. ISAP integrates a number of individual projects, all designed to be compatible and to focus on individual areas required for the overall coverage. Some of the individual projects are stand-alone solutions, e.g., CVE® (Common Vulnerability and Exposures).

ISAP technical specifications are contained in the related Security Content Automation Protocol (SCAP) (see figure 2). SCAP is the model for using specific standards to enable automated vulnerability management, measurement and policy compliance evaluation.

SCAP includes the following components:

• CPE™—The first component of SCAP is the Common Platform Enumeration (CPE) (see figure 3). This is a structured naming scheme for technology components (operating system, equipment, services). CPE provides a flexible model for creating an inventory of the key infrastructure elements across the entity, allowing for further analysis by adding the information provided by the other SCAP elements. Entities face their first obstacle when trying to determine how to address security issues. Unless they have a clear view of what and how many elements are involved, it is impossible to provide appropriate control levels and compliance.
  
  
• CVE—The next component of SCAP is the CVE. CVE is a compilation of publicly known information security vulnerabilities and exposures that have been classified and documented by independent reviewers. CVEs provide a platform of common identifiers (see figure 4). This allows consistent naming of security vulnerabilities. Regardless of the tool or mechanism used to evaluate a system, and as long as CVE is used, the vulnerability will receive the same name and classification. CVE also provides a valuable tool for the interaction among the technology department, information security and internal audit; they can all use CVE to refer to vulnerabilities and keep a consistent naming convention.
• CVSS—After conducting a complete inventory of the technology environment and documenting the existing vulnerabilities, entities can proceed to deploy a consistent classification for vulnerability effects. The Common Vulnerability Scoring System (CVSS) is used to describe the impacts of IT vulnerabilities. The model is based on a quantitative approach that provides a measure regarding different aspects of control, and it can be tailored to articulate the organization’s view on how vulnerabilities impact the business. CVSS can be used to facilitate the prioritization of vulnerability remediation activities and also to calculate the severity of vulnerabilities. This removes part of the subjective nature of vulnerability management. Once information security, internal audit and risk management have agreed on the classification, CVSS will act as a common language to all. Temporal and environmental data can be added to the CVSS information, allowing for calculating the effect of vulnerabilities on critical systems.
• OVAL—The Open Vulnerability and Assessment Language (OVAL) can be used for representing configuration information of systems for testing, analyzing the system for the presence of the specified machine state (e.g., vulnerability, configuration, patch state) and reporting the results of this assessment. OVAL acts as the proxy between the system configuration and the analysis tools used within SCAP and provides significant flexibility for auditors and security professionals to define the rules and parameters that should be assessed. OVAL provides a common mechanism to determine the existence of software vulnerabilities, configuration issues, programs, and/or patches in local systems. If the organization is using different tools to assess the security status of components, this language can be used to help the tools share information and improve consistency.
• XCCDF—XCCDF is an Extensible Markup Language (XML) that can be used to create checklists, benchmarks, audit tests and system evaluations. XCCDF documents include a set of rules that will be verified as part of the evaluation. Also, there are compliance scoring and testing operations supported by the system. Results can be benchmarked against predefined minimum levels (e.g., when a baseline has been defined for the platform). Once SCAP has been deployed, auditors can create their own XCCDF file to check specific parameters within the system. These audit files can be executed continuously and triggers can be set to issue reports when systems are falling below the baseline levels agreed to with management.

Real-life Applications

Due to the fact that SCAP is a US federal model, many vendors have developed plug-ins to their products that make them SCAP-compatible. This is the only common language in the industry, which is important if organizations are planning to purchase new testing or reporting applications.

As of August 2010, there were 39 SCAP-accredited products available.² This shows the level of adoption that the model is having and facilitates the decision-making process as organizations may already have the tools without knowing the additional options that are available, such as:

• Organizations can create their own compliance script, translating security policies into XML files that can be executed by the SCAP-compliant tools with a compliance status returned.
• These scripts can be run by different tools and can test different platforms; output and reporting information can be consolidated into a single report.
• Consolidated results can be used to provide a high-level view of the compliance status to help executive management quickly understand the key risk areas.
• The evolution of compliance can be accurately measured by comparing against previous evaluations across the complete state.
• IT auditors will be able to define their own independent set of tests and run them using the existing tools, thus reducing planning and fieldwork time.

In many organizations, security compliance is measured using a combination of manual tests and scan outputs; the scans are not always configured to reflect the security policies defined within the organization and this causes reports to be confusing and full of false-positives or significant gaps. Large organizations are also affected by the need to collate results from different tools and this increases the complexity of getting the full view of the compliance status.

Commercial tools allow organizations to translate their security policy (more specifically, the operating system configuration parameters) into XML files using XCCDF and OVAL, and then to use the tool to validate and report the level of compliance against the policy. This means that the policy can be checked using different tools and against different operating systems, and, more important, the results from different tools can be collated as they can be translated into common terms by using the CVE, CVSS and CPE.

Conclusion

Leaving aside the technical specifications of SCAP, information security and audit professionals can expect this technology to be a mechanism that will help them deal with the complexities and size related to technology control environments. Information can be prepared for executive management by consolidating the data extracted from SCAP components and showing heat maps that can be explored for noncompliance areas; this will simplify the message and allow for better oversight of the control environment.

IT auditors planning to undertake an infrastructure audit can see their workload reduced significantly as some test samples can be extended to 100 percent of the population and verification can be automated. The flexibility of OVAL allows for the creation of configuration checks for applications; this will likely start with common applications and can evolve into proprietary systems as well.

Similarly, information security professionals looking to prove compliance against international standards can see their work reduced significantly, as shown by implementation examples provided by NIST.³ In the particular case of ISO/IEC 27001, it is possible to see a high number of controls deployed using SCAP-compatible systems and vendor scripts (configuration scripts for operating systems). In particular, the following control objectives from annex A of ISO/IEC 27001 can be tested using SCAP:

• A.8.5 Network management
• A.9 Access controls (most of this section)
• A.10.4 Security of systems files
• A.12.2 Reviews of security policy and technical compliance
• A.12.3 System audit considerations

References

• The Information Security Automation Program and The Security Content Automation Protocol, http://nvd.nist.gov/scap.cfm
• Common Vulnerabilities and Exposures, http://cve.mitre.org/index.html
• Common Platform Enumeration, http://cpe.mitre.org/
• National Institute of Standards and Technology, CVSS, http://nvd.nist.gov/cvss.cfm?version=2
• National Institute of Standards and Technology, XCCDF, The Extensible Configuration Checklist Description Format, http://nvd.nist.gov/xccdf.cfm
• Open Vulnerability and Assessment Language, http://oval.mitre.org/index.html
• Ramirez, David; “Streamline ISO 27001 Implementation,” ISACA Journal, vol. 5, 2006, www.isaca.org/archives
• International Organization for Standardization, ISO/IEC 27001:2005, Information technology—Security techniques— Information security management systems, 2005
• US Federal Computer Security Manager’s Forum Annual Offsite, http://scap.nist.gov/events/

Endnote

¹ Rainbow Series, US Department of Defense Computer Security Center, http://www.fas.org/irp/nsa/rainbow.htm
² National Institute of Standards and Technology, National Vulnerability Database, http://nvd.nist.gov/scapproducts.cfm
³ Brown, Mason; “Automating the Most Critical Security Controls,” http://scap.nist.gov/events/2009/itsac/presentations/day2/Day2_DoD_Brown.pdf

David Ramirez, CISA, CISM, CISSP, BS 7799 LA, MCSE, QSA
is an IT audit director for Barclays Internal Audit. He has more than 15 years’ experience. Ramirez has published a number of articles and white papers, and his book on IPTV security was published by Wiley in January 2008.

Enjoying this article? To read the most current ISACA^® Journal articles, become a member or subscribe to the Journal.

The ISACA Journal is published by ISACA. Membership in the association, a voluntary organization serving IT governance professionals, entitles one to receive an annual subscription to the ISACA Journal.

Opinions expressed in the ISACA Journal represent the views of the authors and advertisers. They may differ from policies and official statements of ISACA and/or the IT Governance Institute^® and their committees, and from opinions endorsed by authors’ employers, or the editors of this Journal. ISACA Journal does not attest to the originality of authors’ content.

© 2010 ISACA. All rights reserved.

Instructors are permitted to photocopy isolated articles for noncommercial classroom use without fee. For other copying, reprint or republication, permission must be obtained in writing from the association. Where necessary, permission is granted by the copyright owners for those registered with the Copyright Clearance Center (CCC), 27 Congress St., Salem, MA 01970, to photocopy articles owned by ISACA, for a flat fee of US $2.50 per article plus 25¢ per page. Send payment to the CCC stating the ISSN (1526-7407), date, volume, and first and last page number of each article. Copying for other than personal use or internal reference, or of articles or columns not owned by the association without express permission of the association or the copyright owner is expressly prohibited.