FERC_INTERCONNECTION_SVC_AGMT.doc
DOC document 248 KB Posted
- Attached to
- CEDMS Federal contract opportunity
- Solicitation number
- FERC13R0050
About this file
FERC-13-R-0050 FERC INTERCONNECTION SVC AGMT.doc
View the file
Other files for this federal contract opportunity
| File | Type | Posted |
|---|---|---|
| CEMDS_Q_A_SRL_04.12.13.docx | DOCX document | |
| FERC-13-R-0050_0002.docx | DOCX document | |
| FERC-13-R-0050_0001.docx | DOCX document | |
| FERC-13-R-0050_CEMDS.docx | DOCX document | |
| FERC-13-R-0050_1.docx | DOCX document |
On GovTribe
Work with this file on GovTribe
- Download the original file
- Contacts named in this file
- Similar government files
- Ask GovTribe AI about this file
Text version
FERC Interconnection Service Agreement Federal Energy Regulatory Commission
Interconnection Service Agreement Federal Energy Regulatory Commission
<INSERT BUSINESS PARTNER>
March 13, 2013 Federal Energy Regulatory Commission
Information Security and Systems Assurance Division 888 1st Street NE
Washington, DC 20426
Document Control
This is a controlled document produced by the Federal Energy Regulatory Commission. The control and release of this document is the responsibility of the document owner. This includes any amendment that may be required and produced.
Document Description
| Date |
| March 15, 2013 |
| Author |
| William Clark |
| Document Title |
| FERC Interconnection Service Agreement |
| Document Description |
| This document establishes policy for standardizing the architecture and design of an interconnection between FERC and its Business Partners. |
Document Owner
| Name |
| Naeem Musa |
| Office/Region |
| Federal Energy Regulatory Commission, Washington, DC 20426 |
| Contact Number |
| (202) 502-8468 |
| E-mail Address |
| Naeem.Musa@ferc.gov |
Revision History
| Issue |
| Date |
| Author |
| Comments |
| 1.0 |
| March 15, 2013 |
| William Clark |
| Official Release |
Contents 11.
Purpose
12.
scope
23.
Authority
24.
INTERCONNECTION STATEMENT OF REQUIREMENTS
25.
SYSTEM SECURITY CONSIDERATIONS
25.1 General Information/Data Descriptions.
35.2 Services offered
35.3 Data sensitivity
35.4 User community
35.5 Information Exchange Security
35.6 Trusted Behavior Expectations
45.7 Formal Security Policy
55.8 Incident Reporting
65.9 Audit trail responsibilities
65.10 Operational Security Mode
65.11 Training and Awareness
65.12 Confidentiality (This section may not be required for all ISAs)
76.
Statement of STANDARDS
76.1 VPN Technology: IPsec
86.2 VPN Technology: SSL
86.3 Internet Protocol Version 6 (IPv6)
86.4 Impact of the Security Engineering Principles
86.5 HSPD-12: Logical Access (government to government connections only)
87.1 General Information/Data Description
87.
NETWORK DESCRIPTIONS
88.1 Commission’s Network
98.2 Commission’s Business Partner Network
98.3 Topological Diagram
98.4 Interconnected Network
98.5 Data Flow Diagrams
108.6 User Role Matrix
11Appendix A: Acronyms/Terms and Definitions
12Appendix B: APPROVALS
1. Purpose
The purpose of this Interconnection Security Agreement (ISA) is to establish the architecture and design for an interconnection between the Federal Energy Regulatory Commission (Commission) and <Insert Commission’s Business Partner Name> hereafter referenced as the “Commission’s Business Partner”. This ISA is intended to minimize security risks and ensure the confidentiality, integrity, and availability (CIA) of Commission information as well as other information in the Commission’s custody. This ISA promotes adequate security of information being accessed and provides that all network access satisfies the mission requirements of both the Commission and Commission’s Business Partner hereafter known as “both parties”. This ISA documents the interconnection arrangements for both parties, defines security safeguards, and provides the technical and operational security requirements. Through this ISA, both parties shall minimize the susceptibility of their connected systems and networks to IS risks and aid in mitigation and recovery from Information Security incidents.
2. scope
The scope of this ISA is focused on:
· The specific identified interconnection between the parties for the purpose of satisfying authorized business needs.
· The existing and future users including employees from both parties, contractors and subcontractors at any tier; and other users managing, engineering, accessing, or utilizing the Commission’s Business Partner Network. User identities may be in the form of human or process entities.
Related network components belonging to both parties, such as hosts, routers, and switches; IT devices that assist in managing security such as firewalls, intrusion detection systems (IDS), and vulnerability scanning tools; desktop workstations; servers; and Major Applications (MA) that are associated with the network interconnection between both parties
3. Authority The associated Memorandum of Understanding (MOU) ratified by both parties and dated <MOU ratification date> authorizes mutual permission to interconnect both parties and establishes a commitment to protect data that is exchanged between the networks or processed and stored on systems that reside on the networks.
Within the Commission:
· The approval to begin work to implement the planning identified in this ISA is granted by formal approval from the Configuration Control Board (CCB). Both an MOU ratified by both parties and this completed ISA are pre-requisites for implementation approval by the CCB. All conditions levied by the CCB must be satisfied before the status of the interconnection can be made Operational.
4. INTERCONNECTION STATEMENT OF REQUIREMENTS
The requirements for interconnection between FERC and <Insert Commission’s Business Partner Name> are for the express purpose of exchanging data between <Insert FERC system name> operated by FERC, and <Insert Business Partner’s system>, owned by <Insert Commission’s Business Partner Name>. The expected benefit of the interconnection is <insert verbiage>.
5. SYSTEM SECURITY CONSIDERATIONS
5.1 General Information/Data Descriptions.
The organizations directly involved in all aspects of the life cycle of this Interconnection are, <Insert Commission’s Business Partner Name> headquartered at <Insert physical address> with secondary site located at <insert physical address if applicable> and the FERC <insert FERC Program Office>, located at 888 First Street, NE, Washington, DC 20426. The Interconnection between <Insert Commission’s Business Partner Name> and FERC is a two-way connection, and the purpose of the Interconnection is to facilitate the <insert business purpose.>. The interconnection takes place via a secure VPN connection interface using AES-encryption as described further herein.
This Agreement specifies the production Interconnection between <Insert Commission’s Business Partner Name> and FERC Servers in support of <Insert business purpose>. This Agreement also specifies the Interconnection between <Insert Commission’s Business Partner Name> and individual workstations located in FERC's office. FERC staff will connect with the <Insert Business Partner System name> utilizing <Insert system interactions>. The purpose of the Interconnection is to secure access of the <Insert system user/data> by authorized FERC end-users.
5.2 Services offered
This Interconnection offers a single end-user service: <Insert description of user services, if any>. The services provided by the Interconnection are limited to the following:
· Site-to-Site secure VPN connection between FERC and <Insert Commission’s Business Partner Name> For the Interconnection, end-user information is exchanged between the OATI Hosted Servers and the FERC end-user's structured query language environment, either SAS Enterprise Guide, or Microsoft Access ODBC (open database connection). Data transferred is protected by an AES-encrypted site-to-site Virtual Private Network (VPN). This VPN is established between <Insert Commission’s Business Partner Name> <insert device type, operating system, and NIST FIPS 140-2 Validated Certificate # > and FERC-Office's Cisco ASA 5520 firewall (NIST FIPS 140-2 Validation Certificate #821).
5.3 Data sensitivity
The sensitivity level of the data transmitted over the Interconnection is a FIPS (<Insert low/moderate/high>) impact level. Access to the FERC-<Insert Commission’s Business Partner Name> (<Insert names of IT assets>) and the data on these <IT assets> will be restricted to authorized users who are authorized by the FERC program manager or his/her designee.
5.4 User community
Access to the <Insert Business Partner System name> will be restricted to authorized users as identified by the program manager or his/her designees. All FERC personnel with access to the system receive initial and annual security awareness training.
5.5 Information Exchange Security
The security of the information being passed on this two-way connection is protected through the use of FIPS 140-2 approved encryption mechanisms. The connections at each end are located within controlled access facilities, guarded 24 hours a day. Individual users will not have access to the data except through their systems security software inherent to the operating system. All access is controlled by authentication methods to validate the approved users.
5.6 Trusted Behavior Expectations
FERC’s system and users are expected to protect <Insert Business Partner System name>><Insert IT assets>, and <Insert Business Partner System name> system and users are expected to protect FERC’s <Insert IT assets>, in accordance with the Privacy Act and Trade Secrets Act (18 U.S. Code 1905) and the Unauthorized Access Act (18 U.S. Code 2701 and 2710). Security controls inherent in both the FERC-<Insert Commission’s Business Partner Name> and <insert FERC IT Assets> systems are designed to protect the confidentiality, integrity, and availability of the data exchanged between the two systems. These controls are described in detail in the FERC’s GSS system security plan and <Insert Commission’s Business Partner Name> equivalent plan. Expected rules of behavior for each system are detailed in the system security plan applicable to each system.
5.7 Formal Security Policy
The formal security policies that govern the protection of each system are documented in the following:
· <Insert Commission’s Business Partner Name>Information Technology Security Program and Policies, consisting of <insert Business Partner system> security controls which conform to and are annually audited against <insert audit standards, i.e., SSAE16/ISAE3402, NERC CIP, NIST SP 800-53, etc, as applicable>.).
· FERC General Support System (GSS) System Security Plan
Both <Insert Commission’s Business Partner Name>and FERC will update their system security plans and/or other such documentation as appropriate to reflect implementation of the Interconnection. Specifically, this documentation will be revised to include the following information required by NIST SP 800-47, Security Guide for Interconnecting Information Technology Systems, and specified in NIST SP 800-18, Guide for Developing System Security Plans for Information Technology Systems:
· Names of interconnected systems
· Organization owning the other system(s)
· Type of interconnection
· Short discussion of major concerns or considerations associated with the interconnections
· Name and title of authorizing management official(s)
· Date of authorization of the interconnection
· Sensitivity level of each system involved in the interconnection
· Description of the Interaction between the systems
· Hardware and software involved in establishing the interconnection
· Security concerns and Rules of Behavior governing the interconnection The Commission’s Business Partner shall:
Third Party Entities Provide FERC with a copy of their most recent independent auditor report of security controls relating to the Business Partner’s network(s) that will have an interconnection to the FERC’s IT infrastructure. Suitable reports to meet this requirement include SSAE 16 reports.
Federal Agencies and Departments
Maintain an SSP on the Commission’s Business Partner’s network and update it whenever there is a major modification. The SSP shall be compliant with and complementary to the Commission’s System Security Plan for the interconnection
5.8 Incident Reporting
General requirements for incident reporting are detailed in the security plans of the FERC systems.
· FERC GSS System Security Plan Security incidents are immediately addressed, so as to contain the incident, establish countermeasures to mitigate the impact of the incident, and recover from the incident. The party discovering the incident will report security incidents in accordance with their procedures. Policy governing the reporting of security incidents is defined in the following documents:
· FERC Incident Response Policy <Insert Commission’s Business Partner Name> will immediately notify the FERC Information System Security Officer (ISSO) when a security incident(s) is detected that has the potential to materially affect the Interconnection, and will take steps to determine whether its system has been compromised, and to take appropriate security precautions. If it is determined that a security incident has occurred, <Insert Commission’s Business Partner Name>will report any security incident to the FERC’s Security Operations Center (fercsoc@ferc.gov) and the IT Support Center immediately (202-502-8163). If the security incident is determined significant, FERC's CISO will report the incident to the US-CERT office within the Department of Homeland Security, and the CERT® Coordination Center.
In the case of FERC, FERC will immediately notify<Insert Commission’s Business Partner Name> when a security incident(s) is detected that has the potential to materially affect the Interconnection, so that <Insert Commission’s Business Partner Name> may take steps to determine whether its system has been compromised, and to take appropriate security precautions. FERC will prepare and submit a security incident reporting form to<Insert Commission’s Business Partner Name>. In addition, any security incident will be reported to the FERC IT Support Center immediately. If the security incident is determined significant, FERC's CISO will report the incident to the US-CERT office within the Department of Homeland Security, and the CERT® Coordination Center.
The incident response team will hold a "lessons learned" meeting with all involved parties after an incident, to address the reason(s) for the incident, how to improve security measures, and the incident handling process. These "lessons learned" will be documented and any appropriate plans of action will be addressed. NIST Special Publication (SP) 800-61, Computer Security Incident Handling Guide and the GSA IT Security Procedural Guide: Handling IT Security Incidents C/0-IT-01-02 are followed
5.9 Audit trail responsibilities
Both parties are responsible for auditing application processes and user activities involving this Interconnection. Audit logs will be accessible only to authorized system/security administrators and the ISSO (for their respective systems). Audit logs will be inaccessible or "read only" (i.e. unable to modify the audit data after it is recorded by the system) to end users. Activities will be recorded as appropriate for each piece of equipment and supporting technology, and may include, for example, event type, date and time of the event, user identification, attributes associated with the event (e.g., success or failure of access attempts), program or command used to initiate the event (where possible), and security actions taken by system administrators or security officers. Audit data will be collected, reviewed, and retained in accordance with local security policies as documented in the system security documentation for each system. At a minimum, audit logs will be retained for ninety (90) days.
5.10 Operational Security Mode
Both the FERC office workstations, and <Insert Commission’s Business Partner Name> systems and databases operate in the <Insert operational Security Mode, ie, Multilevel, High, > security mode. In the <Insert mode level> mode of operation, some users with direct or indirect access to the system will not have security clearances (e.g., background checks) and all users have formal access approval for all information stored or processed on the system and a valid need-to-know for the information contained within the system. Consistent with the Multilevel mode of operation, access to the <Insert Commission’s Business Partner Name>system and the FERC’s <Insert IT asset(s)>, and the data on these servers, will be restricted to authorized users based on their job responsibilities.
5.11 Training and Awareness
There are no new security training or awareness requirements associated with the implementation of this Interconnection. Each organization (<Insert Commission’s Business Partner Name>and FERC is expected to conduct security awareness training for its staff in accordance with the organization's system security requirements. Additionally, FERC is expected to provide users of its system with Rules of Behavior for the system and to obtain user acknowledgement prior to granting access.
5.12 Confidentiality (This section may not be required for all ISAs) This document and attachments contain confidential, proprietary and trade secret information of<Insert Commission’s Business Partner Name>. This information is not to be used, disseminated, distributed, or otherwise transferred without the expressed written permission of Open Access Technology International, Inc.
4. Statement of STANDARDS
The Commission’s IS Program has adopted a number of national and international standards that apply directly to the interconnection of business partner networks. For cost containment, the Commission leverages its Internet connectivity and uses Virtual Private Networking (VPN) to interconnect when practical. This is the primary choice for business partner interconnections. While the Commission is standardized on VPN’s using IPsec (Internet Protocol Security) technology. VPN’s using SSL technology is becoming available, and will be considered on an exception basis only with approval by the CCB.
4.1 VPN Technology: IPsec
The technology standard for constructing secure VPN’s to the Commission is IPsec. To provide the necessary level of protections required by the IS Program, the various configuration options for establishing and operating IPsec have been defined and deviations to this standard are permitted by CCB exception only.
See Table 1 below for the VPN IPsec technology standard.
Table 1
VPN IPsec Standard
| Technology: IPsec |
| Architecture: Gateway to Gateway |
| Security Protocol: Encapsulating Security Protocol (ESP) |
| Mode: Tunnel |
Duty Cycle:
On-demand
| Always Up |
| Initiating End: |
| End Points |
| FERC End (Internet) IP Address: |
Partner End (Internet) IP Address:
FIPS (140) Mode: Enabled
| IKE (Version 1) |
| Authentication method: Pre-shared Key (Unique site specific sequence of 26 random characters containing upper and lower case, numbers, and punctuation) |
Mode: Main
Algorithms:
Encryption: AES-CBC
Integrity: HMAC-SHA-1
Diffie-Hellman Group: 14 (2048 bits in MODP)
SA Lifetime: 86400 (24 hours)
Dead Peer Detection (DPD): Enabled
| IPsec |
| Algorithms: |
Encryption: AES-CBC
Integrity: HMAC-SHA-1
SA Lifetime: 28800 (8 hours)
Padding: None
Perfect Forward: Enabled
IPComp: Disabled
6.2 VPN Technology: SSL
To be considered as exceptions by Change Control Board (CCB) and reviewed on a case-by-case basis, and with approval of the respective AO.
6.3 Internet Protocol Version 6 (IPv6)
To Be Determined. (Should be fully compliant with OMB IPv6 implementation mandates.)
6.4 Impact of the Security Engineering Principles
With the above security principles in mind and with respect to the Commission’s end of the interconnection, the following security requirement must be satisfied:
· The connection of the business partner to Commission’s Internet facing appearance (firewall) must limit the range of possible connections to the specific IP address to that which the partner has specifically identified for this purpose. A secondary is permitted. All other connections shall be silently refused.
6.5 HSPD-12: Logical Access (government to government connections only)
To Be Determined. (Should be fully compliant with OMB implementation mandates.)
Statement of requirements
The expected benefit of the interconnection is <Insert Business Expectation>
7.1 General Information/Data Description
<Insert a description of the information and data that will be made available, exchanged, or passed one-way only by the interconnection of the networks and the respective applications or systems>
5. NETWORK DESCRIPTIONS
8.1 Commission’s Network
Name: Commission
Function: <Insert Commission’ Network Function> Commission Interconnection Terminus Location: <Insert physical site location> Internet End Point IP Address: <Insert Internet IP Address>
| End Points |
| FERC End (Internet) IP Address: |
Partner End (Internet) IP Address:
FIPS (140) Mode: Enabled on both End Points
NIST FIPS 104-2 Validated Certificate <Business Partner inserts certificate number>
All components must have functional descriptions that include the reason they are considered to be relevant. Language should address all the interdependencies necessary to make the network function in support of the interconnection requirements.
8.2 Commission’s Business Partner Network
Name: <Insert Commission’s Business Partner’s Network> Function: <Insert Commission’s Business Partner’s Network Function> Interconnection Terminus Location: <Insert physical site location> Internet End Point IP Address: <Insert Internet IP Address>
Note to Business Partners: FIPS Mode can be validated with a “snapshot” of the configuration setting of the device utilizing a FIPS 140-2 validated cryptographic module implementation. The ISA document must include the NIST approved certification number associated with the specific business partner implementation. (for example, Cisco ASA 55xx firewall running IOS version xxxxx, utilizing FIPS 1402 Validation Certificate #xxx) All components must have functional descriptions that include the reason they are considered to be relevant. Language should address all the interdependencies necessary to make the network function in support of the interconnection requirements.
8.3 Topological Diagram
Appendix A will include a topological drawing that illustrates the interconnectivity between both networks, including all components (e.g., firewalls, routers, switches, hubs, servers, encryption devices, and computer workstations). The drawing should reflect the end to end nature of the communication flows that the interconnection is intended to support. (The intent of the drawing is to depict the end to end connectivity that is achieved with the partner interconnection.)
8.4 Interconnected Network
A text based description of how the FERC network integrates with the business partner network to address and deliver a solution to the requirements. Language should address all the interdependencies necessary to make the end to end “system” function in support of the interconnection requirements.
8.5 Data Flow Diagrams
Appendix B will contain a set of diagrams that includes all information flows (control, data, auditing, etc,) entry and exit points, trust boundaries and levels, and protected resources. .
8.6 User Role Matrix
Include a role matrix of the authorized roles that identifies each user or user grouping to be used access across the interconnection to access the shared resourced.
Appendix A: Acronyms/Terms and Definitions
| Acronym/Term |
| Definition |
| AO |
| Authorizing Official |
| AES |
| Advanced Encryption Standard |
| ATO |
| Authority To Operate |
| CCB |
| Change Control Board |
| CIA |
| Confidentiality, Integrity and Availability |
| CIO |
| Chief Information Officer |
| DPD |
| Dead Peer Detection |
| ESP |
| Encapsulating Security Protocol |
| FERC |
| Federal Energy Regulatory Commission |
| FIPS |
| Federal Information Processing Standards |
| FISMA |
| Federal Information Security Management Act |
| HSPD-12 |
| Homeland Security Presidential Directive12 |
| IDS |
| Intrusion Detection System |
| IPS |
| Internet Protocol Security |
| IS |
| Information Systems |
| ISA |
| Interconnection Service Agreement |
| ISP |
| Interconnection Security Plan |
| IT |
| Information Technology |
| MA |
| Major Application |
| MODP |
| Modular Exponential |
| MOU |
| Memorandum of Understanding |
| NIST |
| National Institute of Standards and Technology |
| OMB |
| Office of Management and Budget |
| SIA |
| Security Impact Analysis |
| SSAE |
| Statement on Standards for Attestation Engagements |
| SSL |
| Secure Socket Layer |
| SSP |
| System Security Plan |
| VPN |
| Virtual Private Network |
Appendix B: APPROVALS We hereby approve this “Interconnection Service Plan”. This Plan will become effective on
1.
2.
Signature:
Date:
<Insert Business Partner’s CISO's Name>
<Insert Business Partner’s Company>
<Insert Business Security Manager Title> Signature:
Date:
<Insert Business Partner’s Network Manager Name>
<Insert Business Partner’s Company> <Insert Business Network Manager Title>
Signature:
Date:
Naeem Musa
Federal Energy Regulatory Commission
Chief Information Security Officer (CISO)
Signature:
Date:
Isaac Hernandez
Federal Energy Regulatory Commission
Director of Network Operations
� “Information” is defined as “any knowledge that can be communicated or documentary material, regardless of its physical form or characteristics, that is owned by, produced by or for, or is under the control of the United States Government.” (Executive Order 12958)
� “Adequate security” is defined as “a level of security that is commensurate with the risk and magnitude of the harm resulting from the loss, misuse, or unauthorized access to or modification of the information.” (Office of Management and Budget (OMB) Circular A-130)
� A “major application” is an application that requires special attention to security due to the risk and magnitude of the harm resulting from the loss, misuse, or unauthorized access to or modification of the information in the application. (OMB A-130)
Controlled Unclassified Information
PAGE
iv
File details come from the government source that posted it. Updated .