I say today is a good day for two reasons:  1.)  BT’s CSO Jill Knesek wrote an article called “Keys to establishing an end-to-end security strategy” which begs some discussion within context, and 2.)  Sara Peters on Twitter last night wanted to know why I thought “risk management” requires more than what most “best practices” around the subject suggest the effort requires.

WHAT SHOULD WE BE REFLECTING ABOUT?

Jill Knesek’s article gives us a rough outline of how to develop a security strategy.  It’s fairly high-level, Pragmatic CSO-ish type stuff.  It gives us a nice outline of

• Get a seat at the table
• Process
• People
• Technology

Nothing earth-shattering there.  But it is a very nice broad CISO-level taxonomy about what we have to reflect on.  The need to reflect is driven by something Jack told me long ago,

“The amount of risk we have is a function of the decisions we made and our ability to execute on them from some point in the past”.

As an Aside:  So Sarah if you’re reading, this quote does much to explain why I said I disagree with much of what our industry calls “risk management”.  We tend to define the process of risk management as essentially a tactical “issue whack-a-mole” exercise. Find the issue.  Analyze the “risk” around the issue.  Fix the issue.  Repeat. This hamster-wheel-of-pain, while sometimes an effective tool for the CISO, is incongruous with addressing root causes (the ability to match a tactical issue to the strategic shortcoming that created the issue is up to the expertise of the analyst or consultant).  It is only Kaizen without (good) Hansei, if you will.

Back to what Jill is writing - the sorts of things we should be reflecting about can be thought of in context of her outline.  Namely:

1. Once you have a seat at the table, what is the nature of that relationship?  Who are you reporting to and what are their concerns? What and how are you reporting and how might that be addressing their concerns?
2. What processes are in place?, How do you know that those are the processes that should be in place? If they are, what kind of job am I doing at those processes?
3. What is the quality of the skills and resources I have from a people perspective, and how do I know if they are adequate?  How do I know that the training they petition me for will effectively reduce organizational risk?
4. Are the Technology solutions I have in place effective, are we managing them effectively, and what sort of States of Knowledge could they provide me with (to make good decisions and execute upon them, from above)?

This, for the CISO, is Hansei.  The continuous management of it is Kaizen.  Not to particularly pick on Jill’s article, but creating a “risk register expressed in ALE” might be fine if you’re trying to explain to the board what your “first 100 days in office” will be like - but these sorts of lists are usually not very strategic in nature, and as such, depending on the outcome of that risk register (and the models used to create it) it might not actually be useful.

WHAT IS NEEDED FOR REFLECTION?

So what is needed for this sort of CISO-level Hansei?

The CISO must understand the

• Current State of Nature

turn that into a

• State of Knowledge

and use that to create a

• State of Wisdom.

CREATING A STATE OF NATURE FOR THE IRM PROGRAM

This Current State of Nature determination be done by applying analytical methods to a program audit.  We must understand questions like,  “What is in that program and how is it structured?”  before we can answer questions about “how (good/bad) are we at managing risk?”

There are many ways to structure an IRM program, but as an example - below is a graphic shared with me by Adrian Seccombe.  For those who know Adrian and the Trust Model - this is classified as “white” so it’s OK for public display and consumption.  But here’s what Adrian is trying to build at a high level:

So regarding Adrian’s program diagram:

1. Is a governance framework.  Think ITIL.
2. Is a risk framework.  Think ISO 27002 using FAIR as an analytical engine.  To be fair (pun) I believe this is really issue management, and it’s a process, but that’s OK.
3. Reg compliance should be self explanatory.  That’s essentially what GRC products do for you.
4. With architecture, I think Adrian is inclined towards TOGAF.
5. Security is the ISMS in place (27001, ISM^3, PCI, whatever…)
6. Are the processes that drive execution
7. Monitor (audit) is creating a State of Nature and Evaluate is creating a State of Knowledge from that State of Nature around items 1-6.

EVALUATE - CREATING A STATE OF KNOWLEDGE ABOUT THE IRM PROGRAM

That evaluate is Hansei/Kaizen.  Evaluation, done effectively, will drive actual organizational risk exposure.  Evaluate will even answer those four questions we raised in the “What Should We Be Reflecting About” section above:

1. Once you have a seat at the table, what is the nature of that relationship?  Who are you reporting to and what are their concerns? What and how are you reporting and how might that be addressing their concerns?
2. What processes are in place?, How do you know that those are the processes that should be in place? If they are, what kind of job am I doing at those processes?
3. What is the quality of the skills and resources I have from a people perspective, and how do I know if they are adequate?
4. Are the Technology solutions I have in place effective, are we managing them effectively, and what sort of States of Wisdom do they provide me with (to make good decisions and execute upon them, from above)?

If we could have a nice metric (or set of metrics) that answers these questions, we might call it something like “My Ability To Manage Risk” or MATMR for short.

