Attachment 1 Office of Information Security Authorization requirements.pdf

Authorization Requirements Standard Operating Procedures Version 1.14

August 13, 2020

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

Table of Contents

1 Purpose

2 Scope

3 Authorization Prerequisites and Registration

3.1 Application Prerequisites

3.2 Application Registration

3.3 System Boundary Guidance

4 Assessment and Authorization Requirements

4.1 Application hosted on Premier/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 Information Security Contingency Plan (ISCP)

4.1.1.5 Interconnection Security Agreement (ISA)/Memorandum of Understanding

(MOU)

4.1.1.6 Minor Application Self-Assessment

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.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 Application Security Testing

4.1.2.5 Application Threat Modeling

4.1.2.6 Security Configuration Compliance Data (SCCD)

4.1.2.7 Control Assessment

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 Information Security Contingency Plan (ISCP)

4.2.1.5 Interconnection Security Agreement (ISA)/Memorandum of Understanding

(MOU)

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

4.2.1.7 Risk Assessment Report (RAR)

4.2.1.8 System Security Plan (SSP)

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

4.2.2.4 Application Security Testing

4.2.2.5 Application Threat Modeling

4.2.2.6 Security Configuration Compliance Data (SCCD)

4.2.2.7 Control Assessment

4.3 Application hosted in FedRAMP 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 Information Security Contingency Plan (ISCP)

4.3.1.5 Interconnection Security Agreement (ISA)/Memorandum of Understanding

(MOU)

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

4.3.1.7 Risk Assessment Report (RAR)

4.3.1.8 System Security Plan (SSP)

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 Application Security Testing

4.3.2.5 Application Threat Modeling

4.3.2.6 Security Configuration Compliance Data (SCCD)

4.3.2.7 Control Assessment

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 Disaster Recovery Plan (DRP)

4.4.1.3 Incident Response Plan (IRP)

4.4.1.4 Information Security Contingency Plan (ISCP)

4.4.1.5 Interconnection Security Agreement (ISA)/Memorandum of Understanding

(MOU)

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.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 Application Security Testing

4.4.2.5 Application Threat Modeling

4.4.2.6 Security Configuration Compliance Data (SCCD)

4.4.2.7 Control Assessment

4.5 Facility

4.5.1 Security Documentation

4.5.1.1 Configuration Management Plan (CMP)

4.5.1.2 Disaster Recovery Plan (DRP)

4.5.1.3 Incident Response Plan (IRP)

4.5.1.4 Interconnection Security Agreement (ISA)/Memorandum of Understanding

(MOU)

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

4.5.1.6 Risk Assessment Report (RAR)

4.5.1.7 System Security Plan (SSP)

4.5.2 Technical Scans/Testing Requirements

4.5.2.1 Nessus Scan

4.5.2.2 Enterprise Discovery Scan (EDS)

4.5.2.3 Security Configuration Compliance Data (SCCD)

4.5.2.4 Control Assessment

4.6 Medical Devices

4.6.1 Security Documentation

4.6.1.1 Interconnection Security Agreement (ISA)/Memorandum of Understanding

(MOU)

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

4.6.1.3 Risk Assessment Report (RAR)

4.6.1.4 System Security Plan (SSP)

4.6.2 Technical Scans/Testing Requirements

4.6.2.1 Nessus Scan

4.6.2.2 Control Assessment

4.7 Other Federal Agency (Non-eMASS Reciprocity)

4.8 Platform

4.8.1 Security Documentation

4.8.1.1 Information Security Contingency Plan (ISCP)

4.8.1.2 Interconnection Security Agreement (ISA)/Memorandum of Understanding

(MOU)

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

4.8.1.4 Risk Assessment Report (RAR)

4.8.1.5 System Security Plan (SSP)

4.8.2 Technical Scans/Testing Requirements

4.8.2.1 Control Assessment

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.1.1 VA T1SOR

8.1.1.2 IO SOR

