Attachment_0024_RMF_Package_Deliverables_Instructions.docx

Attachment 0024 – RMF Package Deliverables Instructions Solicitation No.: W56HZV-22-R-0026

Attachment 0024 RMF Package Deliverables Instructions

Date: 29 March 2022

Distribution Statement A: Approved for public release; distribution is unlimited.

Introduction:

This purpose of this document is to provide instruction for the RMF Package Deliverables.

Package Components:

(a) Authority to Operate (ATO) Requests

a. The ATO Request shall use the approved AO or ISSM format. The ATO Request shall use identify the ‘who’, ‘what’, ‘why’, ‘where’, ‘when’, and ‘how’ of the requested authorization. The ATO Request shall include the System Security Implementation Plan (SSIP), artifacts asserting NIST 800-53 control compliance and any supporting artifacts which attest to that compliance. An ATO Request may be submitted in-lieu of an IATT Request. The ATO Request shall be delivered not less than 45 days prior to the start of the Operation or Limited User Testing to the Program Office.

b. The purpose of this request is to deliver supporting artifacts to the Information System Security Engineer and Information System Security Manager to assist in receiving approval from the Authorized Official (AO) prior to testing.

(b) Assessment and Authorization (A&A) Project Plan

a. The A&A Project Plan shall be used to establish and executable Risk Management Framework activities to achieve and maintain an ATO and shall be completed prior to ICR. The A&A Project Plan shall establish timelines for documentation within the RMF Package Deliverables.

b. The purpose of this document is to assist the contractor, and corresponding government official, in planning their documentation deliveries and timelines

(c) A&A Tasks and Milestones

a. The A&A Tasks and Milestones shall be a list of tasks, deliverables, events, and milestones with status, risk, and schedule for achieving the A&A Project Plan. The A&A Tasks and Milestones shall have a section for schedule which identifies each task, deliverable, event, and milestone as on schedule, complete, behind schedule, and any dependencies required to achieve the schedule.

b. The contractor shall provide and update this document with every delivery of this DID. The A&A Tasks and Milestones shall be used to track tasks, events, deliveries, and schedule for achieving the A&A Project Plan.

c. The purpose of the document is to identify potential risks to meeting the A&A Project Plan and assign action to people for completing tasks.

(d) System Security Implementation Plan –

a. The SSIP shall contain at a minimum, System Information, Mission Description, Concept of Operations (CONOPS), Environment, Operating and Computing Environment, Physical Security Measures, Facilities Descriptions, Threat Analysis, System Architecture Description, Components, Configurations, Subsystem Configuration Files, Platform Diagrams, Accreditation Boundaries, External Interfaces and Data Flow, Internal Data Flow, Security Roles, Cybersecurity Countermeasures associated with Program Protection, Hardware Lists, Software Lists, Countermeasures, and Ports, Protocols, and Services (PPS).

b. A template is in the appendix of this document.

c. The SSIP shall include appendices for the RMF Implementation Plan (RIP), Configuration Management Plan, Information Assurance Vulnerability Management (IAVM) Plan, Key and Certificate Management Plan, Contingency Plan, Incident Response Plan, Assessment and Authorization (A&A) Project Plan, and A&A Tasks and Milestones.

d. The purpose of the SSIP is to be a central authority which supports an ATO. The SSIP is intended to identify the system security practices and implementations.

(e) RMF Implementation Plan (RIP)

a. The RIP shall document compliance to all NIST 800-53 controls. The RIP shall identify all scoping and tailoring of controls for the system. . The RIP shall document NIST 800-53 controls as ‘Compliant’, ‘Inherited’, ‘Non-Compliant’, or ‘Not Applicable’.

b. The purpose of this deliverable is to document compliance to NIST 800-53. The document should trace to subsystem requirements and cyber resiliency requirements.

(f) Software Code Vulnerability Scans –

a. The software code vulnerability scans should not diverge from scope in the software section of the RFP.

b. The purpose for this deliverable is to provide the latest software code vulnerability scans at the time of ATO assessment.

(g) Operating System Vulnerability Scans –

a. The Operating System Vulnerability Scans should not diverge from scope in the software section of the RFP.

b. The purpose for this deliverable is to provide the latest software code vulnerability scans at the time of ATO assessment.

(h) Software/Firmware Information Assurance Vulnerability Management (IAVM) Plan –

