NIST SP 800-47 Rev. 1 日本語訳

NIST Special Publication 800-47

Revision 1

Kelley Dempsey Victoria Yan Pillitteri Andrew Regenscheid

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-47r1

NIST Special Publication 800-47 Revision 1

Kelley Dempsey Victoria Pillitteri Andrew Regenscheid

Computer Security Division Information Technology Laboratory

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-47r1

July 2021

U.S. Department of Commerce Gina M. Raimondo, Secretary

National Institute of Standards and Technology

James K. Olthoff, Performing the Non-Exclusive Functions and Duties of the Under Secretary of Commerce for Standards and Technology & Director, National Institute of Standards and Technology

This publication has been developed by NIST to further its statutory responsibilities under the Federal Information Security Modernization Act (FISMA) of 2014, 44 U.S.C. § 3551 et seq., Public Law (P.L.) 113-283. NIST is responsible for developing information security standards and guidelines, including minimum requirements for federal information systems. Such information security standards and guidelines shall not apply to national security systems without the express approval of the appropriate federal officials exercising policy authority over such systems. This guideline is consistent with the requirements of the Office of Management and Budget (OMB) Circular A-130.

Nothing in this publication should be taken to contradict the 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, OMB Director, or any other federal official. This publication may be used by nongovernmental organizations on a voluntary basis and is not subject to copyright in the United States. Attribution would, however, be appreciated by NIST.

National Institute of Standards and Technology Special Publication 800-47 Revision 1 Natl. Inst. Stand. Technol. Spec. Publ. 800-47 Revision 1, 58 pages (July 2021) CODEN: NSPUE2

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-47r1

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.

There may be references in this publication to other publications currently under development by NIST in accordance with its assigned statutory responsibilities. The information in this publication, including concepts and methodologies, may be used by federal agencies even before the completion of such companion publications. Thus, until each publication is completed, current requirements, guidelines, and procedures, where they exist, remain operative. For planning and transition purposes, federal agencies may wish to closely follow the development of these new publications by NIST.

Organizations are encouraged to review all draft publications during public comment periods and provide feedback to NIST. Many NIST cybersecurity publications, other than the ones noted above, are available at https://csrc.nist.gov/publications.

Comments on this publication may be submitted to:

National Institute of Standards and Technology Attn: Computer Security Division, Information Technology Laboratory 100 Bureau Drive (Mail Stop 8930) Gaithersburg, MD 20899-8930 Email: sec-cert@nist.gov

All comments are subject to release under the Freedom of Information Act (FOIA) [FOIA96].

The Information Technology Laboratory (ITL) at the National Institute of Standards and Technology (NIST) 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 other than national security-related information in federal information systems. The 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.

An organization often has mission and business-based needs to exchange (share) information with one or more other internal or external organizations via various information exchange channels. However, it is recognized that the information being exchanged also requires the same or similar level of protection as it moves from one organization to another (protection commensurate with risk).

This publication focuses on managing the protection of the information being exchanged or accessed before, during, and after the exchange and provides guidance on identifying information exchanges, considerations for protecting exchanged information, and the agreement(s) needed to help manage the risk associated with exchanging information. This publication does not provide implementation guidance on any particular type of technology-based connection, information access, or exchange method. Organizations are expected to tailor the guidance to meet specific organizational needs and requirements regarding the information exchange.

agreements; connection; information exchange; information exchange agreement; interconnection; interconnection security agreement; memoranda of agreement; memoranda of understanding; nondisclosure agreement; protection requirements; risk management; service level agreement; user agreement.

The authors – Kelley Dempsey, Victoria Yan Pillitteri, and Andrew Regenscheid – wish to thank their colleagues who reviewed drafts of this publication and provided valuable input, including Joseph Boone, Joshua Finney, Stephen Ford, Greg Frassmann, Ann Galchutt, Jay Gazlay, Nedim Goren, Alan McClelland, Douglas Montgomery, Thomas Ritz, Scott Rose, John Simms, and Scott Spitnale. The authors also gratefully acknowledge Editorial Review Board reviewers Alan McClelland and Michael Bartock, the work of the original authors of SP 800-47, Tim Grance, Joan Hash, Steven Peck, Jonathan Smith, and Karen Korow-Diks; and the preliminary updates made by Michael Nieles. In addition to the above acknowledgments, a special note of thanks goes to Jeff Brewer, Isabel Van Wyk, Jim Foti, and the NIST web team for their outstanding administrative support. Finally, the authors gratefully acknowledge the contributions from individuals and organizations in the public and private sectors, both nationally and internationally, whose insightful and constructive comments improved the overall quality, thoroughness, and usefulness of this publication.

Patent Disclosure Notice

NOTICE: The Information Technology Laboratory (ITL) has requested that holders of patent claims whose use may be required for compliance with the guidance or requirements of this publication disclose such patent claims to ITL. However, holders of patents are not obligated to respond to ITL calls for patents, and ITL has not undertaken a patent search in order to identify which, if any, patents may apply to this publication.

As of the date of publication and following call(s) for the identification of patent claims whose use may be required for compliance with the guidance or requirements of this publication, no such patent claims have been identified to ITL.

No representation is made or implied by ITL that licenses are not required to avoid patent infringement in the use of this publication.

Managing the Security of Information Exchanges provides guidance for planning, establishing, maintaining, and discontinuing information exchange and access between systems that are owned and operated by different organizations (internal or external) or that cross authorization boundaries. The guidance is consistent with the requirements specified in the Office of Management and Budget (OMB) Circular A-130 for the secure management of information exchanges.

This guidance defines the scope of information exchange, describes the benefits of the secure management of information exchange, identifies types of information exchanges, discusses potential security risks associated with information exchange, and discusses several types of agreements that may be applied by organizations with a mission or business need to exchange information.

An approach for securely managing information exchange between systems and organizations is presented. The following four phases of information exchange management are addressed:

This publication provides recommended steps for completing each phase with an emphasis on the security measures necessary to protect the shared data.

Also included is information for selecting and developing appropriate information exchange agreements and agreement templates. Agreements specify the responsibilities of participating organizations and the technical and security requirements for the information exchange.

An organization often has mission- and business-based needs to share or exchange information with other internal or external organizations via various information exchange methods. However, it is recognized that the information being exchanged also requires the same or similar level of protection as it moves from one organization to another (protection commensurate with risk).

This publication focuses on managing the protection of the information being exchanged or accessed before, during, and after the exchange and provides guidance on identifying information exchanges, considerations for protecting exchanged information, and the agreement(s) needed to help manage the risk associated with exchanging information. This publication does not provide implementation guidance on any particular type of technology-based connection, information access, or exchange method. Organizations are expected to tailor the guidance to meet specific organizational needs and requirements regarding the information exchange.

This publication provides guidance for managing (i.e., planning, establishing, maintaining, and discontinuing) the security of information exchanges between systems that are owned and operated by different organizations or are within the same organization but with different authorization boundaries, including organizations within a single federal agency. Organizations manage the security of the information being exchanged by applying security controls and entering into agreements designed to manage risk and protect the information being exchanged at the same or similar level.

This publication is published by the National Institute of Standards and Technology (NIST) as recommended guidance for federal agencies. It also may be used by non-federal organizations.

Federal agencies rely on applicable laws, regulations, and policies for exchanging information between systems that are used to store, process, and disseminate classified data.

