(U-FOUO) Annex_I_Cloud_Security_Guidance_v5.2.pdf

UNCLASSIFIED//FOR OFFICIAL USE ONLY

(U) ANNEX I:

CLOUD SECURITY GUIDANCE

Version 5.2

30 June 2018

Annex I: Cloud Security Guidance ii

(U) Table of Contents

(U) REVISION LOG ..................................................................................................................................... v

1.0 (U) INTRODUCTION

2.0 (U) GUIDANCE

2.1 (U) General Guidance

2.2 (U) Securing Virtual Private Cloud (VPC) Environments

2.2.1 (U) Restrict Access to Private Subnets/Control VPC Ingress Points:

2.2.2 (U) Design for High Availability & Disaster Recovery:

2.2.3 (U) Security Monitoring & Auditing:

2.2.4 (U) VPC Access & Account Creation:

2.2.5 (U) Elastic Load Balancer (ELB):

2.2.6 (U) Security Groups & Network Access Control Lists (NACL):

2.3 (U) Securing Elastic Compute Cloud (EC2) Instances

2.3.1 (U) Security Monitoring and Auditing:

2.3.2 (U) Access Control:

2.3.3 (U) Data Security:

2.3.4 (U) Configuration Management:

2.3.5 (U) EC2 Key-Pairs:

2.4 (U) AWS Auto Scaling

2.5 (U) AWS Trusted Advisor

2.6 (U) Securing Cloud Data

2.7 (U) Cloud Security Services

2.8 (U) Data Encryption

2.8.1 (U) Encrypting Data in Transit

2.8.2 (U) Encrypting Data at Rest and Key Management

2.9 (U) Identity and Access Management

2.10 (U) Bastion Host

