Digital Identity Risk Assessment Playbook

Acknowledgments

This playbook reflects the contributions of the Digital Identity Risk Assessment working group of the Identity, Credential, and Access Management Subcommittee (ICAMSC). The working group was co-chaired by members from the Internal Revenue Service (IRS) and the Environmental Protection Agency (EPA). Contributions were made by the members of services or agencies representing the Center of Medicare and Medicaid Services (CMS), Department of Defense (DOD), Department of Health and Human Services (HHS), Department of Homeland Security (DHS), Department of Justice (DOJ), Department of the Treasury (USDT), Department of Transportation (DOT), and General Services Administration (GSA).

Introduction

Digital identity represents each individual engaged in an online transaction. However, an individual’s real-life identity may not be known when used to access a digital service.¹ Identity proofing helps establish that the individual is who they claim to be. Digital authentication provides reasonable risk-based assurances that the individual accessing the application is the same individual who previously accessed the service. This playbook is a method to apply the National Institute of Standards and Technology (NIST) Special Publication 800-63-3 Digital Identity Guidelines. Federal agencies can perform a Digital Identity Risk Assessment (DIRA) to determine the appropriate identity, authenticator, or federation level outlined to access an application.

Purpose

Most federal agencies offer services through an IT system or application, such as a website, to their employees, other agencies, and the public. To access an application, users may need to provide identity information, create an account, and log in. These actions are part of the digital identity and authentication process.

DIRAs determine the assurance levels for the digital transactions that involve digital identity or require human authentication.² When agencies build or buy applications that use the most current identity proofing and authentication standards, they protect both the digital transactions and the user and agency data behind the applications.

This Digital Identity Risk Assessment playbook helps federal agency Chief Information Officer (CIO) and Chief Information Security Officer (CISO) teams and business application owners to:

• Update and maintain consistent processes;
• Determine whether an agency application requires a DIRA;
• Integrate DIRA into agency Risk Management Framework (RMF) processes; and
• Learn practices to implement DIRA processes.

NIST publishes implementation guides³ and frequently asked questions (FAQs)⁴ for agencies and service providers to use to create information technology solutions to meet these standards. This playbook promotes consistency, effectiveness, and efficiency in your agency’s processes.

How to Use This Playbook

This playbook is divided into three major sections. Read the entire playbook or jump directly to the section that will help your agency.

• High-Level DIRA Process - A step-by-step guide on how to approach a DIRA process for each agency.
• Agency Process Plays - Six plays to create efficient and consistent processes. For example, Play #4 includes a shortcut decision tree for a streamlined DIRA for some applications.
• Appendices - Example diagrams and templates, and references to policies and standards to use in your agency for communications.

Scope

The DIRA playbook applies to all federal Information Technology (IT) systems and applications that need identity proofing and authentication.⁵ This playbook complements the following standard and policy:

• NIST Special Publication 800-63-3: Digital Identity Guidelines
• Office of Management and Budget Memorandum (OMB) M-19-17: Enabling Mission Delivery through Improved Identity, Credential, and Access Management

All agency information technology systems should use the DIRA process as part of the Risk Management Framework (RMF) and Federal Information Security Modernization Act (FISMA) processes. Business owners and information security officers produce a Digital Identity Assessment Statement (DIAS) to document the assurance levels determined by collecting and analyzing the system or application data as part of the assessment process.

This playbook does not apply to:

• Non-person entities,⁶ such as devices, Robotic Process Automation (RPA), or Machine Learning;
• Facilities access;
• Federation Assurance Level 3 solutions;⁷ or
• National security systems (NSS).⁸

The following sections describe a basic DIRA process and provide plays to help you implement efficiency into your agency’s processes.

High-Level DIRA Process

The DIRA process begins when a new application or system is identified or a time-driven or event-driven reassessment is triggered. Once it is determined that a DIRA is needed, application data is identified, collected, and analyzed to determine the assurance levels and produce a Digital Identity Assessment Statement (DIAS), as shown in Figure 1.

Figure 1: Example DIRA Process

A high-level DIRA process includes five steps:

1. Identify Users, Transactions, and Roles
2. Identify Risks and Assurance Levels
3. Determine Steps to Meet Assurance Levels
4. Finalize Digital Identity Assessment Statement
5. Reassess

Step 1. Identify Users, Transactions, and Roles

The first step is to identify the users and transaction information as well as the functional and business roles of the application. There are many definitions to categorize users within the federal government, such as:

• User Types - Organizational and Non-Organizational users
• Communities of Users - Employee, Partner, and Public users
• Common Roles - General, Functional Privileged, and IT Privileged users

These definitions simplify complex requirements related to individuals and privacy, information security, and identity and access management concepts.

First, identify the user types and communities of users the application supports. Identifying an application’s community of users is important to the DIRA processes as communities have different privacy, regulatory, and solution requirements to consider in risk assessments. Table 1 identifies user types and five common examples of communities of users.

