skip to Main Content

7 Interesting Findings On Cloud Security From the 2021 Verizon Data Breach Investigations Report (DBIR)

Verizon DBIR continues to be an extremely valuable analysis of security incidents and breaches year over year (and some of the embedded humor definitely makes for easy reading). Here’s what stood out in 2021 in relation to public cloud security:

1. Cloud Presence is Growing

This is not new news, but it’s important to recognize that “external cloud assets were more common than on-premises assets in both incidents and breaches… If it was not obvious by now, cloud assets deserve a seat at the grown-up security table and a piece of your budget pie.” Refer to page 20 of DBIR PDF.

Lesson:

There are still some who assume that public clouds are automatically or inherently secure. The cloud provider’s infrastructure is well architected and follows modern security principles. But even their IaaS and PaaS (together, 100s of cloud services) should not be trusted implicitly. Cloud providers are just like you and me (maybe a little better) – their software is also vulnerable. When it comes to your applications running on the cloud, be as vigilant as on-premises. Simply put: attackers will go wherever the crown jewels reside, public clouds are no different.


2. Ransomware

No longer is it about headline-grabbing but is also seen in data on verified incidents. Ransomware took 3rd place in confirmed breaches (10% of all), behind phishing and stolen credentials.  “These actors will first exfiltrate the data they encrypt so that they can threaten to reveal it publicly if the victim does not pay the ransom.” Refer to pages 16, 23, and 55 for double extortion tactics.

Lesson 1:

No decryption means no visibility & no protection. If you’re not inspecting encrypted traffic flows, you should. If not, bad actors can encrypt their traffic thus bypassing all protections to download malware from unknown C2 sites and exfiltrate your data to hold ransom. Quite simply – whether its malicious insiders or hackers, ransomware becomes much easier if you don’t apply a defense-in-depth approach: (a) stop their initial access or exploitation, (b) prevent lateral movement of attacks, (c) block their exfiltration to unknown destinations by FQDN and URL lists and categories, and (d) use DLP to detect sensitive data exfiltration. And, they will do this on encrypted communications like HTTPS/TLS.

Lesson 2:

As more assets move to public clouds, ransomware actors will adapt their techniques to the specifics of public clouds, from stealing cloud IAM credentials to moving laterally using assumed identities to exploiting the use of 100s of cloud services (aka PaaS) including databases, messaging queues, and storage buckets. We’ll cover more on the techniques, tactics, and procedures of ransomware in public clouds in a future article. 


3. Old is Gold

Attackers continue to exploit old vulnerabilities. “one might think that more recent vulnerabilities would be more common. However, as we saw last year, it is actually the older vulnerabilities that are leading the way.” Refer to pages 20-21.

(Figure 33 here for a higher resolution version)

Lesson 1:

This is no surprise. Attackers love a powerful vulnerability, such as Eternal Blue, with the breadth of target systems, and robustness of working exploits and payloads. Attackers seem to be counting on some people not implementing a layered defense in depth approach using advanced IDS/IPS and egress filtering to block command-n-control (C2). Recently, we’ve seen several new vulnerabilities such as Log4J, Azurescape, and OMIGOD. Each of these are very powerful in terms of their breath of target systems and impact of severity. 

These vulnerabilities were especially prominent in their potential impact on the services offered by public cloud providers. It is no longer sufficient to completely assume that in the shared responsibility model, cloud services (both IaaS and PaaS) themselves are automatically safe. 

Lesson 2:

While there is strong attention paid to new vulnerabilities and zero-days, not protecting against well-known attacks is a serious mistake. It is like closing your front door and installing fancy biometric systems but not actually locking the door, and then hoping that an intruder will not probe/test it. Simply put, automating virtual patching for known vulnerabilities and blocking known indicators of compromise (IoCs) such as malicious IPs, sites, and C2 allows security teams to focus on higher-value tasks.


4. Patching is Hard Work

This is no surprise, it takes a lot of time and effort to do this: finding vulnerable systems, testing patch compatibility, rolling them out during maintenance periods, and, often, repatching as in the case of Log4J. Refer to page 21. 

Lesson:

Patching every system for every vulnerability out there is practically impossible and perhaps insane. This does not change in any significant manner in public clouds either – despite some of the automation capabilities. DBIR recommends smart patching: do vulnerability prioritization and patch the most important ones first. We recommend a two-pronged approach to improve productivity: (i) use virtual patching across the board to protect against all vulnerabilities, this gives your security team time to find the vulnerabilities and (b) patch the ones that improve your actual security. 


5. Discover it All

Most organizations spend a lot of time to find out people trying to get in from outside (infiltration aka ingress attack). And then DBIR talks about organizations with sensitive data like healthcare and regulatory requirements needing detective controls to catch this kind of misuse. Refer to page 48. 

Lesson:

Strangely, DBIR mentions detective controls to find out this misuse but has no clear recommendation or call out on putting strong egress/outbound controls based on FQDN or URLs correlated with workload identifiers. 

Here are some example workload IDs, i.e. tags commonly used assigned to your cloud workloads that should drive dynamic egress policies: 

  • deployment stage: dev, test, prod, compliance
  • app-type: crm, erp, web, payment-gateway  
  • app-tier: frontend, app-logic, backend, database

This is especially important in public clouds whether it’s a lift-n-shift design or a modern DevOps-based CI/CD implementation of build, deploy/test, and run. Applications in public clouds use a variety of services, everything from GitHub to third-party services and cloud provider services (aka PaaS). The elastic nature of public clouds means your security policies should be dynamic as well. Simply put, dev workloads may be allowed full access to GitHub (github.com/*) to download and build/use any software/package, but production and compliance workloads must be limited to github.com/myOrgRepo. 


6. Attacks on Payment Card Apps are a bit more Sophisticated:

Compared to normal web apps seeing attacks on a few components, payment apps are a little more sophisticated: “attackers will exploit some vulnerability, then use stolen credentials or some other means to access the code of an e-commerce website that processes credit card data. By using that access to the code base or server, they will insert additional code that will ship off the payment data not only to the correct endpoint but also to their own servers, thereby quietly siphoning off valuable data.” 

Another nugget from DBIR 2021: “System Intrusion, Social Engineering, and Basic Web Application Attacks represent 77% of breaches”! Refer to pages 56 and 86. 

Lesson:

PCI-DSS requires a full defense-in-depth approach outlined in item 2 at the top. Anything less is a broken approach and asking for trouble (or making it too easy for the bad actors). But we all know that compliance requirements ask the bare minimum and cloud providers only meet the baseline compliance requirements for their infrastructure – you are still responsible for protecting your applications with a layered defense-in-depth approach. The lesson really is to think deeper about how to make defense-in-depth work more appropriate for the dynamic nature of public clouds. 


7. Small is Large

In 2021, compared to last year, the number of breaches and attack patterns are roughly the same across SMBs and large organizations. Refer to page 90.

Lesson:

The commonality of motivation (financial), attack patterns (System Intrusion and Basic Web Application Attacks), attack playbook, and increasing use of ransomware (yes, your local garage and dentist is a good target) means that SMBs can no longer assume that they can skate-by in the assumption that bad actors only target big companies (thank you Bitcoin?). What is different is that SMBs have not woken up; case in point: large orgs are able to find breaches faster (in days) than SMBs. 

But SMBs, and also a lot of large organizations, have significant technical debt, low resource availability, and tight business deadlines to meet. What is needed are platforms that can help them simplify cloud network security. Valtix provides a Free Tier that could enable many SMBs depending on their scale requirements.

Final Summary 

DBIR 2021 adds a new category “System Intrusion” that is explained as “a Hacking action paired with a Malware action. We typically see the Use of stolen creds to gain access, followed by the actor dropping Malware to further their aims in the organization.” System intrusion is the top attack vector across verticals, org sizes, and geographies. This trend shows that threat actors have more capabilities, tools, infrastructure, and patience than in the past.

And, most importantly attackers are noticing the growth of applications in public clouds (point #1), recognizing the challenges in patching (#4), the difficulty of visibility (#5), and the targets (#6 and #7). The only sane response is to review, get better awareness and look for comprehensive security that a defense-in-depth approach provides. 

Latest Posts

Back To Top