Attachment C_AWS Incident Response Plan Associate Template.docx

U.S. DEPARTMENT OF VETERANS AFFAIRS

VAEC Amazon Web Services (AWS) GovCloud High And [Organization 2 name/acronym] [Security Categorization: LOW/MODERATE/HIGH] Incident Response Plan

Version 0.0

MM/DD/YYYY

Entries in GREEN are instructions (to be replaced with instruction request) Entries in RED are to be replaced/completed by the System/Application Team Entries in BLACK should NOT to be changed, they are boiler plate changed (if changes are necessary, please highlight) [Organization 2] is the organization/system/application hosted in the VAEC.

1. All colored texts should be removed or converted to black (or matching text) when finalized for signature.

2. This box/page should be removed when finalized.

3. Send to VAECSecurityTeam@va.gov for review PRIOR to final VAEC sign off/approval.

SYSTEM SECURITY ARTIFACT

ASSESSMENT AND AUTHORIZATION

We, the undersigned, approve the content of this Incident Response Plan for the VA Enterprise Cloud AWS GovCloud High (VAEC) located in AWS GovCloud’s Region(s).

A valid PKI can be used to sign in lieu of a handwritten signature.

SIGNATURE Authorities [Organization 2 name/acronym]

<Plan Approver Name> <Job Title>

<Plan Approver Name> <Job Title>

VAEC Review:

Record of Changes/Revisions

This record shall be maintained throughout the life of the document. Each published update shall be recorded. Revisions are a complete re-issue of the entire document. Increment the version number’s decimal (minor) portion here, on the cover page, and in the headers for each revision. The version number’s integer (major) portion will be updated at each time a full Authorization and Accreditation (A&A) is performed.

CSRA/MPG

CSRA/MPG

Organization 2 Author name - [System Acronym]

Provide Organization 2 field above: Date of update, Author name and System Acronym in the document change control record table.

Table of Contents

i OFFICE OF INFORMATION SECURITY

PURPOSE

An Incident Response Plan must be formulated for every information system (IS) at the U.S. Department of Veterans Affairs. The Incident Response Plan (IRP) is a required document that must be included in the Security Artifacts package. The purpose of an incident response plan is the establishment of procedures and protocol for the reporting and handling of information security incidents as required by the policies and laws of the U.S. Federal Government and the U.S. Department of Veterans Affairs.

The guidelines contained herein include fundamental information about responding to security incidents and provides a practical source of guidance and incident response. A structured, systematic incident response program will assist VA personnel to:

· Quick and efficient recovery through proven response measures

· Minimal loss or theft of information or disruption of critical computing services

· Systematic response by outlining the recommended response times

· Protection of IS and data through quick detection and recovery

· Protection of personnel through sound incident response practices

· Efficient use of resources through quick resolution of incidents

This document defines the IR responsibilities of stakeholders operating within the VAEC. The process should be used as a guide to assist these stakeholders with the necessary requirements for building a complete IR plan. The procedures provided will guide these stakeholders when actively responding to an incident.

POLICY AND AUTHORITY

This section shows the Federal laws, regulatory guidance, and directives that drive Department of Veterans Affairs Information Security Programs including the formation of an Incident Response Plan.

· Federal Information Security Modernization Act of 2014 (FISMA 2014), December 2014

· Health Insurance Portability and Accountability Act of 1996 (HIPAA)

· Computer Fraud and Abuse Act of 1986, as amended

· OMB Circular A-130, Managing Federal Information as a Strategic Resource, July 2016

· Federal Information Processing Standard - 199 Standards for Security Categorization of Federal Information and Information Systems February 2004

· Federal Information Processing Standard – 200 “Minimum Security Requirements for Federal Information and Information Systems” March 2006

· NIST SP 800-12 Rev 1 - An Introduction to Computer Security: The NIST Handbook, June 2017

· NIST SP 800-18 Rev. 1 - Guide for Developing Security Plans for Federal Information Systems, February 2006

· NIST SP 800-37 Rev. 2 – Guide for the Security Certification and Accreditation of Federal Information Systems, December 2018

· NIST SP 800-53 Rev. 4 – Recommended Security Controls for Federal Information Systems, January 2015

· NIST SP 800-53A Rev. 4 - Assessing Security and Privacy Controls in Federal Information Systems and Organizations: Building Effective Assessment Plans, Dec 2014

· NIST SP 800-61 Rev. 2– Computer Security Incident Handling Guide, August 2012

· NIST SP 800-84, Guide to Test, Training, and Exercise Programs for IT Plans and Capabilities, September 2006

