In addition to the CFO Act, the article also explores a number of amendments and related Acts which build upon the goals of improved efficiency, productivity and efficacy in federal agencies.

To meet the demand for improved accountability and transparency from the financial management practices of federal agencies, the CFO Act [...]]]> Throughout the 1990s, pressure was on the US government to reduce inefficiencies in federal programs. In an effort to increase public confidence, Congress enacted the Chief Financial Officers Act (CFO Act) in 1990, in order to regulate accounting, auditing and financial reporting practices of the federal government.

In addition to the CFO Act, the article also explores a number of amendments and related Acts which build upon the goals of improved efficiency, productivity and efficacy in federal agencies.

Requirements under the CFO Act

To meet the demand for improved accountability and transparency from the financial management practices of federal agencies, the CFO Act required the following:

• Federal agencies were to put together financial statements for auditing. Audits would be carried out by the Comptroller General or Inspector General.
• A new position – the Deputy Director for Management – was to be created in the Office of Management and Budget (OMB). The Deputy Director for Management represents the chief government official responsible for financial management. The Deputy Director oversees management of information policy, procurement policy, property management as well as productivity improvement. According to the act, the Deputy Director has the following functions:

o   Establish financial management policies and systems implemented throughout the government.

o   Monitor resources required for effective operation of agencies.

o   Review agency budget requests.

o   Review and recommend budget changes to the Director of the OMB.

o   Recommend financial management changes to agency heads.

o   Oversee financial execution of budget.

• A new Office of Federal Financial Management to oversee financial management within federal government agencies.
• The creation of CFO positions in twenty-three major federal agencies. These CFOs would make up the newly-established CFO Council. Each CFO’s roles and responsibilities would include the following:

o   Develop and manage accounting systems. Such systems would need to comply with current accounting standards and principles; internal control standards; and any other requirements of the OMB and/or Department of the Treasury.

o   Direct financial management personal, activities and operations within the agency.

o   Approve and manage financial management systems and projects.

o   Develop operational budgets.

o   Oversee staff recruitment, selection and training for financial management positions.

o   Implement asset management systems within the agency.

o   Monitor financial execution of budget.

• The OMB would be required to prepare a five-year financial management plan, and submit it to Congress. The plan would be updated annually and describe the activities involved in the financial management reform.

Federal Accounting Standards Advisory Board

As a result of the CFO Act, the Federal Accounting Standards Advisory Board (FASAB) was established. The FASAB was initially sponsored by the Secretary of the Treasury, the Director of the Office of Management and Budget and the Comptroller General, whose respective agencies fund the FASAB.

The FASAB functions as a federal advisory committee, tasked with promoting federal accounting standards for public accountability and efficient functioning of public services. The FASAB contributes to assessing:

• Accountability, efficiency and efficacy of the federal government.
• Economic, political and social consequences of federal resource allocation and use.

According to the FASAB, the objective of accounting standards should allow federal agencies to provide comprehensible, relevant and reliable information about their operations. Standards should also contribute to the improvement of accounting systems and the development of effective internal controls.

Government Performance and Results Act of 1993

The Government Performance and Results Act of 1993 (GPRA) updated the CFO Act by initiate performance reform through program goals, performance metrics and public reporting processes. According to the GPRA, federal agencies had to develop and submit the following:

1.   Six-year strategic plan describing the mission of the agency. This was required by 1997.

2.   Annual performance plan, which outlined the following year’s goals. This was required by 1998.

3.   Annual performance report, which compares program goals with performance results. This was due by 2000.

The GPRA requirements challenged federal agencies to become results-oriented and measure their performance.

Government Management Reform Act of 1994

The Government Management Reform Act (GMRA) extended the CFO Act. The GMRA requires that every executive government agency produces auditable financial statements, similar in style to those of private sector organizations. It was designed to amend the CFO Act and improve project management practices within the agencies.

According to the GMRA, each department and agency should produce a statement that includes:

• Overall financial position (assets and liabilities) of offices, bureaus and activities
• Results of the department/agency’s operations

Since the enactment of the GMRA, most executive agencies have struggled to produce adequate financial statements reflecting their operations.

Federal Financial Management Improvement Act of 1996

The Federal Financial Management Improvement Act (FFMIA) was enacted to further develop the CFO Act, the GPRA and the GMRA. It was created in order to correct serious deficiencies in federal financial management and fiscal practices. The FFMIA had the following objectives:

• Ensure consistency in accounting throughout the federal government, from one fiscal year to another.
• Require full disclosure of federal financial data to citizens, Congress, the President and agency management.
• Increase accountability and credibility in financial management practices of the federal government.
• Improve performance, productivity and efficiency of financial management practices.
• Aid in controlling federal government costs.

Information Technology Management Reform Act of 1996

Similar to the previous acts, the Information Technology Management Reform Act (ITMRA; also referred to as the Clinger-Cohen Act) furthered the goals of improving productivity, efficiency and efficacy of the federal programs. The ITMRA was created specifically to streamline the IT planning and procurement process. It gave new responsibilities to the Director of the OMB, which include:

• Develop a process to monitor and analyze risks and results of capital investments.
• Submit a report on program performance benefits and the relationship between the investments and agency goals.

The ITMRA created the new position of Chief Information Officer (CIO) in each agency. The CIO has the following responsibilities:

• Monitor and evaluate performance of the agency IT program.
• Advise the head of the agency on an annual basis regarding information resources management, as part of the strategic planning and evaluation processes.

Summary

This article explores the Acts associated with ensuring federal government accountability in the US. The article begins with the 1990 CFO Act (Chief Financial Officers Act), which requires audited financial statements from federal agencies. It then looks at the GPRA (Government Performance and Results Act of 1993), which began the process of performance reform. The GMRA (Government Management Reform Act of 1994) that followed required agencies to produce auditable financial statements, similar to those required in the private sector. The FFMIA (Federal Financial Management Improvement Act of 1996) built upon the previous acts, requiring full disclosure of federal financial data. Finally, the ITMRA (Information Technology Management Reform Act of 1996) furthered federal objectives of improved productivity and efficacy by streamlining the IT planning and procurement process.

CIPP/G Preparation

In preparation for the Certified Information Privacy Professional/US Government exam, a privacy professional should be comfortable with topics related to this post, including:

• Federal agency responsibilities (II.A.c.)

Federal government reporting obligations (II.B.f.)

In contrast to traditional monitoring processes, which use only a small sample of events, continuous monitoring audits the system during or immediately after they occur.

What is being monitored?

1.   Primary Monitoring – this involves security controls. The primary focus [...]]]> Cybersecurity is one of the highest national priorities in the US. In order to preserve cybersecurity, legislation such as the FISMA (Federal Information Security Management Act) has been substantially updated to improve capacity for preventing, detecting and responding to threats. Ongoing updates to legislation seem to suggest a shift from simply demanding compliance to adoption of a continuous monitoring model.

What is Continuous Monitoring?

In contrast to traditional monitoring processes, which use only a small sample of events, continuous monitoring audits the system during or immediately after they occur.

What is being monitored?

1.   Primary Monitoring – this involves security controls. The primary focus looks at hardware, software and firmware.

2.   Secondary Monitoring – this type of monitoring is concerned with the operational environment. Secondary foci would include the environment, mission and policy/regulations.

3.   Changes to the systems

Key stages in the continuous monitoring process include the following:

• Identify the control rule for each control point.
• Establish a test that validates each control rule.
• Establish tests to identify problematic transactions.
• Test transactions regularly.
• Identify transactions that fail the tests. Notify the appropriate individuals within the organization of failures.
• Investigate failed transactions and act to correct the transactions or control problem.

Continuous Auditing vs. Continuous Monitoring

Both continuous auditing and continuous monitoring aim to provide organizations with more transparency through accurate, timely reporting practices. Continuous auditing is the automated collection of audit indicators from the IT systems, transactions, processes and controls on a continuous basis. This may be carried out by an internal or external auditor. Continuous auditing can serve as a means to detect control failures earlier than other reporting approaches.

By contrast, continuous monitoring is an automated feedback system that reports on the operation of systems and controls. This is analyzed by management to identify gaps or irregularities which may indicate control failures.

SANS Security Controls

Twenty critical security controls were developed by SANS (the SysAdmin, Audit, Network, Security Institute), in collaboration with hundreds of other groups, including the Department of Defense, civilian federal agencies and cybersecurity experts. The SANS controls have been developed in order to reinforce concerns of US cybersecurity legislation, such as the FISMA, in addition to other government documentation, including NIST SP 800-53, SCAP (Security Content Automation Protocol) and FDCC (Federal Desktop Core Configuration). These controls are generally the highest priority concerns of most security professionals.