This publication is intended for the Senior Accountable Official for Risk Management/Risk Executive (function), authorizing officials, system owners, information owners, program managers, security officers, system architects, system administrators, and network administrators who are responsible for planning, approving, establishing, maintaining, or discontinuing information exchanges and access between systems. Specific information exchange technologies are not addressed (i.e., the guidance is technology-neutral and can be applied to any type of information exchange between any type of organization).

This publication is organized into three sections and three appendices. Section 1 introduces the document. Section 2 discusses the document’s purpose and benefits, as well as the types and methods of information exchange. Section 3 describes four phases for managing the security of information exchanges and provides a matrix to help organizations determine the types of agreements needed to manage the security of the information exchange.

The References section provides references information. Appendix A provides glossary information. Appendix B provides acronym and abbreviation translations. Appendix C provides examples of some agreement types.

Information exchange includes access to or the transfer of data outside of authorization boundaries¹ in order to accomplish a mission or business function. When information is accessed or passed across the authorization boundary from one system to another, one or more agreements are used to specify the responsibilities of each organization, the types and impact level of information to be accessed or exchanged, how the exchanged information is to be used, and how the information is to be protected when it is processed, stored, or transmitted on both ends of the exchange. The type of agreement(s) selected and the level of effort required to develop and maintain the agreement are based on factors including, but not limited to, the impact level of the information being exchanged, the relationship between the organizations exchanging information (e.g., internal organization to internal organization, government to government, government to business, business to business, government or business to service provider, government or business to individual), the resiliency requirements of the information exchange, and the level of access to the system and information by users of the other systems and organizations.

Organizations choose to exchange information for a variety of reasons, depending on organizational needs. For example, organizations may exchange information to:

Significant benefits can be realized through information exchange, such as reduced operating costs, greater functionality, improved efficiency, centralized access to data, and the reduction of duplicative datasets. Information exchange between systems may also strengthen ties among participating organizations by promoting communication and cooperation.

Despite the advantages, information exchange exposes the participating organizations to risk. If the information exchange is not properly planned and managed, a failure to protect the information from a loss of confidentiality, integrity, or availability could compromise the information and associated systems. Similarly, if one of the systems is compromised, the exchanged information could be compromised, or an interconnection used to exchange information could be leveraged as a conduit to compromise the other system and information. The risk is underscored because, in most cases, each participating organization has little or no control over the operation and management of the other organization’s system. Additionally, each participating organization may have different risk tolerances associated with the information exchange and dependencies to facilitate and rely on the exchange.

Therefore, it is critical that the participating organizations learn as much as possible about the risks associated with the information exchange² and what security controls can be implemented to mitigate those risks. Depending on the type of information exchange and the impact level of the information being exchanged, it may also be critical that the organizations establish and formally document one or more agreements regarding the management and use of the exchanged information and the operation of any interconnection used to exchange the information. Senior managers from each organization are responsible for reviewing, approving, and signing the agreement (e.g., Risk Executive (function) [RE(f)], Chief Information Officer [CIO], Chief Information Security Officer [CISO], Authorizing Official [AO]).³

Information exchange occurs via communications technology usually provided by an internet service provider (ISP) or via a system interconnection (physical or virtual), which may itself employ the services of an ISP or telecommunications vendor. Methods to exchange information and for which some type of information exchange agreement⁴ may be warranted include but are not limited to direct exchange (including access) across a system interconnection, electronic or digital file transfers, file-sharing services, database access/sharing or exchanges of database transaction information, exchange of information via portable storage device (which does not use an ISP or system interconnection), and email exchange.

Excluded from information exchanges and information exchange agreements are public services (e.g., time service), users accessing publicly available websites via a web browser, connections with an ISP, and organizational users logging into the organizational network via an organization-approved endpoint. Organizations and users accessing a publicly available service or website are not be included in the scope of this document, as public information may not need safeguards on protection, use, or further distribution. However, protected information distributed via a website may be in scope if users are expected to abide by any terms and conditions prior to being given access to the information. Furthermore, the connection between an organization and an ISP is not used to exchange information between the organization and the ISP. Rather, the ISP connection provides a communications channel that allows the organization to exchange information with other organizations.

The types of information to be exchanged, the impact levels of the information being exchanged, and how the information is to be used by the other organization are agreed upon by participating organizations to manage risk and address information security requirements for information exchanges regardless of the particular method of exchange. Such knowledge helps the participating organizations determine:

The organizations consider agreement types such as interconnection security agreements, interconnection exchange agreements, non-disclosure agreements, access agreements, and/or acceptable use agreements, as described in Section 3.1.5.

A system interconnection is defined as a direct connection between two or more systems in different authorization boundaries for the purpose of exchanging information and/or allowing access to information, information services, and resources. An interconnection used for information exchange has at least three basic components: two (or more) endpoints and the mechanism by which the data flows (i.e., the “pipe” through which information is exchanged). The interconnection can be made from one location to another location or from one location to several locations. In this publication, it is assumed that the systems being interconnected are in different authorization boundaries, are owned and operated by different organizations, or are separately managed entities within the same organization. That is, management of the security of information exchanges is needed not only when information is exchanged between different organizations, but also when it is exchanged across authorization boundaries within a given organization.

The decision to exchange information via a system interconnection is based on an assessment of the associated risks. [SP 800-30], Guide for Conducting Risk Assessments, provides guidance on conducting risk assessments and addresses the determination of threats, vulnerabilities, the likelihood of occurrence, and the impact of occurrence on the mission. Organizations participating in the information exchange conduct risk assessments to determine the risks of exchanging information and interconnecting systems from each organization’s perspective.

A system interconnection is made via a dedicated or on-demand circuit (e.g., leased lines) or via a virtual connection using a Virtual Private Network (VPN)⁵ solution (e.g., Internet Protocol Security [IPsec], Secure Sockets Layer Virtual Private Network [SSLVPN], Layer Two Tunneling Protocol [L2TP]).

The dedicated or on-demand circuit or the VPN is the “pipe” that connects the systems. Employment of a dedicated circuit may be more expensive, but it provides greater security assurance for the information exchange because the circuit may only be breached through a direct physical intrusion.

The less expensive alternative is to connect systems over a public network (e.g., the internet) using a VPN. A VPN is a network that enables two or more parties to communicate securely across a public network by creating a private connection, or “tunnel,” between endpoints. Information transmitted via VPN over a public network can be intercepted by unauthorized parties. However, the use of authentication and encryption helps ensure the confidentiality and integrity of the information exchange.

System interconnections can operate at a network level or an application level:

System interconnections can include permanent connections or temporary connections established for a specific period of time (or function):

To address information security requirements for system interconnections, an interconnection security agreement (ISA) that specifies the security requirements expected for the impact level of the information being exchanged for all participating systems is recommended. ISAs are often coupled with Memoranda of Understanding/Agreement (MOU/A).⁶ Examples of ISA and MOU/A templates are provided in Appendix C. Other types of agreements may also be required and applied (e.g., contracts, non-disclosure agreements [NDA], access agreements, and acceptable use agreements). See Section 3.1.5 for more information on agreements.

The diagram below (Figure 1) illustrates two ways in which systems can be interconnected, as described in this section. In the figure, System A is connected to System B via a dedicated circuit. System A is connected to System C via a VPN tunnel.

