What’s the easiest way to learn anything new? Don’t start from scratch. This means employing three strategies:
1) Use the skills you already have
2) Take advantage of the latest tools
3) Don’t reinvent the wheel
Every time you write a new program, do you use a different language, or do you tend to stick to the ones you’ve already mastered? And when you write a new program, do you write every line of code yourself or do you take advantage of existing software libraries and development tools?
You can use the same strategy, you already use in development, to learn threat modeling quickly. By using the same DevOps language and diagrams, you’re already using, to model threats, threat modeling becomes just another step in the development lifecycle. And by utilizing automatic discovery tools, you can find both development and infrastructure problems without much effort. Together they make threat modeling a quick and easy activity to start your SDLC securely.
Diagrams & Templates
If you’re doing DevOps, then you already have architectural diagrams which are accessible to you. Your diagrams may include a high-level overview of components, integration protocols, network boundaries, infrastructure and data flow. You can use these same diagrams to model threats by including the threats in the diagrams.
If you’re doing DevOps, then the chances are good you’re also doing infrastructure as code (IaC). So, whether you’re using a scripting language like Python; a configuration management tool like Ansible; a provisioning tool like AWS CloudFormation; or a templating tool like Docker, to provision, configure and manage your infrastructure, you can use the same thing to model threats.
Now maybe you don’t know how to model threats and include them in your architectural diagrams (yet), that’s okay. You can take advantage of pre-defined templates or “stacks”, which represent portions of threat models corresponding to frequently-used applications and system components. It dramatically reduces what you have to learn in threat modeling when you can draw from a library of templates. And the templates can be reused, in some cases with minor adaptations, as a foundation for creating new threat models.
Inputs & Outputs
You only need to identify a few inputs to your threat model to make it effective, which shouldn’t be difficult for a developer. The inputs include identifying the assets that store critical information, the communication protocols used and the flow of data through the system.
Once you’ve identified your inputs, you can use a commercially available threat modeling tool like ThreatModeler to generate the outputs. A good threat modeling tool will automatically generate threats based on your architectural diagram and periodically scan your environment for changes that may impact security.
The outputs from your threat model should include the threats themselves, your security requirements, your test cases and CIS benchmarks (if available).
The results generated by providing this information will give developers and the security team an idea of all the potential threats and security requirements to implement in the development stage so that the application is secure. And because threat modeling reveals threats early in the SDLC, technology and design decisions which improve security can be made early in the SDLC. That costs a lot less than addressing security fixes post production.
Summary
Learning threat modeling for a developer is not that difficult, if you leverage what you already know and leverage what already exists. The trick is to take advantage of reusable templates from a centralized threat library, integrate threat modeling right into your CICD pipeline and continuously monitor your environment for changes.
By the way, if you’d like to supercharge your learning, download a free copy of ThreatModelers white papers.
