Chapter 8
Network Security

THE AWS CERTIFIED ADVANCED NETWORKING – SPECIALTY EXAM OBJECTIVES COVERED IN THIS CHAPTER MAY INCLUDE, BUT ARE NOT LIMITED TO, THE FOLLOWING:

  • Domain 2.0: Design and Implement AWS Networks
  • images 2.2 Given customer requirements, define network architectures on AWS
  • images 2.5 Derive an appropriate architecture based on customer and application requirements
  • Domain 3.0: Automate AWS Tasks
  • images 3.2 Apply AWS networking concepts
  • Domain 5.0: Design and Implement for Security and Compliance
  • images 5.1 Evaluate design requirements for alignment with security and compliance objectives
  • images 5.2 Evaluate monitoring strategies in support of security and compliance objectives
  • images 5.3 Evaluate AWS security features for managing network traffic
  • images 5.4 Utilize encryption technologies to secure network communications

images There’s a clear trend in the IT industry with respect to network security: the boundary is shrinking. Gone are the “hard on the outside, soft on the inside” days that focused a disproportionate amount of attention on network boundary protection. Pushing all traffic through a static, throughput-constrained edge security stack is no longer considered a complete security solution. Moreover, cloud architectures—with their virtually unlimited horizontal scalability—challenge these traditional notions of network security.

We now see the rise of micro-segmentation, zero trust networks, and software-defined perimeters. And while security in the cloud is still familiar to most network and security professionals, the principles translate into slightly different practices. Defense in depth continues as a guiding principle, and this chapter provides perspective on a range of capabilities that you can leverage in securing your environment.

When you think holistically about security in AWS, it is critical to remember that security is a shared responsibility between you and AWS. Make sure that you are clear where AWS responsibility ends and your responsibility begins; otherwise, you leave a threat vector open to malicious actors.

AWS provides a baseline of security for you. For example, AWS protects service Application Programming Interface (API) endpoints to ensure that they are continuously available. You have responsibilities regarding the protection of your workloads. AWS offers you many network security services and features, and you should understand when and how to use them. Additional capabilities are available as vendor products and services in the AWS Marketplace.

This chapter reviews the services and features that AWS provides to support confidentiality, integrity, and availability of your networks. After a brief section on the importance of cloud governance, the rest of the chapter is dedicated to the implementation of network security in three primary areas: data flow, AWS security services, and detection and response. Data flow security focuses on services like Amazon CloudFront, AWS Shield, and AWS WAF, which provide inline network security capabilities. AWS security services will cover Amazon GuardDuty, Amazon Macie, and Amazon Inspector. These services, when enabled, detect anomalies in your environment. The final portion of the chapter will discuss the ways that you can integrate AWS Cloud services and features to detect and respond to network security events. Key architectural patterns, such as the security of Amazon Virtual Private Cloud (Amazon VPC) and Elastic Load Balancing are covered in Chapter 16, “Scenarios and Reference Architectures.” You should have a deep understanding across the breadth of network security offerings available from AWS to pass the AWS Certified Advanced Networking – Specialty Exam.

Governance

Your ability to protect, detect, and respond to network security events is predicated on your ability to identify assets and understand normal operational behaviors. When VPCs, AWS Identity and Access Management (IAM) principles, or sensitive datasets are created ad hoc without oversight or process, your workloads are exposed to significant risk. This reason, among others, is why an overall governance approach is so important to a holistic security approach in the cloud. AWS provides methodologies, including the AWS Cloud Adoption Framework (CAF), to help you along your cloud journey.

A fundamental principle of security is automation. Chapter 10, “Automation,” provides a deep dive on automation for the network. We cover a few key services in this chapter that take the human element out of the loop with respect to creating, operating, managing, and decommissioning your AWS environments. People make mistakes, people bend the rules, and people can act with malice. Your ability to automate processes will greatly contribute to the overall network security of your environments.

AWS Organizations

AWS Organizations provides centralized management of multiple AWS accounts. It delivers two important features in addition to consolidated billing. The first feature is the concept of a Service Control Policy (SCP). The SCP allows the designated master account to define policies that restrict, at the account level, what services and actions member-account users, groups, and roles can take, including the account root user. SCPs are similar to IAM permission policies and use nearly identical syntax. The second feature is programmatic account creation. When you use AWS Organizations to create a new account within an organization, the new account is created with an administrative role, typically called OrganizationAccountAccessRole, which you assume to access the new account.

We’ll explain why these two features are important for network security with the following example. Let’s say that your organization allows each department to have its own individual AWS account in which to create one or more VPC enclaves. That is, each department may have VPCs that connect back to the organization using a Virtual Private Network (VPN) and a Virtual Private Gateway (VGW), but an Internet gateway is never allowed. Using the AWS Organizations account creation API, you can generate a new account, assume its administrative role, create a VPC in a specific region, connect the VPC to the organizational network over a VPN, and then apply an SCP to the account that prohibits the use of an Internet gateway.

For the exam, you should have general familiarity with AWS Organizations and IAM.

AWS CloudFormation

AWS CloudFormation is a service that allows you to define and manage your AWS environment. With AWS CloudFormation, you define your infrastructure as code using either JSON or YAML. This textual definition, called a template, describes exactly what resources to provision and their respective configurations. You manage the collection of resources in AWS CloudFormation as a single unit called a stack. A stack is the target of create, update, or delete actions that you take with a template. Figure 8.1 shows how you use templates and stacks with AWS CloudFormation.

Diagram shows three instructions such as create or use an existing template, save locally or in S3 bucket, and use AWS CloudFormation to create a stack based on your template. It constructs and configures the stack resources.

FIGURE 8.1 Templates and stacks

When you operate a multi-region or multi-account environment, AWS CloudFormation StackSets is particularly useful. AWS CloudFormation StackSets extends the functionality of stacks by enabling you to create, update, or delete stacks across multiple accounts and regions with a single operation. Using an administrator account, you define and manage an AWS CloudFormation template and use the template as the basis for provisioning stacks into selected target accounts across specified regions.

In order to understand how AWS CloudFormation helps with network security, let’s revisit our previous example. Instead of manually creating a VPC and a connection back to the organization using a VPN, you can define the VPC and VPN using an AWS CloudFormation template. When the cross-account, administrative role is assumed, your automation tooling can call AWS CloudFormation to create these resources in the new account. Because the template is a text file, you can add it to your change and version control systems. Using your Continuous Integration/Continuous Delivery (CI/CD) tool chain, you can scan the template for undesirable elements such as security groups that are open to the world. You can trigger alerts and initiate an investigation if unapproved changes are integrated into the template.

For the exam, you should have a thorough understanding of AWS CloudFormation.

AWS Service Catalog

AWS Service Catalog allows organizations to create and manage a curated portfolio of products. These products might be specific software, servers, or complete multi-tier architectures. AWS Service Catalog allows your organization to assert deployment consistency and governance. AWS Service Catalog uses a combination of IAM roles, termed launch constraints, and AWS CloudFormation templates to deliver fine-grained control of access and configuration during the provisioning process. Figure 8.2 demonstrates the overall workflow, from template creation to product launch.

Diagram shows steps like author template parameters, create products, portfolio creation, add constraints and grant access, browse products, launch products, provision products, notifications, and scheduled lambda functions for automated actions.

FIGURE 8.2 AWS Service Catalog workflow

Let’s revisit our example once more to demonstrate how you can continue to remove humans from the loop, improving your overall security posture. Instead of manually assuming the administrative role in the new account and launching the AWS CloudFormation template, you can instead bundle a new AWS CloudFormation template and launch constraints as a product available to the departments in an AWS Service Catalog. When this enclave VPC product is selected, AWS Service Catalog executes a template to generate the new AWS account, create the VPC enclave, build the VPN, and apply the restrictive SCP. With this approach, creation and configuration of a new account is completely automated. Moreover, the process is standardized, repeatable, and auditable.

Data Flow Security

In this section, we cover AWS Cloud services and features that operate directly on the flow of traffic in your AWS environment. AWS provides multiple options that you can use individually or in combination to achieve your required level of network security. The rest of this section describes each of the services and features, starting from edge locations and working inward to regional capabilities and Amazon Elastic Compute Cloud (Amazon EC2) instance capabilities.

Edge Locations