Figure 1: System Interconnections

Information can be exchanged using various methods via a system interconnection, an ISP, or both. Common methods of information exchange include but are not limited to electronic or digital file transfers, information exchange via portable storage device, information exchange via email, database sharing or exchanges of database transaction information, and web- or cloud-based services.

Information may be exchanged by accessing or transferring the information using one or more of the methods described in Section 2.1.2.

When information is exchanged via transfer, the information is duplicated in additional physical locations. Information transfer may lead to duplicative datasets, outdated information, or an increased risk of unauthorized disclosure or modification. However, the transfer of information may be indicated to support the use of the same information in a different mission or business process, different software application, or when it is otherwise not feasible to exchange information via system access. Organizations are advised to limit or restrict exchanged information to only the specific data needed to support the stated mission/business case rather than transferring the entire dataset. Participating organizations consider the impact of a loss of the confidentiality and integrity of the information being transferred as well as the need to protect the information commensurate with the agreed-upon impact level, regardless of its physical location.

When information is exchanged via system access, the information itself is not transferred but rather is accessed by users from participating organizations. Exchanging information via system access reduces the instances of duplicative datasets and the risk of loss of confidentiality and integrity of the information. As with any form of system access, the extent to which a user may access information resources is dependent on the organizational mission and the adverse impact of a loss of confidentiality, integrity, and availability of the information. Accordingly, organizations may establish a limited exchange, whereby users are restricted to a single application, file, or file location with specific policies in place to govern access (e.g., access limited to read-only). Other organizations may establish more flexible exchanges, enabling users to access multiple applications, files, or databases. Still other organizations may establish exchanges that permit full transparency and access to the system and information.

Risk-based management of information exchanges requires organizational-level governance to protect the information being exchanged with a level of effort that is commensurate with risk. Prior to any actual information exchange, the organization develops, documents, and disseminates policies and procedures governing information exchange. Decisions regarding the level of effort given to managing and protecting exchanged information—including the formality and rigor of planning, implementation, and the identification of formal agreement types needed—are based on organizational policy and procedures. Information exchange policies and procedures and decisions about how to manage and protect exchanged information are based on the impact of loss of the confidentiality, integrity, and availability of the information as determined by risk assessment and in accordance with organizational risk tolerance.

At a minimum, information exchange policy and procedures establish the types of information that can be shared without formal planning and agreements; the types of information that require tracking, formal planning, and agreements; and a process for determining the level of effort needed for exchanging types of information not specified in policy. For example, organizational policy might specify that exchanging low impact information via email does not require formal planning or a formal agreement, while exchanging moderate-impact information via a file sharing service does require some formal planning and one or more formal agreements.

The remainder of this section describes four phases of information exchange management. Based on the level of effort needed to manage and protect exchanged information commensurate with risk and in accordance with organizational policies and procedures, organizations have the flexibility to determine the formality and rigor with which to apply the four phases and select the most appropriate agreements.

The four phases of information exchange management are described below and depicted in Figure 2:

Figure 2: Phases of Information Exchange Management

The process of exchanging information between two or more systems begins with a planning phase in which the participating organizations perform preliminary activities and examine the relevant technical, security, and administrative issues, as shown in Figure 3. The purpose of the planning phase is to ensure that the information exchange operates as efficiently and securely as possible. This section discusses recommended steps for planning a system information exchange. The formality, structure, and rigor of the planning phase steps depend on the type of exchange, the impact level of the information to be exchanged, the relationship of the organizations involved in the exchange, and organizational policies and procedures for information exchange.

Figure 3: Information Exchange Planning Phase

Each organization is responsible for ensuring the security of its respective systems and information and for applying a well-coordinated approach to the information exchange, including regular communications between the organizations throughout the phases of the exchange. Therefore, the organizations consider establishing a joint planning team composed of representatives from participating organizations that may include appropriate managerial and technical staff, mission and business owners, system owners, information owners, system security officers, system administrators, network administrators, and system security architects. The joint planning team could be part of an existing working group or be created specifically for the planned information exchange. Regardless of how the team is formed, the commitment and support of the system and information owners and other senior managers are important. The team is responsible for coordinating all aspects of the planning process and ensuring that the process has clear direction, well-defined responsibilities, and sufficient resources. The planning team may also remain active beyond the planning phase to serve as a forum for future discussions about issues involving the information exchange.

In addition, members of the planning team coordinate with colleagues responsible for information technology (IT) capital planning, configuration management, and other activities that may be associated with the information exchange or related technology. In many cases, the information exchange is in part or in whole a component of each organization’s network. By coordinating the planning of the information exchange with associated stakeholders, the organizations can reduce security risk, reduce redundancy, and promote efficiency.

The organizations work together to define the purpose of the information exchange, determine how the information exchange will support mission and business requirements, and identify potential costs and risks. Defining the business case establishes the basis of the information exchange and facilitates the planning process. Factors to consider are likely costs (e.g., staffing, equipment, and facilities), expected benefits (e.g., improved efficiency and centralized access to data), and potential risks (e.g., security, technical, privacy, legal, financial, etc.).

Note that there may be privacy statutes, regulations, or policies that place restrictions on the data to be exchanged. 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 organization consults with its Privacy Officer and/or Legal Counsel to determine whether the information to be exchanged may be shared, transferred, or accessed by the other organizations participating in the information exchange.

Before exchanging information, each organization ensures that it has applied the Risk Management Framework (RMF) process to affected systems, as described in [SP 800-37], Risk Management Framework for Information Systems and Organizations: A System Lifecycle Approach for Security and Privacy.

The joint planning team identifies and examines relevant technical, security, and administrative issues surrounding the proposed information exchange. The results are used to develop the appropriate agreements needed to support and manage the information exchange and protect the information. The results may also be used to develop an implementation plan for establishing the information exchange. Note that changes made to existing systems in support of the information exchange, especially changes involving the addition of system components (i.e., hardware, software, or firmware) or changes to infrastructure, may necessitate revisiting one or more steps and tasks from the RMF.

The joint planning team considers the following issues:

The joint planning team determines and documents the agreements needed to govern the exchanged information; the systems processing, storing, or transmitting the information; the roles and responsibilities of the affected organizations and users; the terms under which the organizations will abide by the agreement based on the team’s review of relevant technical, security, and administrative issues (as described in Section 3.1.4); and other appropriate requirements. More than one type of agreement may be needed, such as an interconnection security agreement coupled with a non-disclosure agreement. Organizations are advised to seek legal advice regarding the precedence and authority of agreements.

The Potential Agreements Matrix (Table 1) reflects agreements that may be needed based on the type or method of information exchange (rows) and the impact of a loss of that information (columns). The matrix is not intended to be prescriptive or limit the risk-based agreement choices by organizations but rather provides initial guidance to assist organizations in determining the most appropriate agreements. Additional criteria may also impact the types of agreements needed, including relevant technical, security, and administrative issues, as described in Section 3.1.4.

Table 1: Potential Agreements Matrix

Because the agreements themselves may contain information that is moderate impact or higher, agreements are processed, stored, and transmitted in accordance with impact level to protect against theft, damage, or destruction. Examples of some agreement templates are provided in Appendix C.

