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 Balanced Development Automation (BDA) attempts to help address these pressing issues. This is an evolving category that is still being defined but addresses a missing gap in the landscape of DevSecOps tools today.
How BDA 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.
BDA tools focus on leveraging security proactively as a means of achieving speed to market. It is an ideal set of tools for environments driven by regulations or standards that involve multiple stakeholders.
There are four key parts to BDA.
Regulations and standards: BDA tools natively incorporate operational guidance for regulations and standards. Through APIs, other pipeline tools can ingest the relevant procedures and return results back to show completion status against individual clauses.
Just-in-time training: Secure development and operational hardening are critical. With the shortage of qualified resources, BDA tools integrate the right training which helps to ensure consistency at scale while moving at speed.
Secure coding practices: A lot of coding is done through searching code samples in the wild. Unfortunately, these code samples often do not follow secure coding practices. Providing these code samples accelerates the development time.
Risk assessment: The typical risk assessment process for this involves elicitation, analysis, and recommendations. BDA tools shorten the cycle time by filtering out the non-essential activities to achieve compliance for a given standard or regulation. The results are a policy-driven approach to threat modeling which helps accelerate the areas to concentrate on.
Implementing CMMC through BDA
Let’s walk through an example of how BDA can help an organization attempting to achieve CMMC Level 2.
We cannot walk through the entire process for a portfolio of applications but, 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 BDA 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. 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 BDA 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 BDA tools. Speed and scale is achieved by integrating the requirements of various stakeholders and codifying with the BDA tool.
The work performed by engineers continues as they normally do, using the tools and frameworks they are familiar with. This limits the need to slow down and learn an entirely new tool.
Once the engineers have completed their work, to ensure auditability, test cases need to be created. BDA 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 the emphasis on speed of delivery. 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 in order to build up the right capabilities to provide business assurance.
At the end of a cycle, a CMMC report can be generated from the BDA 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 BDA 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 for the harmonization of processes and systems without having to force expensive configuration work into all the systems.
Integration in a BDA 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 BDA tool to prove completion of work.
Achieving CMMC compliance should be considered in light of 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 BDA tools and provides auditability and traceability.
BDA tools are helpful to bring compliance monitoring to DevSecOps automation. Rather than trying to force development and operations into a security sandbox, they 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.