Threat modelling has been around since the dawn of computer systems. Wherever there have been computers, cyber security personnel have used models of them to understand what threats they may face. In doing this, they’ve been able to design systems that embed security into their foundations rather than being implemented as an afterthought.
In 2022, threat modelling is common practice for most organisations. They should ideally have application security professionals threat modelling daily and most software developers have at least heard of threat modelling, if they aren’t performing it regularly.
How is Threat Modelling Done Today?
Most threat modelling guides on the internet, the OWASP guide included, will tell you to start with a complete data flow diagram (DFD) of your system. The problem is this paradigm of threat modelling is outdated.
Development teams today use agile development, which means they don’t have a complete picture of their work before starting. Before they start development, there are likely numerous unknowns that may arise during development which still need to be accounted for in a threat model.
But if the development team aren’t sure of future features and implementations, how can the security team complete a DFD of the entire system and being threat modelling?
Challenges With the Waterfall Method
As organisations try to release software at higher velocity and adapt to market influences more rapidly, they have moved away from more rigid models such as Waterfall development to agile methodologies such as Scrum and Kanban. In Waterfall development, the flow of work happens in discreet phases of development such as:
- Requirements
- Design
- Implementation
- Testing
- Production
(Note that the phases may change from organisation to organisation, but the methodology is the same).
The release cycle for waterfall development is measured in months or even years in some cases, which isn’t a good fit for agile organisations aiming for a time scale of days or weeks. This leads to an overly long feedback loop and delays organisations getting their return on investment.
Is There a Better Way to Model Threats?
To align threat modelling with the requirements of organisations today, security professionals need to move away from more monolithic, slower and archaic software development methodologies such as waterfall development. These approaches don’t align with how software development teams work and cause tension with the security team, who expect most of the decision making to be done up front.
Instead, application security teams must work alongside development teams within the same framework and facilitate the development team to secure their software. Any attempt to slow down the development process will result in the security team being pushed out of the development process. To make sure this doesn’t happen we must reduce the scope of our threat models from entire architectures to focusing on ‘in sprint’ code.
By reducing the scope of threat models from big complex diagrams to the same features that the development teams are working on, we can increase collaboration between security, develop and testing. In practice, this lets organisations scope threat models that align with the development teams. For instance, found threats can be integrated into the same boards the development team are using to create a single plane of glass for features, the respective threat models, and test automation.
Should You Move to Agile Threat Monitoring?
Threat modelling has a reputation as a cumbersome, heavy process with a report delivered at the end that gets shelved and never looked at again. But it doesn’t have to be this way. By moving away from older methodologies, such as the Waterfall Method, we can strip away many of the processes which don’t add any value to produce something which can be easily integrated into the development process. (I do this by adopting the agile mantra of YANGI – “You Aren’t Gonna Need It”.)
To start, you should align yourself with the development teams’ processes, add threats as bugs into development team’s boards, and work with the test team to automate the testing of found threats. This creates a re-enforcing feedback loop focused around the threat models of your features where all teams are working together to better the security design of your systems.
Author
Jack Pye
Cloud Security Engineer
Jack is a published cyber security practitioner with over two years’ experience in the DevSecOps space. As a Cloud Security Engineer at Bridewell, he acts a trusted advisor who helps companies build and secure their applications and underlying infrastructure.
Blogs