Each critical control is associated with a series of tests that should be conducted either on a periodic or a continual basis. The following are the security control categories, along with a brief explanation of the potential risk it addresses, as well as how the control can be implemented and measured. The first fifteen categories are critical controls subject to automated collection, measurement and validation.

1. Inventory of authorized and unauthorized devices

• Risk: New and unprotected systems are vulnerable to exploitation. They may enable attackers to access the information deeper within the organization.
• Implementation: Maintenance of accurate and up-to-date inventories, utilizing inventory monitoring tools. Inventories should include removable media devices, USB tokens, external hard drives and other information storage devices.
• Measurement: Connect hardened test systems to the network, to ensure that they are automatically isolated.

2. Inventory of authorized and unauthorized software

• Risk: Certain versions of software are vulnerable to exploitation, such as backdoor programs, bots and zero-day exploits.
• Implementation: Develop a list of authorized software. Use software inventory tools to track the type, version and patch level of software installed on each system in the organization.
• Measurement: Introduce a benign software test program.

3. Secure configurations for hardware and software on laptops, workstations and servers

• Risk: Default configurations often do not provide an adequate level of security.
• Implementation: Document security settings of system images.
• Measurement: Detect unauthorized changes. Use file integrity checking tools and system scanning tools.

4. Secure configurations for network devices (e.g. firewalls, routers, switches)

• Risk: Overtime, network devices may be less securely configured.
• Implementation: Compare network device configuration against standard secure configurations.
• Measurement: Use changes to network devices to test for alert and isolation. Test that protocols (e.g. IPv6) are being filtered correctly.

5. Boundary defense

• Risk: Weaknesses in configuration or architecture on perimeter systems or network devices can give attackers access into the system.
• Implementation: Communications should be limited to trusted sites and pass through at least one proxy.
• Measurement: Test boundary devices by sending and accepting packets through the boundary.

6. Maintenance, monitoring and analysis of security audit logs

• Risk: Flaws in security logging and analysis may help attackers disguise location, activities and malicious software on machines.
• Implementation: Validate audit logs for hardware and software installed on it.
• Measurement: Review security logs from network devices, servers and hosts.

7. Application software security

• Risk: Application software that has security flaws could allow attackers to introduce buffer overflows, SQL injection attacks, cross-site scripting, etc.
• Implementation: Test internally developed and third-party web and application software. Use web application firewalls to inspect traffic.
• Measurement: Test with a web application vulnerability scanner. Use static code analysis tools and database configuration review tools.

8. Controlled use of administrative privileges

• Risk: Uncontrolled administrative privileges can allow attackers to take over a machine or elevate administrative privileges.
• Implementation: Keep an inventory for all administrative passwords. Ensure that all those with administrative privileges have the appropriate authorization.
• Measurement: Verify enforcement of password policy.

9. Controlled access based on need to know

• Risk: Sensitive data that is mixed with less sensitive data may be easily compromised, since the level of access is the same.
• Implementation: Develop a multi-level data separation scheme.
• Measurement: Test that accounts with limited privileges are unable to access the same files as those with more privileges.

10. Continuous vulnerability assessment and remediation

• Risk: Delays in finding or repairing software with vulnerabilities can allow attackers to gain control and/or access sensitive information.
• Implementation: Vulnerability scanning tools should be used on all systems. Results should be compared to determine if vulnerabilities have been addressed.
• Measurement: Verification of application vulnerability scanning.

11. Account monitoring and control

• Risk: Inactive user accounts may be vulnerable to impersonation and unauthorized access.
• Implementation: System accounts should be reviewed regularly. Accounts that are dormant should be disabled.
• Measurement: Evaluation should be conducted on accounts that have been locked out or disabled, as well as those with expired passwords.

12. Malware defenses

• Risk: Malware can tamper with data stored on a system, capture sensitive information and transmit it to other systems.
• Implementation: Workstations, servers and mobile devices should have anti-virus, anti-spyware and host-based intrusion prevention systems.
• Measurement: Test with benign malware to ensure systems are able to promptly identify, block and quarantine it.

13. Limitation and control of network ports, protocols and services

• Risk: Poorly configured web servers, mail servers, DNS servers and file and print services may give attackers remote access.
• Implementation: Apply host-based firewalls or port filtering tools on end systems.
• Measurement: Install test services with network listeners randomly on the network.

14. Wireless device control

