Not all data breaches are created equal.

While many remain the product of technical prowess so often associated with malicious actors, a burgeoning amount can be attributed to security misconfigurations and overly-permissive entitlements plaguing cloud ecosystems around the globe. Close to 70 percent in fact, according to a survey conducted by Ermetic, an identity and data protection firm.

Furthermore, with the exponential expansion of cloud-native applications and similar undertakings, many organizations often rush to deployment overlooking critical security cross checks that expose a greater attack surface than most stakeholders are willing to admit. These largely unforeseen areas can quickly become the Achilles' heel of any security program as traditional endpoint protection solutions and other security measures remain largely impervious to their presence.

In this blog post, we will explore five of the most common (and likely most damaging) misconfiguration errors associated with popular services featured by Amazon's AWS cloud offering. For this purpose, we examine them in light of what AWS considers best practices surrounding the proper use of these technologies, showcased by a handful of breach reports that attest to their undisciplined provision.

Misunderstanding the shared responsibility model

AWS's shared responsibility model is the foundational agreement between the cloud service provider and its customers that defines the distribution of responsibilities associated with security and compliance.

Following this model, customers are relieved of the operational burden of maintaining and securing the controls and components below the operating system and virtualization layers, diminishing the possibility of a security breach due to potential hardware vulnerabilities. This is commonly referred to as Security **of** the Cloud, in stark contrast to Security in the Cloud, which establishes that customers are ultimately responsible for additional services such as application software and any related security group firewalls.

In addition, AWS has further divided the model into three distinct categories:

Infrastructure services.

Container services.

Abstract services.

Unfortunately, adhering to any one of these categories is no easy task. According to Cloud Security Alliance, the "trick" is to understand where your service provider's responsibilities end and where yours begin. Failure to properly identify these subtleties is certainly a recipe for disaster; one that can severely impact IT operations and even put your entire enterprise at risk.

Take for example *container services*, a category that shifts focus away from infrastructure as a service (IaaS) towards platform as a service (PaaS), moving the responsibility model in the direction of the service provider and partially adding to their bucket important considerations (should a data breach ever occur) such as incident response and cyber forensics. As part of the tradeoff, however, the customer is still responsible for access management using the control plane to secure any related applications, data, and user activity.

In addition to the direct connection between AWS and customers, the shared responsibility model may need to account for differences within a specific organization—particularly those involving third-party vendors and similar entities with access to develop, manage or secure aspects of the cloud environment. All this added complexity leaves ample room for ambiguity, but at the same time, it provides an opportunity to highlight potential areas of the business in desperate need of gap analysis.

Without further ado, here are the top 5 misconfigurations.

1. To encrypt or not to encrypt

Encryption is paramount to confidentiality and integrity; two of the most important tenets of adequate data protection, whether in-transit or at-rest. Everyone in this industry knows that—or *should*. Yet many organizations fail to realize the impor...