AWS delivers several services from a distributed network of edge locations across the globe. This edge infrastructure allows you to improve the overall throughput and latency characteristics of your workloads when servicing incoming requests from the Internet. This infrastructure is also a key tool in detecting, preventing, and mitigating the impact of Distributed Denial of Service (DDoS) attacks on your environment. For the exam, you should understand how edge locations impact the confidentiality, integrity, and availability of your networks.

All services that run in edge locations share a common set of network security characteristics. First, the edge locations all include built-in network layer (Layer 3) and transport layer (Layer 4) network mitigations. The infrastructure is continuously analyzing traffic for anomalies, and it provides built-in defense against common DDoS attacks such as SYN floods, User Datagram Protocol (UDP) floods, and reflection attacks. In the case of SYN floods, for example, SYN cookies are activated to avoid impact on legitimate traffic. As another example, only well-formed UDP or Transmission Control Protocol (TCP) packets are serviced by the edge locations. More generally, all traffic is scored across a set of dimensions to prioritize the flow of legitimate traffic. Second, the global scale of the edge infrastructure allows AWS to absorb attacks by diffusing the incoming traffic flows across multiple edge locations. Third, many services running in an edge location have the ability to apply geographic isolation and restriction; that is, both automated and manual whitelisting and blacklisting of source traffic is possible.

Amazon Route 53

Nearly all network communication starts with the process of translating a resource identifier into a network location. The Internet leverages the Domain Name System (DNS) to perform this task. As IPv6 adoption continues to accelerate, the notion of recalling or hardcoding IP addresses is fading away. Therefore, DNS is a critical network service. Disruption of DNS service can render your environment inaccessible and inoperable.

Amazon Route 53 is a highly-available and scalable DNS web service offered by AWS. Route 53 is covered in depth in Chapter 6, “Domain Name System and Load Balancing.” In this section, we describe how Route 53 uses shuffle sharding and anycast striping to deliver continuous availability in the face of DDoS attacks and other events that impact availability. Route 53 is the only AWS Cloud service with a 100 percent availability Service Level Agreement (SLA).

Shuffle sharding is a technique designed to minimize correlated failures by simultaneously leveraging the traditional benefits of sharding (such as fault isolation and performance scaling) and the effects of randomized, or shuffled, assignment. Imagine for a moment that Amazon Route 53 uses ten instances to create 5 shards, with each shard having a pair of instances for internal redundancy (Amazon Route 53 has significantly more capacity). Further, each customer’s hosted zones are placed on a single shard. If the placement of customers is evenly divided across the shards by customer ID, for example, it might always be the case that zones for Customer 1 and Customer 2 are served from the same shard. In that case, these two customers could have correlated failures. If, for example, Customer 2’s DNS zones were under a DDoS attack, Customer 1 might experience an impact as well. Moreover, one-fifth of all customers might experience that same impact. If instead we took the 10 instances and randomly assigned customers to a pair of instances, the likelihood of correlated failures would significantly decrease. With this method, Customer 1 is on a shuffle shard composed of instances 3 and 5, for example, while Customer 2 is on a shuffle shard composed of instances 4 and 5. Even though the random allocation of shard instances yielded an overlap on instance 5, the failures are no longer necessarily correlated because client retry logic will mitigate the impact of an availability loss to instance 5. Figure 8.3 provides a visual depiction of this approach.

Image described by caption and surrounding text.

FIGURE 8.3 Shuffle sharding

Anycast striping is another availability mechanism built into Amazon Route 53. Anycast is the notion that multiple systems respond to the same IP address. In practical terms, anycast means that when your DNS resolver initiates a connection to an Amazon Route 53 DNS server, the actual responder to which you connect could be in any of several locations across the globe advertising the same anycast address. For example, example.aws is a public hosted zone on Amazon Route 53. It is assigned the name server ns-962.awsdns-56.net, which has an IPv4 address of 192.0.2.194. This IPv4 address is an anycast address, and AWS advertises the address to the Internet from multiple edge locations. Your request will route to the “closest” anycast server (from a Border Gateway Protocol [BGP] perspective).

Given that DNS uses an iterative lookup process, how will you resolve the name server’s fully qualified domain name to an IP address if the .net Top Level Domain (TLD) servers are not responding? The answer: You won’t. To address this failure mode, AWS stripes public hosted zones across Amazon Route 53 DNS servers in each of four TLDs. In this way, not only does Amazon Route 53 provide multiple anycast name server addresses, but the lookup process for the DNS servers themselves are also dispersed across multiple TLDs.

Amazon Route 53 also provides mechanisms to block invalid or unwanted requests. As part of the edge infrastructure, packet filters are applied that drop invalid DNS requests. If you wish to block requests further, Amazon Route 53 provides geolocation routing policies that give you control over the responses provided to DNS resolvers based on their source IP addresses. You can delineate responses by continent, country, or by state in the United States.

Amazon CloudFront

Amazon CloudFront is a global Content Delivery Network (CDN) operated through edge locations that provide regional and global edge caches. The service is designed to bring content closer to consumers on the Internet. Amazon CloudFront is covered in depth in Chapter 7, “Amazon CloudFront.” In addition to overall edge acceleration capabilities, Amazon CloudFront provides several security features that promote availability of your environments and confidentiality of your content.

Because of its ability to mitigate the impact of DDoS attacks, Amazon CloudFront is frequently used to front both static and dynamic content. In order to effectively protect the content sources, called origins, it is important that the origins are accessible only by Amazon CloudFront. That is, if you use Amazon CloudFront to protect your infrastructure, it has little value if a malicious actor can simply bypass Amazon CloudFront and attack your origin directly. There are two common approaches to protecting origins: using an Origin Access Identity (OAI) with Amazon Simple Storage Service (Amazon S3) and using custom headers. Once direct access to your origins is restricted, you can leverage Amazon CloudFront security features like geo-restriction, signed URLs, and signed cookies.

An OAI is a special Amazon CloudFront user that you can associate with your distributions. A distribution is a particular instance of Amazon CloudFront with a defined set of configurations, origins, and behaviors. You grant permissions to the OAI on Amazon S3 objects and buckets. By requiring that access to Amazon S3 occur through Amazon CloudFront using the OAI, you preclude the bypassing of network security controls that you implement in Amazon CloudFront. For example, you might leverage the Amazon CloudFront geo-restriction feature to prevent IP addresses outside of your country from accessing Amazon S3 objects.

For custom origins, like Amazon EC2 and Elastic Load Balancing, you can extend the notion of an OAI to systems outside of Amazon S3 by using custom HTTP headers. Amazon CloudFront allows you to manipulate many of the headers that are passed to your origin. By configuring a custom header, you can restrict access to only those Amazon CloudFront distributions that you designate. A simple approach to protecting a custom origin is simply to limit access to only the known Amazon CloudFront IP addresses. While it is true that AWS publishes the IP addresses used by Amazon CloudFront, the naïve approach misses the fact that anyone with an AWS account can create their own Amazon CloudFront distribution and point it to your origin, bypassing any IP restrictions that you configured on your origin. To resolve this issue, you can add a custom header so that your origin can authenticate whether the incoming traffic originated from your Amazon CloudFront distribution.

With your origin protected from direct access, you can implement controls to ensure the confidentiality of your content. From a purely networking perspective, Amazon CloudFront allows you to enforce the use of particular protocols for transport and encryption. For communication from Amazon CloudFront to your origins, you can require the use of HTTPS and specify the particular version of Transport Layer Security (TLS). For communication from viewers to Amazon CloudFront, you can enforce the use of HTTPS and specify the versions of HTTP supported. You can further improve viewer security by selecting a pre-defined security policy that enforces TLS version 1.1 or 1.2 as the minimum protocol version. When HTTPS is used for viewers, you can leverage the default Amazon CloudFront certificate, use AWS Certificate Manager, or import your own custom certificate.

The use of encryption protects your data in transit, but you may also wish to exert fine-grained control over access to your content. To achieve this confidentiality, Amazon CloudFront allows you to require signed URLs or signed cookies for access to restricted content. When using either of these two methods, you are responsible for creating and distributing the signed tokens. When using signed URLs or signed cookies, you specify the date and time at which the content is no longer available to the consumer. You can optionally specify a starting date and time as well as a restricted set of consumer source IPs.

To provide finer-grained data protection, you can use a new Amazon CloudFront capability called Field-Level Encryption to further enhance the security of sensitive data, like credit card numbers or personally identifiable information (PII). CloudFront’s field-level encryption further encrypts sensitive data in an HTTPS form using field-specific encryption keys before a POST request is forwarded to your origin. This ensures that sensitive data can only be decrypted and viewed by certain components or services in your origin application stack.

