Attachment A - Cloud_Security_Architecture_Security_Patterns.pdf

OFFICE OF

INFORMATION

SECURITY

Department of Veterans Affairs Cloud Architecture Security Pattern

Version 1.0

March 26, 2019 | Enterprise Security Architecture Office

OFFICE OF INFORMATION SECURITY

Enterprise Security Architecture Office

VA Cloud Architecture Security Pattern | i

Internal VA Use Only

Revision History

Date Version Description Author

03/26/2019 1.0 Cloud Security Requirements Enterprise Security Architecture

VA Cloud Architecture Security Pattern | ii

Table of Contents

1. Introduction

1.1. Overview

1.2. Purpose and Scope

1.3. Cloud and VA

1.3.1 VA Enterprise Cloud Use Case

2. Functional Area Guidelines and Minimum Security Requirements

2.1. Network Security

2.2. Monitoring and Logging

2.3. Operating System and Database Security

2.3.1. Operating System

2.3.1.1. Design and Build

2.3.1.2. Test and Production

2.3.2. Database

2.4. Identity and Access Management

2.5. Data Protection and Encryption

2.5.1. Data Decommissioning and Exit

2.6. Incident Response

2.7. Business Continuity and Disaster Recovery

2.8. Application Development and API Security

Appendices Appendix A. Terms and Definitions Appendix B. Acronyms and Abbreviations Appendix C. References Appendix D. CSOC Cloud Visibility Requirements

VA Cloud Architecture Security Pattern | 1

1. Introduction

1.1. Overview

The United States Department of Veterans Affairs (VA) provides near-comprehensive healthcare services to military veterans at VA medical facilities throughout the country, including disability compensation, vocational rehabilitation, education assistance, home loans, life insurance, and burial and memorial benefits. Rapidly-changing technology paired with the increasing number of veterans and rising healthcare costs creates new challenges for VA to meet its mission to provide top-notch service to veterans. In response, VA is undertaking transformational steps to increase efficiency, reduce costs, and improve overall quality of service.

In alignment with the Executive Order (EO) 13800, Strengthening the Cybersecurity of Federal

Networks and Critical Infrastructure, released in May 2017, VA has been proactively prioritizing

Information Technology (IT) modernization by sun-setting legacy systems and software, consolidating disparate environments, and utilizing adaptive technology, such as cloud computing capabilities.

As VA progresses to take advantage of cloud computing capabilities, in support of our veterans, it is vital that VA continues to protect and secure the cloud-based information systems and data that enable critical services to our veterans. The strategic objective of the Enterprise Security

Architecture (ESA) Cloud team is to continually improve VA security capabilities by proactively identifying and mitigating evolving cloud security risks to secure the VA cloud environment.

1.2. Purpose and Scope

The purpose of this document is to provide VA System Owners and Stakeholders security guidelines and minimum security requirements for VA cloud deployments. Stakeholders include departments within VA that have the responsibility for managing and configuring cloud services.

Cloud usage by VA will continue to evolve as updates and changes to hardware, software, configurations, etc., occur; therefore, this document is intended to be a living document that will be maintained and updated by the ESA Cloud team.

This document is not intended to be an operational or detailed configuration management guide.

This document was commissioned by the Chief, Enterprise Security Architecture / Director, Enterprise Security Architecture, and will undergo review by VA cloud stakeholders. It is the responsibility of VA System Owners and Stakeholders to work closely with the ESA Cloud team to understand the current security requirements and responsibilities.

The guidelines and minimum security requirements herein were developed through a series of collaborative working sessions with VA stakeholders, in addition to leveraging VA policies, industry recommendations for cloud security (Cloud Security Alliance), and Federal guidance and standards from National Institute of Standards and Technology (NIST) and Federal Risk and

Authorization Management Program (FedRAMP).

VA Cloud Architecture Security Pattern | 2

1.3. Cloud and VA

Cloud computing differs from traditional on-premises computing in that security responsibilities are shared between the Cloud Service Provider (CSP) and the customer. The guidelines and minimum security requirements in this document are structured to address shared responsibility model as it applies to VA’s use of the cloud across the three generic cloud service models:

Infrastructure-as-a-Service, Platform-as-a-Service, and Software-as-a-Service. The security responsibilities of VA and the CSP change depending on the service model in use.

The cloud service model definitions, per VA 6517 and NIST Special Publication (SP) 800-145, are:

Infrastructure-as-a-Service (IaaS): The capability available to the consumer is to provide processing, storage, networks, and other fundamental computing resources where the consumer is able to deploy and run arbitrary software, which can include operating systems and applications. The consumer does not manage or control the underlying cloud infrastructure but has control over operating systems, storage, deployed applications, and possibly limited control of select networking components (e.g., host firewalls).

Platform-as-a-Service (PaaS): The capability provided to the consumer is to deploy onto the cloud infrastructure consumer-created or acquired applications created using programming languages and tools supported by the provider. The consumer does not manage or control the underlying cloud infrastructure including network, servers, operating systems, or storage, but has control over the deployed applications and possibly application hosting environment configurations.