8.1.1.3 VA Area SOR

9 Appendix E – New Authorizing Official (AO) Guidelines

10 Appendix F – Quick Reference Guide – Continuous Monitoring

Document Revision History

Revision Date Summary of Changes Version Author

7/22/19 Initial Draft 1.0 OIS

8/23/19 Second Draft 1.1 OIS

9/13/19 Third Draft 1.3 OIS

10/11/19 Fourth Draft 1.4 OIS

11/13/19 Updated Premier/VA Network and Platform sections

1.5 OIS

12/13/19 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/20 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

2/12/20 Created Appendix E – New Authorizing Official Guidelines

1.8 OIS

3/13/20 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/20 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

5/13/20 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/20 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/20 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

8/13/20 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

1 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

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.

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 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 GRC Oversight Committee.

1. Fill out the eMASS pre-registration SharePoint request form by going to the eMASS Pre- Registration and clicking new item.

2. The GRC Committee will include the new information system request for discussion on the 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 System Steward eMASS job aid can assist with the registration process. You may also reach out to the mailto:vacooisigoc@va.gov mailto:vacooisigoc@va.gov https://urldefense.proofpoint.com/v2/url?u=https-3A__vaww.portal2.va.gov_sites_infosecurity_ca_ISRM_Operations_-5Flayouts_15_start.aspx-23_Lists_eMASS-2520PreRegistration_AllItems.aspx&d=DwMFAg&c=f4NRRID3zFYDyClb0wZXwA&r=8rnI4fczjEQuBHQL4wcBVJQBngG2CW85eAetVoH2qJY&m=IMux4xV7RqisUmIksCkMH5GOXHRENUr9zDcmLoCsXGI&s=9ExDen2mvkSCUu49Z6bIy6IIJ0vj2SmNAXmksb-Xc8c&e= https://urldefense.proofpoint.com/v2/url?u=https-3A__vaww.portal2.va.gov_sites_infosecurity_ca_ISRM_Operations_-5Flayouts_15_start.aspx-23_Lists_eMASS-2520PreRegistration_AllItems.aspx&d=DwMFAg&c=f4NRRID3zFYDyClb0wZXwA&r=8rnI4fczjEQuBHQL4wcBVJQBngG2CW85eAetVoH2qJY&m=IMux4xV7RqisUmIksCkMH5GOXHRENUr9zDcmLoCsXGI&s=9ExDen2mvkSCUu49Z6bIy6IIJ0vj2SmNAXmksb-Xc8c&e= https://vaww.vashare.oit.va.gov/sites/ois/KnowledgeService/eMASS%20Documents/eMASS%20Training%20Materials/eMASS_SystemSteward_Job_Aid.pdf https://vaww.vashare.oit.va.gov/sites/ois/KnowledgeService/eMASS%20Documents/eMASS%20Training%20Materials/eMASS_SystemSteward_Job_Aid.pdf

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

ISSO or the GRC Oversight Committee 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 Application Registration

Custom-developed VA applications, and sometimes Commercial Off The Shelf (COTS) and

Software as a Service (SaaS) applications, are required to be registered with the VA Software

Assurance Program Office. Registration is necessary to maintain an inventory of the total population of VA applications, by type and business line, according to the VA Common

Application Enumeration (CAE) to ensure application-level security considerations are taken into account when determining readiness and performance.

Application registration guidance is provided below:

• VA application developers are responsible for registering custom-developed applications

• Custom-developed VA applications are required to be registered with software assurance

• COTS may be registered with software assurance at the direction of CSOC

• Software as a Service (SaaS) should follow COTS registration procedures

• Registration is required as a prerequisite to both software assurance application security testing validation and CSOC penetration test / application assessment testing

• This requirement is not applicable to VistA systems

Application registration completion steps:

1. Navigate to the Your IT Services portal using your web browser

2. Click on Make a Request on the home page

3. Click on the Vulnerability Management category