An interconnection security agreement (ISA) is a document that specifies the technical and security requirements for establishing, operating, and maintaining an interconnection between two or more systems. The ISA also supports a Memoranda of Understanding/Agreement (MOU/A) between the organizations. Specifically, the ISA documents the requirements for connecting the systems; describes the protection requirements and controls necessary to protect exchanged information and the systems processing, storing, or transmitting the information; usually includes a topological drawing of the interconnection; and provides a signature line for participating organizations. An ISA is indicated when the information exchange occurs via an interconnection, as described in Section 2.1.1. Note that the organization may already have an interconnection and corresponding ISA with another organization over which information exchanges occur between multiple systems and in support of multiple mission requirements. In such situations, the information owner determines if the security protections and processes specified in the existing ISA reduce risk to a level acceptable for the information to be exchanged. If the protections and processes are acceptable, additional agreements may still be required (see Table 1). If not, the ISA may be modified or a separate interconnection may be needed. An ISA template is provided in Appendix C.

A MOU/A is often applied to information exchanges in conjunction with an ISA. In general, an MOU is a statement of intent between the participating organizations to work together and often states goals, objectives, or the purpose for the partnership; details the terms of and conditions for the agreement; and outlines the operations needed to achieve the goals or purpose. The MOA is most often used to address the financial responsibilities and obligations between the parties. While the MOA does not obligate funds, it could specify the authorities who can obligate funds. In support of information exchange, the MOU and MOA collectively address:

The MOU and MOA do not include technical details on how the information exchange is established or maintained or specific security requirements for the exchange; that is the function of the ISA. An MOU/A is indicated for use in conjunction with an ISA when the information is exchanged via a system interconnection, as described in Section 2.1.1, and may be indicated when moderate- or high-impact information is exchanged via database or web-based service or when high-impact information is exchanged via email, portable storage device, or file transfer. Note that if there are no financial responsibilities associated with the exchange, the MOA may not be indicated. An MOU/A template and development guidance are provided in Appendix C.

An information exchange agreement (IEA) is a document that specifies protection requirements and responsibilities for information being exchanged. The IEA is similar to the ISA but does not include technical details associated with an interconnection. Specifically, the IEA describes the protection requirements and controls necessary to protect exchanged information and the systems processing, storing, or transmitting the information and provides a signature line for participating organizations. An IEA may be indicated when the information exchange occurs via one of the exchange methods described in Section 2.1.2. An IEA template is provided in Appendix C.

A service-level agreement (SLA) represents a commitment between a service provider and one or more customers and addresses specific aspects of the service, such as responsibilities, details on the type of service, expected performance level (e.g., reliability, acceptable quality, and response times), and requirements for reporting, resolution, and termination. Specific to information exchange and interconnections, SLAs explicitly address expectations regarding the availability of the connection used to exchange the information. SLAs are often part of a formal contract. An SLA may be indicated for information exchange when the impact of a loss of availability is moderate or high and the information is exchanged via an interconnection provided as part of a contract with a service provider. [SP 800-35] provides information on information technology services and service-level agreements.

User agreements, access agreements, and acceptable use agreements are user-based agreements that are similar to rules of behavior and specify user responsibilities when exchanging information or accessing information or systems that contain the exchanged information. User responsibilities addressed in the agreement may include but are not limited to what the user is permitted to do with the information, how the information is to be used, and whether the information can be transmitted to other parties. Users with access to the information read and sign the agreement to acknowledge acceptance and understanding prior to being given access to the information. The user, access, or acceptable use agreement may be specific to the information being exchanged, or the participating organizations may determine that existing agreements or rules of behavior already read and signed by participating organizational users provide sufficient protection.

A user, access, or acceptable use agreement may be indicated for any type of information exchange when the information being exchanged is moderate or high impact.

A non-disclosure agreement (NDA) delineates specific information, materials, or knowledge that the signatories agree not to release or divulge to any other parties. An NDA may be valid for a defined time frame or may be indefinite.

A non-disclosure agreement may be indicated for information exchange when the information being exchanged is high impact for confidentiality or is personally identifiable information.

Contracts, agreements that combine elements of the other agreement types, internet service agreements, or other organization-defined agreements may also be applied to the information exchange, as appropriate.

In support of mission or business needs, organizations may enter into interagency and/or interorganizational agreements that are not specific to information exchange but could include the need to exchange information. If information exchange is required to support another agreement, the organization follows the guidance in this publication to determine specific protection and agreement needs for the information to be exchanged.

A tracking system provides a method to log and track information exchange outside of the authorization boundary. Examples of tracking systems include but are not limited to internal spreadsheets or databases; Governance, Risk, and Compliance (GRC) tools or other automated tools; and keeping up-to-date control implementation information in a system security plan. Note that requirements for tracking information exchanges may be addressed as part of other types of agreements (e.g., ISA and IEA).

The joint planning team submits the proposed agreements to the relevant AO or other risk management official from each organization and requests approval for the information exchange. Upon receipt, the AOs or risk management officials review the proposed agreements as well as any other relevant documentation or activities. Based on the review, the AOs or risk management officials decide on one of the following:

If the AOs or risk management officials accept the agreement(s), they sign and date the documents, thereby approving the information exchange. The agreements are then retained by participating organizations in accordance with organizational retention policies and procedures. Notify the appropriate program manager or any other officials responsible for the information and information exchange within each organization that the agreement to exchange information has been approved.

If the agreements are rejected by one or more AO or risk management official, the AO or risk management official may propose solutions and/or specify additional requirements to be completed before approval is granted, including the implementation of additional security controls. In addition, a timeline for completing the tasks is specified. The joint planning team works to meet the requirements, then resubmits the updated exchange agreements.

Emergency situations may arise that necessitate an immediate information exchange. When time does not allow for following the established information exchange security management process, the information exchange can still be managed and controlled. For example, prior to the exchange, the organization may include instructions for handling and protecting the information, restrictions for access to the information, or user access or non-disclosure agreements.

It is incumbent upon information and/or system owners to, at a minimum, document the information exchanged as part of the emergency, the justification for the emergency exchange, and the roles and specific individuals involved in the emergency exchange. Emergency information exchanges are reviewed by participating organizations as soon as is practical after the emergency exchange. If the emergency exchange is to become a recurring or permanent exchange, participating organizations conduct the information exchange security management process after the initial emergency exchange. If the emergency exchange is an isolated event, participating organizations ensure protection of the information commensurate with risk and may follow up with appropriate agreements.

After the information exchange is planned and approved, it may be implemented. This section provides recommended steps for establishing the information exchange, as shown in Figure 4.

Figure 4: Information Exchange Establish Phase

To ensure that information is exchanged securely, the joint planning team develops an information exchange implementation plan. The purpose of the implementation plan is to centralize all aspects of the information exchange effort in one document and to clarify how the technical requirements specified in the agreement(s) will be implemented. A well-developed implementation plan greatly improves the likelihood that the information exchange is implemented successfully and securely.

As appropriate, the implementation plan:

After the implementation plan is developed, reviewed, and approved by senior members of the planning team, the plan may then be executed. A list of recommended tasks for implementing an information exchange is provided below.

It may be necessary to install new hardware and software or to configure existing hardware and software to support the information exchange.