• Risk: Wireless devices are often remotely exploited when used outside the organization.
• Implementation: Each wireless device on the network must have an authorized configuration and security profile.
• Measurement: Wireless clients and access points should be tested for vulnerabilities in various scenarios.

15. Data loss prevention

• Risk: Data leakage may be a result of a variety of attacks (e.g. physical theft, data transfers across the network).
• Implementation: Network monitoring should examine outbound traffic. Laptops with sensitive data should have encrypted hard drives.
• Measurement: Test data should be moved across network boundaries in a variety of scenarios.

The last five control categories are indirectly supported by automated measurement and validation. They include:

16.                Secure network engineering

17.                Penetration tests and red team exercises

18.                Incident response capability

19.                Data recovery capability

20.                Security skills assessment and appropriate training

Example of Continuous Monitoring

An example of a continuous monitoring system in action is the recently-introduced CyberScope tool, which is currently being used by US federal agencies. With CyberScope, agency personnel send in real-time reports and questionnaires on their agency’s IT security status. This replaces the previous practice of sending in annual paperwork and reports, which were costly, time-consuming and provided limited or outdated data. CyberScope was developed in order to move IT security management from simply achieving compliance, to a model of continuous monitoring and situational awareness.

Summary

This article explores the concept of continuous monitoring, a current approach to IT security management. Continuous monitoring can improve the quality of information security by providing up-to-date and meaningful information to decision makers. Unlike traditional monitoring, which can only provide a limited snapshot of the security situation within an agency or organization, continuous monitoring strategies are more dynamic. The article also looks at the SANS security controls, which represent the priority concerns of security professionals today.

CIPP/G Preparation

In preparation for the Certified Information Privacy Professional/US Government exam, a privacy professional should be comfortable with topics related to this post, including:

• Federal Information Security Management Act of 2002 – FISMA (I.C.f.)
• Federal agency performance (I.C.f.i.3.)
• US government privacy program development (II.A.a.)
• Auditing and compliance monitoring (II.B.c.)

The FISMA, enacted in 2002 under the E-Government Act of 2002, required regular reporting from federal agencies regarding their information security practices. These reports were to be submitted on [...]]]> In October 2009, the US federal Office of Management and Budget (OMB) released CyberScope, a reporting tool for federal agencies. Under the FISMA (the Federal Information Security Management Act of 2002), agencies are obliged to report on their information security statuses. The introduction of CyberScope aimed to correct any weaknesses and streamline the IT security reporting process. This article takes a look at how CyberScope has improved upon the FISMA reporting approach.

Background

The FISMA, enacted in 2002 under the E-Government Act of 2002, required regular reporting from federal agencies regarding their information security practices. These reports were to be submitted on an annual basis to the Office of Management and Budget. It quickly became clear that the reports being generated were not useful for agencies or oversight groups, as they could only represent a very limited snapshot of the agency’s IT security posture.

Additionally, the costs of enforcing FISMA mandates were high. For instance, the certification and accreditation required by FISMA cost $1.3 billion per year, while compliance auditing required another $1 billion. Since the enactment of FISMA in 2002, it is estimated that the federal government has spent over $40 billion. The annual security reports mandated by the FISMA would cost $1,400 per page to produce. This added up to over $500 million each year.

Clearly, the security reporting processes were costly, time-consuming and unsecure, without seeming to have positive effects on federal cybersecurity. The reporting methods depended on large, static spreadsheets that were often outdated by the time they were published. An automated method that could reduce costs and streamline the reporting process was required.

During October 2009, FISMA was revamped to mandate real-time reporting, rather than the previously-required annual reports. This new type of reporting would be facilitated by CyberScope, an online reporting tool based on a Justice Department tool. Use of CyberScope was mandated for civilian agencies only; the Department of Defense has its own set of reporting tools and mechanisms.

What is CyberScope?

CyberScope is a web-based application that collects data from each federal agency, to assess IT security. This represents a major shift, as IT reporting was previously done through paperwork reports. CyberScope relies on live data feeds and data entry by agency staff. It is designed as a central repository, accessible by agencies through a standard interface and format. Through this interface, agencies provide data to the OMB, which then compiles and generates reports to other agencies, as required by the FISMA.

CyberScope is based on automation; users login by using a secure PIV (personal identity verification) car and PIN (personal identification number). It supports its 600 agency users in various information collection processes. This more automated and frequent method improves the monitoring and evaluation of IT security performance over time.

CyberScope in Use

