Any service can face a number of threats. A way to surface these is to run through a threat modelling assessment. Running through the process can help to prioritise and make decisions based on data the output gives us.
There are many different ways to perform threat modelling but the previous method I had experience with was to remove all the controls, assess a threat then define the controls to mitigate the threat. This is not a trivial piece of work that includes using security professionals, deconstructing the product and assessing the importance of the data it processes or holds.
The team I had joined needed an overview of the platform, it had been securely architected but a threat model had not been done. Building a new platform with many features still needed a formal threat model process which would have taken too much time. We needed a way that could be completed by our team and not take more than a sprint (2 weeks).
The method we used defined the assets, and the actors linked them with a threat and assessed against the current platform, with the controls it already had in place.
Assets
Anything we want to protect - including personal data held, credentials or keys. leaving items left on whiteboards or a notepad on your desk. Representational damage to the MOJ or Government.
Actors
A person, organisation either external or internal who causes harm to the information system which is intentional or unintentional. These range from being targeted to an employee who is trying to find a work around.
Threats
The STRIDE framework
- Spoofing: Authenticity - I am not who I say I am.
- Tampering: Integrity - changing the data, code or anything that can be changed
- Repudiation: How valid the data is - changing logs to cover up errors or something that has been saved
- Information Disclosure: Confidentiality - Personal information leaks - exposed credentials or secrets
- Denial of Service: Availability - DDOS - Breaking code changes, anything that stops it working
- Elevation of Privilege: Authorization - incorrect controls - old credentials still working
We linked up the threat and provided a narrative/ user story to a spreadsheet to record them.
Ranking the threats, by calculating a threat score by multiplying the severity of the threat - how much damage would it do against the probability it could happen.
| Severity | Probability |
| 0: No impact | 0: Impossible |
| 1: Minor Impact | 1: Highly unlikely |
| 2: Significant Impact | 2: Could happen |
| 3: Critical Impact | 3: Likely to be attempted |
This provides a list of threats which have been scored and in an order.
The next part is to decide what we do with the threats we have found.
We used the following list:
- Fix it - Add a story to be fixed as soon as possible.
- Future fix - Add a story to the backlog to be fixed when it can be scheduled
- Monitor - Keep an eye on it, if the risk needs reassessing later
- Tell people about it - Add to the user documentation and let the right people know
Now to put that into context by running through a threat for the product I am working on.
MoJ forms lets you create and publish digital forms without needing developer skills and not starting from scratch. All data is treated as Official-Sensitive Personal.
- Actor: Form Owner
- Assets: Representational Damage
- Threat: Repudiation
- Narrative: Form missing basic auth and new policy accidentally leaked
- Score: 4 (significant impact * could happen)
- Decision: Tell people about it
- Ticket: Default publish to test will enforce basic auth and documentation to be updated explaining the risk.
- Done: Feature added that forms published to test must have basic auth enabled and user guide updated.
After running through this process a few times my views are that it was quicker and more lightweight, completed during just one sprint (2 week cycle). The whole team was involved which gave better coverage, not just technical threats.
This made the creation and prioritisation of work packages simpler, the what and why had already been explored. We have a living document to refer to and add to when a new feature is designed and developed.
What could be improved? The first session was gruelling, we started with a blank page. Luckily we had some experience in IA and pentesting to fall back on. Saying that, some example threats to talk around first would have made this easier. Not just focus on the technology, consider shoulder surfers on the train or leaving things on a whiteboard in the office or meeting space. Everything should be considered that interacts with the product.
It doesn't replace the full threat modelling session and we know it doesn't cover everything, but gives us a greater understanding and that is better than not doing it at all.
Tips!
- Do a presentation upfront to the team so they know what is expected
- Follow an agenda... It is easy to stray and tell cyber stories
- What's best to work with - in person with colourful paper sticky squares or a remote tool.
- If it is a remote tool, have a practice using the software before the session
- Examples. Lead with an example. But, this is two edged as this can fix the discussion around the one threat and not move on
- Invite colleagues from Cyber Security - they add value and it is their expertise
The resources available to you