Note: For eMASS, the applicable system POCs must have their authorization package completed and progressed to RMF Step 5 Authorize: Stage 4 Risk Review in the workflow no less than 45 calendar days prior to the date they want their authorization decision to be made. 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 progressing the system to RMF Step 5 Authorize: Stage 4 Risk Review, the system POCs should continue to work on the system requirements within eMASS. Any progress made after the package snapshot will be able to be viewed by the Risk Review team during their review.

mailto:vacooisigoc@va.gov https://vaww.vashare.oit.va.gov/sites/ois/KnowledgeService/Pages/eMASS-JobAids.aspx https://vaww.vashare.oit.va.gov/sites/ois/KnowledgeService/Pages/eMASS-JobAids.aspx https://wiki.mobilehealth.va.gov/display/OISSWA/Common+Application+Enumeration https://wiki.mobilehealth.va.gov/display/OISSWA/Common+Application+Enumeration https://yourit.va.gov/va

3 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

4. Click on Software Assurance Request item

5. Fill out the form and select Application Registration in the Services Request field

6. Fill out this PDF form and attach it to the request using the Add attachments link

7. Click on the Submit button

8. Make a note of your ticket's request number

After the request has been made, a VA Software Assurance Program team member will follow

up. You can view this ticket, or any of your open tickets, through Your IT Services portal.

3.3 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

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 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.

https://wiki.mobilehealth.va.gov/download/attachments/24482308/VA%20Application%20Registration%20Request%20Form.pdf?api=v2 https://vaww.vashare.oit.va.gov/sites/ois/KnowledgeService/Pages/eMASS.aspx

4 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

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

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.

5 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

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 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.

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, then the BigFix agent is functioning as expected. 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 at YourIT.

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.

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 on the Knowledge Service eMASS Job Aids 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

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

https://vaww.vashare.oit.va.gov/sites/ois/KnowledgeService/eMASS%20Documents/Hardware%20and%20Software%20System%20Inventory%20Import%20SOP.pdf https://vaww.vashare.oit.va.gov/sites/ois/KnowledgeService/Pages/eMASS.aspx https://vaww.vashare.oit.va.gov/sites/ois/KnowledgeService/eMASS%20Documents/Hardware%20and%20Software%20System%20Inventory%20Import%20SOP.pdf https://vaww.vashare.oit.va.gov/sites/ois/KnowledgeService/eMASS%20Documents/Hardware%20and%20Software%20System%20Inventory%20Import%20SOP.pdf https://dashboard.tic.va.gov/Docs/Pages/BigFix-FAQ.aspx https://dashboard.tic.va.gov/Enterprise-site/Operations-site/Custom-Reports-site/Pages/Computer-Lookup.aspx https://vaww.oit.va.gov/yourit/ https://vaww.vashare.oit.va.gov/sites/ois/KnowledgeService/Pages/eMASS-JobAids.aspx mailto:vaoisisrmrmf@va.gov

6 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 technical/testing requirement results or explain why each security document and/or technical/testing requirement is not applicable or not completed. Each security artifact uploaded to eMASS should be named using the following format:

SystemNameORAcronym_ArtifactName. To clearly identify the latest technical scans/testing results, all technical scans/testing results that have been completed for an authorization package should be uploaded together in a zip file using the following format:

SystemNameORAcronym_TechnicalScans. For a technical scan/testing result that’s completed monthly or quarterly for continuous monitoring, the results should be put into a zip file and uploaded to the Artifacts tab in eMASS using the following format:

SystemNameORAcronym_TechnicalScanName. Additionally, when the user initiates a new Assess and Authorize package/workflow, a Package Name is required. The Package Name should utilize the following format: SystemNameORAcronym_MMYYYY. Once the workflow completes, the package is added to the Historical Package Listing with the Package Name.

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

