NIST 800-63: Securing the Cloud by Securing Digital Identity Lifecycles

Digital business models increase consumer/citizen engagement but come at a cybersecurity cost. Cloud Smart mandates increasingly require agencies to migrate their workloads and business critical operations to the cloud. However, creating identity and managing access often act as barriers because the complex, interconnected ecosystem diminish visibility into how and why users access information. To maintain compliance with NIST 800-63 and NIST 800-53, US agencies need to find a way to create, control and mitigate the risks associated with identity governance and administration while also maintaining compliance with the Shared Responsibility Model.

What is NIST Special Publication 800-63?

NIST 800-63, published in 2017, updated the Digital Identity Guidelines and provided technical requirements for federal agencies implementing digital identity services. The update noted, “the market for identity services is componentized, allowing organizations and agencies to employ standards-based, pluggable identity solutions based on mission need.” Despite this admission, federal agencies still struggle with these individual solutions since many do not connect across the entire data ecosystem, often creating Segregation-of-Duties (SOD) violations or leaving the agency non-compliant.

What is a digital identity?

The inherent irony of NIST SP 800-63 lies in its own admission that no clear definition of digital identity exists. For the purposes of NIST, however, the publication defines digital identity as “the unique representation of a subject engaged in an online transaction.”

To create the guidelines, NIST drills down further to explain that federal agencies need to manage risk in federated and non-federated systems based on the following categories:

  • Identity Assurance Level (IAL) Identity proofing process
  • Authenticator Assurance Level (AAL): Authentication process
  • Federated Assurance Level (FAL): Strength of assertion in a federated environment

Organizations using non-federated environments need the first two components, IAL and AAL. Agencies using federated systems need to add FAL as well, the details of which are described in NIST SP 800-63c.

Within each category, NIST 800-63 defines three risk mitigation levels based on the agency’s risk analysis.

  • Level 1: Low risk
  • Level 2: Moderate risk
  • Level 3: High risk

The higher the risk level, the more assurance that the agency needs to provide over its identity and access management (IAM) and identity governance and administration (IGA) programs.

How Does the Digital Identity Model Work?

The core of the digital identity model lies in four basic steps:

  1. User application through enrollment
  2. Cloud Services Provider (CSP) identity proofs the application and creates a subscriber
  3. CSP and subscriber create authenticators and credentials
  4. CSP engages in lifecycle management

These four simple-sounding steps, however, belie the complexity. NIST’s diagram provides more clarity:

Digital Identity Model

Federation eases many of the burdens associated with enrollment and identity proofing which is why NIST SP 800-63 suggests it as a “best practice” compared to traditional siloed identity systems.

Thus, agencies and other organizations adopting a NIST framework often choose a single-sign on because it enhances user experience, reduces cost, minimizes data, allows for a minimized set of attributes, and enables agency missions.

How To Review Risk

NIST 800-63 provides two detailed risk decision trees for determining IAL and AAL risk and defines six impact categories:

  1. Inconvenience, distress, or damage to standing or reputation
  2. Financial loss or agency liability
  3. Harm to agency programs or public interest
  4. Unauthorized release of sensitive information
  5. Personal safety
  6. Civil or criminal violations

If one of these categories, the entire IAL and AAL fall under the “high risk” rating. If personal safety is considered moderate, the IAL and AAL is also assessed as “high risk.”

When to Use Federation

Although NIST 800-63 doesn’t specify federation as the best option, the guidance does trend towards it as a best practice. Moreover, NIST 800-63b goes into depth on authentication and lifecycle management.

The six scenarios in which NIST suggests authenticator federation are:
  1. Users already have an authenticator at or above their required AAL
  2. Full user community covers requires multiple credential form factors
  3. Agency lacks infrastructure for authentication management
  4. Adding and upgrading primary authenticators may be necessary in the future
  5. Different environments need support
  6. Users come from multiple communities with individual identity infrastructures
The five scenarios in which NIST suggests attribute federation are:
  1. Users or the service require pseudonymity
  2. Service access only requires a partial attribute list
  3. Service access only requires at least one attribute reference
  4. Required attributes issued from somewhere other than the agency
  5. Agency does not need to retain the data long term

