1)  Gunnar has put up his speech as the Quality of Protection Keynote:  “The Economics of Finding and Fixing Vulnerabilities in Distributed Systems.” Don’t worry if that title doesn’t turn you on, his post is one of the best this year.  I wanted to make today’s blog post some reflection on what he says there, but I haven’t the time today and we’ll have to table that until next week.  Anyway, it’s excellent.

2)  Aleks Jakulin writes about The Future of Data Analysis.  I spoke with a CSO who is morphing into a CRO role and one of the things he plans on doing is hiring about  a half dozen data analysts.  If you think better use of Security Information is in your future, you’ll want to take a look at that blog.

3)  Brent Huston of the Ohio voting machine fame writes about an incident he just worked on and risk and rational security.

4)  Our friend Mike Rothman and our friends at Business Of Security/Cisco are doing a Pragmatic CSO thing.  Mike is always entertaining and practical (dare I say, pragmatic) so I think this should be a fun webex.  Hope you’ll sign up.

Namaste Risk Geeks!

First up is a code review quiz, “Test Your Security IQ”. Put your C/C++/C# security skills to the challenge by reviewing ten tricky code snippets that Michael and I devised. As an added incentive, I’ll post public congratulations here in the SDL blog to the first person who reverses the insecure hash found somewhere in the exam (not to give too much of a hint).

Next up, we have “Agile SDL: Streamline Security Practices for Agile Development”. I’ve been talking about web application security issues in the SDL blog (and in the September issue of MSDN magazine, if you missed it). However, while it’s essential to make sure that web-specific issues are covered in the SDL, it’s equally important to make sure that web development teams – and other Agile development teams – can use the SDL effectively, and the classic, phased SDL approach is not always a good fit for these teams. This MSDN article is the first public look at the new SDL/Agile methodology that we’ve been working on for the last year. This process is currently in beta with some internal Microsoft product teams and online services. We’d love to get some external feedback on it before we release it to the entire company, so please send us your thoughts.

Finally, be sure to check out Michael’s Security Briefs column “Threat Models Improve Your Security Process”. Regular readers of this blog know how important threat modeling is to secure development. This article describes methods of using threat modeling not just to identify security vulnerabilities outright, but how to use it to make other SDL activities such as fuzzing and reducing attack surface more effective.

Three articles are more than enough for one team for one month! But be on the lookout for more articles from the usual SDL suspects in the near future. As always, keep watching this space for details.

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.