Applicable Doc. 01 - Authorization_Requirements_SOP_Guide.pdf

t

Authorization Requirements Standard Operating Procedures Version 1.55

October 13, 2023

OFFICE OF

INFORMATION

SECURITY

O F F I C E O F I N F O R M A T I O N S E C U R I T Y P a g e | 1

Table of Contents 1 Purpose 2 Scope 3 Authorization Prerequisites and Registration

3.1 Application Prerequisites

3.2 System Boundary Guidance

4 Assessment and Authorization Requirements

4.1 Application Hosted On-Premises/VA Network

4.1.1 Security Documentation

4.1.1.1 Configuration Management Plan (CMP)

4.1.1.2 Disaster Recovery Plan (DRP)

4.1.1.3 Incident Response Plan (IRP)

4.1.1.4 Systems-Based Business Impact Analysis (BIA)

4.1.1.5 Information System Contingency Plan (ISCP)

4.1.1.6 Interconnection Security Agreement (ISA)/Memorandum of Understanding

(MOU) 32

4.1.1.7 Privacy Threshold Analysis (PTA)/Privacy Impact Assessment (PIA)

4.1.1.8 Risk Assessment Report (RAR)

4.1.1.9 System Security Plan (SSP)

4.1.1.10 Application Threat Modeling

4.1.2 Technical Scans/Testing Requirements

4.1.2.1 Nessus Scan

4.1.2.2 Database Scan

4.1.2.3 Penetration Test/Application Assessment

4.1.2.4 Security Configuration Compliance Data (SCCD)

4.1.2.5 Control Review

4.2 Application Hosted in Managed Service

4.2.1 Security Documentation

4.2.1.1 Configuration Management Plan (CMP)

4.2.1.2 Disaster Recovery Plan (DRP)

4.2.1.3 Incident Response Plan (IRP)

4.2.1.4 Systems-Based Business Impact Analysis (BIA)

4.2.1.5 Information System Contingency Plan (ISCP)

4.2.1.6 Interconnection Security Agreement (ISA)/Memorandum of Understanding

(MOU) 52

4.2.1.7 Privacy Threshold Analysis (PTA)/Privacy Impact Assessment (PIA)

4.2.1.8 Risk Assessment Report (RAR)

4.2.1.9 System Security Plan (SSP)

4.2.1.10 Application Threat Modeling

4.2.2 Technical Scans/Testing Requirements

4.2.2.1 Nessus Scan

4.2.2.2 Database Scan

4.2.2.3 Penetration Test/Application Assessment

O F F I C E O F I N F O R M A T I O N S E C U R I T Y P a g e | 2

4.2.2.4 Security Configuration Compliance Data (SCCD)

4.2.2.5 Control Review

4.3 Application Hosted in the VA Enterprise Cloud (VAEC)

4.3.1 Security Documentation

4.3.1.1 Configuration Management Plan (CMP)

4.3.1.2 Disaster Recovery Plan (DRP)

4.3.1.3 Incident Response Plan (IRP)

4.3.1.4 Systems-Based Business Impact Analysis (BIA)

4.3.1.5 Information System Contingency Plan (ISCP)

4.3.1.6 Interconnection Security Agreement (ISA)/Memorandum of Understanding

(MOU) 72

4.3.1.7 Privacy Threshold Analysis (PTA)/Privacy Impact Assessment (PIA)

4.3.1.8 Risk Assessment Report (RAR)

4.3.1.9 System Security Plan (SSP)

4.3.1.10 Application Threat Modeling

4.3.2 Technical Scans/Testing Requirements

4.3.2.1 Nessus Scan

4.3.2.2 Database Scan

4.3.2.3 Penetration Test/Application Assessment

4.3.2.4 Security Configuration Compliance Data (SCCD)

4.3.2.5 Control Review

4.4 Application Hosted in FedRAMP Cloud (Non-VAEC)

4.4.1 Security Documentation

4.4.1.1 Configuration Management Plan (CMP)

4.4.1.2 Incident Response Plan (IRP)

4.4.1.3 Systems-Based Business Impact Analysis (BIA)

4.4.1.4 Information System Contingency Plan (ISCP)

4.4.1.5 Interconnection Security Agreement (ISA)/Memorandum of Understanding

(MOU) 92

4.4.1.6 Privacy Threshold Analysis (PTA)/Privacy Impact Assessment (PIA)

4.4.1.7 Risk Assessment Report (RAR)

4.4.1.8 System Security Plan (SSP)

4.4.1.9 Application Threat Modeling

4.4.2 Technical Scans/Testing Requirements

4.4.2.1 Nessus Scan

4.4.2.2 Database Scan

4.4.2.3 Penetration Test/Application Assessment

4.4.2.4 Security Configuration Compliance Data (SCCD)

4.4.2.5 Control Review

4.5 FedRAMP Enterprise or Single Instance Cloud Application (-e and -i Systems)

4.5.1 Security Documentation

4.5.1.1 Configuration Management Plan (CMP)

4.5.1.2 Incident Response Plan (IRP)

4.5.1.3 Systems-Based Business Impact Analysis (BIA)

O F F I C E O F I N F O R M A T I O N S E C U R I T Y P a g e | 3

4.5.1.4 Information System Contingency Plan (ISCP)

4.5.1.5 Interconnection Security Agreement (ISA)/Memorandum of Understanding

(MOU) 111

4.5.1.6 Privacy Threshold Analysis (PTA)/Privacy Impact Assessment (PIA)

4.5.1.7 Risk Assessment Report (RAR)

4.5.1.8 System Security Plan (SSP)

4.5.1.9 Customer Responsibility Matrix/ Control Implementation Summary (CRM/CIS)

4.5.1.10 Application Threat Modeling

4.5.2 Technical Scans/Testing Requirements

4.5.2.1 Control Review

4.6 Facility

4.6.1 Security Documentation

4.6.1.1 Configuration Management Plan (CMP)

4.6.1.2 Disaster Recovery Plan (DRP)

4.6.1.3 Incident Response Plan (IRP)

4.6.1.4 Systems-Based Business Impact Analysis (BIA)

4.6.1.5 Information System Contingency Plan (ISCP)

4.6.1.6 Interconnection Security Agreement (ISA)/Memorandum of Understanding

(MOU) 125

4.6.1.7 Privacy Threshold Analysis (PTA)/Privacy Impact Assessment (PIA)

