Resources

Uptic //Blog

Nicky Willebrand
Passionate about all things cloud, security and automation. I hold cloud, security, and DevOps certifications across AWS, Azure, and GCP along with deep experience gained working for cloud & security service providers and for global finance organizations.

Top 5 Cloud Security Threats for 2021

It’s not uncommon for some security vendors and security service providers to generate demand for their products using recent vulnerabilities. But I personally find that approach massively unhelpful to the development, operations, security, and compliance teams that build, manage and secure cloud infrastructure, services, and applications daily.

Rather than sensationalize security threats, I wanted to share my own experiences, and the insights of our cloud teams, gained while working on client’s cloud, DevOps, and security projects.

In this blog, I’ll share that the biggest security threats we encounter do not originate from bad actors, state sponsored agencies, or even script kiddies with port scanners and enough knowledge to be dangerous - even though these groups may ultimately be the ones that commence an attack and cause damage. Rather, the biggest threats to your security result from how you approach security. Let me explain what I mean as we step through a summary of each threat.

 

Threat #5 – Lack of Security Incident and Event Management (SIEM)

A defense in depth approach to security has been best practice for a long time. But many organizations who adopt this approach lack the successful implementation of a central SIEM platform, or lack a SIEM entirely, that can make the wealth of security data meaningful and actionable. A SIEM can provide context and intelligence to individual alerts, determine real threats vs false positives, help prioritize resources during incident response, and power automated remediation.

The lack of SIEM often manifests itself as:

Out of context alerts: each point security product generates its own alerts and notifications
Alert storms: the volume of alerts overwhelms operations teams
White noise: teams ignore or tune out alerts and are unaware of actual threats
Ineffective detection and response: when a real threat or breach happens, teams without a SIEM are slow to detect, respond and remediate

Even where SIEM is deployed, an important capability is often overlooked, resulting in a missed opportunity to illuminate a critical blind spot. And that is the capability of a SIEM is to ingest security events and logs provided by AWS, Azure, and GCP cloud platform APIs to further enrich the SIEMs intelligence precision and effectiveness.

 

Threat #4 – Poor Identity Management, Access Control, and Auditing

I’m personally surprised at how extensive the ‘we trust our employees’ attitude is that I encounter when assessing cloud environments. You should trust your people, but you should not necessarily trust their identities or activities when identity is the primary access key to your virtual datacenter. We wouldn’t give datacenter keys to every employee, and we shouldn’t give away our virtual datacenter keys in the Cloud. Development and DevOps teams appear to be more susceptible to this ‘trust our employee’ approach more than traditional operations teams, but it’s not exclusive by any means.

The cloud has resulted in more resources becoming increasingly public by nature, with identity being the main form of protection and access to these resources. Therefore, it’s critical to rigorously protect identities, including avoiding a culture of lax standing permissions. It should always be assumed that any identity has been breached and thus it’s of utmost important to control the resulting blast radius.

When running compliance software in client cloud environments we nearly always find a treasure trove of identity related issues, including:

  • Active user accounts for third parties that no longer require access
  • Root account usage (AWS specific)
  • No multi-factor authentication (yes, not just on Service Accounts)
  • User accounts that are used by more than one person, often entire teams
  • Global standing permissions rather than timely, and time-limited, permissions when required
  • Reader permissions when not required

The last one is particularly interesting. ‘Reader’ permissions might allow access to data-plane of services, whilst in many cases only the metadata of a service might need to be viewed (I.e. the Security Auditor IAM policy in AWS might just be enough for that third party audit). Don't hand out native Reader permissions without understanding the goal of the action and be mindful about data-plane access.

In an ideal situation identities should adhere to the ‘principle of least privilege’ as the blast radius control mechanism, by providing access:

  • At the minimum privilege level required
  • Only when access is required
  • Only for the duration access is required

 

Threat #3 – Audit driven security and lack of automation

It’s an unfortunate and common occurrence for security and compliance activities to be driven by an upcoming audit. Compliance isn’t the end goal of security, security starts with compliance, and security shouldn’t be a checkmark.

