Cloud Computing Concerns of the U.S. Government by Michael Erbschloe - HTML preview

PLEASE NOTE: This is an HTML preview only and some elements such as links or page numbers may be incorrect.
Download the book in PDF, ePub for a complete version.

6.1 Overview of CND Tiers

DoD operates a tiered CND Command and Control (C2) structure as defined in DODI O-8530.2, Support to Computer Network Defense (CND). The structure consists of USCYBERCOM at the top tier (Tier 1) and a network of CND Service Providers (CNDSPs) (Tier 2) that have been accredited by USCYBERCOM IAW DoD policy. Each DoD information system is operated/managed by a Mission Owner (Tier 3) which must be aligned with an accredited CNDSP which monitors and protects the information systems and associated assets. CNDSPs report information to USCYBERCOM which maintains Cyber Situational Awareness over all DoD networks and ISs. USCYBERCOM also provides threat information collected from various sources and threat mitigation orders to the CNDSPs and Mission Owners.

DoD is adjusting its CND C2 structure to include the Joint Force Head Quarters (JFHQ) – DoD Information Network (DoDIN). As the JFHQ moves into operation, certain responsibilities may shift from USCYBERCOM at Tier 1.

6.2 Concept Changes for Tiers for Cloud Computing

With the move to commercial cloud computing, the DoD is adopting a risk-based approach in applying network defense capabilities and processes. As described in section 3, DoD has defined Impact Levels commensurate to the risk and type of data, with each higher level warranting greater protections.

With Impact Level 2 data, the overall value of the data is not mission critical or sensitive in nature, thus it doesn’t warrant the same level of protections as higher impact level data. Recognizing that the data at Impact Level 2 has minimal requirements for confidentiality, emphasis must be placed on integrity and availability that achieve a level of security and risk acceptable to the responsible Authorizing Official (AO). User connectivity to the information system flows through the CSP’s Internet connection; thus DoD is relying on the network boundary protections and monitoring that the CSP provides for all customers versus capabilities normally provided by a DoD CNDSP. Protection capabilities supporting the mission system at the system/host/application level will be provided by a combination of the CNDSP and the mission system administrators (including the CSP for SaaS).

Level 4 and above data presents greater risk and thus necessitates the need for enterprise defense mechanisms and data collection that enable robust monitoring, event correlation, and analytics. With level 4 and above data, the DoDIN boundary is essentially extended through a connection between the DoD CAP and the CSP's network infrastructure supporting the DoD mission. Therefore, an event may be detected through a few different entities: the CSP through monitoring of their CSO (especially for SaaS); the mission administrators or owners; or the CNDSPs that are supporting the monitoring of the mission and the boundary connection. All entities must work together to quickly investigate and respond to incidents. This change requires new constructs within the CND C2 structure, including the identification of entities with new Tier 2 CND Command and Control (C2) and Operations (Ops) responsibilities. The use of a Cloud Access Point (CAP) drives the requirement for two distinct functions/roles: Boundary CND and Mission CND.

6.2.1 Boundary CND

Boundary CND (BCND) monitors and defends the connections to/from CSPs via an authorized CAP. BCND guards against the risk that each CSP interconnection poses to the DoDIN individually, along with cross-CSP analysis for all connections flowing through an individual CAP. While this function focuses on the connections through a particular CAP, cross-CAP analysis is warranted to determine if a threat extends beyond a single CSP or CAP.

All anomalies identified by a BCND will be forwarded to DISA for cross-CAP analysis activities. The DISA Command Center (DCC) and DISA NetOps Center (DNC) Continental US (CONUS) are assigned global CND C2 and Ops responsibility for protecting the DoDIN. This C2 construct addresses potential impacts across the multiple missions supported by a CSP, ensuring that Mission Owners and supporting MCNDs have access to global situational awareness.

6.2.2 Mission CND

Mission CND (MCND) provides services to a Mission Owner’s cloud-based mission systems/applications and virtual networks. Any given MCND may service cloud-based mission systems/applications and virtual networks instantiated in multiple CSPs and multiple CSOs. MCND is not a new Tier 2 entity; rather it is the integration of existing DoD CNDSPs with a focus on elements of cloud computing. The MCND will typically be the CNDSP used by the Mission Owner’s Command, Service, or Agency (CSA) for their non-cloud-based ISs; however, Mission Owners can choose to use any certified CNDSP for their MCND provider.

6.3 CND Roles and Responsibilities