Table 1: Examples of User Types and Communities

A transaction⁹ is

“... a discrete event between a user and a system that supports a business or programmatic purpose. A government digital system may have multiple categories or types of transactions, which may require separate analysis within the overall digital identity risk assessment.”

Application owners and the information security team collaborate to identify, analyze, and assess the digital transactions of the application. Examples of transactions and transaction types are phrased as actions on data: Create, Read, Modify, Delete.

Finally, map the community of users to the common roles. Most applications have several different user roles, each with different access privileges. Examples of common user roles include:

• General users
• Can access: Information resources provided by the application
• Examples: Employees, general public
• Functional privileged users
• Can access: Information resources provided by the application, and approval workflows
• Examples: Managers
• Information Technology (IT) privileged users
• Can access: IT systems with read, write, or change access
• Examples: System administrators, security analysts

Table 2 provides examples of user types, transactions, and roles.

Table 2: Examples of User Types and Transactions

Step 2. Identify Risks and Assurance Levels

Determine the digital identity risk for each assurance category by assessing the impacts for each community of user, user type, common role, and transactions identified in Step 1.

• Identity Assurance Levels (IALs) indicate the level of confidence in a claimed identity.
• Authenticator Assurance Levels (AALs) indicate authentication requirements.
• Federation Assurance Levels (FALs) indicate the level of confidence in an assertion used to communicate identity or authentication information across applications or across agencies.

The risks and impact assessment considers the risks to both the agency and the user for the transactions. The risk to one can be significant while not negatively impacting the other at all. It’s common for government applications to have different assurance levels based on differing impacts and risks for each community of users and transactions.

Table 3 lists the six impact categories to use. This table is a guideline for categorizing the risks and impacts involved in your application users and transactions.

Table 3: Impact Definitions

Identity Assurance

Identity Assurance Levels define the processes and solutions used to identity proof users attempting to sign up for a digital service or perform an application transaction. IALs mitigate impacts of providing a benefit or information to the wrong user.

• Identity Assurance is: “Are you who you say you are?”
• Impacts are: “What are the risks to the government or to you if you aren’t?”

Defining the IALs for each community of users and transactions from Step 1 is one of the more challenging aspects of a DIRA. The final IAL correlates to how much personal data¹⁰ is validated and verified for that user during the identity proofing process.¹¹

At Identity Assurance Level 1 (IAL1), the application may or may not require proofing. If an application requires input, a user may only need to provide a real or fictitious name for display purposes and an email address to receive notifications. The information may be self-asserted by the user and doesn’t need to be verified. At Identity Assurance Level 2 (IAL2) or 3 (IAL3), increasingly more personal information about the user needs to be validated and verified either remotely, supervised remotely, or in person. At IAL2, a real name, an email address, and an address of record are confirmed through record checks remotely or in person. At IAL3, a biometric is captured and the user must be verified in person.

Figure 2 explains the three Identity Assurance Levels in example terms of the information validated and verified during the identity proofing process.¹²

Figure 2: Identity Assurance Levels

Appendix B. Examples and Templates includes an example of a decision tree of the risk assessment process flow that defines the Identity Assurance Levels for the communities of users and transactions in Step 1.¹³

Authenticator Assurance

Authenticator Assurance Levels define the strength of the authentication process. AALs mitigate potential authentication errors (i.e., an attacker accessing a user’s account).

• Authenticator Assurance is: “Is this the same user as before?”
• Impacts are: “What are the risks to the government or to you if you are not the same user as before?”

At Authenticator Assurance Level 1 (AAL1), a user might only use a username and password. At Authenticator Assurance Level 2 (AAL2) a user has two factors, including a factor such as a one-time password (OTP) managed by a mobile application on a personal or government mobile phone.¹⁴

Figure 3 explains the concept of the three Authenticator Assurance Levels in example terms of the authentication.¹⁵

Figure 3: Authenticator Assurance Levels

Appendix B. Examples and Templates includes an example of the risk assessment process flow that defines the Authenticator Assurance Levels for the community of users and transactions in Step 1.¹⁶

Federation Assurance

Federation Assurance Levels (FALs) indicate the assertion protocol used by an application to communicate identity and authenticator information. FALs protect information about the authenticated user. They mitigate risks if a malicious actor in the transaction changes or replays the information.

This playbook explains FALs with the outcomes first before explaining the high level requirements and the risk process.¹⁷ To determine if your application requires an FAL, consider the following questions:

For existing applications and defined users and transactions (Step 1):

• Is the application integrated with any type of agency enterprise single sign-on solution?
• Is the application integrated with any government or commercial identity provider?
• For organizational government users and transactions, is the application integrated with an employee’s network logon?

For new applications and defined users and transactions (Step 1):

