This is the first installment in a three-part series on threat modeling. For the full story, read part 2 and part 3 as well.

Have you ever been in a position where you are expected to secure a complex system long after it has been designed and fully functional for a few good years? Or maybe you have been tasked to secure an organization that has never before taken cybersecurity seriously? If so, you are probably familiar with the initial frustration and the nagging question, “Where do we start?”

Although there is no universal answer to this question, here is a possible approach to focus your efforts on threat modeling. This article aims to equip you with basic understanding of why you prioritize this security activity and how to begin the process.

What Is Threat Modeling?

There are several widely used definitions for threat modeling. I prefer the one provided by Adam Shostack in his brilliant book, “Threat Modeling: Designing for Security.” He said, “Threat modeling is the use of abstractions to aid in thinking about risks.”

Shostack’s definition draws attention to the ultimate goal of threat modeling: risk identification and prioritization.

Identifying and Prioritizing Risk

Organizations traditionally tend to focus on vulnerabilities and controls prescribed by different frameworks (ISO 27001:2013, SANS CSC 20, etc.) when identifying and prioritizing risk. While the approach has its place, it has serious drawbacks in that it:

• Addresses only known problems in a reactive manner;
• Addresses problems superficially; and
• Often results in overspending on controls with questionable effectiveness.

Don’t get me wrong — I’m not implying that your organization stands to gain nothing by implementing critical security controls. It could be very expensive and difficult, however, targeting controls that might not provide added value to justify the cost.

With the proliferation and widespread adoption of threat intelligence technologies, most enterprises are trying to adopt a threat-focused approach to their risk management. In this context, threat modeling is drawing more and more attention.

Benefits of Threat Modeling

Threat modeling can help you generate a list of prioritized threats applicable to the system you are analyzing. It can also inform the risk management process. In addition to this obvious benefit, there are some not-so-obvious advantages you can draw from threat modeling.

Visibility

In my career, I’ve been fortunately to work on several projects in which the clients were building their security programs from scratch. In such environments, one usually faces the challenge of dealing with well-established systems that are critical to the business but built without much security consideration.

Very often these are legacy systems supporting core business functions and featuring a high level of complexity. Sometimes these systems have no documentation. Threat modeling can help a great deal with clearing out the white spots on your IT environment map.

The threat modeling process requires building an in-depth understanding of the different system components and how they fit together. Going through the process will force your organization to:

• Identify its assets.
• Document the system architecture or update the existing documents (producing at least network and interaction diagrams).
• Build a better understanding of how the different subsystems are connected and how they interact.

Increased Security Awareness

You cannot devise an adequate enterprise security model alone. Your success will depend highly on the involvement of other peers and teams. You will need their expertise to devise a more complete knowledge base around how the system works and to identify the relevant threats.

The threat identification process could trigger useful discussions about vulnerabilities and different exploitation vectors, ultimately raising the level of security awareness across the group.

Prioritization of Security Controls

In our practice, we often find that the clients are trying to implement commonly prescribed security controls without taking into account the specific enterprise context. Penetration testing, for example, is a commonly misunderstood and prescribed assurance activity that will add little value in certain enterprise contexts.

Ultimately, threat modeling output supports the enterprise risk assessment initiative. A well-developed threat model informs the control selection process and puts it in the context of the system-specific threats.

That’s why prioritization of the security control implementation is probably one of the most obvious benefits the enterprise can gain from threat modeling. It allows your organization to:

• Measure the effectiveness of the security controls in the context of specific threats; and
• Focus the control implementation and vulnerability remediation activities to those adding the most value.

A Better Understanding

Threat modeling provides solid ground to build a better understanding of the possible attack vectors. While no threat model is complete, it can be a good foundation for planning and executing different assurance activities (such as vulnerability assessments, penetration tests, etc.) if devised properly.

As part of my work within X-Force Red, quick threat models proved invaluable in devising an attack strategy, and scoping and delivering an assignment. Security assessments are bound by time, so it is imperative to focus on what is important.

I recommend drawing a simple threat model before engaging with penetration testing tasks. It helps to focus on the meaningful attack paths. You could also use it while brainstorming ideas with your colleagues to improve your out-of-the-box thinking.

Threat Modeling Tips

Devising a threat model of your enterprise system can be daunting. Here are some tips to save yourself some pain.

No ‘I’ in Team

As mentioned above you cannot do it alone. I would advise you to:

• Gather and review the available system documentation prior to commencement.
• Establish a work group composed of subject-matter experts — experienced people that design, use, support and manage the system.
• Discuss the system architecture.
• Document your discoveries and observations.

Slow and Steady

Threat modeling a complex system is a time-consuming exercise and requires a lot of planning and coordination. Don’t get disheartened; remember that your work group probably includes people with no formal threat modeling training, and they likely have their own workloads and operational priorities outside of the threat modeling effort. Give everyone enough time to consider the discussion and support wherever necessary with the appropriate amount of guidance.

Stay Focused

Keep your eyes on the scope, because it could very easily creep. Make sure that you have the level of detail you want to address in advance. If you have reached it, do not go further. Moderate the work group discussions accordingly to save time and keep all participants focused.

Follow the Data Trail

It’s hard not to get lost when dealing with complex systems comprising multiple interconnected subsystems relying on different technology stacks. It’s also not easy to answer the question, “Where do we start?”

There are different ways to build your threat model, and there is no magic, one-size-fits-all solution. Throughout my career, I’ve found the most success in threat modeling using data flow, because:

• The attacker needs to interact somehow with your system directly or indirectly, so following the data is usually a good idea.
• Data flows are perimeter agnostic and rely on the concept of trust boundaries. The modern enterprise rarely has a well-defined perimeter anyway.
• Some primary security concerns relate to sensitive or data privacy leaks, data corruption and loss, or denial-of-service (DoS) related to data access.

Go With Your Gut

I would encourage you to follow your common sense and trust your experience. No one else knows your environment and its peculiarities better than you do.

Learn more about X-Force Red and IBM’s specialized pen testing services