If a system submits a change request, the security impact analysis (SIA) must be completed and submitted prior to the change request determination. This is required for all FIPS 199 impact level systems and found in CM-4 of VA Handbook 6500. If the system undergoes a significant change or if there is a major change in the information collected or maintained, then the system is required to complete the authorization process and complete an SIA prior to the change going into operation. Details on completing an SIA can be found within the SIA FAQ on the Knowledge Service Job Aids page. All RMF Steps in eMASS must be completed and all security artifacts need to be updated to reflect the change.

4.1 Application hosted on Premier/VA Network

The Premier/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.3 for Security Boundary

Guidance.

Applications on the Premier/VA Network may choose to inherit common control providers from the VA Tier 1 System of Record (T1SOR) and Infrastructure Operations (IO) SOR. Refer to

Appendix D – Common Control Providers/System of Record (SOR) for complete details to help determine if the VA T1SOR or IO SOR 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, template locations for the applicable security artifacts/documents are provided.

7 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

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.

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.

• 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.

Note: System Level Configuration Management Plans are under the governance of the VA OIT Service Management Office (SMO), Service Configuration Management organization, which collaborates with the Enterprise Program Management Division (EPMD), for continuous maintenance of the template and the availability to the enterprise. Please reach out to the OIT SMO ECRCM Service Configuration Management Staff for any questions about the CMP.

https://vaww.oed.wss.va.gov/process/Library/configuration_management_plan_template.docx https://vaww.oed.wss.va.gov/process/Library/Forms/Customer.aspx mailto:OITSMOECRCMServiceConfigurationMgmtstaff@va.gov

8 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

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

OIS. Each year Emergency Preparedness & Response (EPR) will provide planning and testing guidance through an action item. DRP guidance is provided below.

Roles and Responsibilities

• Emergency Preparedness & Response (EPR) underneath DR/COOP is the Office of

Primary Responsibility (OPR) for planning and testing of plans.

• Plans are based upon current boundaries established by OIS. Each year EPR will provide planning and testing guidance through an action item.

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

Standards / Guidelines

• 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 Contingency Planning

Completion Steps

1. During RMF Step 1 within eMASS, the ISO or system steward will be prompted to indicate whether an DRP is required. If yes, then the ISO or system steward will be required to upload the DRP to eMASS.

2. The ISO or system steward develops or revises the DRP using the applicable standards and guidelines.

3. Once completed and tested, the ISO or system steward uploads the signed DRP to eMASS by going to System > Details > FISMA. By uploading the security document to the

FISMA tab, eMASS will automatically add the document to the Artifacts tab and map it to controls. Once uploaded to the FISMA tab, it can be managed (e.g., newer versions) within the Artifacts tab by clicking the Artifact Name. The security document within the

FISMA tab should not be deleted or the security document and the history will be deleted.

4. Once the DRP has been uploaded to the FISMA tab, the ISO or system steward must ensure that all documents are appropriately associated as evidence to the relevant security controls and CCIs. To verify, go to the Artifacts tab, click on the Artifact Name, and then click Edit Artifact to add in more security controls or CCIs. Refer to the eMASS

Implementation Guide for additional details.

Continuous Monitoring Requirement

9 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

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

4.1.1.3 Incident Response Plan (IRP)

An IRP is necessary for rapidly detecting incidents, minimizing loss and destruction, mitigating weaknesses that were exploited, and restoring computing services. IRP guidance is provided below.

Roles and Responsibilities

• Facilities are responsible for completing the IRP. Systems should upload the facility IRP with the system name added to the title page to indicate the system utilizes the facility

IRP.

• The ISO or system steward works with the assigned ISSO to create or revise the IRP.

• Each site is responsible for developing local level procedures incorporating VA-CSOC area of responsibility.

• NIST SP 800-61

• NIST SP 800-53 (IR-8 Incident Response Plan) indicate whether an IRP is required. If yes, then the ISO or system steward will be required to upload the IRP to eMASS.

2. The System Owner or delegate develops or revises the IRP using the applicable standards and guidelines.

