Guiding your security program beyond best practices.

Using threat modeling to drive security priorities.

We have all seen security best practices. There are many of them. Some might argue, too many. Security frameworks provide great starting points for broad objectives and categories of security controls, but none of them really help prioritize your security program. Using a threat modeling approach to risk assessments can.

That is not to say, best practices are unimportant. They are critically important. They help define and structure security programs so that key controls are not missed. They also provide recommended practices that have been developed through decades of security practitioners’ experience.

However, security best practices do not answer the question of: “Where should I focus now?”

That’s where risk assessments come in, right?

Sure, that is usually the right answer. Risk assessments provide a great starting point for prioritization and focus. We all know that resources are limited, and efficiently allocating limited resources is key for a successful security program — or at least a security program that is as successful as possible.

A good risk assessment will help gain context, identify the risks or hazards, evaluate them, and decide on a risk treatment plan.

Simple, right?

Not quite. That’s where having a methodology for performing risk assessments becomes key. There are many risk assessment methodologies out there that can help (e.g., OCTAVE, ISO 27005, NIST 800–30).

Unfortunately, while many security professionals are great at performing a targeted risk assessment on a specific system or process, security professionals are not so great when performing an organizational risk assessment to help prioritize a security program.

Many times they default to performing a security assessment instead of a true risk assessment. That is, they take the universe of security good practices and compare that to their current state. This creates a laundry list of best practices with no indication of where to begin.

There is nothing wrong with a gap assessment to help understand the major holes in a program, but that still brings us back to the initial question of “Where should I focus now?”

There must be a better way.

I am sharing a method that I have found to be valuable in this process. Your mileage may vary.

1. Identify what matters.

We should be prioritizing our programs based on what matters most to our organization, not every control missing from our security program. To find what matters most, asking three questions:

1. What data does the business rely on to make money or achieve its mission?
2. What data would be extremely damaging to the business reputation or cause regulatory action of lost/stolen?
3. What data would be valuable to attackers?

Hint: They are not always the same.

No need to boil the ocean here. Usually identifying less than five categories of data is more than enough to start.

2. Start mapping your attack surface.

Once the key data elements have been identified, start creating high level data flow diagram for these elements. Draw out the components of the environment that contain or touch each of those key data elements identified.

Perhaps your customer data is one your most critical data elements. Where does it come from? Perhaps it is supplied on a customer sign-up form or directly provided to a customer service representative who inputs it into a customer relationship management tool. Where does it go next? Does it get pulled into a data warehouse? Do marketing teams run reports that include it? Does it get re-displayed in a web application that customers log into?

Start with the entry point of the data into the organization and follow it throughout the environment to its final storage location (whether that be your within your own environment or to a third party). Be sure to clearly identify trust boundaries that the data crosses as it flows throughout the environment and other people/process/technology that it touches.

The purpose of this exercise is map out the attack surface and areas where security efforts should be focused. Most likely, there will be a few data flow diagrams created.

3. Define the threat model.

Now that the key data elements and attack surface are mapped out, start thinking about the likely threat actors (i.e., entities) and vectors they would use to compromise this data. Always consider the motive and means behind the threat actors. Try to define concrete threat scenarios that a motivated threat actor would use to compromise your key asset. Again, no need to boil the ocean.

It is critically important to be realistic here.

Yes, it is entirely possible that a nation-state actor will develop an exploit for a 0-day vulnerability they discovered and use it to compromise your lead engineer’s fully patched laptop. But, is that realistic?

Does your threat model include nation-state actors? Would they risk burning an exploit on your organization to gain access to your systems or data?

Maybe yes, maybe no.

You know your organization best, so you should define the most likely threat scenarios. Just remember, there is also such a thing as making a fool of yourself to senior management during budgeting because you do not understand your business context. Whatever you decide, make sure your threat model is realistic.

Summary

Using a threat model to drive your risk assessments can help define strategic priorities for a security program. Make sure to identify the key data elements, map the attack surface, and define realistic threat actors and scenarios to include in the threat model.