Lots being written about the Cloud, most of it quite dark and gloomy.  In fact I’m surprised, that Hoff hasn’t got a preso spooled up called “The Toxic Cloud” or something similarly ominous for his next speaking tour.
That said, the Economist does a great job distilling the issue into a simple statement -

Cloud computing is a trade-off between sovereignty and efficiency.

Let me ask you -  if you had to put your money on one of those horses, considering your average profit-preoccupied business, which would it be?  I’d put my bottom dollar on the thoroughbred named “Cost Center Reduction”, to place.

WHO ARE WE TO STAND IN THE WAY OF “PROGRESS”?

I’m always fond of Jack’s rule that the role of information risk management boils down to three deceptively simple premises:

• Reduce Risk.
• Reduce Loss.
• Create Operational Efficiencies.

So it would seem antithetical to the charter of the Chief Security Officer to stand in the way of progress as embodied by “cloud computing” (not to mention dangerous to long-term job security).  And I think that this presents opportunities to discuss strategies for managing risk, strategies that aren’t too theoretical and have practical application (though actual “cloud” use by enterprises may be rare at this point).

ON RISK REDUCTION IN THE CLOUD (or, How To Learn From the Shortcomings of PCI DSS)

The good news is, there’s already a well-established model for managing the risk around outsourcing the processing of “confidential” information.  The bad news is, that model kinda sucks it.

The Payment Card Industry, known as the “PCI” or “meal ticket” to many in the industry, faced a similar problem with the introduction of GLBA.  As I see it (and I’m not at all close to the PCI, at all, so this is all just abstract soliloquy) the PCI had one of two choices when faced with the prospect of other people managing their sensitive information:

1. Accept the *massive* amount of GLBA risk their business creates and spend a TON of money to build out the infrastructure (both process and IT) to manage the consumer data themselves (in conjunction with the banks, of course) and never have it grace the computing systems of the retailer.  Or,
2. Transfer the GLBA risk down to the retailer and have them bear the majority of the risk (and cost of reducing risk to a level that might be tolerable to the US Government).

(Martin, you may recall our Twittering about PCI a while back.  This is the crux of my view on the subj.)

Now fortunately, the CSO’s of the world are going to be a little more “invested” in protecting the information they are stewards over, and unlike the PCI, will remain primarily responsible for the C, I, & A of the data in the Cloud.  The cool thing is, this actually presents a great opportunity to start building a meaningful model for co-management of risk!  In fact, we can take the PCI model of contractual risk transference but modify where it goes all wrong, and start working to create something better.  And we can start by euthanizing some faulty assumptions.

JUST HOW INFORMATIVE IS PCI DSS?

What might be the.greatest.mistake of the standards compliance mentality is the assumption of value for the past-state measurement.  That is, I believe that the CSO needs more than some “past-state” assurance in order to understand their risk.    If you look at the concept of “PCI compliance” it really is an examination of a past state of nature that is assumed to be relevant to current and future states.   Many people (myself included) are not at all convinced that this past-state is nearly as informative as those who mandate it’s measurement believe it to be.

That’s not to condemn past-state measurements as completely non-informative,  they most certainly are useful.  It’s just that no self-respecting CSO sleeps well because they were deemed “PCI compliant” 10 months ago.  They sleep well because they have good visibility into current-state information and confidence in their strategy concerning future-state (based on that visibility and the outcomes of sound IRM models).

MOVING PAST THE VULNERABILITY SCANNER INTO INTELLIGENCE AND WISDOM

So realizing this new importance (to me, at least) concerning visibility and IRM models, I’m lead to the conclusion that if we are to manage risk in the Cloud, we’ll have to move beyond “PCI Compliance” or the concept that some regular “audit” of controls in place at the host is all we need to understand our ability to manage risk.  No, the CSO must have good information concerning current and probable future states.   This is that “visibility” I spoke of above.  In fact, we’ll need significant amounts of piercing, transparent visibility.  And in order to gain that visibility, our insight into Cloud Risk Management must include significant provisions for understanding a joint ability to Prevent/Detect/Respond as well as provisions for managing the risk that one of the participants won’t provide that visibility or ability via SLA’s and penalties . These SLA’s must be expressed in measurable terms (more visibility), and those metrics must have their roots in the things that help understand how we manage risk (those aforementioned IRM models).

THE CLOUD COMPUTING SECURITY SILVER LINING (sorry couldn’t resist)

As I mentioned earlier, I do see an opportunity to create insight.  The need for visibility and IRM models would allow us to create a “guidance” if you’ll allow me to use the term.  Not a standard or a “best practice” to audit by, but simply a reference document that says “if you’re going to put information on somebody else’s systems and still hold some significant responsibility for that information, here’s the considerations, why they are considerations, and how you might go about collaborating on the management of risk”.

