The U.S. Department of Defense (DoD) mission is to provide the military forces needed to deter war and ensure our nation's security, and with that comes the challenge of protecting associated information systems. In the last two decades, cloud computing emerged as a technology with tremendous potential, and the DoD has embraced its possibilities. At the same time, cloud computing raises important questions:
In 2018, the DoD released a framework called the Secure Cloud Computing Architecture (SCCA). Building on existing DoD constructs such as NIPRNet (Non-Secure Internet Protocol Router Network) and Information Impact Levels (IL2, IL4, IL5, IL6), “the SCCA is designed to meet the boundary protection needs of the Defense Information Systems Network (DISN) by protecting the DISN from cyberattacks originating from within the Cloud Service Provider’s Cloud Service Environment (CSE).” Use the information on this page as guidance—complementing the DoD documents—for achieving SCCA goals.
To understand the need for SCCA, it helps to understand what came before SCCA.
Information Impact Levels:
In 2015, the Defense Information Systems Agency (DISA) noted that information comes in different impact levels (IL), and that information systems need to be rated according to the level of information protection they provided. The DoD identified these information impact levels:
As a result, each cloud service provider (CSP) supporting the DoD must go through an accreditation process for each cloud region to determine its IL level. As an example, the following Oracle Cloud regions have IL4/5 accreditation:
Oracle Cloud Region |
Information Impact Level |
Connects to BCAP |
---|---|---|
U.S. DoD East (Ashburn, VA) | IL4/IL5 | Yes |
U.S. DoD North (Chicago, IL) | IL4/IL5 | Yes |
U.S. DoD West (Phoenix, AZ) | IL4/IL5 | Yes |
U.S. Gov East (Ashburn, VA) | IL4 | No |
U.S. Gov West (Phoenix, AZ) | IL4 | No |
Cloud Computing–Security Requirements Guide:
The IL levels listed above were part of a broader document called the “Cloud Computing – Security Requirements Guide” (CC SRG). The Defense Information Systems Agency (DISA) created this document in 2015 to provide detailed requirements on what a commercial cloud region needed to provide adequate protection of DoD information. This document included sections on:
Networks–NIPRNet, SIPRNet:
In today’s interconnected world, the network itself is both a vital asset and a potential threat vector. The DoD, working alongside the Intelligence Community (IC), uses two networks below that are “fit for purpose” for specific workload categories:
Government Network |
Purpose |
---|---|
NIPRNet | Unclassified information |
SIPRNet | Classified information, up to and including Secret |
Each of these prior security constructs was successful and provided guidance to industry partners on how to offer solutions that meet DoD needs. By 2017, the DoD saw new emerging needs that motivated the creation of an additional framework: SCCA.
In 2017, the DoD released a new document called the “Secure Cloud Computing Architecture – Functional Requirements Document” (FRD) (PDF).
Building on—and not replacing—the prior CC SRG, the Functional Requirements Document describes these DoD goals:
Maximize the use of commercial cloud computing
The DoD recognized that commercial cloud computing—with cutting-edge technologies in artificial intelligence, machine learning, and autonomous operations—had the potential to accelerate the DoD’s own adoption of these capabilities.
Optimize cost-performance trade in cyber security
Commercial clouds operate on a massive global scale, and this scale offers significant cost savings to the DoD. The challenge, as the FRD articulates, was finding a way to achieve these cost savings without sacrificing security.
Protect the DoD shared networks
The Defense Information System Network (DISN) and DoD Information Network (DoDIN) are vital shared assets that support thousands of DoD workloads. The FRD noted that it was vital to protect DISN and DoDIN networks from any attacks that may originate externally from commercial clouds.
Protect mission-owner workloads
As DoD mission owners deploy their workloads onto various commercial clouds, the FRD noted the importance of defining and enforcing standards to protect the security of those workloads.
If your organization is considering a SCCA, an important question to ask is, “What role will we play?”
The SCCA FRD identifies three primary SCCA roles:
SCCA Role |
Description |
---|---|
Mission owner (MO) | A DoD entity responsible for delivering and operating a DoD mission system. MOs are responsible for the procurement, deployment, and secure operations of mission systems deployed to the cloud environment. Accordingly, MOs are expected to maintain trusted configuration baselines and to perform continuous monitoring for deployed mission systems. |
Mission cyberspace protection (MCP) | The DoD entity charged with the responsibility of securing a MO’s enclave and networked systems by establishing and delivering cybersecurity capabilities. The MCP is specifically responsible for cyber defense of MO systems. |
DISN boundary cyberspace protection (BCP) | The DoD entity charged with the responsibility to establish and deliver cybersecurity capabilities to protect the DISN. This entity will be DISA. |
For your organization, questions to ask include:
Each of these prior security constructs was successful and provided guidance to industry partners on how to offer solutions that meet DoD needs. By 2017, the DoD saw new emerging needs that motivated the creation of an additional framework: SCCA.
SCCA includes four primary technical components, described below:
SCCA Component |
Description |
---|---|
Cloud access point (CAP) |
Connects the DISN or NIPRNet to a commercial cloud. There are three variants of a CAP:
Major functions:
|
Virtual data center security stack (VDSS) |
Serves as the virtual security enclave protecting applications and data hosted in commercial environments. Core services:
|
Virtual data center management Service (VDMS) |
Provides the security systems that manage the security posture of the mission owner enclave. Enable mission owners to:
|
Trusted cloud credential manager (TCCM) |
Controls and monitors privileged user access for cloud environments. The TCCM owns and maintains the cloud credential management plan (CCMP). In contrast to CAP, VDSS, and VDMS, the TCCM is a person (or role) and associated processes and procedures. Responsibilities:
|
As the Functional Requirements Document mentions, “The SCCA is broken into four technical components to allow flexible implementation and DoD IT organization ownership.”
Department of Defense:
The Department of Defense box on the left represents the DoD Meet-Me Point(s), DoD Boundary Cloud Access Points (BCAPs), DoD Cyber Security Service Providers (CSSPs), and other entities running under DoD control and serving as the interface between the DoD Network (left side) and commercial cloud (right side).
VDSS:
On the right side, Subnet A represents the VDSS, along with load balancer and next-generation firewall virtual appliances. (Web application firewall functionality can be a feature subset of the load balancer or firewall.) This protects the mission owner assets within the cloud environment.
VDMS:
On the right side, Subnet B represents the VDMS and its component services. Per SCCA flexibility, these may be either cloud-native services or third-party solutions running atop the CSP’s IaaS infrastructure.
Mission owner enclaves:
Toward the bottom are two boxed areas labelled “IaaS Workloads.” These represent two separate workloads—either from different MOs, or from the same MO but covering different capabilities. SCCA allows there to be as many MO enclaves as necessary; the two in Figure 1 are meant to represent “one or more.” Finally, note there are no SCCA components directly within these MO enclaves since the VDSS and VDMS appear in the upper half of the diagram.
Building on DISA’s foundational guidance, the next logical question might be, “How can my organization implement an SCCA-compliant solution using the Oracle Cloud?”
Customers can implement SCCA in three primary ways:
Build your own
Oracle has technical briefs and architectural guidance based on what other customers have done. Click below for access to this material.
Share an existing SCCA environment
Other DoD agencies have already shared their existing SCCA environments in the past, and this can be a quick, low-cost option for you to get started, based on your workload.
Broker-provided
Some organization serve as an "SCCA Broker", providing an existing solution to DoD agencies for a fee. Cloud One, sponsored by the US Air Force, is one such broker. Following this path can be a very easy and quick way to meet your SCCA compliance requirements.
Contact your Oracle team to discuss these options, and which is best for you.