Scroll to discover
Watch a Demo
Skip to content

NIST 800-53 and How Threat Modeling Can Help.

We know it's not easy to make regulations or standards sound jazzy. So bear with us while we summarize the essentials. 

 

Why do organizations need to conform to NIST 800-53 Rev.5?

As of May 30, 2023, FedRAMP officially approved and adopted the new Rev. 5 baselines – aligning with the National Institute of Standards and Technology Special Publication 800-53 (NIST 800-53) Rev. 5 baselines that went into effect in September of 2021. The Federal Information Security Management Act (FISMA) also stipulates that the NIST 800 series is to be followed. It does not require an agency to implement every single control but to implement the controls relevant to their organization and systems.

What companies is the NIST special publication aimed at?

Cloud Service Providers (CSPs) with existing authorizations, those who are mid-process, and those looking to achieve a FedRAMP authorization for the first time will all be required to align with Rev. 5 baselines. As well as organizations needing to map to FISMA (The Federal Information Security Management Act) compliance requirements. Non-compliance can lead to penalties and other negative impacts such as reduced funding or reputational damage.

Icon - Nist

What exactly is NIST SP 800-53? We’ve summarized it for you.

NIST 800-53, governs security controls for federal information systems. It mandates risk assessment, security planning, and continuous monitoring. CSPs must conduct risk assessments and implement controls based on identified risks. This framework underscores the relevance of threat modeling in federal information security. Revision 5 also details the need for threat modeling and vulnerability analysis: ‘Require the developer of the system, system component, or system service to perform threat modeling and vulnerability analyses during development and the subsequent testing and evaluation of the system, component, or service..’

Icon - Executive order

Threat modeling to conform and secure. NIST says so. 

The practice of threat modeling is recommended within the NIST SP 800-53 Rev. 5. 
It is discussed in several following areas of the publication, including a specific chapter (SA-11) exclusively for threat modeling and vulnerability analysis. 

Within the IriusRisk Threat Modeling Tool, there are Security Libraries built in for FedRAMP and NIST 800 series, including 800-53 Rev 5. Which means users of IriusRisk, can align their architecture to what is required from the Rev 5 publication.

Love details? Here are the NIST Threat Modeling Specifics
There are three chapters within NIST 80–53 that specifically states threat modeling is a required an activity. These have been summarized below, or you can read the full details here.

  • Security and Privacy Engineering Principles

    Implement SA-8: Security & Privacy Engineering Principles.

    Apply organization-defined principles in system development. Include threat modeling for risk mitigation.

  • Threat Modeling and Vulnerability Analyses

    Implement SA-11 Developer Testing and Evaluation.

    Mandate developer-conducted threat modeling and vulnerability analysis throughout system, component, or service development. Consider impact, environment, threats, and risk levels. Utilize defined tools, methods, and rigor levels. Validate with organization-defined acceptance criteria. This ensures effective operation and mitigation of vulnerabilities arising from design changes.

  • Reuse of Threat and Vulnerability Information

    Implement SA-15 Development Process, Standards and Tools.

    Mandate utilizing threat modeling and vulnerability analysis from similar systems in current development. Leverage vulnerability insights for informed design and implementation, drawing from similar systems or components. Utilize data sources like NIST National Vulnerability Database.

  • Security and Privacy Engineering Principles
  • Threat Modeling and Vulnerability Analyses
  • Reuse of Threat and Vulnerability Information

Security and Privacy Engineering Principles

Implement SA-8: Security & Privacy Engineering Principles.

Apply organization-defined principles in system development. Include threat modeling for risk mitigation.

Threat Modeling and Vulnerability Analyses

Implement SA-11 Developer Testing and Evaluation.

Mandate developer-conducted threat modeling and vulnerability analysis throughout system, component, or service development. Consider impact, environment, threats, and risk levels. Utilize defined tools, methods, and rigor levels. Validate with organization-defined acceptance criteria. This ensures effective operation and mitigation of vulnerabilities arising from design changes.

Reuse of Threat and Vulnerability Information

Implement SA-15 Development Process, Standards and Tools.

Mandate utilizing threat modeling and vulnerability analysis from similar systems in current development. Leverage vulnerability insights for informed design and implementation, drawing from similar systems or components. Utilize data sources like NIST National Vulnerability Database.

Powered by Partners.

We are the experts in automated threat modeling, and we know which regulations our clients must conform to. We also have a partnership with stackArmor, the experts in all-things-FedRAMP. stackArmor allows us to offer even further guidance and support, for organizations. Plus, our training and consultancy partner, Toreon, offers valuable guidance on becoming compliant with NIST 800-53. So whatever you need for your Rev 5. journey, we have a stellar team to make this possible. 

So, what next?

Take a look at our Security Content Library for all of the included risk patterns which are mapped to these standards, directives and compliance needs. 

Ready to talk?

Get a bespoke demo of IriusRisk Threat Modeling, the NIST Library, and how our tool can support you to comply with FedRAMP. Our knowledgeable team is ready to help. 

TM Demo email banner
Community Edition - Email banner (1)