While federal agencies such as NASA, the Department of the Treasury, the Department of Veterans Affairs, the Department of Agriculture and the Department of State were able to submit real time data feeds by July 2010, many agencies required systems upgrades to support the CyberScope reporting program. In order to accommodate the agencies unable to submit through CyberScope, the OMB has allowed for reporting through Excel templates, with the information being uploaded using XML.

FISMA reporting through CyberScope for the fiscal year of 2010 involves a three-tiered approach, which is made up of:

a) Direct data feeds from security management tools

Direct reporting from continuous monitoring programs and security management tools is required by the OMB. The OMB has defined a set of elements that monitoring systems are obliged to report on. This includes: inventory; systems and services; hardware; software; external connections; security training; and identity management and access. During the fiscal year of 2010, agencies are required to report on a quarterly basis. Beginning in 2011, they will need to report on a monthly basis.

b) Government-wide benchmarking regarding IT security

CyberScope presents agencies with a number of questions regarding the security poster. The agency head is also required to submit a comprehensive overview of the information security policies, procedures and practices of the agency. This overview can be completed through CyberScope. From 2010 onwards, the OMB only accepts submissions through CyberScope.

c) Agency-specific interviews

A team of specialists will interview agencies on specific threats. This information will be presented in the 2010 Report on FISMA to Congress.

The combination of electronic interviewing, in-person interviewing and the continuous collection of data aims to develop a cybersecurity profile for each federal agency. These profiles are crucial for identifying strengths and weaknesses in the federal government’s IT systems and ensure compliance.

As mandated by the OMB, the Department of Homeland Security (DHS) is responsible for providing support to agencies in securing their systems. It is responsible for oversight of the CyberScope tool. The DHS must also track and report progress to ensure implementation is effective.

Beyond CyberScope

CyberScope is one of a number of other digital tools that can help support FISMA objectives and facilitate compliance. For instance, the Department of State has introduced a digital security dashboard which monitors its extensive system of 5,000 routers and 40,000 host computers supporting 285 posts worldwide. The automated dashboard is linked to the Risk Scoring Program.

The Risk Scoring Program routinely monitors and assesses ten categories of vulnerabilities. Each category is then scored between one and ten, with ten points representing the most severe vulnerability. Using the risk scores, letter grades between A to F- are assigned to the IT professionals responsible for the systems. This is done at least once every two days.

The continuous monitoring model introduced by the Program allows IT professionals to identify their degree of risk against the defined criteria. It also allows them to rank themselves against their peers, which can be motivational and foster competition.

As a result of the Department of State’s Risk Scoring Program, the Department of State has been able to reduce risk at its domestic offices by 83% since 2008. It has also been able to reduce risk at its foreign locations by 84%.

To complement the automated reporting introduced by CyberScope, the OMB implemented a cybersecurity dashboard. This dashboard was created to facilitate FISMA submissions in a timely and secure manner.

Summary

This article explores the need for CyberScope, an automated, real-time reporting tool, which allows US federal agencies to comply with the FISMA (Federal Information Security Management Act). Prior to the introduction of CyberScope, agencies relied on a costly and time-consuming reporting method, which could only provide a very limited snapshot of their IT security status. CyberScope is also part of a new three-tier approach to FISMA monitoring, which is made up of direct data feeds, government-wide benchmarking and agency-specific interviews. In addition to CyberScope, the article also explores other digital tools based on the continuous monitoring model, which can be used to facilitate FISMA compliance.

CIPP/G Preparation

In preparation for the Certified Information Privacy Professional/US Government exam, a privacy professional should be comfortable with topics related to this post, including:

• Office of Management & Budget – OMB (II.A.c.i.)
• OMB reporting requirements (II.A.c.i.1.b.)
• OMB reporting obligations (II.B.f.i.)
• FISMA reporting (I.C.f.i.2.)

The FISMA (Federal Information Security Management Act) mandates that information system must adequately protect government data. Under [...]]]> The National Institute of Standards and Technology (NIST) is responsible for developing standards and guidelines for information security for all civilian federal agencies. It produces security controls for information systems, which are the safeguards necessary to protect the confidentiality, integrity and availability of the data. The NIST SP (Special Publication) 800-53: Recommended Security Controls for Federal Information Systems defines security controls for executive agencies of the US federal government. This article introduces the publication and some of its key concepts.

Purpose of NIST SP 800-53