AWS Lambda@Edge

AWS Lambda@Edge allows you to run AWS Lambda functions inside of Amazon CloudFront. The service executes on the basis of Amazon CloudFront events, called triggers, that occur during the normal lifecycle of request/response interactions with viewers and origins. While AWS Lambda@Edge opens a broad range of opportunities for application enhancement, there are specific uses of the service that can materially improve the security of your origins.

In the previous section on Amazon CloudFront, we described the use of headers to authenticate a specific distribution to the origin. Historically, this header/value pair was static and slow-changing. Static values are more readily compromised over time. For example, imagine if you never changed your user name and password. With AWS Lambda@Edge, you can implement a programmatic method to populate the header value dynamically, making it more difficult to subvert your origin access enforcement mechanisms.

A similar use case involves validation of consumer-provided authorization tokens. You can use AWS Lambda@Edge to inspect headers and authorization tokens. For example, if you experienced an application layer attack (Layer 7), you could leverage AWS Lambda@Edge to validate the format and validity of the asserted session or authorization tokens to distinguish between accepting valid traffic and dropping malicious traffic. As a result, invalid requests would not reach the origin.

Edge Locations and Regions

Some AWS Cloud services provide network security capabilities both to edge locations and to AWS Regions. This section describes these services and the AWS resources that they can protect.

AWS Certificate Manager

AWS Certificate Manager is an AWS Cloud service for creating and managing TLS certificates for your AWS websites and applications. AWS Certificate Manager is supported on Amazon CloudFront, Elastic Load Balancing, AWS Elastic Beanstalk (using Elastic Load Balancing), and Amazon API Gateway. You can use certificates generated by AWS Certificate Manager, or you can import your own certificates into AWS Certificate Manager. The use of certificates supports the network security objectives of confidentiality and integrity.

When you use AWS Certificate Manager certificates, AWS provides you with a domain-validated RSA-2048, Secure Hash Algorithm (SHA)-256 certificate that is valid for 13 months. The service will attempt to auto-renew the certificate, typically 30 days before expiration, provided that the certificate is Internet accessible to the service. The certificate must include at least one Fully Qualified Domain Name (FQDN), and you can add additional names. You may also request wildcard names (such as *.example.aws). AWS Certificate Manager-generated certificates are free, and you cannot download the private key. The private key is encrypted at rest with AWS Key Management Service (AWS KMS).

Certificates in AWS Certificate Manager are regional resources. When you want to use the same FQDN in multiple regions, you’ll need to request or import a certificate in each region. For Amazon CloudFront, you perform these tasks in the US East (N. Virginia) Region.

AWS WAF

AWS WAF is a web application firewall that allows you to protect specific AWS resources from common web exploits that could affect the confidentiality, integrity, and availability of your network and your data. AWS WAF integrates with Amazon CloudFront and the Application Load Balancer to monitor HTTP and HTTPS requests. Using custom rules and common, built-in attack patterns, you can prevent impact to your workloads.

With AWS WAF, you implement Web Access Control Lists (ACLs) to control your HTTP and HTTPS traffic. Web ACLs are composed of rules, and rules are composed of conditions. Figure 8.4 depicts these relationships. The rest of this section will describe each of these components in greater detail.

Chart shows components of web ACL such as rule which combines conditions with an AND and rate-based rule which combines conditions with an AND and adds a rate limit. Rate limit is15,000.

FIGURE 8.4 Web ACLs, rules, and conditions

Conditions are the basic building blocks for AWS WAF. Six condition types are supported. When you create a condition with multiple filters, any given entry will satisfy the condition (that is, the filters are OR’ed). For example, one of the condition types is IP addresses. When you add multiple IP addresses to a single condition, the match of any single address makes the condition true. The conditions for AWS WAF are listed next.

The first condition, Cross-Site Scripting (XSS), enables you to match web requests containing scripts that might exploit vulnerabilities in your applications. This condition allows you to search for XSS in common parts of the request data, including the HTTP method, header, query string, Uniform Resource Identifier (URI), or body. This condition also allows you to manipulate the request data, termed transformation, to facilitate matching. You can convert all of the data to lower case, decode HTML, decode the URI, normalize the whitespace, and simplify strings intended to represent command-line text.

The second condition, IP addresses, allows you to match on IPv4 and IPv6 addresses. For IPv4 addresses, AWS WAF will only filter /8, /16, /24, and /32. For IPv6 addresses, AWS WAF will only filter /24, /32, /48, /56, /64, and /128.

The third condition, size constraints, allows you to match requests on the basis of length. This condition will evaluate common parts of the request data, and it allows you to apply the same transformations available in XSS. With this condition, you specify the byte size and the comparison operator (for example, equals, not equals, greater than, or less than).

The fourth condition is SQL injection (SQLi). Like XSS and size constraints, you filter on common parts of the request data and can apply transformations. This built-in attack pattern then evaluates the data for indicators of SQLi.

The fifth condition, geographic match, enables you to allow or block requests based on the country from which the request originates.

The last condition, string match, allows you to match based on string content. String match filters on the common parts of the request data, and it allows you to use the same transformations previously described. You select the match operator (for example, contains, starts with, or ends with) and specify the match value. This match value can be textual or base64 encoded. Regular expression (regex) matching is also supported.

Once the conditions are defined, you compose rules with the conditions. Each rule contains a name, an Amazon CloudWatch metric name, a rule type, and a condition list. The name of the rule is used later when creating the web ACL. The Amazon CloudWatch metric name is the name of the dimension that will appear in Amazon CloudWatch. The rule type can be either regular rule or rate-based rule. The distinction is that rate-based rules also take into account the number of matching requests that arrive from a given IP address in a five-minute interval. The rate limit must be greater than or equal to 2,000 requests per five-minute interval. For each condition you add to the rule, you can specify whether the evaluation should occur on the defined filters (for example, does match) or an inverse of the filters (for example, does not match). When you add multiple conditions to a rule, all conditions must match (that is, conditions are AND’ed).

You can associate an AWS resource—either an Amazon CloudFront distribution or an Application Load Balancer—with a single web ACL. Multiple resources can use the same web ACL. Each web ACL has a name and an Amazon CloudWatch metrics name, similar to the rules definition. Web ACLs are composed of a list of rules, evaluated in order, and a default action that allows or blocks unmatched traffic. Regular rules allow you to specify whether the web application firewall should allow, block, or count the request. Rate-based rules allow you to block or count. When the count action is selected, AWS WAF increments a counter and then continues to process the next rule in the web ACL.

Once a web ACL is implemented, you can view request metrics from Amazon CloudWatch and retrieve sample match data. The sample data includes source IP, country, method, URI, request headers, matched rule, the action taken on the request, and the time the request was received.

You can use AWS WAF in a static configuration, a dynamic configuration, or as an integrated component with a third-party offering. Static configuration means that the configuration of your web ACLs is not automatically updated based on changes in the threat landscape of your environment. Dynamic configuration of AWS WAF is covered later in this chapter in the “Detection and Response” section. There are also third-party vendors that integrate with AWS WAF. You can find these third-party offerings in the AWS Marketplace.

AWS Shield

AWS Shield provides protection against DDoS attacks. AWS Shield offers two distinct levels of protection. The first, AWS Shield Standard, provides protection for all AWS customers against common and most frequently occurring attacks—like SYN/UDP floods, reflection attacks, and others—to support high availability of applications on AWS. It is a no-cost, always-on option that is designed to mitigate the majority of Layer 3 and Layer 4 attacks. AWS Shield Standard contains a continuously evolving rule base that is updated by AWS in response to changes in the Internet threat landscape. Customer visibility into the details of attacks is limited, however.

The second level, AWS Shield Advanced, provides additional DDoS attack protection for Amazon Route 53 hosted zones, Amazon CloudFront distributions, Elastic Load Balancing load balancers, and resources attached to Elastic IP addresses, like Amazon EC2 instances. In addition to network layer (Layer 3) and transport layer (Layer 4) detection and mitigation, AWS Shield Advanced also provides intelligent DDoS attack detection and mitigation for application layer (Layer 7) attacks. Information about ongoing attacks are provided in real time through detailed metric reporting, and customers receive attack forensic reports. Moreover, customers can contact a 24x7 DDoS Response Team (DRT) for assistance during an attack.