If security controls are not in place or are configured improperly, the process of establishing the information exchange could expose the systems to access by unauthorized personnel. Therefore, the first step is to implement appropriate security controls or to configure existing controls, as specified in the agreement(s) and implementation plan. Security controls may include any of the controls from [SP 800-53] (based on risk assessment and system impact levels).

Integrate applications or protocols for services that support the information exchange. Examples include but are not limited to database applications, email, web browsers, application servers, authentication servers, domain servers, development tools, editing programs, and communications programs.

Conduct an assessment to determine if the equipment that supports the information exchange operates properly and that there are no obvious ways for unauthorized users to circumvent or defeat security controls.¹⁰ Test the interface between applications across the exchange, and simulate data traffic at planned activity levels to verify correct translation at the receiving end. Test security controls under realistic conditions. If possible, conduct testing in an isolated, non-operational environment to avoid affecting the systems.

Document the results of the testing and compare them with a set of predetermined operational and security requirements approved by each organization. Determine whether the results meet a mutually agreed upon level of acceptable risk and whether other actions are required. Correct weaknesses or problems and document the actions taken. Retest the exchange and implemented controls to ensure that weaknesses or problems were eliminated and that new flaws have not been introduced.

Conduct security training and awareness for all authorized personnel who will be involved in managing, using, or operating the information exchange. Periodically provide training and awareness for new users and refresher training for all users. Distribute the rules of behavior to all personnel who will be authorized to exchange information. Ensure that personnel know how to report suspicious or prohibited activity and how to request assistance if they encounter problems.

The organizations update their system security plans and related artifacts to reflect the changed security environment in which their respective system operates. In addition, consider conducting mutual reviews of those sections of the updated plans that are relevant to the information exchange. The details for conducting mutual reviews are addressed in information exchange agreements.

It is recommended that the security plans include the following information regarding the information exchange (and other information exchanges, if appropriate):

See [SP 800-18], Guide for Developing Security Plans for Federal Information Systems, for more information.

Establishing an information exchange may represent a significant change to affected systems. Before proceeding further, each participating organization assesses and authorizes their respective system to provide assurance that security protections remain at an acceptable level of risk. [SP 800-37] provides information on assessment and authorization activities as part of the NIST Risk Management Framework.

Activate the information exchange for use by all parties, following prescribed guidelines. It is recommended that the organizations closely monitor the information exchange for an agreed upon period to ensure that it operates properly and securely. Analyze audit logs carefully and frequently and monitor the types of assistance requested by users. Document and correct any weaknesses or problems that occur.

Once established, the information exchange is actively maintained to help ensure that the information is exchanged securely. This section describes recommended activities for maintaining the information exchange, as shown in Figure 5.

Figure 5: Information Exchange Maintain Phase

It is critical that the organizations participating in an information exchange maintain clear lines of communication and communicate regularly. Open lines of communication help to ensure that the information exchange and any associated interconnections are properly maintained and that security controls remain effective. Open communications also facilitate changes in management activities by making it easy for all sides to notify each other about planned system changes that could affect the information exchange. Finally, maintaining clear lines of communication enables organizations to promptly notify each other of security incidents and system disruptions and to conduct coordinated responses.

Communication between designated personnel is accomplished by using procedures specified in agreements associated with the information exchange. Topics for communication include but are not limited to the following:

The participating organizations agree on the ownership and maintenance of any systems and system components used to facilitate the information exchange. Systems and system components are maintained in accordance with implemented controls from the [SP 800-53] Maintenance family.

User accounts associated with the information exchange are actively managed in accordance with implemented controls from the [SP 800-53] Access Control, Identification and Authentication, and Personnel Security families.

Security controls that support the information exchange are assessed with the frequency agreed upon by the participating organizations, whenever a significant change occurs, and/or in accordance with organizational continuous monitoring programs to ensure that the controls are operating effectively and are providing adequate protection.

Security assessments may be conducted by the designated audit authorities of one or all of the participating organizations or by an independent third party. The organizations agree on the rigor of reviews as well as processes for reporting and responding to assessment findings.

SPs [800-37], [800-53A], and [800-115] and [NISTIR 8011] provide guidance on conducting security assessments. [SP 800-137] provides guidance on continuous monitoring.

Event logs for systems and system components associated with the information exchange are analyzed with the frequency agreed upon by the participating organizations to detect and track unusual or suspicious activities. Event logs are managed in accordance with implemented controls from the [SP 800-53] Audit and Accountability family. [SP 800-92] provides guidance on log management.

Organizations that participate in the information exchange notify each other of security incidents or suspected security incidents that affect systems or system components associated with the information exchange. The organizations then take appropriate steps to isolate and respond to such incidents in accordance with their respective incident response procedures and implemented controls from the [SP 800-53] Incident Response family. Depending on the type and severity of the incident, organizations may need to coordinate incident response activities or even terminate the information exchange. The applicable agreements for the information exchange address the roles and responsibilities for incident response for each participating organization, along with incident notification and emergency termination processes. Incidents are reported in accordance with applicable laws, executive orders, directives, regulations, policies, standards, and guidelines. SPs [800-61], [800-83], and [800-86] provide guidance on incident response. Also see [US-Cert Federal Incident Notification Guidelines].

The organizations coordinate contingency planning training, testing, and exercises to minimize the impact of disasters and other contingencies that could damage systems involved in the information exchange or jeopardize the confidentiality, integrity, or availability of shared data. Give special attention to emergency alerts and notifications, damage assessments, and response and recovery, including data retrieval. The organizations may consider developing joint procedures based on existing contingency plans, if appropriate. Finally, the organizations notify each other about changes to emergency POC information (primary and alternate), including changes in staffing, addresses, telephone and fax numbers, and email addresses. [SP 800-34] provides guidance on contingency planning.

Effective configuration management is critical to the maintenance and security of the information exchange. Each organization establishes a change control board (CCB) or a similar body to review and approve planned changes to its respective systems, such as upgrading software or adding services.

The decision to upgrade or modify a system is based on the security requirements specified in applicable agreements and a determination that the change will not adversely affect the exchange of information. It is recommended that planned changes be tested in an isolated, non-operational environment to avoid affecting systems. In addition, notify other parties of the changes in writing, and allow participating organizations to be involved in the process.

If a planned change is specifically applicable to the information exchange, participating organizations establish a joint CCB or a similar body to review and approve the change. In most cases, such changes are designed to improve the operation and security of the information exchange, such as by adding new functions, improving user interfaces, and eliminating (or mitigating) known vulnerabilities. Nevertheless, it is critical that organizations carefully review the changes before implementing them and manage and track the changes after they are made. [SP 800-128] provides guidance on security-focused configuration management.

System security plans, applicable agreements (e.g., ISA, MOU/MOA, IEA, and access agreements), and other relevant documentation pertaining to the information exchange are reviewed and updated with a frequency agreed upon by the participating organizations or whenever there is a significant change to systems associated with the information exchange. Refer to [SP 800-18] for information on updating system security plans.

The business case for continuing the information exchange is reviewed with a frequency agreed upon by the participating organizations to determine if the exchange of information remains necessary. If the information exchange is no longer necessary, Section 3.4 provides information on discontinuing the information exchange.

This section describes the process for discontinuing the information exchange, as shown in Figure 6. To the greatest extent possible, the information exchange is discontinued in a methodical manner to avoid system disruptions.

Figure 6: Information Exchange Discontinue Phase

