Two Main Takeaways from the 2020 DBIR for Cloud Security

If you’ve been hiding under a rock for the last 13 years, let me share with you that the Verizon Data Breach Investigations Report (DBIR) is the longest running data-driven report on the state of information security. It is highly respected because of the sound statistical methodologies used, the quality of the teams behind it over time, and the uniquely rich data set contributed by Verizon and hundreds of relevant contributors.

I am very passionate about the need for making data-driven decisions in the realm of information security. So much of what passes for wisdom in our industry reminds me of the pre-scientific evolution of medicine. We need well written, properly executed studies using good data sets, like the DBIR and the many reports published by others such as the enlightened folk at Cyentia Institute. These reports are a breath of fresh air and give me hope that we can make better decisions going forward.

In this post, I will highlight my own personal and subjective selection of the two most relevant lessons learned for cloud security on the recently published 2020 edition of the DBIR.

The Reign of Pain Falls Mainly on the Control Plane

There is a clear theme on the 2020 DBIR around the use of illegitimately obtained credentials. So let’s see what the DBIR has to say about how often stolen or lost credentials were used in the actual breaches they studied:

“… it must be said that Hacking and even breaches in general (at least in our dataset) are driven by credential theft. Over 80% of breaches within Hacking involve Brute force or the Use of lost or stolen credentials.”  2020 DBIR page 19

“Cloud breaches involved an email or web application server 73% of the time. Additionally, 77% of those cloud breaches also involved breached credentials.”  2020 DBIR page 27

‍

One of the most relevant things about cloud security is that there is this entire new attack surface comprised of the cloud service provider’s APIs, commonly called the control plane. Differently from the management interfaces of on-premises IT infrastructure, the control plane is Internet accessible, shared by all customers and widely known and documented.

This clearly underscores how critical the issue of access control is in general, but much more so in the cloud’s control plane. An attacker that manages to obtain credentials can much more easily use them in the cloud than in on-premises management UIs. After all, on-premises management systems typically are inside a perimeter, and vary from company to company as to what technologies, version and flavors are deployed, and where they are located. Just finding the relevant internal targets can be a time-consuming and noisy endeavor for an attacker, no so with the cloud service provider APIs.

You need to plan for and design preventative and detective controls to prevent against control plane abuse, such as:

• Enforcement of 2-factor authentication for all;
• Granting the least amount of privileges possible to people and systems, and enforcing environment-wide guard rails that will limit actions even if excessive privileges are given to individual identities;
• Integrating control plane access to an identity provider / directory to leverage existing access monitoring and revocation;
• Limiting the storage of long-term control plane credentials in user endpoints;
• Detecting the accidental disclosure of credentials, such as developers inadvertently commiting them into code repositories or providing them to phishing web pages;
• Logging and detecting suspicious login and privileged activity;
• Implementing adequate endpoint security and monitoring particularly for users that have privileged access to your control plane.

To Human is Err

The 2020 DBIR highlights that error, misconfiguration and accidental publishing of information are often involved in breaches and incidents:

‍“Errors definitely win the award for best supporting action this year. They are now equally as common as Social breaches and more common than Malware, and are truly ubiquitous across all industries.”‍

“In Figure 14 you can see that since 2017, Misconfiguration errors have been increasing. This can be, in large part, associated with internet-exposed storage discovered by security researchers and unrelated third parties. While Publishing errors appear to be decreasing, we wouldn’t be surprised if this simply means that errors formerly attributed to publishing a private document on an organization’s infrastructure accidentally now get labeled Misconfiguration because the system admin set the storage to public in the first place.”  2020 DBIR page 14

‍

Keep in mind these figures include cloud and on-premises breaches. However, I would hazard a guess that if the numbers for cloud were separated, they would be worse than the on-premises ones.

The cloud ecosystems are relatively new, incredibly complex, and still evolving rapidly. It is simultaneously very new and little known to many IT and information security professionals, and also deceptively easy to use for rapid development and deployment of new projects and systems.

I’ve anecdotally run across many incidents were developers themselves, with little or no operations or security experience, were tasked with creating and operating cloud infrastructure.

This combination makes misconfigurations and errors particularly frequent and impactful on cloud environments. S3 buckets and unauthenticated databases such as Elasticsearch instances are very commonly featured in headline-grabbing stories of high-profile security incidents. But lesser known issues such as public disk images can be just as damaging.

This is in part due to the fact that the cloud is again not just a SaaS version of the same things we did on-premises. Some deeper changes are at play here. For example, it’s usually Operations that are formally responsible for patch management. But with containerized applications, Developers are writing the Dockerfiles and deciding with OS packages are installed inside the containers. Similar issues might occur with Infrastructure as Code as well.

Cloud is a new and exciting field, but the existing talent pool is truly small and investments in this area are sorely needed so people know what to do. I find it truly shocking how little investment companies are making in proper hands-on cloud security training. Also shocking is how much of the available training material is purely functional, and even some of the best providers blatantly teach people how to use the cloud in an insecure fashion.

Organizations should attack this issue on many fronts:

• Ensure you have proper governance in place for how to deal with cloud environments, with an updated view of roles and responsibilities that will impact budget, processes, tooling and auditing.
• Train your Operations, Development, Architecture, Security and Audit staff in cloud security. Prefer hands-on courses taught by information security professionals, such as the ones offered by SANS, Securosis, Summit Route or (shameless plug) Tenchi Security.
• Use continuous automated monitoring of cloud security posture, for example deploying a commercial or open-source CSPM solution.
• Logging and monitoring can always help detect access to accidentally exposed data or misconfigured services, so that a swift incident response can mitigate the impact of a breach.

Alexandre Sieira is the Founder of Tenchi Security, and a former Senior manager and global leader of the Managed Security Services – analytics products under the Detect & Respond portfolio tower at Verizon.