Are you or your colleagues writing code? Then we hope you are also thinking about how to make that code as secure as you can. Cyber threats have three dimension:
- A value that can be exploited (leaked, changed, made unavailable)
- A vulnerability that makes exploitation possible (a software bug, a design flaw, or a user being fooled by social engineering)
- A threat actor who is motivated to perform the exploitation
Of these three, we can only really control the vulnerabilities. There are two sources of technical vulnerabilities; design flaws, and implementation errors. In software engineering, there are many tools that can help find and fix implementation errors (debuggers, linting, static analysis, and so on). Running security tools during the build process is very helpful – but it will not solve every problem.
In fact, only 50% of vulnerabilities in software will typically come from implementation errors. The rest of them are design flaws:
- Have we implemented the right functionality?
- Can the functionality be used in more than one way?
- Have we limited access to the functionality in the right manner?
These things are not possible to catch as part of the build process. Luckily, we are not left completely helpless; there are other tools we can turn to.
- Threat modeling
- Software testing
Many software developers are well versed in the benefits of testing, such as unit tests and integration tests. A lot fewer have really engaged in threat modeling. These two things help us with two things. Threat modeling is here to help us find out what kind of scenarios we should protect against, and to find remedies to protect against the types of attacks we have found. The testing is to check that the security features work as planned, and to verify that all functions are performing as expected with respect to their inputs and outputs.
So, what is a threat model? A threat model seeks to find ways a threat actor or a hacker could attack the software, and then to find measures against it. In theory this sounds all good, the only problem is that for most engineers and developers developing a threat model is quite hard. We are trained to design functionality, not how to destroy or abuse functionality. This means that the threat modeling activity requires quite a significant shift in mindset for most developers; you have to think like the criminal instead of like a creator. To achieve this, we need some tools, or some framework to move ahead with this. If you go ahead and google “threat modeling methodologies” you will find a lot of different approaches, quite a few of them may seem quite academic and complicated. They may be excellent methods for experts with a lot of time on their hands and specialists to help with analysis; most organizations don’t have this at their disposal. Choosing one of the simpler methods described in the literature, or in supporting tools for threat modelling, will generally give you variations of the following approach – that we agree is the natural flow of thoughts here:
- Define the threat context (who are the attackers, what are our values, what would they seek to obtain)
- Create a data flow diagram describing how the software works. This should preferably be on a high level, but detailed enough that discussions around technical attack vectors are meaningful. Typically, nodes in the diagram will be classes or functions in your code.
- Apply guidewords to guide a discussion on threats. This can be done by a single person, but preferably do this as a group activtiy and run the scenario identification as a brain storming session. Don’t evaluate credibility at this stage; the goal is to capture potential threats!
- Evaluate the threats based on the threat context according to the risk they pose. Remember that risk is the combination of probability/credibility and severity of the outcome of an attack!
- Plan mitigations. In most cases these are software artefacts that you can add to your backlog or requriement specification – and then treat with the same software QA tools as the rest of the project. Security is now a feature!
Cybehave can provide engaging training on threat modeling reinforced by practical hacking exercises for you developer teams. Contact us at email@example.com if you want ot hear more about this.