Software-as-a-Service (SaaS): The capability provided to the consumer is to use the provider’s applications running on a cloud infrastructure. The applications are accessible from various client devices through a thin client interface such as a web browser (e.g., web-based email). The consumer does not manage or control the underlying cloud infrastructure including network, servers, operating systems, storage, or even individual application capabilities, with the possible exception of limited user-specific application configuration settings.

1.3.1 VA Enterprise Cloud Use Case

The primary cloud deployment in use by VA is the VA Enterprise Cloud (VAEC) and is thus the use case referenced throughout this design pattern. Per VA memorandum, “Use of the VA

Enterprise Cloud to Host Applications,” released by the Office of Information Technology (OIT) on Nov. 30, 2017, “all project managers and business owners shall plan to utilize the VA

Enterprise Cloud to host any new software applications.” General Support System (GSS) in

VAEC supports VA cloud implementation and includes virtual machines, networking, network security services, configuration management, system scanning, logging, and other critical core services. The VAEC is comprised of Amazon Web Services (AWS) and Microsoft Azure IaaS cloud services and enables the use of PaaS, SaaS and hosting of custom applications. In the

VA Cloud Architecture Security Pattern | 3 context of the VAEC, the shared responsibility model is depicted below:

Figure 1- Shared Responsibility in the VA Enterprise Cloud (Source: Enterprise Cloud

Solutions Office)

In the VAEC, the VA Enterprise Cloud Solutions Office (ECSO) is responsible for managing the security of core services while project team or application owner is responsible for managing the security of their applications and data. When leveraging the VAEC, application inherits some of the security controls, thus saving significant cost, time, and resources on security control implementation and management.

VA Cloud Architecture Security Pattern | 4

2.Functional Area Guidelines and Minimum

Security Requirements The guidelines and minimum security requirements provided below are focused in the areas of

Network Security, Monitoring and Logging, Operating System and Database Security, Identity and Access Management, Data Protection and Encryption, Incident Response, Business

Continuity and Disaster Recovery, and Application Development and Application Programming

Interfaces Security (API). These guidelines and minimum requirements address concerns specific to the cloud and are supplemental to the requirements of VA Handbook 6500 and other

VA policies.

2.1. Network Security

The networking used in cloud infrastructures differs from traditional enterprise infrastructures.

CSPs use virtualized networks that allow for more flexibility in provisioning and architecting networks. This also provides security benefits with respect to isolation and network segmentation. As networks are not constrained by physical hardware, it is possible to build out as many isolated networks as desired, without it becoming cost prohibitive. This provides additional segmentation capabilities, such as the ability to apply firewall policies at granular levels to assets or groups of assets regardless of network location. VA should make use of these more flexible network security capabilities when implementing cloud systems.

The VAEC use case is referenced in the approach for development of network security requirements and guidelines herein.

The network security guidelines provided in this section are intended for IaaS implementations within the VAEC. In IaaS, the CSP is responsible for configuring and maintaining the physical network. The cloud consumer is responsible for provisioning and configuring the network resources required for their cloud implementation. This includes assigning Internet Protocol (IP) address space, creating separate virtual networks for different purposes, and providing security controls for these networks. Since the VAEC is built on an IaaS system, the guidelines herein also apply to the VAEC. In PaaS and SaaS, the CSP is responsible for network configuration;

hence, these guidelines and minimum requirements do not apply in those models.

These guidelines and minimum requirements are intended to mitigate the risk associated with the increased attack surface for cloud-based systems. Firstly, CSPs are especially vulnerable to attackers due to the value and quantity of data being stored in the cloud. Secondly, multi-tenancy may increase this risk as VA will not have control of/or insight into the security posture of other tenants. Due to lack of familiarity with cloud, misconceptions about the shared responsibility model, and a history of breaches in misconfigured government cloud systems, VA shall employ cloud-centric defense-in-depth. This strategy includes providing isolation and separation of cloud systems through the use of network segmentation, security groups, Access

Control Lists (ACLs) and routing tables.

Network Security Guidelines and Minimum Requirements

VA Cloud Architecture Security Pattern | 5

• System Owners shall implement network isolation and segmentation when using cloud

IaaS services.

• System Owners shall use security groups and ACLs to control access to and from segmented networks when using cloud IaaS services.

• System owners shall configure security groups with a default deny policy for both inbound and outbound communications when using cloud IaaS services.

• System Owners shall document security groups in the System Security Plan (SSP).

• System Owners shall enable all virtual network and security group logging capabilities and send them to the Enterprise Security Information and Event Management (SIEM) instances. In the VAEC, the logging shall be sent to the SIEM hosted in the core services network segment.

• VAEC shall create separate isolated networks for High and Moderate impact systems as defined in Federal Information Processing Standards Publication 199 Standards for

Security Categorization of Federal Information and Information Systems (FIPS 199) and

VA Handbook 6500 Risk Management Framework for VA Information Systems – Tier 3:

VA Information Security Program (VA Handbook 6500), Appendix F. The High network segments shall host only High (or lower) impact systems, and the Moderate network segments shall host only Moderate (or lower) impact systems. Moderate impact network segments shall not host High impact systems. Low impact network segments shall not host High or Medium impact systems.

