Empowering Security: Cultivating a Threat Modeling Mindset

Anyone can learn to threat model, and everyone should. Threat modeling is about using models to find security problems. Using a model means abstracting away a lot of details to provide a look at a bigger picture, rather than the code itself. You model because it enables you to find issues in things you haven't built yet, and because it enables you to catch a problem before it starts. Lastly, you threat model as a way to anticipate the threats that could affect you.

Threat modeling for cloud systems expands on standard threat modeling to account for unique cloud services. It allows organizations to further security discussions and assess their security controls and mitigation decisions.

Is the Purpose of Cloud Threat Modeling Different from Non-cloud Threat Modeling?

Cloud threat modeling serves a similar purpose [as non-cloud threat modeling] but does offer additional benefits.

First, cloud threat modeling enables and drives secure cloud adoption. From the onset of cloud technology, more so than with other technologies or changes, security was considered preventative to cloud adoption. Although most of the security-related barriers, such as technology, regulation, or risk, have been lifted or overcome, decision makers still ask the following questions:

• Can I trust cloud services and infrastructure with company X, in a multi-tenant fashion?
• Is it safe to move key business and financial processes to SaaS from our premises?
• Can the cloud offer sufficient privacy and confidentiality controls for sensitive and regulated data?

Cloud threat modeling is a helpful and enabling step in responding to questions such as introduced above. It brings an understanding of threats, assets, and security controls and therefore instills confidence by informing stakeholders and assisting in decisions.

Secondly, cloud threat modeling helps select the most secure, service, deployment, and multi-tenancy model configuration. When selecting service models (SaaS, PaaS, IaaS), deployment models (private, public, hybrid, community), and multi-tenancy environment, the primary considerations are business objectives, security, and regulations. Cloud threat modeling helps determine what threats are inherent to a certain model or design and what controls are available and, therefore, what security efforts are implied as well.

Are the Threats Considered in Cloud Threat Modeling Different from Non-Cloud Threat Modeling?

Threats to cloud systems, applications, and environments are unique. Different technologies such as instance metadata service and cross-account IAM access federation come into play. Different technology and consumption models describe cloud systems. Therefore, different attacks are viable against them and to different impacts and impact gravity than otherwise.

JUST LIKE SECURITY, THREAT MODELING IS A TEAM SPORT…

Why Threat Modeling

Understanding what could possibly go wrong in your system and what you can do about it will increase your trust in what you’re delivering, leaving you free to concentrate on other facets of the system. And that is what’s really behind the need for threat modeling.

Threat modeling is MUST because it will make teams work easier and better in the long term. It will lead to cleaner architectures, well-defined trust boundaries (you don’t know what those are yet and why they are important, but soon you will!), focused security testing, and better documentation. And most of all, it will instill in the team the superpower of security mindedness in an organized, orchestrated way, leading to better security standards and guidelines across different team’s development effort.

What is better?

Is it better to reduce the velocity of an Agile team, or that of a team of hackers who are trying to access your data?        

Secure By Design Principles

The purpose of Secure Product Design is to ensure that all products meet or exceed the security requirements laid down by the organization as part of the development lifecycle and to ensure that all security decisions made about the product being developed are explicit choices and result in the correct level of security for the product being developed.

Security Principles:

• Principle of Economy of Mechanism
• Principle of Fail Safe Defaults
• Principle of Complete Mediation
• Principle of Open Design
• Principle of Separation of Privilege
• Principle of Least Privilege
• Principle of Least Common Mechanism
• Principle of Psychological Acceptability

Learning to Threat Model

You begin threat modeling by focusing on four key questions:

• What are you building?
• What can go wrong?
• What should you do about those things that can go wrong?
• Did you do a decent job of analysis?

Now begins GAME TIME……..

and why Serious Games?

The idea to perform threat modeling on a system using a serious card game as developed by the security department at Microsoft. At its core, threat modeling should be done continuously as part of the (agile) development process. Thus, it should also be done by the developers (Along with Security Architect, Engineers, Practitioners), as they are the real experts on the system.

Microsoft's game allows developers, architects and security experts to find threats to the system even if they do not have a strong background in IT security. It is a threat catalog that guides the player's thoughts to new and unusual perspectives on the system, just as an attacker would do. Gamification makes this a fun thing to do and keeps the players motivated to find creative attacks.

But most important the game will teach the developers to look at the system with security in their mind. Therefore, it raises the awareness for security during implementation, avoiding threats from the start.

Five-step process

• Draw a diagram.
• Use the EoP game to find threats.
• Address each threat in some way.
• Check threat modelling work with the checklists.
• Celebrate and share threat modelling work.