· VA Directive 6500, Managing Information Security Risk: VA Information Security Program VA Directive 6500 Appendix D, Minimum Security Controls for VA Information Systems, Jan 2019

· VA Handbook 6500, Risk Management Framework for VA Information Systems - Tier 3: VA Information Security Program, Mar 2015

· VA Handbook 6500.2 Management of Breaches Involving Sensitive Personal Information, March 2019

· VA Handbook 6500.5, Incorporating Security and Privacy into the System Development Life Cycle, Mar 2010

· Veterans Affairs Directive 6517, Risk Management Framework for Cloud Computing Services, November 2016

· Veterans Affairs Handbook 6517, Risk Management Framework for Cloud Computing Services, November 2016

· FedRAMP Incident Communications Procedure v3.0, December 2017

· Veterans Affairs OIS CSOC Cybersecurity Incident Response Plan, version 7.0, January 2019

SHARED RESPONSIBILITY MODEL

Cloud systems operate under a shared responsibility model to define the division of security, privacy and operational responsibilities. Shared responsibility is an important concept used to define IR expectations for CSPs and VA when a cloud system is in use. The division of responsibilities for all cloud systems must be clearly understood and documented and varies by cloud service model as illustrated in Figure 1 below.

IR PROCESS OVERVIEW

Incident Response is a process that drives the course of action for cyber security events. When an incident occurs, VA systems must utilize the detailed IR process to stop, contain, and control the incident quickly. The IR process has the following four phases:

· Preparation

· Detection and Analysis

· Containment, Eradication, and Recovery

· Post-Incident Activity Figure 2 below, provides an overview of the activities performed during the IR process.

Figure 2 - Overview of Activities Performed During IR Process Image Source: created by author Preparation During the preparation phase, a system’s IR plan is developed, tested, and exercised. System Owners must ensure patch management, anti-virus scanning, and configuration management processes are established. Additionally, training materials should be identified and distributed, exercise scenarios created, and communication procedures provided to all relevant personnel. Properly preparing for an incident also includes identifying all potential attack vectors relevant to each cloud system to inform the remainder of the IR process.

Incident prevention is another significant consideration for establishing a system’s security posture or impacting the privacy of the system. Prevention begins by including wise investments in security infrastructure and services—informed by risk-aware threat analysis tools (e.g. .govCAR, Lockheed Martin’s Cybersecurity Kill Chain, ISACA Cybersecurity Nexus, ENISA Threat Landscape, NSA/CSS Technical Cyber Threat Framework). Once secure architectures are in place, system owners can be proactive—by providing training and ensuring an adequate Continuous Monitoring program—in drastically reducing the number of potential incidents targeting VA’s network. Incident prevention should be a primary goal and can be accomplished via the following elements:

· System Risk Assessments and Plan of Action and Milestones (POA&Ms)

· Security/Privacy Awareness & Training

· Host security and endpoint management

· Security Information and Event Management (SIEM) onboarding requirements

· Continuous Monitoring program

Detection & Analysis All systems must have a clear identification of all security tools available for monitoring and alerting. First responders detect and assess potential incidents and determine the validity and magnitude of the impact to properly prioritize the incident. The incident is assigned a severity rating based on the functional impact, the information impact, and recoverability when an incident ticket is created. When the severity is determined, response teams are expected to perform and react based on that severity. All potential incidents should be treated as valid until classified as a false positive.

Detected incidents must be immediately reported to a supervisor and the Information System Security Officer (ISSO) for an incident ticket to be created. If the incident involves Protected Health Information/Personally Identifiable Information (PHI/PII), the Privacy Officer (PO) must also be alerted. The ISO and PO for the system will be required to enter the incident into the Privacy Security Events Tracking Systems (PSETS) within one hour of the initial report. The following criteria should be used as high-level guidance for how teams should respond to incidents after the severity has been determined and management has been notified:

· High severity – The IR team should expect to act immediately even if it leads to a service disruption. Notifications about any disruptions should be sent immediately, and updates must be provided every 24 hours.

· Medium severity – The IR team should notify the appropriate VA System Owners of any planned action to coordinate with assessing the relative risk of service disruption vs. any security or privacy implications. Updates should be sent every 48 hours.

· Low severity – The IR team should notify VA System Owners but not act until a mutually agreed upon course of action has been determined. Updates should be provided every 72 hours.

Notifications must be sent out to the appropriate individuals as soon as an incident is prioritized, and subsequently via the noted timeframes.