• Do the same users access other agency applications and could the user experience for identity and authentication be streamlined?

If your agency and application owner answers “Yes” to any of these questions, then the application is federated, or could be federated during the solution definition step (Step 3), and needs a FAL defined for each user community and transaction.

FALs are implemented using standard-based protocols across the federal government. These protocols are commonly used in many applications and transactions globally and are routinely supported in commercial off-the-shelf (COTS), native cloud software-as-a-service, and consumer and enterprise mobile applications. Each FAL defines minimum requirements for how the integrations are performed and the requirements if the user’s information is passed between applications. For example, for some implementations, the federation assurance levels map to commonly used federation protocols such as OpenID Connect (OIDC) and Security Assertion Markup Language (SAML). How those implementations are done maps to the increasing FAL options.

Figure 4 explains the concept of the three Federation Assurance Levels in example terms.¹⁸

Figure 4: Federation Assurance Levels

Appendix B. Examples and Templates includes an example of a decision tree of the risk assessment process flow that defines the Federation Assurance Levels for the communities of users and transactions in Step 1.¹⁹

Step 3. Determine Steps to Meet Assurance Levels

Analyze available technology and solutions at your agency, determine if they are sufficient enough to meet the application needs, and identify what you need to implement. Use data and agency enterprise defined needs when choosing solutions, including:

• Number of users by community of users;
• User experience (UX) and usability (for non-organizational users (i.e., public, business, partner)); and
• Direct and indirect benefits to reuse enterprise-level chosen solutions, including consolidated support desks.

Your agency may determine alternatives to the NIST-recommended guidance for the assessed assurance levels based on:²⁰

• Your mission,
• Your risk tolerance,
• Your existing business processes,
• Special considerations for certain populations,
• The availability of data that provides similar mitigations to those described in the Digital Identity Guidelines, or
• Other capabilities unique to the agency.

Step 4. Finalize Digital Identity Acceptance Statement

Formalize the results of the assessment process with a Digital Identity Acceptance Statement (DIAS). A DIAS must include a minimum set of information about the risk assessment and the assessed and implemented assurance levels.²¹

An example of a DIAS is included in Appendix B. Examples and Templates.

Step 5. Reassess

A digital identity reassessment may be time-driven or event-driven and applies to a reassessment of the DIRA.

If an event triggers a security impact analysis, an agency may perform a DIRA outside the normal continuous monitoring cycle. Significant changes requiring a digital identity reassessment include changes in:

• Core mission or business functions;
• Purpose or nature of a system;
• Risk environment;
• How information, including PII, is processed; or
• How information is processed, stored, or transmitted by the system.

Agency Process Plays

This section introduces six plays for your agency to create efficient and consistent processes for a DIRA.

Play 1. Streamline Risk Management and Assessment Processes

The Risk Management Framework (RMF) forms the basis of your agency application Assessment and Authorization (A&A) lifecycle. A DIRA process integrates into the routine phases of the RMF to streamline processes and enables efficient reuse of application and agency resources. Figure 5 shows an alignment of this playbook’s example DIRA process steps with the RMF.

Figure 5: Example DIRA Process Steps in Risk Management Framework Phase

Step 1 of the example DIRA process happens in the Categorize phase. When categorizing a system,²² application owners and security officers identify overall system data types and assign impact levels for each of the confidentiality, integrity, and availability security objectives.

A Privacy Threshold Analysis (PTA) is typically included in this phase. The identification of the DIRA IALs, AALs, and FALs directly correlates to the collection of PII; who has access to what information; whether information is self-asserted or verified; and the risks of excessive identity proofing.

Meanwhile, Step 4 of the example DIRA process aligns with the Assessment phase. The Digital Identity Acceptance Statement must include the IALs, AALs, and FALs where the application was assessed and the implementations made.

Play 2. Add Context for the Mission

Context is powerful when assessing risks, making agency risk decisions, and engaging across multi-disciplinary agency stakeholders. Standard and general government-wide policies set the foundation for many agency activities but are written for broad mission areas. Translate user types, transactions, DIRA impact levels, and risk statements into words that are applicable and useful to your agency.

Table 4 provides examples of how agencies add agency-specific terms or context for user types, transactions, and impact levels.

Table 4: Example Definitions and Agency Context

Table 5 provides an example of how two agencies apply context to Transactions and Impact Levels.

Table 5: Example Transactions and Impact Levels

Play 3. Use Templates

It’s a best practice that agencies develop standardized templates to promote consistency in procedures for digital identity risk assessments. Example templates can be as simple as:

• Visual informational guides for what a DIRA is,
• Informational guides on risks,
• Simple spreadsheets or digital surveys, and
• Digital Identity Acceptance Statements.

Appendix B. Examples and Templates contains a few example templates provided by agencies.

Play 4. Shortcut Decision Trees

