Last Updated on May 8, 2018
Cloud services are used by 97% of all companies. A jaw-dropping 26% of those companies have experienced data theft from the public cloud, according to a fascinating new study by McAfee. That means cloud services have a 74% success rate when it comes to data security.
Putting 74% in Perspective—Why Batting .740 Isn’t Good Enough
A 74% success rate is a pretty good in many areas. Tom Brady has never come close to completing 74% of his passes. If you somehow managed to win 74% of the hands you play at blackjack, a cushy retirement on a Caribbean island would await you.
But you wouldn’t fly on any airline that boasts a 74% safe landing rate. Nor would you drive a car whose brakes worked 74% of the time.
So, on which end of this spectrum would you place the security of your highly sensitive data? Because if you are not OK with a one-in-four chance that it will be stolen, then don’t store it in the public cloud.
How Can Companies Reduce Cloud Security Risks?
Wisely, according to the same study, only 69% of businesses trust the public could to keep their data secure. But cloud use is increasing. So, what is a company to do? Especially a smaller or midsized company (SMB)? With cloud service providers (CSPs) being, by definition, third parties, how do you integrate the necessary third-party risk management (TPRM) into your overall information security and risk management practices?
Smaller companies are particularly vulnerable to issues with cloud providers. Because of their size, they are often forced to use cloud services for services that larger companies might place on-site. Yet, they are not large enough to fund information security enough to have specialists on staff to deal with cloud security as well as on-site systems security.
TPRM for Cloud Services
This will be the first of a few posts based on this new study. To start with, I want to discuss a few aspects of cloud security that directly impact your TPRM approach to cloud security.
1. There is no such thing as “the” cloud, or even “the” public cloud.
When people talk about “the cloud” they can be talking about Platform-as-a-Service (PaaS), Software-as-a-Service (SaaS), or Infrastructure-as-a-Service (IaaS). These models are very different, and they have very different security issues.
2. There is also no such thing as an “average” cloud services provider (CSP).
They range from multi-billion dollar behemoths with highly advanced and complex security controls to tiny startups that often have a fantastic looking web page, but very few security controls. The best-practice way to manage risk when using Amazon Web Services (AWS) is vastly different than when using a service backed by a six-person startup.
3. Cloud services are often nested.
This makes third-party risk management harder, because now you not only have third parties (the CSP you have a contract with) to worry about, but you also must consider the security of the cloud providers they use.
4. Cloud services interact in ways that create new and complex risks.
The whole is riskier than the sum of its parts. You might use one CSP for your accounting package, a different CSP for file storage, a third CSP for your fulfillment platform, and yet another CSP for your data analytics. Not only do you have to be concerned about each of their sets of controls, but also you are frequently moving data from one CSP to another in order to process it, thus introducing more risk than if only employees of your company were accessing the data.
5. A cloud service provider’s security and the security of your data with that CSP can be very different things.
For example, AWS is one of the most popular CSPs in the world. I have deeply reviewed their security controls and their security approach. They are very good; they put a lot of effort into security, and it shows. Yet we see breaches involving AWS all the time. For example, the enormous Verizon data breach of 2017 involved the lack of security of a database on an AWS server. How are these seemingly incongruous facts possible? Simple: Amazon does a great job doing what they say they will do, which is secure the infrastructure. What your organization does with that infrastructure, including what you deploy on it… that’s your problem to secure.
What You Can Do Now
Where does all that leave your company and its sensitive data?
We will explore this topic in much more depth in upcoming posts. In the meantime, here are a few 4 tips from Pivot Point Security—we’ve been doing TPRM for several years, and keeping information secure for almost two decades:
- Develop some form of TPRM program and integrate it with your information security function. As noted above, 97% of companies use CSPs. You do have third-party risk. The only question is whether you will manage it well or poorly.
- Understand your entire enterprise’s use of cloud services. According to the McAfee study, the average company uses 25 different CSPs. My experience is that very few companies understand all the cloud services they are actually using. This is one of the most critical steps in developing a TPRM program, and (surprisingly) often one of the most difficult.
- Spend time figuring out who is doing what in your relationships with your cloud service providers. Who is securing the infrastructure? Who is responsible for encryption? Who is doing backups? You will likely be surprised by the answers you find.
- Understand and develop processes around shadow IT. “Shadow IT” includes those IT services that are driven and managed outside of the traditional IT infrastructure. When you consider your company’s portfolio of cloud services as recommended above, you will very likely discover some cloud services that are getting highly sensitive data that your information security function didn’t know about. And, very likely, nobody has looked at their security.
For many companies, data security is cloud security now. Which means data security is also TPRM. This is different from the way we secured our data just ten years ago. If you have any questions, or would be interested in knowing more, we’d love to hear from you.