What is Secure Cloud Computing Architecture (SCCA)?

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:

• How to reduce operating costs by leveraging cloud economies of scale?
• How to protect DoD’s centralized networks?
• How to protect DoD’s decentralized mission-owner workloads?
• How to share security responsibilities among government and commercial organizations?
• How to leverage unique solutions from each partner without sacrificing interoperability?
• How to enforce security standards in a multi-cloud ecosystem?

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.

A brief history—before SCCA

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:

• IL 1: Unclassified information approved for public release
• IL 2: Noncontrolled unclassified information
• IL 4: Controlled unclassified information
• IL 5: Controlled unclassified Information–Mission Critical, National Security Systems
• IL 6: Classified information up to Secret

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:

• Information system objectives/impact levels
• Risk assessment of cloud service offerings
• Security requirements
• Cyberspace defense and incident response
• Roles and responsibilities

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.

Business drivers for 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.

SCCA roles and responsibilities

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:

• Roles: “Which role(s) does my organization want to play?”
• Responsibilities: “What will our responsibilities be?”
• CSP enablement: “How do each CSP’s offerings improve my ability to perform these responsibilities?”

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.

Technical components of 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: Boundary CAP (BCAP) Internet CAP (ICAP) Component CAP (CCAP) Major functions: Cloud connectivity: Provide mission partners with dedicated connectivity to approved Level 4 and Level 5 commercial cloud providers. DISN protection: Protect the DISN from any attack that originates from the cloud environment.
Virtual data center security stack (VDSS)	Serves as the virtual security enclave protecting applications and data hosted in commercial environments. Core services: Web application firewall (network traffic inspection) Next-generation firewall (intrusion prevention, intrusion detection)
Virtual data center management Service (VDMS)	Provides the security systems that manage the security posture of the mission owner enclave. Enable mission owners to: Configure and deliver security policies Push upgrades Manage roles and security policies
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: Establish plans, polices, and procedures to securely manage CSP provided customer portal account access credentials and privileges Enforce least privilege access for privileged accounts that are established and managed using the CSP’s IdAM system

SCCA reference architecture

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.

• Bastion (“jump box”)
• Identity and access management (IAM)
• Assured compliance assessment solution (ACAS)
• Host-based security system (HBSS)
• Security information and event management (SIEM)
• Patch management
• Core services

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.

Deployment options for SCCA compliance

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.