Security Policies in AWS
There are common security policies and practices that you should be aware of when operating AWS solutions. This section of the chapter covers some of the more important ones.
The distributed denial of service (DDoS) attack is one to be feared. Famous examples of this attack include stories about how huge chunks of the entire Internet itself were made unavailable for relatively long periods of time. Just like with a regular old denial of service (DoS) attack, the goal is resource exhaustion so that disruption is in place for legitimate traffic that is attempting to flow or access a service or resource. Having many systems (potentially) participate in the attack (DDoS) can make the attack that much more effective due to the increase in frequency of the communications.
It is worth restating for clarity—there are two main and related objectives behind DDoS (and DoS):
Exhaust resources on the server side of the computing model.
Once exhaustion occurs, disrupt desired traffic flows or requests.
We often use the Open Systems Interconnection (OSI) model in order to help us think about and mitigate DDoS attacks. Figure 5-3 shows the OSI model.
FIGURE 5-3 The OSI Model
DDoS attacks that tend to focus on the lower layers (1 through 4) of the OSI model are often called infrastructure attacks, whereas upper layers that come under attack are referred to as application-layer attacks. An example of a Layer 4 attack might be a SYN flood or an amplified UDP reflection attack. An attack at Layer 7 (Application) might be an HTTP flood.
Let’s examine one of these in more detail. In an amplified UDP reflection attack, the attacker uses the connectionless UDP protocol to ask a server for some piece of information. The attacker forges the packet header so that it contains a different sender address. The machine that receives these “spoofed” packets will send a response back to the forged source address.
ICMP, NTP, DNS, DHCP, TFTP, and many more are all examples of UDP services that, if left unchecked, can be abused. Depending on the command sent and data requested, the amplification ratio can range from 2× to over 200×. This is to say that the attacker sends a small request to the vulnerable server, and the server sends a much larger response to the target system.
Fortunately, AWS knows of these many potentially devastating DDoS attacks and includes some powerful protections for us for free, as well as ensures these protections are in an always-on state.
AWS Shield Standard
If you are using the AWS services of Route 53 (DNS) and CloudFront (CDN), you are already taking advantage of the free DDoS prevention methods of AWS Shield Standard. AWS engages in powerful protection methods for these services that include powerful network flow monitoring as well as protection mechanisms against Layer 3 and Layer 4 attacks. For example, the amplified UDP reflection attack described previously should be blocked thanks to the default behaviors of AWS Shield Standard.
AWS Shield Advanced
While it is not free like the AWS Shield Standard’s functionality, you might be compelled to take advantage of the more advanced version, AWS Shield Advanced. This is most commonly acquired through an Enterprise-level support agreement with AWS.
As you might guess, AWS Shield Advanced has the ability to protect a wider range of services than the standard version can. Here are some of the services that are provided protection by the suite of features:
Elastic Load Balancing
Elastic IP Addressing
AWS Global Accelerator
Not only do you enjoy a wider range of services that are protected, your features expand as well, including the following:
Resource baselining and trending
Protection against Application (Layer 7) attacks
AWS DDoS Response Team (DRT)
DDoS Cost Protection
Real-time Threat Dashboard access
As if this was not enough, if you use AWS Shield Advanced to protect your EC2 instances, during an attack AWS Shield Advanced automatically deploys your VPC network ACLs to the border of the AWS network. This allows the security suite to provide protection against larger DDoS events.
It is well known that encrypting your data at rest is often necessary to obtain the level of security you require. Fortunately, AWS not only supports this, but provides many tools to allow you a variety of protections in a variety of configurations. Data encryption capabilities include the following:
Data encryption capabilities available in AWS storage and database services, such as EBS, S3, Glacier, Oracle RDS, SQL Server RDS, and Redshift
Flexible key management options, including AWS Key Management Service; allowing you to choose whether to have AWS manage the encryption keys or to have you keep complete control over your keys
Encrypted message queues for the transmission of sensitive data using serverside encryption (SSE) for Amazon SQS
Dedicated, hardware-based cryptographic key storage using AWS CloudHSM, allowing you to satisfy compliance requirements
In addition, AWS provides APIs for you to integrate encryption and data protection with any of the services you develop or deploy. For more information on data encryption, see Chapter 4, “Storage and Data Management.”
Inventory and Configuration
One of the legitimate concerns when moving to a cloud service like AWS is the flexibility and ease of resource creation getting out of hand. You can have inventory and the configuration of devices become unmanageable. AWS has tools such as the following to assist with this potential problem:
Amazon Inspector is a security assessment service that automatically checks applications for vulnerabilities or deviations from best practices. This inspection includes impacted networks, OS, and attached storage.
Deployment tools to manage the creation and decommissioning of AWS resources according to organization standards.
Inventory and configuration management tools, including AWS Config, that identify AWS resources and then track and manage changes to those resources over time.
Template definition and management tools, including AWS CloudFormation to create standard, preconfigured environments; for more information on CloudFormation, see Chapter 7, “Automation and Optimization.”
Monitoring and Logging
“Track everything” is the war cry for many AWS engineers with concerns about cloud security. AWS provides tools for monitoring and logging that include the following:
Deep visibility into API calls through CloudTrail, including details on the calls themselves
Log aggregation options, streamlining investigations, and compliance reporting
Alert notifications through CloudWatch when specific events occur or thresholds are exceeded
Consistent use of these tools can improve the security posture, and reduce the risk profile, of your AWS solutions.
In order to perform penetration testing to or originating from any AWS resources, you must complete a request form to obtain permissions from Amazon.
There are several important things to note about penetration testing requests. As previously mentioned, there have been modifications to some of these parameters, but your exam might not reflect the current changes:
To request permission, you must be logged in to the AWS portal using the root credentials associated with the instances you wish to test; otherwise, the form will not pre-populate correctly. If you have hired a third party to conduct your testing, Amazon suggests that you complete the form and then notify your third party when approvals are granted.
You are only permitted testing of EC2 and RDS instances that you own. Tests against any other AWS services or AWS-owned resources are prohibited.
Amazon does not permit testing small or micro RDS instance types; testing of m1.small or t1.micro EC2 instance types is not permitted.