In May, 2021, the Biden Administration issued Executive Order (EO) 14028, “Improving the Nation’s Cybersecurity.” Included in the EO is the requirement that “the Federal Government must take action to rapidly improve the security and integrity of the software supply chain.” Responsive to the EO, the National Institute of Standards and Technology (NIST) published an interagency/internal report NISTIR 8397, Guidelines on Minimum Standards for Developer Verification of Software. The report provides eleven recommendations for software verification techniques, the first of which is “Threat modeling to look for design-level security issues.”
Threat modeling is an exercise in which teams name potential weaknesses that could enter an application through the design and coding phases of development. Once these are enumerated, teams can assign risk mitigation controls to development, security, and operations for implementation during the normal course of development and deployment. By doing so, testing focus shifts to one verification of the controls versus first-pass vulnerability identification. The result is more secure software and fewer issues found late in the development process that slow down new releases.
Manual Threat Modeling? Not in Today’s Environment
NIST’s guidance recommends that threat modeling be conducted “multiple times during development, especially when developing new capabilities, to capture new threats and improve modeling” [emphasis in original]. Unfortunately, in our opinion, this recommendation is unachievable using the referred to threat modeling methods.
NISTIR 8397 references 12 threat modeling methods in a publication from Carnegie Mellon University’s Software Engineering Institute. All are manual. We’ve discussed at length the challenges of manual threat modeling. Briefly, it requires senior engineering and security resources to diagram an application’s architecture and data flow, generate attack trees and generate trust boundaries. When an application changes through “new capabilities,” so does the threat model. Each pass at the threat model can require days of work and discussion, limiting its use to only the organization’s most critical applications. Consequently, manual threat modeling does not scale and inconsistent due to the biases and preferences of the participants. Auditing a team’s progress implementing controls is particularly challenging, as test cases may vary by a team’s preferences and the lack of integrations with automated testing tools and issue trackers.
Authority to Operate and Threat Modeling
U.S. federal government agencies – like most customers – need rapid delivery and security. Manual threat modeling supports only the latter. Software suppliers to the government must also meet ATO requirements or maintaining continuous ATO (cATO). This includes providing evidence they comply with NIST’s Risk Management Framework and thousands of security controls that can vary by deployment environment. Adding or trying to incorporate manual, resource-intensive traditional threat modeling approaches is a difficult approach for even the best funded DevSecOps teams. Tracking thousands of controls and validating their implementation using manual methods across a portfolio of applications is impossible.
To reduce cybersecurity risk at scale, software producers targeting U.S. federal, state, and local government agencies need a different approach to modeling software weaknesses and providing evidence that appropriate controls are in place. To meet the demands of today’s customers it must tightly integrate with product workflows and help product teams deliver secure products at high velocity.
A Better Approach
Organizations producing software for U.S. government agencies need a threat modeling solution that enables them to scale threat modeling for DevSecOps, achieve ATO, and release secure products faster. Like most DevSecOps initiatives, this requires automation.
Automated threat modeling enables teams to quickly identify threats in an application’s programming languages, frameworks, and deployment environments. Threats are then translated into actionable tasks (mitigation controls) and assigned to development, security, and operations for implementation. If a component of the application’s technical stack is added or changed, the threat model and mitigation controls can be updated independent of the rest of the model.
How SD Elements Can Help U.S. Government Agencies with Software Threat Modeling
SD Elements is a secure coding and threat modeling platform that allows organizations to rapidly develop secure, compliant software and interconnected components. Instead of requiring scarce senior security and development resources to spend days modeling an application, SD Elements produces a threat model from a survey of the application’s technical stack. It translates threats into specific, consistent security controls; actionable tasks, including code samples and test plans that mitigate threats. Integrations with Automated Security Testing (AST) tools allow teams to validate that security controls are properly implemented.
SD Elements allows the ultimate shift-left approach to software security. Using SD Elements helps teams anticipate weaknesses in applications and their deployment environments that could be exploited by attackers and build mitigation controls as part of the normal development process. By automating the process, SD Elements reduces threat modeling time by 80 percent or more, allowing teams to scale threat modeling across their software portfolios.
Unlike manual threat modeling methods, SD Elements provides teams with a centralized platform for identifying threats and tracking controls. Its extensive content library is continuously updates by Security Compass’s team of security experts and includes U.S. federal government standards and regulations including the NIST Risk Management Framework (RMF), NIST SP 800-53R5, FedRAMP, Committee on National Security Systems Instruction (CNSSI), and others. Using this built-in application security expertise ensures consistent controls across all programming languages and deployment platforms, on premise or in the cloud.
SD Elements provides a single pane of glass for near real-time reporting on the status of threats and mitigations across an application or portfolio. To reduce workflow disruptions, it integrates with the development tools used every day by teams. It assigns tasks and tracks progress through issue trackers like Jira, Archer, and ServiceNow. It validates the effectiveness of controls through integrations with security testing tools like Checkmarx, Synopsys, Veracode, and others.
Next Steps
If you are a U.S. federal, state, and local government agency that develops software, or are a contractor that develops software for these agencies, learn more about how SD Elements can help you automate and scale your organization’s threat modeling process while maintaining ATO by downloading our recent white paper, Speeding Secure Software Development and Attaining Authority to Operate Faster and at Scale in the U.S. Government Agencies.