The following is a list of the CND C2 functional elements and their responsibilities as it relates to cloud operations.

  • DoDIN CND: A Tier 1 function of the DCC and DNC CONUS focused on cross-DoDIN risk in DoD’s use of cloud computing and commercial CSPs.
  • Responsible for protecting the DoDIN and DoD mission systems in commercial cloud infrastructure through cross-CAP correlation and analysis of events/data.
  • Directs C2 actions regarding DoDIN-wide incident and system health reporting involving a CAP or CSP.
  • For DoDIN-wide incidents, establish and maintain external communications with the CSP and ensure internal DoD communications are established between all entities which include the MCND and BCND.
  • Interfaces with US-CERT to obtain relevant CSP information; ensures cross-sharing of information across all BCND/MCND entities.
  • Boundary CND (BCND): A Tier 1 and Tier 2 function of a certified CND provider responsible for the management and monitoring of a CAP.
  • Responsible for protecting the DoDIN and DoD mission systems in commercial cloud infrastructure connected via the CAP.
  • Coordinates communications between USCYBERCOM and MCNDs.
  • Responsible for monitoring CSP adherence to incident response processes and advising the CSPs via the respective MCND on protecting their infrastructure and the DoD mission systems that they host.
  • Mission CND (MCND): Tier 2 responsibilities integrated in the existing DoD CNDSPs focused on cloud computing. At a minimum, the MCND is responsible for:
  • Monitoring, protecting, and defending the Mission Owner’s cloud-based systems, applications, and virtual networks in the CSP’s IaaS/PaaS infrastructure.
  • Ensuring internal DoD communications are established between all entities which include the Mission Owner, MCND, and BCND.
  • Providing information on CSPs and missions being supported and the supporting BCND to DoDIN CND and the JFHQ DoDIN for situational awareness.
  • Mission Administrators: Administrators of Mission Owner’s cloud-based systems, applications, and virtual networks; at a minimum, a Tier 3 entity consuming CNDSP services is responsible for:
  • Following Tier 1 and Tier 2 direction (C2).
  • Maintaining and patching the cloud-based mission systems, applications, and virtual networks.
  • Installing and maintaining protective measures for the cloud-based mission systems, applications, and virtual networks.
  • The CSP: CSPs provide for their own CND services to provide for a secure environment for Mission Owner's systems, applications, and virtual networks. CSPs will effectively function as an extension of the DoD CND Tier 3 entity (i.e., the Mission Owner) toward this end. At a minimum, CSPs are responsible for:
  • Providing local operational direction and support for CND within their infrastructure and service offerings.
  • Fully maintaining, patching, monitoring, and protecting the infrastructure, operating systems, and applications supporting all service offerings.
  • Fully maintaining, patching, monitoring, and protecting SaaS service offering OSs and applications including DoD data/information in them.
  • And as contracted:
  • Coordinating with the MCND regarding incident response and the mitigation of threats to DoD cloud based mission systems/applications and data.
  • Providing timely incident and system health reports.
  • Maintaining bidirectional Cyber Situational Awareness.
  • Mission Owners: Individuals/organizations responsible for the overall mission environment, ensuring that the functional and CND requirements of the system are being met. At a minimum, Mission Owners are responsible for:
  • Engaging and funding the services of a MCND to provide for the defense of the Mission Owner’s systems, applications, and virtual networks in any CSP’s IaaS/PaaS infrastructure (whether DoD operated or operated by a commercial/non-DoD entity).
  • Establishing the terms and requirements in the contract with the CSP for incident reporting, incident response, and communications with the appropriate MCND and BCND providers.

Figure 8 provides a graphic representation of these entities and the flow of communications between them.

Figure 8 - DoD Cloud Incident Response and CND C2 Structure

Figure 8 - DoD Cloud Incident Response and CND C2 Structure

6.4 Incident Reporting and Response

FedRAMP, through the selection and implementation of IR-6, requires CSPs to report incidents to the Department of Homeland Security (DHS) United States Computer Emergency Readiness Team (US-CERT) and the consuming Federal Agencies. For CSOs that are multi-tenant or otherwise shared across Federal Agencies outside of the DoD (Impact Levels 2 through 5), incidents will be reported to US-CERT as required by FedRAMP, in parallel with reporting to DoD. For CSPs providing dedicated infrastructure to the DoD (Impact Levels 4 and above), incidents regarding that infrastructure and CSOs will not be reported to US-CERT, but directly to the DoD. The DoD Tier 1 (USCYBERCOM/JFHQ DoDIN) will handle coordination with US-CERT and other entities as appropriate.

All CSPs actively supporting DoD missions will be supported by a MCND. The MCND will be the DoD point of contact to whom the CSP's Operational entity will report and coordinate response to incidents affecting the security posture of the CSP and the CSP's cloud service offerings. The MCND will coordinate with the higher tiered BCND as appropriate.

6.4.1 Incident Response Plans and Addendums

CSPs will provide, either as part of their Incident Response Plan or through an Incident Response Plan Addendum, their approach to fulfilling integration requirements. CSPs will make their plan or addendum available to DISA for review and approval as a condition of its PA and inclusion in the DoD Cloud Service Catalog. CSPs will update and deliver the Incident Response Plan Addendum (if used) in conjunction with updates and deliveries of their Incident Response Plan, as required by the FedRAMP selected security control IR-1. A CSP must specifically address data breaches, where a “breach” includes the loss of control, compromise, unauthorized acquisition, unauthorized access, or any similar term referring to situations where any unauthorized person has access or potential access to government data, whether in electronic or non-electronic form, for any unauthorized purpose. CSPs must ensure that the plan or addendum addresses all breaches regardless of the time, day, or location of the breach and must provide for notice to the Government of any breach of its data. The plan or addendum must incorporate any other policies or procedures that the Government may require to be followed in the event of a breach, including, but not limited to:

  • How and to whom within the Government, the breach will be reported;
  • Specific steps to be taken in order to mitigate or remedy the breach, including time periods for taking such steps (e.g., reporting of Personally Identifiable Information (PII) data breaches within one hour, Negligent Disclosure of Classified Information (NDCIs) which are commonly referred to as spillages);
  • How and under what circumstances any individuals or entities affected by a breach will be notified and by whom; and
  • Any other special instructions for handling computer security incidents affecting, or potentially affecting U.S. Government data; consistent with guidance and policy directives issued by DoD, NIST, US-CERT and CNSS for incident management, classification, and remediation; or other applicable law, regulation, order, or policy.

