NIST SP 800-100 日本語訳

NIST Special Publication 800-100

Recommendations of the National Institute of Standards and Technology

Pauline Bowen

Joan Hash

Mark Wilson

Computer Security Division Information Technology Laboratory National Institute of Standards and Technology Gaithersburg, MD 20899-8930

October 2006

U.S. Department of Commerce Carlos M. Gutierrez, Secretary

Technology Administration Robert Cresanti, Under Secretary of Commerce for Technology

National Institute of Standards and Technology William Jeffrey, Director

The Information Technology Laboratory (ITL) at the National Institute of Standards and Technology promotes the U.S. economy and public welfare by providing technical leadership for the Nation's measurement and standards infrastructure. ITL develops tests, test methods, reference data, proof-of-concept implementations, and technical analyses to advance the development and productive use of information technology. ITL's responsibilities include the development of management, administrative, technical, and physical standards and guidelines for the cost-effective security and privacy of nonnational-security-related information in federal information systems. This Special Publication 800 series reports on ITL's research, guidelines, and outreach efforts in information system security and its collaborative activities with industry, government, and academic organizations.

Authority

This document has been developed by the National Institute of Standards and Technology (NIST) in furtherance of its statutory responsibilities under the Federal Information Security Management Act (FISMA) of 2002, Public Law 107-347.

NIST is responsible for developing standards and guidelines, including minimum requirements, and for providing adequate information security for all agency operations and assets, but such standards and guidelines shall not apply to national security systems. This guideline is consistent with the requirements of the Office of Management and Budget (OMB) Circular A-130, Section 8b(3), Securing Agency Information Systems, as analyzed in A-130, Appendix IV: Analysis of Key Sections. Supplemental information is provided A-130, Appendix III.

This guideline has been prepared for use by federal agencies. It may also be used by nongovernmental organizations on a voluntary basis and is not subject to copyright regulations. (Attribution would be appreciated by NIST.)

Nothing in this document should be taken to contradict standards and guidelines made mandatory and binding on federal agencies by the Secretary of Commerce under statutory authority. Nor should these guidelines be interpreted as altering or superseding the existing authorities of the Secretary of Commerce, Director of the OMB, or any other federal official.

Certain commercial entities, equipment, or materials may be identified in this document in order to describe an experimental procedure or concept adequately. Such identification is not intended to imply recommendation or endorsement by NIST, nor is it intended to imply that the entities, materials, or equipment are necessarily the best available for the purpose.

NIST would like to thank the many people who assisted with the development of this handbook.

NIST management officials who supported this effort include: Joan Hash, William C. Barker, Elizabeth Chew, and Matthew Scholl.

The authors would like to thank Elizabeth Lennon, Alicia Clay, Elizabeth Chew, Richard Kissel, Carol Schmidt, Matthew Scholl, and Patricia Toth who assisted with reviewing this Handbook and provided comments and suggestions for improvement.

Additional drafters of Handbook chapters include:

Ron Ross, Tim Grance, and Marianne Swanson, NIST.

Nadya Bartol, Joe Nusbaum, Laura Prause, Will Robinson, Karen Kent, and Randy Ewell, BAH,

In addition, special thanks are due those contractors who helped craft the Handbook, prepare drafts, and review materials:

Nadya Bartol of Booz, Allen, Hamiliton (BAH), served as Project Manager for BAH on this project. In addition, many BAH employees contributed to the Handbook, including: Anthony Brown, Linda Duncan, Gina Jamaldinian, Sedar Labarre, Ines Murphy, Steven Peck, Mike Kapetanovic, Michael Rohde, Jacob Tsizis, Aderonke Adeniji, and Marge Spanninger.

The authors also gratefully acknowledge and appreciate the many contributions from individuals in the public and private sectors whose thoughtful and constructive comments improved the quality and usefulness of this publication.

Errata

The following changes have been incorporated into Special Publication 800-100.

This Information Security Handbook provides a broad overview of information security program elements to assist managers in understanding how to establish and implement an information security program. Typically, the organization looks to the program for overall responsibility to ensure the selection and implementation of appropriate security controls and to demonstrate the effectiveness of satisfying their stated security requirements. The topics within this document were selected based on the laws and regulations relevant to information security, including the Clinger-Cohen Act of 1996, the Federal Information Security Management Act (FISMA) of 2002, and Office of Management and Budget (OMB) Circular A-130. The material in this handbook can be referenced for general information on a particular topic or can be used in the decision-making process for developing an information security program. National Institute of Standards and Technology (NISTIR) Interagency Report 7298 provides a summary glossary for the basic security terms used throughout this document. While reading this handbook, please consider that the guidance is not specific to a particular agency. Agencies should tailor this guidance according to their security posture and business requirements.

The purpose of this publication is to inform members of the information security management team (agency heads; chief information officers [CIOs]; senior agency information security officers [SAISOs], also commonly referred to as Chief Information Security Officers [CISOs]; and security managers) about various aspects of information security that they will be expected to implement and oversee in their respective organizations. In addition, the handbook provides guidance for facilitating a more consistent approach to information security programs across the federal government. Even though the terminology in this document is geared toward the federal sector, the handbook can also be used to provide guidance on a variety of other governmental, organizational, or institutional security requirements.

This handbook summarizes and augments a number of existing NIST standards and guidance documents and provides additional information on related topics. Such documents are referenced within appropriate subchapters.

The intended audience includes agency heads, CIOs, SAISOs (also commonly referred to as CISOs), and security managers. The handbook provides information that the audience can use in building their information security program strategy. While there are differences between federal and private sector environments, especially in terms of priorities and legal requirements, the underlying principles of information security are the same. The handbook is therefore useful to any manager who requires a broad overview of information security practices.

Chapter 2

Federal agencies rely heavily on information technology (IT) to run their daily operations and deliver products and services. With an increasing reliability on IT, a growing complexity of federal government IT infrastructure, and a constantly changing information security threat and risk environment, information security has become a mission-essential function. This function must be managed and governed to reduce the risks to federal government operations and to ensure the federal government’s ability to do business and serve the American public.

The purpose of information security governance is to ensure that agencies are proactively implementing appropriate information security controls to support their mission in a cost-effective manner, while managing evolving information security risks. As such, information security governance has its own set of requirements, challenges, activities, and types of possible structures. Information security governance also has a defining role in identifying key information security roles and responsibilities, and it influences information security policy development and oversight and ongoing monitoring activities.

To ensure an appropriate level of support of agency missions and the proper implementation of current and future information security requirements, each agency should establish a formal information security governance structure.

Information security governance can be defined as the process of establishing and maintaining a framework and supporting management structure and processes to provide assurance that information security strategies are aligned with and support business objectives, are consistent with applicable laws and regulations through adherence to policies and internal controls, and provide assignment of responsibility, all in an effort to manage risk.

The United States (U.S.) Congress and the Office of Management and Budget (OMB) have instituted a number of laws, regulations, and directives that govern establishment and implementation of federal information security practices. These laws, regulations, and directives establish federal- and agency-level responsibilities for information security, define key information security roles and responsibilities, identify minimum information security controls, specify compliance reporting rules and procedures, and provide other essential requirements and guidance. These laws and regulations place responsibility and accountability for information security at all levels within federal agencies, from the agency head to IT users. They also provide an infrastructure for developing and promulgating detailed standards and implementation guidance to federal agencies and overseeing implementation of required practices through NIST and the Government Accountability Office (GAO), respectively.

These three entities, the U.S. Congress, OMB, and GAO, define and influence federal agency governance and information security requirements. Congress creates laws and oversight measures to establish objectives, present timely analyses to establish overall governance standards across the federal government, and provide aid in economic and budget decisions, including decisions about public IT assets and those funds needed to secure them. Agencies must establish clear reporting requirements that meet legislative requirements set by Congress and must also provide Congress with the necessary information and estimates required for the congressional budget process. OMB assists the President in overseeing the preparation of the federal budget and supervises its administration by the executive branch agencies. OMB provides further guidance to the agencies on implementing legislative information requirements in the form of circulars and memoranda. GAO also provides oversight of agency information security activities as a part of its mission “to support the Congress in meeting its constitutional responsibilities and to help improve the performance and ensure the accountability of the federal government for the benefit of the American people.”¹ GAO reviews agency implementation of legislative and regulatory requirements and reports to Congress and the American public on its findings.

At a minimum, information security governance in a federal department or agency must meet the requirements as they are detailed in applicable legislation, regulations, and directives. Furthermore, agencies can benefit from identifying overall good governance practices for establishing strong management and oversight. Agencies should tailor their information security governance practices to their organization’s own missions, operations, and needs.

The following are a few key legislative acts that define overall federal agency governance requirements:

Supporting these acts, three legislative documents emerge as the foundational sources for specific information security governance requirements:

Figure 2-1 illustrates key roles of legislative, regulatory, and oversight bodies in establishing governance and information security governance requirements for the federal enterprise.

Figure 2-1. Key Legislative, Regulatory, and Oversight Roles

The need to identify and implement appropriate federal government and agency-specific information security governance practices can be daunting. Agencies should identify applicable requirements based on relevant legislation, regulations, federal directives, and agency-level directives. Agencies should also ensure that information security governance structures are implemented in a manner that best supports their unique missions and operations.