4.6.1.8 Risk Assessment Report (RAR)

4.6.1.9 System Security Plan (SSP)

4.6.2 Technical Scans/Testing Requirements

4.6.2.1 Nessus Scan

4.6.2.2 Enterprise Discovery Scan (EDS)

4.6.2.3 Security Configuration Compliance Data (SCCD)

4.6.2.4 Control Review

4.7 Medical Devices

4.7.1 Security Documentation

4.7.1.1 Configuration Management Plan (CMP)

4.7.1.2 Disaster Recovery Plan (DRP)

4.7.1.3 Incident Response Plan (IRP)

4.7.1.4 Systems-Based Business Impact Analysis (BIA)

4.7.1.5 Information System Contingency Plan (ISCP)

4.7.1.6 Interconnection Security Agreement (ISA)/Memorandum of Understanding

(MOU) 142

4.7.1.7 Privacy Threshold Analysis (PTA)/Privacy Impact Assessment (PIA)

4.7.1.8 Risk Assessment Report (RAR)

4.7.1.9 System Security Plan (SSP)

4.7.2 Technical Scans/Testing Requirements

4.7.2.1 Nessus Scan

4.7.2.2 Control Review

4.8 Other Federal Agency (Non-eMASS Reciprocity)

O F F I C E O F I N F O R M A T I O N S E C U R I T Y P a g e | 4

4.9 Platform

4.9.1 Security Documentation

4.9.1.1 Configuration Management Plan (CMP)

4.9.1.2 Disaster Recovery Plan (DRP)

4.9.1.3 Incident Response Plan (IRP)

4.9.1.4 Systems-Based Business Impact Analysis (BIA)

4.9.1.5 Information System Contingency Plan (ISCP)

4.9.1.6 Interconnection Security Agreement (ISA)/Memorandum of Understanding

(MOU) 154

4.9.1.7 Privacy Threshold Analysis (PTA)/Privacy Impact Assessment (PIA)

4.9.1.8 Risk Assessment Report (RAR)

4.9.1.9 System Security Plan (SSP)

4.9.2 Technical Scans/Testing Requirements

4.9.2.1 Control Review

5 Appendix A – Acronyms/Definitions 6 Appendix B – Quick Reference Guide – Security Documentation Requirements 7 Appendix C – Quick Reference Guide – Technical/Testing Requirements 8 Appendix D – Common Control Providers/System of Record (SOR)

8.1 VA T1SOR

8.2 VA Enterprise SOR

8.3 VA Area SOR

8.4 Cloud Service Provider SaaS and PaaS SOR

9 Appendix E – New Authorizing Official (AO) Guidelines 10 Appendix F – Quick Reference Guide – Continuous Monitoring 11 Appendix G – Type Authorization

11.1 Process

11.2 Requirements

11.3 Responsibilities

11.3.1 Responsibilities of Originating Organization

11.3.2 Responsibilities of Receiving Organization

11.4 Change Management

11.5 Identical Instance

11.6 Validation of Type Authorization

13. Appendix I – High Priority Controls

13.1 External Connections Controls

O F F I C E O F I N F O R M A T I O N S E C U R I T Y P a g e | 5

Document Revision History

Revision Date Summary of Changes Version Author 7/22/2019 Initial Draft 1.0 OIS 8/23/2019 Second Draft 1.1 OIS 9/13/2019 Third Draft 1.3 OIS 10/11/2019 Fourth Draft 1.4 OIS 11/13/2019 Updated Premier/VA Network and Platform sections

1.5 OIS

12/13/2019 Updated Application Registration (section 3.2)

Changed ‘Secure Code Review’ sections to ‘Application Security Testing’ for all applicable boundaries and updated the steps to complete the requirement

Removed ‘Quality Code Review’ requirement

Changed ‘Secure Design Review’ to ‘Application Threat Modeling’ for all applicable boundaries and updated the steps to complete the requirement

Changed ‘Status of Artifacts’ to ‘Status of Requirements’ and added link to Status of Requirements template (Section 4)

Added Security Impact Analysis (SIA) requirement for systems requiring a major change (Section 4)

1.6 OIS

1/13/2020 Added link for SIA Q&A in Section 4

Updated ‘Security Configuration Compliance Data’ instructions in all SCCD sections

Added Common Control Providers/System of Record (SOR) details (i.e., VA T1SOR, IO SOR, VA Area SOR) in Appendix D and updated SOR verbiage throughout the SOP

Updated all ‘Application Security Testing’ sections with new details on how results are uploaded to eMASS

1.7 OIS

O F F I C E O F I N F O R M A T I O N S E C U R I T Y P a g e | 6

2/12/2020 Created Appendix E – New Authorizing Official

Guidelines

1.8 OIS

3/13/2020 Changed Major Change Form location to KS eMASS Job Aids (Section 4) and added link

Updated verbiage in all technical scan sections to indicate that BOD 19-02 remediation timeline requirements are for Internet accessible systems only

Added the Penetration Test/Application Assessment (WASA) requirement for Managed Service (Section 4.2.2.3) and updated the table in Appendix C

Clarified scan requirements for FedRAMP (Section 4.3.2 and Section 4.4.2)

Revised Step 1 for all Nessus scan sections to include the Hardware/Software SOP

Inserted reference to the eMASS Implementation Guide throughout the SOP

1.9 OIS

4/13/2020 Added reference and link to the VA Cloud Security Procedural Guidance in the FedRAMP cloud Non-VAEC boundary (Section 4.4)

Created Appendix F – Quick Reference Guide – Continuous Monitoring

Changed SCA to Control Assessment to capture security and privacy controls

1.10 OIS

O F F I C E O F I N F O R M A T I O N S E C U R I T Y P a g e | 7

5/13/2020 Specified only one POA&M required for each technical scan requirement. Update is within each technical scan section

Added requirement that FedRAMP systems must have registered system in eMASS for the FedRAMP and the enterprise/VA boundary.

Entry names in eMASS must be same as names listed on FedRAMP.gov. Details in section 4.3 and section 4.4

VAEC link updated with new URL

Added a note in section 4.3.2 and section 4.4.2 to ensure Platform-as-a-Service (PaaS) servers/services are not added to the Hardware and Software system inventory

1.11 OIS

6/12/2020 Updated the SIA paragraph in Section 4

Added CMP template link and template contact information to CMP section for all boundaries except for VAEC and Facility. VAEC already has a template and the Facility CMP template is in progress

