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:
- 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,
- 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.
