One of the most challenging steps in deploying or migrating an application or infrastructure to a cloud computing environment is first determining if such a move makes sense. This isn’t purely security-related issue, as application developers, infrastructure administrators and business managers all have to assess if the cloud will make their lives easier, or lock them into yet another technological fad with long-term consequences. Now maybe the decision ends up being based on the prettiest sales presentation or the hottest business article, but for those of us in security, it’s important that we understand, assess and effectively communicate potential
While cloud computing can be an incredibly complex undertaking fraught with technological minefields, starting your project with a matrix-based, detailed mathematical risk model is likely one of the fastest was to ensure you won’t be invited to those lunchtime working sessions. Early in the project it’s far more important to communicate visceral risk in business terms, as opposed to scaring folks into thinking the C.I.A. is monitoring your project.
As I was helping edit the second version of the Cloud Security Alliance’s Security Guidance document released in late 2009, I realized that one thing missing from the document -- and most every risk framework -- was context. It is all too easy to jump deep into products and probabilities and lose track of the big picture. Thus I wrote the guide’s “Editorial Note on Risk” to provide a simpler, quicker starting point to get you engaged sooner and help determine if a project is even worth pursuing before you start dedicating significant resources.
At the core of the process are six basic questions for assessing cloud computing risks that, when you get down to it, are the core of any good risk assessment. These questions help us discuss our traditional confidentiality, availability and integrity using plain business terms designed to strike home to non-security people in the language they more commonly use. Consider how your organization would be harmed if:
- The asset – data, application or process -- became widely public and distributed.
- An employee of the cloud provider accessed the asset
- The process or function was manipulated by an outsider.
- The process or function failed to provide expected results.
- The information/data were unexpectedly changed.
- The asset were unavailable for a period of time.
You’ll notice these questions drive right at the most common concerns about cloud computing risks. Would it hurt our business if data became widely public or someone in our provider peeked at it? Are we worried about a hacker changing how it works or altering data? What would the damage be if the cloud service went down?
These aren’t FUD; we should be asking these same sorts of questions about our internal infrastructure. And in some cases, the cloud might provide better answers than handling things ourselves. Your goal (if you read the entire framework) isn’t to perform a full risk assessment, but to quickly determine if the cloud makes sense for the project in the first place. And to do so in a way that anyone else can easily understand.
The real trick is that you can’t do this on your own. Go to the sponsors and other stakeholders in the project and have them fill out a sentence or three for each question, and then compile and distribute the results. This gets everyone on the same page, even if you don’t all agree.
About the author:
Rich Mogull has nearly 20 years experience in information security, physical security, and risk management. Prior to founding independent information security consulting firm Securosis, he spent seven years at Gartner Inc., most recently as a vice president, where he advised thousands of clients, authored dozens of reports and was consistently rated as one of Gartner's top international speakers. He is one of the world's premier authorities on data security technologies, including DLP, and has covered issues ranging from vulnerabilities and threats, to risk management frameworks, to major application security.
This was first published in February 2011