The decision to discontinue the information exchange involves appropriate managerial, security, and technical staff and is based on a valid rationale, such as ongoing security failures by one or more participants or the lack of a mission-based need to continue the exchange. Before discontinuing the information exchange, the initiating party notifies the other parties in writing and waits to receive an acknowledgment in return. The notification describes the reasons for discontinuing the information exchange, provides the proposed timeline for the discontinuance, and identifies the technical and managerial staff who will conduct the discontinuance.

An organization may have a variety of reasons to discontinue the information exchange, including:

Schedule the discontinuance of the information exchange so that it permits a reasonable period for internal business planning and allows participants to make appropriate preparations, including notifying affected users and identifying alternative resources for continuing operations. In addition, managerial and technical staff from each organization coordinate to determine the logistics of discontinuing the information exchange and the disposition of shared data, including purging and overwriting moderate- or high-impact data and coordinating with records management. Discontinue the information exchange when the impact on users is minimal, based on known activity patterns. Following the discontinuance, each organization updates affected system security plans and related documents to reflect the changed security environment in which its respective systems operate.

If a participating organization detects an attack, intrusion attempt, or other contingency that exploits or jeopardizes the information or systems involved in the information exchange, it might be necessary to abruptly terminate the information exchange without providing written notice to the other party. Such an extraordinary measure is taken only in extreme circumstances and only after consultation with appropriate technical staff and senior management.¹¹

The decision to make an emergency discontinuance is made by the system owner and implemented by technical staff. If the system owner is unavailable, a predesignated staff member may authorize the discontinuance in accordance with written criteria that stipulate the conditions under which this authority can be exercised.

The system owner or designee immediately notifies the other party’s emergency contact by telephone or other verbal method and receives confirmation of the notification. All parties work together to isolate and investigate the incident in accordance with incident response procedures, including conducting a damage assessment and reviewing audit logs and security controls. If the incident was an attack or an intrusion attempt, the parties notify the relevant law enforcement authorities and make every attempt to preserve evidence.

After the emergency discontinuance, the initiating party provides a written notification to the other party in a timely manner. The notification describes the nature of the incident, explains why the information exchange was discontinued, describes how the information exchange was terminated, and identifies actions taken to isolate and investigate the incident. In addition, the notification may specify when and under what conditions the information exchange may be restored.

The organizations may choose to resume the information exchange after it has been discontinued. The decision to resume the information exchange is based on the cause and duration of the discontinuance. For example, if the information exchange was discontinued because of an attack, intrusion, or other contingency, all parties implement appropriate countermeasures to prevent a recurrence of the problem and modify agreements to address any issues that require attention. Alternatively, if the information exchange has been discontinued for a long period of time (e.g., several months or more), each party performs a risk assessment on its respective system and reexamines all relevant planning and implementation issues, including the development of new agreements.

[DHS BOD 18-02] Department of Homeland Security (2018) Securing High Value Assets. (U.S. Department of Homeland Security, Washington, D.C.), Binding Operational Directive 18-02, May 7, 2018. Available at https://cyber.dhs.gov/bod/18-02/

[FOIA96] Freedom of Information Act (FOIA), 5 U.S.C. § 552, As Amended By Public Law No. 104-231, 110 Stat. 3048, Electronic Freedom of Information Act Amendments of 1996. Available at https://www.govinfo.gov/app/details/PLAW-104publ231

[OMB A-130] Office of Management and Budget Memorandum Circular A-130, Managing Information as a Strategic Resource, July 2016. Available at https://www.whitehouse.gov/sites/whitehouse.gov/files/omb/circulars/A130/a130revised.pdf

[FIPS 140-3] National Institute of Standards and Technology (2019) Security Requirements for Cryptographic Modules. (U.S. Department of Commerce, Washington, D.C.), Federal Information Processing Standards Publication (FIPS) 140-3. https://doi.org/10.6028/NIST.FIPS.140-3

[FIPS 199] National Institute of Standards and Technology (2004) Standards for Security Categorization of Federal Information and Information Systems. (U.S. Department of Commerce, Washington, D.C.), Federal Information Processing Standards Publication (FIPS) 199. https://doi.org/10.6028/NIST.FIPS.199

[SP 800-18] Swanson MA, Hash J, Bowen P (2006) Guide for Developing Security Plans for Federal Information Systems. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) 800-18, Rev. 1. https://doi.org/10.6028/NIST.SP.800-18r1

[SP 800-30] Joint Task Force Transformation Initiative (2012) Guide for Conducting Risk Assessments. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) 800-30, Rev. 1. https://doi.org/10.6028/NIST.SP.800-30r1

[SP 800-34] Swanson MA, Bowen P, Phillips AW, Gallup D, Lynes D (2010) Contingency Planning Guide for Federal Information Systems. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) 800-34, Rev. 1, Includes updates as of November 11, 2010. https://doi.org/10.6028/NIST.SP.800-34r1

[SP 800-35] Grance T, Hash J, Stevens M, O'Neal K, Bartol N (2003) Guide to Information Technology Security Services. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) 800-35. https://doi.org/10.6028/NIST.SP.800-35

[SP 800-37] Joint Task Force (2018) Risk Management Framework for Information Systems and Organizations: A System Life Cycle Approach for Security and Privacy. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) 800-37, Rev. 2. https://doi.org/10.6028/NIST.SP.800-37r2

[SP 800-50] Wilson M, Hash J (2003) Building an Information Technology Security Awareness and Training Program. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) 800-50. https://doi.org/10.6028/NIST.SP.800-50

[SP 800-52] McKay KA, Cooper DA (2019) Guidelines for the Selection, Configuration, and Use of Transport Layer Security (TLS) Implementations. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) 800-52, Rev. 2. https://doi.org/10.6028/NIST.SP.800-52r2

[SP 800-53] Joint Task Force (2020) Security and Privacy Controls for Information Systems and Organizations. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) 800-53, Rev. 5, Includes updates as of December 10, 2020. https://doi.org/10.6028/NIST.SP.800-53r5

[SP 800-53A] Joint Task Force Transformation Initiative (2014) Assessing Security and Privacy Controls in Federal Information Systems and Organizations: Building Effective Assessment Plans. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) 800-53A, Rev. 4, Includes updates as of December 18, 2014. https://doi.org/10.6028/NIST.SP.800-53Ar4

[SP 800-53B] Joint Task Force (2020) Control Baselines for Information Systems and Organizations. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) 800-53B, Includes updates as of December 10, 2020. https://doi.org/10.6028/NIST.SP.800-53B

[SP 800-60-1] Stine KM, Kissel RL, Barker WC, Fahlsing J, Gulick J (2008) Guide for Mapping Types of Information and Information Systems to Security Categories. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) 800-60, Vol. 1, Rev. 1. https://doi.org/10.6028/NIST.SP.800-60v1r1

[SP 800-60-2] Stine KM, Kissel RL, Barker WC, Lee A, Fahlsing J (2008) Guide for Mapping Types of Information and Information Systems to Security Categories: Appendices. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) 800-60, Vol. 2, Rev. 1. https://doi.org/10.6028/NIST.SP.800-60v2r1

[SP 800-61] Cichonski PR, Millar T, Grance T, Scarfone KA (2012) Computer Security Incident Handling Guide. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) 800-61, Rev. 2. https://doi.org/10.6028/NIST.SP.800-61r2

