With the introduction of the Cybersecurity Maturity Model Certification (CMMC) in the U.S. as a means of unifying cybersecurity standards for the Department of Defense, organizations must consider the impact on their DevSecOps operational activities. There are many stakeholders to consider: business, development, operations, security, compliance, and risk. From a governance perspective, how do we integrate this standard with our DevSecOps teams?
A lot of tools and processes traditionally lack a security perspective.
Given the importance of software development in an organization today, the impact of operationalizing CMMC is not trivial. Many organizations rely on manual spreadsheets to keep track of compliance against standards and frameworks like CMMC. This approach is difficult for traceability and makes third party auditing a laborious process.
Ideally, we want to provide a real-time assessment of the residual software security risk across a portfolio of DevSecOps projects while work is being performed. The goal is to utilize security as an enabler to help the business move faster while facilitating collaboration across multiple stakeholders. This type of approach can help business stakeholders make informed decisions.
In this article, we will explain how Developer-centric Threat Modeling addresses these pressing issues and a missing gap in the DevSecOps tools landscape.
How Developer-centric Threat Modeling ensures security with speed
Historically, DevOps teams were focused almost entirely on speed of delivery. Our tools were focused on increasing levels of automation and the continuous integration and delivery pipelines reinforced the importance of speed. With the introduction of security practices in DevSecOps, the challenge was in trying to integrate a practice based on security controls into a fast-moving delivery pipeline. The result was either security was left until the last minute, or it slowed down the delivery process — none of which was ideal.
Threat modeling can help. Threat modeling exercises anticipate weaknesses in the application’s technology stack, then prescribe security countermeasures to be implanted during the normal development cycle. Traditional threat modeling requires many days or weeks of time from scarce senior resources and is therefore limited to an organization’s most critical applications.
Developer-centric Threat Modeling (Developer-centric Threat Modeling) solves this problem by automating software threat model generation, translating those threats into actionable countermeasures and security and compliance best practices, and delivering those directly to developers within existing DevOps workflows. It is an ideal set of tools for environments driven by regulations or standards that involve multiple stakeholders.
There are five key parts to Developer-centric Threat Modeling:.
- Information Gathering: SD Elements guides users in a systematic way so that projects are onboarded efficiently. It gathers information about your project, such as its technology stack, deployment infrastructure, security testing tools, and compliance requirement.
- Threat Modeling: Based on Security Compass’s extensive knowledgebase of security threats and countermeasures, highly visual threat modeling system dependency diagrams can be generated within a fraction of the time and effort typically required by more traditional manual methods .
- Expert Assessment: SD Elements analyzes the information and correlates it with regulations, security and compliance requirements, and industry best practices in the knowledge base .
- Recommendations: SD Elements makes intelligent decisions on threats, countermeasures, security controls, just-in- time training, and even code samples specific to your technology and industry, delivered these directly to your issue tracking tools. It also rapidly classifies your project into relative risk grouping to help your teams manage projects by potential risk.
- Validation and Reporting: SD Elements tracks countermeasures and controls and can also validate the status of certain tasks automatically by capturing updates from security testing tools. This gives you a near real-time view into the risk status of your projects, and the controls in scope for each, at any time in the project life cycle.
Implementing CMMC through Developer-centric Threat Modeling
Let’s walk through an example of how Developer-centric Threat Modeling can help an organization attempting to achieve CMMC Level 2.
For this example, let us assume we have a standalone Java application with a database. The simplicity of this architecture will allow us to focus on value creation in the compliance and governance process rather than the technology domain.
A Developer-centric Threat Modeling tool would correlate the CMMC Level 2 guidance with the architectural constraints of the application to identify areas of risk. In this case, that means the intersection of a Java application with a backend database against CMMC Level 2 compliance requirements. The tool would identify the following policy from CMMC:
AC.2.007: Employ the principle of least privilege, including for specific security functions and privileged accounts.
Notice how this is useful from a compliance and security perspective. People in these teams are used to dealing with policies across the lifecycle (from policy creation to termination). However, handing this over to a developer or operations engineer is not prescriptive enough. There may be different ways to interpret what this means and how it should be implemented. The ambiguity surrounding this is not for lack of trying, it is simply speaking a different language between policymakers and engineers.
What we need is more concrete guidance that contextualizes the above policy into a language that developers, operations, and engineers can understand and implement. As an example, a Developer-centric Threat Modeling tool would offer the following translation:
- Restrict access to tables and schemas that are needed.
- Restrict access to actions that are needed (such as select, update, and delete).
- Remove access to stored procedures that the application does not need.
Notice how the words being used are contextual. Access control, database schemas, and stored procedures instantiate the high-level guidelines into easy-to-understand instructions (thereby reducing wasted time). This example can be further elaborated to contextualize against a particular database platform. The translation between a high-level security guideline and actionable tasks is a key value proposition of Developer-centric Threat Modeling tools. Speed and scale is achieved by integrating the requirements of various stakeholders and codifying with the Developer-centric Threat Modeling tool.
The work performed by engineers continues as normal, using the tools and frameworks with which they are familiar. This limits the need to slow down and learn an entirely new tool.
Once the engineers have completed their work, test cases need to be created to ensure auditability. Developer-centric Threat Modeling tools provide sample test cases as an accelerator. The benefit of having this guidance upfront is that, by shifting testing to the left, we can start to create test cases much earlier. Additionally, the prescriptive nature of the test cases allows for the traceability of these test cases to the CMMC policy. Here is an example of the prescriptive output:
- Test #1: Review the source code to determine the account that the application uses to connect to its database at runtime. The test fails if the application uses a database super-user account.
- Test #2: Review the database permissions for the user. The test fails if the user has more permissions than it requires (such as ability to drop tables, alter the database schema, or execute unnecessary prepared statements).
Once again, the language is relevant to the testing stakeholder. If the test cases pass, that rolls back into AC.2.007 as a successful completion. In this way, each clause in the CMMC standard has auditability and traceability while retaining an emphasis on delivery speed. These test cases can be performed through automation or human-in-the-loop processes. By combining these results, teams can identify areas of weakness and provide evidence of additional training or guidance to build the required capabilities for business assurance.
At the end of a cycle, a CMMC report can be generated from the Developer-centric Threat Modeling tool that shows whether all relevant technical tasks have been completed to comply with CMMC Level 2. In doing so, multiple stakeholders can interact in a way that integrates their processes without requiring extensive process or architectural rework.
The example above illustrates Developer-centric Threat Modeling tools in the context of compliance, development, operations, and testing. But it is not difficult to extend this to include architects (with prescriptive requirements on readable/writeable classes, for example) or database authentication for operations teams. The intent is to demonstrate how CMMC operationalization can occur in a fast-moving delivery pipeline.
Focusing on integration and automation
As stated at the beginning of this article, security and compliance activities often operate in their own silos. That makes integration with fast-moving continuous integration and delivery cycles difficult. Artifacts produced from one team are not easily ingested into downstream systems. That creates unnecessary noise and makes system integration and automation difficult to achieve.
True integration and automation is achieved through harmonization of the underlying metadata across multiple stakeholder systems. This allows organizations to synchronize processes and systems without having to force expensive configuration work into all the systems.
Integration in a Developer-centric Threat Modeling context does not preclude second and third level integration. For example, developers can still use code scanners as part of their testing and the results can feed into a Developer-centric Threat Modeling tool to prove completion of work.
Conclusion
Achieving CMMC compliance should be considered as an ongoing, sustainable program. This requires the ability of multiple stakeholders to provide their requirements into a fabric that integrates into a DevSecOps workflow. The definition of “complete” is baked into Developer-centric Threat Modeling tools and provides auditability and traceability.
Developer-centric Threat Modeling tools are helpful to bring compliance monitoring to DevSecOps automation. Rather than trying to force development and operations into a security sandbox, Developer-centric Threat Modeling tools integrate security from the beginning. It shifts the conversation from a zero-sum decision around speed or security. Rather, it is the inclusion of both in a way that articulates the residual risk and trade-offs to stay within the guardrails of an organizational risk threshold.