Threat frameworks such as the NSA/CSS Technical Cyber Threat Framework and .govCAR are helpful for providing an in-depth overview of specific threat categories that can be encountered in cloud systems. Examples of these categories are as follows:

· Unauthorized Access

· Compromised Information

· Denial of Service (DoS)/Distributed DoS (DDoS)

· Cyber Intrusion

· Phishing/Vishing

· Malicious Code

With cloud systems, there are additional cloud-specific attack vectors to consider. The following table details some potential attack vectors that cloud systems can expect to encounter:

Table 1 - Cloud Specific Attack Vectors Finally, establishing appropriate and adequate logging and monitoring of a system is critical for tracking signs of potential incidents. Along with traditional sources of precursors and indicators, cloud systems need to consider the following detection and tracking mechanisms to ensure a full view of indications of potential or active incidents:

· Billing activity and alarms – to detect abnormal spikes in billing activity or unauthorized changes to services or subscriptions

· Management plane and Identity Access Management (IAM) – for unauthorized credential creation, service or subscription changes, and other potential signs of heightened privileged account compromise

· Application Programming Interface (API) activity tracking – to identify any abnormal, unscheduled, unsuccessful, or unauthorized application calls Available and applicable CSP-specific tools (e.g. AWS CloudWatch/CloudTrail, Azure Monitor) – to ensure visibility into all required areas of a system’s architecture

Containment, Eradication, & Recovery Incidents must be effectively and efficiently contained to minimize impact on the Information System, Mission/Business function, and the organization. Cloud-based systems can typically apply cloud services to minimize downtime by copying and isolating affected systems for further investigation. In addition, a more rapid recovery may be enabled by provisioning new production-ready snapshots or images of the affected systems or reverting affected systems to a known secure state. During the preparation phase, event conditions for detection and analysis are defined, and these event conditions are reviewed for incidents during the detection and analysis phase. During the containment, eradication, and recovery phase the focus is on creating images to perform forensics, isolating compromised or impacted systems, and gathering evidence to accurately determine the risk that the incident poses to VA.

Containment is focused on ensuring that the incident does not impact additional systems. Eradication concentrates on removing the threat from the environment and confirming that the threat has been completely addressed. Recovery reconstitutes the system to a known secure state and includes confirmation, using available tools and resources, that the threat has been sufficiently eradicated from the environment.

Early phases of containment, eradication, and recovery are primarily focused on increasing the immediate security of the system. Long term re-engineering of the system, supporting infrastructure, and requisite IR processes are handled as Post-Incident Activity.

Post-Incident Activity During this phase, all issues encountered during the IR process should be documented and any necessary compensating security or privacy controls implemented and assessed to mitigate identified risks in the IR process. It is also vital to hold “lessons learned” meetings during post-incident activity to facilitate learning and improvement of the IR function. Per NIST 800 61, holding these meetings with all involved parties (both internal and external) will be extremely helpful in improving security measures and the IR process in general. This is especially true in cloud computing due to the nature of shared responsibilities. To accommodate, these lessons learned meetings should focus on answering the following questions:

· Was the incident sufficiently detected? If not, how can detection and analysis capability be improved to detect these types of incidents more effectively or efficiently?

· Was the incident properly communicated in the expected timeframes? If not, how can the process be improved, and expectations with providers be clarified, to ensure future incident communications are improved?

· Did the system staff have sufficient knowledge to provide inputs for system-specific aspects of the IR process? If not, how can this situation be addressed with additional training, tests, and/or exercises?

These questions should be considered in the context of the event and any updates to the system architecture, documentation, and third-party service agreements (such as SLAs) should be initiated based upon the results of the post-incident analysis.

The nature of cloud computing and the support provided to the IR process by a CSP (as a third party) changes how IR has traditionally been accomplished at VA. For VA System Owners, it is critical that the CSP be engaged throughout the response process whenever an incident occurs within CSP areas of responsibility to ensure a comprehensive understanding of the incident is achieved. Additionally, CSP support can be invaluable in helping determine the occurrence of an incident, a proper containment/eradication strategy, and confirmation that the system has completely recovered.

SYSTEM INFORMATION

This section describes information defining and relating to the VAEC AWS GovCloud High and [Organization 2 name/acronym] [Security Categorization] System Description System Name

System Name: VAEC AWS GovCloud High Assessing System GRC Acronym: VAEC AWS GOVCLOUD HIGH System Identification: 86

Enter your organization system name below

System Description