There is one last, important point about AWS Shield Advanced. With the move to the cloud and its virtually unlimited resources, many well-architected, horizontally-scalable applications can absorb a typical DDoS attack. That is, cloud architectures can often scale out to meet the surge demands of a typical DDoS attack. Customers pay for resources consumed in the cloud; as a result, we now see customers affected by Economic Denial of Sustainability (EDoS) attacks. The notion of EDoS is that, while a DDoS attack may not impact your availability, the financial cost of absorbing an attack itself becomes untenable. With AWS Shield Advanced, AWS offers some cost protection against billing spikes caused by a DDoS attack. This cost protection, however, is limited to Amazon Route 53 hosted zones, Amazon CloudFront distribution, Amazon EC2 instances, and Elastic Load Balancing load balancers.

When using AWS Shield Advanced, you mitigate application layer (Layer 7) attacks either with your own custom mitigations or through engagement of the DRT. When you create your own mitigations, you implement rules in AWS WAF, which is included for free with your AWS Shield Advanced subscription. When you engage the DRT, an AWS DDoS expert works with you to identify attack signatures and patterns. With your permission, the DRT creates and deploys the mitigations onto your AWS WAF. In order to allow the DRT to push these mitigations to your AWS WAF, you must first authorize the DRT by creating a cross-account IAM role.

Regions

AWS provides a series of region-based services that enable you to protect your environment. This section describes the services that act directly on data flows in the region and the AWS resources that they can protect.

Elastic Load Balancing

Elastic Load Balancing allows you to distribute incoming traffic across multiple resources, such as Amazon EC2 instances within an AWS Region. Load balancing is covered in depth in Chapter 6. In this section, we discuss features of Elastic Load Balancing that you can leverage to provide confidentiality, integrity, and availability to your workloads.

Because Elastic Load Balancing sits in front of your resources, it provides you with a level of protection. Elastic Load Balancing will automatically scale to meet the demands of the vast majority of use cases, contributing to the overall availability of your workload. With Elastic Load Balancing, you define the ports and protocols that it will accept, which are called listeners. Elastic Load Balancing only accepts incoming traffic on its listeners, minimizing the attack surface. Moreover, Elastic Load Balancing proxies connections to your VPC resources, so common attacks like SYN floods are not seen by your back-end resources because only well-formed TCP connections result in data flow to your resources.

When you use Application Load Balancer to provide access from the Internet to your VPC resources, the load balancer forwards traffic into your VPC using private IPv4 addresses from the subnet on which its network interfaces reside. Network Load Balancer, however, will propagate the originating, public source IPv4 address. While Internet-facing load balancers have public IP addresses, resources in your VPC are not required to use publicly-routable IP addresses. Without a publicly-routable IP address, traffic from resources in your VPC, like an Amazon EC2 instance, cannot reach the Internet directly.

To support your confidentiality and integrity goals, Elastic Load Balancing has options for connections over Secure Sockets Layer (SSL)/TLS with Classic Load Balancers and HTTPS both for Classic Load Balancer and Application Load Balancer. As part of the configuration process, you provide a certificate, and you can use AWS Certificate Manager for this process. You also select the security policies used on incoming connections. Security policies allow you to select from a suite of ciphers for various SSL/TLS protocol versions.

A common approach, often termed the Elastic Load Balancing sandwich, leverages two tiers of load balancers to provide inline data flow analysis. In this architecture, a front-end set of Internet-facing load balancers receives incoming traffic. The traffic is load balanced to a fleet of Amazon EC2 instance running security processes of some type (such as web application firewall, content filters, or data loss prevention). In turn, this fleet of security devices forwards the traffic to a second set of load balancers. Finally, these internal load balancers forward the traffic to your workload’s front end.

You can use a similar approach to provide inline data flow analysis for traffic leaving your VPC. In this architecture, you configure your workload’s proxy setting to send requests through Elastic Load Balancing. The load balancer, in turn, forwards the traffic to a fleet of Amazon EC2 instances running proxy software and security processes. Finally, these security devices forward the permitted traffic onto the intended destination. Note that the second layer of load balancers is not used in this configuration.

Subnets and Route Tables

Route tables control the behavior of the implicit router on each subnet of a VPC. A subnet is a network segment within the Classless Inter-Domain Routing (CIDR) range of your VPC contained within a single Availability Zone. Route tables and subnets are covered in depth in Chapter 2, “Amazon Virtual Private Cloud (Amazon VPC) and Networking Fundamentals.” From a network security perspective, you should understand how the allocation of subnets and route tables enables you to construct architectures that promote secure operation.

When you construct a VPC, it is important that you clearly demarcate the infrastructure based on intended routing behaviors. For example, it is common for customers to place Internet-facing load balancers into dedicated public subnets. This approach allows you to apply fine-grained controls on the routing within the subnet, implement network ACLs at the subnet boundary, configure security group rules on the load balancer’s elastic network interfaces, and limit resources in the subnet with an IAM policy. With these four levers, you have precise control over the flow of traffic into and out of your infrastructure.

Route tables are particularly important when you want to keep traffic within the AWS infrastructure. Leveraging gateway VPC endpoints, you can create routes that, for example, provide a path directly between your VPC resources and Amazon S3. Moreover, with VPC endpoints for Amazon S3 and Amazon DynamoDB, you define policies that determine the degree of access granted through the endpoint. Another example is VPC peering. With peering, you create a relationship between VPCs, and the route table entries you supply cause traffic to flow directly between the two VPCs using only the AWS infrastructure. Finally, AWS PrivateLink offers another mechanism to consume services without leaving the AWS infrastructure. When you use PrivateLink, AWS places an elastic network interface into your VPC connected to a load balancer that sends traffic to a fleet in the provider’s VPC. The effect is similar to peering, without the need to expose an entire VPC.

From an availability perspective, it is worth noting that AWS-provided gateways, endpoints, and peering are highly available. The Internet gateway, for example, is not a single device—it is a horizontally-scaled fleet of edge devices.

Customers often want to connect back to an on-premises environment as well. The two primary methods used are AWS Direct Connect, which was discussed in depth in Chapter 5, “AWS Direct Connect,” and VPNs, which were discussed in depth in Chapter 4, “Virtual Private Networks.” Availability approaches are also discussed in Chapters 4 and 5. To deliver confidentiality and integrity, you can leverage two common patterns to create an encrypted connection between your on-premises location and AWS using IP security (IPsec) over AWS Direct Connect.

The simplest pattern is to use an AWS managed VPN connection over a public Virtual Interface (VIF), configuring your edge router as the customer gateway. Traffic leaving your edge router would pass through the IPsec connection, running over your public VIF, and terminate on the VGW connected to your VPC. Subnets requiring access would add a route in their associated route table to the VGW. This pattern is shown in Figure 8.5.

Diagram shows VPC subnets within availability zones of AWS region connected to customer network through router, virtual private gateway, direct connect public virtual interface of VPN connection, and customer gateway.

FIGURE 8.5 VPN over Public VIF

Another pattern uses Virtual Routing and Forwarding (VFR) on the customer gateway to create an IPsec connection over a private virtual interface, terminating on an Amazon EC2 instance in your VPC running VPN software. Subnets requiring access would add a route in their associated route table to the Amazon EC2 instance running the VPN software. This Amazon EC2 instance must have source/destination checking disabled. This pattern is shown in Figure 8.6.

Diagram shows VPC subnets within availability zones of AWS region connected to customer network through router, internet gateway, direct connect private virtual interface of VPN connection, and customer gateway.

FIGURE 8.6 VPN over Private Virtual Interface

Security Groups and Network Access Control Lists (ACLs)

The most basic primitives for delivering network security on AWS are security groups and network ACLs. Security groups are stateful network layer (Layer 3)/transport layer (Layer 4) firewalls that you apply to network interfaces in your VPC. Network ACLs are stateless network layer (Layer 3)/transport layer (Layer 4) filters that you apply to subnets within your VPC. Both are covered in depth in Chapter 2.

Because cloud architectures scale elastically, there are typically changes in resources over time. Security groups allow you to abstract this complexity. For example, when using Auto Scaling, you specify a security group to use. As Amazon EC2 instances are added or removed from the Auto Scaling group, the set of IP addresses in use will change. The security group assigned to instances’ network interfaces, however, will not. As a result, you can reference this security group in your Amazon Relational Database Service (Amazon RDS) security group, for example, to ensure that the database is continuously accessible by your Amazon EC2 instances.

