GRC and Cloud Security

I had an epiphany while researching an upcoming talk on cloud security. As part of my research I decided it was time that I finally dig into the Cloud Security Alliance (CSA) efforts to find out what exactly was out there and to become a bit more knowledgable. It turns out, unsurprisingly, that it's mostly straightforward. However, one thing really jumped out at me: GRC is fundamental to managing cloud-based services!

I've known for a while that legal - and, by extension, legal compliance - was an important component to a cloud security strategy, but I'd never really thought about the overall role of GRC. Now that I've had a little time to mull things over, it's really struck me that GRC is extremely important - possibly even the most important - part of your cloud security strategy. Let me explain...

The current version of the CSA Guide (v2.1) is arranged into 13 "domains"... those domains are:
   1. Cloud Computing Architectural Framework
   2. Governance and Enterprise Risk Management
   3. Legal and Electronic Discovery
   4. Compliance and Audit
   5. Information Lifecycle Management
   6. Portability and Interoperability
   7. Traditional Security, Business Continuity, and Disaster Recovery
   8. Data Center Operations
   9. Incident Response, Notification, and Remediation
   10. Application Security
   11. Encryption and Key Management
   12. Identity and Access Management
   13. Virtualization

Whether or not it was done intentionally, you'll noted that GRC is effectively #1 on the list of topics once the basics of "cloud computing" are defined. I personally think this is actually a proper statement on things. If you lack a robust GRC program, then everything else will be relatively undirected and inefficient. How can you make decisions on any of the other topics if you don't first define your requirements and tolerances? (short answer: you can't!)

What does this mean? Simply put: if your organization is moving toward cloud-based services or platforms, then it's imperative that you build-out your GRC program, and asap. If you don't think your org is starting to leverage such offerings, then I have some bad news for you: it's probably happening behind your back. This is especially true the larger an organization gets. We're already seeing cases where business units are whipping out their corporate cards to gain access to SaaS solutions, or even to host on AWS, rather than deal with the bureaucratic red tape necessary to get things approved internally. Do these actions amount to policy violations? Maybe yes, maybe not... however, it's too late to worry about that little detail now that the genie is out of the bottle.

What's your plan of action? Fundamentally, it's time to attack GRC as a discipline... check out my post "Defining GRC (the discipline)" for a primer on some of the key pieces... and, if you have questions more basic than that, also check out my recent post "GRC: What Does It Mean?" for more background on the topic. Once you have a good understanding of the basics, then I highly recommended jumping over the CSA web site to read their security guidance.

About this Entry

This page contains a single entry by Ben Tomhave published on April 12, 2011 9:46 AM.

GRC: What Does It Mean? was the previous entry in this blog.

Identity Crisis: The Delusion of NSTIC is the next entry in this blog.

Find recent content on the main index or look in the archives to find all content.

Monthly Archives

Pages

  • about
Powered by Movable Type 6.3.7