Agencies should integrate their information security governance activities with the overall agency structure and activities by ensuring appropriate participation of agency officials in overseeing implementation of information security controls throughout the agency. The key activities that facilitate such integration are strategic planning, organizational design and development, establishment of roles and responsibilities, integration with the enterprise architecture, and documentation of security objectives in policies and guidance. Figure 2-2 illustrates the relative relationship of these various components.

Figure 2-2. Information Security Governance Components

“Strategic plans, annual performance plans, and annual program performance reports are the main elements of GPRA. Together these elements create a recurring cycle of reporting, planning, and execution.”⁵

GPRA requires federal agencies to develop and submit to OMB and Congress a “strategic plan for program activities” and “prepare an annual performance plan covering each program activity set forth in the budget of such agency.“6 Agencies are required to refresh their strategic plans within three years of submitting their previous strategic plans, while submitting performance plans is required annually.

Agencies should integrate information security into the agency strategic planning processes by establishing and documenting information security strategies that directly support agency strategic and performance planning activities. The organization’s information security strategy should establish a comprehensive framework to enable the development, institutionalization, assessment, and improvement of the agency’s information security program. The information security strategy should support the overall agency strategic and performance plans and IT strategic plan (if applicable) with its content clearly traceable to these higher-level sources. Each agency should define the following for its information security program:

Agencies should document their information security strategy in an information security strategic plan or another document, if appropriate. Regardless of how the information security strategy is documented, its contents should be aligned with the overall agency strategic planning activities. The document should be revisited when a major change in the agency information security environment occurs, including:

Information security governance structures can be characterized in a number of ways. There are two basic models of information security governance structures: centralized and decentralized. While agency heads are ultimately responsible for managing and governing their respective agency, the authority and responsibility over information security differs in the two types of structures. Key characteristics of the two structures are:

Completely centralized or decentralized information security governance implementations are quite rare. In reality, the variety of implemented information security governance structures spans the continuum from a centralized structure at one end to a decentralized structure at the other. Agencies usually adopt hybrid structures that include some characteristics of both centralized and decentralized types of structures, and they adopt the particular mix of these characteristics to fit their agency mission, size, homogeneity of their components, and existing governance structure.

Agencies in the process of establishing or changing their information security governance structure should consider the following key factors to determine the optimal extent of the centralization or decentralization:

To the degree that these factors are limited or varied, an organization’s hybrid information security governance structure will fall somewhere between the extremes of a completely centralized or decentralized structure, as depicted in Figure 2-3. An organization’s placement on this continuum may also shift over time in response to changing internal factors or external requirements.

Since information security governance structure is highly dependent on the overall organizational structure, organizations are often limited in their choices about how to organize their information security governance activities. Agencies should be cognizant of the characteristics and challenges that a centralized or decentralized structure presents and work within their respective organizations to ensure the best use of information security resources within the boundaries of their own structure.

There are several governance stakeholders common to most organizations that span the organization. These stakeholders include senior leadership, a CIO, information security personnel, and a chief financial officer (CFO), among others. The specific requirements of each role may differ with the degree of information security governance centralization or in response to the specific missions and needs of an organization.

Figure 2-3. Information Security Governance Structures

The Clinger-Cohen Act assigns the responsibility for ensuring “that the information security policies, procedures, and practices of the executive agency are adequate.”⁸ FISMA provides the following details on agency head responsibilities for information security:

FISMA assigns the agency CIO the following responsibilities:

FISMA assigns SAISO the following responsibilities:

The chief enterprise architect or comparable position in an organization is responsible for:

Many other individuals within an organization have a stake in information security, from top senior management down to individual users. A few of the primary senior management roles and their coinciding responsibilities are listed below. The scope of each role will depend on whether or not these roles should be redundant in the decentralized governance structure. These individuals should work collaboratively to ensure that information security exists within their organizational responsibility.

Inspector General (IG). The IG is a statutory office within an organization that, in addition to other responsibilities, works to assess an organization’s information security practices and identifies vulnerabilities and the possible need to modify security measures. The IG completes this task by:

Chief Financial Officer. The CFO is the senior financial advisor to the investment review board (IRB) and the agency head. Information security investments fall within the purview of the CFO and are included in the CFO’s reports. In this capacity, the CFO is responsible for:

Chief Privacy Officer or other designated official with privacy responsibilities. The chief privacy officer is responsible for privacy compliance across an organization, including privacy compliance measures that apply to information security assets and activities. The chief privacy officer works to maintain a balance between security and privacy requirements, and works to ensure that one is not compromised for the sake of the other. To this end, the chief privacy officer serves as the senior official responsible for:

Physical Security Officer or other designated official with physical security responsibilities. The physical security officer is responsible for the overall implementation and management of physical security controls across an organization, to include integration with applicable information security controls. As information security programs are developed, senior agency officials should work to ensure this coordination of complementary controls. In consideration of information security, the physical security officer serves as the senior official responsible for:

Personnel Security Officer or other designated official with personnel security responsibilities. This responsibility is often resident within the Human Resources or Human Capital organization. The personnel security officer is responsible for the overall implementation and management of personnel security controls across an organization, to include integration with specific information security controls. As information security programs are developed, senior agency officials should work to ensure this coordination of complementary controls. In consideration of information security, the personnel security officer serves as the senior official responsible for:

Acquisitions/Contracting. The Acquisitions/Contracting function is responsible for managing contracts and overseeing their implementation. Personnel executing this function have the following responsibilities in regards to information security:

FEA is a business-based framework for governmentwide improvement. The purpose of FEA is to facilitate cross-agency analyses and identify duplicative investments, gaps, and opportunities for collaboration within and across federal agencies.¹⁰ FEA facilitates identification of duplicative or wasteful investments, areas where investments should be made, and where departments and agencies can collaborate to improve government operations or services.

The FEA consists of five reference models:

OMB requires agencies to integrate security into their enterprise architecture development life cycle.¹¹ In addition to complying with OMB requirements, the integration of information security into the agency enterprise architecture efforts benefits both the agencies and the federal government:

the tool would handle. Since the federal government has numerous IT-related efforts under way, including critical infrastructure protection (CIP) and COOP processes that seek to preserve national resources as well as the ability of departments and agencies to operate in adverse or emergency conditions, a security-enabled FEA will provide support to those other efforts while simultaneously ensuring that information is appropriately protected within these efforts.

Information security policy is an aggregate of directives, rules, and practices that prescribes how an organization manages, protects, and distributes information.¹²

Information security policy is an essential component of information security governance—without the policy, governance has no substance and rules to enforce. Information security policy should be based on a combination of appropriate legislation, such as FISMA; applicable standards, such as NIST Federal Information Processing Standards (FIPS) and guidance; and internal agency requirements.

Agency information security policy should address the fundamentals of agency information security governance structure, including:

Supporting guidance and procedures on how to effectively implement specific controls across the enterprise should be developed to augment an agency’s security policy. This subsequent guidance on information security, created by the agency, in consideration of external guidance (e.g. NIST Special Publications and OMB memoranda), should be consistent with the information security policy and may not supersede it, unless the policy itself is being modified. Agencies should ensure that their information security policy is sufficiently current to accommodate the information security environment and agency mission and operational requirements. To ensure that information security does not become obsolete, agencies should implement a policy review and revision cycle. As a part of the periodic review and the initial development of the information security policies, agencies should work to ensure that all internal security policies (i.e., physical and personnel) are sufficiently coordinated to ensure effective implementation of crosscutting and convergent security objectives, such as access control initiatives.

An effective information security governance program requires constant review. Agencies should monitor the status of their programs to ensure that:

Over time, policies and procedures may become inadequate because of changes in agency mission and operational requirements, threats, environment, deterioration in the degree of compliance, changes in technology or infrastructure, or business processes. Periodic assessments and reports on activities can be a valuable means of identifying areas of noncompliance, reminding users of their responsibilities and demonstrating management's commitment to the security program. While an organization’s mission does not frequently change, the agency may expand its mission to secure agency programs and assets and, by extension, require modification to its information security requirements and practices. It is important that a change in an organization’s internal requirements is checked against external federal requirements as, for example, a change to an information system’s security posture may alter its subsequent reporting requirements.

To facilitate ongoing monitoring, the SAISO and other officials can compare and correlate a variety of real-time and static information available from a number of ongoing activities within and outside of their programs. FISMA requires agencies to perform an annual assessment of their information security programs and report information security performance measures quarterly and annually. The intent of these reporting requirements is to facilitate close to real-time assessment and monitoring of information security program activities. Ongoing monitoring combines the use of existing data to oversee a security program, and typically occurs throughout all phases of the program life cycle. Agencies can use a variety of data originating from the ongoing information security program activities to monitor performance of programs under their purview, including POA&Ms, performance measurements and metrics, continuous assessment, configuration management and control, network monitoring, and incident statistics.

Table 2-1 provides a broad overview of key ongoing activities that can assist in monitoring and improving an agency’s information governance activities.

Table 2-1. Ongoing Monitoring Activities

There are many diverse, and sometimes conflicting, priorities an organization must account for in meeting information security governance requirements. These criteria present challenges an organization is likely to face in its efforts to establish information security governance.

Some of the most common challenges include:

Information security governance provides a framework for establishing and maintaining an information security program that will evolve with the organization it supports. The following list is a summary of good information security governance practices that are critical for ensuring the security of enterprise information assets:

www.csrc.nist.gov

www.gao.gov

www.whitehouse.gov/omb/

Public Law 107-347 [H.R. 2458], The E-Government Act of 2002, Title III of this Act is the Federal Information Security Management Act of 2002 (FISMA), December 17, 2002.

Office of Management and Budget Circular A-130, Management of Federal Information Resources, November 2000.

Chapter 3

The system development life cycle (SDLC) is the overall process of developing, implementing, and retiring information systems through a multistep process from initiation, analysis, design, implementation, and maintenance to disposal. There are many different SDLC models and methodologies, but each generally consists of a series of defined steps or phases.

Various SDLC methodologies have been developed to guide the processes involved, and some methods work better than others for specific types of projects. Regardless of the type of the life cycle used by an organization, information security must be integrated into the SDLC to ensure appropriate protection for the information that the system is intended to transmit, process, and store. Security is most useful and cost-effective when such integration begins with a system development or integration project initiation, and is continued throughout the SDLC through system disposal. A number of federal laws and directives require integrating security into the SDLC, including the Federal Information Security Management Act (FISMA) and Office of Management and Budget (OMB) Circular A-130, Appendix III.

This section provides a general overview of security integration into the SDLC and is not intended to prescribe any particular model or methodology. Each phase of the SDLC includes a minimum set of information security-related activities required to effectively incorporate security into a system. An organization can either use a generic SDLC as described in this section or develop a tailored SDLC that meets its specific needs. National Institute of Standards and Technology (NIST) Special Publication (SP) 800-64 Rev. 1, Security Considerations in the Information System Development Life Cycle, presents a framework for incorporating security into all phases of the SDLC, depicted in Figure 3-1, to ensure the selection, acquisition, and use of appropriate and cost-effective security controls.¹⁹

All information technology (IT) projects have a starting point, what is commonly referred to as the initiation phase. During the initiation phase, the organization establishes the need for a particular system and documents its purpose. The information to be processed, transmitted, or stored is typically evaluated, as well as who is required access to such information and how (in high-level terms). In addition, it is often determined whether the project will be an independent information system or a component of an already-defined system. A preliminary risk assessment is typically conducted in this phase, and security planning documents are initiated (system security plan).

Figure 3-1. System Development Life Cycle

Once these tasks have been completed and a need has been recognized for a new or enhanced IT product or service, several processes must take place before the project is approved, to include clearly defining project goals and defining high-level information security requirements. Typically, during this phase, the organization defines high-level information security policy requirements as well as the enterprise security system architecture.

During this phase, the system is designed, purchased, programmed, developed, or otherwise constructed. This phase often consists of other defined cycles, such as the system development cycle or the acquisition cycle.

During the first part of the development/acquisition phase, the organization should simultaneously define the system’s security and functional requirements. These requirements can be expressed as technical features (e.g., access control), assurances (e.g., background checks for system developers), or operational practices (e.g., awareness and training). During the last part of this phase, the organization should perform developmental testing of the technical and security features/functions to ensure that they perform as intended prior to launching the implementation and integration phase.

In the implementation phase, the organization configures and enables system security features, tests the functionality of these features, installs or implements the system, and finally, obtains a formal authorization to operate the system. Design reviews and system tests should be performed before placing the system into operation to ensure that it meets all required security specifications. In addition, if new controls are added to the application or the support system, additional acceptance tests of those new controls must be performed. This approach ensures that new controls meet security specifications and do not conflict with or invalidate existing controls. The results of the design reviews and system tests should be fully documented, updated as new reviews or tests are performed, and maintained in the official organization records.

An effective security program demands comprehensive and continuous understanding of program and system weaknesses. In the operation and maintenance phase, systems and products are in place and operating, enhancements and/or modifications to the system are developed and tested, and hardware and/or software is added or replaced. During this phase, the organization should continuously monitor performance of the system to ensure that it is consistent with preestablished user and security requirements, and needed system modifications are incorporated.

For configuration management (CM) and control, it is important to document the proposed or actual changes in the security plan of the system. Information systems are typically in a constant state of evolution with upgrades to hardware, software, firmware, and possible modifications to the surrounding environment where the system resides. Documenting information system changes and assessing the potential impact of these changes on the security of a system is an essential part of continuous monitoring, and key to avoiding a lapse in the system security accreditation.²⁰

Monitoring security controls helps to identify potential security-related problems in the information system that are not identified during the security impact analysis, which is conducted as part of the CM and control process.

The disposal phase of the system life cycle refers to the process of preserving (if applicable) and discarding system information, hardware, and software. This step is extremely important because during this phase, information, hardware, and software are moved to another system, archived, discarded, or destroyed. If performed improperly, the disposal phase can result in the unauthorized disclosure of sensitive data. When archiving information, organizations should consider the need and methods for future retrieval. While electronic information is relatively easy to store and retrieve, problems can arise if the technology used to create the records is no longer available in the future as a result of obsolescence or incompatibility with new technologies. Additionally, the organization should consider what measures must be taken for the future use of data that has been encrypted, such as taking appropriate steps to ensure the secure long-term storage of cryptographic keys. It is equally important to consider legal requirements for records retention when disposing of information systems. For federal systems, system management officials should consult with their office responsible for retaining and archiving federal records.

The removal of information from a storage medium, such as a hard disk or tape, is called sanitization. There are four categories of media sanitization: disposal, clearing, purging, and destroying.²¹ Because different kinds of sanitization provide different levels of information protection, organizations should use information security requirements as a guide for selecting the sanitization method that best suits their needs.

Security activities must be integrated into the SDLC to ensure proper identification, design, integration, and maintenance of applicable security controls throughout an information system’s life cycle as summarized in Table 3-1.

Table 3-1. Security Activities in the SDLC

Website: www.csrc.nist.gov

References: Public Law 107-347 [H.R. 2458], The E-Government Act of 2002, Title III of this Act is the Federal Information Security Management Act of 2002 (FISMA), December 17, 2002.

Office of Management and Budget Circular A-130, Management of Federal Information Resources, November 2000.

Federal Information Processing Standard 199, Standards for Security Categorization of Federal Information and Information Systems, February 2004.

Federal Information Processing Standard 200, Minimum Security Requirements for Federal Information and Information Systems, March 2006.

National Institute of Standards and Technology Special Publication 800-18 Revision 1, Guide for Developing Security Plans for Federal Information Systems, February 2006.

National Institute of Standards and Technology Special Publication 800-30, Risk Management Guide for Information Technology Systems, July 2002.

National Institute of Standards and Technology Special Publication 800-37, Guide for the Security Certification and Accreditation of Federal Information System, May 2004.

National Institute of Standards and Technology Special Publication 800-53, Recommended Security Controls for Federal Information Systems, February 2005.

National Institute of Standards and Technology Special Publication 800-60, Guide for Mapping Types of Information and Information Systems to Security Categories, June 2004.

National Institute of Standards and Technology Special Publication 800-64, Security Considerations in the Information System Development Life Cycle, Rev. 1, June 2004.

National Institute of Standards and Technology Special Publication 800-65, Integrating Security into the Capital Planning and Investment Control Process, January 2005.

National Institute of Standards and Technology Special Publication 800-88, Guidelines for Media Sanitization, September 2006.

Chapter 4

The security awareness and training program is a critical component of the information security program. It is the vehicle for disseminating security information that the workforce, including managers, need to do their jobs. In terms of the total security solution, the importance of the workforce in achieving information security goals and the importance of training as a countermeasure cannot be overstated. Establishing and maintaining a robust and relevant information security awareness and training program as part of the overall information security program is the primary conduit for providing the workforce with the information and tools needed to protect an agency’s vital information resources. These programs will ensure that personnel at all levels of the organization understand their information security responsibilities to properly use and protect the information and resources entrusted to them. Agencies that continually train their workforce in organizational security policy and role-based security responsibilities will have a higher rate of success in protecting information.

As cited in audit reports, periodicals, and conference presentations, people are arguably the weakest element in the security formula that is used to secure systems and networks. The people factor, not technology, is a critical factor that is often overlooked in the security equation. It is for this reason that the Federal Information Security Management Act (FISMA) and the Office of Personnel Management (OPM) have mandated that more and better attention must be devoted to awareness activities and role-based training, as they are the only security controls that can minimize the inherent risk that results from the people who use, manage, operate, and maintain information systems and networks.³¹ Robust and enterprise-wide awareness and training programs are needed to address this growing concern.

National Institute of Standards and Technology (NIST) Special Publication (SP) 800-50, Building an Information Technology Security Awareness and Training Program, provides guidelines that can help federal departments and agencies meet their information security awareness and training responsibilities defined in FISMA and in Office of Management and Budget (OMB) policy. The publication identifies models for building and maintaining a comprehensive awareness and training program as part of an organization’s information security program.

NIST SP 800-50 is a companion publication to NIST SP 800-16, Information Technology Security Training Requirements: A Role- and Performance-Based Model. NIST SP 800-50 works at a higher strategic level and discusses how to build and maintain an information security awareness and training program; NIST SP 800-16 addresses a more tactical level and discusses the awareness-training-education continuum, role-based training, and course content considerations. The learning continuum is shown in Figure 4-1.