3. Once completed and tested, the ISO or system steward uploads the signed IRP to eMASS by going to System > Details > FISMA. By uploading the security document to the FISMA tab, eMASS will automatically add the document to the Artifacts tab and map it to controls. Once uploaded to the FISMA tab, it can be managed (e.g., newer versions) within the Artifacts tab by clicking the Artifact Name. The security document within the

FISMA tab should not be deleted or the security document and the history will be deleted.

Note: Questions about the planning process, plan templates, or testing process should contact the EPR team.

mailto:OITITOPSSPECOECCDRCOOPAllStaff@va.gov

10 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

4. Once the IRP has been uploaded to the FISMA tab, the ISO or system steward must ensure that all documents are appropriately associated as evidence to the relevant security controls and CCIs. To verify, go to the Artifacts tab, click on the Artifact Name, and then click Edit Artifact to add in more security controls or CCIs. Refer to the eMASS

Implementation Guide for additional details.

Continuous Monitoring

The IRP must be tested and updated annually or when a significant/major change to the system occurs.

4.1.1.4 Information Security Contingency Plan (ISCP)

Contingency planning refers to interim measures to recover information system services after a disruption. Interim measures may include relocation of information systems and service to an alternate site. Plans are based upon current boundaries established by OIS. Each year EPR will provide planning and testing guidance through an action item. ISCP guidance is provided below.

Roles and Responsibilities

• Emergency Preparedness & Response (EPR) underneath DR/COOP is the Office of

Primary Responsibility (OPR) for planning and testing of plans.

• The ISO or system steward works with the assigned ISSO to create or revise the ISCP.

Information Systems

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

• VA Handbook 6500.8 Information System Contingency Planning indicate whether an ISCP is required. If yes, then the ISO or system steward will be required to upload the ISCP to eMASS.

2. The ISO or system steward develops or revises the ISCP using the applicable standards and guidelines.

3. Once completed and tested, the ISO or system steward uploads the signed ISCP to eMASS by going to System > Details > FISMA. By uploading the security document to the

FISMA tab, eMASS will automatically add the document to the Artifacts tab and map it to controls. Once uploaded to the FISMA tab, it can be managed (e.g., newer versions) within the Artifacts tab by clicking the Artifact Name. The security document within the

11 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

FISMA tab should not be deleted or the security document and the history will be deleted.

4. Once the ISCP has been uploaded to the FISMA tab, the ISO or system steward must ensure that all documents are appropriately associated as evidence to the relevant security controls and CCIs. To verify, go to the Artifacts tab, click on the Artifact Name, and then click Edit Artifact to add in more security controls or CCIs. Refer to the eMASS

Implementation Guide for additional details.

Continuous Monitoring Requirement

The ISCP must be tested and updated on an annual basis or when a significant/major change in the system occurs.

4.1.1.5 Interconnection Security Agreement (ISA)/Memorandum of Understanding (MOU)

Before an external connection is established with the VA, a Memorandum of Understanding

(MOU)/Interconnection Security Agreement (ISA) is required to authorize a connection between information systems that do not share the same Authorizing Official. An ISA/MOU must be provided for all external interconnections.

Roles and Responsibilities

• The ISO, in coordination with the entities identified in NIST SP 800-47, will complete the

ISA/MOU.

• A VA review team will assess the documents against a checklist for quality and content.

• The reviewer will work with the ISSO to ensure no documentation deficiencies and notify the ISSO when the document is ready for signatures.

• The ISSO will obtain the appropriate signatures.

• The ISSO will upload the document to the Enterprise Document SharePoint and to the

Artifacts tab within eMASS. The ISO or system steward should ensure the correct

Artifact Category and Type are selected when uploading to the Artifacts tab.

• NIST SP 800-47

12 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

1. The ISO, in coordination with the entities identified in NIST SP 800-47, will complete the MOU/ISA using the latest template provided at: MOU ISA Template.

2. ISSO will upload all final draft MOU/ISA documents to the MOU ISA Document Portal.