Replaced CM-2 reference with CM-9 within the CMP sections. When uploading the CMP to eMASS, CM-9 should be added as the appropriate security control

1.12 OIS

7/13/2020 ISO Responsibilities and Attestation templates have been added to the KS Job Aids page with link included in Section 3.1

Added a Nessus scan section (Section 4.6.2.1) for the Medical Device boundary

1.13 OIS

O F F I C E O F I N F O R M A T I O N S E C U R I T Y P a g e | 8

8/13/2020 Added note to section 2 that VA ATO information should not leave the VA network

Added SCCD requirement to Premier/VA Network boundary (section 4.1.2.6)

Clarified one POA&M item required for each technical scan performed (e.g., new Nessus scan POA&M item required for each monthly scan). Update is within each technical scan section

New section added for Security Boundary Guidance (section 3.3)

1.14 OIS

9/11/2020 Updated ISA/MOU template link 1.15 OIS 10/13/2020 Incorporated latest eMASS update by changing

Risk Review stage to RMF Step 5: Stage 3 in section 3.1

1.16 OIS

11/13/2020 Updated URL for the VAEC homepage through section 4.3

Updated FedRAMP package request email address for VA OIS ESA CSA

Added Platform as a Service (PaaS) clarification/guidance to FedRAMP Cloud VAEC section 4.3.2

Updated URLs for Medical Device Nessus scans in section 4.6.2.1

1.17 OIS

12/11/2020 Added ISRM Compliance contact information (email address) in Section 1

Clarified that ‘system-level’ system stewards assist with REEF mitigation in applicable Nessus scan sections

1.18 OIS

O F F I C E O F I N F O R M A T I O N S E C U R I T Y P a g e | 9

01/13/2021 Clarified in Penetration Test/Application

Assessment sections that VA-CSOC does not perform on-site scans of external systems

Updated requirements for Internet facing applications in Penetration Test/Application Assessment sections

Added SCCD FAQ link in each SCCD section

1.19 OIS

02/11/2021 Updated section 8.1.1.2 to reference name change from VA IO SOR to VA Enterprise SOR (VA ENTSOR). Updated throughout document

Updated Technical Scans section 4.5.2.2 to include new requirement that IA-5.3 will be utilized for POA&M creation where necessary for EDS

Updated URL for Knowledge Service eMASS Job Aids pages in section 4.0 to new SharePoint site

1.20 OIS

3/12/2021 Updated the Note in section 3.1 to add Control Review timeline details for RMF Step 4