GETTING TO A STATE OF WISDOM

What’s then missing is how you create a State of Wisdom around the State of Knowledge developed - your “MATMR” metric.  That is, given the current State of Knowledge - how can I be most effective?  This State of Wisdom requires proper models for what risk is, and what you can do to manage it applied in a probabilistic manner (because we can’t intrinsically *know* the future, we can only say with some degree of certainty what the desired course should be).

So the outcome of Hansei/Kaizen should be to create a State of Wisdom about Risk Management.  This is why reflection must be relentless - because your wisdom must be similarly abundant.

This is no small part of the reason RMI exists, why we build software and help organizations understand the things they do.

Not bad. I actually managed to get a good night sleep.

Click here to subscribe to Liquidmatrix Security Digest!.

And now, the news…

1. Google and Wildcard Domains | GNUCITIZEN
2. Trojan plays anti-China games for hacking | The Economic Times
3. Villains Getting Smarter: Are We, Too? | Korea Times
4. Agency Sees Theft Risk for ID Card in Medicare | NY Times
5. Universities urged to tighten computer security | The Arizona Daily Star
6. Organised e-crime targets students for recruitment | ZDNet UK
7. Time to dismount the hamster security wheel of pain | The Regsiter
8. New security awareness posters aid the battle | Cambridge Network

Tags: News, Daily Links, Security Blog, Information Security, Security News

I was out in Colorado today. I filled up with gas before returning the car and paid $3.39 for regular gas.  When I landed in West Palm Beach I had to put gas in my car on the way home and paid $3.49 for regular.  When does this stop?  Is it really going to 4 bucks a gallon soon as they say?  Why stop there, 5, 6 7 bucks a gallon?  What is it going to take for us to finally say enough and do something in this country about getting off the black heroin?

So busy talking about the war, mortgages and the stock market, why aren't any of the major candidates putting out detailed plans on how we are going to move off of oil and gasoline hamster wheel that is a monkey on the back of each and every one of us.  I am fed up and not going to take it anymore!

I was out in Colorado today. I filled up with gas before returning the car and paid $3.39 for regular gas.  When I landed in West Palm Beach I had to put gas in my car on the way home and paid $3.49 for regular.  When does this stop?  Is it really going to 4 bucks a gallon soon as they say?  Why stop there, 5, 6 7 bucks a gallon?  What is it going to take for us to finally say enough and do something in this country about getting off the black heroin?

So busy talking about the war, mortgages and the stock market, why aren't any of the major candidates putting out detailed plans on how we are going to move off of oil and gasoline hamster wheel that is a monkey on the back of each and every one of us.  I am fed up and not going to take it anymore!

The brainstorming meeting is a mainstay of expert threat modeling. It’s pretty simple: you put your security experts in a room with system diagrams and a whiteboard. Usually, you put your system designers in there, and make them promise not to strangle your experts. Optionally, you can add beer or scotch. Sometime later, you get a list of threats. How long depends on how big the system is, how well its requirements are documented, and how well your experts work together.

We like having our developers threat model. There are a lot of reasons for this. Not only do they know the system better than anyone else, but getting people involved in a process helps ensure that they buy into it.

Now this desire is great, but it leads to some issues, first and foremost is that many of the people who are now involved aren’t security experts. This means that they lack both direct experience of the process and the background that informs it. This isn’t a slam on them. I lack experience in the database design process, and I don’t have years of experience to help orient me. So I’d make mistakes designing a database, and someone who isn’t a security expert may make mistakes in security. For example, someone might try to use encryption to mitigate tampering threats. (The SDL crypto requirements cover this, and I try to gently correct them to integrity mechanisms like MACs or signatures.) This is a reality that we have to account for at the process design level.

Adding Structure to Chaos

So how does this relate to the brainstorming meeting? It’s a dramatic increase in the need for structure. Where experts may think they do better threat modeling with scotch in hand, , it certainly doesn’t lead to beginners having a flow experience. So we need a structure, and we need to provide it.

We encourage people to get started by drawing a whiteboard diagram. Almost everyone in software draws on whiteboards regularly, and this makes it an ideal first step. It’s an ideal first step because everyone can do it, see that they’ve done it, and feel like they’re making progress.

The core mechanism we’ve used to provide it is the STRIDE/element chart. (I’ll talk a lot more about its origins and limits in a few posts, but for now, let’s pretend it’s gospel, and enumerates all possible threats.) Given this gospel, it becomes possible to step through the threat modeling diagram, “turn the crank,” and have threats come out. “Item 7 is a data flow? Let’s look for T,I and D.” (Tampering, Information disclosure, and Denial of service.)

Similarly, we have four ways of addressing threats – redesign, standard mitigations, new mitigations, and risk acceptance. We have training on mitigating threats, we have explanation of why and when to use each (and they’re presented in a preferred order).

Lastly, we provide advice about how to validate the threat model and it’s relation to reality.

