Domain 6 - Security
In this course, you'll gain a solid understanding of the key concepts for Domain Six of the AWS Solutions Architect Professional certification: Security.
By the end of this course, you'll have the tools and knowledge you need to successfully accomplish the following requirements for this domain, including:
- Design information security management systems and compliance controls
- Design security controls with the AWS shared responsibility model and global infrastructure
- Design identity and access management controls
- Design protection of Data at Rest controls
- Design protection of Data in Flight and Network Perimeter controls
This course is intended for students seeking to acquire the AWS Solutions Architect Professional certification. It is necessary to have acquired the Associate level of this certification. You should also have at least two years of real-world experience developing AWS architectures.
As stated previously, you will need to have completed the AWS Solutions Architect Associate certification, and we recommend reviewing the relevant learning path in order to be well-prepared for the material in this one.
This Course Includes
- Expert-led instruction and exploration of important concepts.
- Complete coverage of critical Domain Six concepts for the AWS Solutions Architect - Professional certification exam.
What You Will Learn
- Designing ISMS systems and compliance controls
- Designing security controls
- Designing IAM management controls
- Identity and Access Management
- Designing protection of Data at Rest controls
- Designing protection of Data in Flight and Network Perimeter controls
You can encrypt transport between your instances and Databases using SSL connections. HTTPS uses the SSL/TLS protocol. For MySQL and SQL Server, RDS creates an SSL certificate and installs the certificate on the DB instance when the instance is provisioned. Once an encrypted connection is established, data transferred between the DB instance and your application will be encrypted during transfer. You can also require your DB instance to only accept encrypted connections. The AWS Storage Gateway securely transfers your data to AWS over SSL. Okay, so how about inbound connections from the public domain? You can also protect data in transit originating from outside connections using SSL connections. All AWS services provide secure customer access points, also called API endpoints, that allow you to establish secure HTTPS communication sessions. So, all AWS services support SSL. Amazon Elastic Load Balancers can terminate or pass through HTTPS or SSL. An Elastic Load Balancer listener is a process that checks for connection requests. It is configured with a protocol and port for front-end, which is client to load balancer, and a protocol and port for back-end, which is load balancer to back-end connections. If you HTTPS or SSL for your front-end listener, you must deploy an SSL/TLS certificate on your load balancer. The load balancer uses the certificate to terminate the connection and then decrypt requests from clients before sending them to the back-end instances. The SSL protocol uses an X.509 certificate. The X.509 certificate is issued by a certification authority, or CA, and it contains identification information. You can create a certificate using AWS Certificate Manager or a tool that supports the SSL and TLS protocols, such OpenSSL. You need to specify this certificate when you create or update and HTTPS listener for your load balancer. You can select the cipher key of your choice. And AWS provides support for most common ciphers. The best option is to use the latest predefined security policy. In the cloud, you can use a combination of Amazon VPC implicit firewall rules at the hypervisor-layer, alongside network access control lists, security groups, host-based firewalls, and IDS/IPS systems to create a layered solution for network security But while security groups, Network ACLs, and host-based firewalls meet the needs of most environments, if we are running sensitive or commercial sites where defense is a priority, we should deploy a network-level security control appliance. Along with creating the right zones, there are generally three options for implementing a security appliance. We can implement it inline. We can implement a distributed threat protection layer. Or we can implement an overlay threat protection layer. Now, ideally, we want to implement the control inline, where traffic is intercepted and analyzed prior to being forwarded to its final destination, such as an application server. However, there is no one magic bullet with mitigation. So, each design needs to be based on the business priorities and the actual requirements. Latency requirements may make inline services less favorable in some instances. Overlay security controls are effective only on top of a secure infrastructure. Now, DNS traffic is a good example of this type of control. When DNS systems are not properly secured, DNS client traffic can be intercepted and DNS names in queries and responses can be spoofed. Spoofing is a simple but efficient attack against an infrastructure which lacks basic controls. SSL and TLS can provide additional protection. And using Route 53, which provides a secure DNS service, somewhat reduces the threat of spoofing. However, we need to consider all options for protecting our cloud infrastructure. AWS partners and third-party services can simplify some of these requirements by providing a scalable service that is integrated with the AWS VPC. Okay, so AWS has cost services that help us reduce attack surface area and mitigate attacks. However, it is still necessary to implement an architecture that allows us to take advantage of these capabilities. Now, here is the reference architecture provided by AWS in the current Security Best Practice whitepaper. So, let's summarize this, in reference to the Solution Architect Professional certification exam. AWS provides a number of infrastructure layer defenses, such as the choice of instance size, the choice of region, load balancing, and edge locations, through CloudFront and Route 53, to protect the availability of your application. For application layer defense, we need to detect plus scale to absorb and block malicious requests. Amazon CloudFront allows you to cache static content, and serve it from AWS Edge Locations that can help reduce the load on your origin. And additionally, CloudFront can automatically close connections from slow reading or writing attackers. And Amazon CloudFront geo restrictions can further prevent users in specific geographic locations from accessing your content. Now, if you know the source IP addresses that you want to block, you can create a rule with an action to block and associate it with web ACL. Some attacks consist of web traffic that is disguised so it looks like regular end user traffic. So, to mitigate this type of attack, you can use an AWS Lamba function to implement rate-based blacklisting. With rate-based blacklisting, you can set a threshold for how many requests your web application can serve. If a bot or crawler exceeds this limit, you can use AWS WAF to automatically block any additional requests. Another way to deal with application layer attacks is to operate at scale. In the case of web applications, you can use ELB to distribute traffic to many Amazon EC2 instances that are basically over-provisioned or configured to autoscale for the purpose of serving surges of traffic. Now, another key strategy is reduce our attack surface area, so, obfuscating the AWS Resources, as it's called. With that, we're limiting the attack surface area by opening only the reports that are required for our app and using bastion hosts where appropriate. Now, security groups Network ACLs are similar in that they allow you to control access to AWS Resources with a new VPC. Security groups allow you to control inbound and outbound traffic at the instance level. And Network ACLs, remember, offer similar capabilities, but at the VPC subnet level. So, Network ACLs allow and deny, and security groups only allow. Another key surface area consideration is protecting your origin. And if you're using CloudFront with an origin that's inside your VPC, you should be using Lamba or a Lamba function, or similar, to automatically update your security group rules to allow only traffic from CloudFront. This can improve the security over our origin by helping to ensure that Amazon CloudFront and AWS WAF can't be bypassed. Another one that's easily overlooked is protecting your API endpoints. Now, ordinarily, when there's a need to expose an API to the public, there's a risk that that API front-end could be targeted in the DDoS attack. Amazon API Gateway is a fully managed service. So, that allows you to create an API that acts like a front door to applications running on EC2, or Lambda, or any other web application front. Let's talk about tools and services we have in AWS to help us. And if we just look at some examples of inline threat protection technologies, generally, we're talking about third-party firewall devices that we can install on Amazon EC2 instances. We're talking about unified threat management gateways. We can think of intrusion prevention systems, data loss management gateways, anomaly detection gateways, and advanced persistent threat detection gateways. Now, all of these appliances that we can add on top of network access control lists, we have on our perimeter of our subnets and our security groups that we have on our resources. So, if we just look at some of the techniques and how those can be used to help us with this additional layer of protection, with firewalls, like security groups networks access control lists, we're looking to manage the list of allowed destination servers and services. And we can limit the IP addresses and restrict TCP and UDP ports. We're ideally looking to manage the list of allowed sources of traffic. So, where traffic is coming from, we want to limit that as much as possible, and certainly to manage the list of allowed protocols. With WAFs, then we're looking at limiting the platform- and application-specific attacks and certainly looking to limit unauthorized user access. With host-based or inline IDS/IPS systems, that's one way of removing Trojans and network attacks. If we're traffic shaping and rate-limiting, you know, often DDoS attacks deplete network and system resources, so rate-limiting is a good technique for protecting scarce resources from over-consumption. And common things we want to trap is ICMP flooding and application request flooding, where we can detect considerable deviations from the normal of traffic we're seeing. All right, so inside that test model, the most important thing with security is that we do test it out to ensure that we, you know, it's working in the way that we want. And every information security management system needs to ensure there's regular reviews of the effectiveness of our security controls and our policies. That's the only real way we can guarantee that the efficiency of the controls against new threats and vulnerabilities will work. And customers do need to ensure that their infrastructure is protected against attacks. Going back to our Shared Security Responsibility Model, you know, a lot of the route controls that need to be put in place are the responsibility of the customer. So, verifying our existing controls does require, you know, regular testing. And it's best practice for AWS customers to undertake a number test approaches. One is the external vulnerability assessments. And that's where a third-party evaluates system vulnerabilities with little or no knowledge of the infrastructure and its components, so, really looking to try and break in. We have external penetration tests. And that's where a third-party with little or no knowledge of the system actively tries to break into it in a controlled fashion. With our internal grey / white box review of applications and platforms, you know, a tester who has some or full knowledge of a system validates the efficiency of controls in place or ideally evaluates applications and platforms for known vulnerabilities. Now, those three controls need to be run within the confines of the AWS Acceptable Use Policy. And that Acceptable Use Policy outlines permitted and prohibited behavior in the AWS cloud. And it certainly defines security violations and network abuse. So, AWS supports both inbound and outbound penetration testing in the cloud. Although, you must request permission to conduct a penetration test. Imagine you have a business customer that runs a group buying site. They deliver a huge volume of customer transactions each day. And one of the key requirements they have is always the ability to scale to thousands of instances. Now, they have asked you to deliver a scalable intrusion detection and prevention system to improve their security. As it turns out, one of the future goals of the management team is to attain either PCI/DSS or SOC one, two, or three compliance. So, you've been ask to do this in the best way you can inside their VPC. Now, thanks to your security workshops, the customer is aware that AWS provides a number of infrastructure layer defenses, such as instance size, choice of region, load balancing and edge locations, via CloudFront and Route 53, to protect the availability of their application. And we've already implemented a lot of those plus VCP Flow Logs and CloudTrail monitoring. You've implemented ELB to terminate inbound requests to the web app and to reduce any attack surface area. We've been over-provisioning instances to reduce any impact that might be caused by a DDoS attack. However, the over-provisioning is becoming a little expensive, and the blended nature of some of the recent attacks is becoming a concern. Our customer uses a combination of Amazon RDS and DynamoDB to collect their dynamic data. And they've been archiving nightly into Amazon S3 and then out to Elastic MapReduce looking for clickstream trends and promotional opportunities from the click data. Now, during this exercise last night, they found questionable log entries and suspect someone is attempting to gain unauthorized access to the system. We're gonna need to come up with a cost-effective scalable mitigation solution to this kind of attack. They've asked us to introduce a threat protection layer. So, we brainstorm this a bit as a team. One of the team suggests setting up one or two of the network interfaces on our EC2 host to promiscuous mode to packet sniff all traffic across the subnet. But someone else points out that while you can place an interface into promiscuous mode, the hypervisor will not deliver any traffic to an instance that it's not addressed to it. So, in the VPC, it's not possible for a virtual instance running in promiscuous mode to receive or sniff traffic that is intended for a different virtual instance. So, on the face of it, that's not going to work. Another suggestion is that we choose a host-based IDS application or software, open-source or otherwise, and bootstrap each EC2 host with that agent. Now, this has everyone thinking as it's feasible to add another install to our bootstrapping routine. However, there's a few concerns about increasing that load time further, and someone in the team raises that key word scale again. We need to build a scalable intrusion detection service, right? So, do we need to create an inline threat protection solution, a distributed threat protection solution, or an overlay network threat protection solution? One of our team point out that there's a number of solutions out there that offer a virtual firewall appliances that can be deployed as an inline gateway for filtering inbound and outbound network traffic. And firewall appliances provide additional application level filtering deep packet inspection that certainly could help us meet our IPS and IDS requirements. However, another member of our team points out that due to the inline nature of this option, that firewall or gateway could become a potential throughput bottleneck, or worse, a single point of failure. So, we would need to ensure any inline service is architectured and engineered to be highly available and scalable. And with our current network design, that could be a challenge. So, what about a distributed threat protection solution? That's where we install threat protection agents on individual instances in the VPC. And a central threat management server communicates with all host-based threat management agents for log collection, analysis, correlation, and active threat response as required. A benefit of host-based agents is that they can include built-in OS capabilities, such as iptables and Windows firewalling. So, it could provide that deep packet inspection, which would help us meet our IPS and IDS requirements. One of our team points out that host-based security software works really well with highly distributed and scalable application architectures because network packet inspection is distributed across the entire software fleet. But another teammate points out that licensing and maintenance costs need to be tabled as part of our consideration set for that type of solution, as with a thousand plus servers, that solution could be quite expensive. So, what about overlay? If we build an overlay network on top of our Amazon VPC, using technology such as GRE tunnels, VTun interfaces, or by forwarding traffic on another ENI to a centralized network traffic analysis and intrusion detection system, that could provide us an active or passive threat response. So, we hone down on a short list of distributed or overlay threat protection, as scale and availability are going to remain our priorities. Having either provided as a service by a third party, like Trend Micro, Alert Logic, Sophos, or the like, could really assist us with meeting our requirements for PCI DSS, SOC, or HIPAA compliance in future. So, how do we determine between overlay or distributed? One of a team suggest overlay, suggesting that it may make sense to create a second VPC and route all traffic from our primary application VPC through the second VPC where we place our scalable virtualized IDS/IPS platform. But someone else points out that traffic in that instance is going to be directed out via our VGW. So, this might filter traffic okay. But with that design, is it possible that all we're doing is creating a potential bottleneck on our gateways? So, after much debate, we identify our next step as being to discuss what's required with some non-AWS partners to help us identify what solution design would work best. We can then present the options back to our customer. Due to the nature of AWS, we could do all this quite quickly. And it's possible we ended up with a blended scenario. It's important to keep in mind that with security, there isn't one size that fits all. And the more layers and the more diversity we can provide in the way that we protect our environment, the more safe and robust it will be for our end customer. So, fast forward to a day later, our IT manager for our group buying company comes back with bad news. There's no budget for using a third-party product until next quarter. So, we need to get creative. So, one of a team first suggests perhaps we just add those identified hostile source IPs as as explicit inbound deny rule to our Network ACL in the web tier subnet. Now, that would provide a temporary solution, but it's not a vary scalable mitigation solution. Another idea tabled is removing all protocols but the TLS 1.2 from the web tier ELB, and in that, enabling advanced protocol filtering. Now, that might enable the ELB to perform some firewall functionality, essentially reducing our attack surface area somewhat. Now, stuck up on the whiteboard from our session yesterday is the word scale. So, one way could be to create a new ELB and an auto-scaling group of EC2 instances running a host-based web application firewall. Ideally, we could redirect Route 53 to resolve to this new WAF tier. The ELB and the WAF tier would then pass the traffic to the current web tier. The web tier, we could set off our security groups to only allow traffic from our new WAF tier security group. So, while it's not quite the full IDS/IPS solution that we know we need, that solution could just provide us with an additional layer until we get our full approval for our IDS/IPS service.
About the Author
Head of Content
Andrew is an AWS certified professional who is passionate about helping others learn how to use and gain benefit from AWS technologies. Andrew has worked for AWS and for AWS technology partners Ooyala and Adobe. His favorite Amazon leadership principle is "Customer Obsession" as everything AWS starts with the customer. Passions around work are cycling and surfing, and having a laugh about the lessons learnt trying to launch two daughters and a few start ups.