Dissecting Cloud Security Breaches
Recent Gartner prediction: By 2020 95% of cloud security failures will be the customer’s fault. I agree with this in a general sense, and it led to an interesting discussion of cloud breaches with some colleagues. One said:
“It makes perfect sense, but is this because cloud services providers (CSPs) are so good at security or because they are so good with their legal contracts? I suspect the latter.”
Being good with contracts is just one aspect of the growing divergence between the well-run CSP and the average privately-operating IT installation.
The notion of “customer’s fault” is broadly applicable in an operational sense of fact as well as in a legal sense of blame. Even a software-as-a-Service (SaaS) operation like Salesforce (where the CSP controls all the infrastructure and application components) gives the customer plenty of room to screw up. After all, SaaS customers may still fail to implement strong authentication, mismanage privilege, or neglect to monitor activity in the service. Only with business process as-a-service (BPaaS) offerings does the customer have less room to screw up.
Digging into the Number
Sure, the 95% number is more illustrative than rigorous, but it could be broadly accurate. Hidden in the 5% number is the fact that CSP failures could be very serious. When one of the big CSPs goes down, it could be catastrophic to the IT operations of many companies and also to cyber-insurers, or even re-insurers. And why is that number only 5% when there are so many startups running CSP operations on a shoestring budget? Perhaps the reason there aren’t many more smaller, less-professionally-managed CSPs failing is Darwinian. Caveat emptor, huh? At any rate, the smaller CSP failures would affect fewer customers.
Fortunately, when a large CSP fails, as in the famous Amazon Web Services (AWS) East Coast region outage, the fault is usually contained. Large CSPs are just more proficient at operationalizing resilience. This may put a catastrophic CSP failure almost, but not quite, into the black swan category. Time will tell.
An Internal Example
On reading essentially this same discussion in an email, another colleague of mine declared: “Totally agree with your analysis, Dan, and its further backed up by what I’m seeing with the evolution of workflows on ServiceNow within our company. ServiceNow as a platform I’m sure is rock solid with stringent security processes. But we’re are creating workflows that can automatically spawn Active Directory security groups or unlock root account credentials. Without performing security testing on the logic behind these ticketing workflows, it’s not hard to envision someone causing a security incident ‘on ServiceNow’ that has nothing to do with the actual CSP.”
So we decided to recommend some pen-testing…
Important Take-Aways
CSPs have a strong market incentive to prioritize security even more than a relatively-diligent end user organization normally does. CSPs tend to hire experienced security staff to perform continuous security monitoring and to manage vulnerabilities. Heck, CSPs avoid having many of the well-known system vulnerabilities in the first place by virtue of having custom inhouse platforms.
But don’t be naïve and assume that just because the larger, better-known CSPs run a tight ship internally that they are automatically taking care of your security. Customers still have to take care of identity and access management and their own security monitoring. In an infrastructure-as-a-service (IaaS) environment like AWS, customers have to shoulder vulnerability management, host security and other tasks as well.
Overconfidence in the CSP only leads to disaster for customers that allow employees too much privilege to administer the service, or too much power to over-share data. Customers must take a more rigorous approach, automating some of the access management, application deployment or workload management functions and ensuring competent resources oversee what isn’t automated.
Above all, monitor. Cloud access security brokers (CASBs), such as CloudLock, can act as gateways between Internet access points, or proxies for mobile endpoints. In that position they can discover “shadow IT” cloud applications, provide single sign on to CSPs, and monitor user behavior. Other tools can collect logs and events from SaaS, PaaS or IaaS environments alike, enabling centralized reporting and alert review.