• VAEC shall create separate network segments for production and non-production environments for each categorization level (Low, Moderate and High).

• VAEC shall create a separate isolated network segment for public-facing systems (logical

Demilitarized Zone [DMZ]).

• Security groups for logical DMZs shall be created to allow traffic to publicly accessed applications only via cryptographically secure protocols such as Hypertext Transfer

Protocol Secure (HTTPS) and Transport Layer Security (TLS). The ports, protocols, and reasoning for this access are required to be documented and approved by the Enterprise

Security External Change Council (ESECC).

• VAEC shall create separate network segments for core services systems.

• VAEC shall create security group policies to allow access between core services network segments and other network segments.

• Each security group policy shall permit only required traffic between the segments, and ports, protocols.

• All other exceptions to the default deny policy for security groups shall be documented and submitted for approval. The ESECC approves these requests for traffic between VA and the CSP. The Cloud Governance Board approves these requests for traffic within the cloud network.

• Peering between cloud network segments shall be documented and evaluated on a case by case basis during the ATO process.

• Transit virtual networks (VPCs/VPEs) between cloud implementations shall be documented and evaluated on a case by case basis during the ATO process.

• All traffic being routed to and from the VA enterprise network shall use dedicated connections between VA and the CSPs. Any exceptions must be documented and

VA Cloud Architecture Security Pattern | 6 evaluated on a case by case basis during the ATO process. This applies to all cloud service models (IaaS, PaaS, and SaaS).

• Traffic shall not be routed directly to/from the CSP and the Internet. All Internet traffic shall traverse the Trusted Internet Connection (TIC) per VA Handbook 6513 Secure

External Connections.

• Additional connections to CSPs shall be evaluated on a case by case basis. All additional connection requests and exceptions should be documented and submitted to the ESECC for approval.

• Remote user access shall be in accordance with VA Handbook 6500. Exceptions must be documented and evaluated during the ATO process.

• Reference VA Handbook 6517: Risk Management Framework for Cloud Computing

Services for further guidance.

2.2. Monitoring and Logging

Monitoring and logging applies to all service models in the cloud. However, more log types are available in IaaS than in PaaS or SaaS. IaaS offers the greatest number of log sources, including system, server, network and API logs. In PaaS, system, server and network logs may not be available, though this can vary depending on the CSP. In the case of SaaS, application-level logs may be the only log type available.

While the concept of monitoring and logging is similar for traditional enterprise and cloud environments, cloud implementations introduce additional complexity to on-premises network event streams. Robust log implementations will be even more important to manage increased volumes and variety of log events generated within emerging cloud deployments based on serverless architectures, Internet of Things (IoT), and containerization. VA has the responsibility to implement log management solutions for optimum ingestion, correlation, alerting, and reporting. Toward that end, it is better to have more metadata per log event than too little to avoid insufficient data for analytics. Stakeholders should also look ahead to future log management challenges in the cloud (e.g., the 3 V’s: volume, velocity, variety; storage, indexing and volumization, rotation, archival, query-ability and availability).

In the cloud context, logging can involve the installation of a logging agent on instances within the security enclave. This point is important for VA’s overall security posture, as the complexity of the enterprise cloud environment has the potential to obscure recognition and analysis of incidents. As more applications are migrated to the VA cloud environment, visibility into those applications is also crucial. Therefore, application logs should be engineered to report relevant data points that may not have surfaced in OS or database server logs. Likewise, accurate event timestamping and documentation of log file destinations in cloud storage are requirements (see section 2.8. Application Development and API Security for additional information on application-specific logging).

Event Characterization: A key cloud consideration is to monitor and log machine and user-driven events. Important user-based events include privilege escalation, configuration drift, and authentication events. Because IP addresses can change or be shared across virtual machines, other methods such as unique identifiers are required to differentiate event types. Creating a

VA Cloud Architecture Security Pattern | 7 baseline cloud logging template or schema to test against and to facilitate automation will save administrative overhead in the long term.

Instrumentation: Instrumentation is a critical part of logging and monitoring. Data-driven decisions about the performance and health of a system are possible only if relevant data are captured. Additionally, stakeholders shall decide whether to centrally manage logs or to distribute them to multiple secure storage repositories. Logs shall be highly available, regularly backed up, and encrypted at rest and in transit. Log storage methods shall take into account chain-of-custody and forensic needs. Logging solutions shall integrate on-premises and cloud provider logs for hybrid cloud solutions. Automation shall be integrated into log management wherever possible to free up resources for more in-depth security work such as log analysis, manual dataset querying and extraction, event correlation, and predictive analytics.

Data Characterization: In concert with proper log instrumentation and management, VA shall have a data characterization strategy and an associated data taxonomy in place to allow for accurate and agile data mining, reporting and analytics. It is recommended to include more metadata rather than run the risk of too little to allow sufficient characterization.

While the purpose of this document is to address cloud service providers from a vendor-agnostic vantage point, the following are examples of the primary log sources available in two major

CSPs currently in use:

AWS: CloudTrail (API logging), Elastic Load Balancer access logs, S3 server access logs, CloudWatch, VPC Flow Logs, Kinesis Streams (real time data stream).

Azure: Azure Monitor, Audit logs, Activity Logs, Resource-level diagnostic logs, Security Center, Network Watcher, Log Analytics via Operations Management Suite

(OMS).

Alerting & Monitoring Guidelines and Minimum Requirements:

Log events shall be fed into VA-designated alerting and monitoring tools to provide optimal situational awareness of VA’s security posture in a cloud deployment. To provide such an alerting and monitoring capability for the cloud, VA, at minimum, shall:

• Determine VA’s ideal alerting medium(s) for cloud deployments (e.g., email, dashboards, Short Message Service [SMS]).

• Employ integrated dashboards to provide a ‘single pane of glass’ view for monitoring security events in the cloud for specific Cyber Security Operations Center (CSOC) use cases.

General Logging Guidelines and Minimum Requirements:

When operating in the cloud:

• VA shall decide system owner metric requirements for cloud applications.

• System Owners shall determine types of logs to collect from cloud deployments and log storage locations in accordance with VA Handbook 6500 and the CSOC Cloud Visibility

Requirements in Appendix D.

VA Cloud Architecture Security Pattern | 8

• VA shall establish and employ a data characterization methodology for data in the cloud.

• VA shall distribute log management architecture diagrams for cloud platforms to security stakeholders.

• VA shall identify the appropriate agents to place on endpoints within the cloud environment.

• VA shall identify log file destinations for VA systems in IaaS and PaaS platforms; logs shall be sent to object storage in designated CSP storage buckets; indexers shall collect logs from every available source.

• VA shall encrypt logs in the cloud at rest and transit to maintain confidentiality and integrity in accordance with VA Handbook 6500.

• Reference VA Handbook 6517: Risk Management Framework for Cloud Computing

Services for further guidance.

2.3. Operating System and Database Security

2.3.1. Operating System

The Operating System (OS) responsibility in the cloud can vary depending on the cloud service model. The responsibility and management at the hypervisor level is the responsibility of the

CSP. In the IaaS service model, VA is responsible for configuration and patching of OS instances. In PaaS and SaaS, the CSP manages OS functionalities, leaving the customer with less responsibility and control.

Within the VA Enterprise Cloud, the VAEC team shall provide management of the OS for virtual instances within VA cloud deployments. This management will include deployment and patching of the OS used in the virtual environments. For operating systems and databases deployed outside of the VAEC, it should be noted that System Owners shall coordinate with

Information Technology Operations and Services (ITOPS) to determine responsibility for configuration and management of cloud services. Refer to VA Handbook 6517: Risk

Management Framework for Cloud Computing Services for further guidance.

When migrating systems to the cloud it is advised that a system does not follow the “lift and shift” methodology. Lifting and shifting applications does not take advantage of the scalability and resiliency available in the cloud. Instead, cloud-based systems and applications should be architected to take advantage of these features. Security shall be designed and tested through all phases of the development and deployment. All databases and operating systems selected for the cloud shall be compliant with the VA Technical Reference Model (TRM).

2.3.1.1. Design and Build

When migrating to the cloud, it is strongly suggested that developers take advantage of the cloud’s virtualized compute capabilities (such as Microsoft Azure virtual machines (VMs) or

Amazon Elastic Compute Cloud (EC2) instances), which are foundational infrastructure services that provide secure, resizable compute capacity in the cloud. These are designed to make web-scale cloud computing easier for developers. Developers benefit from the ability to scale systems up and down quickly in a cost effective manner. Utilizing these capabilities facilitates standardization in virtual machines, allows for control over machines, and standardizes security requirements across the system.

VA Cloud Architecture Security Pattern | 9

Configuration of the OS is required to meet approved VA baseline configuration guidelines and the Center for Internet Security (CIS) guidelines. OS configurations shall be validated using

VA’s approved configuration management tool.

2.3.1.2. Test and Production

Prior to deployment of the OS image to the production environment, the OS is required to undergo a credentialed OS-level scan completed by the CSOC. Please refer to the Office of

Information Security (OIS) Authorization Requirements Standard Operating Procedures (SOP)

(current version: 3.14) for requirements and specific details.

Operation

Once the OS has been deployed, the VA Enterprise Cloud team is responsible for coordinating with the System Owner to conduct monthly credentialed OS-level scans conducted by the CSOC.

The System Owner is responsible to remediate all vulnerabilities within the following VA timeframes per VA Handbook 6500, Appendix F, Attachment 2:

• Critical: Patches are required to be tested and applied within 30 days.

• High: Patches are required to be tested and applied within 60 days.

• Moderate: Patches are required to be tested and applied within 90 days.

• Low: The System Owner and/or designee determines the patching time frame.

• Emergent: Patches are required to be tested and applied as soon as possible.

Patching and Configuration Guidelines and Minimum Requirements for the OS:

• VA-approved reference baselines shall be used for all images in the cloud.

• Patching of the OS shall be handled by the VAEC team for operating systems in the

VAEC. If the System Owner has deviated from the standard OS image or has added additional software, the System Owner shall be responsible to coordinate and patch the