Network ACLs provide another method for managing the flow of packets in your VPC. By default, the network ACL in your VPC allows all packets into and out of all subnets. Some customers use the fact that both security groups and network ACLs control packet flow to implement a type of separation of duties. That is, the workload owner is given control of the security group configuration, but the organization charged with network security retains control of the network ACLs. In this way, coordination between the two parties is required to allow new packet flows. Often, the network ACLs are configured on private subnets to permit only the transmission and receipt of traffic within the particular VPC. In this way, the workload owner can make needed changes to the security groups. If a malicious actor gains access to the security group configuration, however, any attempt to exfiltrate (transmit out without authorization) data directly to the Internet would fail.

As you compose your subnets, think through your anticipated and expected traffic flows. If you lay out your subnets such that you can summarize related subnets into an aggregate, you can create clean or simple network ACLs that are easier to understand. In addition, you should consider that network ACLs are a common way to limit inter- subnet traffic allowed by the VPC local route.

Amazon Elastic Compute Cloud (Amazon EC2)

From an Amazon VPC perspective, your Amazon EC2 instances are arguably the most important piece of the network security environment. Weak authentication, unpatched operating systems, and unmanaged Amazon EC2 instances are likely to fall victim to compromise. When an instance is compromised, it provides a launch pad from which malicious actors can attempt to move throughout your environment, even through AWS Direct Connect or a VPN connection. When thinking through network security, always be mindful of the shared responsibility model. Figure 8.7 provides an overview of the responsibility delineation for Amazon EC2.

Chart shows responsibilities of customer and AWS. AWS is responsible for compute, storage, database, networking et cetera. Customer is responsible for client-side data, server-side encryption, network traffic protection et cetera.

FIGURE 8.7 Shared responsibility model

When reviewing Figure 8.7, note that network traffic protection, network configuration, and firewall configuration are all customer responsibilities. When traffic passes between Amazon EC2 instances in your VPC, for example, you have no visibility into how that traffic is routed in the underlying AWS infrastructure. Recall from Chapter 2 that an Availability Zone contains one or more data centers. Instances that you launch in a subnet might reside on physical hosts in separate data centers. As a result, traffic would flow on fiber-optic cables between buildings. If you want to ensure the confidentiality and integrity of data in transit, you should leverage encryption when communicating between VPC resources, including Amazon EC2 instances. You should also encrypt sessions that you initiate to Amazon EC2 instances using protocols like Secure Shell (SSH). You should use encryption throughout your environments.

Network configuration is another important aspect of network security. For example, an Amazon EC2 instance can have more than one network interface. This simple capability has dramatic implications on the configuration of the network in your VPC. By extension, it has a direct impact on network security.

Imagine for a moment that you have a public website that captures sensitive information. You leverage a common architecture, placing your Internet-facing Elastic Load Balancing load balancers in a dedicated public subnet, and you create a private subnet for the rest of your instances. Because you do not want data exfiltrated from the instances in your private subnet, you apply security groups that only permit traffic within the VPC; you configure network ACLs similarly. You ensure that the route table associated with your private subnet has only the local VPC CIDR route. Moreover, you apply an IAM policy that prevents anyone from changing the security groups, the network ACLs, and the route tables in the VPC. Is this a secure network configuration?

What if a malicious actor within your company launches an Amazon EC2 instance in the private subnet? He creates an elastic network interface in the public subnet and attaches it to the instance. With the primary interface in the private subnet and a second interface in the public subnet, he configures the instance for Network Address Translation (NAT). With a few routing changes on the instance, he confirms that he can reach the Internet. After logging on to one of the instances housing the sensitive data, he updates the default gateway in the operating system to point to his newly created NAT instance. With a few more clicks of the mouse, the malicious actor is exfiltrating sensitive data to the Internet.

Another consideration, one that could have helped in the previous example, is effective management of operating system firewalls. When these are centrally managed and enforced by policy, operating system firewalls can prevent unknown or unexpected data flows. Moreover, operating system firewalls often provide a mechanism to correlate the process or software receiving or transmitting data. If, for example, your Amazon EC2 instance were compromised by a virus of some sort, your firewall might block unexpected data flows or unknown processes, mitigating risk while you investigate.

In AWS, it is not possible to create a Switched Port Analyzer (SPAN) port, but you can use on-instance agents to achieve the same outcome. Using integrated operating system capabilities or offerings from the AWS Marketplace, it is possible to capture packet data from each Amazon EC2 instance and stream the data to a collector. Similarly, you can implement advanced network security features like Intrusion Detection or Prevention Systems (IDS/IPS) using on-instance agents.

Regional Services

AWS offers many regional services that operate outside of your VPC. Services like Amazon Kinesis and Amazon Simple Queue Service (Amazon SQS) are managed by AWS, and AWS assumes more responsibility for delivering them to you. Even so, you still have some responsibility for the confidentiality, integrity, and availability of your data over the network. For example, you should connect to these services using SSL/TLS. You should encrypt data at rest using client-side encryption or using AWS KMS server-side encryption. You should sanitize data inputs to these services to prevent failures of availability in downstream processing. Lastly, you should create AWS Organizations SCPs and/or IAM policies that set sensible restrictions on the actions users can take on the services.

AWS Security Services

AWS delivers several managed services that, when enabled, provide you with visibility into the security of your network. Each service employs an approach that is tailored for its specific usage to identify anomalies and notify you. The services are built and operated by the AWS Security organization and benefit from Amazon’s experience operating security at scale.

Amazon GuardDuty

Amazon GuardDuty is a managed, intelligent threat detection service that provides you with a more accurate and easy way to continuously monitor and protect your AWS accounts and workloads. With a single-click in the AWS Management Console, GuardDuty immediately begins analyzing billions of events from AWS CloudTrail, VPC Flow Logs, and DNS Logs. There are no agents, sensors, or network appliances to deploy and absolutely no footprint in your AWS account, meaning that there is no risk of performance or availability impact to existing workloads. GuardDuty uses threat intelligence feeds, such as lists of malicious IPs and domains, and machine learning to detect threats more accurately. Unlike compliance and best practices services like AWS Config and AWS Trusted Advisor, Amazon GuardDuty is designed to identify active threats in your environment. Furthermore, Amazon GuardDuty has broad visibility going beyond protecting just virtual machines and the network to monitor and profile all AWS account behavior. For example, GuardDuty can detect compromised EC2 instances serving malware or mining Bitcoins. It can detect attackers scanning your web servers for known application vulnerabilities, or accessing AWS resources from an unusual geo-location. It also monitors AWS account access behavior for signs of compromise, such as unauthorized infrastructure deployments, like instances deployed in a region that has never been used, or unusual API calls, like a password policy change to reduce password strength. When a threat is detected, GuardDuty delivers a detailed security finding to the console and AWS CloudWatch Events, making alerts actionable and easy to integrate into existing event management or workflow systems. With GuardDuty, you get intelligent threat detection and actionable alerts in an easy-to-use, pay-as-you-go cloud security service.

Amazon Inspector

Amazon Inspector is a security service that allows you to analyze your VPC environment to identify potential security issues. With Amazon Inspector, you create assessment targets using Amazon EC2 instance tags, create an assessment template with a selected rules package, and then run the assessment. At the end of the assessment period, Amazon Inspector produces a set of findings and recommended steps to resolve potential security issues.

As discussed in the Data Flow Security section of this chapter, Amazon EC2 security failures can have a material impact on the overall network security of your environment. Amazon Inspector offers a straightforward approach to understanding the posture of your Amazon EC2 instances. This information is certainly important, but you also need to understand your overall network configuration.

Amazon Macie

Amazon Macie is a security service that uses machine learning to discover, classify, and protect sensitive data in AWS automatically. Amazon Macie recognizes sensitive data such as Personally Identifiable Information (PII) or intellectual property and provides you with dashboards and alerts that give visibility into how this data is being accessed or moved. Amazon Macie leverages User and Entity Behavioral Analytics (UEBA), a Support Vector Machine (SVM) classifier to automate document classification, predictive analytics to baseline user activity and identify risky accesses that could indicate targeted attack or unauthorized access to data stored in Amazon S3, and insider threats on data stored in Amazon S3.

