Amazon AWS security: Can you deploy resilience, zero trust, intrusion kill chain prevention, and risk assessment?
Rick Howard: In the last two episodes, I did a deep dive into Microsoft Azure and cybersecurity first principles. In the process, I learned that cloud providers have developed a vocabulary to describe the concepts of how their services work. The ideas shared among all cloud providers are similar, but many of them have different names and offer subtle differences in capability. And in the words of my favorite stand-up comic, John Mulaney...
(SOUNDBITE OF FILM, "JOHN MULANEY: KID GORGEOUS AT RADIO CITY")
John Mulaney: Those don't match up at all.
Rick Howard: For this episode, I'm going to take a look at Amazon AWS and try to distinguish between the services and the concepts that are the same between AWS and Azure and how they are different.
Rick Howard: My name is Rick Howard. You are listening to "CSO Perspectives," my podcast about the ideas, strategies and technologies that senior security executives wrestle with on a daily basis. Let's start with some networking basics in both Azure and AWS.
Rick Howard: For both services, customers rent space on each cloud provider's network. Microsoft calls them virtual networks. Amazon calls them virtual private clouds, or VPCs. The IP addresses that support these ephemeral networks are private, meaning that any virtual host within can't get to the internet and that any host on the internet can't see the virtual host.
Rick Howard: In order to allow access to and from the internet, cloud providers use an old legacy networking trick called Network Address Translation, or NAT. According to the GeeksforGeeks website, quote, "the idea of NAT is to allow multiple devices to access the internet through a single public address. It's a process in which one or more local IP addresses are translated into one or more global IP addresses and vice versa," end quote. Amazon calls its version a NAT gateway, and Microsoft calls its version a source network address translation or - wait for it - a SNAT. And like I said last episode, how great is that acronym?
Rick Howard: I think we should hand out boxes of SNATs to all newbie cybersecurity professionals - you know, as kind of an initiation rite - and have them carry one around with them at all times, like the historic military coin tradition. When we see a newbie at a bar at Defcon or Black Hat, we can say, hey, newbie, you have your SNAT with you? And if they don't, then they have to buy the first round. But, you know, I digress.
Rick Howard: Both Microsoft and Amazon had the same concept and name for organizing their data centers. A region is a physical location around the world where one or more data centers are clustered, and an availability zone, or AZ, is a logical construct of one or more discrete data centers. For both companies, each AZ has its own subnet that the customer can divide into multiple, smaller subnets. Within those subnets, customers can deploy virtual workloads. Microsoft calls their workloads Azure Virtual Machines, or Azure Instances, and Amazon calls theirs Amazon Elastic Compute Cloud, or Amazon EC2.
Rick Howard: To reduce the attack surface between subnets, both Microsoft and Amazon have this idea of a simplified virtual stateful inspection firewall. Microsoft calls theirs a network security group, or NSG, and Amazon simply calls theirs a security group.
Rick Howard: For example, let's say that you have one subnet dedicated to finance and another dedicated to dev ops. Security administrators can restrict access to each subnet by IP and port, which is similar to the old hardware stateful inspection firewalls that were invented back in the 1990s, and that is a key point to remember. These security groups, these old-timey stateful inspection firewalls, are bread-and-butter technology. There's nothing fancy here.
Rick Howard: In order to connect their customers of virtual instances back to their traditional on-prem data centers, Azure has a SaaS application called ExpressRoute, and AWS has a SaaS application called Direct Connect.
Rick Howard: Storage is also a SaaS application that sits outside the customers' cloud infrastructure. Microsoft calls their storage service Azure Storage, and Amazon calls theirs Simple Storage Service, or S3. Informally, the network defender community has defaulted to calling the AWS Simple Storage Service as S3 buckets, and these have been in the security news since the initial launch of the servers back in 2006. Many organizations don't configure them properly and mistakenly leave them open to anybody on the internet, thus permitting all who care to look the ability to copy the data within. When you hear the media talk about the latest S3 bucket leak, this is what they're talking about.
Rick Howard: According to the Register's Shaun Nichols, as of August 2020, quote, "leaky AWS S3 buckets are so common, they're being found by the thousands now, with lots of buried secrets," unquote. Azure's storage has its leaky moments, too, but it feels like, to me, we don't see as many Azure storage leaks in the news as we do S3 bucket leaks. But, you know, I might be wrong there.
Rick Howard: The key point to remember is that both companies offer a mix of virtual infrastructure capability and supporting SaaS applications that include security tools. Some SaaS tools come with a subscription, but others you have to pay for.
Rick Howard: With their SaaS security applications, network defenders can try to orchestrate their four first principle strategies - intrusion kill chain prevention, zero trust, resilience and risk assessment. Before I talk about that, let's go over some Amazon details that are unique to the AWS service.
Rick Howard: AWS has a notion of network access control lists, or NACLs - another great acronym, by the way - that we might as well throw into the box of SNATs that we're handing out to all the newbies. I mean, I'm just trying to be efficient here. These NACLs provide stateless controls between subnets. By stateless, I mean that they don't keep track of the back-and-forth communication between two endpoints. If you want a NACL rule to block a specific IP address between, say, the finance subnet and the dev ops subnet, you have to install two rules, one to the blocked IP and one from the blocked IP.
Rick Howard: This is different from the security groups mentioned at the top of the show, which are stateful, meaning that you only have to install one rule in the security group to stop communications between subnets.
Rick Howard: AWS also specifically requires virtual router configuration. Just because you allow communication between subnets within your security groups and with NACL rules, you still have to insert the communication routes in the virtual router. By contrast, Microsoft Azure automatically configures the routes for the customer. Logically, then, the communications path between two AWS subnets - let's say the finance subnet and the dev ops subnet - is this.
Rick Howard: Now, this is a little complicated, but bear with me. You have to visualize the communications path if you're going to insert security rules between two subnets or two virtual hosts.
Rick Howard: So let's start with the EC2 workload for the finance subnet up through the security group for the finance subnet - which is optional, by the way - up through the NACL for the finance subnet - also optional - up through the router for the VPC - this is mandatory - now back down through the NACL for the dev ops subnet - optional - down through the security group for the dev ops subnet - again, optional - and finally down to the EC2 workload in the dev ops subnet. If you want to insert a security stack between the finance subnet and the dev ops subnet - let's say a virtual firewall - you would create a third subnet, call it the security stack subnet, and adjust the router to point down to it instead of directly to the dev ops subnet and then configure the virtual firewall to point down directly to the dev ops subnet.
Rick Howard: Whew, that was a lot, but I hope you get the picture. You have many options at your disposal to create zero trust rules. You probably don't need to use all of them, but you should develop a coherent plan and deploy them consistently throughout your virtual networks.
Rick Howard: With those AWS basics out of the way, let's see how Amazon helps us deploy our four first principle strategies. And let's start with resilience.
Rick Howard: As I said in the Azure episodes, resilience is where most cloud providers shine. They make it relatively easy to establish redundant workloads and redundant data storage in geographically separate locations. Compared to how the IT and security communities have been doing this for years with our own physical data centers - you know, the ones we own and maintain ourselves - virtual data centers from the likes of Microsoft, Google and Amazon take the burden of data center management off the plate. We can do it all with software using provider SaaS applications and APIs, which is probably the most compelling argument to adopt the DevOps and DevSecOps philosophies.
Rick Howard: As with Azure, Amazon logically organizes AWS into physical regions around the world and offers one or more data centers in each for customer use called availability zones. For critical workloads, as with Azure, there are many resiliency options to consider in AWS. The most compelling from my view is establishing redundant workloads in different regions that keep each other updated automatically - a hot-hot model compared to a hot-cold model or even a hot-warm model. This hot-hot model provides another degree of resilience in case a data center in one region fails for whatever reason. The other region, the functional one, will just pick up the slack and if done correctly can scale workloads automatically until the crisis is rectified.
Rick Howard: For backups, AWS offer something called Amazon EBS snapshots that function like how traditional backup systems have worked back on prem. They're incremental backups, meaning that the system only saves the changes since the last snapshot. AWS also offers a database backup SaaS application called CloudEndure Disaster Recovery that continuously replicates EC2 workloads, including the operating system, system state configuration, databases, applications and files into low-cost S3 three buckets.
Rick Howard: For backup encryption, AWS offers a server-side encryption service, meaning that once you get the data on the backup system, the server will encrypt it. And for ransomware protection, AWS offers an immutable storage service called S3 Storage Lock, that once the data is stored, it can't be changed, deleted or encrypted for a specified period of time in a write-once-read-many model. This is the old WORM model from back in the day. All of these SaaS applications and infrastructure capabilities are fine, but as the AWS documentation points out, these are resiliency tools, not a resiliency solution. You still have to design the plan yourself and then implement it.
Rick Howard: According to Amazon's Mark Ryland and Quint Van Deman, one zero trust best practice is to apply the general purpose zero trust idea to workloads. Quote, "if two components don't need to talk to one another across the network, they shouldn't be able to, even if these systems happen to exist within the same network or network segment," unquote.
Rick Howard: You configure that with the AWS Security Groups' SaaS application. Ryland and Van Deman point out that security groups can be used for both north-south traffic, meaning network traffic in and out of the security group, as well as east-west traffic, meaning network traffic between workloads on the same subnet.
Rick Howard: For north-west traffic between two VPCs, you can also establish a private link between them that no other VPC will have access to. You can also perform a similar zero trust function with AWS's APIs by installing your applications behind an Amazon API gateway and limiting who and what can access it. This also has the side benefit of providing application distributed denial-of-service, or DDoS, protection. Amazon does offer a web application firewall called AWS WAF - W-A-F - but it is specifically designed to protect web applications against attacks like SQL injection and cross-site scripting.
Rick Howard: I want to be clear here, AWS WAF isn't a next-generation firewall that you might get from one of the big security platform companies like Cisco, Checkpoint, Palo Alto Networks or Fortinet. These vendors design their security platforms from the beginning to enforce zero trust rules at the application layer, rules, for example, like one allowing the DevOps team to use the GitHub application but prohibiting the finance department from doing so. You aren't getting that done with an AWS WAF.
Rick Howard: Of course, you can't really do zero trust without a robust identity and access management system. Most organizations that have been around for a while have deployed Microsoft's Active Directory back at headquarters and in their data centers. You can use the AWS AD Connector to connect AWS apps to your on-premise directory. But if you're a small organization that, as they say, has gone cloud-native, meaning that you don't really have any on-prem infrastructure, you can use the AWS identity and access management system as a starting point.
Rick Howard: As with Microsoft Azure, it's a really good idea to install some sort of two-person control for critical functions and to watch closely what is being done with the root accounts for AWS services. According to Louis Columbus at Forbes Magazine, he recommends that AWS administrators, quote, "vault AWS root accounts and federate access for the AWS console," unquote, and then audit everything with two SaaS applications, AWS CloudTrail and Amazon CloudWatch. He also says that if you haven't implemented multifactor authentication everywhere, you should stop what you're doing right now and get that done. Those are wise words indeed.
Rick Howard: For intrusion kill chain prevention, Amazon offers some rudimentary tools that might help in this effort, but they are a bare minimum. AWS has an intrusion detection SaaS application called Amazon Guard Dog, a NetFlow collection service called VPC Flow Logs, a security cloud analytics service called AWS Security Hub and a simplistic XDR capability called Amazon Detective. But like Microsoft, Amazon doesn't seem to embrace the intrusion kill chain idea. There is no literature that I could find that talks about how AWS embraces the strategy on their website or even if they can map their services to the minor attack framework.
Rick Howard: The same goes for risk assessment offerings, too. With the telemetry collected from the AWS SaaS applications I mentioned above for the intrusion kill change strategy plus the telemetry from the zero trust and resilience SaaS applications, you might be able to calculate the risk probability yourself. But you'll have your work cut out for you. Remember; we're trying to calculate the probability of material impact due to a cloud cyberattack within the next three years or so. There is no easy button for that within the AWS cloud offering.
Rick Howard: And after deep dives into two of the three big cloud providers, Microsoft and Amazon, I have come to the preliminary conclusion that network defenders can reasonably design and deploy our resilience and zero trust strategies with some degree of rigor in cloud environments. I'll reserve judgment until I look at Google in a couple of weeks, but that looks like the general direction this analysis is taking.
Rick Howard: On the other end, cloud providers have only rudimentary capabilities for deploying the intrusion kill chain prevention and risk assessment strategies, if they have any at all. If you're going to deploy all four first principle strategies in the cloud, which you know you should do, you're going to have to supplement the cloud security SaaS offerings with other third-party solutions.
Rick Howard: And that's a wrap. If you agreed or disagreed with anything I have said about Amazon AWS, hit me up on LinkedIn, and we can continue the conversation there. Next week, we will invite the experts to the CyberWire Hash Table to see what I got wrong on this episode. You don't want to miss that.
Rick Howard: The CyberWire's "CSO Perspectives" is edited by John Petrik and executive produced by Peter Kilpe. Our theme song is by Blue Dot Sessions. And the mix of the episode and the remix of the theme song was done by the insanely talented Elliott Peltzman. And I am Rick Howard. Thanks for listening.