Cyber-based threats to federal systems and critical infrastructure are evolving and growing. These threats can be intentional or unintentional, targeted or non-targeted, and can come from a variety of sources, including criminals, terrorists, and other adversarial groups, as well as hackers and disgruntled employees. These potential attackers have a variety of techniques at their disposal, which can vastly enhance the reach and impact of their actions. For example, cyber attackers do not need to be physically close to their targets, their attacks can cross state and national borders, and they can preserve their anonymity. Further, the growing interconnectivity among different types of information systems presents increasing opportunities for such attacks. Reports of security incidents from federal agencies are on the rise, increasing by more than 200 percent from fiscal year 2006 to fiscal year 2008. In February 2009, the Director of National Intelligence testified that foreign nations and criminals had targeted government and private sector networks to potentially disrupt or destroy them, and that terrorist groups had expressed a desire to use cyber attacks as a means to target the United States. As recently as July 2009, media accounts reported that a widespread and coordinated attack over the course of several days targeted Web sites operated by major government agencies, including the Departments of Homeland Security and Defense, the Federal Aviation Administration, and the Federal Trade Commission, causing disruptions to the public availability of government information. Such attacks highlight the importance of developing a concerted response to safeguard federal information systems. Compounding the growing number and kinds of threats, we—along with agencies and their inspectors general—have identified significant weaknesses in the security controls on federal information systems, which have resulted in pervasive vulnerabilities. These include deficiencies in the security of financial systems and information and vulnerabilities in other critical federal information systems and networks. These weaknesses exist in all major categories of information security controls at federal agencies; for example, in fiscal year 2008, weaknesses were reported in such controls at 23 of the 24 major agencies. Specifically, agencies did not consistently authenticate users to prevent unauthorized access to systems; apply encryption to protect sensitive data; and log, audit, and monitor security-relevant events, among other actions. Our recent work focusing on specific agencies has also revealed security weaknesses, as illustrated by the following examples: In 2009, we reported that three National Aeronautics and Space Administration centers had not, among other things, sufficiently restricted system access and privileges to only those users that needed access to perform their assigned duties, appropriately implemented encryption to safeguard sensitive information, and expeditiously applied a critical operating system patch or patches for a number of general third-party applications. At the same time, the agency experienced numerous cyber attacks and malicious software infections, thereby exposing critical and sensitive data to unauthorized access, disclosure, and manipulation. We recommended that the agency take steps to mitigate these weaknesses and fully implement a comprehensive information security program. In the same year, we reported that the Financial Crimes Enforcement Network, a bureau within the Department of the Treasury, had not consistently implemented effective password controls or effectively controlled user identification and authentication. As a result, there was increased risk that malicious individuals could gain inappropriate access to sensitive systems and data. We recommended that the agency take steps to fully implement an agencywide security program. In 2008, we reported that although the Department of Energy’s Los Alamos National Laboratory—one of the nation’s weapons laboratories—had implemented measures to enhance the information security of its unclassified network, there were still vulnerabilities in monitoring and auditing compliance with security policies and controlling and documenting changes to a computer system’s hardware and software. Finally, we reported in 2007 that the Department of Homeland Security had significant weaknesses in computer security controls intended to protect the information systems used to support its U.S. Visitor and Immigration Status Indicator Technology program for border security. For example, the department had not implemented controls to effectively prevent, limit, and detect access to computer networks, systems, and information. Specifically, it had not provided adequate logging or user accountability for the mainframe, workstations, or servers and had not consistently maintained secure configurations on the application servers and workstations at a key data center and points of entry. In each of these cases, we made recommendations for strengthening or fully implementing agencies’ information security programs. In addition to the responsibilities of individual agencies, OMB and NIST play key roles in ensuring the security of federal systems and information. Under the Federal Information Security Management Act of 2002 (FISMA), OMB is responsible for developing and overseeing the implementation of policies, principles, standards, and guidelines on information security, and reviewing agency information security programs at least annually. In addition, the act requires that OMB report to Congress no later than March 1 of each year on the status of agency compliance with FISMA. The act, which sets forth a comprehensive framework for ensuring the effectiveness of information security controls over information resources that support federal operations and assets, also assigned NIST responsibility for developing standards and guidelines (for systems other than national security systems) that include minimum information security requirements. FISMA also assigns specific responsibilities to agencies to document and implement agencywide security programs and report on their security policies, procedures, and practices. For example, agencies are responsible for developing and complying with minimally acceptable system configuration requirements. Finally, FISMA requires agency inspectors general to annually evaluate agency information security activities. To help carry out its responsibilities for ensuring federal information security, OMB launched the FDCC initiative in March 2007. This initiative required federal agencies to implement common security configurations on Windows XP and Vista operating systems by February 2008. Subsequently, OMB issued several other memorandums detailing additional requirements and guidance to agencies on completing implementation of the initiative. OMB also has responsibility for approving any changes to the settings or setting parameters. At the request of OMB, NIST published the first beta version of the FDCC configuration settings in July 2007 for federal workstations that use Windows XP or Windows Vista as their operating system. FDCC was based on settings developed by the Air Force in partnership with the National Security Agency, Defense Information Systems Agency, NIST, and representatives from the Army, Navy, and Marines. Over the course of the next 11 months, NIST made several updates to the content and posted the revised versions on its Web site. The first major version of the configuration settings, version 1.0, was posted on NIST’s Web site in June 2008 after a period of public comment. Based on implementation information reported by the agencies to NIST in March 2008, agency feedback on settings that were problematic to implement, and comments from the federal community, OMB had NIST remove 40 settings from the original beta version for version 1.0. In addition to publishing the FDCC settings, NIST also has responsibility for: Developing resources, in collaboration with Microsoft, to aid agencies in deploying and testing the security configuration settings within their computing environments. These include group policy objects, which allow agencies to deploy the settings to desktop and laptop computers agencywide, and virtual hard-disk files, which allow agencies to test the settings in a non-operational environment. These files were first made available for agencies to download from NIST’s Web site starting in July 2007 and were later updated with the release of major version 1.0. Establishing the Security Content Automation Protocol (SCAP), which can be used to support the automated checking, measuring, and monitoring of the FDCC settings for compliance. Product vendors can create a tool (i.e., application) that uses SCAP for these activities. Validating SCAP tools to ensure that a tool uses the features and functionality available through SCAP. In order for a tool to receive validation, a vendor must first have the tool tested by 1 of 10 independent testing laboratories accredited under NIST’s National Voluntary Laboratory Accreditation Program. The testing results are then sent by the laboratory to NIST for review. If the tool passes, NIST will validate the SCAP tool, which is valid for 1 calendar year. Making technical changes to the SCAP that support the FDCC settings, such as when new specifications are added, existing specifications are updated, or when a more efficient method is found to test a particular setting. NIST has released two additional major versions to make technical modifications to the SCAP: version 1.1 in October 2008 and version 1.2 in April 2009. NIST also publishes patch content updates based on Microsoft’s patch releases. Posting frequently asked questions on its Web site on behalf of OMB to answer agencies’ questions about testing, deployment, reporting deviations, and use of SCAP tools for evaluation of compliance. The questions have also provided clarification of the settings requirements and their applicability to different types of computers, including contractor- owned or operated machines. These questions are revised on a periodic basis as needed and as determined by NIST. In its March 2007 directives to agencies to implement FDCC, OMB established two goals for the initiative: improve information security and reduce overall information technology (IT) operating costs for agencies that use or plan to use Windows XP or Vista operating systems on their workstations. By implementing the initiative, OMB intended that agencies should be able to achieve the following objectives: Provide a baseline level of security through the use of standardized configuration settings that limit access privileges granted to users and other access controls, thereby controlling what a user may or may not do on his or her workstation. The settings create a baseline from which agencies may increase the level of security by making the settings more restrictive or by employing firewalls and intrusion detection systems along with other security devices and practices. Reduce risk from security threats and vulnerabilities by employing the use of standards that are more restrictive than the default settings of the manufacturer. For example, the required settings do not allow the installation of unauthorized software, which lowers the risk of introducing a virus or other malicious device along with the software. Save time and resources by requiring all FDCC workstations within an agency to use the same settings.