As agencies and organizations embrace cloud migration, federation becomes a more appealing IAM choice. While NIST 800-63 focuses on how to create and authorize identities, it ignores how to manage them and prove governance once an organization grants access to data. Federation allows agencies and organizations to control access to their data assets, but governance requires continuously monitoring to ensure that the organization maintains compliance with its policies within the data assets. As such, agencies need to begin with federated IAM strategies and supplement those with additional safeguards.

How to Prove Governance Over Digital Identities

Digital identities include human and digital identities, which makes governance difficult across the ecosystem. Unique human accounts within a federated environment can be accessed and authenticated using traditional federation technologies such as single-sign on with multi-factor authentication. However, people are dynamic meaning their access rights must change to meet their needs. Additionally, adding Software-as-a-Service (SaaS) applications to Infrastructure-as-a-Service (IaaS) environments further complicates access control management processes.

Verify and Identity Proof: SSO

Creating a digital identity requires creating a user and verifying the identity at the enterprise level. The end user registers for the account using the SSO, which then verifies the identity and attributes to create the user. At this point, the user has a unique name and ID that connects with the multifactor authentication method allowing them to into the ecosystem.

Assign Roles and Groups: IAM

User access policies define the roles that can interact with information. To secure the individual users, they need defined attributes that connect to roles within the ecosystem. For example, a role can be viewer, operator, editor, or administrator. Each role can perform different actions within the environment.

Next, the roles need to be placed into groups. For example, groups can be aligned with resources or services. For example, a viewer cannot make changes to the information contained in the environment. Meanwhile, an editor may be able to make changes to information but not to visibility. In some cases roles overlap, particularly as users need access to different applications within the cloud ecosystem. This means that a user can be a viewer for documents but an editor over their account information. In that case, they might be placed in a group “Customer.”

Dynamic Identity Proofing: IGA

People are dynamic. Whether workforce or citizen, people move within the agency or to other agencies. Thus, identity proofing also requires more than a one-time enrollment.  As workforce members and citizens move throughout the agency, their needs change which also means that they may require additional access. The provisioning/deprovisioning process requires identity proofing, despite already being enrolled in the ecosystem.

Continuous Monitoring: IGA and Cloud Privileged Access Management (PAM)

Privileged access to cloud resources muddies the identity proofing process. Once inside the ecosystem, users continuously request more access as the agency adds more resources. For example, traditional methods of governing access to data focus on creating roles that align with the SSO solution to grant access to the application. Unfortunately, while users can obtain a single username and password, the access becomes all encompassing which can diminish “least privilege necessary” controls. In terms of PAM, this creates an even greater risk of internal access misuse. Thus, agencies or organizations choosing to use NIST 800-63 and 800-53 need continuous insight into how users access data. To do this, they need detailed entitlement monitoring that goes beyond application access and delves into the file level. A single user – privileged or not – with access to files they do not need can lead to unauthorized use and data leakage.

Saviynt: FedRAMP Moderate Authority-to-Operate (ATO) Compliance-as-a-Service

Saviynt, the first and only IGA/Cloud PAM solution with FedRAMP Moderate ATO, creates a Cloud Smart option for agencies and other FedRAMP compliant organizations.

As part of the Shared Responsibility Model, agencies need to ensure that they maintain governance over access to their data and cloud solutions. Saviynt’s security posture in conjunction with its intelligent analytics accelerate cloud migration strategies and cloud security programs.

Access assignment in IaaS platforms is static, yet IAM roles/policies align with the dynamic nature of users. As such, removal of access using legacy solutions can lead to possible data breaches, infiltration, and leakages. Saviynt supports multi-tenant and multi-application access governance and privileged access management to maintain compliance with internal controls and prevent segregation of duties violations.

As a cloud-native solution, the Saviynt platform provides identity lifecycle management across all users – including DevOps – to ensure that agencies and enterprises control access to applications, environments, and ecosystems.

With our peer-to-peer analytics, federal agencies and businesses can ease the provisioning/deprovisioning process, automating requests as well as providing suggestions to mitigate potential security violations.

For more information or to schedule a demo, contact Saviynt today and ease the burdens associated with Cloud Smart mandates.

Karen Walsh

About author

Organic content marketing manager with 12 years experience in education and compliance. Using this experience, she focuses on bridging the gap between CISOs and the CSuite by educating through content to enable organizations to strengthen their cybersecurity posture.

Comments are closed here.