The cloud has changed how we use and consume IT services. Where data resides along with how it is transferred, stored and processed has fundamentally changed and with-it new risk management challenges. Let's talk about some of those challenges. First and foremost, the cat is out of the bag. We're not going back to the data center, and any resistance to that is going to be seen as a business inhibitor and will therefore not get much airtime. Second, I think that the cloud has been adopted typically in silos because every employee has a credit card. That's a big problem because it doesn't allow the enterprise to have oversight across the board on how data is being processed and stored. I also think that the cloud is pretty ambiguous as a term. Not all cloud service providers are created equal. AWS, Azure and GCP are pretty rock-solid, but 80% of the Cloud we consume is not with them but with the Ma and Pa SaaS companies around the world. Of course, those SaaS are living off of AWS for the most part, but do you know with whom you keep your contract? Not with AWS but rather with the SaaS provider, and they habitually are terrible at security. Lastly, security is fundamentally different in a software-defined world. For the cloud, this is a world of shared responsibility where half of the responsibility for security is ours and the other half is the service providers. All of this gets very murky, and unfortunately, a lot of early adopters of the cloud believe that the cloud service provider has almost all the responsibility. That's just not true.
The Strategy
Now let's switch tracks and talk a little bit about strategy. Understanding what cloud services have been adopted by your organization, authorized or not is the first step. Then understanding what data is being transferred, processed and/or stored into the various cloud services is second. Once you have identified the cloud services and the data types that are being put in the cloud, you then need to put on your risk management hat and start tracking what if any security controls are in place to protect the data and who owns the responsibility of configuring and managing said security control(s). Next, and maybe this should have been the first part of the strategy, is the need to increase awareness to the business and the stakeholders. From a business risk perspective, “times are a-changing.” Privacy laws are now in force to compel companies to adequately protect the data they collect. Failing to do the right thing and suffering a data breach can now result in irreparable reputational damage (mandatory breach disclosure) and financial penalties (fines). Businesses should now acknowledge handling personal identifiable information (PII) as a high-risk activity whether in your own data center or in a cloud. Cloud adoption has some major benefits, and any astute businessperson can realize the cost savings and increased agility that cloud can afford us. However, more often than not, the business and risk owners are wowed by the whiz-bang of the cloud and blinded to the additional and nuanced risks. Traditionally, we have had a decent ability to control how accessible the data is and who has access when in our own data center. We call this the walled garden approach. By no means is it perfectly secure; it's something we have become decent at securing. However, the walls come down when it comes to the cloud, which means your data is slightly more exposed to threats than it was before. That is not to say your data cannot be secured as good if not potentially better than in your own data center. However, it is a "choose your own adventure" scenario. A misconfiguration of your cloud service on your end or choosing a cloud service provider that sucks at security (many of them) are by far the most common means for getting in the news for a security incident and experiencing punitive fines. Understanding that risk is crucial when making cloud adoption decisions.
Conclusion
You need to understand and manage risk accordingly but enable, not inhibit the business. Shadow Cloud adoption, especially software as a service (SaaS), is likely in your IT environment, and you need to strike a balance of reducing risk while not stopping the business. As an example, there is likely one or more teams in your organizations who have adopted an insecure SaaS service. You do want them to stop using it, but you will need to bring a better solution or compensating control to them first before we can start saying “No, I'm taking your tools away.” Next, look for the opportunity to review and refactor early adoptions of infrastructure as a service (IaaS). The first generation of Cloud adoption was lifting and shifting servers from the data center into the cloud. We joke that if you suck at security in the data center, you can totally suck at security in the Cloud. Lifting and shifting “bad” from your data center into the cloud is likely going to come back and haunt you in the future. You should consider the cloud as a green field where you can pragmatically migrate applications into a pristine and highly secure environment one at a time. But rather than lifting and shifting old and insecure configurations, you refactor your applications to leveraging next-generation cloud-native services which can save you money and have best practice security functionality baked in.
About the Author: Over the past decade and a half, Alex Dow has helped organizations increase situational awareness and enable better prevention, detection and responsive capabilities. Alex has worked within three mission-critical Security Operation Centres (SOC), designed and operated the Vancouver 2010 Olympics honeypot and recently architected and built out the situational awareness platform for a large federal government environment. Beyond Alex’s day job, he has taught Cloud Security for The SANS Institute, runs a not-for-profit and produces an annual cybersecurity conference: BSides Vancouver. Editor’s Note: The opinions expressed in this guest author article are solely those of the contributor, and do not necessarily reflect those of Tripwire, Inc.