All federal applications that perform digital transactions and require identity proofing or authentication require a Digital Identity Acceptance Statement, regardless of how the system is hosted. However, not all federal applications require the full example DIRA process and efforts.

Table 6 provides an example shortcut guide for determining whether to perform a full DIRA process based on application characteristics. IAL, AAL, and FAL levels in this table are examples. Applications must follow agency policies, which may be more stringent than the examples in this table.

Table 6: DIRA Shortcut Guide

Play 5. Leverage Existing Agency Tools

Leverage existing tools at your agency to automate and create repeatable and consistent DIRA processes. For example, one agency integrated the DIRA process into its Governance Risk and Compliance (GRC) tool. The agency was able to simplify integration with the Risk Management Framework (RMF) lifecycle and support the inclusion of the DIAS with other system artifacts. Agencies that use commercial GRC tools should consider integrating DIRAs into the workflows.

Play 6. Less Is More

A common assumption when building or buying applications for missions is that all users need accounts. Take the opportunity during the DIRA process to consider the application processes and functionality needed. Consider the mission, applications needs, and the two example questions below:

1. Do all users need accounts?
2. How many users are regularly recurring returning users?

Reconsider the business process carefully and validate the current and future designs using data on the returning users, transaction volumes, and privacy principles.

• Design the business process for the user to submit information without requiring an account,
• Limit the information required to create the account, and
• Make most of the information requested optional.

Appendix A. Policy, Standards, and Guidance

This section provides links to the federal laws, policies, standards and other guidance that impact and shape DIRA implementations. NIST also publishes useful Frequently Asked Questions for agencies, and Implementation Resources for solution developers.

Appendix B. Examples and Templates

This appendix provides examples and templates of existing resources to help establish or improve DIRA processes. It includes the following sections:

1. Decision Tree Examples
2. Process Flow Examples
3. Digital Identity Acceptance Statement Example and Template

1. Decision Tree Examples

This section includes additional example risk assessment decision trees used by some agencies for the Digital Identity Risk Assessment for transactions. Original source decision trees are in NIST Special Publication 800-63-3 Digital Identity Guidelines, Section 6, Selecting Assurance Levels.

Figure 6: Identity Assurance Level Decision Tree

Figure 7: Authenticator Assurance Level Decision Tree

Figure 8: Federation Assurance Level Decision Tree

2. Process Flow Examples

This section includes additional example process flow diagrams used by some agencies for the Digital Identity Risk Assessment processes. Choose and reuse any process flow that works best for your agency.

Figure 9: Explains the DIRA Process from Data Collection to Ongoing Assessment

Figure 10: Explains in a More Detailed Way the DIRA Process Flow from the Data Collection Phase to the Ongoing Assessment Phase

Figure 11: Explains a Six-Step Process of What is Required to Implement a DIRA

3. Digital Identity Acceptance Statement Example Template

This Digital Identity Acceptance Statement template is provided as one sample for agencies.

Appendix C. NIST Special Publication 800-63-3, Requirements Traceability Matrix

This appendix includes both normative requirements and informative references from NIST SP 800-63-3 Digital Identity Guidelines. Only requirements related to the agency processes for digital identity risk assessments are included. The Playbook Consideration column includes comments on the standards statements and alignment to this playbook’s development.

Appendix D. Updates to NIST Special Publication 800-63

In June 2017, NIST replaced the Electronic Authentication Guideline²⁴ with the Digital Identity Guidelines.²⁵ The new standard provides agencies increased security and privacy, more flexibility to meet their mission and constituent needs, and better alignment with digital identity best practices. It outlines the digital identity risk assessment methodology that federal agencies must implement.

NIST’s Digital Identity Guidelines identify the implementation requirements for conducting a DIRA and enable modernized risk-driven approaches for digital identities. Figure 12 depicts updated content details.

Figure 12: Digital Identity Guideline Information Locations

Why the Update to NIST Special Publication 800-63-3?

NIST Special Publication 800-63-3 was updated to do the following:

• Implement Executive Order 13681: Improving the Security of Consumer Financial Transactions²⁶
• Align with the current market
• Promote innovation
• Simplify and provide clearer guidance

What Has Changed?

• The DIRA process replaces the Electronic Authentication Risk Assessment process.
• There is a shift from levels of assurance (LOAs) to individual assurance levels (collectively known as xALs) for identity proofing, authentication, and federation.
• The updated document introduces federation as a separate topic.

Mix and Match Assurance Levels

The revised guidance provides individual assurance levels that can be mixed and matched, giving agencies the flexibility to deploy strong authentication without having to proof a user’s identity (i.e., if the collection of sensitive information is not required). The mix and match assurance levels allow opportunities for:

• Greater flexibility,
• Greater user experience,
• Enhanced privacy, and
• Reduced risk.

Footnotes