The VA Enterprise Cloud AWS GovCloud High (VAEC) is a General Support System that provides a secure application and hosting environment for VA applications, content, and utilities that are used to deliver content and applications to an audience made up of employees, veterans, contractors, and partners across all VA medical centers and component facilities and the Federal government, veterans and the general public. Content and applications are provided by Veterans Benefits Administration (VBA), Veterans Health Administration (VHA), National Cemetery Administration (NCA) and Support Offices. VAEC provides the following services: Content delivery, Application Hosting and Management Services.

The VAEC infrastructure is hosted by AWS GovCloud, a cloud service provider. The AWS GovCloud platform is used to provide a variety of hosting environments to suit a variety of needs. AWS GovCloud can support applications categorized up to High as rated in accordance with Federal Information Processing Standard (FIPS) 199. VA applications available to the public are hosted in AWS GovCloud.

A dedicated private data link (AWS Direct Connect) provides all connectivity for VA resources communicating to the environment. Virtual Private Clouds (VPCs) wrap the applications within AWS GovCloud to encapsulate network access. Access from the applications to VA internal resources such as Identity, Credential, and Access Management (ICAM) and Active Directory (AD) Services are conducted over the encrypted private data link to the VA Network.

VAEC is located in the AWS GovCloud Region with multiple Availability Zones (AZs) designed to allow U.S. government agencies, contractors and customers to move sensitive workloads into the cloud for addressing specific regulatory and compliance requirements. AWS GovCloud does not manage logical access controls within the VAEC system boundary. VAEC offers the same level of security as other VA physical technology centers and supports existing VA security controls and certification requirements such as FISMA, HIPAA, HITECH, SAS-70, ISO 27001, FIPS 140-2 compliant end points, and PCI DSS.

[Organization 2] System Description Enter your organization system description here.

System Categorization

VAEC AWS GovCloud High Assessing - HIGH

Enter your organization system categorization below.

[Organization 2] System Categorization [System Name] - [LOW/ MODERATE/HIGH] System Categorization is derived in the System Security Plan. Indicate the overall system sensitivity level by using exact level calculated in the SSP.

System Contacts VAEC Area Manager / System Owner Name: David Catanoso Email: David.Catanoso@va.gov Phone: 732-440-9583 Mobile: None Listed

Enter your organization System Owner below.

[Organization 2] System Owner

VAEC End User Operations Manager Name: Chris Cardella Email: Christopher.Cardella@va.gov Phone: 512-326-6180 Mobile: 512-590-9414

Enter your organization End User Operations Manager below.

[Organization 2] End User Operations Manager

VAEC Information System Security Officer(s) Name: Albert Estacio Email: Albert.Estacio@va.gov Phone: 909-583-6309 Mobile: 909-528-4958

Enter your organization Information System Security Officer below.

[Organization 2] Information System Security Officer

VAEC Privacy Officer Name: Rita Grewal Email: Rita.Grewal@va.gov Phone: 202-632-7861 Mobile: 540-327-7539

Enter your organization Privacy Officer below.

[Organization 2] Privacy Officer

Discussion: Enter the name of the system/facility Privacy Officer as defined in the systems Security Plan (SSP).

System Location Geographical Location of the Physical System The VAEC AWS GovCloud High (VAEC) is located in the AWS GovCloud region with multiple Availability Zones. AWS does not disclose the physical address of its data centers.

Enter your organization Geographical Location of the Physical System here.

Logical Location of the Management System The VAEC AWS GovCloud High (VAEC) is located in the AWS GovCloud region with multiple Availability Zones.

Enter your organization Logical Location of the Management System here.

Location of System Backups The VAEC AWS GovCloud High (VAEC) is located in the AWS GovCloud region with multiple Availability Zones.

Enter your organization Location of System Backups here.

SYSTEM INTERCONNECTIONS

The VAEC system is VA’s enterprise cloud-based provider for applications hosted in VAEC clouds. The VAEC utilizes internal system interconnections with:

• VA AD Service: Identification, Authentication, and Authorization services for application servers and the cloud infrastructure

• VA CSOC: Auditing, Monitoring, and Incident Response

• VA CSOC: Trusted Internet Connection to the CSP.

• VA CSOC: Network termination and firewall management

Enter your organization system interconnections here.

STAKEHOLDERS AND RESPONSIBILITIES

IR planning for VA cloud systems must meet VA CSOC requirements for collaborating with external stakeholders. This can introduce complexity to the IR process as each stakeholder can be a first responder and is responsible for the security of various portions of the information system. Understanding the IR responsibilities of stakeholders for the system is vital to being able to properly document the VA system's IR plan and identify all key points of contact. The IR responsibility for each of these stakeholders is explained in the sections that follow.