And I think that if we undertake this journey, there is going to be a lot of growth and risk management innovation along the way.  But keen insights into what it means to manage risk will be necessary, and secure and forthright collaboration will be of absolute importance.

I say that last bit because, if these pundits are right about the utility of a hosted computing model - the Cloud will happen regardless of the CSO’s ability or desire to manage it.

In a blast from the past, Sybase is aiming to be your mobile phone security provider. According to this article in Information Week, Sybase iAnywhere division's, Afaria security line already provides device authentication and encryption and now will add anti-virus and firewall capabilities.

I was glad to see the Sybase name in the article.  I have fond memories of Sybase on Sun servers from my early web hosting days.  It is also good to see a new competitor in the mobile phone business. Lets see if Sybase gives the McAfee's, Symatecs, etc a run for their money. Or who knows maybe another not yet heard from name will come out to dominate the mobile phone market.

What I also was unaware of was that there were over 500 viruses that target mobile phones.  With Sybase covering Windows Mobile, Symbian (they just went open source), Blackberry and more, even the Apple iPhone appears to be covered.  Though overall I still think this is an immature market, it will be interesting to see who steps up.

In a blast from the past, Sybase is aiming to be your mobile phone security provider. According to this article in Information Week, Sybase iAnywhere division's, Afaria security line already provides device authentication and encryption and now will add anti-virus and firewall capabilities.

I was glad to see the Sybase name in the article.  I have fond memories of Sybase on Sun servers from my early web hosting days.  It is also good to see a new competitor in the mobile phone business. Lets see if Sybase gives the McAfee's, Symatecs, etc a run for their money. Or who knows maybe another not yet heard from name will come out to dominate the mobile phone market.

What I also was unaware of was that there were over 500 viruses that target mobile phones.  With Sybase covering Windows Mobile, Symbian (they just went open source), Blackberry and more, even the Apple iPhone appears to be covered.  Though overall I still think this is an immature market, it will be interesting to see who steps up.

I said recently that I wanted to talk more about what I do. The core of what I do is help Microsoft’s product teams analyze the security of their designs by threat modeling.   So I’m very concerned about how well we threat model, and how to help folks I work with do it better.   I’d like to start that by talking about some of the things that make the design analysis process difficult, then what we’ve done to address those things.  As each team starts a new product cycle, they have to decide how much time to spend on the tasks that are involved in security.  There’s competition for the time and attention of various people within a product team.  Human nature is that if a  process is easy or rewarding, people will spend time on it.  If it’s not, they’ll do as little of it as they can get away with.  So the process evolves, because, unlike Dr No, we want to be aligned with what our product groups and customers want

There have been a lot of variants of things called “threat modeling processes” at Microsoft, and a lot more in the wide world.   People sometimes want to argue because they think Microsoft uses the term “threat modeling” differently than the rest of the world.  This is only a little accurate.  There is a community which uses questions like “what’s your threat model” to mean “which attackers are you trying to stop?”  Microsoft uses threat model to mean “which attacks are you trying to stop?”  There are other communities whose use is more like ours.  In this paragraph, I’m attempting to mitigate a denial of service threat, where prescriptivists try to drag us into a long discussion of how we’re using words.)   The processes I’m critiquing here are the versions of threat modeling that are presented in Writing Secure Code, Threat Modeling, and The Security Development Lifecycle books.

In this first post of a series on threat modeling, I’m going to talk a lot about problems we had in the past.  In the next posts, I’ll talk about what the process looks like today, and why we’ve made the changes we’ve made.   I want to be really clear that I’m not critiquing the people who have been threat modeling, or their work.  A lot of people have put a tremendous amount of work in, and gotten some good results.  There are all sorts of issues that our customers will never experience because of that work.  I am critiquing the processes,  saying we can do better, in places we are doing better, and I intend to ensure we continue to do better.

We ask feature teams to participate in threat modeling, rather than having a central team of security experts develop threat models.  There’s a large trade-off associated with this choice.  The benefit is that everyone thinks about security early.  The cost is that we have to be very prescriptive in how we advise people to approach the problem.  Some people are great at “think like an attacker,” but others have trouble.   Even for the people who are good at it, putting a  process in place is great for coverage, assurance and reproducibility.  But the experts don’t expose the cracks in a process in the same way as asking everyone to participate.

Getting Started 

The first problem with ‘the threat modeling process’ is that there are a lot of processes.   People, eager to threat model, had a number of TM processes to choose from, which led to confusion.  If you’re a security expert, you might be able to select the right process.  If you’re not, judging and analyzing the processes might be a lot like analyzing cancer treatments.  Drugs?  Radiation?  Surgery?  It’s scary, complex, and the wrong choice might lead to a lot of unnecessary pain.   You want expert advice, and you want the experts to agree.

