Move to the Cloud with Confidence: 6 Key Risks & Mitigation Techniques — Part 2

Author: Samuel Lewis, Senior Security Consultant, CISO Global

According to Gartner, cloud spending will reach $597.3 billion by the end of 2023. Whether it’s infrastructure as a service (IaaS), a software as a service cloud application (SaaS), or some other use for the cloud, organizations are finally adopting cloud use models that help increase scalability, reliability, and speed, while reducing overhead costs. The adage about the cloud in IT security circles is that while most people think of “the cloud” as some ethereal, magical technology poof in the sky, “It’s actually still a computer – just someone else’s computer.” So, that brings us to the question of whether or not that “someone else” is securing “their computer” (server) that has your data in it. In most cases, this is where we get into the significant risks cloud outsourcing can bring and how to address them. In the last article, we looked at ways to mitigate two of the 6 key risks that come with the cloud: information security, and uptime and availability. In this installment, we will examine how you can mistakenly get yourself into risk with vendor lock-in and data loss when using a cloud service provider (CSP). 

Cloud providers love to get you started using their products by inviting you to move data into their environment. While you may be comforted by the idea that a contract allows you to leave them if dissatisfied, the truth is that once your data is in their systems, you are pretty locked in (and they know it). Transferring data and transitioning systems is no easy task. In fact, it can cost you so much in lost internal work hours that it is cost prohibitive in many cases to do so, which makes cloud solutions “sticky” – you feel stuck with them, so you put up with frustrations associated with their services. So, before you move data into any cloud system, you will want to acknowledge the risk of being stuck with them and think about some ways to mitigate it. 

To begin, a cost-benefit analysis will help you think about whether or not staying with the CSP makes financial sense for your organization in the long run. Then, you will want to find some ways to keep yourself from being totally dependent on a single provider. You could consider leveraging several public cloud providers at once in what is called a multi-cloud approach. Instead of a homogenous architecture, multi-cloud is heterogenous. This can help in the event that one cloud experiences downtime, but it also helps you examine the services of more than one cloud provider to compare over time. If you have issues with one CSP, at least you will not have your entire environment or system in there. Another architectural approach to consider is what is called a hybrid cloud environment, where you keep some of your data on premises and some of your data in the cloud. Again, this has the benefits of dividing risk over multiple environments rather than putting all your eggs in one basket, so to speak.  

A third way to mitigate the risk of vendor lock-in is to dig into the end-user license agreement with your legal team to determine what will happen if you want your data back. This is an essential question that many people were asking when cloud environments and solutions first gained traction in the market, “Who owns my data at the end of the day, and how do I get it back if I want to?” It’s still a valid question, and one you should really consider. There have long been rumors that some cloud-based social media applications’ privacy policies give their companies ownership of all photos and data shared through their platforms. In 2015-2016, when the platform was being widely adopted, numerous articles reported that the company’s privacy policy indicated that it owned all photos taken by individual users with its app, even after they disappeared (a core functionality of Snapchat). In years since, Snapchat has worked to dispel this belief, but it raises the issue that anytime you use a cloud-based application, infrastructure, or other service, you need to read the fine print. When their policies change over time, you should read the updates, as well, and make sure you can always get your data back – understanding and making sure you are okay with any hassle, charges, time limitations, or any other terms laid out in the contract. If your cloud vendor doesn’t have good answers to the question of what it will take to get 

your data returned, I recommend you walk away. There is always a competitor around the corner. 

The issues with cloud environments typically center around your data – data protection, data return, data integrity, and in this case, data loss. There is a good reason for that; data is one of your most valuable resources. Losing valuable data can cause business interruptions, create errors, and many other costly problems. While cloud brands with household names like Microsoft, AWS, or Google would be thought to have plenty of redundancies, it is a good idea to think through worst case scenarios. For example, what happens if all your data is in two redundant data centers, both of which are located on the U.S. East Coast, and the entire eastern seaboard is struck with a catastrophic hurricane? You could be temporarily or permanently without access to your data.  

As with uptime and availability risks, it is good to think through not just redundancies, but who owns responsibility for cloud backups. Never assume they are doing it for you, because chances are, that is not happening. You are likely to need to engage your own backup provider, then make sure your cloud backups are properly architected to protect them from 1) attackers, 2) weather events, and 3) human error. It’s the same thinking that goes into disaster recovery plans – assume the worst can happen, calculate your risk tolerance level for how much data you can afford to lose without going out of business (or other loss levels), then create policies, procedures, and other mitigating controls to protect your data. When it comes to cloud applications like a CRM or automated marketing and sales app, you will definitely want to understand your provider’s processes and frequencies for protecting data. Do they perform backups? How often? Where are backups stored? How are they architected to protect them from attackers, accidental deletion, or weather events? 

Now for the big one: backup testing. Who is testing backup procedures? Without regular failover testing, there is no way to know if those backups are working as expected. If you are backing up data stored in an IaaS environment, you are likely doing that yourself. If the systems being backed up are cloud apps, however, you will need assurance as to how often and how well these tests are being performed. Like any business relationship, make sure you get it in writing. If something happens, your legal team is going to ask you to provide the signed documentation showing the provider’s responsibilities for protecting your data. Without that, you have little recourse and should consider backing systems up, yourself. This is a step that is often ignored during contract creation, negotiation, and signing with CSPs / cloud vendors. When in a hurry, organizations may miss a step, so be sure to help by taking proactive steps next time you engage a CSP on behalf of your company. 

In summary, whether you are in process of transitioning cloud vendors, engaging a new cloud service for the first time, or just trying to assess your risk with existing cloud providers, looking at your contracts through the lens of risk can help. When you look specifically at the potential for vendor lock-in and data loss, you are likely to see a clearer path emerge. If you would like help securing, architecting, or evaluating outsourced cloud systems, reach out to us anytime for a discussion with one of our CISO Global experts.