Process Stakeholders FedRAMP VA is responsible for ensuring proper communications for all FedRAMP-Authorized cloud systems. Incidents occurring in the cloud have the potential to impact multiple agencies; as a result, FedRAMP assigns Information System Security Officers (ISSO) to coordinate and oversee the security function of the CSP—including coordination of IR activities for any services that have received a FedRAMP JAB P-ATO. All federal agency use of cloud systems must comply with and must be reported to FedRAMP. In the event of a major incident affecting multiple agencies, the FedRAMP ISSO facilitates communications with the FedRAMP Director, Joint Authorization Board (JAB), and others within the FedRAMP Program Management Office (PMO).

All CSPs that have obtained a FedRAMP Provisional Authorization are assigned a FedRAMP ISSO by the FedRAMP PMO. FedRAMP ISSOs are headquartered at the Office of the FedRAMP PMO. Supporting the PMO, FedRAMP ISSOs provide oversight for CSP security incidents. OMB Circular A-130 § (8) (b) (1) (b) xi requires that federal agencies establish oversight mechanisms to evaluate systematically and ensure the continuing security, interoperability, and availability of systems and their data.

FedRAMP ISSOs are not first responders and are dependent on after action reports from other stakeholders. The role of FedRAMP ISSOs in the incident communication process is described below.

· Receives notification of incident from first responders.

· Confirms with CSP that CSP is following their Incident Response Plan.

· Records all incident communications in the FedRAMP database.

· Ensures that the appropriate stakeholders are kept updated.

· Monitors the communication flow between stakeholders.

· Ensures timely closure of all incidents.

· Ensures that POA&Ms are created if needed because of an incident.

· Discusses with CSP the option of requesting outside assistance (e.g. US-CERT).

· Makes use of after-action reports to facilitate further communications.

In the event of a major incident affecting multiple agencies, escalates and facilitates communications to FedRAMP Director and Joint Authorization Board and others as necessary.

US-CERT

US-CERT is a government-wide IR organization that assists civilian federal agencies with incident handling efforts. Federal regulations require that all government agencies and CSPs working in the government space notify US-CERT any time an incident occurs. VA CSOC is identified as the central interface for VA correspondence with US-CERT and all communication with US-CERT should be coordinated with CSOC.

FISMA requires federal agencies to report incidents to US-CERT, which acts as the government-wide incident response organization that assists civilian federal agencies in their incident handling efforts. US-CERT does not replace any existing agency response teams; rather, it augments the efforts of the federal civilian agencies by serving as a focal point when dealing with incidents. The responsibilities of US-CERT are outlined in 44 U.S.C. § 3546 and are summarized as follows:

· Notify agency POCs, CSPs, and FedRAMP ISSOs of known incidents.

· Coordinate cyber security operations and incident response.

· Monitor and report security incidents and network flow data.

· Distribute advisories on potential threats.

· Assist government-wide and agency-specific efforts to provide adequate, risk- based and cost-effective cyber security.

National Service Desk (NSD) The National Service Desk (NSD) serves as the help desk point of contact for VA systems. The NSD should be informed of any active incidents and should have access to all system IR communication procedures and contact lists.

· Contact NDC 24/7 Support Line: 1-304-260-6687.

Cloud Service Provider CSPs are responsible for managing any incidents detected within portions of the cloud environment not under VA management. Various VA stakeholders will review and approve the CSP IR plan as part of the ATO process for cloud services. VA System Owners will also review to determine all IR responsibilities and document the appropriate VA IR requirements in the system’s IR plan. All CSPs must adhere to VA IR requirements and FedRAMP Incident Communications Procedures. Whenever a CSP detects an incident it should be reported to all affected customer agencies based on the categorization of the incident. The CSP should also inform the affected agencies POCs whenever USCERT assistance is required. CSP general responsibilities are described below.

· For incidents related to unauthorized access or personally identifiable information, report the incident to US-CERT within one hour of awareness (required by OMB Memo M-07-16).

· Notifications should be done via telephone and followed up with an email.

· Use phone numbers and email addresses as provided by the FedRAMP PMO.

· If necessary, request assistance from US-CERT.

· Follow procedures in the system Incident Response Plan.

· Log all incident details on Incident Reporting Form (found in Incident Response Plan).

· Follow the Configuration Management Plan for change control.

· Manage and maintain a Continuous Monitoring program.

· As required by the FedRAMP Continuous Monitoring Guide and Strategy, report incidents as they occur and annually through the Self-Attestation template.

