To say that RE:Invent was a shocking revelation for many 3rd party vendors/integrators/developers would be an understatement. However, this has become the norm when it comes to Amazon’s Cloud offering, AWS. Holding an annual convention for the past 5 years, they have redefined what it means to add features and react to an ever-changing and challenging market during this age of IT innovation and disruptive tech.
As CEO of AWS, Andy Jassy, said during the first keynote, “We are iterating at a faster clip than anybody.” From 280 significant features in 2008, to now over 1000 significant features, yielding an average of just around 3 new features a day, AWS truly has set a new standard in what it means to speak to your customers needs.
In line with the tradition at the annual RE:Invent, AWS announced a slew of new features and services to speak to their customer’s needs and progress an idea they have dubbed as “being transformers” in an ever-changing and adapting IT landscape.
Part of the focus during the keynotes revolved on how customers are demanding specifically what is being done to ensure that certain security measures are in place guaranteeing that their usage of AWS Services will not result in an increase of risk/attack vectors. In response to these customer demands and to bolster their offerings, AWS has announced the general availability of AWS Shield.
What is AWS Shield?
AWS Shield is a managed service, meaning they do the lifting for you while you offload the responsibility of Denial of Service attacks onto Amazon Web Services. Essentially, AWS’s intention at launch is to have the service active for users at the outset, then offer an advanced level that works in conjunction as an add-on to Elastic Load Balancing, CloudFront, and Route 53. These are the primary services dealing with the OSI model that AWS is concerned with when it comes to advanced security (more on this in a bit). Note that the primary notification engine for Shield will be built into CloudWatch, which is the real-time notification mechanism and communication gateway between yourself and the Threat Response Team for DDoS at AWS.
Currently the service is offered in two flavors AWS Shield Standard and AWS Shield Advanced :
AWS Shield Standard is active on the outset of your account and has no additional cost associated with the service. It is stated and designed to protect you from “96% of the most common attacks today” and gives examples of protecting the customers apps from HTTP slow reads, SYN/ACK floods, and Reflection attacks. What you mainly need to understand is that this protection is transparent to the ELB, CloudFront and Route53 services, as this is something AWS is already doing for their own network and requires no further mitigation or configuration by the customer.
AWS Shield Advanced takes it up a notch and provides additional DDoS mitigation capability for volumetric attacks, intelligent attack detection and mitigation for attacks at the application and network layers. AWS lends you a team around-the-clock, 24-hours-a-day for custom mitigation/response during attacks. AWS will also includes advanced real time metrics and reports via the AWS Shield dashboard and Personal Health Dashboard. Lastly, but most importantly, AWS gives you the piece of mind that you will receive DDoS cost protection to shield against bill spikes in the aftermath of a DDoS attack. The team will help you build custom-tailored ACL or Access Control Lists that will ensure to mitigate your Layer 7 attacks. WAF will be bundled into this level if selected and will not occur additional costs.
Why did AWS Launch AWS Shield and AWS Shield Advanced?
The particular threat model that AWS Shield addresses is the Distributed Denial of Service, better knows as DDoS.
A Denial of Service attack in its essence is used to overwhelm a server/service with more requests than it can handle, resulting in the server/service going down until the demand regresses to tolerant levels.
This is in particular an interesting use case to discuss for AWS, because while DDoS attacks may occur due to poor administrative/development methodologies, the larger set of statistics point more towards malicious attempts to obstruct the usage of a particular service without discrimination of that service’s attack vector.
This can yield in an exponential increase in costs when tied together towards the elastic environments Amazon’s Cloud offering gives, essentially playing against a customer whom may have configured their services to increase elastically by demand – but when the demand is artificially generated during a DDoS attack, this can leave the customer very vulnerable.
Essentially, AWS wants to focus on three different types of threat models/environments: Volumetric DDoS attacks, State-exhaustion DDoS attacks, and Application-layer DDoS attacks. Let’s break these down a bit further and reference the graphic showing how AWS has structured these threat models against the OSI Model:
Volumetric Attacks: Used to disrupt networks by bombarding them with more traffic than tolerable or by generating phantom queries that will flood a victim with an astonishing amount of low-level “surprise” replies (also known as Reflection attacks). They are essentially trying to flood the pipeline of your network and can be used for things like UDP reflection attacks.
AWS sees this revolving around the Network layer of the OSI Model.
State-Exhaustion Attacks: Exploiting the stateful protocols and generating pressure on firewalls and load balancers by reserving large numbers of per-connection resources. An example is to generate the TCP SYN but never send anything else after the initial packet, thus causing resources to be reserved but no further communication occurs.
AWS sees this revolving around the Transport Layer of the OSI Model.
Application-Layer Attacks: This is where AWS considers the more complicated attacks occur. These usually consist of well-formed but malicious requests (i.e. DNS queries and HTTP GETs) that are designed to consume application resources. For example, opening up multiple HTTP connections and reading the responses over the period of many seconds or minutes will reserve/consume excessive memory.
AWS sees this revolving around the Application Layer of the OSI Model.
In line with how AWS sees these threat models, they have shown that the primary threat lands with Volumetric attacks, resulting with an even split between State Exhaustion and Application Layer.
You can see that the features for AWS Shield Standard include protection for Volumetric attacks and State-exhaustion attacks and some Application Layer attacks (looks to be primarily DNS). The Advanced level will give you the full layer 7 application layer protection with an additional associated cost and also loss-mitigation or cost-capping protections (more on this next).
Pricing and Feature Structure
When accessing your account, you will be presented, as we have shown below, with a chart or info-graphic that shows the overall feature set for AWS Shield and AWS Shield Advanced.
You will notice that the bulk of the features, primarily those requiring hands-on or granular control, are listed within the Shield Advanced column. This means for you to get specific attention and protection you must first be using either ELB, CloudFront or Route53 products to gain access to Shield Advanced, and then have a cost that starts at $3000/month that will be additional to your AWS Services. Organizations must consider whether it is necessary to purchase AWS Shield Advanced to attain a greater level of protection then already provided.
That AWS Shield standard is provided with all services without any additional cost or configuration is a statement and really putting AWS in a position to squarely tell their customers we are there for you for anything you need, including development, deployment, support, mitigation, security and innovation.
Keep in mind the one key item that AWS is positioning as an advantage for the Shield Advanced level is the inclusion of the Web Application Firewall, or WAF, at no additional cost. This forces organizations to take a weighted and careful approach when analyzing risk mitigation vs. associated deployment costs.
Terms of Service/Service Level Agreement (SLA)
Upon account creation and service usage, a customer will receive AWS Shield standard automatically. Meaning, that the AWS Shield standard service gives you protection out-of-the-box and will be bundled as a further protection that will guarantee the service level agreements in the individual services being used. Essentially, before DDoS was either a third-party additional cost add-on or a risk taken by organizations by not implementing extra measures. Now this is no longer necessary: The initial risk is removed as AWS Shield Standard is automatically configured and activated.
Shield Advanced does require you to be using one of three services (ELB, CloudFront, Route53) to qualify and you also need to maintain a certain level of paid support with AWS. Once qualified, should a problem occur where AWS is not able to maintain the level of services guaranteed by Route53 or CloudFront utilizing AWS Shield, you will be reimbursed the costs incurred for each 24-hour period. This will be given to the customer in the form of “Service Credits” to be used or applied towards an AWS usage bill. A rather interesting approach when looking at the large costs for the service in addition to your current AWS usage costs when using Shield Advanced.
It looks like with AWS’s announcement of AWS Shield, 3rd party vendors that are currently occupying this space will need to ensure their market niches are cemented in their offerings. By bundling this into their product and also delivering high level attack mitigation, AWS is further solidifying its presence as a go-to resource for cloud computing in the modern technology environment.
It is a statement in itself to switch on DDoS protection for all of your customers on the outset of them simply opening an account with you, dealing a blow to 3rd party integrators yet intensifying AWS’s stance to their customers that they are there to back the customer and protect (or “Shield”) them.
From a simplistic view, the service basically provides real-time monitoring from AWS and 24×7 real human security experts bundled with cost-protection mitigation. The rest of the features are just a cherry on top of the cake. Building from the same model of off-loading the costs and migrating risks to external parties further decreases an organization’s attack and risk vector, it would really require a customer to justify the necessary additional protections beyond the given AWS Shield standard and whether the service’s premium additional costs are manageable. An enterprise looking to be agile and cost effective should definitely consider AWS Shield Advanced as a multi-talented product resolving numerous issues with effective cost savings and risk mitigation.
As it is against the terms and conditions for AWS customers to test or stress their networks beyond tolerable limits. We will have to wait for any real world use case scenarios, if ever discussed or publicly released, to see Shield Advanced really bringing value to the customer and determine whether the associated costs and service credits do provide a valuable measure of revenue mitigation when looking at revenue/reputation losses that may have occurred due to a breach of SLA post a DDoS attack on an active Shield Advance customer.