Added RMF Step 4 Assessment requirement (GRC Bulletin #48) to all Control Review sections

1.21 OIS

03/24/2021 Added Appendix G Type Authorization 1.22 OIS

O F F I C E O F I N F O R M A T I O N S E C U R I T Y P a g e | 1 0

04/13/2021 Addition of section 4.5; FedRAMP Enterprise

Cloud Application (-e Systems) procedures

Update of Appendix B and C to include FedRAMP Enterprise Cloud Application (-e Systems)

Updated all Penetration Test/Application Assessment sections to remove redundant language “and/or internet facing” in first bullet

Updated all Nessus scan sections to remove step 5 from completion steps

Updated all Application Threat Modeling sections with clarified procedures

Updated all Application Security Testing sections with clarified procedures

Updated Application Registration section 3.2 with clarified procedures

1.23 OIS

O F F I C E O F I N F O R M A T I O N S E C U R I T Y P a g e | 1 1

05/13/2021 Update to all System Security Plan (SSP) sections; Step 3: “The system steward should upload the CCI export to the Artifacts tab within eMASS to be considered an appendix of the SSP. Refer to the eMASS Implementation Guide for additional details”

Update of SOR definition in Appendix D

Updated section 4.3, Application hosted in FedRAMP cloud (VAEC) with additional VA ENTSOR language

Updated section 4.3.2, Technical Scans/Testing Requirements with clarified language and VAEC links

Updated section 4.3.2.6, Security Configuration Compliance Data (SCCD) with PaaS Note

Added IaaS/PaaS to Appendix A0 Acronyms/Definitions table

Added additional section 8.1.1.4, Cloud Service Provider SaaS and PaaS SOR to Appendix D, Common Control Providers/System of Record

(SOR)

Added to section 3.3 Step 10 that devices can only be associated with one FISMA boundary

Added to section 4 that the Status of Requirements should be uploaded to the Artifacts tab in eMASS

Added note in all SCCD sections to address issues reaching the 90% threshold due to offline devices

Added note on how to request an ISSO in section 3.1

1.24 OIS

O F F I C E O F I N F O R M A T I O N S E C U R I T Y P a g e | 1 2

Moved the note in section 3.1 that references the time requirements to be in RMF Step 4 and RMF Step 5: Stage 3 to Section 4

Added note to section 4.4 and section 4.5 that the -F/-VAF and -e packages must be completed simultaneously in eMASS

06/11/2021 All ICAMP links have been updated to reflect current Cloud migration

Specified which CCI to use for POA&M creation to all Nessus scan, Penetration Test/Application Assessment, and Database Scan sections

Moved Application Threat Modeling requirement from Technical Scans/Testing Requirements section to Security Documentation section for each applicable boundary

Updated Appendix B and Appendix C to reflect the Application Threat Modeling change

1.25 OIS

07/13/2021 Updated section 4.3 header from “Application hosted in FedRAMP cloud (VAEC)” to “Application Hosted in the VA Enterprise Cloud

(VAEC)”

Updated section 4.3 “VAEC main page” link to “VAEC Cybersecurity page”

Updated section 4.3 to include additional language regarding applications migrating from Traditional/On-Premises/Hybrid applications

1.26 OIS

O F F I C E O F I N F O R M A T I O N S E C U R I T Y P a g e | 1 3

08/11/2021 Updated sections 11.1.3.1 and 11.1.3.2 in

Appendix G – Type Authorization

Added missing ISCP section to Facility boundary

Updated section 4 to include addition of “Information System Change Requests” and clarified guidance for SIA and Significant/Major Changes

Updated Configuration Management guidance to include VA ITSM change control system guidance for sections 4.1.1.1, 4.2.1.1, 4.3.1.1, 4.4.1.1, 4.5.1.1, and 4.6.1.1

Added ‘IT Service Management (ITSM)’ to Appendix A – Acronyms/Definitions table

Added ‘Software Composition Analysis’ requirement to all applicable Technical Scans/Testing sections. New scan/analysis will be completed during the Application Security Testing process

Updated Appendix C – Quick Reference Guide – Technical/Testing Requirements to include new ‘Software Composition Analysis’ requirement

Updated all references in section 4.6 Facility from “The ISO or system steward” to “The ISO, system steward, or designee”

1.27 OIS

O F F I C E O F I N F O R M A T I O N S E C U R I T Y P a g e | 1 4

09/10/2021 Removed format suggestion in section 4 to eliminate confusion

Added ‘validate’ to all Control Review sections in paragraph 3

Updated step 5 in all SCCD technical scan sections with “SCCD will utilize CCI CM-6.7 for POA&M creation where necessary to keep track of the remediation effort”

Replaced ‘Software Assurance Request’ verbiage with ‘Application Security Support’ in Application Registration section and all Application Security Testing sections

Added language ‘Kotlin’ to supported programming languages in all Software Composition Analysis sections

1.28 OIS

10/13/2021 Added ‘Save As’ filename requirement for all monthly Nessus scan/ICAMP reports along with screen capture of how to ‘Save As’ within ICAMP to all Nessus scan sections (Step 3c)

1.29 OIS

11/12/2021 Added sentence to section 3.3 Step 10 that all lower environments, such as Development and Test, must be added to the Hardware/Software Inventory for vulnerability scanning purposes

Removed ‘Minor Application Self-Assessment’ section. Added reference and link to ‘Minor Assessment Requirements for eMASS SOP’ in second paragraph of section 4

1.30 OIS

O F F I C E O F I N F O R M A T I O N S E C U R I T Y P a g e | 1 5

12/13/2021 Updated all Application Threat Modeling, Application Security Testing, and Software Composition Analysis sections to eliminate confusion between DevSecOps and Non- DevSecOps environments

Added verbiage at beginning of section 4.4 to specify the non-VAEC systems covered in the section

Note added in section 4.5 FedRAMP Enterprise Cloud Application to clarify responsibilities for - F, -VAF, and -e packages

Updated Roles and Responsibilities within CMP section of the Facility boundary

Updated first paragraph in all SCCD sections to include a BigFix alternative if BigFix cannot be installed

1.31 OIS

01/13/2022 Added Appendix H – Provisional ATO Process

Updated verbiage in section 3.3 Step 10 for lower environments

Added link for IRP template in section 4.6.1.3

1.32 OIS

02/11/2022 Updated verbiage in last sentence of the ‘Warning’ box in all Software Composition Analysis sections

1.33 OIS

O F F I C E O F I N F O R M A T I O N S E C U R I T Y P a g e | 1 6

03/11/2022 Clarified responsibilities in sections 4.4 and 4.5 for FedRAMP packages and added single instance (-i) verbiage where appropriate

Updated FedRAMP header in section 4.5 to include Single Instance (-i)

Updated broken links for HW/SW Import SOP throughout document

Changed verbiage in all Control Review sections that states the Control Review team will review a sub-set of the top findings found in OIG audits from the past fiscal year audits

Added note in P-ATO section 12.2 that -F/-VAF packages must be progressed at the same time as -e/-i packages

1.34 OIS

04/13/2022 Updated MOU/ISA team name in all applicable sections

Added Cybersecurity Support request details to Section 3.1

Provided additional clarification to Section 3.3 Step 10

Added single instance (-i) reference to second paragraph of Section 4.4

Updated the Other Federal Agency boundary in Appendix B and Appendix C

Added sentence to the end of Section 4.8 Other Federal Agency with a link to the Reciprocity SOP on Knowledge Service

Added Appendix I – Action Item Release

1.35 OIS

05/13/2022 Updated CSOC Database Scan Questionnaire link in Sections 4.1.2.2, 4.2.2.2, 4.3.2.2, and 4.4.2.2

1.36 OIS

O F F I C E O F I N F O R M A T I O N S E C U R I T Y P a g e | 1 7

06/10/2022 Removed “Note” for DRP and ISCP due to invalid details in sections 4.1.1.2, 4.1.1.4, 4.2.1.2, 4.2.1.4, 4.3.1.2, 4.3.1.4, 4.4.1.2, 4.4.1.4, 4.5.1.3, 4.6.1.2, 4.6.1.4, 4.9.1.1

Updated MOU/ISA portal links in sections 4.1.1.5, 4.2.1.5, 4.3.1.5, 4.4.1.5, 4.5.1.4, 4.6.1.5, 4.7.1.1, 4.9.1.2

1.37 OIS

07/12/2022 Minor formatting adjustments throughout document

1.38 OIS

08/12/2022 All site and report links updated to reflect new Information Central Analytics Metrics Platform (ICAMP) migration to SharePoint Online site

All ICAMP “report export” step and screen captures updated

1.39 OIS

9/13/2022 Updated Appendices B and F to include Disaster Recovery Plan Test, Incident Response Plan Test, and Information System Contingency Plan Test

1.40 OIS

10/13/2022 Added Information System Vulnerability Management Plan (ISVMP) guidance in section 4.

Clarified Test document requirements for FedRAMP systems.

1.41 OIS

11/10/2022 Minor formatting adjustments throughout document

1.42 OIS

12/13/2022 Included link to new Templates section of the eMASS Knowledge Service page

Updated each Security Configuration Compliance Data (SCCD) section to account for the new report requirements

Updated sections 11.1 and 11.2 in Appendix G

– Type Authorization

1.43 OIS

O F F I C E O F I N F O R M A T I O N S E C U R I T Y P a g e | 1 8

01/13/2023 Added Information System Contingency Plan and Business Impact Analysis at a requirement for Medical Devices

Added link to connections, ports, and protocols template

1.44 OIS

02/13/2023 Removed Appendix I – Action Item Release

Updated each section to address ISCP and DRP requirements

Added BIA requirement to each section

Updated Appendices B and F to add the BIA requirement

Updated links to System Owner Attestation and System Owner Responsibilities

Added link in Section 3.1 to the eMASS Account Access Request Policy and Procedure SOP

1.45 OIS

03/13/2023 Fixed broken links; Minor formatting adjustments throughout document

1.46 OIS

04/13/2023 Updated POA&M requirements for sections 4.1.2.1, 4.1.2.2, 4.1.2.3, 4.2.2.1, 4.2.2.2, 4.2.2.3, 4.2.2.6, 4.3.2.2, 4.3.2.3, 4.4.2.1, 4.4.2.2, 4.4.2.3, and 4.6.2.1

Added verbiage to section 4.3 regarding the transition of a traditional system to a cloud system.

Added verbiage to section 4.3.2.2 regarding Database scan requirements

1.47 OIS

O F F I C E O F I N F O R M A T I O N S E C U R I T Y P a g e | 1 9

05/12/2023 Updated sections 4.1.2, 4.2.2, 4.3.2, 4.4.2, 4.5.2, 4.6.2, and 4.9.2 to remove single POA&M requirement.

Updated document requirements for the Reciprocity, Medical Device, and Platform boundaries

Added Cyber Automated Web Scanner (CAWS) verbiage to Enterprise Discovery Scan section

Updated ISA/MOU Sections to address External Connection Controls

Added Appendix I – High Priority Controls

1.48 OIS

06/02/2023 Removed section 3.2 Application Registration

Removed Application Security Test and Software Composition Analysis sections from all boundaries

Updated all Penetration Test/Application Assessment sections for all boundaries

1.49 OIS

06/15/2023 Removed Appendix H – Provisional ATO;

current process is obsolete

Updated links to System Owner Responsibilities and System Owner Attestation

Added requirement to upload the SSP generated in RMF Step 3 Stage 5 to the Artifacts tab in eMASS

Added language regarding scanning requirements for PaaS systems within the VAEC boundary that are containerized

1.50 OIS

07/13/2023 Minor formatting adjustments throughout document

1.51 OIS

08/11/2023 Updated step 5 in all technical scan sections with SCCD to utilize CCI CM-6.5 instead of CM- 6.7

1.52 OIS

O F F I C E O F I N F O R M A T I O N S E C U R I T Y P a g e | 2 0

08/30/2023 Updated all DRP sections to reflect the current process.

Fixed duplication in section 4.9

1.53 OIS

09/13/2023 Minor formatting adjustments throughout document

1.54 OIS

10/13/2023 Minor formatting adjustments throughout document

1.55 OIS

1 Purpose To obtain and maintain a Department of Veterans Affairs’ (VA) Authorization to Operate (ATO), the authorization requirements included within the contents of this document must be completed. Enterprise Mission Assurance Support Service (eMASS), VA’s Governance, Risk and Compliance (GRC) tool, is the authoritative management tool for VA’s Assessment and Authorization (A&A) process and Risk Management Framework. All systems will be assessed in eMASS by the Risk Review team for an authorization recommendation to be submitted to the Authorizing Official (AO) for final ATO consideration. eMASS guidance documentation can be found in the eMASS VA Implementation Guide and eMASS User Guide located on the Help page within eMASS.

This is a living document based on current federal and VA security policies, standards, and guidance, and is subject to change. For any questions regarding the Authorization Requirements SOP Guide for eMASS, please reach out to ISRM Compliance.

2 Scope These procedures apply to systems that are required to obtain an ATO. These systems must be entered into eMASS and be evaluated for potential risk to the VA. The ATO packages/artifacts and any other ATO information should not leave the VA network.

3 Authorization Prerequisites and Registration

3.1 Application Prerequisites

Information System Owners (ISO) for a new information system looking for a determination on an ATO requirement or looking to begin the process to obtain an ATO can submit a request to the GRC Oversight Committee. Follow the steps below to complete the eMASS system pre-registration. For any questions regarding system registration, email the VA OIS GRC Intake Reviewers.

1. Fill out a new Cybersecurity Support request form by going to the Cybersecurity Request Portal.

2. Your request will be reviewed by an intake team for assignment of a new ISSO and the GRC Committee will include the new information system request for discussion on the mailto:vaoisisrmcompliance@va.gov mailto:vaoisgrcintakereviewers@va.gov mailto:vaoisgrcintakereviewers@va.gov https://leaf.va.gov/NATIONAL/103/cybersecurity_request_portal/ https://leaf.va.gov/NATIONAL/103/cybersecurity_request_portal/

O F F I C E O F I N F O R M A T I O N S E C U R I T Y P a g e | 2 1 weekly meeting agenda, scheduled Thursdays at 12:00pm EST. During the meeting, the GRC Committee will approve or deny the information system or request additional information before a decision.

3. Once the GRC Committee approves the new information system request and an eMASS administrator approves the system, an email is automatically generated in eMASS to notify the System Owner or delegate of the approval. The System Owner or delegate must then complete the eMASS system registration. Access to eMASS is required to register a new system.

4. The System Steward completes the eMASS System Registration. The eMASS Account Access Request Policy and Procedure SOP can assist with the registration process. You may also reach out to the ISSO or the VA OIS GRC Intake Reviewers via email with any questions regarding system registration.

5. Once the eMASS system registration has been completed, the GRC Oversight Committee will approve it and the system project team can begin documentation for security and privacy controls and working through the RMF workflow towards an ATO. The ISO must complete the System Owner Responsibilities and the System Owner Attestation documents then upload both to the Artifacts tab within eMASS.

3.2 System Boundary Guidance

The System Boundary needs to be properly represented in eMASS to ensure the system description, environment, architecture, assets, devices, and hardware and software baselines are recorded accurately.

Roles and Responsibilities

The ISO and system steward should work to document the boundary. The ISSO should review and validate in RMF Step 1 – Security Categorization.

Standards / Guidelines

• NIST SP 800-60

• NIST SP 800-53 (CM-8 Information System Component Inventory, and enhancements)

• FIPS 199, FIPS 200

• VA Handbook 6500

• Hardware and Software System Inventory Import SOP – located in Standard Operating

Procedures section of the eMASS Knowledge Service page

Boundary completion steps:

1. On the system information tab, ensure the System Description field is accurate. Provide a narrative description of the system, function, and purpose.

2. On the system information tab, ensure the System Environment field is accurate.

Provide a general description of the technical system. Include the primary hardware, software, and communications equipment. Include any environmental or technical https://dvagov.sharepoint.com/sites/OITOIS/KnowledgeService/eMassDocumentLibrary/eMASS_Account_Access_Request_Policy_and_Procedure_SOP.pdf?CT=1676303220419&OR=Outlook-Body&CID=7A026EFE-CFE8-4911-8751-A62836BC4ABF https://dvagov.sharepoint.com/sites/OITOIS/KnowledgeService/eMassDocumentLibrary/eMASS_Account_Access_Request_Policy_and_Procedure_SOP.pdf?CT=1676303220419&OR=Outlook-Body&CID=7A026EFE-CFE8-4911-8751-A62836BC4ABF https://dvagov.sharepoint.com/sites/OITOIS/KnowledgeService/eMassDocumentLibrary/Information_System_Owner_Responsibilities_Template.pdf%22 https://dvagov.sharepoint.com/sites/OITOIS/KnowledgeService/eMassDocumentLibrary/Information_System_Owner_Attestation_Template.pdf https://vaww.vashare.oit.va.gov/sites/ois/KnowledgeService/Pages/eMASS.aspx

O F F I C E O F I N F O R M A T I O N S E C U R I T Y P a g e | 2 2 factors that raise special security concerns. Include hosting location name (i.e., Amazon, AITC, the name of the vendor data center).

3. On the system information tab, ensure the System Authorization Boundary field is accurate and includes a description of everything within the accreditation boundary of the system. Include Pre-Prod* environments if they will handle production data and ensure to include any minor applications, child applications, and VA custom developed applications covered by the same ATO. Do not include connected system information or systems that are not covered by the scans of this boundary, associated artifacts, or control implementation. (*Note: per step 10, all assets for all lower environments, including the Development, Test, and pre-prod environments, must be added to the Hardware/Software Inventory for vulnerability scanning purposes.)

4. On the system information tab, upload a System Authorization Boundary diagram.

Select “Choose File” to attach related evidence/diagram. The boundary diagram must include:

a. all components included in the system boundary;

b. an authorization boundary drawn around the components indicating that they are within the system’s boundary;

c. any other systems/devices outside of the system’s boundary to which the system is directly connected; and

d. a legend explaining what each shape/icon/line/etc. represents.

5. On the system information tab, ensure the Hardware / Software / Firmware field is accurate. List the Hardware/Software/Firmware used by the system.

6. On the system information tab, ensure the System Enterprise and Information Security Architecture field is accurate. The security architecture field should accurately and completely describe:

a. the required security functionality;

b. the allocation of security controls among physical and logical components; and

c. expresses how individual security functions, mechanisms, and services work together to provide required security capabilities and a unified approach to protection.

7. On the system information tab, upload a System Enterprise and Information Security Architecture diagram. The diagram should include an authorization boundary that:

a. clearly defines services wholly within the boundary;

b. depicts all major components or groups within the boundary;

c. identifies all interconnected systems, including the Agency Access Point (e.g., VA.gov);

d. depicts all major software/virtual components (or groups of) within the boundary; and

e. is validated against the inventory.

8. On the system information tab, ensure the Information Flows / Paths field is accurate.

This field should:

a. identify anywhere Federal data is to be processed, stored, or transmitted;

b. clearly delineate how data comes into and out of the system boundary; and

O F F I C E O F I N F O R M A T I O N S E C U R I T Y P a g e | 2 3

c. depict how all ports, protocols, and services of all inbound and outbound traffic are represented and managed, including the use of definitive Agency DNS.

9. On the system information tab, upload an Information Flows / Paths diagram. The diagram should:

a. identify anywhere Federal data is to be processed, stored, or transmitted;

b. clearly delineate how data comes into and out of the system boundary; and

c. depict how all ports, protocols, and services of all inbound and outbound traffic are represented and managed, including the use of definitive Agency DNS.

10. All systems should complete the Hardware and Software System Inventory Import process to ensure all IPs and host names are properly added to eMASS so that scans and integrations with ICAMP, BigFix, and CDM will function. Instructions can be found in the Hardware and Software System Inventory Import SOP. The SOP can also be found by going to the Standard Operating Procedures section of the eMASS Knowledge Service page. The connections, ports, and protocols Template can be found in the Templates section of the eMASS Knowledge Service page. The ISO or system steward must ensure all hostnames for endpoints that comprise the FISMA boundary are listed in the eMASS Hardware/Software Inventory. The hostnames in the Hardware/Software Inventory must exactly match the hostnames listed in the BigFix Computer Lookup reporting (e.g., “R03AAASQL99” will be considered a different endpoint than “R03AAASQL99.R03.MED.VA.GOV”). Please use the Hardware and Software Inventory Import SOP for managing the Hardware/Software Inventory. Please note, devices can only be associated with one FISMA boundary. If the device or component is shared, it should only be registered with the owning information system responsible for Enclave/OS/Infrastructure ownership and management. Additionally, development assets that process, store, transmit VA data, have an interconnection to a system that has an ATO, and/or external to VA, must be inventoried for vulnerability scanning. These specific types of lower environment assets should already be part of an ATO boundary due to the inclusion of VA sensitive information and/or connection to a production or external to VA environment. All other lower environment assets must also be inventoried for discovery purposes due to being connected to the VA network. These inventory assets should not be included within any part of an ATO process outside of CM- 8 and CM-8(5). They are included solely for discovery purposes at this time. As a reminder, unaccredited lower environments are never allowed to process, store, and/or transmit VA sensitive information without an ATO. All lower environment assets must adhere to VA standards for naming conventions, patching, vulnerability remediation, configuration management, and IP Governance for rapid identification within inventory reports.

11. The BigFix agent must be installed to receive Security Configuration Compliance Data as well as communicate with CDM. Ensure that the BigFix agent is installed/functioning correctly and confirm that your information system/facility endpoints (i.e., servers/workstations) make up the FISMA boundary. A functioning endpoint is one that is actively communicating with the BigFix core servers and has a last-report-time within the last day or two. Please utilize the Computer Lookup reporting to search for endpoints by hostname(s). If an endpoint is found and has a recent last-report-time, https://vaww.vashare.oit.va.gov/sites/ois/KnowledgeService/Pages/eMASS.aspx https://vaww.vashare.oit.va.gov/sites/ois/KnowledgeService/Pages/eMASS.aspx https://vaww.vashare.oit.va.gov/sites/ois/KnowledgeService/Pages/eMASS.aspx https://vaww.vashare.oit.va.gov/sites/ois/KnowledgeService/Pages/eMASS.aspx https://vaww.vashare.oit.va.gov/sites/ois/KnowledgeService/Pages/eMASS.aspx https://dashboard.tic.va.gov/Enterprise-site/Operations-site/Custom-Reports-site/Pages/Computer-Lookup.aspx

O F F I C E O F I N F O R M A T I O N S E C U R I T Y P a g e | 2 4 then the BigFix agent is functioning as expected. Please see the BigFix FAQ for help on installing the BigFix agent. If you need assistance with BigFix, please contact the Enterprise Service Desk (ESD) to enter a ticket and assign it to the OIS EV Support Group.

Contact the ESD by phone at 1-855-673-4357 or online through Your IT Services portal.

Continuous Monitoring Requirement

The system boundary must be updated and validated on an annual basis (90 days for medical devices per CM-8.1) or when any change to the system boundary, devices, hardware, or software baselines occurs. Ensure devices are only associated with one FISMA boundary.

4 Assessment and Authorization Requirements The Authorization Requirements SOP details the technical scans/testing and security documentation requirements for each boundary. Within each boundary section, details are provided for the required security artifacts, including security document requirements, technical/testing requirements, and Federal/VA guidelines. Additional information related to the parties/OIS organization(s) that can provide additional guidance or assistance for each artifact may also be provided. A Status of Requirements, which is located in the Templates section of the eMASS Knowledge Service page, needs to be completed for each ATO package and indicate if a security document and/or technical/testing requirement is applicable or not applicable. The Status of Requirements should provide details on the latest security documentation and technical/testing requirement results or explain why each security document and/or technical/testing requirement is not applicable or not completed. Once the Status of Requirements is completed, it should be uploaded to the Artifacts tab within eMASS.

Security artifacts should not be password protected. eMASS limits access to personnel with a need to view the system details and security artifacts.

For items related to Minor Applications in eMASS, please refer to the eMASS Minor Application Assessment Guide.

Information System Change Requests

According to NIST 800-128; Guide for Security-Focused Configuration Management of Information Systems, a Security Impact Analysis (SIA) is incorporated into the configuration management process to ensure the impact of all changes are documented, analyzed, and evaluated for any adverse impacts on the security posture of the system.

To ensure that the changes have been implemented as approved, a SIA is performed as a part of the Configuration Management Plan (CMP) and supports the implementation of NIST [SP 800-53] control CM-4 and any potential enhancements. If the SIA identifies a significant change(s), the system is required to submit this artifact as part of the CM/CR Process prior to the change going into operation.

Note: Questions about the system boundary guidance or processes should be directed to ISRM.

https://dashboard.tic.va.gov/Docs/Pages/BigFix-FAQ.aspx https://yourit.va.gov/va?id=va_home https://vaww.vashare.oit.va.gov/sites/ois/KnowledgeService/Pages/eMASS.aspx https://dvagov.sharepoint.com/sites/OITOIS/KnowledgeService/eMassDocumentLibrary/eMASS_Minor_Application_Assessment_Standard_Operating_Procedure.pdf https://dvagov.sharepoint.com/sites/OITOIS/KnowledgeService/eMassDocumentLibrary/eMASS_Minor_Application_Assessment_Standard_Operating_Procedure.pdf https://csrc.nist.gov/news/2019/nist-updates-sp-800-128 https://csrc.nist.gov/news/2019/nist-updates-sp-800-128 mailto:vaoisisrmrmf@va.gov

O F F I C E O F I N F O R M A T I O N S E C U R I T Y P a g e | 2 5

Steps for Security Impact Analysis (SIA)

1. Retrieve Major SIA Template from the Templates section of the eMASS Knowledge Service page.

2. Fill out all requested tab information regarding systems current security posture and change details.

3. Submit completed SIA form to the VAOISSIATeam@va.gov for ISRM review.

4. Receive competed SIA spreadsheet with completed Summary Memo detailing the extent changes affect the security posture of the system in relation to the functionality of existing security controls and organizational risk tolerance.

Additional guidance and templates related to SIAs may be found on the Knowledge Service eMASS Job Aids page.

Completion Steps for a Significant/Major Change

If the SIA identifies a significant change(s), the system is required to submit this artifact as part of the CM/CR Process prior to the change going into operation. Once the SIA is completed, reviewed, and returned:

1. The completed SIA must be uploaded to the Artifacts tab in eMASS. The Information System Owner (ISO) is responsible for reviewing this artifact.

2. A completed and signed Significant/Major Change Notification Form should be uploaded to the Artifacts tab in eMASS at least 45 days prior to implementation of the change.

3. According to VA Handbook 6500; Risk Management Framework For VA Information Systems VA Information Security Program, “formal reauthorization is required whenever a system undergoes a significant change or when there is a major change in the information collected or maintained”.

All RMF steps in eMASS must be completed and all security artifacts need to be updated to reflect the change. To restart the RMF Process in eMASS, please refer to this Authorization Requirements SOP or eMASS Implementation Guide for additional guidance.

Note: For eMASS, the applicable system POCs must request the AODR initiate RMF Step 4 and advance/release controls to the Control Assessor no later than 70 days prior to the Authorization Termination Date (ATD) and/or the scheduled Control Review. The Control Review will be completed within 15 days with the results uploaded to the Artifacts tab in eMASS and the Control Review Team notifying the system stakeholders to close out RMF Step 4.

Additionally, the applicable system POCs must have their authorization package completed and progressed to RMF Step 5 Authorize: Stage 3 Risk Review in the workflow no less than 45 calendar days prior to the ATD or date they want their authorization decision to be made if requesting an out of cycle ATO review due to a major change. Once the package has been progressed, a package snapshot will be taken within eMASS for the Risk Review team to analyze for an ATO. After https://vaww.vashare.oit.va.gov/sites/ois/KnowledgeService/Pages/eMASS.aspx https://vaww.vashare.oit.va.gov/sites/ois/KnowledgeService/Pages/eMASS.aspx mailto:VAOISSIATeam@va.gov https://dvagov.sharepoint.com/sites/OITOIS/KnowledgeService/Pages/eMASS-JobAids.aspx https://dvagov.sharepoint.com/sites/OITOIS/KnowledgeService/Pages/eMASS-JobAids.aspx https://gcc02.safelinks.protection.outlook.com/ap/w-59584e83/?url=https%3A%2F%2Fdvagov.sharepoint.com%2Fsites%2FOITOIS%2FKnowledgeService%2FeMassDocumentLibrary%2FMajor_Change_Form-06122020.docx%3FWeb%3D1&data=04%7C01%7C%7C9b0db0a6d18f4c89854f08d9250e45ec%7Ce95f1b23abaf45ee821db7ab251ab3bf%7C0%7C0%7C637581565487592092%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=ok8f0RKomaAuU4ClI3jXNBsBvx6AqxpEl7mT6FT5KAs%3D&reserved=0 https://www.va.gov/vapubs/viewPublication.asp?Pub_ID=1255&FType=2 https://www.va.gov/vapubs/viewPublication.asp?Pub_ID=1255&FType=2

O F F I C E O F I N F O R M A T I O N S E C U R I T Y P a g e | 2 6

Information System Vulnerability Management Plan (ISVMP) The Information System Vulnerability Management Plan (ISVMP) establishes a plan for the communication and orchestration of vulnerability management practices at the system-level. It identifies vulnerability management roles and responsibilities, resources, processes, and standards to ensure vulnerabilities are managed throughout the information systems life cycle.

ISVMP guidance is provided below.

Roles and Responsibilities

The ISVMP template can be found on the EVMP Knowledge Service (KS) main page.

1. The ISO and system steward should work with the ISSO and applicable service lines, stakeholders, and vendors (if applicable), to complete the ISVMP template.

2. The ISO should validate processes adhere to the ISVMP lifecycles for assessing, prioritizing, remediating, mitigating, and re-assessing vulnerabilities.

3. The ISVMP should include remediation points of contact for those personnel responsible for supporting the remediation activities of the information system and information system components.

Standards / Guidelines

• NIST Cyber Security Framework

• Gartner Vulnerability Management Cycle

• VA Handbook 6500

• POAM Management Guide

• Flaw Remediation SOP

• Vulnerability Management Memo

Completion Steps

1. The ISO and system steward works with the ISSO to complete the ISVMP template.

2. Once the ISVMP template is complete, the ISO or system steward uploads the ISVMP to the Artifacts tab in eMASS, and links to the appropriate security control (SI-2.12) for the ISVMP.

Continuous Monitoring Requirement

The ISVMP must be updated on an annual basis or when a significant/major change to the system occurs.

progressing the system to RMF Step 5 Authorize: Stage 3 Risk Review, the system POCs should continue to work on the system requirements within eMASS. Any progress made after the package snapshot will not be able to be viewed by the Risk Review team during their review.

https://dvagov.sharepoint.com/sites/EVMS-PSSTProjects/Shared%20Documents/ISVMP/ISVMP%20Final%20Deliverables/V06554055_Information%20System%20Vulnerability%20Management%20Plan%20(ISVMP)%20and%20Template_Signed.pdf?CT=1651254250295&OR=ItemsView https://dvagov.sharepoint.com/sites/OITOIS/KnowledgeService/Pages/EVMP.aspx

O F F I C E O F I N F O R M A T I O N S E C U R I T Y P a g e | 2 7

4.1 Application Hosted On-Premises/VA Network

The On-Premises/VA Network includes applications that are VA managed and utilize an OS platform such as Window, UNIX, or Mainframe. A&A requirements for VAEC and other FedRAMP Cloud applications are addressed separately. Please refer to section 3.2 for Security Boundary Guidance.

Applications on the On-Premises/VA Network may choose to inherit common control providers from the VA Tier 1 System of Record (T1SOR) and VA Enterprise SOR (VA ENTSOR). Appendix D

– Common Control Providers/System of Record (SOR) for complete details to help determine if the VA T1SOR or VA ENTSOR is applicable.

4.1.1 Security Documentation

The following sections provide details for each of the required security artifacts including the document requirements, references, and the parties that can provide additional guidance for each artifact. If available, templates for the applicable security artifacts/documents are located in the Templates section of the eMASS Knowledge Service page.

An artifact that is generated through eMASS as part of the authorization package and is reviewed/approved by the ISO and/or Information System Security Officer (ISSO) in the eMASS workflow as part of the authorization package may not require signature(s) and may be valid without signature(s). Contact your ISSO with questions on how to complete the documentation.

4.1.1.1 Configuration Management Plan (CMP)

The Configuration Management Plan (CMP) identifies configuration management roles and responsibilities, resources, and processes to ensure any changes are evaluated and approved before implementation. CMP guidance is provided below.

As part of the normal configuration/change management of an information system, change requests are entered into the authorized VA IT Service Management (ITSM) change control system, Your IT Services, for review, approval, and implementation by the appropriate VA OIT organizations or service providers.

Roles and Responsibilities

The CMP template should be used to complete the CMP and is available in the VA OIT Service Management Office’s Process Asset Library (PAL). The ISO or system steward should work with the ISSO to complete the CMP.

Standards / Guidelines

• NIST SP 800-128

• NIST SP 800-53 (CM-9 Configuration Management Plan)

• VA Handbook 6500

• The CMP should include processes for managing configuration and change management.

• The CMP should include infrastructure servers that support the system.

https://vaww.vashare.oit.va.gov/sites/ois/KnowledgeService/Pages/eMASS.aspx https://yourit.va.gov/va https://vaww.oed.wss.va.gov/process/Library/configuration_management_plan_template.docx https://vaww.oed.wss.va.gov/process/Library/Forms/Customer.aspx

O F F I C E O F I N F O R M A T I O N S E C U R I T Y P a g e | 2 8

• The CMP should include a current configuration baseline detailing hardware and software associated with the system. Network devices do not apply.

Completion Steps

1. The ISO/system steward works with the ISSO to complete the CMP.

2. Once the CMP is complete, the ISO or system steward uploads the CMP to the Artifacts tab in eMASS, and links to the appropriate security control (CM-9) for the Configuration Management Plan.

Continuous Monitoring Requirement

The CMP must be updated on an annual basis or when a significant/major change to the system occurs.

4.1.1.2 Disaster Recovery Plan (DRP)

Disaster Recovery planning refers to measures to recover information system services to an alternate location after a disruption. Plans are based upon current boundaries established by the Office of Information Security (OIS). Each year the OIS Information System Business Continuity Office (OIS ISBC) will monitor systems to make sure they maintain the annual review requirements. DRP guidance is provided below.

Roles and Responsibilities

• OIS ISBC is the Office of Primary Responsibility (OPR) for oversight of planning and testing of system level DRPs.

• The ISO or system steward works with the assigned ISSO and DRP Director to create or revise the DRP.

• NIST Special Publication 800-34 Rev. 1 – Contingency Planning Guide for Federal Information Systems

• NIST SP 800-53 (CP-2 Contingency Plan)

• VA Handbook 6500

• VA Handbook 6500.8 Information System Contingency Planning

Completi…