VA System Owners The VA System Owner is responsible for developing the IR plan as part of authorization of a VA system. Systems hosted within the VAEC will inherit many IR functions via VAEC support. VA System Owners will be required to document any gaps in IR functions between the system and the cloud hosted infrastructure. VA System Owners must ensure IR plans include communication requirements, first responder use case expectations, specific monitoring and alerting requirements, and responsibilities for all stakeholders. Additional guidance for gathering roles and responsibilities within VA can be found in VA Handbook 6500.2, Management of Breaches Involving Sensitive Personal Information, section 3.

VA System Owners should report all incidents consistent with the agency’s incident response policy. Agency should designate a primary and secondary POC for incident communications. VA Agency POCs should be shared with the FedRAMP ISSO team, US-CERT, and all CSPs under contract with the agency. When CSPs report incidents to agencies, agencies should in every case offer to coordinate assistance between US-CERT and the CSPs. Agency general responsibilities are described below.

· Notify CSP if the agency becomes aware of an incident that a CSP has not yet reported.

· Provide a primary and secondary POC for CSPs and US-CERT as described in agency and CSP Incident Response Plans.

· Notify US-CERT when a CSP reports an incident.

· Work with CSPs to resolve incidents; provide coordination with US-CERT if necessary.

· Notify FedRAMP ISSO of CSP incident activity.

Monitor security controls that are agency responsibilities.

VA Information System Security Officers (VA ISSO) VA ISSOs oversee the security program for VA systems, including IR. ISSOs will assist with managing any active incidents and work with the various IR stakeholders throughout the IR process.

· Provide input to weekly incident response reports.

· Receive ISVM messages and report compliance.

· Track and document information system security incidents on an ongoing basis.

· For incidents involving Privacy information, the ISSO must ensure the Privacy Officer is informed in a timely manner in accordance with Component-specific guidance.

VA Privacy Officer The VA Privacy Officer (PO) oversees and monitors the success of the privacy controls, policies, and procedures for all systems that are collecting, processing, or storing Personally Identifiable Information (PII). POs will review all incidents that result in potential exposure of VA Privacy data. When necessary, a PO may request revisions to the IR program to comply with any changes in the regulations, law, professional ethics, or other accreditation requirements.

· Oversee privacy incident management.

· Review and approve program and system Privacy Threshold Analyses (PTAs), Privacy Impact Assessments (PIAs), and System of Records Notices (SORNs).

· Designate Privacy Sensitive Systems based on validated PTAs. Privacy Sensitive Systems are those that maintain Personally Identifiable Information (PII).

VA Cyber Security Operations Center (CSOC) VA Cyber Security Operations Center (CSOC) is the primary department within VA responsible for oversight and guidance of all Cyber Security operations (e.g., security event monitoring and Incident Response (IR) execution). VA CSOC is responsible for many tasks during the IR process and is the central interface for VA correspondence between US-CERT and FedRAMP. Any incident communication with FedRAMP or US-CERT must be coordinated with CSOC.

Enterprise Cloud Solutions Office (ECSO) VA ECSO is responsible for hosting the VA Enterprise Cloud (VAEC) infrastructure. Systems that are hosted within VAEC will have many IR functions performed as part of VAEC support. Additionally, ECSO often provides guidance, review, and approval for many cloud systems’ security documents (Incident Response Plan, Configuration Management Plan, etc.) to ensure cloud security best-practices are followed for system implementations.

Potential VA Cloud Use Cases VA systems that are using cloud services have four potential VA cloud use cases. Each use case has a different set of responsibilities. These use cases are detailed in Table 2 below along with associated high-level responsibilities.

Table 2 - VA Cloud Use Cases

Incident Response Planning The following sections describe the process for validating IR plan inputs and generating a VA system-specific IR plan for cloud systems.

Validate Current Documentation To identify any gaps that need to be covered by a system IR plan, VA System Owners must review the following documentation:

· CSOC IR plan

· VAEC IR plan (if applicable)

· FedRAMP Incident Communications Procedure

· CSP SLA

· CSP IR plan

· VA Handbook 6500

· VA Handbook 6500.2

All relevant CSP contacts must be identified in the CSP IR plan and documented in the system’s IR plan Points of Contact (POC) list for any incident reports or communications. All specific IR requirements should be identified in the relevant SLA. During a review, VA System Owners should confirm that the CSP IR plan provides sufficient answers to the following questions:

· Has the CSP adequately documented all IR security and privacy requirements?

· Does the CSP perform annual IR tests and exercises?

· What/When was the last test or exercise, and are the results available?

· Does the CSP perform annual IR training?

· What/When was the last training, and are results available?