Figure 4-1. The IT Security Learning Continuum

All users have information security responsibilities. FISMA mandates that all users complete “awareness training,” though NIST publications call this “awareness.” FISMA also tasks agencies with identifying and training those individuals who have significant responsibilities for information security, a requirement formalized by OPM’s information security awareness and training policy promulgated in June 2004. OPM’s policy strengthens the FISMA requirement for user exposure to “awareness training” by adding “at least annually,” and requires agencies to provide “role-specific training” in accordance with NIST guidance. Although there is no federal mandate for formal education (provided by colleges or universities) and certification of information security professionals, they are mentioned in this section since some agencies include them as part of a comprehensive training solution for federal employees.

An agency’s information security program policy should contain a clear and distinct section devoted to agency-wide requirements for the awareness and training program. Although security awareness and training is generally referred to as “a” program, many organizations consider awareness and training to be two distinct functions, each with separate purposes, goals, and approaches. Proper implementation of these components (with consideration of options like education and professional certification) promotes professional development, which leads to a high-performance workforce.

Requirements for the security awareness and training program should be documented in the enterprise-level policy and should include:

Security awareness is a blended solution of activities that promote security, establish accountability, and inform the workforce of security news. Awareness seeks to focus an individual’s attention on an issue or a set of issues. Awareness is a program that continually pushes the security message to users in a variety of formats.

An awareness program includes a variety of tools, communication, outreach, and metrics development.

Information security training strives to produce relevant and needed security knowledge and skills within the workforce. Training supports competency development and helps personnel understand and learn how to perform their security role. The most important difference between training and awareness is that training seeks to teach skills that allow a person to perform a specific function, while awareness seeks to focus an individual’s attention on an issue or a set of issues.

Role-based training provides security courses that are tailored to the specific needs of each group of people who have been identified as having significant responsibilities for information security in their organization. NIST SP 800-16 provides guidance for establishing role- and performance-based security training programs.

Education integrates all of the security skills and competencies of the various functional specialties into a common body of knowledge and adds a multidisciplinary study of concepts, issues, and principles (technological and social). Information security education strives to produce information security specialists and professionals who are capable of vision and proactive response. Several colleges and universities provide academic programs to support the information security needs of the public and private sectors. Many of these schools partner with the federal sector to accomplish research and development tasks to improve information security.

In response to the growing demand for information security personnel within federal agencies, there has been a movement toward increased professional standards for federal and contracted security personnel. This “professionalization” integrates training, education, and experience with an assessment mechanism to validate knowledge and skills, resulting in the “certification” of a predefined level of competence. The relationship among these professional development elements is illustrated in Figure 4-2.

Figure 4-2. Elements of Professional Development

It should be noted that there are distinct differences among certifications that are offered by a variety of organizations. Primarily, one will encounter certificates of completion, certifications awarded by an industry and/or vendors, and graduate-level certificates awarded by academic institutions:

The development of an information security awareness and training program involves three major steps:

Even a small amount of information security awareness and training can go a long way toward improving the security posture of, and vigilance within, an organization.

Awareness and training programs must be designed with the mission of the agency in mind. The awareness and training program must support the business needs of the organization and be relevant to the organization’s culture and information technology architecture. The most successful programs are those that users feel are relevant to the subject matter and issues presented.

Designing an information security awareness and training program answers the question “What is our plan for developing and implementing awareness and training opportunities that are compliant with existing directives?” In the design step of the program, the agency’s awareness and training needs are identified, an effective agency-wide awareness and training plan is developed, organizational buy-in is sought and secured, and priorities are established.

Once the awareness and training program has been designed, supporting material can be developed. Material should be developed with the following in mind:

In both cases, the focus should be on specific material that the participants should integrate into their jobs. Attendees will pay attention and incorporate what they see or hear in a session if they feel that the material was developed specifically for them. Any presentation that feels so impersonal and general that it could be given to any audience, will be filed away as just another of the annual “we’re here because we have to be here” sessions. An awareness and training program can be effective, however, if the material is interesting, current, and relevant.

The awareness audience must include all users in an organization. Users may include employees, contractors, foreign or domestic guest researchers, other agency personnel, visitors, guests, and other collaborators or associates requiring access. The message to be spread through an awareness program, or campaign, should make all individuals aware of their commonly shared information security responsibilities.

On the other hand, the message in a training class is directed at a specific audience. The message in training material should include everything related to security that attendees need to know in order to perform their jobs. Training material is usually far more in-depth than material used in an awareness session or campaign.

An information security awareness and training program should be implemented only after a needs assessment has been conducted, a strategy has been developed, an awareness and training program plan for implementing that strategy has been completed, and awareness and training material has been developed.

The program’s implementation must be fully explained to the organization to achieve support for its implementation and commitment of necessary resources. This explanation includes expectations of agency management and staff support, as well as expected results of the program and benefits to the organization. Funding issues must also be addressed. For example, agency managers must know if the cost to implement the awareness and training program will be totally funded by the chief information officer (CIO) or information security program budget, or if their budgets will be impacted to cover their share of the expense of implementing the program. It is essential that everyone involved in the implementation of the program understand their roles and responsibilities. In addition, schedules and completion requirements must be communicated.

Once the plan for implementing the awareness and training program has been explained to (and accepted by) agency management, the implementation can begin. Since there are several ways to present and disseminate awareness and training material throughout an organization, agencies should tailor their implementation to the size, organization, and complexity of their enterprise.³³

An organization’s information security awareness and training program can quickly become obsolete if sufficient attention is not paid to technology advancements, IT infrastructure changes, organizational changes, and shifts in organizational mission and priorities. CIOs and senior agency information security officers (SAISOs) need to be cognizant of this potential problem and incorporate mechanisms into their strategy to ensure that the program continues to be relevant and compliant with overall objectives. Continuous improvement should always be the theme for security awareness and training initiatives, as this is one area where “you can never do enough.” Efforts supporting this post-implementation feedback loop should be developed in consideration of the security organization’s overall ongoing performance measures program.³⁴

Once the program has been implemented, processes must be put in place to monitor compliance and effectiveness. An automated tracking system should be designed to capture key information on program activity (e.g., courses, dates, audience, costs, sources). The tracking system should capture this data at an agency level, so it can be used to provide enterprise-wide analysis and reporting regarding awareness, training, and education initiatives.

Tracking compliance involves assessing the status of the program as indicated by the database information and mapping it to standards established by the agency. Reports can be generated and used to identify gaps or problems. Corrective action and necessary follow-up can then be taken. This follow-up may take the form of formal reminders to management; additional awareness, training, or education offerings; and/or the establishment of a corrective plan with scheduled completion dates.

Formal evaluation and feedback mechanisms are critical components of any security awareness and training program. Continuous improvement cannot occur without a good sense of how the existing program is working. In addition, the feedback mechanism must be designed to address objectives initially established for the program. Once the baseline requirements have been solidified, a feedback strategy can be designed and implemented. Various evaluation and feedback mechanisms that can be used to update the awareness and training program plan include surveys, evaluation forms, independent observation, status reports, interviews, focus groups, technology shifts, and/or benchmarking.

A feedback strategy should incorporate elements that address quality, scope, deployment method (e.g., Web-based, onsite, offsite), level of difficulty, ease of use, duration of session, relevancy, currency, and suggestions for modification.

Metrics are essential to feedback and evaluation. They can be used to:

It is necessary to ensure that the program, as structured, continues to evolve as new technology and associated security issues emerge. Training needs will shift as new skills and capabilities become necessary to respond to new architectural and technology changes. A change in the organizational mission and/or objectives can also influence ideas on how best to design training solutions and content. Emerging issues, such as homeland defense, will also impact the nature and extent of security awareness and training activities necessary to keep users informed and/or trained about the latest threats, vulnerabilities, and countermeasures. New laws and court decisions may also impact agency policy that, in turn, may affect the development and/or implementation of awareness and training material. Finally, as security policies evolve, awareness and training material should reflect these changes.

CIOs, program officials, and SAISOs should be primary advocates for awareness, training, education, and professionalization. Securing an organization’s information and infrastructure is a team effort, requiring the dedication of capable individuals to carry out their assigned security roles within the organization. Listed below are some key indicators to gauge the support for, and acceptance of, the program:

Website: www.csrc.nist.gov

References: Public Law 107-347 [H.R. 2458], The E-Government Act of 2002, Title III of this Act is the Federal Information Security Management Act of 2002 (FISMA), December 17, 2002.

Office of Personnel Management, 5 Code of Federal Regulations, Subpart C, Employees Responsible for the Management or Use of Federal Computer Systems, Section 930.301, Computer Security Training Program.

National Institute of Standards and Technology Special Publication 800-16, Information Technology Security Training Requirements: A Role- and Performance-Based Model, April 1998.

National Institute of Standards and Technology Special Publication 800-50, Building an Information Technology Security Awareness and Training Program, October 2003.

National Institute of Standards and Technology Special Publication 800-55, Security Metrics Guide for Information Technology Systems, July 2003.

