Sparked from a question on our public discord channel https://discord.gg/HeHuehh
What does GRIMM's threat modeling process look like? Is it only used in the design phase of the Software/System Development Life Cycle (SDLC), or can it be applied to systems already in production?
We use the Trike methodology on account of it's friendliness to people who are not security experts. Like most threat modeling methodologies, it is most efficient when it's used even earlier than design: at requirements phase of the SDLC. When there are requirements like "no need to set up an account" and "make sure user-entered data is kept confidential" it is really difficult for anyone to implement that in a way that isn't going to surprise some of the business people down the road.
What information are we talking about here? Does this include things like usernames, or is it just things like email addresses and phone numbers? From whom should it be kept confidential? Should my name be kept confidential from friends on the system? Should the system prevent administrators of the server, database, or cloud that it's hosted in from seeing this info? Getting these things clearly established is pretty important, and Trike helps get everyone on the same page. This can be done after the product is already deployed at well. In fact, some of the analysis is easier, because there's already a concrete system in place which is not constantly changing. However when people find out their systems aren't providing the level of protection that they want, it's a lot more effort to make changes on systems that have already been deployed.
During threat modeling engagements, we want to make it clear to everyone (product owners, managers, developers, operations, etc.) that threat modeling is an ongoing process. It's not something you do at the beginning and never look at again. Every time a feature is added that changes who can access what, it should go through the threat modeling process to make sure everyone is on board. It's more planning and coordination up front, but less time spent re-doing things or having to patch weird edge cases that weren't considered.
The Trike project describes it best, but the oversimplified explanation is we figure out who are the actors, what are assets within the system, what are the intended actions of the system, what are the rules that governed the intended actions. From the Trike original whitepaper:
An actor is a human being who interacts with the system in some way. Actors must interact with some part of the system which is in scope for the threat model.
Assets are normally discrete data entities, but sometimes physical objects, which feature in the business rules of the system. Assets are things which are inherently meaningful in the problem domain of the system, not merely in the way the system is implemented.
Actions are things which actors do to assets. The intended actions demonstrate what the system was designed to accomplish, where are the functional requirements to denote how the system should accomplish those actions.
Some of the questions we explore include:
- What privilege levels exist? (i.e. who uses the system, including roles who you don't really want to use the system like "anonymous internet user" but they can)
- Determine what the system needs to defend against? (e.g. should an admin be able to see or manipulate everything?)
- Defining what things need protecting and from whom, and then going through the architecture to determine if this is happening in theory (e.g. in the design).
Once the threat model is done, we have a map of all of the places where there could be security issues. Implementation review checks two things: does the implementation match the design, and were there any programming errors that are going to cause a security incident. For example, analyzing functions to see if authentication flows match what was depicted during the threat model. We do this for all use cases, of which authentication is merely one. For any notable findings along with mitigation recommendations are provided to the product owners for evaluation.
The output of the Trike threat modeling process is a complete understanding of the system, its actions, actors that interact with it and understand the risks associated with it. This is an ongoing process and should be revisited with configuration changes or upgrades of the system. If you need assistance with threat modeling systems you built, or rely on, feel free to reach out to us!