· Are all CSP contacts clearly defined?

· Are expectations/responsibilities clearly defined for all potential scenarios described by the FedRAMP First Responder Use Cases?

· How soon will the CSP be expected to contact VA System Owners after an incident has been detected?

· How soon is VA expected to contact the CSP after an incident has been detected?

· How will the CSP contact US-CERT/FedRAMP (if they are responsible)

· Who will perform this notification?

· What is the expected time from incident detection to US-CERT notification?

· Is the cloud system isolated or multi-tenant within the CSP environment?

· What sort of logging/alerting will the CSP perform?

· What methods can the CSP use to contain the incident?

· Where are back-ups stored?

· Does VA have access?

· What is the CSP’s strategy for resuming production operations while investigating, containing, or eradicating an incident?

System Owners also should confirm the CSP IR plan addresses, at a minimum, the requirements laid out by the FedRAMP Incident Communications Procedure, and then use the system specific IR plan to address any responsibility gaps between the VA system IR and CSP. Any supplemental requirements to address these gaps should be included in SLA documentation.

VA Cloud Incident Response Procedures An active incident response for a malicious event impacting a VA system follows the below high-level process:

· Data is collected from following potential data sources, among others: ePO, Sourcefire, Splunk, Email / IronPort, Remedy/SNOW, US-CERT, DNS/Blackhole, Phone, IBM BigFix, SIEM, Investigative Analysis.

· Source and destination of the event and are reviewed.

· If the impacted system is within VA’s responsibilities, the IR team will determine if this is event or incident and will report accordingly. If the event is a false positive, event criteria should be submitted for tuning, event metrics should be reported, and no secondary remediation action needed.

· If the event is an Incident, the system stakeholders will create an incident ticket, determine if it is investigative ticket or not, determine priority level and track ticket as an Ops issue.

· An incident report will be generated and if it meets FedRAMP Incident Handling or VA IR reporting criteria, it will be reported to US-CERT and FedRAMP as applicable.

· In situations where the VA OIG needs to be involved, ticket handling protocol will be initiated and IR stakeholders will follow up with updates to ensure proper and timely closure of the ticket.

The procedures below should be followed by incident stakeholders and responders to ensure CSOC requirements are followed when actively involved in incident response:

ACTION

1. Name of the reporter

1. Organization of the reporter

1. Reporting time

1. Reporting method (e.g., call, email, etc.)

1. Contact information

1. Nature of the event

1. Time of the event

1. Location of the event

1. Source of the event

1. Scope of the impact (e.g., ecosystem and/or persons involved)

1. Business impact

1. Detection method of the event

1. Privacy Officer

1. Local IT Office

1. System Administrator

1. Gateway Ops