Increased competition for limited federal budgets and resources requires that agencies allocate available funding toward their highest-priority information security investments to afford the agency and its systems and data, the appropriate degree of security for their needs. This goal can be achieved through a formal enterprise capital planning and investment control (CPIC) process designed to facilitate and control the expenditure of agency funds. The Federal Information Security Management Act (FISMA) and other existing federal regulations charge federal agencies with integrating information security activities and the capital planning and investment control process. The practices discussed in this chapter are designed to help security practitioners and managers identify funding needs to secure systems and provide strategies for obtaining the necessary funding.

Implementation of information security within the federal government is guided by a combination of legislation, rules and regulations, and agency-specific policies. FISMA is the overarching information security legislation for federal information systems. Signed into law in 2002, FISMA:

As Figure 5-1 illustrates, the corrective action and cost information contained in the POA&M serve as inputs to the Exhibit 300s and are then rolled into the Exhibit

To facilitate effective implementation of OMB capital planning and NIST security requirements, the Government Accountability Office (GAO) offers a Select-Control-Evaluate investment life-cycle model as a best practices approach to investment management. While not compulsory, the framework articulates key activities for managing IT investments throughout the life cycle. The three phases ensure that investment management practices, including security, are disciplined and thorough throughout each phase of the investment life cycle. Figure 5-1 illustrates the three phases.

The Select phase refers to activities involved with assessing and prioritizing current and proposed IT projects based on mission needs and improvement priorities, and then creates a portfolio of IT projects to address these needs and priorities. Typical Select phase activities include screening new projects; analyzing and ranking all projects based on benefit, cost, and risk criteria; selecting a portfolio of projects; and establishing project review schedules.

The Control phase refers to activities designated to monitor the investment during its operational phase to determine whether the investment is within the cost and schedule milestones established at the beginning of the investment life cycle. Typical processes involved in the Control phase include using a set of performance measures to monitor the developmental progress for each IT project to enable early problem identification and resolution.

The Evaluate phase refers to determining the efficacy of the investment, answering the question, “Did the investment achieve the desired results and performance goals identified during the Select phase?”

Figure 5-1. Select-Control-Evaluate Investment Life Cycle

Figure 5-1 illustrates the relationship between security drivers in the GAO Select-Control-Evaluate investment lifecycle and the System Development Life Cycle (SDLC). During the Select phase, security drivers include assessment activities to ensure that IT security investments comply with security requirements. During the Control phase, investments are monitored through the use of security metrics to ensure that security controls are in place and operational, and that investments remain compliant with requirements. During the Evaluate phase, security drivers include self-assessment activities to ensure compliance and media sanitization efforts following removal from operation and prior to disposition.

National Institute of Standards and Technology (NIST) Special Publication (SP) 800-65, Integrating IT Security into the Capital Planning and Investment Control Process, provides a seven-step process, illustrated in Figure 5-2, for prioritizing security activities and corrective actions:

Management: prioritize agency-wide business cases against requirements and CIO priorities and determine investment portfolio.

Figure 5-2. Integrating Information Security into the CPIC Process

The following sections provide an overview of the integration of information security into the CPIC process to help ensure that corrective actions identified in the annual FISMA reporting process through POA&Ms are incorporated into the CPIC process to deliver maximum security in a cost-effective manner.

Integrating information security into the CPIC process requires input and collaboration across operating units and lines of business throughout the life cycle of technology investments. Figure 5-3 depicts a hierarchical approach to the CPIC process in which investment decisions are made at both the enterprise and operating-unit levels.

Figure 5-3. Notional IT Management Hierarchy

While specific practices for investment management can differ at the operating-unit level because of varying mission scopes, the process generally mirrors the process at the departmental level. The CIO formulates and articulates information security priorities to the organization to be considered within the context of all agency investments. Priorities may be based on agency mission and executive branch guidance such as the President’s Management Agenda (PMA), OMB guidance, or other external/internal priorities. Examples of security priorities include certifying and accrediting all systems or implementing public key infrastructure (PKI) throughout the enterprise. It is important to note that OMB/executive branch guidance or laws should be ranked highest among these priorities.

Once operating units finalize their IT portfolios and budget requests for the budget year, they forward their requests to the agency-level decision makers. At the agency level, several committees evaluate IT portfolios from the operating units as referenced in Figure 5-3, culminating in a review by the IRB. The IRB then decides on an agency-level IT portfolio and forwards recommendations to the agency head for review. Once the agency-level IT portfolio is approved by the agency head, the necessary Exhibit 300s and Exhibit 53 are forwarded to OMB for funding consideration.

Many different stakeholders, from information security, capital planning, and executive leadership areas, have key roles and make decisions on integrating information security into the CPIC process with the ultimate goal of forming a well-balanced IT portfolio. Involvement at the enterprise and operating-unit levels throughout the process allows agencies to ensure that CPIC and information security goals and objectives are met. Figure 5-4 identifies typical leading, supporting, or approving roles for each stakeholder as they apply to the integration of security into the CPIC process phases.

Figure 5-4. Roles and Responsibilities throughout the CPIC Process

The first step in integrating information security and the CPIC process is to assess the security baseline. The security baseline provides a snapshot of the agency’s compliance with baseline security requirements (BLSRs) and is instrumental in identifying information security strengths and weaknesses. The result of a security baseline analysis enables agency executives to evaluate their information security posture and identify areas for improvement. Agencies can identify their baselines for enterprise-level and system-level investments. System-level investments are those security investments designed to strengthen a discrete system’s security posture, such as strengthening password controls or testing a contingency plan for a particular system. Enterprise-level investments are those security investments that are ubiquitous across the agency and will improve the overall agency’s security posture, such as the acquisition of an enterprise-wide firewall or intrusion detection system (IDS).

NIST SP 800-55, Security Metrics Guide for Information Technology Systems, provides guidance on developing and implementing an information security metrics program. Metrics can provide baseline compliance percentages that indicate the existence of adequate security controls, highlight current weaknesses, and identify gaps between actual and desired implementation status of information security controls. The goal of the security baseline establishment exercise is to provide agency officials an understanding of the strengths, weaknesses, and vulnerabilities that exist within the agency’s security controls and to help identify investments that are required to mitigate weaknesses. The resulting vulnerabilities and weaknesses then serve as inputs into the next step of the CPIC process: identifying prioritization criteria.

Available funding does not always allow all security needs identified in the baseline assessment to be addressed immediately. Therefore, requirements must be prioritized to address the most pressing security investment needs first. Specific prioritization criteria will vary from agency to agency depending on specific agency mission and goals and applicable legislation and regulations. Examples of information security priorities include:

A variety of taxonomies can be used to organize prioritization criteria, including FIPS 200 security control families or other agency-specific categories.

Once agency management and stakeholders agree on the prioritization of investments, the agency can begin the prioritizing process by rank-ordering requirements against the prioritization criteria. The objective of this activity is to fund first the most critical security investment. The next layer of funding should then be applied to the next critical security investment and so forth, until the security budget is entirely expended, or priorities met, whichever comes first.

Before conducting corrective action prioritization, the agency should allocate the funding necessary to mitigate significant deficiencies and other needs that obviously require attention. These initiatives should then be removed from the prioritization process to avoid duplication of effort.

After identifying the security baseline and prioritization criteria, an agency can prioritize corrective actions at two levels:

The prioritization methodology relies primarily on existing data sources and inputs. Specific data inputs for the two types of prioritization are highlighted in Table 5-1.

Table 5-1. Prioritization Data Inputs

Some of the data inputs need to be manipulated further to support the corrective action prioritization process:

Figure 5-5. Corrective Action Impact Calculation

After assembling process inputs, conduct the following four steps to complete the prioritization process:

Both enterprise- and system-level prioritization should be performed and then overlapped to ensure that appropriate agency priorities receive funding commensurate with their risk levels. Prioritization may be facilitated using a spreadsheet or a more sophisticated automation tool.⁴¹ Visualization of the prioritization may be used to facilitate the decision-making process.

Figure 5-6 demonstrates an example of a corrective action prioritization visualization approach using notional data. From a system-level perspective, Figure 5-6 plots system category along the vertical axis and corrective action impact along the horizontal axis. The notional agency systems are denoted as the small letters at the top of each quadrant. In this example, systems “N” and “F” were found to have category rankings of “high” and corrective action impacts of “great.”

Figure 5-6. Joint Prioritization with Costs

Drawn from the perspective of the enterprise, Figure 5-6 plots agency-determined security controls importance along the vertical axis and corrective action impact along the horizontal axis. The numbers (1-17) represent the seventeen NIST SP 800-53 security control areas used for this example. Security control area 12 ranked “high” in importance but had a “basic” corrective action impact.

The dollar figures in Figure 5-6 represent the total cost to implement all corrective actions within that cell. For example, looking at cell HG, it would cost the agency $85,961 to implement corrective actions for systems “N” and “F” and topic area “4.” After plotting all of its systems, the agency should perform executive validation of the placement of the various systems to ensure that stakeholders’ priorities are met.

Agency information security stakeholders should review the prioritization results to ensure that the prioritization is appropriate and given the opportunity to reprioritize their inputs if the results of the process are found to be unsatisfactory. Assuming the agency stakeholders agree that all prioritized corrective actions are appropriate, as displayed in Figure 5-6, the analysis can proceed accordingly. As indicated by the axes, the implementation of corrective actions should begin with cell HG and proceed diagonally down to cell LB to ensure that the agency implements the most cost-effective, high-impact corrective actions.

