With the great migration to the cloud, application development morphed into DevOps. Application development suddenly required two areas of design: the application itself and the underlying cloud infrastructure that supports the application. And unfortunately, both are susceptible to security threats, and therefore both need to be protected.
The development community is always on the lookout for ways to speed up design by automating as many processes as possible. And while it’s difficult to automate the design of a unique application, infrastructure is more predictable, and therefore lends itself more to automation.
Enter infrastructure as code. Infrastructure as Code (IaC) is “a method of managing and provisioning cloud infrastructure using programming techniques instead of manual processes. Automation is almost always considered a business benefit in and of itself, but automation through infrastructure as code unlocks a whole range of benefits that work together to level up any DevOps department.”
So, it shouldn’t come as a surprise that IaC adoption continues to grow and is one of the top 10 trends in DevOps today. What’s another top 10 trend in DevOps today? Evolving DevOps into DevSecOps, which integrates security into the DevOps CI/CD pipeline.
There are only a few ways to seamlessly turn DevOps into DevSecOps today and one of the very best is by incorporating threat modeling. Not only is threat modeling becoming mandated by regulatory bodies (e.g., FDA, FTC, NIST), but making it part of the DevSecOps process is the most cost-effective time to do it.
Infrastructure as Code and Threat Modeling
So, a lot of companies are looking to make threat modeling part of their DevSecOps process. But the artifact produced when doing IaC is really just a human readable description of the infrastructure. How do you generate a threat model when all you have to start with is a JSON or HCL file?
Threat modeling requires you to generate a threat diagram, identify the threats, identify the controls to mitigate those threats and then apply those controls. Oh, and it should be a seamless part of the DevSecOps process which doesn’t require some entirely new skill set for the developers who created the file in the first place. That’s the challenge.
There are a lot of different frameworks people use to create threat modeling diagrams, but none of them make the assumption that you’re starting from an IaC configuration file. At this moment, you really only have two options.
The first option is to generate the threat diagram manually from the IaC file. This requires a little interpretation on the developer’s part. There are commercially available tools to assist in creating the diagram, but it still requires starting from a blank canvas. Manually created threat diagrams take time and lend themselves to human error. Never a good thing when threat modeling.
It sure would be great if there was some way to automate the process of converting the IaC file to a fully fleshed out threat model. As things turn out, there is, which brings us to option number two.
IaC-Assist by ThreatModeler was purpose-built to solve the precise challenge detailed above. How do you create a threat model, when starting with an IaC file, without having to do so manually?
IaC-Assist loads right in the IDE and enables engineers to implement security policies and controls without having to leave their coding environment. IaC-Assist identifies design flaws in code, explains the issue and provides just-in-time contextual guidance for revision. All with one click.
If you’d like to learn more about how IaC-Assist can instantly transform your configuration files into threat models, you can reach out to ThreatModeler here.