a. The MOU/ISA Intake Portal User Guide is located on the MOU ISA Document Portal.

3. The Business Requirements MOU/ISA Review Team will assess the documents for quality, content and security.

4. The Business Requirements Division (BRD) reviewer(s) and the ISSO will work collaboratively with the ISO/COR to correct deficiencies found in the documentation.

5. Once all deficiencies have been corrected and accepted, the BRD reviewer will notify the ISSO via email that the document is ready for signatures.

6. The ISSO will route the document for signatures.

7. Upon receipt of the completed and signed MOU/ISA document, the ISSO will upload the document using the Publish a Signed Document feature on the MOU ISA Document Portal.

8. The finalized documents with signatures are linked to the appropriate security controls (CA-3, SA-9) and uploaded to the Artifacts tab within eMASS.

Continuous Monitoring Requirement

The MOU/ISA Annual Review Sheet must be completed annually based on the date of the last signature on the MOU/ISA. If there is a significant change that impacts the architecture as documented, please contact the Business Requirements Division.

4.1.1.6 Minor Application Self-Assessment

Minor applications refer to information systems that rely on an underlying host information system for most of its security controls. A minor application must be associated with another system/application and cannot fall under a facility or a platform.

All minor applications are required to complete the Minor Application Self-Assessment. The

Minor Application Self-Assessment must be uploaded to the Artifacts tab within eMASS under the associated system/Major Application.

4.1.1.7 Privacy Threshold Analysis (PTA)/Privacy Impact Assessment (PIA) All ISOs or system stewards must work with the VA Privacy Services Office to complete a PTA for each system. During RMF Step 1 within eMASS, the ISO or system steward will be prompted to indicate whether a PTA/PIA is required. If yes, then the ISO or system steward will be required to upload the PTA/PIA to the Artifacts tab within eMASS.

Privacy Threshold Analysis (PTA) https://vaww.portal2.va.gov/sites/infosecurity/fieldsecurity/ESO%20Library/Forms/AllItems.aspx?RootFolder=%2Fsites%2Finfosecurity%2Ffieldsecurity%2FESO%20Library%2FMOU%20ISA%20Templates%2FMOU%20ISA%20Documents&FolderCTID=0x0120002326DA99653E964BAD0FD5F39F245C85&View=%7b5EE98236-FE0A-4AC7-9FE1-6AF9B686AB0D%7d https://vaww.portal2.va.gov/sites/infosecurity/FY15CRISPAudit/CRISPRemediationContract/WorkSite/SitePages/MOU-ISA_Version2.aspx https://vaww.portal2.va.gov/sites/infosecurity/fieldsecurity/ESO%20Library/MOU%20ISA%20Templates/MOU%20ISA%20Intake%20Form%20Instructions.pdf https://vaww.portal2.va.gov/sites/infosecurity/fieldsecurity/ESO%20Library/MOU%20ISA%20Templates/MOU%20ISA%20Intake%20Form%20Instructions.pdf https://vaww.portal2.va.gov/sites/infosecurity/FY15CRISPAudit/CRISPRemediationContract/WorkSite/SitePages/MOU-ISA_Version2.aspx https://vaww.portal2.va.gov/sites/infosecurity/FY15CRISPAudit/CRISPRemediationContract/WorkSite/SitePages/MOU-ISA_Version2.aspx mailto:OITITOPSSOESOMOUISAREQUESTS@va.gov https://vaww.portal2.va.gov/sites/infosecurity/ca/CA%20Home%20Documents/ATO%20Documents/Minor%20Application_Self%20Assessment_Workbook_Jan%202019.xlsx

13 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

Roles and Responsibilities

• The ISO, Privacy Officer, ISSO, and Business Owner must work together to submit a PTA, which is reviewed by the Privacy Services Office.

• The PTA requires the Privacy Officer, ISO, and ISSO to sign and date the PTA.

• If the PTA determined a PIA is required, then see the below PIA section to complete the

PIA.