a. The IAVM Plan shall address the NIST 800-53 Risk Assessment Vulnerability Monitoring and Scanning control (RA-5).

b. The IAVM Plan shall document how the contractor monitors and scans for vulnerabilities in the system and hosted applications with frequency, events, and/or randomly defined and when new vulnerabilities potentially affecting the system are identified and reported. The IAVM Plan shall document vulnerability monitoring tools and techniques that facilitate interoperability among tools and automate parts of the vulnerability management process. The IAVM Plan shall document the process for remediating legitimate vulnerabilities for both operational and development environments. The IAVM plan shall document how, what, when, and where to share vulnerability information to help eliminate similar vulnerabilities in other systems and subsystems. The IAVM Plan shall be submitted in conjunction with the System Security Implementation Plan.

c. The purpose of this deliverable is to document compliance to NIST 800-53 control RA-5.

(i) Key and Certificate Management Plan (KCMP) –

a. The KCMP shall be IAW DI-MISC-81688. The template is modified to include a section 3.7, titled Key Storage, which shall detail where each key and certificate is stored through its lifecycle with enumeration between private and public keys and certificates (This includes backups, production facilities, the fielded system and its subsystems, maintenance devices, and other devices which store and use keys and certificates). The template is modified to include a section 3.8, titled Compromise, which will describes what to do if keys become compromised or are suspected to be compromised. Table 2, in section 3.2, of the KCMP template may be changed to better enumerate multiple keys as long as all information from the table remains present. Section 3.4 shall also detail how the keys are generated.

b. KCMP shall document all information related to system keys.

c. The purpose of the KCMP is to provide all necessary information related to system keys.

(j) Plan of Action and Milestones –

a. The POA&M shall be considered a ‘living’ document and shall regularly be updated throughout the entire lifecycle of the System through Decommission. The POA&M shall contain all Not Applicable (N/A) IA Controls, All Non-Compliant IA Controls, and all Vulnerability Findings as identified in the Vulnerability Scans, STIGs, SRGs, and SCAP Benchmarks.

b. The purpose of the POA&M is to track plans of action for issues.

(k) Cyber Security Waiver –

a. Cyber Security Waivers shall include justification for waiver, cost to implement, length of time the waiver is applicable or the period of time to achieve compliance, identification of systems the waiver is applicable to, any analysis of alternatives, any information on tradeoff analysis performed, and other relevant information.

b. Acceptance of this deliverable shall not constitute acceptance nor concurrence of the waiver and does not free the contractor of any contractual obligations.

c. Cyber Security Waiver Requests provide capability for acknowledgement by the PM that compliance to a cybersecurity or set of cybersecurity requirements will not or cannot be achieved for a period of time for the System due to technology or Programmatic constraints.

Appendix A: SSIP Template

System Security Implementation Plan

Date: DAY MONTH YEAR

Distribution Statement A: Approved for public release; distribution is unlimited.

SECURITY NOTICE: Contractor responses to the data requirements are likely to be at the Controlled Unclassified Information (CUI) level. For security related guidance and procedures on how to mark, handle, and transmit classified information, contractors should refer to DoD 5220.22-M National Industrial Security Program Operating Manual, 28 Feb 2006, supporting DD 254, and the OMFV Security Classification Guide (CUI) signed by PEO GCS on 18 February 2021.

All CUI responses should be marked with the following CUI Designation Indicator and Distribution Statement:

Controlled by: the name of the Offeror Company (not required if identified in the letterhead) Controlled by: identification of the office creating the document CUI Category(ies): CTI, EXPT Distribution Statement: D POC: name and phone number or email of POC

DISTRIBUTION STATEMENT D: Distribution authorized to the Department of Defense and U.S. DoD contractors only; Administrative or Operational Use; Export Control; date of determination is 18 February 2021. Other requests for this document shall be referred to the attention of the PM MCS Security Manager at: Program Executive Office Ground Combat Systems (PEO GCS), ATTN: SFAE-GCS-C, 6501 E. 11 Mile Road, Detroit Arsenal, MI 48397-5000.

WARNING - This document contains technical data whose export is restricted by the Arms Export Control Act (Title 22, U.S.C., Sec 2751, et seq.) or the Export Administration Act of 1979, (Title 50, U.S.C., App. 2401 et seq.) as amended. Violations of these export laws are subject to severe criminal penalties. Disseminate IAW provisions of DoD Directive 5230.25.

