Friday, July 12, 2019

Where To Start wth Selecting a Cloud Service Provider (CSP) for DoD

The fundamental resource for cloud deployments in DoD is the DISA IASE. Until 15 Dec 2014 (the DoD CIO memo which permits DoD components to acquire cloud services directly) , the DISA ECSB (Enterprise Cloud Service Broker) was the designated broker for Cloud services in the DoD (see DoD Enterprise Cloud Service Broker Cloud Security Model, Version 2.1, March 13, 2014).
DoD uses the NIST SP 800-145 definition of cloud services to determine if a Cloud Service Offering (CSO) should be considered "cloud." Typical cloud services include any "as-a-service" offering:
  • Software As A Service (SaaS)
  • Platform As A Service (PaaS)
  • Infrastructure As A Service (IaaS)
  • Storage As A Service
Note the information below was written prior to the publishing of the SRG (the SRG replaced the cloud security model documents) and needs to be updated! The most current DISA cloud computing requirements is here:  DoD Cloud Computing Security. The current Security Requirements Guide is v1r2 published 25 MAR 2016.
(http://iase.disa.mil/cloud_security/Documents/cloudsecuritymodel_v2-1_20140320.pdf) is probably the first reference to go through. One of the first things that you need to do before selecting a Cloud Service Provider (CSP) is figure out what Impact Level (1-6) your service falls in. That will govern which CSP can host your application or data, because they will need a Provisional ATO (PA) for their service at that Impact Level. For example, AWS East/West (E/W) is approved at Impact Levels 1 and 2, and GovCloud is approved at Level 4 and IBM CMSG is approved at Level 5 (there are currently no CSPs approved at Impact Level 6, which is for Classified systems or data). The DoD approved CSOs are listed in the DoD Cloud Services Catalog.
To categorize your data and thus come up with an Impact Level, you use NIST SP 800-60 (two volumes, Volume II is what you need) to categorize the information type(s) stored, processed, disseminated, or otherwise used by the system. I have completed this activity for a few AGC services:  SDSFIE, IENC, and DDASS. The link to NIST SP 800-60 is here:  http://csrc.nist.gov/publications/nistpubs/800-60-rev1/SP800-60_Vol2-Rev1.pdf. You'll end up with an assignment for Confidentiality, Integrity, and Availability (CIA) for the system which can be Low, Medium, or High. That triad corresponds to an Impact Level. For example, {L,M,x} is an Impact Level 2 system which has low impact for confidentiality (this is public data, no big problem if it is released), medium for integrity (it's fairly important that the data is accurate and not changed), and an availability that is up to the system owner to select (i.e. it can be low, medium, or high). Here's a table of all the Impact Levels that were originally published under the DISA Cloud Security Model and have been reduced to 4 levels (2, 4, 5 & 6) with the release of the Cloud SRG:
  • Impact Level 1:  Unclassified, Public (NA-L-x)
  • Impact Level 2:  Unclassified, Private (L-M-x)
  • Impact Level 3:  Controlled Unclassified Information (L-M-x)
  • Impact Level 4:  Controlled Unclassified Information (M-M-x)
  • Impact Level 5:  Controlled Unclassified Information (H-H-x). This level may now be for National Security Systems (NSS). NSS are defined in CNSSI 4009 and NIST SP 800-59.
  • Impact Level 6:  For the Enterprise Cloud Service Broker (ECSB) Initial Operating Capability (IOC), only DoD Cloud Service Providers (CSP) are eligible to provide services for Impact Level 6. Any DoD CSPs providing service at Impact Level 6 must have a DoD ATO.
Note the "Private" tag on Impact Level 2. Per discussion with the DISA ECSB, they agree that public systems that use some kind of registration or access control (logon, but not necessarily DoD PKI), are considered "private" (which is different than "private" as defined by JTF-GNO CTO 07-015, which is what led us to using CAC or ECA for access to sites hosting CUI data).
The SRG introduces the requirement for DoD Provisional Authorizations (PA) and use of a Cloud Access Point (CAP) for Impact Levels 4-5 to mitigate risk to DoD by allowing CSPs to interconnect with DoD networks. The application of additional security controls beyond FedRAMP is termed FedRAMP Plus (+). FedRAMP is the minimum security baseline for all DoD cloud services. There are three paths to a Provisional ATO (PATO):
  • FedRAMP Joint Authorization Board (JAB) to DoD PA
  • FedRAMP Agency to DoD PA
  • DoD Sponsored (CSP needs 3PAO or DoD assessor)
"Shared Controls" require that the Cloud Service Offering (CSO) and Mission Owner address security.
How many controls need to be considered?
​ ​Required ​Total ​Mission Owners Can Add ​
​NIST Moderate ​260 ​260 ​ ​
​FedRAMP Moderate ​+65 ​325 ​ ​
​DoD Impact Level 2 ​+0 ​325 ​ ​
​DoD Impact Level 4 ​+35 ​360 ​9 (NIST) ​TBD (Privacy Overlay if required)
​DoD Impact Level 5 ​+9 ​369 ​12 (NIST) ​TBD (Privacy Overlay if required)
​DoD Impact Level 6 ​+0 ​369 ​11 (NIST) ​98 (from the Classified Privacy Overlay if required)

Computer Network Defense (CND) responsibilities must be clearly defined.
The Mission Owner defines the cloud availability and resiliency (disaster recovery, business continuity) under a Service Level Agreement (SLA) with the CSP.
When approaching cloud migration, organizations should identify their IT services and the information type(s) associated with them, categorize them, address "special considerations" identified in NIST SP 800-60 Vol. 2, and assign a CSM Impact Level. Note that generic information types, such as "maps," are not going to be defined in NOST 800-60 Vol. 2. You have to know how the information is being used in order to categorize it. For example, a web application might provide maps of inland waterways. The maps are for waterway navigation, therefore the information type is "Water Transportation."
As far as approvals go, there's two parts:
1) Registration through the DISA ECSB
2) Approval for your mission service from your approving authority. This concerns getting an ATO for the application.
Here's the main DISA ECSB page. From there, you can find the policy documents as well as the Cloud Service Request (CSR) form:  http://disa.mil/Services/DoD-Cloud-Broker.
As far as the approval process goes, currently this is done under DIACAP and will be transitioning to the Risk Management Framework (RMF). Be leery of references to DoDI 8510.01 regarding the C&A process, because that document was revised in March of 2014 and kept the same numbering but changed title to "Risk Management Framework (RMF) for DoD Information Technology (IT)" and now we use the term "Assessment and Authorization" or A&A instead of C&A. DIACAP uses the DoDI 8500.2 IA control catalog and RMF uses the NIST SP 800-53 control catalog. DIACAP is a 5-step process (Initiate and Plan IA C&A, Implement and Validate Assigned IA Controls, Make Certification Determination & Accreditation Decision, Maintain Authorization to Operate and Conduct Reviews, Decommission). RMF is a 6-step process (Categorize, Select Controls, Implement Controls, Assess Controls, Authorize, Monitor). Per the RMF, we should begin working on System Security Plans (SSP), Information System Contingency Plans (ISCP), and other governance documentation for our cloud services. NIST provides templates:  http://csrc.nist.gov/publications/nistpubs/800-18-Rev1/sp800-18-Rev1-final.pdf, http://csrc.nist.gov/publications/nistpubs/800-34-rev1/sp800-34-rev1_errata-Nov11-2010.pdf.
Physical versus Logical, Shared or Dedicated?
​IL 2 ​shared or dedicated infrastructure (on or off premise OK)
​IL 4 ​shared or dedicated infrastructure with strong evidence of virtual separation controls and monitoring. Ability to meet search and seizure requests of DoD Data. On or off premise OK.
​IL 5 ​Only dedicate infrastructure (on or off premise OK). Only DoD Private, DoD Community or Federal Government community clouds can be used. Each deployment can support multiple missions/tenants from each customer organization. Virtual or physical separation between DoD and Federal tenants/missions is permitted. Virtual or physical separation between DoD tenants or missions is permitted. Physical separation from non-DoD, non-Federal tenants is required.
​IL 6 ​Dedicated infrastructure approved for classified information. On or off premise OK provided NISPOM or DoD 8500.1 requirements met. Requires cleared personnel (CSP must have FCL at appropriate level). Each deployment may support multiple SECRET missions. Virtual or physical separation is required between DoD and Federal tenants. virtual or physical separation between DoD tenants/missions is permitted. Physical separation from non-DoD/non-Federal tenants is required.
Other considerations:
  • The cloud management/orchestration features need to be considered (e.g. two-factor authentication for administration of the virtual infrastructure, not just the VMs themselves)
  • e-discovery and law enforcement seizure issues need to be considered.
  • ITAR clouds do not necessarily meet the standards for dedicated clouds (e.g. AWS GovCloud). 
  • PKI requirements:
    • CAC or ECA must be used at IL 4/5.
    • NSS Token must be used at IL 6.
    • Cloud provisioning portal or multi-factor authentication must be PK enabled for IaaS/PaaS/SaaS at IL 4, 5, and NSS Token at IL 6.