Completion Steps

1. The PTA template and the PTA completion process can be found at Privacy Compliance

PTA.

2. Once completed, the ISO or system steward uploads the signed PTA to eMASS by going to System > Details > FISMA. By uploading the security document to the FISMA tab, eMASS will automatically add the document to the Artifacts tab and map it to controls.

Once uploaded to the FISMA tab, it can be managed (e.g., newer versions) within the

Artifacts tab by clicking the Artifact Name. The security document within the FISMA tab should not be deleted or the security document and the history will be deleted.

3. Once the PTA has been uploaded to the FISMA tab, the ISO or system steward must ensure that all documents are appropriately associated as evidence to the relevant security controls and CCIs. To verify, go to the Artifacts tab, click on the Artifact Name, and then click Edit Artifact to add in more security controls or CCIs. Refer to the eMASS

Implementation Guide for additional details.

Privacy Impact Assessment (PIA)

If a PIA is required as an outcome of the PTA analysis by the Privacy Services Office, a PIA must be completed.

Roles and Responsibilities

• The PIA must be submitted to the Privacy Services Office by the Privacy Officer with input from the ISO, ISSO, and any other relevant stakeholders. Additional comments from the PIA support analysts, if any, must also be incorporated.

• The ISO must answer questions related to the PIA in the FISMA tab within eMASS

(System > Details > FISMA). Since the Privacy Compliance Dashboard within eMASS can provide reports on these metrics across all systems, the PIA questions must be kept up to date.

• The PIA requires the Privacy Officer, ISO, and ISSO to sign and date the PIA.

Standards / Guidelines

• E-Government Act of 2002

• OMB Circular 03-22

• VA Directive 6502 http://vaww.oprm.va.gov/privacy/pta.aspx http://vaww.oprm.va.gov/privacy/pta.aspx

14 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

• VA Directive 6508

• VA Handbook 6508.1

• NIST SP 800-53 (AR-2 Privacy Impact, Risk Assessment)

• VA Handbook 6500

Completion Steps

1. The PIA template and the PIA completion process can be found at Privacy Compliance

PIA.

2. Once the PIA is verified as completed by Privacy Services, re-submit the PIA as a PDF file with the required signatures to PIA Support. Additionally, the ISO or system steward uploads the signed PIA to eMASS by going to System > Details > FISMA. By uploading the security document to the FISMA tab, eMASS will automatically add the document to the

Artifacts tab and map it to controls. Once uploaded to the FISMA tab, it can be managed

(e.g., newer versions) within the Artifacts tab by clicking the Artifact Name. The security document within the FISMA tab should not be deleted or the security document and the history will be deleted.

3. Once the PIA has been uploaded to the FISMA tab, the ISO or system steward must ensure that all documents are appropriately associated as evidence to the relevant security controls and CCIs. To verify, go to the Artifacts tab, click on the Artifact Name, and then click Edit Artifact to add in more security controls or CCIs. Refer to the eMASS

Implementation Guide for additional details.

Continuous Monitoring Requirement

A PTA must be completed annually. A PIA is valid for 3 years. If a major change to the system occurs, then a new PTA/PIA must be completed.

4.1.1.8 Risk Assessment Report (RAR)

The RAR identifies, estimates, and prioritizes risk involved with organization operations. The

RAR is generated within eMASS and utilizes the details provided on control risk, the 40 threats, and any ongoing or risk accepted POA&M items.

Roles and Responsibilities

• The ISO, system steward, and ISSO are responsible for ensuring POA&M items within eMASS are property created and updated.

• The 40 threats must be reviewed by the ISO, system steward, and ISSO.

• The ISSO validates information added by the ISO or system steward within eMASS.

Standards / Guidelines

Note: Additional guidance for completion of the PIA/PTA can be provided by the Privacy Services Office. Any questions may be sent to PIA Support.