[SP 800-77] Barker EB, Dang QH, Frankel SE, Scarfone KA, Wouters P (2020) Guide to IPsec VPNs. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) 800-77, Rev. 1. https://doi.org/10.6028/NIST.SP.800-77r1

[SP 800-83] Souppaya MP, Scarfone KA (2013) Guide to Malware Incident Prevention and Handling for Desktops and Laptops. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) 800-83, Rev. 1. https://doi.org/10.6028/NIST.SP.800-83r1

[SP 800-86] Kent K, Chevalier S, Grance T, Dang H (2006) Guide to Integrating Forensic Techniques into Incident Response. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) 800-86. https://doi.org/10.6028/NIST.SP.800-86

[SP 800-92] Kent K, Souppaya MP (2006) Guide to Computer Security Log Management. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) 800-92. https://doi.org/10.6028/NIST.SP.800-92

(National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) 800-92. https://doi.org/10.6028/NIST.SP.800-92

[SP 800-113] Frankel SE, Hoffman P, Orebaugh AD, Park R (2008) Guide to SSL VPNs. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) 800-113. https://doi.org/10.6028/NIST.SP.800-113

[SP 800-115] Scarfone KA, Souppaya MP, Cody A, Orebaugh AD (2008) Technical Guide to Information Security Testing and Assessment. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) 800-115. https://doi.org/10.6028/NIST.SP.800-115

[SP 800-128] Johnson LA, Dempsey KL, Ross RS, Gupta S, Bailey D (2011) Guide for Security-Focused Configuration Management of Information Systems. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) 800-128, Includes updates as of October 10, 2019. https://doi.org/10.6028/NIST.SP.800-128

[SP 800-137] Dempsey KL, Chawla NS, Johnson LA, Johnston R, Jones AC, Orebaugh AD, Scholl MA, Stine KM (2011) Information Security Continuous Monitoring (ISCM) for Federal Information Systems and Organizations. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) 800-137. https://doi.org/10.6028/NIST.SP.800-137

[SP 800-181] Petersen R, Santos D, Wetzel KA, Smith MC, Witte GA (2020) Workforce Framework for Cybersecurity (NICE Framework). (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) 800-181, Rev. 1. https://doi.org/10.6028/NIST.SP.800-181r1

[IR 8011-1] Dempsey KL, Eavy P, Moore G (2017) Automation Support for Security Control Assessments: Volume 1: Overview. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Interagency or Internal Report (IR) 8011, Vol. 1. https://doi.org/10.6028/NIST.IR.8011-1

[IR 8011-2] Dempsey KL, Eavy P, Moore G (2017) Automation Support for Security Control Assessments: Volume 2: Hardware Asset Management. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Interagency or Internal Report (IR) 8011, Vol. 2. https://doi.org/10.6028/NIST.IR.8011-2

[IR 8011-3] Dempsey KL, Eavy P, Goren N, Moore G (2018) Automation Support for Security Control Assessments: Software Asset Management. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Interagency or Internal Report (IR) 8011, Vol. 3. https://doi.org/10.6028/NIST.IR.8011-3

[IR 8011-4] Dempsey KL, Takamura E, Eavy P, Moore G (2020) Automation Support for Security Control Assessments: Software Vulnerability Management. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Interagency or Internal Report (IR) 8011, Vol. 4. https://doi.org/10.6028/NIST.IR.8011-4

[HVA Control Overlay] Cybersecurity & Infrastructure Security Agency (2021) High Value Asset Control Overlay. Available at https://www.cisa.gov/publication/high-value-asset-control-overlay

[NARA CUI] National Archives and Records Administration (2020) Controlled Unclassified Information (CUI) Registry. Available at https://www.archives.gov/cui

[NIST NICE] National Institute of Standards and Technology (2020) National Initiative for Cybersecurity Education (NICE). Available at https://www.nist.gov/itl/applied-cybersecurity/nice

[USCERT IR] Cybersecurity & Infrastructure Security Agency (2017) US-CERT Federal Incident Notification Guidelines. Available at https://us-cert.cisa.gov/incident-notification-guidelines

acceptable use agreement — See user agreement.

access agreement — See user agreement.

application interconnection — A logical communications link between two or more applications operated by different organizations or within the same organization but within different authorization boundaries used to exchange information or provide information services (e.g., authentication, logging).

electronic/digital file transfer — Transmission of a file (information) between two systems via a file transfer (communications) protocol.

file sharing services — Services that include but are not limited to information sharing and access to information via web-based file sharing or storage.

information exchange — Access to or the transfer of data outside of system authorization boundaries in order to accomplish a mission or business function.

information exchange agreement — A document specifying protection requirements and responsibilities for information being exchanged outside of system authorization boundaries. Similar to the interconnection security agreement but does not include technical details associated with an interconnection.

interconnection — See system interconnection.

interconnection security agreement — A document specifying information security requirements for system interconnections, including the security requirements expected for the impact level of the information being exchanged for all participating systems.

intermittent ad-hoc connection — A needs-based connection initiated for a specific time or purpose after which the connection is terminated. Intermittent connections are most often made via virtual connection.

memoranda of understanding/agreement — A statement of intent between the participating organizations to work together and often states goals, objectives, or the purpose for the partnership; details the terms of and conditions for the agreement; and outlines the operations needed to achieve the goals or purpose.

network interconnection — A physical or virtual communications link between two or more networks operated by different organizations or operated within the same organization but within different authorization boundaries.

non-disclosure agreement — Delineates specific information, materials, or knowledge that the signatories agree not to release or divulge to any other parties.

permanent connection — A perpetual communication channel. Permanent connections are most often made via a dedicated circuit.

service-level agreement — Represents a commitment between a service provider and one or more customers and addresses specific aspects of the service, such as responsibilities, details on the type of service, expected performance level (e.g., reliability, acceptable quality, and response times), and requirements for reporting, resolution, and termination.

scheduled data transfer — A connection used to transfer data on a regular, recurring basis.

system interconnection — A direct connection between two or more systems in different authorization boundaries for the purpose of exchanging information and/or allowing access to information, information services, and resources.

user agreement — A user-based agreement that is similar to rules of behavior. It specifies user responsibilities when exchanging information or accessing information or systems that contain the exchanged information. Also known as access agreement or acceptable use agreement.

PURPOSE: The purpose of this Information Exchange Agreement (IEA) is to establish the terms, conditions, and safeguards under which [specify organization] will disclose to [specify organization] certain information, records, or data to [state reason for IEA]. By entering into this IEA, the [specify organization] agrees to comply with the terms and conditions set forth in [specify location of terms or conditions] and all other terms and conditions set forth in this IEA.

DOCUMENT SUBMISSION: Prior to signing this IEA, the [specify organization] will complete and submit [specify submission requirements, if any] to [specify organization].

TRANSFER OF DATA: [Specify organization] will provide the information to the [specify organization] under this IEA using the following information exchange method: [Specify method(s) of transfer, such as system interconnection, electronic/digital file transfers, portable storage device(s), or other method approved by [specify organization]].

SECURITY PROCEDURES: The [specify organization] will comply with [specify applicable federal laws, executive orders, directives, regulations, policies, standards, and guidelines]. In addition, the [specify organization] will comply with the following: [specify organization-specific regulations, policies, procedures, etc.].