OS or additional software.

• Anything installed that is not part of the standard VAEC team list of core services is the responsibility of the System Owner to maintain, upgrade, and patch in accordance with

VA policy. All deviations shall be documented and maintained by the System Owner for auditing purposes.

• For OS logging, please refer to section 2.2 Monitoring and Logging.

• OS patches shall be tested in a pre-production environment prior to pushing into production.

2.3.2. Database

Database responsibility in the cloud can vary depending on the cloud implementation model.

Similar to OS responsibilities in the cloud, VA is responsible for managing databases deployed in IaaS. The responsibility and management of the database is the responsibility of the CSP if the System Owner chooses to leverage managed database services (e.g. PaaS managed database services). When using managed services, the CSP will install, patch, and perform backups of the data.

https://vaww.sde.portal.va.gov/svcs/sma/BCM/VA_Baselines/Forms/AllItems.aspx https://vaww.portal2.va.gov/sites/infosecurity/ca/CA%20Home%20Documents/ATO%20Documents/Authorization%20Requirements%20SOP%20Guide.doc https://vaww.sde.portal.va.gov/svcs/sma/BCM/VA_Baselines/Forms/AllItems.aspx

VA Cloud Architecture Security Pattern | 10

If the System Owner chooses to leverage an unmanaged service, the responsibility of installation, configuration, patching, and backups is that of the System Owner.

• The System Owner shall coordinate with the VAEC team to determine ownership and responsibility of installation, configuration, patching and backups of databases hosted in the VAEC.

• The System Owner shall maintain and document a secure configuration and baseline of database instances. All deviations from VA database baselines shall be maintained and documented for auditing purposes.

• VA shall conduct credentialed database security scans to verify configuration and patch levels. The System Owner is required to coordinate scan activities with the CSOC.

• The System Owner shall remediate security scan findings within the established VA patching timeframes.

• The System Owner shall enable logging for the database. Please refer to section 2.2

Monitoring and Logging.

Regardless of the database engine or cloud service model utilized, it is the responsibility of the

System Owner to ensure the data is protected in a secure manner meeting VA requirements. VA is required to meet FIPS 140-2 requirements per VA Handbook 6500, Appendix F to ensure VA data is securely protected. In most cases, database encryption is not turned on by default, and shall be enabled during configuration. The Data Protection and Encryption section provides additional details to secure and protect data in the cloud.

2.4. Identity and Access Management

Identity and Access Management (IAM) in the cloud is multifaceted due to the shared responsibility model between CSPs and the cloud consumer’s IAM environment. CSPs are responsible for managing the underlying identification and authorization structure for access to the cloud services environment, while the customer is responsible for management of identities, access, and entitlements to the consumer organization’s applications. Since each CSP has their own IAM system, the complexity of IAM management increases as the number of CSPs increase. IaaS, PaaS, and SaaS services all include an IAM component with a joint responsibility between the CSP and the cloud consumer. Refer to VA Handbook 6517: Risk Management

Framework for Cloud Computing Services for further guidance.

The Office of Identity, Credential, and Access Management (OICAM) within the Office of

Human Resources & Acquisitions (HR&A) provides enterprise identity, credential and access management (ICAM) services for VA. Business owners shall work with the HR&A OICAM office to determine the appropriate implementation for the cloud access for VA systems. Since each CSP has their own IAM system, every cloud service shall be assessed by the OICAM office to determine the best method for integration with ICAM services. The services include Identity

Services (IdS) (Master Veteran Index [MVI]) and Access Services (AcS) such as Provisioning, Single Sign-On internal (SSOi), Single Sign-On external (SSOe), Specialized Access Control

(SAC), Credential Service Provider (CSP), Identity Proofing, Electronic Signature, and

Compliance, Audit and Reporting (CAR). Business owners shall submit a service request in

VA Cloud Architecture Security Pattern | 11 order to obtain ICAM services. The service requests are located on ICAM Central at https://www.osp.va.gov/Office_of_Personnel_Security_and_Identity_Management.asp

The VAEC system provides VA managed Active Directory services to applications as a core service.

The following items are unique to CSP IAM services:

• Each CSP provides their internal IAM system for direct access to cloud services. These

IAM services shall be configured securely to avoid compromise. This includes limiting privileged access and enabling multi-factor authentication for all accounts. Even if VA

ICAM services are used for the majority of IAM services, each cloud IAM service will have aspects that need to be configured and managed (e.g. system provisioning and accounting). These services shall be limited to administrative personnel and all access and actions shall be logged.

• CSP employees may need temporary access to VA systems for maintenance or troubleshooting problems. Typically, these are temporary accounts that are provisioned to complete a specific task and are disabled once the task is complete.

• The logging provided by CSP IAM services may differ in context and detail from on-premises systems. Monitoring processes and log analytics may need to be modified to identify and detect compromise of privileged accounts.

When managing IAM in the cloud, VA shall comply with all security policies including VA

Handbook 6500, Appendix F, and VA 6510. In executing these policies, VA shall be cognizant of the unique issues of IAM in the cloud and implement controls that account for these issues.