http://vaww.oprm.va.gov/privacy/pia.aspx http://vaww.oprm.va.gov/privacy/pia.aspx mailto:PIASupport@va.gov https://vaww.vashare.oit.va.gov/sites/ois/KnowledgeService/Pages/eMASS.aspx mailto:PIASupport@va.gov

15 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

• NIST SP 800-30

• NIST SP 800-53 (RA-3 Risk Assessment)

1. The ISO and ISSO should complete the Risk Assessment tab within their system.

2. All non-compliant Controls should be addressed for their risk plus any of the 40 threats that are applicable.

3. By default, the Risk Assessment tab will only show Non-Compliant Controls but the view can be changed using the Filter.

4. The RAR will be included in the snapshot packages created in eMASS. Alternatively, the

RAR can be generated by going to the Reports tab within eMASS.

Continuous Monitoring

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

4.1.1.9 System Security Plan (SSP)

Roles and Responsibilities

• The ISO or system steward completes the assessments in eMASS and develops POA&M items and responses.

• The ISSO validates information added by the ISO or system steward in eMASS.

Standards / Guidelines

• NIST SP 800-18,

• NIST SP 800-53 (PL-2 System Security Plan)

• VA Handbook 6500

Completion Steps

1. The SSP is developed within eMASS.

2. All required diagrams and confirmation of the security authorization boundary, to include all devices and supporting software architecture, should be added to eMASS in the appropriate locations.

3. The system steward completes the RMF steps in eMASS and develops POA&Ms for all

CCIs marked Non-Compliant. eMASS will apply the user’s N/A justification (test result) to automatically generate a POA&M item for all controls marked as Not Applicable.

4. The ISO and ISSO validates information added by the system steward in eMASS.

5. The SSP will be included in the snapshot packages created in eMASS. Alternatively, the

SSP can be generated by going to the Reports tab within eMASS.

16 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

The SSP must be updated annually or when a significant/major change to the system occurs.

4.1.2 Technical Scans/Testing Requirements

Findings identified in each technical/testing requirement, also referred to as a technical scan, should be mitigated from the initial detection date within the remediation timeframe specified in the VA Handbook 6500 (i.e.), Critical – 30 days; High – 60 days; Moderate – 90 days; Low – determined by the ISO; Emergent – ASAP. As outlined in BOD 19-02, Internet accessible systems require mitigation of Critical findings within 15 days and High findings within 30 days of the initial detection date. A single POA&M item should be created in eMASS for each of the applicable scans to track the remediation progress. Every completed scan requires a POA&M item. For example, a new Nessus scan POA&M item must be created every month for each new scan. In addition, a detailed remediation strategy with expected remediation date and status of each vulnerability should be uploaded to the Artifacts tab within eMASS for each of the applicable scans.

4.1.2.1 Nessus Scan

A credentialed Nessus vulnerability scan against all instances of the operating system and desktop configurations must be conducted to identify security flaws. When conducting the Nessus Scan, a discovery scan to identify all assets within the authorization boundary must be conducted as a part of the vulnerability scan (a discovery scan will not enumerate any vulnerabilities).

The following steps can be performed to meet the Nessus Scan requirement:

12. All systems should complete the Hardware and Software System Inventory Import process to ensure all IPs are properly added to eMASS and a Nessus scan can be completed. Instructions can be found in the Hardware and Software System Inventory

Import SOP, which is in the Standard Operating Procedures section of the eMASS

Knowledge Service page.

13. The ISO or system steward can request a Nessus scan using this link. Once the request is completed, ISRM will work with CSOC to determine if a separate supplemental vulnerability scan shall be conducted or authentication information for the non-

Windows devices be added to the existing monthly predictive scan. If ISRM/CSOC determine a supplemental scan is required then the results, once received, must be uploaded to the Artifacts tab within eMASS. If decided that the authentication information can be added for the non-Windows devices to the monthly predictive scans

Note: CSOC must conduct an independent Nessus Scan for all VA owned systems.

https://vaww.portal2.va.gov/sites/infosecu…