All the above pertains to security. As far as deployment in the cloud goes, and in particular AWS, there's a lot of technical information to read concerning AMI instances (templates or base operating system sources), EC2 (Elastic Compute Cloud, which are the VMs), EBS (Elastic Block Store, space to run the VM), S3 (Simple Storage Service), Glacier (archival storage), VPC (Virtual Private Cloud), and other Amazon-specific, virtualization, networking, etc. concepts. Once deployed, and authorized, there's the requirement for continuous monitoring (step 6 of the RMF) and compliance with ongoing OMB, USCYBERCOM, ARCYBER, and other Federal or DoD policies.
The DISA Cloud Connection Process Guide (CCPG) is intended to assist DoD components with navigating the security requirements and onboarding processes for implementing commercial cloud services.

Other government cloud computing guidance:
Resources:
eMASS
  • AWS GovCloud (US) Impact Level 4 DoD PA was issued 26 October 2018 and expires 26 October 2019 and was signed by Mr. Roger Greenwell. POC for questions concerning the eMASS package is Mr. Charlie Griggs at DISA (charles.e.griggs2.civ@mail.mil). The eMASS package ID is 657.
  • ARL as a CSSP provides a spreadsheet which lists NIST SP 800-53 controls and CCIs they take responsibility for. Until/unless this information gets transferred into eMASS and the record can be inherited, recommend establishing manual inheritance. This will provide compliance with approximately 120 assessment procedures. 
CSP/CSO Resources:
News:
Vendors:
  • Autonomic Resources
  • AWS Services in Scope by Compliance Program. Lists the status (approved, not approved, undergoing assessment) of AWS services for the following compliance programs:  SOC, PCI, ISO, FedRAMP, DoD CC SRG, HIPAA BAA, IRAP, MTCS, C5, K-ISMS, ENS High, OSPAR, HITRUST CSF. For DoD CC SRG, environments are broken out by IL 2 (East/West), IL 2 (GovCloud), IL 4 (GovCloud), and IL 5 (GovCloud).
  • AWS Cloud Adoption Framework (CAF). Identity and Access Management, Detective Controls, Infrastructure Protection, Data Protection. and Incident Response. Assigns stakeholders to one of six perspectives:  Business, People, Governance, Platform, Security, Operations. Need to understand cloud adoption from the view of those stakeholders.
  • ​Amazon Web Services (AWS) East/West. Impact Level 2.
  • AWS GovCloud US. Impact Level 4 and 5
  • Carpathia
Press:

Posted by at
Labels: , , ,

No comments:

Post a Comment

Subscribe to: Post Comments (Atom)