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 No comments:
Labels: , , ,

Wednesday, July 10, 2019

Interim Authority to Test (IATT) Process for the Army

The US Army Network Enterprise Technology Command (NETCOM) IATT process is described here:  https://army.deps.mil/NETCOM/sites/RMF/csdwiki/iattfaq.aspx

Highlights:

  • An IATT is used to permit testing of a system in an operational environment with live data.
  • All applicable security controls should be tested and satisfied before testing in an operational environment or with live data except for those that can only be tested in an operational environment.
  • The Army has implemented a security controls overlay to streamline the IATT assessment process. The IATT overlay is designed to reduce the amount of time and resources necessary to assess the security state of the system under test. The AO will determine if use of the IATT Overlay is acceptable or unacceptable.
  • RMF Steps 1 and 2 (categorization and selection) must be completed prior to initiating the IATT process.
  • Documentation must be uploaded to eMASS to reflect the initial/test design. The final design may be different (and thus the revised design will be assessed if an ATO is pursued).
    • System details section of eMASS must be accurately completed.
    • Hardware list
    • Software list
    • Authorization boundary diagram
    • Data flow diagram (depict how specific data types are transmitted in/out/within the accreditation boundary). This should probably include CAL boundaries as well as ports and protocols.
    • System Enterprise and Information Security Architecture that describes how the system is/ will be integrated into the enterprise architecture and information security architecture. This should include enterprise services such as Defense Enterprise Email (DEE) as well as services to be provided by the Cybersecurity Security Service Provider (CSSP).
    • Other documentation:  rack diagrams, connection diagrams, physical blueprints, process flow diagrams, build guides, or operational guides which fully describe the system and its configuration to an unfamiliar reviewer. These documents may be bundled together in a Functional Architecture.
  • A documented test plan must be provided, which includes a test timeline, test purpose, and test scope (locations, networks, connectivity). References include Test and Evaluation Master Plan at DAU and Operational Test and Evaluation (TEMP) Guidebook. Our best business practice is to include a Word document which describes the test purpose, scope, and tests to be performed along with a Microsoft Project file which more clearly defines the test timeline and phases if applicable.
  • Third party assessment performed by a SCA-V is not required (but can be done if desired).
  • All STIGs (and SRGs) must be applied, assessed, and reviewed. The ISO may follow the sample rate guidance documented in Appendix C of the Security Control Assessor - Validator (SCA-V) Tactics, Techniques, and Procedures (TTP) to keep the STIG review files to a manageable number. Full STIG checklists must be utilized, not just the benchmarks. STIG and SRG assessment results (.ckl) must be provided in the eMASS record.
  • The hardware and software vulnerabilities must be assessed and remediated or mitigated after performing a vulnerability scan (ACAS). A copy of the vulnerability scan must be provided in the eMASS record.
  • The STIG and vulnerability analysis must identify and describe:
    • False positives, false negatives
    • Vulnerabilities that cannot be remediated due to operational requirements/technical limitations.
    • Vulnerabilities that cannot be remediated due to limitations of the testing environment, test configuration of the system, or testing schedule.
    • Specific mitigations in place for vulnerabilities.
    • Security controls that have ongoing vulnerabilities mapped to them that have been tailored by the IATT overlay.
  • If STIG or ACAS scan results import vulnerabilities that do not map to controls (e.g. controls were remove by the IATT overlay), the ISO must manually add these controls (e.g. tailor).
  • The ISO performs a self-assessment and provide appropriate test results for each CCI within each control.
  • The ISO must complete the Risk Assessment within the eMASS record by completing the Risk Assessment tab for all non-compliant security controls. eMASS will automatically filter the Risk Assessment tab for controls marked non-compliant. Information on completing the Risk Assessment can be found on the RMF Knowledge Service (RMFKS): https://rmfks.osd.mil/rmf/RMFImplementation/AssessControls/Pages/ResidualRisk.aspx
  • The ISO must create a POA&M item in eMASS for all ongoing vulnerabilities (including any that cannot be remediated) as well as vulnerabilities present in the STIG/SRG and ACAS scans that cannot be remediated.
    • Vulnerabilities that will be remediated at a later time must include at least one milestone documenting the steps needed for remediation and will be marked as "Ongoing"
    • Vulnerabilities that cannot be remediated must have a valid justification and must be marked as "Risk Accepted". When the AO completes the authorization decision, all Risk Accepted POA&M items will be marked as "Approved"
    • Vulnerabilities present in the scans that have since been remediated must include a reference to evidence tht hat vulnerability is address (evidence must be uploaded as an artifact) and must be marked as "Completed."
  • When the self-assessment is completed, the ISO initiates an Assess and Authorize (A&A) Package Approval Chain (PAC). Scans must be no older than 30 calendar days. The statements below must be included as a comment in the submission:  
    • "Seeking an IATT for the dates [dates in the test plan]."  The ISO may include additional detail about the dates as necessary (for example if the IATT will cover multiple connection periods).
    • (If the IATT overlay is used) "The Authorizing Official [or Authorizing Official Designated Representative, whichever is accurate] has approved the use of the IATT overlay [describe approval method]."  The intent of this statement is to guide reviewers to the document, package history, or other evidence recording the AO / AODR's approval of the IATT overlay.
  • Once the IATT is approved, the ISO must remove the IATT overlay if it has been applied. This will re-add security controls removed by the IATT overlay so that they can be assessed. Security controls that remain in the baseline when the IATT is removed will return to the baseline as Not Applicable. The ISO just add new test results for these controls to mark the Compliant or Not Compliant.
Posted by at No comments:
Subscribe to: Posts (Atom)