The FISMA (Federal Information Security Management Act) mandates that information system must adequately protect government data. Under the FISMA, the responsibility for developing security standards falls under the jurisdiction of the NIST. The NIST SP 800-53 provides guidelines for federal agencies to select and define security controls for their information systems. It is also used in non-federal government and private sector organizations as well.

Within the context of federal agencies, the publication was created to achieve the following:

• Facilitate a consistent approach to select and specify information security controls.
• Offer minimum information security controls.
• Offer a catalog of information security controls to meet the current and future security needs of organizations.
• Form a basis to develop security control assessment methods and procedures.

The NIST SP 800-53 is directed towards information system and security professionals, which may include:

• Chief information officers
• Senior agency information security officers
• Authorizing officials
• Program/project managers
• Mission/application owners
• System designers
• System/application programmers
• Information system owners
• Information owners
• Information system administrators
• Information system security officers
• Auditors
• Inspectors general
• Evaluators
• Certification agents

Organization & Structure

There are three general classes of security controls and seventeen security control families, as listed below:

Management

• Certification, Accreditation and Security Assessments
• Planning
• Risk Assessment
• System and Services Acquisition

Operational

• Awareness and Training
• Configuration Management
• Contingency Planning
• Incident Response
• Maintenance
• Media Protection
• Physical and Environmental Protection
• Personnel Security
• System and Information Integrity

Technical

• Access Control
• Audit and Accountability
• Identification and Authentication
• System and Communications Protection

Baselines

The concept of baseline controls refer to the minimum security controls that are recommended for a system, based on its security categorization. The baseline enables agencies and organizations to determine the safeguards needed to protect the systems.

However, baselines alone are not enough to properly manage risk. The following considerations must be made when selecting baseline controls:

• Security Controls – Which security controls are “common” controls? How does this relate to the responsibilities of the owners of the information systems?
• Operational Environment – How can the operational environment of the system affect physical security controls?
• Physical Infrastructure – Do the security controls of the facility provide adequate protection to the information system and its assets?
• Public Access – What special security controls are necessary if users access the system through public interfaces? How are the issues of identification and authentication handled?
• Technology – What types of technologies are being used within the system (e.g. cryptography, public key infrastructure, wireless technologies)? Which risks can be mitigated through automated mechanisms?
• Policy and Regulation – Which laws, Executive Orders, directives, policies, standards or regulations apply to the types of data or systems used by the agency?
• Security Objectives – Can any security controls be downgraded to the corresponding controls of a lower baseline?

There are three sets of baseline controls: low-impact, moderate-impact and high-impact levels. This is based on FIPS 199 (Federal Information Processing Standards Publication), which is the mandatory federal security categorization standard. Each impact level is associated with a different security category. Security categories facilitate the proper selection of security controls, as well as how to supplement the baseline to appropriately manage risk.

Security categories (low, moderate or high) are based on the security objectives of confidentiality, integrity and availability. The format for representing the security category (SC) of a system is as follows:

SC_{information system} = {(confidentiality, impact), (integrity, impact), (availability, impact)}

Potential impact values for each objective can be low, moderate or high. Low-impact systems are information systems that have all three security objectives set at “low.” Moderate-impact systems have at least one “moderate” security objective and no objectives greater than moderate. High-impact systems have at least one “high” security objective.

Overall impact levels of information systems take into consideration three elements:

1.   Different types of information processed, stored or transmitted by the system.

2.   Impact levels of each type of information.

3.   Security categorization for each security objective.

The overall impact level is determined from the highest impact level of the three security objectives.

Risk Management

Proper risk management is crucial for any information security program. The risk approach balances security controls with efficacy, legislation, directives, regulations and policies. According to the NIST Risk Management Framework, managing risk involves the following steps:

• The information system is categorized.
• A set of baseline security controls are selected and used as a starting point for a risk assessment.
• The baseline set of controls are supplemented with additional information, including agency security requirements, threat information and other circumstantial information.
• The adjusted set of security controls is documented in the system security plan.
• Security controls are implemented into the system.
• Security controls are assessed using the appropriate methods and procedures.
• Information system operation is based on risk determination. This may involve risk to operations, assets or individuals.
• The selected security controls are monitored and assessed continuously. Any changes to the system are considered and reported as well.

Updating Controls

The security controls may need to be reassessed and updated. There are a number of events that may trigger this, including:

• Data breach
• Identification of a new and credible threat
• Major changes to the system configuration

According to the NIST SP 800-53, it is recommended to take the following precautions:

• Assess the sensitivity of the system and data processed, stored or transmitted by that system.
• Assess the current situation of the system, taking into consideration vulnerabilities, threats and risks.
• Determine any necessary corrections that may need to be initiated.
• Determine if reaccreditation of the system is necessary.

Summary

This article introduces the NIST SP 800-53, which outlines recommended security standards and controls for information systems in federal agencies. The framework was developed as a mandate of the FISMA (Federal Information Security Management Act of 2002), and is recommended for use in the private sector as well.  The article outlines the purpose of the NIST publication and lists the organizational structure for the security controls. It also looks at the process by which the controls are selected and how baseline controls can be updated to better reflect an organization’s security situation. Finally, the article outlines the reasons for which controls may be updated and how agencies or organizations can respond to events.

CIPP/G Preparation

In preparation for the Certified Information Privacy Professional/US Government exam, a privacy professional should be comfortable with topics related to this post, including:

• FISMA performance (I.C.f.i.3.)
• System compliance (I.C.f.i.ii.)

SCAP (Security Content Automation Protocol) enables maintenance and assessment of enterprise systems security to be conducted in a standardized manner. SCAP is made up of several open standards that are used to identify and describe flaws and other security issues. SCAP standards may be able to carry out any of the following tasks:

-       Automatically verify patches

-       Check system security [...]]]> SCAP is a means of applying standards to ensure management and measurement of vulnerabilities. The objective of SCAP is to facilitate evaluation and policy compliance by integrating the goals of IT with those of IT security.

What is SCAP?

SCAP (Security Content Automation Protocol) enables maintenance and assessment of enterprise systems security to be conducted in a standardized manner. SCAP is made up of several open standards that are used to identify and describe flaws and other security issues. SCAP standards may be able to carry out any of the following tasks:

-       Automatically verify patches

-       Check system security configuration settings

-       Search systems for vulnerabilities and risks

As the standards are transparent, interoperable, repeatable and automated, organizations can evaluate their policy compliance. For instance, an organization can evaluate for FISMA compliance with SCAP standards. With SCAP, compliance is an automatic result of good enterprise security, since compliance reporting is linked to the system configuration.

NIST (US National Institute of Standards and Technology) defines SCAP standards, defines the mappings and manages the protocol. However, NIST is not responsible for controlling the underlying SCAP standards, which are discussed later in this article.

Components of SCAP

SCAP is made up of security checklist data, vulnerability enumerations and the mappings between these enumerations. SCAP content is described below:

• Security Checklist Data

Checklists are overseen by the NIST National Checklist program. This is written in machine-readable language.

• Vulnerability Enumerations

This is a list of all security related flaws or issues as well as a list of vendor/product names.

• Mappings

These mappings are provided by the National Vulnerability Database (NVD). The mappings describe the affected product names and help identify the standard impact score for flaws or issues.

In addition to the main SCAP standard, there are also six underlying SCAP standards. The underlying standards are listed and described below:

1.   CVE

o   Common Vulnerability Enumeration

o   This describes publicly known IT vulnerabilities and issues.

o   CVE provides common names to identify publicly-known problems. These names are also referred to as “CVE names,” “CVE numbers,” “CVE-IDs” and “CVEs.”

o   CVE supports an organization’s vulnerability management functions.

o   CVE names contain the following information:

§  CVE identification number

§  Either “entry” or “candidate” status

§  Description of security vulnerability

§  Important references, such as vulnerability reports or OVAL-ID

2.   CCE

o   Common Configuration Enumeration

o   This describes system configuration issues.

o   CCE also enables the correlation of configuration data from multiple sources in an efficient, accurate manner.

o   CCE assigns enumerations (referred to as “CCEs”) to configuration statements and controls. It is similar to the CVE list.

o   CCE supports an organization’s configuration management functions.

o   CCEs contain the following information:

§  CCE identifier number

§  Human-readable description of the issue

§  Parameters specifying CCE implementation

§  Related technical mechanisms regarding the configuration issue

§  References to the documents or tools that describe the configuration issue in detail

3.   CPE

o   Common Platform Enumeration

o   This is a naming scheme for a number of IT platforms (i.e. operating systems, applications and hardware).

o   CPE enables the identification of specific platforms, based on URI (Uniform Resource Identifiers) syntax.

o   CPE supports an organization’s asset management functions.

o   CPE includes the following:

§  Formal name format

§  Description of complex platforms

