What is the National Institute of Standards & Technology (NIST)?
What is the National Institute of Standards & Technology?
The National Institute of Standards & Technology (NIST) is a physical sciences lab and non-regulatory US government agency devoted to developing standards that increase technological competitiveness and innovation. NIST’s mission is “to promote US innovation and industrial competitiveness by advancing measurement science, standards, and technology in ways that enhance economic security and improve our quality of life.”
Founded in 1901 and now part of the US Department of Commerce, the standards developed by NIST have influenced the innovation of technological services, power grids, electronic health records (EHR), computer chips, nanotech, atomic clocks, and much more. Regarding information technology, NIST has been the guiding force behind Zero Trust and cloud-security guidelines and standards.
For the scope of this article, we’ll focus on the work of NIST as it relates to securing cloud-based information systems.
NIST & Zero Trust Architecture
Zero Trust Security is a cybersecurity model that moves beyond an implicit trust model and continuously re-evaluates the risk and trust levels of every digital interaction. Based on the principle of “never trust, always verify,” Zero Trust provides the “least access” required to relevant data, applications, and assets as they are needed to complete a job.
Refactoring your security architecture to support modern cloud-based technologies requires a modern identity solution that integrates with existing security and compliance tools. This way, a Zero Trust Identity Architecture can continue to enforce existing use cases while enabling the creation of new ones. This requires an architecture built upon interoperable solutions that can readily exchange information, providing your organization the visibility, risk, and threat intelligence to drive automated decision-making.
In the wake of several high-profile cyber attacks and breaches involving federal agencies, NIST created an abstract definition of a Zero Trust Architecture along with several deployment models. Elaborated in NIST SP 800-207, Zero Trust Architecture, this model provides a roadmap for enterprise security architects looking to implement Zero Trust-based approaches to information security.
According to the NIST model, a Zero Trust Architecture must incorporate three core components. These are:
- A policy engine, which decides to grant, deny, or revoke access to resources for all entities that request to do so. The policy engine calculates trust scores or confidence levels to serve as a basis for each of these decisions.
- A policy administrator, which establishes and terminates the connection between an entity and a resource. The policy administrator relies on decisions made by the policy engine to determine whether to allow individual sessions to proceed. It generates authentication tokens or credentials for each session.
- A policy enforcement point, which enables and monitors ongoing connections between entities and enterprise resources.
With Zero Trust architecture, all interactions are to be achieved in the most secure manner possible, emphasizing consistent identity verification and authentication. And all interactions are continuously reassessed. Each time access to a resource is granted, this is done for only one session — and for that resource alone. Every access request is evaluated dynamically based on organizational policy and risk evaluation. Each request is checked to ensure that the identity making the request (user or machine identity) should be granted access, that their laptop, mobile device, or other IT system is behaving appropriately, and that the requested resource has the right characteristics.
To obtain the complete set of capabilities needed to achieve holistic visibility and control, you’ll need multiple solutions with overlapping and tightly integrated capabilities.
Building a Zero Trust architecture isn’t a simple, one-step process. It instead requires implementing new solutions that can gather intelligence across your IT ecosystem and inform the SASE, access management, and security tools that enforce policies. Designing such an architecture means thinking differently about interconnectivity and the value of an open, standards-based approach. It means thinking smarter in your entire approach to identity and security across your organization.
Dive into the details by reading more about the Building Blocks of Zero Trust Identity Architecture on our blog.
NIST, FISMA & Cloud Security
FISMA is a US regulation that provides an information security framework for government contractors and federal agencies, including the legislative and executive branches of government. It aims to ensure information is appropriately handled and managed. FISMA’s standards and procedures are defined by NIST, which provides a risk management framework for achieving FISMA compliance. The FISMA guidelines for compliance are outlined in NIST 800-53, NIST 800-63, NIST 800-171, FIPS 199, and FIPS 200.
For an in-depth breakdown of FISMA, and how to achieve compliance, check out our FISMA glossary entry.
Let’s take a deeper dive into NIST-800, the standard focused on digital identity services.
Understanding NIST 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 Separation of Duties (SoD) violations or leaving the agency non-compliant.
What is a Digital Identity?
The irony of NIST SP 800-63 lies in its own admission that there is no clear definition of digital identity. However, the NIST 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 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:
- User application through enrollment
- Cloud Services Provider (CSP) identity proofs the application and creates a subscriber
- CSP and subscriber create authenticators and credentials
- CSP engages in lifecycle management
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 traditionally siloed identity systems.
Thus, agencies and organizations adopting a NIST framework often choose Single Sign On (SSO) 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:
- Inconvenience, distress, or damage to standing or reputation
- Financial loss or agency liability
- Harm to agency programs or public interest
- Unauthorized release of sensitive information
- Personal safety
- 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 are 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:
- Users already have an authenticator at or above their required AAL
- Full user community requires multiple credential form factors
- Agency lacks infrastructure for authentication management
- Adding and upgrading primary authenticators may be necessary in the future
- Different environments need support
- Users come from multiple communities with individual identity infrastructures
The five scenarios in which NIST suggests attribute federation are when:
- The users or the service require pseudonymity
- Service access only requires a partial attribute list
- Service access only requires at least one attribute reference
- Required attributes are issued from somewhere other than the agency
- The 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 continuous monitoring to ensure that the organization maintains compliance with its policies within the data assets. As such, agencies must begin with federated IAM strategies and supplement those with additional safeguards.
Saviynt & FedRAMP
The Federal Risk and Authorization Management Program (FedRAMP) was developed as a means to validate cloud-computing services for FISMA compliance. 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 must maintain governance over access to their data and cloud solutions. Saviynt’s security posture, in conjunction with its intelligent analytics, accelerates 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. Removing 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/de-provisioning process, automating requests and providing suggestions to mitigate potential security violations.
Saviynt’s Identity Cloud
Saviynt Identity Cloud is built in the cloud, for the cloud, and is the only FedRAMP-authorized SaaS solution for Identity Governance and Administration (IGA) and Cloud Privileged Access Management (CPAM). The fundamentals of IGA align closely with the requirements outlined in Federal Identity Credential and Access Management (FICAM). Saviynt Identity Cloud is a modular, converged cloud platform developed entirely in-house using a single code base without bolted-on solutions from third-party acquisitions to complicate the implementation process. Each solution can operate independently, allowing customers to select the product that suits them – and integrate Identity Cloud with existing solutions.