To continue with the example, assume the notional agency has a $2,000,000 budget to implement information security corrective actions. As Figure 5-6 demonstrates, adding the three highest priority cells together (HG, HA, and MG) brings a total of $891,775, which is nearly half of the corrective action budget. The agency would then move to the next tier of prioritization, or cells HB, MA, and LG. Totaling these cells yields a total of $503,350, which combined with the previous total from HG, HA, and MG, yields a running total of $1,395,125. With $604,875 remaining in the corrective action budget, the agency would proceed with prioritization into cells MB and LA. Totaling those two cells yields $2,619,505. Clearly, this total exceeds the remaining corrective action budget, so stakeholders will have to decide on how to allocate the remaining dollars. Should stakeholders determine that the corrective action impact order (G, A, B) is the driving factor, the corrective actions in cell LA will be implemented. If the stakeholders determine that the system and security control category (H, M, L) is the driving factor, the corrective actions from cell MB will be implemented until the remaining $604,875 is expended.⁴²

Once prioritizing against requirements is completed, operating units are poised to select their investments for the budget year and begin the process of requesting funding from OMB for the next year to implement the corrective actions and security controls.

The Exhibit 300 is the capture mechanism for all of the analyses and activities required for full internal review (e.g., IRB, CIO). More importantly, Exhibit 300 is the document that OMB uses to assess investments and ultimately make funding decisions, and therefore should be leveraged by agencies to clearly demonstrate the need for life cycle and annual funding requests. The Exhibit 300 is completed for new IT investments and is resubmitted annually for mixed life-cycle and steady-state investments. Operating units should evaluate their prioritized corrective actions and security controls identified during the prioritization process and determine whether the outputs need to be incorporated into an existing investment’s Exhibit 300 or whether they will need to create an independent Exhibit 300 for a new investment.

The IRB reviews and selects investments for the agency portfolio based on the Exhibit 300s forwarded by the operating units. Like the prioritization that occurs at the operating-unit level, the IRB typically uses strategic selection criteria to rank-order the investment pool and usually makes decisions based on agency mission and goals, not just on cost. While security is not the typical driving force behind portfolio management, it is a critical element in the investment strategy because it serves as a qualifier for receiving funding and as a business enabler for those functions which support the agency’s mission. After prioritizing and approving select Exhibit 300s, the IRB creates an investment portfolio request for review by OMB.

Following selection into the agency’s IT portfolio, the agency aggregates Exhibit 300s into the Exhibit 53. The Exhibit 53 provides an overview of the agency’s entire IT portfolio by listing every IT investment, life cycle, and budget-year cost information.

In addition to containing all investments with Exhibit 300s, the Exhibit 53 also contains other IT investments that do not have Exhibit 300s (e.g., legacy systems with costs below agency thresholds). OMB evaluates an agency’s Exhibit 53 and

Exhibit 300s and determines appropriate funding amounts for the budget year based on the justification articulated in the Exhibit 300s. Agencies then receive their budget year funding and must implement or maintain their investments throughout the year by applying allocated funding.

Exhibit 300 Information: http://www.whitehouse.gov/omb/circulars/a11/current_year/s300.pdf

www.csrc.nist.gov

Public Law 107-347 [H.R. 2458], The E-Government Act of 2002, Title III of this Act is the Federal Information Security Management Act of 2002 (FISMA), December 17, 2002.

Office of Management and Budget Circular A-130, Management of Federal Information Resources, November 2000.

Federal Information Processing Standard 199, Requirements for Security Categorization of Federal Information and Information Systems, February 2004.

Federal Information Processing Standard 200, Minimum Security Standards for Federal Information and Information Systems, March 2006.

National Institute of Standards and Technology Special Publication 800-18, Revision 1, Guide for Developing Security Plans for Federal Information Systems, February 2006.

National Institute of Standards and Technology Special Publication 800-53A, Guide for Assessing the Security Controls in Federal Information Systems (draft), April 2006.

National Institute of Standards and Technology Special Publication 800-37, Guide for the Security Certification and Accreditation of Federal Information Systems, May 2004.

National Institute of Standards and Technology Special Publication 800-53, Revision 1, Recommended Security Controls for Federal Information Systems, February 2006.

National Institute of Standards and Technology Special Publication 800-55, Security Metrics Guide for Information Technology Systems, July 2003.

National Institute of Standards and Technology Special Publication 800-60, Guide for Mapping Types of Information and Information Systems to Security Categories, June 2004.

National Institute of Standards and Technology Special Publication 800-65, Integrating Information Security into the Capital Planning and Investment Control Process, January 2005.

Office of Management and Budget Circular A-11, Preparation, Submission, and Execution of the Budget, 2003.

Chapter 6

A system interconnection is defined as the direct connection of two or more information systems for sharing data and other information resources. Organizations choose to interconnect their information systems for a variety of reasons based on their organizational needs. For example, they may interconnect information systems to exchange data, collaborate on joint projects, or securely store data and backup files.

An interconnection is a direct connection between one organization’s system with another system of the same or different organization through a mechanism by which they are joined (the “pipe” through which data is made available, exchanged, or passed one way only). The “pipe” may be a dedicated line that is owned by one of the organizations or is leased from a third party (e.g., Integrated Services Digital Network [ISDN], T1 or T3 line). Alternately, the systems may be connected over a public network (e.g., Internet) using a virtual private network (VPN).

Figure 6-1 depicts the concept of information system interconnection.

Figure 6-1. Information System Interconnection

The following are examples of interconnections:

Levels of system interconnection may vary. For example, some organizations may choose to establish a limited interconnection, whereby users are restricted to a single application or file location with rules governing access. Other organizations may establish a broader interconnection, enabling users to access multiple applications or databases. Still other organizations may establish an interconnection that permits full transparency and access across their respective enterprises.

Interconnecting information systems can expose the participating organizations to risk. If the interconnection is not properly designed, security failures could compromise the connected systems and their data. Similarly, if one of the connected systems is compromised, the interconnection could be used as a conduit to compromise the other system and its data.

Federal policy requires that federal agencies establish interconnection security agreements. Specifically, Office of Management and Budget (OMB) Circular A-130, Appendix III, requires that agencies obtain written management authority before connecting their information systems to other systems, based on a mutually acceptable level of risk. National Institute of Standards and Technology (NIST)

Special Publication (SP) 800-47, Security Guide for Interconnecting Information Technology Systems, provides detailed guidance on interconnecting information systems.

All federal agencies must explicitly address the subject of interconnecting information systems by establishing formal agreements that specify the technical and security requirements of the interconnection, define the responsibilities of the participating organizations, and specify the rules governing these interconnections. In addition to an A-130, Appendix III, requirement to obtain written management authority before interconnecting information systems, OMB recommends that agencies use NIST SP 800-47 to ensure compliance for connections to non-agency systems.⁴³

When organizations are properly managing interconnected systems, the added benefits include greater efficiency, centralized access to data, and greater functionality. The security controls of each of the interconnected systems should be evaluated and meet each other’s requirements for implementing security controls that are appropriate for the particular interconnection. Both organizations should specify their requirements regarding the security controls to be implemented in accordance with NIST FIPS 200, Minimum Security Requirements for Federal Information and Information Systems, and NIST SP 800-53, Recommended Security Controls for Federal Information Systems.

Each system involved in interconnection should be governed by an organization’s AO who has the authority to formally assume responsibility for operating a system at an acceptable level of risk. NIST SP 800-53 specifically defines an information systems connections control (specified in Table 6-1) that organizations are required to implement based on an information system’s security categorization. Since these categorizations and guidance apply to individual systems, agencies should carefully weigh the associated risks when systems differing in configuration or security controls are interconnected.

Table 6-1. NIST SP 800-53 Information System Connections Control

It is critical that both organizations maintain clear lines of communication to:

Identifying and implementing security controls is vital in protecting the confidentiality, integrity, and availability of the connected systems and the data that is transferred between the systems. If security controls are not in place or if they are configured improperly, the process of establishing the interconnection could expose the information systems to unauthorized access. Agencies should select applicable controls from NIST SP 800-53, based on the security categorization of the systems involved in the interconnection from FIPS 199, Standards for Security Categorization of Federal Information and Information Systems, and NIST SP 800-60, Guide for Mapping Types of Information and Information Systems to Security Categories. The security controls should be appropriately selected in consideration of the systems that will be connected and the environment in which the interconnection will operate.

One or both organizations should review the security controls for the interconnection at least annually or whenever a significant change occurs to either system or the operational environment. This review is intended to ensure that all controls are operating properly and still provide the requisite degree of system and data security.⁴⁴

NIST SP 800-47 details a four-phase “life-cycle management” approach for interconnecting information systems that emphasizes proper attention to information security:

The process of connecting two or more information systems begins with a planning phase, where the participating organizations perform preliminary activities and examine all relevant technical, security, and administrative issues. The planning phase ensures that the interconnection will operate as efficiently and securely as possible. Six steps are recommended for planning a system interconnection. Figure 6-2 illustrates the step-by-step process to plan a system interconnection. A more detailed process is described in the following paragraphs.