6.4.2 Information Requirements, Categories, Timelines, and Formats

Defending DoD missions and systems is a shared responsibility that requires all entities (CSPs; CND entities (MCND, BCND); Mission Owners and Mission Administrators) to work collectively as a team. An event may be detected by any of following entities, depending upon the connection architecture (direct Internet or through a CAP):

  • CSP personnel through monitoring of their CSO (especially for SaaS);
  • Mission administrators or owners (includes the CSP for PaaS/SaaS);
  • Supporting MCNDs through their monitoring;
  • Supporting BCNDs via the CAP monitoring.

All entities must work together to quickly investigate and respond to events and incidents. In the course of a CSP performing CND for its environments, CSPs will monitor their information systems and report relevant information to the MCND, focused on situations where any unauthorized person has access or potential access to government data.

CSP’s reporting requirements to DoD will align with the reporting lexicon used by US CERT for the broader Federal Government reporting requirements. Incident notifications should include a description of the incident and as much of the following information as possible:

  • Contract information to include contract number, USG Contracting Officer(s) contact information, contract clearance level, etc.
  • Contact information for the impacted and reporting organizations as well as the MCND.
  • Details describing any vulnerabilities involved (i.e., Common Vulnerabilities and Exposures (CVE) identifiers)
  • Date/Time of occurrence, including time zone
  • Date/Time of detection and identification, including time zone
  • Related indicators (e.g. hostnames, domain names, network traffic characteristics, registry keys, X.509 certificates, MD5 file signatures)
  • Threat vectors, if known (see Threat Vector Taxonomy and Cause Analysis flowchart within the US-CERT Federal Incident Notification Guidelines)
  • Prioritization factors (i.e. functional impact, information impact, and recoverability as defined flowchart within the US-CERT Federal Incident Notification Guidelines) (https://www.us-cert.gov/sites/default/files/publications/Federal_Incident_Notification_Guidelines.pdf)
  • Source and Destination Internet Protocol (IP) address, port, and protocol
  • Operating System(s) affected
  • Mitigating factors (e.g. full disk encryption or two-factor authentication)
  • Mitigation actions taken, if applicable
  • System Function(s) (e.g. web server, domain controller, or workstation)
  • Physical system location(s) (e.g. Washington DC, Los Angeles, CA)
  • Sources, methods, or tools used to identify the incident (e.g. Intrusion Detection System or audit log analysis)
  • Any additional information relevant to the incident and not included above.

Initial incident reports should be submitted within one hour of discovery with follow-on information provided as available. Initial reports may be incomplete to facilitate communication and teamwork between the CSP and the supporting MCND/BCND entities. CSPs should balance the necessity of timely reporting (incomplete reports with critical information) versus complete reports (those with all blocks completed). Timely reporting is vital, and complete information should follow as details emerge.

NOTE: These requirements are applicable to all systems at all Information Impact Levels. The CSP must follow these requirements when integrating with the DoD Command and Control (C2) and Network Operations (NetOps) structure. Mission Owners must include these requirements in the contract, even at Level 2.

6.4.3 Incident Reporting Mechanism

DoD CSP's CND providers will report all incidents IAW normal DoD processes using the Joint Incident Management System (JIMS).

Commercial CSPs will report all incidents via the on-line Defense Industrial Base (DIB) Cyber Incident Collection Form (ICF). Use of the on-line form is preferred. Access to this form requires a DoD-approved medium assurance External Certificate Authority (ECA) certificate. If you are unable to access this form, please call (877) 838-2174 or email: DCISE@DC3.mil.

The CSP must include, for routing purposes, all MCND points of contact (POCs) for all DoD missions affected by the incident. This is in addition to any other POCs required by the tool for routing to contract managers, etc. The MCND, once the report is received, will initiate the DoD reporting process via JIMS.

Note: The Incident Collection Form (ICF) requires modification in order to be fully aligned with the above reporting requirements. In the interim the current form will be used. CSPs should complete the fields as appropriate.

When classified incident reporting is appropriate and directed, CSPs will use SIPRNet email or secure phone/fax to report and coordinate incidents as specified. This will always be the case for Level 6 reporting.

Existing notification mechanisms of a CSP that are already in place to communicate between the CSP and its customers for some or all classes of CND information may be used, as long as those mechanisms demonstrate a level of assurance, equivalent to the listed encrypted mechanisms, for the confidentiality and integrity of the information.