1. VA-CSOC FTEs (identified in Stakeholder Recipient List

1. CSA CHTA Team

1. CSA DMA Team

1. SDSD

1. Number of host(s) affected

1. Priority (i.e., Critical, High, Medium, Low, None) Hostname

1. Source IP address Destination IP address

1. Username

1. Cloud vendor

1. Malware name

1. Incident type

1. Indicator of compromise

1. US-CERT Classification Information

1. Preliminary remediation action/resolution Attachment(s)

CONTACT INFORMATION

VAEC:

Enter your organization contact information in the table below [Organization 2 name/acronym]:

REFERENCES

Acronyms Enter additional acronyms used in the table below:

Definitions Discussion: This is not required if terms used in the response plan are considered basic knowledge in incident response or computer information security.

Appendix A – 800-53 CONTROL FAMILY Incident Response (IR)

IR-1

(L), (M), (H) Incident Response Policy and Procedures:

The organization:

a. Develops, documents, and disseminates to [Assignment: organization-defined personnel or roles]:

1. An incident response policy that addresses purpose, scope, roles, responsibilities, management commitment, coordination among organizational entities, and compliance; and

2. Procedures to facilitate the implementation of the incident response policy and associated incident response controls; and

b. Reviews and updates the current:

1. Incident response policy [Assignment: organization-defined frequency]; and

2. Incident response procedures [Assignment: organization-defined frequency].

In Place

Common

Planned

In Place and Planned

System Specific

Not Applicable

IR-2

(L), (M), (H) Incident Response Training:

The organization provides incident response training to information system users consistent with assigned roles and responsibilities:

a. Within [Assignment: organization-defined time period] of assuming an incident response role or responsibility;

b. When required by information system changes; and

c. [Assignment: organization-defined frequency] thereafter.

In Place

Common

Planned

In Place and Planned

System Specific

Not Applicable

IR-2 (1)

(H) Incident Response Training:

The organization incorporates simulated events into incident response training to facilitate effective response by personnel in crisis situations.

In Place

Common

Planned

In Place and Planned

System Specific

Not Applicable

IR-2 (2)

Incident Response Training:

The organization employs automated mechanisms to provide a more thorough and realistic incident response training environment.

In Place

Common

Planned

In Place and Planned

System Specific

Not Applicable

IR-3

(M), (H) Incident Response Testing:

The organization tests the incident response capability for the information system [Assignment: organization-defined frequency] using [Assignment: organization-defined tests] to determine the incident response effectiveness and documents the results.

In Place

Common

Planned

In Place and Planned

System Specific

Not Applicable

IR-3 (2)

Incident Response Testing:

The organization coordinates incident response testing with organizational elements responsible for related plans.

In Place

Common

Planned

In Place and Planned

System Specific

Not Applicable

IR-4

Incident Handling:

The organization:

a. Implements an incident handling capability for security incidents that includes preparation, detection and analysis, containment, eradication, and recovery;

b. Coordinates incident handling activities with contingency planning activities; and

c. Incorporates lessons learned from ongoing incident handling activities into incident response procedures, training, and testing/exercises, and implements the resulting changes accordingly.

In Place

Common

Planned

In Place and Planned

System Specific

Not Applicable

IR-4 (1)

Incident Handling:

The organization employs automated mechanisms to support the incident handling process.

In Place

Common

Planned

In Place and Planned

System Specific

Not Applicable

IR-4 (4)

Incident Handling:

The organization correlates incident information and individual incident responses to achieve an organization-wide perspective on incident awareness and response.

In Place

Common

Planned

In Place and Planned

System Specific

Not Applicable

IR-5

Incident Monitoring:

The organization tracks and documents information system security incidents.

In Place

Common

Planned

In Place and Planned

System Specific

Not Applicable

IR-5 (1)

Incident Monitoring:

The organization employs automated mechanisms to assist in the tracking of security incidents and in the collection and analysis of incident information.

In Place

Common

Planned

In Place and Planned

System Specific

Not Applicable

IR-6

Incident Reporting:

The organization:

a. Requires personnel to report suspected security incidents to the organizational incident response capability within [Assignment: organization-defined time-period]; and

b. Reports security incident information to [Assignment: organization-defined authorities].

In Place

Common

Planned

In Place and Planned

System Specific

Not Applicable

IR-6 (1)

Incident Reporting:

The organization employs automated mechanisms to assist in the reporting of security incidents.

In Place

Common

Planned

In Place and Planned

System Specific

Not Applicable

IR-7

Incident Response Assistance:

The organization provides an incident response support resource, integral to the organizational incident response capability that offers advice and assistance to users of the information system for the handling and reporting of security incidents.

In Place

Common

Planned

In Place and Planned

System Specific

Not Applicable

IR-7 (1)

Incident Response Assistance:

The organization employs automated mechanisms to increase the availability of incident response-related information and support.

In Place

Common

Planned

In Place and Planned

System Specific

Not Applicable

IR-8

Incident Response Plan:

The organization:

a. Develops an incident response plan that:

1. Provides the organization with a roadmap for implementing its incident response capability;

2. Describes the structure and organization of the incident response capability;

3. Provides a high-level approach for how the incident response capability fits into the overall organization;

4. Meets the unique requirements of the organization, which relate to mission, size, structure, and functions;

5. Defines reportable incidents;

6. Provides metrics for measuring the incident response capability within the organization;

7. Defines the resources and management support needed to effectively maintain and mature an incident response capability; and

8. Is reviewed and approved by [Assignment: organization-defined personnel or roles];

b. Distributes copies of the incident response plan to [Assignment: organization-defined incident response personnel (identified by name and/or by role) and organizational elements];

c. Reviews the incident response plan [Assignment: organization-defined frequency];

d. Updates the incident response plan to address system/organizational changes or problems encountered during plan implementation, execution, or testing;

e. Communicates incident response plan changes to [Assignment: organization-defined incident response personnel (identified by name and/or by role) and organizational elements]; and

f. Protects the incident response plan from unauthorized disclosure and modification.

In Place

Common

Planned

Hybrid

In Place and Planned

Not Applicable

IR-10

Privacy Overlay Incident Response Plan:

The organization establishes an integrated team of forensic/malicious code analysts, tool developers, and real-time operations personnel.

In Place

Common

Planned

Hybrid

In Place and Planned

Not Applicable

Appendix B – Incident Response and Management Resources

Federal Agency Incident Categories