Amazon Macie starts by identifying and protecting the data that malicious actors are likely to target. Amazon Macie automatically learns jargon and internal project names and estimates the business value for each object within your Amazon S3 buckets. Next, Amazon Macie learns how users interact with that data by examining historical access activity. When Amazon Macie detects anomalous activity, it generates alerts. These alerts are available in Amazon CloudWatch Events, and you can build automation with services like AWS Lambda to take action to protect your data.

Because Amazon Macie provides a fully customizable, proactive loss-prevention capability, it is an important part of your network security toolbox. Not only does Amazon Macie allow you to understand the relationship between your most sensitive data and user access patterns, it is also able to identify information stored in Amazon S3 that could undermine your network security posture.

When you consider network security in the cloud, you must also consider the methods by which changes are made to your environment. Unlike traditional, physical data centers, an API call will cause immediate changes to your AWS environment. As a result, the security of your network can change quickly. Amazon Macie can alert you when AWS API credentials or SSH keys appear in your Amazon S3 buckets.

Detection and Response

Up to this point, the chapter has focused on individual services and features related to network security. For the rest of the chapter, we provide a series of examples that demonstrate how you can integrate AWS Cloud services to enhance detection and response. The examples provided are not exhaustive. For the exam, you should understand the integration points that are available in AWS Cloud services for detection and response.

Secure Shell (SSH) Login Attempts

A series of failed login attempts often indicates an active intrusion threat. This example leverages several AWS Cloud services to detect and respond to these login failures. Once the failures are detected, action is taken to block the source of the attack.

AWS Cloud Services

The example integrates the following AWS Cloud services:

Amazon CloudWatch monitors your AWS resources and the applications that you run on AWS in real time. You can use Amazon CloudWatch to collect and track metrics, logs, and events. Amazon CloudWatch alarms send notifications or automatically makes changes to the resources that you are monitoring based on rules that you define.

AWS CloudTrail acts as a recorder, documenting the history of AWS API calls and related events in your account. AWS CloudTrail delivers these records in a log file to an Amazon S3 bucket that you specify. You can even have AWS CloudTrail logs from multiple accounts delivered to the same bucket. To provide confidentiality and integrity, you can configure AWS CloudTrail to encrypt logs and generate an integrity digest file.

IAM helps you securely control access to AWS resources. You use IAM to control who or what can use your AWS resources, what resources they can use, and the ways they can use them.

AWS Lambda lets you run code without provisioning or managing servers. AWS Lambda executes your code only when needed and it scales automatically. You can use AWS Lambda to run your code in response to events.

Amazon Simple Notification Services (Amazon SNS) coordinates and manages the delivery messages to subscribing endpoints. Amazon SNS facilitates communication between publishers and subscribers. Publishers, like Amazon CloudWatch alarms, communicate asynchronously with subscribers by producing and sending a message to a topic. Subscribers, like AWS Lambda functions, receive the message when they are subscribed to the topic.

Architecture Overview

The diagram in Figure 8.8 provides an overview of the components in this example.

Diagram shows components such as application server, log stream, log group, AWS cloud, metric filter, AWS IAM, CloudWatch alarms, CloudWatch console, CloudWatch logs agent, SSH logs, Amazon SNS, and e-mail.

FIGURE 8.8 SSH login attempts overview

Solution Description

In this example, your application runs on Linux instances. SSH is the mechanism used to log in and manage the systems. Each instance on which you run the Amazon CloudWatch Logs agent also has an IAM instance role assigned to the Amazon EC2 instances to allow the agent to write to Amazon CloudWatch Logs. As the SSH daemon updates its logs, the information is sent from the instance to Amazon CloudWatch Logs. The logs for each instance are represented in Amazon CloudWatch Logs as a unique log stream. The instance log streams are aggregated into a log group.

With the log group in place, you can create a metric filter. Metric filters express how Amazon CloudWatch should extract observations from ingested logs and represent them as data points in an Amazon CloudWatch metric. Metric filters are assigned to log groups. You configure the metric filter to match the specific string sequence in the logs that indicate a login failure. You also specify an Amazon CloudWatch alarm to indicate when the allowed number of failed login attempts per unit time (for example, two failed attempts every five minutes) is exceeded. As part of the alarm configuration, you specify an Amazon SNS topic on which to publish the alarm.

In order to automate response, you subscribe an AWS Lambda function to the alarm topic in Amazon SNS. The subscribed AWS Lambda function contains your code for processing the source IP address of the failures and, using an IAM role for the AWS Lambda execution, updates the VPC network ACLs to deny incoming requests from the source. (Recall that network ACLs allow deny statements, but security groups do not.) You can also subscribe your email address to the AWS Lambda topic to receive an email when the alarm threshold is breached.

Network Traffic Analysis

One method for detecting network anomalies in your environment is to understand traffic flow patterns. Sudden changes in “top talkers,” for example, could indicate an active data exfiltration. You might also find it useful to understand denied data flows or unused security groups and ports. This example demonstrates how you can gain visibility and analyze your flow data from your VPC.

AWS Cloud Services

The example integrates the following AWS Cloud services:

Amazon CloudWatch monitors your AWS resources and the applications that you run on AWS in real time. You can use Amazon CloudWatch to collect and track metrics, logs, and events. Amazon CloudWatch alarms send notifications or automatically makes changes to the resources you are monitoring based on rules that you define.

Amazon Elasticsearch Service makes it easy to create a domain and deploy, operate, and scale managed Elasticsearch clusters. Elasticsearch is a popular, open source search and analytics engine for use cases such as log analytics, real-time application monitoring, and clickstream analytics.

IAM helps you securely control access to AWS resources. You use IAM to control who or what can use your AWS resources, what resources they can use, and in what ways they can use them.

Kibana allows you to visualize data in Amazon Elasticsearch Service. Kibana is a popular open source visualization tool designed to work with Elasticsearch. Amazon Elasticsearch Service provides an installation of Kibana with every Amazon Elasticsearch Service domain. You can find a link to Kibana on your domain dashboard in the Amazon Elasticsearch Service console.

Amazon Kinesis Firehose delivers managed, real-time streaming data to destinations such as Amazon S3, Amazon Redshift, or Amazon Elasticsearch Service. You configure your data producers to send data to Amazon Kinesis Firehose, and it automatically delivers the data to the destination that you specified. You can also configure Amazon Kinesis Firehose to transform your data before data delivery.

AWS Lambda lets you run code without provisioning or managing servers. AWS Lambda executes your code only when needed, and it scales automatically. You can use AWS Lambda to run your code in response to events.

VPC Flow Logs enables you to capture information about the IP traffic going to and from network interfaces in your VPC. Flow log data is stored using Amazon CloudWatch Logs.

Architecture Overview

The diagram in Figure 8.9 provides an overview of the components in this example.

Diagram shows traffic flow through network containing Amazon CloudWatch, lambda ingestor function, firehouse, lambda decorator function, and Amazon ES. Error logs flow from firehouse to Amazon S3.

FIGURE 8.9 Network traffic analysis overview

Solution Description

In order to analyze your network traffic, this example leverages the VPC Flow Logs features and Amazon Elasticsearch Service. To augment the analysis, flow data is correlated with information about the relevant security groups. The complete dataset is stored in Amazon Elasticsearch Service, allowing you to view flow data, analyze unused security groups, and identify unused security group rules with Kibana.

The heart of this solution is the Elasticsearch cluster. After you create an Amazon Elasticsearch Service domain, you need to populate the cluster with flow data. Amazon Kinesis Firehose provides a simple mechanism for pumping data into Amazon Elasticsearch Service. You can augment the information passed into Amazon Elasticsearch Service by using a Amazon Kinesis Firehose data transformation. With data transformations, you send Amazon Kinesis Firehose data through an AWS Lambda function that modifies the Amazon Kinesis Firehose output. For this solution, you create an AWS Lambda function that augments the VPC Flow Log data by adding information about direction of the traffic (that is, inbound or outbound), security groups associated with the traffic, and information about the IP address (for example, geolocation). When complete, you have a Amazon Kinesis Firehose delivery stream that takes input, transforms it, and delivers it to your Elasticsearch cluster.