§  System to check names

§  Description format

§  Tests to a name

4.   CVSS

o   Common Vulnerability Scoring System

o   This helps to determine the impact of IT vulnerabilities. Other vulnerability scoring systems, such as the CERT/CC or the SANS vulnerability analysis scale may also be used by commercial as well as non-commercial organizations.

o   CVSS also serves as a means to communicate vulnerability characteristics.

o   CVSS supports an organization’s configuration management and vulnerability management functions.

o   CVSS is made of the following metric groups, as described below:

a) Base Metric Group

• • This measures the intrinsic, fundamental characteristics of certain vulnerabilities. Base metrics are constant, regardless of time and user environments.
  • Base metrics include:
    • Access Vector
    • Access Complexity
    • Authentication
    • Confidentiality Impact
    • Integrity Impact
    • Availability Impact

b) Temporal Metric Group

• This measures characteristics that change over the course of time, but are unrelated to user environments.
• Temporal metrics include:
  • Exploitability
  • Remediation Level
  • Report Confidence

c) Environmental Metric Group

• This measures the characteristics that are dependent upon a specific user environment.
• Environmental metrics include:

• • • Collateral Damage Potential
    • Target Distribution
    • Confidentiality Requirement
    • Integrity Requirement
    • Availability Requirement

5.   XCCDF

o   eXtensible Checklist Configuration Description Format

o   This is an XML-based language.

o   XCCDF is used to represent checklists, benchmarks and other pertinent documents in machine-readable format.

o   XCCDF supports an organization’s compliance management and configuration management functions.

6.   OVAL

o   Open Vulnerability and Assessment Language

o   This is an XML-based language.

o   OVAL represents configuration information; analyzes the system for patches, vulnerabilities, security configuration standards or other machine states; and reports assessment results.

o   OVAL supports an organization’s configuration management and vulnerability management functions.

SCAP Validation & Emerging Specifications

SCAP protocols facilitate the exchange of system configuration controls and vulnerability information in a standardized format. The Validation Program assesses the ability of the products to use the SCAP components. SCAP validation is carried out by independent laboratories, accredited by the NIST. Based on lab results, the product is SCAP-validated. The information is announced on the NIST web page.

There are a number of different SCAP Validated Products, distributed by the following five vendors:

1.   Gideon Technologies – SecureFusion

2.   netIQ – Secure Configuration Manager

3.   secure elements – CS Compliance Platform

4.   ThreatGuard – Secutor Prime and S-CAT

5.   Tenable Network Security – Security Center

A number of other SCAP products are in the testing process. Other products are on the potential validation list. There are a number of emerging specifications, which are listed below:

• ARF (Asset Reporting Format)
• OCIL (Open Checklist Interactive Language)
• OCRL (Open Checklist Reporting Language)
• CCSS (Common Configuration Scoring System)
• CMSS (Common Misuse Scoring System)

SCAP Release Cycle

SCAP specifications are under ongoing change in order to meet the needs of its users. SCAP change management is outlined in its Release Cycle:

• NIST review, community feedback and candidate process – consideration of new or updated specifications that may become part of SCAP.
• Review of potential SCAP candidates – this allows the community to offer comments or feedback before finalization of the specification.
• Publication of draft SCAP – gives notices regarding new/updated specifications.
• SCAP beta content – provided for testing and use by the community.
• Publication of final NIST specification – after this step, the specification becomes effective.
• SCAP content finalization – any previously released beta content becomes final.
• Laboratory product validation period – product testing by accredited laboratories. This extends for a period of twelve months.
• Expiration of product validations – product validations expire after one year.

Summary

This article introduces SCAP open standards by exploring the reasons for which they may be implemented within an organization. The article describes the functions of the six components (or underlying standards) of SCAP, which include: the Common Vulnerabilities and Exposures (CVE); Common Configuration Enumeration (CCE); Common Platform Enumeration (CPE); Common Vulnerability Scoring System (CVSS); eXtensible Configuration Checklist Description Format (XCCDF); and Open Vulnerability and Assessment Language (OVAL). The process by which emerging standards are validated and updated is also described.

CIPP/G Preparation

In preparation for the Certified Information Privacy Professional/US Government exam, a privacy professional should be comfortable with topics related to this post, including:

• Federal Information Security Management Act of 2002 – FISMA (I.C.f.)
• System compliance (I.C.f.ii.)
• Program management – FISMA model (II.A.b.i.)