Most of the threat modeling processes previously taught at Microsoft were long and complex, having as many as 11 steps.  That’s a lot of steps to remember.  There are steps which are much easier if you’re an expert who understands the process.  For example, ‘asset enumeration.’  Let’s say you’re threat modeling the GDI graphics library.  What are the assets that GDI owns?  A security expert might be able to answer the question, but anyone else will come to a screeching halt, and be unable to judge if they can skip this step and come back to it.  (I’ll come back to the effects of this in a later post.)

I wasn’t around when the processes were created, and I don’t think there’s a lot of value in digging deeply into precisely how it got where it is.  I believe the core issue is that people tried to bring proven techniques to a large audience, and didn’t catch some of the problems as the audience changed from experts to novices.

The final problem people ran into as they tried to get started was an overload of jargon, and terms imported from security.  We toss around terms like repudiation as if everyone should know what it means, and sometimes implied they’re stupid if they don’t.  (Repudiation is claiming that you didn’t do something.  For example, “I didn’t write that email!,” “I don’t know what got into me last night!”  You can repudiate something you really did, and you can repudiate something you didn’t do.)  Using jargon sent several unfortunate messages:

1. This is a process for experts only
2. You’re not an expert
3. You can tune out now
4. We don't really expect you to do this well

Of course, that wasn’t the intent, but it often was the effect.

The Disconnected Process

Another set of problems is that threat modeling can feel disconnected from the development process.  The extreme programming folks are fond of only doing what they need to do to ship, and Microsoft shipped code without threat models for a long time.  The further something is from the process of building code, the less likely it is to be complete and up to date.  That problem was made worse because there weren’t a lot of people who would say “let me see the threat model for that.”   So there wasn’t a lot of pressure to keep threat models up to date, even if teams had done a good job up front with them.  There may be more pressure with other specs which are used by a broader set of people during development.

Validation

Once a team had started threat modeling, they had trouble knowing if they were doing a good job.  Had they done enough?  Was their threat model a good representation of the work they had done, or were planning to do?  When we asked people to draw diagrams, we didn’t tell them when they could stop, or what details didn’t matter.  When we asked them to brainstorm about threats, we didn’t guide them as to how many they should find.  When they found threats, what were they supposed to do about them?  This was easier when there was an expert in the room to provide advice on how to mitigate the threat effectively.   How should they track them?   Threats aren’t quite bugs—you can never remove a threat, only mitigate it.  So perhaps it didn’t make sense to track them like that, but that left threats in a limbo.

"Return on Investment"

  The time invested often didn’t seem like it was paying off.  Sometimes it really didn’t pay off.    (David LeBlanc makes this point forcefully in “Threat Modeling the Bold Button is Boring”) Sometimes it just felt that way—Larry Osterman made that point, unintentionally in “Threat Modeling Again, Presenting the PlaySound Threat Model,” where he said “Let's look at a slightly more interesting case where threat modeling exposes an issue.”  Youch!  But as I wrote in a comment on that post, “What you've been doing here is walking through a lot of possibilities.  Some of those turn out to be uninteresting, and we learn something.  Others (as we've discussed in email) were pretty clearly uninteresting”  It can be important to walk through those possibilities so we know they’re uninteresting.  Of course, we’d like to reduce the time it takes to look at each uninteresting issue.

Other Problems

Larry Osterman lays out some other reasons threat modeling is hard in a blog post: http://blogs.msdn.com/larryosterman/archive/2007/08/30/threat-modeling-once-again.aspx
 

One thing that was realized very early on is that our early efforts at threat modeling were quite ad-hoc.  We sat in a room and said "Hmm, what might the bad guys do to attack our product?" It turns out that this isn't actually a BAD way of going about threat modeling, and if that's all you do, you're way better off than you were if you'd done nothing. 

Why doesn't it work?  There are a couple of reasons:

It takes a special mindset to think like a bad guy.  Not everyone can switch into that mindset.  For instance, I can't think of the number of times I had to tell developers on my team "It doesn't matter that you've checked the value on the client, you still need to check it on the server because the client that's talking to your server might not be your code.".

Developers tend to think in terms of what a customer needs.  But many times, the things that make things really cool for a customer provide a superhighway for the bad guy to attack your code. 

It's ad-hoc.  Microsoft asks every single developer and program manager to threat model (because they're the ones who know what the code is doing).  Unfortunately that means that they're not experts on threat modeling. Providing structure helps avoid mistakes.

With all these problems, we still threat model, because it pays dividends.  In the next posts, I’ll talk about what we’ve done to improve things, what the process looks like now, and perhaps a bit about what it might look like either in the future, or adopted by other organizations.