Cloud Hosting

Many modern organizations are migrating their infrastructure and systems to the cloud. AWS, like other cloud providers, has a Shared Responsibility Model that determines which cloud components AWS is responsible for securing and which are the customers responsibility to secure. Lets take a look at what this model means, its many challenges and how organizations can better protect their cloud infrastructure and improve their cloud security posture.

The AWS Shared Responsibility Model is a framework by AWS that determines which cloud architecture components Amazon, as the CSP (Cloud Service Provider), is responsible for securing, and which are the customers responsibility to secure. As a rule of thumb, AWS is responsible for security of the cloud, and the customer is responsible for security in the cloud.

Breaking that down, AWS is responsible for the host operating system, the virtualization layer and the physical security of the cloud servers. The customer is responsible for protecting the rest which is not a trivial amount of security ownership including network controls, configurations, IAM and customer data.

AWS Shared Responsibility Model [Source: AWS]

While structured and seemingly self-evident (i.e. everyone knows what is theirs to do security-wise), the shared responsibility model with AWS comes with considerable challenges.

First and foremost, many cloud customers do not understand the model or are even aware it exists. Some cloud customers may have the false sense that the CSP takes care of cloud security as part of the services and tools it provides. Others are not sure about the division of responsibility, i.e. the scope of their responsibility vs. that of the CSP. And there are gray areas, such as how to handle networking security given that both parties share responsibility for it.

In a recent IDC survey commissioned by Ermetic, a senior security decision maker noted that clarity regarding system security responsibility with cloud vendors and support is a big concern.

Contributing to the lack of clarity is that the level of security responsibility differs according to the kind of cloud service acquired: IaaS and PaaS require more security ownership by the customer whereas SaaS requires the customer to do almost nothing.

In a recent podcast, AWS security consultant Scott Piper notes that shared responsibility is a misnomer and should more accurately be called split responsibility. Piper points out that the model has no sharing or collaborative aspect just the responsibilities of the provider and the responsibilities of the customer, with no watchful eye by the provider ensuring that security problems or gaps arent created.

To complicate things further, each public cloud provider has its own shared responsibility model. The same area that one CSP designates the providers responsibility, another CSP may designate the customers responsibility or that of both. In the case of IaaS, broadly speaking, securing the physical aspects of infrastructure control falls to the CSP and securing the configuration and inner workings of the provisioned cloud resources falls to the customer.

Digital transformation accelerated by COVID-19 has caused many organizations to expand their move to the cloud. However, with this transformation so relatively new, these organizations internal company knowledge of managing and maintaining cloud infrastructure is still being developed. As a result, many such companies lack the expertise and bandwidth to identify, understand and solve the challenges of cloud security and shared responsibility.

For example, the IDC survey found that 50% of companies did not succeed in implementing the principle of least privilege a pillar of cloud security. They are failing at this important strategic initiative due to the difficulty and time it takes, lack of personnel or expertise, and multi-cloud difficulties.

Another reason the AWS shared responsibility model is challenging is the lack of tools available for consumers to secure the areas of shared responsibility that they own. According to Latch, an enterprise SaaS innovator in the building sector, Its a real challenge to find cloud-native security solutions that really work.

In addition, AWS does provide a growing array of security tools, such as for granting and controlling permissions IAM Policy Simulator and AWS Access Analyzer to name a couple. While these native tools do not answer all modern cloud security needs or even fully cover the customers shared responsibilities, customers may think they do. Also, native tools require much labor and expertise, so organizations may not be using them to the fullest. In fact, it happens that many organizations that implemented commercial and free of charge CSP tools were breached, and had sensitive data compromised.

The recent introduction of cloud security to organizations has also raised new questions about cloud security ownership within an organization. While security was traditionally the hands-down responsibility of IT or dedicated security teams, today, multiple divisions, departments and/or roles are involved.

The same survey found that the professional roles involved in cloud infrastructure security are diverse, and can include IT/Operations, DevOps, Cloud Security, Development/Engineering and IAM Security. According to the study, this diversity of security ownership within the organization results in fragmented decision making, siloed security practices and difficulties in implementing security across the board. These internal realities, together with the complications of a shared responsibility model, may inhibit or at the very least complicate implementation of proper cloud security practices.

Many organizations today are meeting their needs by deploying multiple cloud environments: AWS, GCP, Azure and others. Native security tools are cloud specific by nature, are at different levels of maturity and do not cover multi cloud use cases. In the above mentioned podcast, Piper recognizes the challenges in using the same solutions for multiple clouds and the difficulty in gaining an aggregated, consistent view across all the clouds in use.

These challenges create an acute need for unified multi cloud solutions that can see deeply into each public cloud and help address each clouds shared responsibility requirements.

Due to these challenges, many organizations are not properly handling their share in the security of their cloud infrastructure. This lack of adequately securing what falls to them to secure, including network controls, configurations, IAM and customer data, puts the organization at considerable risk of having identities and their entitlements exploited, and sensitive data compromised upon a cloud data breach.

The risk is not theoretical. According to the IDC survey, 98%(!) of organizations suffered a cloud data breach in the last 18 months. Getting breached is almost a given in todays hyper-hacked cloud world. More importantly, 63% of organizations had sensitive data exposed in the cloud and that number ballooned to 85% for companies with large cloud footprints. This means that these organizations were not correctly identifying and mitigating the risks of access to their sensitive data. These failings can have significant business implications and penalties in the long-run.

Why was their sensitive data exposed? The same survey found that 71% were using their cloud providers commercial security tools and 68% were using their providers free tools. This heavy reliance on cloud provider tools brings us back to confusion around shared responsibility. Organizations are possibly unclear about the capabilities of these tools for ensuring cloud infrastructure protection or are not putting in place the appropriate solutions to carry out their shared part in the fray or both.

Cloud security tools in use or planned for use by organizations [IDC State of Cloud Security 2021]

Half the battle is understanding your organizations shared (or split) security responsibilities. The other half is effectively addressing them. Relying on native tools alone to cover your cloud infrastructure security responsibilities is not enough. Failing to implement more substantial solutions can lead to serious data compromise and business impact.

So where do you start? Find an identity focused solution that tackles the leading risk to cloud infrastructure permissions to reduce your cloud attack surface at scale and address compliance. Gain a complete view into your cloud assets so you can assess and report on risk, with step by step remediation. Later, bring least privilege automation to engineering, preventing risk from the get-go.

The post The AWS Shared Responsibility Model: Everything You Need to Know appeared first on Ermetic.

*** This is a Security Bloggers Network syndicated blog from Ermetic authored by Ermetic Team. Read the original post at: https://ermetic.com/whats-new/blog/aws/the-aws-shared-responsibility-model-everything-you-need-to-know/

View original post here:
The AWS Shared Responsibility Model: Everything You Need to Know - Security Boulevard