The last piece of the solution is connecting VPC Flow Logs into the Amazon Kinesis Firehose delivery stream that you created. VPC Flow Logs are delivered to Amazon CloudWatch Logs. You can use AWS Lambda as an Amazon CloudWatch Logs streaming target to ingest data from Amazon CloudWatch Logs and push it into Amazon Kinesis Firehose. Once you enable Amazon CloudWatch Logs streaming to your AWS Lambda function, the end-to-end flow is complete. VPC Flow Logs periodically places data into Amazon CloudWatch Logs. Amazon CloudWatch Logs streams the data to an AWS Lambda function that you’ve written to push data into a Amazon Kinesis Firehose delivery stream. As the data is processed by Amazon Kinesis Firehose, another AWS Lambda function augments the flow data, and the final product is delivered to your Elasticsearch cluster.

With the VPC Flow Logs data augmented and delivered to your Elasticsearch cluster, you can use Kibana to run queries on the flow data.

IP Reputation

As discussed earlier in the chapter, AWS WAF integrates with Amazon CloudFront and Application Load Balancer and allows you to protect your AWS environments. Because AWS WAF is API-driven, you can gain tremendous value by automating configuration of web ACLs. This example demonstrates how you automate third-party detection data into your own response actions.

AWS Cloud Services

The example integrates the following AWS Cloud services:

Amazon CloudWatch monitors your AWS resources and the applications you run on AWS in real time. You can use Amazon CloudWatch to collect and track metrics, logs, and events. Amazon CloudWatch alarms send notifications or automatically makes changes to the resources that you are monitoring based on rules that you define.

IAM helps you securely control access to AWS resources. You use IAM to control who or what can use your AWS resources, what resources they can use, and the ways they can use them.

AWS Lambda lets you run code without provisioning or managing servers. AWS Lambda executes your code only when needed, and it scales automatically. You can use AWS Lambda to run your code in response to events.

AWS WAF lets you monitor the HTTP and HTTPS requests that are forwarded to Amazon CloudFront or an Application Load Balancer. AWS WAF also lets you control access to your content based on conditions that you specify, such as the IP addresses.

Architecture Overview

The diagram in Figure 8.10 provides an overview of the components in this example.

Diagram shows components like Amazon CloudFront accessed by allowed users based on source IP addresses, elastic load balancing or custom origin, web servers, AWS WAF, CloudFront access log S3 bucket, AWS lambda, and CloudWatch.

FIGURE 8.10 IP reputation overview

Solution Description

There are several publicly-available IP reputation lists that provide information about known bad IP address. You can protect your AWS environments by programmatically incorporating these IP addresses into AWS WAF web ACLs that block them. This solution provides a straightforward approach for using Amazon CloudWatch Events, AWS Lambda, and AWS WAF to generate and update a dynamic list of disallowed IP addresses.

The first step in the solution is to create a periodic event that triggers an AWS Lambda function. Amazon CloudWatch Events provides an event bus where actions across your AWS Cloud environment are seen. Amazon CloudWatch Events also has the capability to generate scheduled events. In order to process updates in the IP reputation lists, you configure a scheduled Amazon CloudWatch Event. The event calls an AWS Lambda function that you create to download and process one or more IP reputation lists. The AWS Lambda function uses an IAM role that allows it to call the AWS WAF APIs directly, updating the IP addresses condition used for blocking IPs. Once the AWS Lambda function completes, the current list of bad IPs is blocked from Amazon CloudFront distributions and Application Load Balancers.

Summary

In this chapter, you reviewed network security concepts, AWS Cloud services relevant to network security, and the integration of multiple AWS Cloud services to enable higher-level capabilities. The chapter discussed governance considerations, protecting data flow, managed AWS security services, and detection and response. The chapter is not exhaustive, but it does provide you with a solid foundation of network security for the exam.

In the section on governance, you learned about the importance of controlling your AWS accounts. Tools like AWS Organizations, AWS CloudFormation, and AWS Service Catalog allow you to control change in your environment, enforce standards, and implement guard rails. Moreover, these services allow you to automate, taking manual, human action out of the process. Automation can dramatically improve your overall security posture.

In the section on data flow security, you reviewed the edge location and region services that operate directly on the flow of traffic in your AWS environment. Services that run in edge locations benefit from a standard set of protections. Particular services have additional capabilities to withstand network attack. AWS designs services to deliver confidentiality, integrity, and availability.

Amazon Route 53 uses techniques like shuffle sharding and anycast striping to deliver a 100 percent availability SLA. Amazon CloudFront provides you with the ability to diffuse DDoS attacks across the AWS global infrastructure. You can prevent direct attacks on your origins by ensuring that they only accept requests from Amazon CloudFront. You can also use AWS Lambda@Edge to validate incoming Amazon CloudFront requests before they are passed to the origin, further protecting your environment.

AWS Certificate Manager facilitates the creation and management of SSL/TLS certificates for Amazon CloudFront and Elastic Load Balancing, delivering confidentiality and integrity to data in transit. When you use AWS Certificate Manager certificates, AWS provides you with a domain-validated RSA-2048, SHA-256 certificate that is valid for 13 months. The service will attempt to auto-renew the certificate, typically 30 days before expiration, provided that the certificate is Internet accessible to the service. You can use fully qualified domain names or wildcard names with AWS Certificate Manager. If you use a third-party certificate provider, you can upload your certificate into AWS Certificate Manager.

AWS WAF and AWS Shield provide protection for your Amazon CloudFront and Application Load Balancer resources. AWS WAF uses web ACLs that contain ordered rules to allow, block, or count incoming requests. Rules are either standard or rate based and contain match conditions. AWS WAF evaluates conditions on cross-site scripting, IP address, size, SQLi, geo-location, and string matches. AWS Shield Standard is available to all customers at no additional charge. AWS Shield Standard mitigates the majority of network layer (Layer 3) and transport layer (Layer 4) attacks. AWS Shield Advanced provides additional capabilities, including intelligent DDoS attack detection and mitigation for application layer (Layer 7) attacks. AWS Shield Advanced provides real-time, detailed metric reporting, and you have access to a 24x7 DRT. Lastly, AWS Shield Advanced offers some cost protection against billing spikes.

Elastic Load Balancing load balancers provide you with a level of protection when placed in front of your Internet-facing VPC resources. Elastic Load Balancing only accepts incoming traffic on its listeners, minimizing the attack surface. Elastic Load Balancing proxies connections to your VPC resources, mitigating common attacks like SYN floods because only well-formed TCP connections result in data flow to your resources. Using an Elastic Load Balancing sandwich, you can place security processes and appliances inline with traffic incoming to your VPC. You can use a load balancer with a proxy fleet to achieve similar inline security filtering for outbound traffic.

Subnets and route tables allow you to control the behavior of packet flows in your VPC. Leveraging VPC endpoints allows resources in your VPC to communicate with external services without attaching an Internet gateway or VGW. Similarly, you can communicate between VPCs using VPC peering. When you need to communicate with your on-premises environment, you can encrypt communications using an IPsec connection with an AWS managed VPN connection over the Internet or over an AWS Direct Connect public VIF. You can also establish an encrypted connection using an Amazon EC2 instance running VPN software and an AWS Direct Connect private VIF.

Security groups and network ACLs are primitives used within your VPC to control traffic flow. Security groups provide stateful firewall capabilities, and they allow you to use the security group as an abstraction to hide dynamic changes in your VPC. Network ACLs are typically coarser-grained, stateless rules. Some organizations use a separation of duties model, where security groups are controlled by one team and network ACLs are controlled by another.

You reviewed how the shared responsibility model applies to Amazon EC2 instances. Network communication protection and operating system patches are your responsibility. You should use the tools available within your instance’s operating system to secure the network further. Without a deliberate, thoughtful approach to protection of your VPC, malicious actors can use your Amazon EC2 instances to bypass the network flow controls you establish.

Amazon offers a number of regional services beyond those described explicitly in the chapter. Each provides mechanisms to control access, enforce encryption, and emit log data for analysis. IAM and AWS KMS are important services for access control and encryption, respectively.

You also reviewed managed security offerings. Amazon GuardDuty detects and alerts on active threats in your environment. Amazon Inspector rationalizes the layers of security around applications running on your Amazon EC2 instances. Amazon Macie identifies threats with respect to data in Amazon S3.

The final section of the chapter provided examples of how you can integrate AWS Cloud services to provide higher-level capabilities for network security. Each example demonstrated how you can improve visibility and automate action to protect your environments. For the exam, you should understand the integration points available in AWS Cloud services for detection and response.

Resources to Review

For more information on the AWS Cloud services discussed in this chapter, visit the following URLs:

Exam Essentials