2.11 (U//FOUO) Enterprise Cross Domain Services

2.12 (U) Enterprise Audit

2.13 (U) Infrastructure Security

2.13.1 (U) Chef Utility

2.13.2 (U) Puppet Utility

2.14 (U) Cloud Incident Response

2.15 (U) Patch Management

2.16 (U) Host-Based Security Services

2.17 (U) Platform Security

2.17.1 (U) Securing Containers

2.17.2 (U) Securing Pivotal Cloud Foundry

2.18 (U) Assessment & Authorization (A&A) iii

2.19 (U) Risk Management Framework

2.19.1 (U) Information Impact Level Determination

2.20 (U) Shared Security Responsibility Model

2.20.1 (U) Security Inheritance Model

2.21 (U) ATO Self-Assessment

2.21.1 (U) Body of Evidence

2.22 (U) Risk Evaluation Acceleration Management Process (REvAMP)

2.23 (U) DevOps Security

2.23.1 (U) Static Application Security Testing (SAST)

2.23.2 (U) Dynamic Application Security Testing (DAST)

2.23.3 (U) Interactive Application Security Testing (IAST)

2.23.4 (U) DevOps Software Security Testing iv

(U) TABLE OF FIGURES

Figure 1: (U) Auto Scaling Policy

Figure 2: (U) Security Templating Process

Figure 3: (U) Cloud Transition A&A Process

Figure 4: (U) RMF Process

Figure 5: (U) REvAMP Risk Evaluation Levels

Figure 6: (U) DevOps Pipeline

Figure 7: (U) DevOps Software Security Testing Workflow

Figure 8: (U) DevOps Software Security Testing Component Relationships

(U) LIST OF TABLES

Table 1: (U) Information Impact Level Attributes

Table 2: (U) Body of Evidence (A&A) Requirements

Table 3: (U) REvAMP (Levels 0-2) Qualification Criteria

Table 4: (U) ThreadFix Scanner Integrations with Corresponding Jenkins Plug-ins https://ideonline/sites/sein/isi/CloudAcceleration/Documents/Cloud%20Guidance%20v5.2%20-%20Guidance%20Summary%20Update/Historical/Version%205.2_2017_Drafts/2-Annex%20I_Cloud%20Security%20Guidance_Draft%206.0v3.docx#_Toc498941511 https://ideonline/sites/sein/isi/CloudAcceleration/Documents/Cloud%20Guidance%20v5.2%20-%20Guidance%20Summary%20Update/Historical/Version%205.2_2017_Drafts/2-Annex%20I_Cloud%20Security%20Guidance_Draft%206.0v3.docx#_Toc498941512 https://ideonline/sites/sein/isi/CloudAcceleration/Documents/Cloud%20Guidance%20v5.2%20-%20Guidance%20Summary%20Update/Historical/Version%205.2_2017_Drafts/2-Annex%20I_Cloud%20Security%20Guidance_Draft%206.0v3.docx#_Toc498941514 https://ideonline/sites/sein/isi/CloudAcceleration/Documents/Cloud%20Guidance%20v5.2%20-%20Guidance%20Summary%20Update/Historical/Version%205.2_2017_Drafts/2-Annex%20I_Cloud%20Security%20Guidance_Draft%206.0v3.docx#_Toc498941515 v

(U) REVISION LOG

UNCLASSIFIED

Version Revision Date Revision Summary

1.0 12/31/2015 Initial Release Cloud Security Guidance V1

2.0 02/29/2016 Cloud Security Guidance V2-updated Container Security, DewPoint, Automating

Security

3.0 4/19/2016 Cloud Security Guidance V3- update Enterprise Security Services, PCF

4.0 6/30/2016 Cloud Security Guidance V4: DevOps Testing; VPC & EC2 Security

4.1 8/5/2016 Updated classification/portion marking to support push to SBU

5.0 9/30/2016 Added Data Encryption and Key Management

5.2 5/31/2018 Updated Trusted Advisor, Auto Scaling, REvAMP, guidance statements, Cloud

Transition Security Process, and Data Encryption

Annex I: (U) Cloud Security Guidance

1.0 (U) INTRODUCTION

(U) The Cloud Security Guidance Annex provides security guidance for all NGA cloud environments on the Top Secret, Secret, and Unclassified domains. This security guidance is to be considered in cloud development, deployment, and operations.

(U) The guidance addresses key security requirements and offers recommended best practices and requirements to programs adopting cloud services. Key overarching concepts of this guidance are:

• Embedding security into development activities (i.e., enterprise services)

• Automating security processes (i.e., infrastructure as code)

• Governing security changes

(U) The document discusses security architecture impacts, as well as aligns the cloud security services with NGA inheritable security controls, processes and policies, and establishes a common terminology for cloud security services and Intelligence Community (IC) compliance standards.

(U) NGA’s approach to securing the cloud is to deploy security services that are consistent throughout the enterprise and across all security domains. Security services are focused on the services and tools that integrate or operate with AWS services, given its Cloud Service Provider (CSP) support in all three domains. Exceptions will exist where the security risk, and/or operating environment dictate deviations. Ultimately, the goal is to employ and manage a single baseline of security services that provide the necessary levels of security.

2.0 (U) GUIDANCE

2.1 (U) General Guidance

(U) Guidance: Program Managers and developers will adhere to all NGA/IC applicable security policies.

(U) This guidance provides software engineers and developers participating in the deployment of

NGA services to cloud environments with the essential security requirements and principals drawn from industry best practices. Information on signed and draft policies can be found at:

• NGA Corporate Policy Library

• NGA/TSR Reference Library

(U) Also, refer to AWS Security Best Practices for CSP-related information.

(U) Architects/Designers:

• Guidance: Developers shall leverage APIs to integrate enterprise security services with existing cyber capabilities available in the cloud.

• Guidance: Instances deployed in the cloud will enforce least privileged access controls.

• Guidance: Developers shall use layered security concepts to provide isolation between security zones based on data sensitivity—firewall layering, application containers, virtual firewalls.

https://d0.awsstatic.com/whitepapers/aws-security-best-practices.pdf https://www.intranet.nga.ic.gov/org/d/SitePages/DCOI%20Corporate%20Library.aspx#/viewer https://ngaonline/sites/CIO-T/TS/TSR/Pages/TSR_SOP.aspx https://ngaonline/sites/CIO-T/TS/TSR/Pages/TSR_SOP.aspx https://d0.awsstatic.com/whitepapers/aws-security-best-practices.pdf https://d0.awsstatic.com/whitepapers/aws-security-best-practices.pdf

• Guidance: Applications shall be deployed on authorized enterprise standard Virtual Machine Images (VMIs).

• Guidance: Trust boundaries between services and components should be highlighted in architecture patterns by:

o Building immutable infrastructure where security is integrated into the infrastructure utilizing approved VMIs that build to an approved baseline.

o Leveraging hardening scripts (i.e., Chef recipes) for consistent image deployments.

(U) Administrators/Developers:

• Guidance: Standard Virtual Private Network (VPN) protocols such as SSH, SSL and IPSEC shall be employed when deploying virtual private cloud (VPC).

• Guidance: Applications shall utilize external trusted security services for authentication and authorization, when possible.

• Guidance: Sensitive data will be encrypted at rest to ensure unauthorized access to sensitive data does not occur.

• Guidance: Data masking and encryption will be employed based on data sensitivity aligned with enterprise data classification standards.

2.2 (U) Securing Virtual Private Cloud (VPC) Environments

(U) Guidance: Secure Virtual Private Clouds (VPCs) shall apply security groups, establish subnets and control inbound and outbound traffic with Network Access Control Lists (NACLs) accesses to resources.

(U) Activities should employ a deny-all traffic by default enforcement policy for their cloud environment; and, only open the minimum necessary ports for the application to function.

Administrators should at a minimum adhere to security best practices for VPCs as follows:

2.2.1 (U) Restrict Access to Private Subnets/Control VPC Ingress Points:

• Only instances that should be accessible via the Internet shall reside in public subnets, when Internet access is required for Private Subnets, such traffic is to be routed through a network address translation (NAT) instance in order to prevent direct inbound connections.

• Isolate VPCs according to their corresponding functional areas, including development, testing, and production.

• Control and monitor all outgoing traffic traversing an internet gateway by restricting the ports, domains, URLs, etc.

• Establish VPN connections to the virtual private gateway from gateway devices on premises. Secure each connection with a pre-shared key in conjunction with the IP address of the customer gateway device.

2.2.2 (U) Design for High Availability & Disaster Recovery:

• Continuously backup your environment’s image to ensure fast recovery in the event of a system failure.

• Maintain high availability by deploying resources across multiple Availability Zones (AZ) within the same region. If a service disruption occurs in one AZ, traffic can be routed to alternate AZs to limit the impact of the disruption.

• Reduce latency of geographical distant users and contribute to high availability of mission critical systems by deploying resources across multiple regions when available.

2.2.3 (U) Security Monitoring & Auditing:

• Use CloudWatch or the AWS Management Console to monitor the health and performance of the instances running within the VPC, as well as the status of all VPN connections to reduce response time in the case of a disruption.

• Leverage CloudTrail to monitor Access Control Lists (ACL) within the VPC and ensure compliance with policy.

• Configure privileged IAM on the VPC in order to monitor and audit administrator access.

• Enable VPC flow logs to capture packet movement across the VPC.

• Apply anti-virus protection across all EC2 instances.

2.2.4 (U) VPC Access & Account Creation:

• Leverage the bastion host to access private instances within a VPC from an external network.

2.2.5 (U) Elastic Load Balancer (ELB):

• ELBs should only be provisioned for public subnets within the VPC.

• Increase ELB availability for redundancy purposes, given AWS stores ELB replication within one AZ, by periodically storing snapshots in the S3 for long-term durability in case of a service disruption.

• Enable point-to-point encryption using TLS for networks that use HTTPS connections; and, terminate at the ELB level as opposed to the instance level.

2.2.6 (U) Security Groups & Network Access Control Lists (NACL):

• Standardize the security group naming convention to improve management and reduce manual errors.

• Establish unique security groups for each VPC in order to maintain network segmentation.

• Security groups must be created specifically for the VPC, as any EC2 level security group(s) will not be applied within the VPC.

• Restrict access to administrative ports such as 22 (SSH) and 3389 (RDP) to only those IP addresses that absolutely require it. Similarly restrict access to common database ports.

• Avoid creating security groups that apply to port ranges, only create rules that apply to a single port.

• Use non-standard ports for internal application traffic.

(U) As NACLs are only applied to traffic that travels between subnets within the VPC, allow only required ports necessary for application to application communication and close all other unnecessary ports.

2.3 (U) Securing Elastic Compute Cloud (EC2) Instances

(U) Guidance: The Operating System (OS) and applications residing on cloud compute (e.g., EC2) instances will be patched as mandated to keep them secure from known vulnerabilities;

Risk Management will enforce patching frequency.

(U) Guidance: Encryption protocols, such as TLS or IPsec, will be used on all traffic between cloud compute (e.g., EC2) instances.

(U) Guidance: Activities residing on cloud compute (e.g., EC2) instances shall use hardened VMIs. If a custom VMI is absolutely necessary, the Program Manager shall coordinate the business justification with NGA’s Risk Management Team prior to installation.

(U) Guidance: SSH Access Keys and credentials will not be stored in publically accessible directories.

(U) Guidance: Programs should continuously scan for and remediate critical and high vulnerabilities of the VMI selected for use. Note, in some cases the baseline VMI published for enterprise use may require STIG configurations conducted by the ASP.

(U) Developers and administrators should at a minimum adhere to security best practices for EC2, as follows:

2.3.1 (U) Security Monitoring and Auditing:

• Employ granular access to different administrative functions in order to maintain separation of duties.

• Configure instances to send important local security log files to the organization’s centralized log management system for analysis.

• Minimize the attack vector by separating application components across security groups to prevent horizontal attacks. Critical components that do not absolutely require public access are to be maintained in private subnets.

• Audit access and all changes to EC2 instances to verify server integrity to ensure only authorized changes are made. Identify all system and application logs as well as the software components that generate EC2 instance logs.

• Deploy host-based firewalls to restrict inbound and outbound traffic.

2.3.2 (U) Access Control:

• APIs should be encrypted with TLS in order to maintain confidentiality and access to individual APIs is to be restricted to maintain least privilege.

mailto:TSRiskManagementDAORTeam7@coe.ic.gov

• Separate administrative accounts are to be created and multifactor authentication required for access to these accounts.

• Define the minimum set of privileges each server needs in order to perform its function.

• Require multi-factor authentication for access to the management plane. All such access is to be logged and audited, and privileges are to be revoked when there is no longer a business need for administrative access.

2.3.3 (U) Data Security:

• OS and applications on instances are to be patched regularly in order to keep them updated and secure.

• Employ encryption protocols such TLS or IPsec on all traffic between EC2 instances, AWS API endpoints, and all other sensitive endpoints in order to maintain confidentiality.

• Standardize naming conventions of instances to reduce manual errors.

• Utilize independent EBS volumes for the OS and data ensuring that the volume holding the data persists after instance termination.

• When not in use, instances should be stopped. Instance data should not be held in temporary storage in order to prevent data loss when instances start and stop. Termination protection is to be used in order to prevent accidental termination of instances.

• Take regular EBS snapshots. Maintain backups of the snapshots and periodically verify the integrity of the data within the backup copies.

• Regularly test the process of recovering instances and EBS volumes to ensure safe recovery in the event of a system failure.

2.3.4 (U) Configuration Management:

• Maintain a baseline configuration and track each server as a configuration item (CI).

• Assess each server against the current baseline to identify any deviations.

• Maintain an AMI catalog that contains security configuration baselines to ensure all instances are launched with standardized security controls.

2.3.5 (U) EC2 Key-Pairs:

• Regularly rotate SSH key pairs for EC2 instances.

Use pass phrases to protect keys from unauthorized access as they provide greater protection than standard passwords.

• Use non-standard ports to reduce the possibility of being noticed by port scanning technologies. However, all ports, protocols, and services must be authorized by NGA Risk Management and DISA.

• Private keys must not be stored in publicly accessible directories. Restrict key access to only those users who are authorized to use those keys.

• Properly dispose of keys. Completely remove all key pairs that are no longer attached to an EC2 instance.

2.4 (U) AWS Auto Scaling

(U) Guidance: Activities should configure Auto Scaling to use multiple AZs. If one AZ becomes unavailable, Auto Scaling can launch instances in another one to compensate.

(U) AWS Auto-Scaling is a service which allows consumers to launch and/or terminate EC2 instances to appropriately handle the demand for the application. By specifying auto scaling groups users can define a policy which establishes a minimum, maximum, and desired number of instances given the necessary performance the application must maintain. Automatic scaling of instances within a cloud environment contributes to enterprise cost savings. It also reduces the impact of incidental denial of service (DOS); and, should the demand of an application rise, the application shall remain accessible.

2.5 (U) AWS Trusted Advisor

(U) Guidance: Programs should utilize CSP security validation tools (e.g., AWS Trusted Advisor) to scan for security vulnerabilities (separate from the ACAS scans) before ATO and continuously after ATO is obtained.

(U) Guidance: Programs should refer and adhere to the guidelines specified within the security validation tool (e.g., AWS Trusted Advisor) SOP.

(U) The AWS Trusted Advisor service provides a mechanism to monitor and validate that the environment is optimized for cost, performance, fault tolerance, and security. The service scans the cloud resource’s configuration against pre-defined best practices. For example, Trusted Advisor will verify that a resource’s Security Groups are restricted to ports rather than open to all external access points. The service’s continuous monitoring and reporting dashboard provides valuable security recommendations and alerts when potentially insecure cloud configurations have been employed.

2.6 (U) Securing Cloud Data

(U) Intelligence Community Directive (ICD) 501 authorizes the DNI to produce and mandate metadata standards for the IC to adhere to in the cloud. The DNI has published guidelines and specifications for the use of Enterprise Data Headers (EDH) and Trusted Data Formats (TDF) to condition and standardize mission data for use. Specific guidance and format information on EDH and TDF can be found in Annex G: Cloud Data Guidance.

(U) The Chief Data Officer (CDO) seeks to apply the enterprise services needed to discover, access and transform NGA data for use by any activity. Obviously that cannot be done with classified and controlled information. However, automated access via Policy Enforcement Points (PEPs) is being applied, so that when user credentials meet the metadata attributes, the authorized user can access the data. Anyone with the rights and need to know would be granted access to the data.

Figure 1: (U) Auto Scaling Policy https://ngaonline/sites/CIO-T/TS/TSC/TSC%20Documents/Forms/AllItems.aspx?RootFolder=%2Fsites%2FCIO%2DT%2FTS%2FTSC%2FTSC%20Documents%2FReference%20and%20Policy%20Documentation%2FSOPs%5FConOps https://ngaonline/sites/CIO-T/TS/TSC/TSC%20Documents/Forms/AllItems.aspx?RootFolder=%2Fsites%2FCIO%2DT%2FTS%2FTSC%2FTSC%20Documents%2FReference%20and%20Policy%20Documentation%2FSOPs%5FConOps https://inteldocs.intelink.ic.gov/inteldocs/action.php?kt_path_info=ktcore.actions.document.view&fDocumentId=537769

(U) Data sets are tagged for ingestion into the cloud to identify what the data is, the classification of the data, under what authorities the data was received and what policies apply to the use of this data (i.e., need to know, restrictions on use) to support Attribute Based Access Control (ABAC).

Additional tags may also be applied to support a broad range of automated enterprise operations, such as discovery, retrieval, retention, and records management.

(U) Data security will be handled at the object level, with the mandate to leverage EDH and TDF, access, discovery and retrieval will be handled at the metadata level.

(U) Additional guidance can be found in the NGA Cloud Data Guidance Annex G.

2.7 (U) Cloud Security Services

(U) Guidance: Activities in the cloud shall integrate with the IC ITE Common Service Providers (CSPs) enterprise security services to eliminate duplication of security services.

(U) Deploying consistent security services throughout the enterprise and across all domains is the IC ITE goal. Instances will exist where the domain architectures and/or security risks may require deviation. Employing and managing a single baseline of security services enhances the ability to effectively monitor security compliance and effect enhanced cybersecurity.

(U) NGA’s approach to securing the cloud is to deploy security services that are consistent throughout the enterprise and across all security domains. The goal is to employ and manage a single baseline of security services that provide the necessary levels of security.

(U) The Enterprise Service Catalog, located in NGA’s ATLAS identifies the available cloud security service offerings.

2.8 (U) Data Encryption

2.8.1 (U) Encrypting Data in Transit

(U) Guidance: Data traversing across and between cloud environments will be encrypted.

(U) Guidance: Data exiting the cloud environment will be encrypted.

2.8.2 (U) Encrypting Data at Rest and Key Management

(U) Guidance: Data residing in the cloud will be encrypted.

(U) Guidance: Regardless of domain, programs managing Personally Identifiable Information (PII), Health Insurance Portability and Accountability Act (HIPAA), and Special Access Program (SAP) data will use a FIPS 140-2 Level 3 compliant key management solution.

(U) Guidance: PII, HIPAA, and SAP keys will be stored outside of the cloud, regardless of the security domain which they reside.

(U) Guidance: Impact Level 2 data and above (excluding PII, HIPAA, and SAP data sets) should leverage CSP key encryption services (e.g., AWS KMS) to encrypt cloud stored and compute data (e.g., EBS volumes, databases, S3 buckets, Snowballs).

(U) Guidance: Programs shall obtain privileges as a Key Admin role from the Cloud Operations team prior to creating keys and associated policies.

http://ndegsnarwvapp02.titanium.rttitanium.nima.ic.gov/ibmcognos/cgi-bin/cognosisapi.dll?b_action=cognosViewer&ui.action=run&ui.object=%2fcontent%2ffolder%5b%40name%3d%27NEAR%27%5d%2ffolder%5b%40name%3d%27Domains%27%5d%2ffolder%5b%40name%3d%27ESC%27%5d%2freport%5b%40name%3d%27ESC%20Cloud%20Services%27%5d&ui.name=ESC%20Cloud%20Services&run.outputFormat=PDF&run.prompt=true http://ndegsnarwvapp01.titanium.rttitanium.nima.ic.gov:8082/ee/request/folder?id=41238

(U) Guidance: CSP maintained data transport devices (e.g., AWS Snowballs) will undergo double encryption to protect Unclassified data during physical transport of the device.

(U) One of the main reasons for encrypting data is policy compliance. Data encryption provides for the enforcement of Confidentiality and Integrity for the various types of data that policy requires additional protection, such as PII, HIPPA, and Controlled Unclassified Information (CUI).

(U) Data at rest refers to data that is being stored. Data at rest is frequently defined as data that is not in use or is not traveling to system endpoints, such as S3 buckets, other systems, or any network file storage.

(U) The need for the encryption of data-at-rest will be based on the data protection requirements.

There are multiple factors that dictate the solution to be employed, which include data protection requirements, the technology, and the domain the data resides.

(U) Encryption key management is administering the full lifecycle of cryptographic keys and protecting them from loss or misuse. The lifecycle includes: generating, using storing, archiving, and deleting of keys. Protection of the encryption keys includes limiting access to the keys physically, logically, and through user/role access.

(U) The Data Encryption White Paper provides guidance for the utilization of the two approved solutions for use by NGA programs. These solutions are AWS Key Management Service (KMS) and Vormetric within the C2S environment. This document describes processes and guidelines for executing various key management functions and defines roles and responsibilities for KMS integrated services that are supported within the C2S environment.

2.9 (U) Identity and Access Management

(U) Guidance: Activities migrating to CSP services (e.g., C2S) shall integrate with GEOAxIS until such time that IC ITE’s IAA services can fully accommodate NGA mission application requirements.

(U) GEOAxIS is NGA’s Enterprise IdAM solution on all three security domains (TS, S, U). Activities will continue to leverage GEOAxIS services until IAA is completed. GEOAxIS provides the capability to control privileged access to the Cloud Access Point (CAP) for NGA’s Unclassified Cloud and Secret Cloud. GEOAxIS’ IdAM services (e.g., AuthN, AuthZ) are in place to broker requests to protected resources.

(U) The GEOAxIS Consumer Integration team facilitates program integrations. Programs will apply the PM’s Guide to Cloud Migration and contact NGA’s security POCs for integrating GEOAxIS services. For additional information on GEOAxIS services see:

• GEOAxIS (C2S)

• GEOAxIS (SC2S)

• GEOAxIS (Unclassified)

(U) Authentication (AUTHN)

(U) Guidance: Activities will enforce PKI authentication for user and non-person entities accessing their applications and services.

(U) In almost cases, except for publicly releasable material, activities must authenticate the user or the calling service, or both. Generally, for the web browser model, authentication can be offloaded https://intelshare.intelink.ic.gov/sites/nga-cloud/SiteAssets/SitePages/Guidance/NGA%20Cloud%20Guidance%20v5.2/Design%20White%20Paper%20-%20Data%20Encryption_June_2018.pdf https://intelshare.intelink.ic.gov/sites/nga-cloud/SiteAssets/PMs%20Guide%20to%20Cloud%20Migration-Process%20Templates%20Expert%20Tips-v1-mfarley-032717.docx https://geoaxis.nga.ic.gov/consumers/getting-started.xhtml https://geoaxis.nga.ic.gov/consumers/getting-started.xhtml https://geoaxis.nga.smil.mil/ https://geoaxis.nga.smil.mil/ https://geoaxis.nga.mil/consumers/getting-started https://geoaxis.nga.mil/consumers/getting-started to either GEOAxIS or the web server that a web app is operating in; the pattern redirects the user to an authentication mechanism and control is not returned until the user is verified to have authenticated.

(U) In other models, particularly for back end applications and services that don’t have a direct connection to the user, they must both authenticate the requesting service and accept an authentication assertion (i.e. token) that validates that the end user was authenticated.

(U) In addition to the GEOAxIS and web server features for authenticating the user, activities that communicate with other activities must mutually authenticate using two-way TLS. This establishes an encrypted channel and also satisfies the PKI requirement. Activities should rely on GEOAxIS to provide all of the user authentication processing for the variety of credential types, form factors, and degrees of authentication assurance. In cases where PKI is not a possible authentication method, the Activity must consult Risk Management and GEOAxIS to document use cases and determine a secure mechanism that provides an acceptable degree of assurance for the entity being authenticated.

(U) Activities deployed onto Pivotal Cloud Foundry may also integrate with the Single Sign On (SSO) Service Tile which provides GEOAxIS AUTHN API services for application users.

(U) A PKI-based authentication reduces the risk imposed by the use of username/password, which is the weakest form of authentication. Non-PKI scenarios include foreign partners without a PKI credentialing system; and, State, Local and Tribal users who have the same impediments; and mobile users who can’t use a CAC due of hardware limitations. These circumstances should be coordinated with Risk Management and GEOAxIS to determine the most appropriate means for authentication.

(U) Authorization (AUTHZ)

(U) Guidance: Activities should not attempt to construct their own authorization logic; leverage GEOAxIS or AccessIT! which immediately applies the authorization logic as denoted by the GUI-defined policy.

(U) Activities should call GEOAxIS with a request for an authorization decision, passing the identity of the user (or calling activity), the action requested, and the resource (or resource metadata) being requested. GEOAxIS or AccessIT! acts as the Policy Decision Point (PDP), retrieving the applicable policies, computing whether access is allowed, and returning a Permit or a Deny. The activity then acts as the Policy Enforcement Point (PEP), either allowing access or not.

(U) In some circumstances, the activity can request the user’s attributes and determine for itself whether the user deserves access, acting as both a PDP and a PEP. In this case, the IdAM provider returns attributes to the activity that apply to the user (i.e., citizenship and clearance). The activity then constructs the logic to compare the clearance against the classification of the data and checking dissemination/releaseability against the REL markings.

(U) The specific approach to authorization varies pending the activity’s software architectural model. Web applications that build the contents of a page piece-by-piece and for which each piece’s restrictions can vary should call the authorization (AuthZ) endpoint. Services that expose only endpoints to other activities should also make authorization calls to GEOAxIS. Activities using data from the OpenDataStore should first try to use the S3 PEP, which handles all authorization.

And as a last example, “Apps”, in the parlance of the API Gateway product Apigee, should rely on Apigee and the APIs (services) that it calls.

(U) Not leveraging these services requires justification to the Security Control Assessors and Risk Management. If these services potentially impact an activity’s performance, engage with GEOAxIS and the OpenDataStore team.

(U) Often authorization can be done at the data level and the activity can inherit the key NIST 800- 53 controls. In general, activities that actually manage the data are responsible for ensuring that the end user and the activity calling it are both eligible for the data being provided. One catch to this is that the application protecting the data may not understand its use; a user wanting to modify data may be able to read it but not change it; this distinction may be in the activity’s purview to authorize, but still by relying on GEOAxIS to the extent possible. Note that it is possible for a user to not receive some data, due to an intermediate application or service is not accredited for that data.

(U) Note, activities should be building for risk-based approaches. This concept adjusts access via the level of risk, including systemic risk (e.g., crisis scenario), a vulnerable environment, and the user’s credential strength. These variables might alter what actions are allowed, or whether data is obfuscated or volume-constrained. Each activity should be considering the question of how would they change what a user can see or do given the risk level.

2.10 (U) Bastion Host

(U) Guidance: System Administrators and other privileged users shall login using the Bastion Host for conducting elevated privileged functions.

(U) The Bastion Host Remote Desktop Gateway Service provides secure access to privileged users who shall serve as system administrators. Identifiers and verification credentials provided to the Bastion Host are validated with the Active Directory service prior to granting access to an authorized privileged system admin account. Authorized privilege users shall use their general user account when performing non-privileged functions.

(U) Refer to the IaaS Bastion Host Design Whitepaper for details on the C2S Bastion Host implementation and use. Note that the Unclassified cloud’s Bastion Hosts will be maintained within the EntServicesOps_VPC instead of the activity’s public subnet.

2.11 (U//FOUO) Enterprise Cross Domain Services

(U//FOUO) Guidance: Programs needing to leverage cross domain capabilities or connect to a cross domain should first receive authorization from NGA’s Cross Domain Support Office.

(U//FOUO) NGA’s Enterprise Cross Domain Service (ECDS) is an enterprise-wide service satisfying NGA’s cross domain requirements. It provides capabilities to transfer file, socket and streaming data in all directions between multiple network environments. ECDS is a system-of-systems architecture, leveraging best-of-breed cross domain solutions, data filtering engines, and systems monitoring and management technologies to provide high assurance, low latency transfers of data.

(U//FOUO) ECDS is not currently deployed within the cloud however it’s services are still offered to activities residing within the cloud on all three domains. Detailed information on ECDS services https://intelshare.intelink.ic.gov/sites/nga-cloud/SiteAssets/SitePages/Guidance/NGA%20Cloud%20Guidance%20v5.2/Design%20White%20Paper%20-%20IaaS-Bastion%20Host_June_2018.pdf can be obtained at the Security Engineering - Enterprise Cross Domain Home Page or contact the

NGA ECDS PMO.

2.12 (U) Enterprise Audit

(U) Guidance: Activities shall comply with ICS 500-27.

(U) Guidance: Activities will serve as the responsible entity for the collection and forwarding of the necessary application logs.

(U//FOUO) The ICS 500-27, Collection and Sharing of Audit Data, mandates that IC elements audit information resources within IC element environments. NGA has implemented an enterprise audit solution that captures and stores audit events per ICS 500-27, Appendix B - Set of Auditable Events.

The NGA enterprise AMIs are to be used for easy capture of OS logs.

(U) Activities in cloud environments are required to audit and log application activities to ensure:

• Application specific events are captured.

• S3 buckets are configured to the ICS 500-27, Appendix B requirements.

• All security related CloudTrail logs and alerts are forwarded to the Enterprise Audit repository for aggregation and correlation.

(U) Participating in onboarding events immediately following the program’s Categorization and Selection TEM will ensure audit requirements and the Enterprise Audit Onboarding Process are addressed.

2.13 (U) Infrastructure Security

2.13.1 (U) Chef

(U) Guidance: Activities shall use an automated enterprise configuration management tool for program development and operations.

(U) Guidance: When secure system configurations (e.g., Chef recipes) are modified they should be tested in a development/staging environment to validate functionality and availability of the changed environment.

(U) Guidance: Analytics should be implemented in support of the enterprise’s operational risk assessment to quickly identify instances which are not within compliance.

(U) Security is baked into the cloud architecture by leveraging automated enterprise configuration management tools such as Chef and Puppet to create recipes and hardening scripts to assure an approved and consistent security baseline is deployed with AMIs. The added benefit to this approach is verifiable compliance and an offering of quicker roads to authorization of applications by:

• Leveraging Infrastructure as Code for security automation

• Validating security relevant changes to code and environments

• Leveraging Chef recipes for consistent image deployments https://ngaonline/sites/t/Architecture-Engineering/TAD/TADI/Security_Engineering_-_Enterprise_Cross_Domain_Service_(ECDS)/SitePages/Home.aspx https://ngaonline/sites/t/Architecture-Engineering/TAD/TADI/Security_Engineering_-_Enterprise_Cross_Domain_Service_(ECDS)/SitePages/Home.aspx https://ngaonline/sites/t/Architecture-Engineering/TAD/TADI/Security_Engineering_-_Enterprise_Cross_Domain_Service_(ECDS)/SitePages/Home.aspx https://ngaonline/sites/t/Architecture-Engineering/TAD/TADI/Security_Engineering_-_Enterprise_Cross_Domain_Service_(ECDS)/SitePages/Home.aspx https://ngaonline/sites/t/Architecture-Engineering/TAD/TADI/Security_Engineering_-_Enterprise_Cross_Domain_Service_(ECDS)/SitePages/Home.aspx https://ngaonline/sites/t/Architecture-Engineering/TAD/TADI/Security_Engineering_-_Enterprise_Cross_Domain_Service_(ECDS)/SitePages/Home.aspx https://ngaonline.titanium.rttitanium.nima.ic.gov/teamsites/CyberSecurityOperations/Enterprise%20Audit/Policies/ICS%20500-27%20-%20Collection%20and%20Sharing%20of%20Audit%20Data.pdf https://ideonline/sites/sein/esi/ese/Documents/Project%20Documents/2015_Archive/Enterprise%20Audit%20Integration/Enterprise%20Audit%20Onboarding%20Overview_ver%205_6.pptx

(U) Configuration Management tools, such as Chef and Puppet, enable the creation of baseline templates that define the system security configuration. After a base template is established, privileged update and maintain those templates stored in the GitHub repository. By establishing a master template, security engineers and auditors understand exactly what is deployed onto the network. Secure configuration management can apply to any situation which has a defined repeatable security pattern across multiple instances, to include infrastructure as code, AMI hardening, or custom applications.

(U) Automating configuration management reduces the overall risk (as a result of human manual configuration errors), enforces and validates server policy compliance, simplifies patching across the distributed enterprise, enables rapid roll-backs, and reduces the time to deploy authorized environments. Figure 2 defines the high level process which development teams practice “baking-in” security.

(U) Chef allows application development teams to define Ruby-scripted ‘cookbook recipes.’ These recipes are the templates which developers leverage to streamline the installation, configuration, testing, and deployment of infrastructure and applications. When deploying Chef, refer to the audit guidelines to identify and remediate security patches to Chef’s software baseline.

(U) It is recommended as best practice for the Chef Server to enforce write privileges to a limited set of approved users to reduce exposure to malicious or incidental modifications. The Chef Server leverages the enterprise auditing tools (i.e. CloudTrail and HP ArcSight) to log all access and modifications to recipes which contributes to enterprise security. It establishes a rapid incident response process for immediate rollbacks and reduces the impact from insider threats.

(U) Once a Chef recipe is authorized and pushed to production, Chef clients will continuously call the Chef Server to identify and compare their current state with the desired state. If the clients do not meet the defined policy, they will automatically download and update their configuration with the new scripts.

2.13.2 (U) Puppet

(U) Puppet provides a node manager GUI which allows system administrators to create rules to update system attributes for a group of like-systems. For example, the node manager would enable a user to generate a single update for BIOS information which will propagate to all nodes. This capability reduces time and risk associated with manual configuration of individual instances. Like Chef, Puppet automates application deployment and orchestrates enterprise changes by enforcing the desired configuration state. Puppet’s reporting capability provides visibility into the security compliance posture, enabling enterprise tracking of all components and their corresponding modification history. When deploying Puppet refer to their security disclosures to identify and remediate security vulnerabilities from Puppet software.

(U) The Puppet agents frequently poll the Puppet Master Server to compare their current configuration state with the desired state found in the GIT repository. Should the agent have a different configuration, the server pushes an update to the appropriate agent. All server-to-client

Figure 2: (U) Security Templating Process https://ngaonline.titanium.rttitanium.nima.ic.gov/teamsites/CS/ITISCS/UnifiedServices/CloudSecurity/Gold%20Standard%20%20Security%20Documents/Audit%20Policy/UNC%20CHEF%20Audit%20Policy_Nov%2021%202016.docx https://ngaonline.titanium.rttitanium.nima.ic.gov/teamsites/CS/ITISCS/UnifiedServices/CloudSecurity/Gold%20Standard%20%20Security%20Documents/Audit%20Policy/UNC%20CHEF%20Audit%20Policy_Nov%2021%202016.docx https://puppetlabs.com/security updates are audited and reported to allow easy, efficient roll-backs, as needed. All updates and access the server are logged and captured in the enterprise audit solution. The master repository enforces RBAC to restrict permissions of project templates and modifications to agent attributes.

(U) Chef and Puppet allow consumers to inherit several NIST 800-53 configuration management controls; however, the implementation of internally developed or externally provided Ruby scripts allow developers to automate repeated patterns to account for other security controls (e.g., AMI hardening, audit log generation, and port configuration).

(U) Both tools simplify the management and enforcement of compliance policies. Their automation and propagation of hardened baselines reduce cost and risk from a manual configuration process; they effectively streamline the continuous integration/continuous delivery process allowing security to develop and accredit in an agile DevOps environment. Refer to the Chef Design Whitepaper for additional implementation details.

2.14 (U) Cloud Incident Response

(U) Guidance: System and mission owners shall report any cyber related event.

(U) Guidance: Mission owners and NGA/SISCC shall adhere to the Cloud Sanitization and Spill Standard Operating Procedures upon system compromise and/or unauthorized disclosure of information.

(U) A cyber event or a potential incident is defined in CJCSM 6510.01B or identified as a Category 1-9 classification event defined in the NGA CSOC SOP. The Computer Network Defense (CND) in a cloud environment is ever changing; and, NGA will take advantage of cyber technology to protect the data and the network. When handling an incident, responders will need to be familiar with specific services managed by the CSP such as:

• IAM - Managing identities (keys, security groups, policy, roles, and least privilege)

• EC2 - Instances, Instance types, Snapshots, AMIs, CloudFormation scripts

• S3 - Object Data Storage

• AWS Regions and Availability Zones

• CloudTrail & CloudWatch – Audit logs, API calls, instance monitoring

• Other services, such as EBS, VPC, Peering Connections, and CloudFormation

(U) The major difference in Incident Handling and Incident Response in cloud environments is the way that traditional ownership is defined and how a Computer Network Defense Service Provider (CNDSP) operates. Customers no longer have absolute control over how data is stored, routed, and the way it traverses the network. The CSP operates the ISP functions for the customer. Thus in the cloud, NGA has the responsibility for everything it deploys in the cloud that is not a part of the underlying infrastructure; which is essentially all application and the associated data.

(U) The shared responsibility model acts as a guide to NGA's CNDSP in reference to how cyber incidents are handled. As such, the CSP provides the tools to manage the configuration, logging, architecture and provide insight into traffic to and from any of the services that are being used.

The CSP is responsible for responding to events within any of its services. However, any applications deployed within are the responsibility of the customer.

https://intelshare.intelink.ic.gov/sites/nga-cloud/SiteAssets/SitePages/Guidance/NGA%20Cloud%20Guidance%20v5.2/Design%20White%20Paper%20-%20CHEF_June_2018.pdf

2.15 (U) Patch Management

(U//FOUO) Guidance: Activities shall ensure instances are patched as agreed upon by NGA Risk Management.

(U) Patch Management is key to ensuring that the operating system or back-end application is hardened to protect the environment from known vulnerabilities due to insecure system configurations. Activities will be able to leverage continuous ACAS Scans to verify that instances have been hardened to meet DISA STIG compliance.

(U) Two distinct patch management repositories are provided on each domain, one for Linux instances and one for Windows instances. The CSPs are not responsible for continuously patching the mission owner’s instances, however they will maintain these repositories for enterprise consumption. Activities will be able to pull from these repositories to obtain the necessary patch updates. The CSP does not patch the mission owner’s instances. However, they provide the repositories for mission owners to patch their own systems continuously. Consult the Patch Management CONOP for additional information. Also, refer to the Cloud Operations Team’s SOPs for detailed information how to patch instances, the following SOPs may assist activities:

• UNC-SOP-0022: DIV Repo Provision

• UNC-SOP-0037: UNC WSUS Maintenance

• UNC-SOP-0039: UNC WSUS Install and Configuration

• AWS-SOP-0036: C2S WSUS Maintenance

• AWS-SOP-0044: C2S Patch Updating Windows with WSUS and Linux with YUM Patch

Updates

• AWS-SOP-0063: C2S Linux Patching and Maintenance

2.16 (U) Host-Based Security Services

(U) Guidance: Mission owners shall ensure successful HBSS integration with the ePO server.

(U) HBSS Requirements are derived from USCYBERCOM. Waiver requests for HBSS requirements must be coordinated with the HBSS Ops Team and NGA Risk Management.

HBSS integration with the ePO server can be coordinated with the HBSS@coe.ic.gov. Note that HBSS is built into the AMI provided for enterprise consumption. For additional information and guidance on host-based security refer to the Host Defense Cloud Requirements Guide and the USCYBERCOM TASK ORD 14-0305.

2.17 (U) Platform Security

(U) Guidance: PaaS capabilities should be managed from dedicated Bastion Hosts residing within the cloud environment.

(U) Bastion Hosts are hardened, purpose built workspaces dedicated for management within a domain. Access to the workload owner’s application will be through an CSP account.

2.17.1 (U) Securing Containers

(U) Guidance: PaaS containers shall first receive ATO authorization for enterprise employment prior to using commercial and custom container applications in production.

https://ngaonline/sites/t/Architecture-Engineering/CAMG/Shared%20Documents/Working%20Documents/C.%20Security/04.%20Security%20Guidance%20Inputs/Reference%20Docs/2015%2012%2012%20-%20CONOPS_Patch%20Managment_v1_1.docx mailto:HBSS@coe.ic.gov https://ngaonline/sites/t/Architecture-Engineering/CAMG/Shared%20Documents/Working%20Documents/C.%20Security/04.%20Security%20Guidance%20Inputs/Reference%20Docs/(UFOUO)%20Host%20Defense%20Cloud%20Requirements%20Guide.docx https://ngaonline/sites/t/Architecture-Engineering/CAMG/Shared%20Documents/Working%20Documents/C.%20Security/04.%20Security%20Guidance%20Inputs/Reference%20Docs/(UFOUO)%20Host%20Defense%20Cloud%20Requirements%20Guide.docx

(U) ATO authorization for containers includes the following CIO-T security coordination, supplementary to the standard ATO requirements:

• Foreign Owned Controlled & Influenced (FOCI): Process used to mitigate supply chain risks

• Software Assurance Program (SWAP): Process for NGA Programs to gain approval to utilize Open-Source, Freeware, Shareware, COTS, GOTS, and Foreign software

Software Acquisition: (SWAP Form, Software White List, SWAP Status Spreadsheet)

• Automated DevOps Security Process: Approval process for widgets and application;

identifies vulnerabilities within software code using HP Fortify, SonarQube, OWASP Dependency Checker, OWASP ZAP, etc.

(U) Containers provide isolation between applications and between the application and the host operating system, which effectively reduces the attack surface to the container itself and to adjacent containers sharing the same infrastructure.

(U) The inherent nature of containers facilitates rapid and efficient patches to applications and reduces the amount of required patches to the underlying infrastructure as multiple containers can be deployed onto a single OS. This model mitigates many risks that result from individual application configuration management processes and contributes to a more effective security compliance strategy for the enterprise.

(U) With respect to the concept of inheritance, PaaS containerization applies the inherited security model. Once the organization secures the infrastructure layer, the container is responsible for securing the application data within the container. Securing the container boundary prevents modifications by unauthorized users, prevents data leakage between applications, simplifies audits and reduce impacts from insider threats.

(U) Administrators and Security Analyst:

• (U) Guidance: Users accessing containers shall be authenticated and authorized access to each specific container.

• (U) Guidance: Applications and services deployed within containers shall run with non-root privileges to mitigate risk of privileged escalation.

(U) Containers that require Root Privileges shall receive Risk Management authorization.

• (U) Guidance: Container software should explicitly deny all network traffic between external connections and adjacent containers existing on the same host to…