Togetherness Threat Modeling
We live in a hyperconnected world where every system, third-party library, or developed piece of code could imply a security breach. This situation is particularly relevant to big companies, like IKEA where I work, where brand reputation is a key factor of success and a way to convey trust to customers. But, what are they doing about it? Threat modeling is one of the pieces of this security landscape and a mandatory requirement for every product in IKEA SSDLC.
According to the Threat Modeling Manifesto:
Threat modeling is analyzing representations of a system to highlight concerns about security and privacy characteristics.
In other words, it is a way to evaluate a system from an attacker perspective. Following this assumption, many questions will probably arise:
- How do we start?
- Who is responsible for threat modeling?
- How do we perform threat modeling in this cybercrime era?
How do we start?
Doing threat modeling over talking about it.
It doesn’t matter if you are an agile practitioner or follow up traditional approaches in your project or product. Threat modeling should be started as soon as possible. Some examples of this starting point could be once you have defined your architecture or have launched a first MVP.
However, all these considerations cannot be initiated without a team that understands the business needs and potential threats from a security and privacy operations perspective. Therefore, take the necessary time to know your team and business needs and go ahead with threat modeling.
Who is responsible for threat modeling?
People and collaboration over processes, methodologies, and tools.
This is a transitive question that follows up others like who is responsible if a security breach takes place in a company?
It is everyone because it will not only affect the product attacked but the brand reputation with all co-workers involved. For this reason, threat modeling and its collaboration between different teams are so relevant in big companies where roles and responsibilities are distributed.
In traditional approaches, security engineers hold as a single representative of threat modeling. These engineers had to act as a bridge between the different teams across the company and identify the main business needs and their threats in terms of security or privacy.
Thanks to the threat modeling manifesto, this approach is more focused on a togetherness value where engineering, data, product, UX, security, and privacy teams act as a single one. All of them will be part of the threat modeling in any iteration and thus will be responsible to protect against attackers.
It’s possible that some questions arise regarding team autonomy. However, the need to call security or privacy experts in every iteration is not a mandatory requirement but it requires some time to reach the desired autonomy.
Once again, Threat Modeling Manifesto comes with the following value:
A journey of understanding over a security or privacy snapshot.
This is also one of the most important values of this approach because it allows companies to grow at scale by creating a strong security awareness from business needs not only technical perspectives. The first step will require the know-how from these experts but, as time passes, the rest of the team members will get the necessary autonomy and confidence to take their own decision and only request help from these experts in some special or hard scenarios.
How do we perform threat modeling in this cybercrime era?
Continuous refinement over a single delivery.
Let’s think like a software engineer within the software development lifecycle. We start evolving, in small and fast iterations, a basic concept or idea until it reaches a minimum viable capability and success by launching to market as soon as possible.
Why couldn’t we do the same thing with threat modeling? this approach aims to address this question.
In order to reach this goal, we need to create a solid foundation to work on. In this case, the first step will be threat modeling as code approach that allows adapting the threat modeling and its product to the emerging threats in a way that is contextually relevant and prioritized.
Furthermore, there are some extra points to use threat modeling as code:
- Establish a single methodology for the entire organization avoiding misunderstandings within the teams.
- Keep track of the changes and their motivations by hosting code into the default SCM (i.e. Github.com, Gitlab).
- Allow cross-collaboration between teams with common SCM practices like issues or pull requests.
In the next article, we will cover deeply threat modeling as code with some examples. Stay tuned!