Understand the shared responsibility model. While AWS manages security of the cloud, security in the cloud is your responsibility. You control what security you choose to implement to protect your content, platform, applications, systems, and networks. When using Amazon EC2, you are responsible for network traffic protection.

Understand how to automate security in your environment. Using AWS Cloud services like AWS Organizations, Amazon CloudFront, and AWS Service Catalog, you can automate the creation of known account baselines. When you automate, you can build in best practices, implement guard rails, and centralize logging to provide security visibility across your AWS accounts. People make mistakes, people bend the rules, and people can act with malice. Your ability to automate will greatly contribute to the overall network security of your environments.

Understand edge location capabilities that protect your environments from DDoS attacks. Edge locations all include built-in network layer (Layer 3) and transport layer (Layer 4) network mitigations. The edge location infrastructure is continuously analyzing traffic for anomalies, and it provides built-in defense against common DDoS attacks such as SYN floods, UDP floods, and reflection attacks. AWS can activate SYN cookies to avoid impact to legitimate traffic. Only well-formed UDP or TCP packets are serviced by the edge locations. All traffic is scored across a set of dimensions to prioritize the flow of legitimate traffic. The global scale of the edge infrastructure allows AWS to absorb attacks by diffusing the incoming traffic flows across multiple edge locations.

Understand the availability techniques for Amazon Route 53. Amazon Route 53 uses shuffle sharding and anycast striping to isolate availability challenges and mitigate impact to you. The service only responds to well-formed DNS requests.

Understand how to prevent malicious actors from bypassing Amazon CloudFront. You can use an Amazon S3 OAI to ensure that only Amazon CloudFront can access your Amazon S3 buckets. For other origins, you can insert HTTP headers to authenticate that the request originated from Amazon CloudFront. AWS Lambda@Edge can be used to generate these authenticators dynamically. You can use signed URLs and signed cookies to restrict access further to your origins.

Understand the capabilities offered by AWS WAF. AWS WAF can protect your Amazon CloudFront distributions, Application Load Balancers, and Amazon EC2 instances. AWS WAF uses web ACLs. Web ACLs contain an ordered list of rules that specify whether to allow, count, or drop traffic. Rules are either standard or rate-based and are composed of conditions. Conditions match on cross-site scripting, IP addresses, size, SQLi, geo-location, and string match.

Understand the details of AWS Certificate Manager certificates. AWS Certificate Manager certificates provide you with a domain-validated RSA-2048, SHA-256 certificate that is valid for 13 months. The service will attempt to auto-renew the certificate, typically 30 days before expiration, provided that the certificate is Internet accessible to the service. The certificate includes at least one FQDN, and you can add additional names. You may also request wildcard names (for example, *.example.com). AWS Certificate Manager-generated certificates are free, and you cannot download the private key.

Understand how Elastic Load Balancing protects your VPC resources. Elastic Load Balancing automatically scales to meet the demands of the vast majority of use cases, contributing to the overall availability of your workload. With Elastic Load Balancing, you define the ports and protocols it will accept, minimizing the attack surface. Elastic Load Balancing proxies connections to your VPC resources; so, common attacks like SYN floods are not seen because only well-formed TCP connections result in data flow to your resources. When you wish to provide inline security processes for traffic inbound to your VPC, you can leverage an Elastic Load Balancing sandwich. When you want to provide inline security processes for traffic outbound from your VPC, you can leverage an internal load balancer and a proxy fleet of Amazon EC2 instances.

Understand how to protect traffic using route tables and subnets. Route tables allow you to control how traffic leaves your subnets. You can use VPC endpoints and VPC peering to keep traffic within the AWS infrastructure without attaching an Internet gateway or VGW to your VPC. When you do need to connect to your on-premises infrastructure, encrypt your traffic using IPsec connections. You can use an AWS managed VPN connection over the Internet or over an AWS Direct Connect public VIF. You can use your own VPN software on an Amazon EC2 instance over an AWS Direct Connect private VIF.

Understand how to secure your Amazon EC2 instances. AWS provides many services and features to assist you in securing your network. Even so, you should also secure your Amazon EC2 instances. Use tools to manage configurations, enforce policies, and detect anomalous behavior on your instances. Understand the risks posed to your environments by a compromised Amazon EC2 instance and devise mechanisms to detect and respond to anomalous behavior.

Understand the capabilities of each managed AWS security service. Amazon GuardDuty detects and alerts on active threats in your environment. Amazon Inspector rationalizes the layers of security around applications running on your Amazon EC2 instances. Amazon Macie identifies threats with respect to data in Amazon S3.

Understand how you can integrate various AWS Cloud services to deliver higher-level security capabilities. You can combine AWS Cloud services to provide detection and response capabilities. For the exam, you should understand the integration points available in AWS Cloud services for detection and response.

Exercises

The best way to become familiar with the various network security services and features is through direct, hands-on experience. The following exercises provide you with the opportunity to experiment and learn. You should feel free to expand beyond the exercises.

For assistance completing these exercises, refer to the following Amazon User Guides:

Review Questions

  1. Which of the following allows you to create new AWS accounts programmatically?

    1. AWS Identity and Access Management (IAM)
    2. AWS Organizations
    3. Amazon Simple Storage Service (Amazon S3)
    4. AWS CloudTrail

  2. AWS CloudFormation allows you to define your infrastructure as code in what artifact?

    1. JSON
    2. StackSets
    3. Stacks
    4. Templates

  3. Which of the following is a security benefit of services such as AWS Service Catalog? (Choose two.)

    1. Automation
    2. Repeatability
    3. Self-service
    4. Curation
    5. AWS Marketplace Integration

  4. Amazon Route 53 uses several methods to deliver a 100 percent availability Service Level Agreement (SLA). Which method guards against failures of Top Level Domain (TLD) servers?

    1. Shuffle sharding
    2. Routing policies
    3. Anycast striping
    4. Latency routing

  5. Which of the following allows you to restrict access to your Amazon Simple Storage Service (Amazon S3) bucket to Amazon CloudFront distributions that you control?

    1. Custom HTTP header
    2. Origin Access Identity (OAI)
    3. AWS Lambda@Edge
    4. Preshared keys

  6. Private keys in AWS Certificate Manager are protected using which one of the following?

    1. AWS CloudHSM
    2. AWS Key Management Service
    3. Client-side encryption
    4. Amazon S3 server-side encryption

  7. AWS WAF integrates with which one of the following AWS resources?

    1. Amazon Simple Storage Service (Amazon S3)
    2. Amazon DynamoDB
    3. Amazon CloudFront
    4. Amazon Route 53

  8. AWS Shield Standard provides protection at which layers of the Open Systems Interconnection (OSI) model? (Choose two.)

    1. Physical (Layer 1)
    2. Data Link (Layer 2)
    3. Network (Layer 3)
    4. Transport (Layer 4)
    5. Application (Layer 7)

  9. Which Amazon Virtual Private Cloud (Amazon VPC) feature allows you to access AWS Cloud services without the use of an Internet gateway?

    1. VPC endpoints
    2. VPC peering
    3. Customer-hosted endpoints
    4. Network Address Translation (NAT) gateway

  10. What aspect of an Amazon Virtual Private Cloud (Amazon VPC) is stateful?

    1. Network Access Control Lists (ACLs)
    2. Security groups
    3. Amazon VPC Flow Logs
    4. Prefix list

  11. Which AWS Cloud service will help you identify sensitive account data, like access and secret keys, stored in an Amazon Simple Storage Service (Amazon S3) bucket?

    1. Amazon Inspector
    2. AWS Config
    3. AWS CloudTrail
    4. Amazon Macie

  12. You are tasked with identifying unused security groups and ports in a Virtual Private Cloud (VPC). Which AWS capabilities should you use?

    1. Amazon CloudWatch metrics
    2. AWS CloudTrail
    3. AWS Config
    4. VPC Flow Logs

  13. To protect its website, the organization directs you to implement known-attacker protection for the website. The website resides behind an Application Load Balancer. You have subscribed to a threat intelligence service that posts hourly IP reputation lists. What combination of AWS Cloud services will allow you to block traffic based on this threat intelligence?

    1. Amazon CloudWatch, AWS Lambda, AWS WAF
    2. Amazon CloudFront, AWS Lambda, AWS WAF
    3. AWS CloudTrail, AWS Lambda, AWS Config
    4. AWS CloudTrail, Amazon CloudWatch, AWS Lambda
..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
18.119.160.181