How an IL4 Identity Provider Successfully Services IL5 Environments

By embracing the cloud and new standards, the Department of Defense (DoD) can advance its information systems and guide the modernization of cybersecurity as required in Pillar 1 of National Cybersecurity Strategy, Section 3 of Executive Order (EO) 14028, Improving the Nation’s Cybersecurity, and Section 1 of National Security Memorandum on Improving the Cybersecurity of National Security, Department of Defense, and Intelligence Community Systems (NSM8). 

But the Department’s goal of a modern, threat-informed infrastructure for the warfighter isn’t accomplished alone. The campaign to secure cloud services is a shared responsibility between DoD mission owners and Cloud Service Providers (CSPs). The Defense Information Systems Agency (DISA) Cloud Computing Security Requirements Guide (CC SRG) documents these guidelines and provides a framework for implementing commercially available cloud computing.

Impact Levels (IL) form the base construct of this framework. Each IL aligns to a specific level of information sensitivity and risk and to a subset of the Committee on National Security Systems Instruction (CNSSI) No. 1253 Security Controls. These ILs also dictate connectivity requirements, some of which include Cloud Access Points (CAPs). CAPs provide a connection for cloud offerings to connect to the NIPRNet via a DISA or service security stack. DISA has created a Risk Management Framework (RMF) process for the assessment and authorization of Cloud Service Offerings (CSOs), specifically tailored for the DoD, and that exists in parallel to the Federal Risk and Authorization Management Program (FedRAMP).

Understanding what level a given CSO needs to operate at is simple. All you need is an understanding of the mission and data that it is processing. Here are some examples:
 

Okta’s DoD journey

Over the past year, Okta has worked diligently with DISA to extend our Identity-as-a-Service (IDaaS) offering to the DoD and its mission partners in an exclusive environment without pilot program approval restrictions. We have completed this effort, culminating in a new conditional Provisional Authorization (PA) for Okta for US Military. Part of this milestone is an acknowledgment from the DISA Authorizing Official (AO) of Okta’s IDaaS as an identity and access management service for IL5 environments.

How can an IL4 IDaaS be used for access management into an IL5 system? To answer that question, we need to go back to the controls and data.

Let’s start with the data. IDaaS is a cloud-based Identity and Access Management (IAM) platform that provides a central management point to access other systems and applications, but it does not “process” data in the traditional sense. What kind of data would you want to store in a user directory? One would be hard pressed to find a need to store National Security data, Sensitive Personal Identifiable Information (SPII) or Protected Health Information (PHI) as an account attribute. One of the tenets of the Zero Trust model is to assume that the adversary has already gained access to your environment. Placing protected information in an account would make the actor's job easier! If we take a look at IDaaS as an enabling function for an overall system (or family of systems), it's easy to see that we should avoid storing protected data in a directory. For example, if you need a unique identifier for personnel, consider using their Electronic Data Interchange Personnel Identifier (EDIPI) and not their Social Security Number (SSN).

The second factor is the controls inheritance model. IDaaS provides inheritable controls based on its functionality as part of an overall system architecture. The Okta System Security Plan (SSP) and inheritable controls become an invaluable reference for anyone designing an inheritance model. Since IDaaS doesn’t store any CUI data, the bulk of the additional controls under IL5 must be leveraged against the systems that store the CUI data. Okta can assist in meeting these additional requirements as part of a hybrid approach. With that in mind, only those controls that Okta directly impacts are marked as inheritable. For example, Okta provides FIPS 140-2 encryption to the data stored within itself, but not the data in your warfighting maintenance system.

The final factor is Okta’s additional investments in hosting the environment on a .mil domain and restricting its use to only DoD-approved entities, an important step in our ongoing commitment to the DoD. These architectural components (data, controls, and exclusivity) are the logical factors that allowed DISA to grant Okta for US Military a conditional PA at IL4 and allow the use of IDaaS to support IL5 environments. This unique situation exemplifies Okta’s future as a leader in DoD cloud migration and Zero Trust efforts.

To learn more about this effort and the IL5 applications we integrate with, download our whitepaper on Deploying Modern Identity for National Security or contact us at federal@okta.com.