1. SYSTEM IDENTIFICATION

1.1. System Name/Title: [State the name of the system. Spell out acronyms.]

1.1.1. System Categorization: [Identify FIPS 199 categorization. Spell out acronyms.]

1.1.2. System Unique Identifier: [Insert the System Unique Identifier]

1.1.3. Systems Operational Status: [Operational, Under Development, Major Modification]

1.2. Responsible Organization:

Name:

Address:

Phone:

1.2.1. Information System Owner (Government point of contact responsible for providing and/or receiving CUI):

Name:

Title:

Office Address:

Work Phone:

e-Mail Address:

1.2.1.1. Program Manager:

Name:

Title:

Office Address:

Work Phone:

e-Mail Address:

1.2.1.2. Information System Security Manager:

Name:

Title:

Office Address:

Work Phone:

e-Mail Address:

1.3. General Description/Purpose of System: What is the function/purpose of the system? [Provide a short, high-level description of the function/purpose of the system. Include System Information, System Architecture Description and Diagram, Mission Description, and Concept of Operation.]

1.3.1. End users and privileged users: [In the table below, provide the users and administrators of the system. Include all those with privileged access such as system administrators, database administrators, application administrators, etc. Add rows to define different roles as needed. And define their roles / purpose.]

Roles of Users:

1.4. General Description of Information: CUI information types processed, stored, or transmitted by the system are determined and documented. For more information, see the CUI Registry at https://www.archives.gov/cui/registry/category-list. [Document the CUI information types processed, stored, or transmitted by the system below].

2. SYSTEM ENVIRONMENT

Include a detailed topology narrative and graphic that clearly depicts the system accreditation boundaries, system interconnections, and key devices. (Note: this does not require depicting every workstation or desktop, but include an instance for each operating system in use, an instance for portable components (if applicable), all virtual and physical servers (e.g., file, print, web, database, application), as well as any networked workstations (e.g., Unix, Windows, Mac, Linux), firewalls, routers, switches, copiers, printers, lab equipment, handhelds). If components of other systems that interconnect/interface with this system need to be shown on the diagram, denote the system boundaries by referencing the security plans or names and owners of the other system(s) in the diagram.

[Insert a system topology graphic. Provide a narrative consistent with the graphic that clearly lists and describes each system component.]

2.1. Include or reference a complete and accurate listing of all hardware (a reference to the organizational component inventory database is acceptable) and software (system software and application software) components, including make/OEM, model, version, service packs, and person or role responsible for the component. [Insert the reference/URL or note that the hardware component inventory is attached.]

2.2. List all software components installed on the system. [Insert the reference/URL or note that the software component inventory is attached.]

2.3. Hardware and Software Maintenance and Ownership - Is all hardware and software maintained and owned by the organization? [Yes/No - If no, explain:]

2.4. Countermeasures [Define any countermeasures associated with program protection. If none, write N/A:]

2.5. Ports, Protocols, and Services (PPS) [Define Ports, Protocols, and Services used by the system. include access control lists as applicable.]

2.6. Internal Interfaces and Data Flow [Define all internal interfaces and data flows for the system]

2.7. External Interfaces and Data Flow[Define all external interfaces and data flows for the system. Identify any and all ISA/MOA/MOUs on file and the stakeholders for these ISA/MOA/MOUs.]

2.8. System and Subsystem Configuration Files [Identify and append system and subsystem configuration files]

2.9. Physical Security Measures [Define physical security measures, ex: locks, doors, traps]

3. RECORD OF CHANGES

4. RMF Implementation Plan

(Note: The source of the controls is NIST Special Publication 800-53)

Technical, Policy]

Provide a thorough description of how all of the security requirements are being implemented or planned to be implemented. The description for each security requirement contains: 1) the security requirement number and description; 2) how the security requirement is being implemented or planned to be implemented; and 3) any scoping guidance that has been applied (e.g., compensating mitigations(s) in place due to implementation constraints in lieu of the stated requirement). If the requirement is not applicable to the system, provide rationale. The table may contain all NIST 800-53 controls, or be split into multiple tables by control family.

5. Information Assurance Vulnerability Management (IAVM) Plan

6. Assessment and Authorization (A&A) Project Plan

7. A&A Tasks and Milestones image1.png