Disclaimer: I am not an attorney. I'm not offering you legal advice, only some common-sense analysis of a potentially game-changing document from a very important body for the financial services industry. The original PDF document, complete with my notes in the margins and highlights are included below should you choose to review for yourself.
Where to begin on this one... A few days ago I wrote up a quick summary after skimming this document.
Since then, others have written articles and posts on the topic, so it's time I post my thoughts too. I still encourage you to read the full paper and analyze it for yourself, since I think it's critical to be educated on things that matter.
Contrary to what was written in this BankInfoSecurity post, which I think completely misses the point, I think this paper is a fantastic document. At the core of what I disagree with, Mr. Francoise Gilbert of the IT Law Group says this: "I find this document a bit disappointing," she says. "They view cloud computing as just another form of outsourcing, and that's a far too simplistic view."
Unfortunately, I think he misses the point that cloud computing isn't magically new - it's just another form of outsourcing. Let's take Infrastructure as a Service (IaaS) for example. You're basically leasing (virtual) hardware outsourced to a 3rd party rather than having it in your own data center.
Once you get over the virtualization there is very little left to get excited about from a risk perspective that thinking about cloud as outsourcing doesn't already cover. Anyway, not to belabor the point, but this is just an example of how easy it is to get caught up in the glimmer of cloud and miss the entire point of it's beauty.
Let's dive into this document that the FFIEC has produced, and analyze it bit by bit.
First, as I pointed out in my previous post the document has this profound statement "The Federal Financial Institution Examination Council Agencies consider cloud computing to be another form of outsourcing with the same basic risk characteristics and risk management requirements as traditional forms of outsourcing". Whether you believe it or not this is the stake in the ground for the FFIEC.
There has been a buzz of discussion and articles (see above) by folks who believe that cloud computing is somehow fundamentally different than anything we in IT have done before. Those people are wrong. Yes there are differences between what we traditionally know as outsourcing and what we think of as cloud computing. But if you break it down to risk management - cloud = outsourcing. Period, and to think otherwise is over-analyzing, in my humble opinion.
Another key point the document makes it that all of this is basically a pointer back to the "FFIEC Information Technology Examination Handbook", specifically the "Outsourcing Booklet"... you should have a background in those two to get a full understanding of this published FFIEC document.
I also think it's interesting that the document mentions that save the NIST document published in December 2011, there is "no widely-accepted definition" of cloud computing - basically saying there is no consensus amongst providers, consumers, and pundits ... this is absolutely true.
There was a recent discussion about whether "cloud" mandated virtualization with people disagreeing all over the place which demonstrates this as truth. Attend any of your local Cloud Security Alliance chapter meetings and ask someone to define cloud... then sit back and listen/watch.
The document breaks apart nicely into six sections - (1) due diligence, (2) vendor management, (3) audit, (4) information security, (5) legal, regulatory and reputational considerations, and (6) business continuity planning. For those of you who caught this right off, notice information security is buried a bit as number 4, rather than being right at the top. I think this speaks to something which is in the tone of this document.
The first 3 parts of this document are those things many of us consider common sense, or not really a part of "security". Let's face it, due diligence, vendor management and audit are generally things InfoSec people steer pretty clear of because it's paperwork, process, relationships, and more paperwork.
Another key which I think more than a few of you readers will appreciate, is that the first 3 parts can't easily be 'solved' by purchasing a box with blinky lights. Yes, information security gets its own sub-section simply because it's important - but no more or less important than things like due diligence, audit, and vendor management... I think that's interesting, don't you? As a final point, the fact that business continuity still has to be mentioned is... painful. I'll explain in a minute.
The key phrase is right in the beginning, and says "A financial institution’s use of third parties to achieve its strategic plan does not diminish the responsibility of the board of directors and management to ensure that the third-party activity is conducted in a safe and sound manner and in compliance with applicable laws and regulations." Basically - your data, your responsibility.
The due diligence section is broken up into 3 potential issues - data classification, data segregation and recoverability. You'll notice I bolded the word "data", because it's not about your VMs, or your applications, or even your databases - it's about the data. I really appreciate the focus on data classification based on the last few weeks of BYOD discussion in the community. I think this is a nice return to basics - if you do not know what is important to you then protecting 'it' is impossible.
The paramount point on data classification continues to haunt enterprises as it did back when I was getting into IT back in the mid 90's. What is it? Where is it? How do we classify it? these should be basic questions that are at the heart of every good information protection/security strategy. Data segregation is also mentioned in much the same context as it was when I first started using an outsourced hosting provider back in 1998... how does our financial data and other NPPI (non-public personal information) share space, technology and access with others.
Are we in the same physical space as a key competitor? Is our financial data potentially sharing space on a the same object storage service as provider of questionable content? Does any of this matter? These are all great points made, questions to ask, and they aren't any different when cloud technologies are applied in place of traditional outsourcing.
On a final point, recoverability. I've been reading and talking about enterprise resilience a metric ton lately and reading this point on recoverability made me smile. In essence, I think I would sum it up as this - "don't let your cloud provider become your new single point of failure". Common sense whether you're going cloud, or traditional IT.
This sub-section is pretty simple and basically states that you need to make sure your vendors understand you as a customer, and you understand your vendors. Basically going cloud will likely require additional controls you didn't have before to keep a close eye on your vendor, and other standard stuff.
Then we get to a point I don't think is discussed enough (mental note, discuss this soon): "disengagement". Disengaging from a cloud provider can be absolutely messy, especially once you've gotten comfortable in their environment. One of the key tenets of the HP Converged Cloud strategy is customer choice - but that isn't simple. The customer must be aware of their provider's features to "lock you in" to their service. At its basics, many providers are roughly compatible - OpenStack is OpenStack .. sort of.
It's the value-adds that get you every time. Make sure you're got an exit strategy for when you need to divorce yourself from your vendor. Make sure you have a way to exit their cloud, your services and data intact. Speaking of data, be cognizant of how much you're storing because even if it's moving from one OpenStack cloud to another ... moving multiple petabytes of data isn't trivial of instantaneous - and will likely cost a fortune.
The audit sub-section has two key points. The first is the trickiness of determining the adequacy of your vendor's controls. In many of today's clouds, this is tricky. Some providers will fill out the 100-page RFP that you have asking for details, some will simply hand you the last audit they went through as their version of "good enough". The trick is getting their "good enough" to match up with your "good enough".
Does your provider give you access to the behind-the-curtain details? I'm guessing not. Some will let you talk to their CISO and discuss details without actually being able to walk away with anything tangible - is that good enough? It's not like you can go get a tour of their cloud like you could when you were evaluating data centers right? Can you audit your provider? To what depth, how often, and with what mechanisms - those are all questions you should be asking.
The other interesting point this document mentions is training (or augmenting) your existing staff to catch them up on cloud-related technologies. How's that for a good idea?
Let's start this sub-section off with the notion that your existing policies probably should have the layer of dust blown off of them and should be updated to include concepts that probably weren't around 10 years ago when your policy was written. If you policies have been updated, good for you, you're ahead of the game.
Continuous monitoring is mentioned - which I think is fantastic because it gets us away from a point-in-time position on 'security'. Yes, everyone is secure when there is nothing going on and all the controls are working properly, but unfortunately environments, especially cloud, are far from static and must be monitored closely at all times.
Having a comprehensive data inventory and a suitable process for classifying your data (hrmm... Deja vu) fall into the basics you should be doing anyway bucket. Basics keep killing us and we keep wondering why all the shiny new technologies organizations implement aren't doing their job? You're missing the basics, so the add-ons are pretty... but useless.
Having effective identity management (IdM) has been important since ...forever. Cloud just exacerbates the need as we start to cross platforms we don't have direct control over. An identity management program is something more enterpises have gone through in the last decade - many went over budget and took too long but it's critical to keep this process of knowing your users and their acceptable roles and access requirements constantly in check. When identity management breaks down, all the technology in the world won't save you from a data breach - from the insider, outsider, or "oops".
Interesting that the FFIEC chooses to highlight "Storage of data in the cloud could increase the frequency and complexity of security incidents" but it is so very true. Whether we're talking about incident response from composite response teams (yours, the vendors, and any 3rd parties), forensics in a cloud environment (good luck), or trying to monitor that many more systems, networks and data points for risks and threats - the cloud certainly requires the security team to up its game.
No disputing that security needs to step it up significantly when it comes to protecting and reacting in the cloud... as an industry we're starting to see some effective strategies but I think that we're still in the early stages of anything 'cross-industry' such as incident response, etc.
Oh, and lest I forget to mention - data destruction is important. This isn't about whether you trust your vendor to destroy your data once you've either decided to exit the cloud, or something as simple as downing a virtual machine ... are those bits recoverable by someone else? The answer should always be no - but can someone prove it?
This is where I think the unspoken advice is that encryption, encryption, encryption is your friend. You shouldn't be relying on your vendor to do it either... because saying "we encrypt" and doing it right are really distant things. Key management is difficult in a controlled environment like your data center, the implications in the cloud are even more harrowing.
Legal, Regulatory and Reputational Considerations
As I read this section something just jumped off the page. This line: "financial institution should understand the applicability of laws and regulations within the hosting countries and the financial institution’s ability to control access to its data" lays down another fine point about the cloud, that perhaps is a little different than what we're used to.
The financial institutions must now consider the laws and regulations of the country in which their data is hosted... I know we've talked about data sovereignty/residency in the past but this statement highlights that issue for American financial institutions wishing to utilize the cloud. I would really want to have some more clarification on this topic, because it's a huge deal breaker in many financial + cloud cases.
Business Continuity Planning
I can sum this entire section up for you like this - "don't put all your critical eggs in one cloud provider's basket". Enterprise resiliency is a critical aspect of going cloud. If your applications and data systems are critical they should be able to survive your cloud provider's failure because, as I've said before, everything fails. Plan for it, test it, expect it.
This is a fantastic document, and as an IT and Security Manager from a financial services SME told me in a discussion - "there is what the document says, and what security leaders will want to use it for". Great point. I think those that are slamming this document for being too vague are completely missing the point. This document is open-ended and doesn't give specifics for that very reason - so that IT leaders can use it to their advantage to have a conversation with their senior leadership and maybe even their board of directors on what will be coming in some SEC regulation a little further down the road.
While "cloud" is still a mythical scary unicorn to many C-levels in finance, "outsourcing" is an old friend. Simply changing the words in the discussion is monumental, and I think it's a fantastic tool for security and IT leaders in the financial space. As the IT manager I was speaking with said, this document gives him the ability to "use whatever technology makes the most sense for the company, based on performance, cost" and at the end of the day isn't that what we want from an organization like the FFIEC or some other governing body?
Look, if you're an IT or security leader you don't want a specific set of things to do for cloud computing. This would quickly turn into a bunch of boxes that need to be checked such as "anti-virus on all virtual machines, check!" - I can hear it now. Instead, this document is brilliant because it lays out the things that it believes are key areas of focus, and really shines in its ability to liken something new and potentially scary to something enterprises are already used to - outsourcing.
I will leave you with one final quote from my colleague about this document in which he says that this document is a "framework for how to talk to business about cloud".
Perfectly summed up.
Download the FFIEC Statement on Cloud Computing below...
Cross-posted from Following the White Rabbit