It’s no secret that Amazon Web Services (AWS) helps to run a wide swath of the web’s most popular websites, services, and applications.
However, the rise of cloud services has not gone unnoticed by hackers, who have broadened their scope from traditional applications and infrastructure to cloud environments.
Providing an adequate infrastructure as a service (IaaS) and ensuring the entire system can run critical business applications for some of the world’s largest banks, government entities, and streaming services securely is no small challenge. Their failure could do untold damage and interrupt service for millions, perhaps even billions of internet users.
Introducing the AWS Shared Responsibility Model
As a provider for cloud-based web services to millions, Amazon has made extensive investments in cybersecurity as its services have grown and matured over the years. A cornerstone of their security approach lies in their shared responsibility model: AWS assumes responsibility for the physical security of their infrastructure and services, but tasks the correct deployment of AWS environments – including configuration and successful security maintenance – to customers. In other words, AWS secures on the cloud, but consumers must secure what they keep in the cloud.
For organizations looking to move development to the cloud, we’ve put together a rundown of the reasons behind Amazon’s model, how it works, and how organizations can keep up their part of the bargain.
Overview of the Current Threat Landscape
In adopting the shared responsibility model, Amazon has correctly identified the highest risk to compromise their systems: the likelihood of unintended consequences from unwise security decisions on behalf of their customers.
Over the past decade, cybersecurity incidents have grown both in frequency, sophistication, and severity. Since 2015, the number of yearly cyberattacks rose to 1.473 billion in 2019, an approximate 189% increase from 2015, according to records available on Statistica.
However, as research from Kaspersky Labs has found, security incidents in public cloud infrastructure are more likely the result of consumers than the cloud provider. On closer review, 90% of all corporate data-breaches in the cloud occurs due to human error.
What’s more, these incidents appear to derive from accidents that are more negligent in addressing best practices than accidental keystrokes, with 60% of breaches involving vulnerabilities for which a patch was available but not applied.
If that weren’t enough, most organizations are also prohibitively slow at identifying cybersecurity breaches once they’re underway, taking the average business 280 days to identify and mitigate a breach, according to IBM.
Amazon Shared Security Model Overview
As we mentioned above, the AWS shared responsibility model largely tasks Amazon to secure and standardize its infrastructure, while leaving the maintenance of inputs and updates to clients. AWS takes ownership over the data centers you’ll use, including:
- Physical access
- Backup data centers
- Generators
- Uninterrupted power supply systems
- Air conditioning
- Fire suppression, among many others
You’re Responsible for What You Put Into the Cloud
AWS has devised three main models for shared responsibility, which vary based on the type of service used. They are as follows:
- Shared Responsibility Model for Infrastructure Services: Users are responsible for server-side encryption, OS security, network security, firewall configuration, network traffic protection, and application security and identity access management. The platform covers the security of their data centers in the cloud, both physical and otherwise. Infrastructure services include AWS applications like EC2.
- Shared Responsibility Model for Container Services: Here, responsibilities are much the same, with a few notable exceptions. AWS covers platform and application management, but customers are additionally responsible for firewall configuration. Container services include AWS Relational Database Service and AWS Elastic Beanstalk.
- Shared Responsibility Model for Abstract Services: Much like container services, this model places even more responsibility on the platform side, adding network traffic protection to their responsibilities. As with Infrastructure services, though, this includes the addition of identity access management applied at the user and group level. Abstract services include Amazon DynamoDB, Amazon Glacier, and Amazon Simple Storage Service (S3)
Ultimately, it’s in the user’s best interest to understand the evolving attack surface, assess how to use AWS tools, and fill in any feature or security gaps with third-party security services, which should help alleviate any burden placed on internal delivery and operational teams.
Vulnerabilities Specific to Cloud Services
As today’s businesses increasingly move their workflows, infrastructure, and critical processes to the cloud, they often face an unknown environment, and one’s whose security considerations may appear counter-intuitive.
Mainly, those new to cloud-based workflows are additionally unaware of related security concerns and develop a false sense of security that may lead to careless accidents. Such services need to be reconfigured in accordance with an overall security strategy that covers vulnerabilities – existing and as they arise.
Or, as put by Amazon’s president of security engineering, Steven Schmidt:
“When customers neglect to keep up their side of the SSRM, they’re unwittingly putting their businesses at risk from potential vulnerabilities that come with the cloud’s larger attack surface.”
Which Vulnerabilities Are Specific to the Cloud?
Cloud environments are vulnerable in particular to containers used to host cloud-based servers, databases, including OS exploits, container breakouts, denial of service attacks (DoS), embedded malware, and credential theft. Each of these has been known to lead to data breaches, and systems must be created, configured, management, and updated regularly.
This trend appears to be on the rise, too. Vulnerabilities for container services grew 240% in the two years preceding 2019, according to a threat study reported on by Forbes. Yet, despite threats mounting year after year, this study additionally found that only one in four organizations see a lack of staff expertise as a top concern.
Protection against such incidents isn’t helped by the fact that 92% of respondents surveyed by Oracle and KPMG for the Cloud Threat Report 2020 admitted to having a “gap between current and planned usage and the security of their cloud security program.”
Furthermore, Oracle and KPMG uncovered that confusion plagues cloud service consumers. Sixty-seven percent of survey participants found shared responsibility for securing their software as a service (SaaS) most confusing – a 13% increase upsurge over the previous year. A mere 8% of respondents said they fully understand the shared responsibility model for all types of cloud services, a drop from 18% in 2019.
While cloud migration is accelerating, organizations need to gain a clear understanding of the shared responsibility model that pertains to them – it is nothing less than foundational.
Strategies for Tackling Security in the Cloud Age
First, you’ll need to assess your current infrastructure for vulnerabilities. For this, we recommend implementing a thorough threat modeling practice. For the uninitiated, threat modeling is a process that involves the cataloging of all network endpoints, communication flows and interactions within an environment, noting all known threats (attack surface vectors) associated with that environment, and then resolving those vulnerabilities.
Within your cloud environment, you’ll want first to inventory the assets comprising the top three layers of the AWS cloud environment – the controls you’re responsible for in Amazon’s shared model. The top three layers include apps, hosts, and networks, which require regular upkeep.
Next, AWS users should work on the prioritization of known threats. Note here that risks should be prioritized by severity on top of their likelihood of occurring, as proactive threat hunting requires a focus on the most potentially damaging security events.
Finally, you’ll need to ensure the proper security at every stage of the development project, through the utilization of threat modeling, whether automated or manual, during the design stage of any development work.
What’s more, you’ll find that AWS provides its own tools to aid in the securing of your cloud environment. In 2019, for instance, the cloud giant created the AWS Security Hub. This service automatically aggregates, prioritizes, and normalizes findings in a wide range of AWS and AWS partner security solutions.
AWS Security Responsibilities
Much like the platform itself, AWS security considerations require forethought and planning. Through a combination of threat modeling, perimeter and practice security, organizations can find themselves in firmer footing than many of their laxer competition.
Perfect security isn’t required, after all, and much of the work has been done for you, as Schmidt noted.
“We don’t solve all problems. What we do is give you a foundation that you can trust and depend on, and that means your staff doesn’t have to pay attention to that anymore. They can focus their energies on the piece that’s above what we do and that dividing line does change based on the individual service.”
Do Your Part in Shared Responsibility: Use ThreatModeler to Seamlessly Identify, Prioritize and Mitigate Threats
ThreatModeler was tapped by AWS for a joint offering that enables DevSecOps to expedite workload migrations to the cloud with security built-in. This proactive, self-service practice reduces time spent on security control decision making, empowering teams to build accurate threat models and rapidly design secure applications for Cloud Development Life Cycles (CDLC). ThreatModeler can ensure that your organization plays its part in shared responsibility as a cloud customer by applying the appropriate security layers across your organization.
ThreatModeler is the first and only automated platform to accelerate the design, build, deployment and management of secure applications and underlying infrastructure. ThreatModeler enables visual simulation of an ecosystem’s systems, applications and process. Through its unique, patented features, ThreatModeler enables you to import third-party files (such as Visio and TMT) to create complete, accurate threat models.
With a full diagram of the attack surface, teams can uncover threats and display all attack paths that can potentially compromise components. The next step is to prioritize risk from highest priority to lowest and send it down the CI/CD toolchain for threat mitigation so teams can code with security built-in.
With threat chaining, another patented feature, DevSecOps can now take a created threat model and save it as a Component in the ThreatModeler Toolbox library. Once nested in a new threat model, all threats and security controls are automatically applied across the enterprise, yielding a macro view of how your threat model mitigates threats downstream against your colleagues’ threat models, at scale. If any team member makes a change to the component, the alteration is reflected in all threat models in which it is contained. This reduces human error and enables for a more holistic mitigation of threats.
ThreatModeler’s joint offering with AWS ensures that what you’re putting in the cloud is secure. With its Drift feature, the platform alerts teams to any changes as soon as they’re made in an AWS architecture. Made aware of the changes automatically, architects can assign the security controls needed so that it stays secure. Furthermore, as part of its Drift feature, ThreatModeler keeps updated with any service additions, including threats and security controls, through its integration with AWS Config, AWS Security Hub and others.
To learn more about how ThreatModeler™ can help your organization build a scalable threat modeling process, book a demo to speak to a ThreatModeler expert today.
Watch our webcast, How to Automate and Accelerate the Design of Secure AWS Cloud Environments featuring panelists from AWS, BlackRock and Intuit.