Between these four steps and the hamster wheel which ties them together, we give people the structure in which they can take on the process. The other thing I wanted to address is how we respond to consistent “errors” that we see.

Where Trust Boundaries Show Up

We used to give people clear guidance that trust boundaries should only intersect with data flows. After all, you can’t really have a process that’s half-running as admin, and half as a normal user. Logically, you have two entities. And people kept drawing trust boundaries across processes and data stores. It drove me up the wall. It was wrong.

As people kept doing it, I decided to swallow my pride and accept it. I now tell people to put their trust boundaries wherever they believe one exists. And they’ve continued exactly as before, but I’m a lot happier, because I’ve found a way to help them draw more detailed diagrams where they need them. Which includes anywhere a trust boundary crosses a process or data store. They’re happier too. No one is telling them that they’re wrong.

I was going to title this post “Lord grant me the strength to change the things I can, the courage to accept what I can’t, and the wisdom to know the difference,” but, first, it’s too long, and second, if we started that way, it would be wrong to add beer or scotch.

One of the largest changes that we’ve made is to a simplified process (and diagram). I like to say that this looks pretty much like every other software process diagram you see today. That’s intentional. There’s only so much we can expect people to take away from a class, and making this simple and familiar helps ensure there’s room for the other important parts.

First, the “process hamster wheel,” (with apologies to Yankee Group analyst Andy Jaquith):

Now that you’ve seen the wheel, I’ll briefly describe the steps:

1. Vision: Consider your security requirements, scenarios and use cases to help frame your threat modeling. What are the security aspects of your scenarios? What do your personas expect or hope doesn’t happen? What are the security goals of the system you’re building, and how do those interact with the system as it stands?
2. Model: The basic idea is to create a diagram of your software, showing all trust boundaries.

a. Draw a diagram of your software. We encourage use of the DFD formalisms, which Larry Osterman describes in this post.

 

Essentially, the elements are

1. External entities (anything outside your control)
2. Processes (running code)
3. Data stores (files, registry entries, shared memory, databases)
4. Data flows (which connect all the other elements)

b. Draw trust boundaries between components. You can do this on a whiteboard, in Visio, or in one of the specialized threat modeling tools we’ve built. (A trust boundary is anywhere that more than one principal can access an object, such as a file or process.)

c. If your trust boundary crosses something which isn’t a data flow, you need to break it into two logical elements, or draw a sub-diagram with more details. (This is different advice: we used to tell people trust boundaries could only cross data flows. People drew them anywhere that felt right. We decided to go with what people were doing—there was important information in what they were expressing.)

d. If you need more details to express where trust boundaries are, add an additional diagram.

e. When you don’t have any more trust boundaries to draw, you’re done.

f. If a diagram doesn’t have any trust boundaries, you may have drawn too many details.

3. Identify Threats using STRIDE/element

For each element in your diagram, consider threats of the types indicated in this chart. (We’ll come back to the chart’s origins in a later post.)

There’s an important mis-conception we often see, which is that STRIDE is appropriate for use as a classification system. It’s really hard to use STRIDE to describe attacks—the impacts blend together really quickly. The most valuable use of STRIDE is to help people think about how threats have impacted elements of a design in the past. That is, it’s a framework for finding threats, not for describing them. “What if someone spoofs this host?”

 

4. Mitigate

Here on the SDL strategy team, we love threat modeling. We know that not everyone feels that way, and we ask teams to threat model so that they can find and mitigate threats. A threat model document with great diagrams and lots of threats isn’t very useful if you don’t take the key step of addressing the issues you find. There are four ways to do that:

a. Redesign to eliminate threats.

b. Use standard mitigations, such as those provided by OS features, to mitigate threats.

c. Invent new mitigations, understanding that this is a subtle art.

d. Accept risk, when allowed by the SDL

5.  Validate

There are two levels of validation. The first is within each stage, the second is a validation pass at the end of the process. That end of process validation entails:

a. Make sure that the diagrams are up-to-date and accurate

b. Ensure that you have STRIDE threats per data flow that crosses a trust boundary, and for each element that such a trust boundary connects to

c. Make sure you’re mitigating each threat

i. You have a bug filed per threat that you want to mitigate. The bug should be of the form “attacker can do X. Proposed fix: Y.” You might include tradeoffs you’re making, and possibly have test plans in the bug, if you include those.

ii. You have a valid reason for each non-mitigated threat not being mitigated.

iii. All threats are in class i or ii.

5.a. On change, re-validate

 

This hamster wheel has a very intentional brake on it: the word change, above validate. What that means is you want to go through the process again when you make changes that need to be on the diagram. Checking to see if your diagrams change is a relatively simple check that allows people to track changes against their threat model as their design iterates.

In the next post, I’ll talk about the reasoning behind the design, and offer up some process tools that anyone can use to make a process more user-friendly.