RECEIVING ORGANIZATION’S RESPONSIBILITIES: The [specify organization] is responsible for [specify receiving organization’s responsibilities].

CONTRACTOR/AGENT RESPONSIBILITIES: The [specify organization] will restrict access to the information obtained from [specify organization] to only those authorized [specify organization] employees, contractors, and agents who need such information to perform official duties as specified by purposes identified in this IEA. In addition, the [specify organization] will comply with the limitations on the use, duplication, and disclosure of [specify organization] information set forth in [specify any additional agreement, policy, etc.] with respect to its contractors and agents.

POINTS OF CONTACT: Specify points of contact for each organization. Different points of contact may need to be specified for different issues (e.g., information exchange issues, program or policy issues, system issues, system security issues, agreement issues, technical issues, incident response, etc.).

DURATION: The effective date of this IEA is [specify date]. This IEA will remain in effect [specify time- and/or event-driven triggers for duration].

CERTIFICATION AND PROGRAM CHANGES: At least [specify time period] before the expiration of this IEA, the [specify organization] will certify to [specify organization] in writing that: (1) it is in compliance with the terms and conditions of this IEA; (2) the information exchange processes under this IEA have been and will continue to be conducted without change; and (3) upon [specify organization]’s request, provide event logs, assessment reports, or other documents that demonstrate review and oversight activities. If there are substantive changes in any of the programs or information exchange processes listed in this IEA, the parties will modify the IEA accordingly.

MODIFICATION: Modifications to this IEA must be in writing and agreed to by all parties.

TERMINATION: The parties may terminate this IEA at any time upon mutual written consent. In addition, either party may unilaterally terminate this IEA upon [specify time period] advance written notice to the other party. Such unilateral termination will be effective [specify time period] after the date of the notice or at a later date specified in the notice. [Specify organization] may immediately suspend the information exchange under this IEA or terminate this IEA if [specify organization], in its sole discretion, determines that the [specify organization] (including its employees, contractors, and agents) has (1) made an unauthorized use or disclosure of [specify organization]-supplied data or (2) violated or failed to follow the terms and conditions of this IEA or the other agreement(s).

AUTHORIZED SIGNATURES: The signatories below warrant and represent that they have competent authority on behalf of their respective organizations to enter into the obligations in this IEA.

The requirements for interconnection between [specify organization] and [specify organization] are for the express purpose of exchanging data between [specify system to be interconnected] owned by [specify organization] and [specify system to be interconnected] owned by [specify organization]. [Specify organization] requires the use of [specify organization]'s [specify system to be interconnected], and [specify organization] requires the use of [specify organization]'s [specify system to be interconnected] as approved and directed by [insert appropriate approving official] dated [specify date]. The expected benefit of the specified interconnection is to [specify benefits of the interconnection].

(Insert a drawing here.)

This ISA is valid for [insert time period] after the last date on either signature below. At that time, it will be updated, reviewed, and reauthorized. Either party may terminate this ISA with [specify time period] advanced notice in writing or in the event of a security incident that necessitates an immediate response.

The organizations that own and operate the connected systems establish an MOU/A (or an equivalent document) that defines the responsibilities of all parties in establishing, operating, and securing the interconnection. The MOU/A is a management document that does not contain the technical details of the interconnection. Those details are addressed separately in the ISA (see above).

An MOU/A development guide is provided below, although organizations may use their own MOU/A format. A sample MOU/A is provided below the development guide.

Identify any previous agreements that this memorandum supersedes, including document titles and dates. If the memorandum does not supersede any other agreements, so state.

Use the Introduction section to describe the purpose of the memorandum. Identify the organizations and systems that are involved in the interconnection.

Identify any relevant legislative, regulatory, or policy authorities on which the MOU/A is based.

Use the Background section to describe the systems that will be interconnected, the information that will be exchanged or passed one way across the interconnection, and the business purpose for the interconnection.

Make the description of the systems brief and nontechnical. The goal is to identify the systems and their authorization boundaries. The memorandum does not provide system specifications. The Background section includes the formal name of each system, briefly describes system functions, identifies system physical locations, identifies information impact or classification level and the system categorization or classification level, and identifies the type(s) of information stored, processed, and/or transmitted by each system.

Discuss the communications that will be exchanged between the parties throughout the duration of the interconnection. Identify the specific events for which the parties must exchange formal notification and discuss the nature of such communications.

State that the parties will jointly develop and sign an ISA before the systems can be connected. In addition, describe the purpose of the ISA.

State that all parties agree to abide by the security arrangements specified in the ISA. In addition, state that all parties certify that their respective system is designed, managed, and operated in compliance with all relevant federal laws, regulations, and policies.

The Cost Considerations section provides the financial details of the agreement. It specifies who will pay for each part of the interconnection and the conditions under which financial commitments may be made. Typically, each organization is responsible for the equipment necessary to interconnect its local system, while the organizations jointly fund the interconnecting mechanism or media. However, the financial arrangements are fully negotiable.

Identify the expiration date of the memorandum and procedures for reauthorizing it. In addition, stipulate that the memorandum may be terminated with written notice from one of the parties to the other. The memorandum and the ISA have the same expiration date.

The memorandum includes a signature line with a signature block for each authorizing official. Arrange the signature blocks on the same line with one signature on the left and one on the right. Include an area for the date signed.

SUPERSEDES: (None or title and date of superseded document)

The purpose of this memorandum is to establish a management agreement between [specify organization] and [specify organization] regarding the development, management, operation, and security of an interconnection between [specify system] owned by [specify organization] and [specify system] owned by [specify organization]. This agreement will govern the relationship between [specify organization] and [specify organization], including designated managerial and technical staff, in the absence of a common management authority.

The authority for this agreement is based on [specify document] issued by the [specify management official with appropriate authority] on [specify date of document authorizing the agreement].

It is the intent of all parties to this agreement to interconnect systems to exchange data between [specify system] and [specify system]. [Specify organization] requires the use of [specify organization]'s [specify system], and [specify organization] requires the use of [specify organization]'s [specify system], as approved and directed by the [specify management official with appropriate authority] in [specify document named under “Authority” section]. The expected benefit of the interconnection is to [specify benefit(s) of the interconnection].

Each system is described below:

Frequent formal communications are essential to ensuring 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 [specify system] and [specify system] agree to designate and provide contact information for technical leads for their respective systems and to facilitate direct contacts between technical leads to support the secure management and operation of the interconnection. To safeguard the confidentiality, integrity, and availability of the connected systems and the information that the systems store, process, and transmit, the parties agree to provide notice of specific events within the time frames indicated below:

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 all 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 Authorizing Official for each system.

All parties agree to work together to ensure the joint security of the interconnected systems and the information stored, processed, and transmitted, as specified in the ISA. Each party certifies that its respective system is designed, managed, and operated in compliance with all relevant federal laws, regulations, and policies.

All 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 all parties. Modifications to either system that are necessary to support the interconnection are the responsibility of the respective system owner’s organization.

This agreement will remain in effect for [specify time period] after the last date on either signature in the signature block below. After [specify time period], 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 explicitly supersedes this agreement, which is referenced by title and date. If one or all parties wish to terminate this agreement prematurely, they may do so upon [specify time period] 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/Agreement.