By far the most secure, low risk environments we encounter are those where security policies and desired platform state are defined first and then implemented and enforced by security products and environment settings.

Further, by continuously automating and enforcing these security policies and desired states across infrastructure and applications stacks:

  • The environment remains secure throughout it’s lifecycle, not just day 1
  • Security audit preparation is simplified and requires less effort
  • The audit process is compressed, and iterations reduced
  • Remediation work is minimized by enforcement at deployment time (i.e., with Azure Policy)
  • The inefficient and endless ‘scan-fix-drift’ cycle is finally broken

But perhaps most importantly, automating compliance provides a real-time view into compliance status. By identifying infrastructure or application components when configurations drift, become non-compliant and pose risks that could be exploited, teams are able to focus their efforts to patch, update, and reconfigure these components to maintain security.

 

Threat #2 - Security as bolt-on

The cloud promises speed, agility, and scale. But there is also the incorrect perception that the cloud is secure by default. With the seemingly endless resources available to AWS, Azure, and Google Cloud, how could their cloud platforms not be secure?

The shared responsibility model operated by AWS, Azure, and GCP makes it clear that the underlying cloud platform is secure. But cloud configuration, applications and data that reside on top of their cloud are the responsibility of their customer.

Often customers deploy their cloud infrastructure and applications and only then realize the true extent of that they are responsible for, and typically lack the skills, resource, and experience in the complex and unfamiliar world of cloud security.            

But bolting on security products to an insecure cloud design is equivalent to installing a burglar alarm on a tent. No amount of security products added to a cloud design that is flawed will provide adequate protection.

Instead, make security a standard parameter of your service design by asking questions like:

  • Does this service need to be public? Or can it reside inside of a network?
  • Can I do without local accounts? (think databases)
  • Have I onboarded proper activity logging standards?
  • What level of privilege is required and how can I minimize standing privileges?
  • Can I use paradigms like just-in-time access and privileged identity management?
  • Can my systems be onboarded into patch management?

 

Honerable Mention - Unpatched systems

Patch your systems please. I've yet to encounter a fully 'cloud-native' environment without some IaaS deployments. The attack surface of a Virtual Machine is far larger than that of stateless, serverless workloads as more control comes to the customer to implement proper standards. Something that helped me 'sell' patches on production systems is to always enable a High-Availability pattern on for instance your IIS server. This means that even if 1 server goes down, due to patching (woohoo!) the other server would still serve traffic. 

Try to make sure that services that require a form of patch management allow for downtime, otherwise keeping a vulnerability unpatched due to risk of downtime becomes a nasty discussion and leaves you at risk to the vulnerability. 

Threat #1 - Misconfiguration

Operating in the cloud requires very different skills, experience, and thinking compared to traditional on-premises and virtualized environments.

The cloud is agile because there are so many settings and configuration options available at your fingertips to customize how you want your specific cloud to function. But because of the plethora of settings across hundreds of cloud services it becomes so much easier for misconfiguration to occur and a security risk to arise. Just look at one of the most widely used cloud services, AWS S3 buckets, to see the number of instances were a simple misconfiguration resulted in public access and data stolen. In these cases, it was just simple human error due to a genuine mistake or lack of training and awareness.

The single most effective approach to alleviate misconfiguration is through automation. Humans are slow and prone to mistakes and distractions, whereas machines are fast and produce predictable outcomes.

Automating deployment through Infrastructure as code, Platform as code (including security), and Compliance as code ensures that all environmental settings and variables are secured before they’re deployed. These development paradigms support the shift-left security model which makes Security part of your development cycle at the start of the journey rather than a gatekeeper at the end. This enables organizations to leverage the speed, scale, and agility of the cloud while always maintaining security and visibility.

 

Summary

A lot of what we talked about earlier is based on shifting security left and zero trust. These are not new paradigms, a lot of their footing comes from older more tried and tested ways of working, but the Cloud actually enables these paradigms. By embracing proper CI/CD standards, enforcing a certain state of an environment and always thinking least privilege organisations will diminish their attack surface by a large amount.

Like what you read? Sign up to receive new blogs direct to your inbox