IAM Security Guidelines and Minimum Requirements:

• System Owners shall work with the HR&A OICAM office to obtain VA’s ICAM services in the cloud.

• All cloud services shall be assessed by the HR&A OICAM office to identify the best method for integration with VA’s ICAM services.

• System Owners shall work with the HR&A OICAM office to develop scenarios to address IAM technical failures and remediation.

• System Owners shall limit the use of CSP IAM services to provisioning, troubleshooting and accounting purposes. General users should not use CSP IAM services.

• System Owners shall disable the root accounts of CSP IAM services. Individual user identities with administrator roles shall be created to manage cloud services.

• System Owners shall enable multi-factor authentication in accordance with NIST SP 800-

63-3 for all CSP IAM implementations.

• System Owners shall enable logging for all CSP IAM actions in accordance with VA

Handbook 6500 and send them to the enterprise SIEM.

• VA shall develop incident response procedures to address compromise of privileged cloud user accounts.

https://www.osp.va.gov/Office_of_Personnel_Security_and_Identity_Management.asp

VA Cloud Architecture Security Pattern | 12

2.5. Data Protection and Encryption

Due to the cloud’s virtualized and elastic nature, data storage falls into several categories: object, volume, database and application-level. Across each of the three service models of cloud computing, the shared responsibility model dictates that customer data is the responsibility of the customer. While cloud vendors provide storage services and some protection capabilities natively, VA stakeholders need to ensure that proper encryption and data protection settings are in place for VA systems and applications when moving to, and operating in, the cloud.

Key management is an important component of data protection in cloud environments. There are three general key management scenarios:

• VA controls the encryption method and the entire key management infrastructure (KMI).

• VA controls the encryption method, the CSP provides the storage component of the KMI;

and VA provides the management layer of the KMI.

• The CSP controls the encryption method and the entire KMI.

VA should consider employing hardware security modules (HSMs). In the VAEC, for example, AWS and Azure are currently the prevalent CSPs in use. In AWS, CloudHSM is the relevant

HSM option. Azure’s Key Vault also has an HSM capability. These options come at an extra cost, and if employed, should be stood up within a highly available, fault-tolerant architecture.

AWS CloudHSM offers FIPS 140-2 Level 3 validated HSMs, while Azure Key Vault offers

FIPS 140-2 Level 2 validated HSMs. Alternatively, on-premises HSMs are also an option. The optimal HSM deployment should be decided by VA stakeholders.

The VAEC architecture involves use of the TIC. Encrypting data in transit using IPSec or TLS is a requirement. VPN connections to CSPs should be decrypted prior to traversing the TIC connection. In all cloud deployments, because API access figures prominently in cloud architectures, securing API traffic between the API client and cloud endpoints is a requirement.

VA data, applications and systems being housed in the cloud shall adhere to the system categorization guidance set forth in FIPS Publication 199 Standards for Security Categorization of Federal Information and Information Systems, which classifies systems based on potential impact should there be a breach of confidentiality, integrity, and/or availability. Such potential impacts fall into the Low (limited adverse effect on organizational operations, organizational assets, or individuals), Moderate (serious effect), and High (severe or catastrophic effect) categories.

VA System Owners and stakeholders aiming to operate in the cloud shall implement a data loss prevention (DLP) solution that follows the enterprise-wide VA DLP policy (in development).

The purpose of DLP is to monitor access to sensitive data, prevent breaches, leaks, and spillage of such data, and to prevent the placement of sensitive data in unauthorized applications and repositories. DLP functionality may be offered natively by a CSP at the SaaS level (for example, Microsoft Office 365, which is in use by VA, has integrated DLP capabilities), but will likely be the responsibility of VA to implement in IaaS and PaaS. Many cloud access security brokers

(CASBs) offer DLP capabilities as well. Cloud-focused DLP solutions shall be evaluated by VA stakeholders for their appropriateness and utility in VA’s disparate cloud environments.

VA Cloud Architecture Security Pattern | 13

A final data protection consideration in the cloud is that data governance should include scheduling snapshots of virtual instances to prevent data loss. A snapshot is a point-in-time capture of all the components required to recover and restore data. As such, snapshots themselves shall be encrypted. Please see section 2.7 Business Continuity and Disaster Recovery for additional requirements related to backups and snapshots.

2.5.1. Data Decommissioning and Exit

Data deletion is different when using a cloud vendor and varies from CSP to CSP. For example, AWS advises that when a deletion request is invoked, AWS does not decommission the underlying physical media, but rather the underlying storage blocks are marked as unallocated.

When AWS determines data has reached end-of-life, AWS follows Department of Defense

5220.22-M and NIST SP 800-88 to destroy data. VA shall work with cloud vendors to follow the data deletion and retention guidance specified in VA Handbook 6500, Appendix E, including that specific to personally identifiable information (PII). VA tracks the existence of PII, personal health information (PHI), and payment card information (PCI) via the VA Enterprise

Architecture Repository (VEAR) at both the system and data store levels. Data sensitivity and definitions are dictated per VA Handbook 6500, Section 3.