Figure 6-2. Steps to Plan a System Interconnection

Step 1: Establish a Joint Planning Team

The organizations should consider establishing a joint planning team composed of appropriate management and technical staff that includes program managers, system security officers, system administrators, network administrators, and system architects. The typical joint planning team is responsible for coordinating all aspects of the planning process and ensuring that it has both clear direction and sufficient resources. It also must have the commitment and support of the system and data owners, and other senior managers.

Step 2: Define the Business Case

Both organizations should work together to define the purpose of the interconnection, determine how it will support their mission requirements, and identify potential costs and risks. Defining the business case will establish the basis of the interconnection and facilitate the planning process. Factors that should be considered are estimated costs (e.g., staffing, equipment, facilities), expected benefits (e.g., improved efficiency), and potential risks (e.g., technical, legal, and financial).

Step 3: Perform Certification and Accreditation

Establishing an interconnection may represent a significant change to the connected systems. Before proceeding further, each organization should consider recertification and reaccreditation of its respective system(s) to verify that security protections remain acceptable. A full security certification and accreditation might not be necessary, however, if the system continues to operate within an acceptable level of risk; in that case, an abbreviated certification and accreditation would suffice.⁴⁵

Step 4: Determine Interconnection Requirements

The joint planning team should identify and examine all relevant technical, security, and administrative requirements surrounding the proposed interconnection.

Step 5: Document Interconnection Agreement

The interconnection security agreement (ISA) is a security document that specifies the technical and security requirements for establishing, operating, and maintaining the interconnection. It also supports the memorandum of understanding/memorandum of agreement (MOU/MOA) between the organizations. Specifically, the ISA documents the requirements for connecting the information systems, describes the security controls that will be used to protect the systems and data, contains a topological drawing of the interconnection, and provides a signature line.

The joint planning team should document an agreement governing the interconnection and the terms under which the organizations will abide. The agreement should be based on the team’s review of all relevant technical, security, and administrative requirements identified and examined in Step 4.

The MOU/MOA documents the terms and conditions for sharing data and information resources. It defines the purpose of the interconnection, identifies relevant authorities, specifies the responsibilities of each organization, defines the apportionment of costs, and identifies the timeline for terminating or reauthorizing the interconnection. In order to operate as an instrument that can be enforced by any agency that is a party to the interconnection, the MOU/MOA must be signed by an organization official, typically the authorizing official (AO). Lastly, because the ISA and the MOU/MOA may contain sensitive information, the original document and any copies should be protected appropriately against unauthorized disclosure or modification, damage, or destruction.

Step 6: Approve or Reject System Interconnection

The joint planning team should submit the ISA and the MOU/MOA to the AO of each organization, requesting approval for the interconnection. Upon receipt, the AOs should review the ISA, the MOU/MOA, and any other relevant documentation or activities. Organizations may combine ISAs and MOU/MOAs to simplify their management processes and reduce paperwork if these two documents fall within the purview of the same AO. When combining ISAs and MOU/MOAs, organizations must ensure that the contents and the intent of these two documents remain unaltered.

Based on this review, the AOs should decide on one of the following:

After the system interconnection is planned and approved, it can be implemented. The recommended steps for establishing the system interconnection are provided in Figure 6-3.

Figure 6-3. Recommended Steps for Establishing the Interconnection

Step 1: Develop an Implementation Plan

To ensure that the information systems are connected properly and securely, the joint planning team should develop a system interconnection implementation plan. At a minimum, the implementation plan should:

Step 2: Execute the Implementation Plan

After the implementation plan is developed, it should be reviewed and approved by senior members of the planning team and then executed. A list of recommended tasks for establishing an interconnection includes:

Procedures associated with each task should be described in the implementation plan.

Step 3: Activate the Interconnection

Both parties should activate the interconnection following the implementation plan execution. Each agency should closely and frequently examine the system’s audit logs and the types of assistance requested by the system’s users during this time to ensure that it operates properly and securely. Lastly, the appropriate agency should promptly document and address any security weaknesses or problems.

After the interconnection is established, the participating organizations must actively maintain it to ensure that it operates properly and securely. The following activities are recommended for maintaining the interconnection:

Phase-out may either be planned or it may be an emergency. Organizations may wish to restore some of the disconnections but not others.

An organization might have a variety of reasons to terminate an interconnection, for instance, changed business needs, cost considerations, or changes in system configuration. The decision to terminate the interconnection should be made by the system owner with the advice of appropriate management and technical staff. Before terminating the interconnection, the initiating party should provide written notice to the receiving party. In turn, the receiving party should acknowledge receipt of the notification. The notification should describe the reason(s) for the disconnection, provide the proposed timeline for the disconnection, and identify technical and management staff that will conduct the disconnection.

The schedule for terminating the interconnection should permit a reasonable time period for internal business planning so both sides can make appropriate arrangements. In addition, staff from both organizations should coordinate to determine the logistics of the disconnection and the disposition of shared data, including purging and overwriting sensitive data. The disconnection should be conducted when the impact on users is minimal. Following the disconnection, each organization should update its system security plan and related documents.

If one or both organizations detect an attack, intrusion attempt, or other contingency that exploits or jeopardizes the connected systems or their data, it might be necessary to abruptly terminate the interconnection without providing written notice to the other party. This extraordinary measure should be taken only in extreme circumstances and only after consultation with appropriate technical staff and senior management.

The decision to make the emergency disconnection should be made by the system owner (or a designated staff member) and implemented by technical staff. The system owner or designee should immediately notify the other party verbally and receive confirmation of the notification. Both parties should work together to isolate and investigate the incident, in accordance with incident response procedures. If necessary, law enforcement authorities should be notified, and evidence should be preserved.

The initiating party should provide a written notification to the other party in a timely manner (e.g., within five days). The notification should describe the nature of the incident, explain why and how the interconnection was terminated, and identify actions taken to isolate and investigate the incident. The notification should also specify when and under what conditions the interconnection may be restored, if appropriate.

Both organizations may choose to restore the system interconnection after it has been terminated. The decision to restore the interconnection should be based on the cause and duration of the disconnection. For example, if the interconnection was terminated because of an attack, intrusion, or other contingency, both parties should implement appropriate countermeasures to prevent a recurrence of the problem. If necessary, they also should modify the ISA and MOU/MOA to address issues requiring attention. Alternately, if the interconnection has been terminated for more than 90 days, each party should perform a risk assessment on its respective system and reexamine all relevant planning and implementation requirements, including developing a new ISA and MOU/MOA.

Sample MOU/MOA and ISA Checklist follow.

Annex 6.A Sample MOU/MOA

This annex provides a sample MOU/MOA template that agencies can use as a starting point for developing their own MOU/MOAs. This sample does not cover all possible scenarios and should be used as an example only.

SUPERSEDES: (None or document title and date)

INTRODUCTION The purpose of this memorandum is to establish a management agreement between “Organization A” and “Organization B” regarding the development, management, operation, and security of a connection between "System A," owned by Organization A, and "System B,” owned by Organization B. This agreement will govern the relationship between Organization A and Organization B, including designated managerial and technical staff, in the absence of a common management authority.

AUTHORITY The authority for this agreement is based on "Proclamation A" issued by the Agency Head on (date).

BACKGROUND It is the intent of both parties to this agreement to interconnect the following information technology (IT) systems to exchange data between "ABC database" and "XYZ database." Organization A requires the use of Organization B's ABC database, and Organization B requires the use of Organization A's XYZ database, as approved and directed by the Agency Head in Proclamation A. The expected benefit of the interconnection is to expedite the processing of data associated with "Project R" within prescribed timelines. Each information system is described below:

COMMUNICATIONS

Frequent formal communications are essential to ensure the successful management and operation of the interconnection. The parties agree to maintain open lines of communication between designated staff at both the managerial and technical levels. All communications described herein must be conducted in writing unless otherwise noted. The owners of System A and System B agree to designate and provide contact information for technical leads for their respective system, and to facilitate direct contacts between technical leads to support the management and operation of the interconnection. To safeguard the confidentiality, integrity, and availability of the connected systems and the data they store, process, and transmit, the parties agree to provide notice of specific events within the time frames indicated below:

INTERCONNECTION SECURITY AGREEMENT

The technical details of the interconnection will be documented in an Interconnection Security Agreement (ISA). The parties agree to work together to develop the ISA, which must be signed by both parties before the interconnection is activated. Proposed changes to either system or the interconnecting medium will be reviewed and evaluated to determine the potential impact on the interconnection. The ISA will be renegotiated before changes are implemented. Signatories to the ISA shall be the AO for each system.

SECURITY

Both parties agree to work together to ensure the joint security of the connected systems and the data they store, process, and transmit, as specified in the ISA. Based on National Institute of Standards and Technology Special Publication 800-53, Recommended Security Controls for Federal Information Systems, both parties should authorize all connections from the information system to other information systems outside of that accreditation boundary and monitor and control the system interconnections on an ongoing basis. Each party should identify security controls that apply to the interconnection based on each system’s information security categorization and impact level and agree on a mutual set of applicable controls. Each party certifies that its respective system is designed, managed, and operated in compliance with all relevant federal laws, regulations, and policies, and will ensure that appropriate security controls are maintained throughout the life of this MOU/MOA.