Develope Threat Modelling Diagrams

• Focus on data flow, not control flow.
• Anytime you need to qualify your answer with “sometimes” or “also,” you should consider adding more detail to break out the various cases. For example, if you say, “Sometimes we connect to this web service via SSL, and sometimes we fall back to HTTP,” you should draw both of those data flows (and consider whether an attacker can make you fall back like that).
• Anytime you find yourself needing more detail to explain security-relevant behavior, draw it in.
• Any place you argued over the design or construction of the system, draw in the agreed-on facts. This is an important way to ensure that everyone ended that discussion on the same page. It's especially important for larger teams when not everyone is in the room for the threat model discussions. If they see a diagram that contradicts their thinking, they can either accept it or challenge the assumptions; but either way, a good clear diagram can help get everyone on the same page.
• Don't have data sinks: You write the data for a reason. Show who uses it.
• Data can't move itself from one data store to another: Show the process that moves it.
• The diagram should tell a story, and support you telling stories while pointing at it.
• Don't draw an eye chart (a diagram with so much detail that you need to squint to read the tiny print).

The key thing to remember is that the diagram is intended to help ensure that you understand and can discuss the system. Rmemberthe quote : “All models are wrong. Some models are useful.”

Therefore, when you're adding additional diagrams, don't ask, "Is this the right way to do it?" Instead, ask, "Does this help me think about what might go wrong?"

The main elements of a data flow diagram

Trust Boundaries

A trust boundary is anyplace where various principals come together—that is, where entities with different privileges interact.

Drawing Boundaries

After a software model has been drawn, there are two ways to add boundaries: You can add the boundaries you know and look for more, or you can enumerate principals and look for boundaries.

If you don't see where to draw trust boundaries of any sort, your diagram may be detailed as everything is inside a single trust boundary, or you may be missing boundaries.

Ask yourself two questions. First, does everything in the system have the same level of privilege and access to everything else on the system? Second, is everything your software communicates with inside that same boundary?

What to Include in a Diagram

So what should be in your diagram? Some rules of thumb include the following:

• Show the events that drive the system.
• Show the processes that are driven.
• Determine what responses each process will generate and send.
• Identify data sources for each request and response.
• Identify the recipient of each response.
• Ignore the inner workings, focus on scope.
• Ask if something will help you think about what goes wrong, or what will help you find threats.

Threat Modeling Technologies

• STRIDE
• PASTA
• VAST
• Hybrid Threat modeling
• RTMP
• OCTAVE
• LINDDUN
• Attack Trees

Structured Approaches to Threat Modeling

When it's hard to answer “What's your threat model?” people often use an approach centered on models of their assets, models of attackers, or models of their software. Centering on one of those is preferable to using approaches that attempt to combine them because these combinations tend to be confusing.

Focusing on Assets

There are three ways the term asset is commonly used in threat modeling:

• Things attackers want
• Things you want to protect
• Stepping stones to either of these

Focusing on Attackers

Given a list of attackers, it's possible to use the list to provide some structure to a brainstorming approach. Attacker-driven approaches are also likely to bring up possibilities that are human-centered. For example, when thinking about what a spy would do, it may be more natural (and fun) to think about them seducing your sysadmin or corrupting a janitor, rather than think about technical attacks. Worse, it will probably be challenging to think about what those human attacks mean for your system's security.

Focusing on Software

Good news! You've officially reached the “best” structured threat modeling approach.

Software-centric models are models that focus on the software being built or a system being deployed. Some software projects have documented models of various sorts, such as architecture, UML diagrams, or APIs. Other projects don't bother with such documentation and instead rely on implicit models.

How Long Threat Modeling Exercise should be?

The answer to that varies according to system size and complexity, the familiarity of the teams with the system, skill in threat modeling, and even the culture of meetings in an organization. Some very rough rules of thumb are that you should be able to diagram and find threats against a “component” and decide if we need to do more enumeration in a one-hour session with an threat modeler to moderate or help.

For the sort of system that a small start-up might build, the end-to-end threat modeling could take a few hours to a week, or possibly longer if the data the system holds is particularly sensitive. At the larger end of the spectrum, a project to diagram the data flows of a large online service has been known to require multiple people working for several months.

References

[1] Threat Modeling: Designing for Security by Adam Shostack

[2] https://github.com/dehydr8/elevation-of-privilege

[3] Cloud Threat Modeling by CSA

[4] Threat modeling for builders

[5] Recommended Threat Modeling Tools

I appreciate you reading The Security Chef.

Thanks for reading The Security Chef! Subscribe for free to receive new posts and support my work.