VA shall plan for the potential need to exit a cloud provider and ensure that all stored VA data are portable and securely deleted from the cloud upon termination. This prevents the lack of data portability and extraction that can lead to “vendor lock-in.” Further, upon removing data from a cloud provider’s environment or exiting a CSP agreement entirely, VA shall use crypto erasure or crypto shredding techniques, whenever possible, to reduce the risk of incomplete data deletion.

Key Service Level Agreement (SLA) terms pertinent to data deletion include:

• Whether vendor provides secure deletion (e.g., degaussing or crypto erasure) of archived and backed-up data as determined by the tenant.

• Determine if there is a published procedure for exiting the service arrangement, including assurance to sanitize all computing resources of tenant data once a customer has exited your environment or has vacated a resource.

Cloud Data Protection Guidelines and Minimum Requirements

To secure data in the cloud:

• System Owners shall identify and classify cloud data assets.

• VA shall implement a data loss prevention (DLP) solution for VA cloud deployments as directed by policy (Refer to VA DLP Policy – In Development).

• VA shall refine its data storage policies to identify what data is and is not allowed in the cloud.

• VA shall keep an up-to-date dossier of the storage locations in the cloud and monitor for integrity and access.

o Storage locations do not just signify repositories or addresses; While cloud providers’ government cloud regions may be confined to a single region (for example, AWS GovCloud), it is important for VA to have situational awareness

VA Cloud Architecture Security Pattern | 14 into the storage and replication schemes in place within any CSP’s region of operation. If CSP’s expand the reach of their Government-approved cloud services to new regions, it will enhance VA’s data security posture to have awareness into data dispersion and replication methods employed by CSPs.

• VA shall have a sanitization and isolation process in place for data coming into VA cloud systems from public or untrusted sources.

• For development, test, and sandbox environments in the cloud, VA shall create test or

‘dummy’ data sets to avoid sensitive data exposure.

• System Owners shall implement versioning for cloud object level storage.

• In cases where it is possible, VA shall manage its encryption keys for VA cloud systems;

however, when utilizing managed services provided by CSPs, the keys may be managed in a proprietary fashion by the CSP.

• Keys for VA cloud systems shall be rotated or refreshed on a regular basis as decided by

VA stakeholders.

• Snapshots of virtual machines in VA cloud deployments shall be encrypted.

• Data stored in the cloud shall be encrypted using server-side encryption or encrypted prior to upload.

• Keys shall be passed to the cloud client using secure transport methods (TLS, SSH) from the VAEC KMI to ensure confidentiality and integrity.

• Cloud storage repositories shall be configured to be private.

• Reference VA 6500, Appendix F for Privileged Access Module (PAM) and Least

Privileged Access guidance consistent with NIST 800-53

2.6. Incident Response

For VA procured cloud services, incident response is a joint effort between the CSP and VA.

Depending on the type and severity, incident response may also involve United States Computer

Emergency Readiness Team (US-CERT) and FedRAMP. With multiple parties responsible for different areas of incident handling:

• Clear roles and responsibilities shall be defined.

• Notification procedures shall be developed and documented, and shall cover the cases when the CSP discovers an incident, when VA discovers an incident, and when US-

CERT discovers an incident that affects VA data and/or CSP systems.

The specific notification requirements are outlined in the FedRAMP Incident Communications

Procedure, v1.0. The role and responsibilities and notification plans should be determined and shared between VA and the CSPs. FedRAMP certified CSPs include their incident response plans and notification procedures in their FedRAMP packages. For non-FedRAMP services, VA shall request the CSP’s incident response plan. At the time an account is established, VA should provide their incident notification contacts to CSPs. Updates of these contacts should be provided to the CSPs whenever they change.

The cloud affects all phases of the security incident lifecycle as described in NIST SP 800-61 rev

2, as described below:

VA Cloud Architecture Security Pattern | 15

• Preparation: VA incident response plans should be updated to include incident response procedures for incidents in the cloud. This includes defining roles and responsibilities, notification procedures, escalation procedures, data and formats available for forensics purposes, and tools needed to investigate an incident in the cloud.

• Detection and Analysis: In addition to monitoring systems in the cloud, VA should also monitor the management plane of the cloud. This includes monitoring API calls, application logs, and management activity logs. More information on monitoring and logging in the cloud can be found in section 2.2 Monitoring and Logging. Automation and orchestration can be used in the cloud to accelerate response and maintain the state of the cloud at the time of an alert.

• Containment, Eradication, and Recovery: Containment of an incident can occur much faster in the cloud. A new clean environment can quickly be built, and the compromised instance can be removed from the environment and virtually firewalled off. This gives the incident response team the opportunity to observe the attacker’s exploit methods and determine the scope of the breach. During this phase, the incident response team should determine if the management plane was affected by the attack and if new instances are free of the attacker. This can be done through reviewing the management plane logs and by assuming the root role to ensure that anomalous behavior is not being hidden from lower level users.

• Post Mortem: After an attack, the incident response team should review their procedures and determine what did and did not work. This may result in updating the

VA incident response plan or SLAs with CSPs.

Incident Response in the Cloud Guidelines and Minimum Requirements:

• VA shall review CSP incident response plans to understand incident handling procedures and coordination of the CSPs. This includes defining the roles and responsibilities of the

CSP, the designated CSP contact people, the expected response time, and the CSP escalation procedure.

• VA shall integrate CSP incident notification and response procedures into the VA incident response plans.

• VA shall ensure the CSP has correct VA contacts for notifications of incidents discovered by the CSP.

• VA and CSP shall identify and agree upon an out-of-band notification procedure in the case of a communications failure.

• VA shall test incident response procedures with the CSP at least annually per FedRAMP guidance. This includes testing roles and responsibilities, communication methods and hand-offs.

• VA shall understand and document the data and logs that will be available to VA for incident investigation. This includes understanding the content and format of data that will be supplied by the CSP.

• VA shall determine and document the tools and processes to be used for investigations in a cloud environment.

• Due to the dynamic and high-velocity nature of the cloud, it is recommended that certain incident response tasks be automated. These include taking snapshots of storage, VA Cloud Architecture Security Pattern | 16 capturing metadata, and pausing virtual machines to save the volatile memory state at the time of an alert.

• VA shall develop procedures for maintaining a proper chain-of-custody for forensics data relating to incidents in the cloud.

• VA shall monitor the management plane in addition to deployed systems to identify incidents in the cloud.

• During the containment phase, VA shall attempt to verify that the management plane is free of an attacker. This may require assuming the root role to view activity that may be masked from lower level administrators.

• After an incident, VA shall conduct a postmortem to determine if incident response plans or SLAs should be changed to better handle incidents in the future.

2.7. Business Continuity and Disaster Recovery

Business continuity and disaster recovery (BCDR) processes and plans will change when migrating to the cloud. In IaaS, CSPs are responsible for the infrastructure, and thus responsible for contingency and disaster recovery planning for the infrastructure. In PaaS, CSPs are responsible for the contingency and disaster recovery of the infrastructure and operating system or platform. In SaaS, CSPs are responsible for contingency and disaster recovery of the whole system, including the application. VA has more flexibility and control of contingency and disaster recovery planning for IaaS, less with PaaS, and minimal with SaaS. VA shall consider

CSP BCDR plans and modify their own contingency and disaster recovery plans to account for the CSPs’ responsibility in relation to BCDR. In addition, the plans should be tested at least annually with the CSPs. VA should also modify their business impact analysis that takes into consideration the dependency on the CSPs for continuity of operations in the cloud. This includes dependency on the CSPs’ implementation of their own business continuity and disaster recovery planning, maintaining regulatory compliance, the CSPs’ responsibilities in the case of a data breach, and the possibility of a CSP discontinuing service.

VA cloud systems should be architected to be highly available and able to meet the recovery time objectives (RTO) and recovery point objectives (RPO) identified for the system(s). In the

VAEC, the GSS core services should be redundant and distributed across multiple regions or availability zones of each CSP. Each individual instance or system in the cloud should be replicated and load balanced in different availability zones or regions, so that if an outage or disaster occurs in one region or zone, the system can fail over to another instance in a different region or zone. This includes replicating operating system, database, and application settings across regions or zones. Availability status of cloud systems should be monitored, and in the case of a failure, failover should be automated. In times when systems are not able to fail-over, automation should be used to allow systems to fail gracefully.

The dedicated communication links between VA and the CSPs should be redundant, connected at different TIC gateways, and able to fail over in the case of a power outage or disaster.

Backup planning and procedures should be considered for cloud systems. Most IaaS and PaaS cloud providers offer tools to provide backup and restore services to cloud consumers. Storage volumes, images, and software configurations should be backed up and stored in different locations than the original images. The storage offering used for backup storage should be in

VA Cloud Architecture Security Pattern | 17 compliance with the RTO and RPO numbers for the system. In SaaS, CSPs provide their own backups, and typically offer cloud consumers the ability to export data. In cases where the CSP backup does not meet the system RTO and RPO numbers, VA can use these offerings to create their own data backups. Restoration using the backups should be tested on a regular basis in accordance with VA Handbook 6500.8. In all cases, backups should be encrypted.

Business Continuity and Disaster Recovery Guidelines and Minimum Requirements:

• VA shall review and modify its business impact analysis to account for cloud-specific concerns and risks in accordance with VA policy. These include dependencies on the

CSP, regulatory and compliance failure, data breaches, and vendor lock-in.

• The disaster recovery and contingency plans for cloud systems shall be updated to include notification procedures and contact information for designated CSP disaster recovery personnel. They shall include coordination procedures for working with CSPs in the case of a disaster or outage.

• Disaster recovery plan testing shall occur for cloud assets in accordance with NIST SP

800-34, rev 1, NIST SP 800-53, rev 4, and VA Handbook 6500.8. This testing shall be done in conjunction with the CSP.

• System Owners shall architect IaaS and PaaS cloud systems for high availability and in multiple availability zones and/or regions to comply with VA business continuity and disaster recovery policies.

• Storage volumes, images, and software configurations of cloud systems shall be backed up and stored in different locations than the original images. This process should be automated, and backups shall be encrypted.

• System Owners shall…