PRIVACY REQUIREMENTS

Both parties agree to examine privacy issues related to data that will be exchanged or passed over the interconnection and determine whether such use is restricted under current statutes, regulations, or policies. Examples of data that might be restricted include personally identifiable information such as names and social security numbers, or confidential business information such as contractor bid rates and trade secrets. Each party should consult with its Privacy Officer or Legal Counsel to determine whether such information may be shared or transferred. Permission to exchange or transfer data should be documented, along with a commitment to protect such data.

COST CONSIDERATIONS

Both parties agree to equally share the costs of the interconnecting mechanism and/or media, but no such expenditures or financial commitments shall be made without the written concurrence of both parties. Modifications to either system that are necessary to support the interconnection are the responsibility of the respective system owners’ organization.

TIMELINE

This agreement will remain in effect for one (1) year after the last date on either signature in the signature block below. After one (1) year, this agreement will expire without further action. If the parties wish to extend this agreement, they may do so by reviewing, updating, and reauthorizing this agreement. The newly signed agreement should explicitly supersede this agreement, which should be referenced by title and date. If one or both of the parties wish to terminate this agreement prematurely, they may do so upon 30 days' advanced notice or in the event of a security incident that necessitates an immediate response.

I agree to the terms of this Memorandum of Understanding / Memorandum of Agreement.

(Organization A Official)

(Signature Date)

(Organization B Official)

(Signature Date)

Annex 6.B ISA Checklist

This annex provides a generic checklist that agencies may use in developing their ISAs to ensure that they have discussed requirements covered in this section.

Website: www.csrc.nist.gov

References: Federal Information Processing Standard 199, Standards for Security Categorization of Federal Information and Information Systems, February 2004.

Federal Information Processing Standard 200, Minimum Security Requirements for Federal Information and Information Systems, March 2006.

National Institute of Standards and Technology, Information Technology Laboratory (ITL) Bulletin: Secure Interconnections for Information Technology Systems, February 2003.

National Institute of Standards and Technology Special Publication 800-30, Risk Management Guide for Information Technology Systems, July 2002.

National Institute of Standards and Technology Special Publication 800-37, Guide for the Security Certification and Accreditation of Federal Information Systems, May 2004.

National Institute of Standards and Technology Special Publication 800-42, Guidelines on Network Security Testing, October 2003.

National Institute of Standards and Technology Special Publication 800-47, Security Guide for Interconnecting Information Technology Systems, August 2002.

National Institute of Standards and Technology Special Publication 800-53, Revision 1, Recommended Security Controls for Federal Information System, February 2006.

National Institute of Standards and Technology Special Publication 800-60, Guide for Mapping Types of Information and Information Systems to Security Categories, June 2004.

Chapter 7

A performance measures program provides numerous organizational and financial benefits to federal agencies. Agencies can develop information security metrics that measure the effectiveness of their security program, and provide data to be analyzed and used by program managers and system owners to isolate problems, justify investment requests, and target funds specifically to the areas in need of improvement. By using metrics to target security investments, agencies can get the best value from available resources. The typical information performance management program consists of four interdependent components: senior management support, security policies and procedures, quantifiable performance metrics, and analyses.

Strong senior management support establishes a focus on security within the highest levels of the organization. Without a solid foundation (e.g., proactive support of those persons in positions that control information resources), the effectiveness of the security metrics program can fail when pressured by politics and budget limitations. The second component of an effective security metrics program is practical security policies and procedures backed by the authority necessary to enforce compliance. Metrics are not easily obtainable in the absence of policies and procedures. The third component is developing and establishing quantifiable performance metrics that are designed to capture and provide meaningful performance data. To provide meaningful data, quantifiable security metrics must be based on information security performance goals and objectives, and be easily obtainable, repeatable, relevant, useful, and measurable. Finally, the security metrics program itself must emphasize consistent, periodic analysis of the metrics data. The results of this analysis are used to apply lessons learned, improve the effectiveness of existing security controls, and plan future controls to meet new security requirements as they occur. Accurate data collection must be a priority with stakeholders and users if the collected data is to be meaningful to the management and improvement of the overall security program.

A number of existing laws, rules, and regulations cite information technology (IT) performance measurement in general and information security performance measurement in particular, as requirements. These laws include the Clinger-Cohen Act, Government Performance and Results Act (GPRA), Government Paperwork Elimination Act (GPEA), and the Federal Information Security Management Act (FISMA).

National Institute of Standards and Technology (NIST) Special Publication (SP) 800-55, Security Metrics Guide for Information Technology Systems, provides guidance on how an organization, by using metrics, identifies the adequacy of in-place security controls, policies, and procedures. It provides an approach to help management decide where to invest in additional security protection resources or how to identify and evaluate nonproductive controls. It explains the metrics development and implementation process and how it can also be used to adequately justify security control investments. The results of an effective metrics program can provide useful data for directing the allocation of information security resources and should simplify the preparation of performance-related reports.

Fiscal constraints and market conditions compel government and industry to operate on reduced budgets. In such an environment, it is difficult to justify broad investments in the information security infrastructure. Historically, arguments for investing in specific areas of information security lack detail and specificity and fail to adequately mitigate specific system risk. Information security metrics can facilitate the capital planning and investment control (CPIC) process by providing quantifiable information for business case development.⁴⁶ Information security metrics can also assist with determining the effectiveness of implemented information security processes, procedures, and controls by relating results of information security activities (e.g., incident data, revenue lost to cyber attacks) to the respective requirements and to information security investments.

Departments and agencies can also demonstrate compliance with applicable laws, such as FISMA, rules, and regulations by implementing and maintaining an information security metrics program as described in this handbook. Information security metrics will assist in satisfying the annual FISMA reporting requirement by providing an infrastructure for organized data collection, analysis, and reporting. Information security metrics can also be used as input into the Government Accountability Office (GAO) and Inspector General (IG) audits.

Metrics are tools that support decision making. Like experience, external mandates, and strategies, metrics are one element of a manager’s toolkit for making and substantiating decisions. Metrics are used to answer three basic questions:

Two processes guide the establishment and operation of an information security metrics program: metrics development and metrics implementation. The metrics development process establishes the initial set of metrics and selection of the metrics subset appropriate for an organization at a given time. The metrics program implementation process operates a metrics program that is iterative by nature and ensures that appropriate aspects of information security are measured for a specific time period.

Figure 7-1 illustrates the place of information security metrics within a larger organizational context and demonstrates that information security metrics can be used to progressively measure implementation, efficiency, effectiveness, and the business impact of information security activities within organizations or for specific systems.

Figure 7-1. Information Security Metrics Development Process

The information security metrics development process consists of two major activities:

The process steps do not need to be sequential. Rather, the process illustrated in Figure 7-1 provides a framework for thinking about metrics and aids in identifying metrics to be developed for each system. The type of metric depends on where the system is within its life cycle and on the maturity of the information system security program. This framework facilitates tailoring metrics to a specific organization and to the different stakeholder groups present within each organization.

Phases 5, 6, and 7, depicted in Figure 7-1, involve developing metrics that measure process implementation, effectiveness and efficiency, and mission impact. The specific aspect of information security that metrics will focus on at any given point will depend on information security program maturity. Implementation evidence, required to prove higher levels of effectiveness, will change from establishing existence of policy and procedures to quantifying implementation of these policies and procedures, then to quantifying results of implementation of policies and procedures, and ultimately to identifying the impact of implementation on the organization’s mission.

Based on existing policies and procedures, the universe of possible metrics can be prohibitively large; therefore, agencies should prioritize metrics to ensure that the final set selected for initial implementation has the following attributes:

Metrics can be derived from existing data sources, including security certification and accreditation, security assessments, plan of action and milestones (POA&M), incident statistics, and agency-initiated or independent reviews.⁴⁷ Agencies may decide to use a weighting scale to differentiate the importance of selected metrics and to ensure that the results accurately reflect existing security program priorities. This process would involve assigning values to each metric based on the importance of a metric in the context of the overall security program. Metrics weighting should be based on the overall risk mitigation goals, is likely to reflect higher criticality of department-level initiatives versus smaller-scale initiatives, and is a useful tool that facilitates integration of information security into the departmental capital planning process.

A phased approach may be required to identify short-, mid-, and long-term metrics in which the implementation time frame depends on a combination of system-level effectiveness, metric priority, data availability, and process stability. Once applicable metrics that contain the qualities described above are identified, they will need to be documented with supporting detail, including frequency of data collection, data source, formula for calculation, implementation evidence for measured activity, and a guide for metric data interpretation. Other information about each metric can be defined based on an organization’s processing and business requirements.

Information security metrics should be used for monitoring information security control performance and initiating performance improvement actions. This iterative process consists of six phases, depicted in Figure 7-2.

Figure 7-2. Information Security Metrics Program Implementation Process

Phase 1 of the process, Prepare for Data Collection, involves activities that are key for establishing a comprehensive information security metrics program. These activities include the information security metrics identification, definition, development, and selection activities, and developing a metrics program implementation plan.

After the metrics have been identified, specific implementation steps should be defined on how to collect, analyze, and report the metrics. These steps should be documented in the metrics program implementation plan. The following items may be included in the plan: