A deep dive on the current security threat landscape with AWS

Everyone, welcome to Net 207. We're gonna dive deep into the current security threat landscape today and we're excited to be here with you.

We're gonna talk about DDoS and the threat vectors that we see trending today. We're gonna discuss how you can protect yourself around DDoS and web applications. So we're gonna talk about web application vulnerabilities and the top trending vulnerabilities that we're seeing.

We're also gonna discuss botnets and the good work that we're doing to get around the corner to see what's out there developing in the wild so that not only we can protect the infrastructure services that we're providing to you, but you can protect your applications.

We're excited also to extend a look into the threat landscape as we look at the accounts and what's trending as far as threats in the accounts. We know that the threat landscape doesn't end at the edge, right? So we're excited to talk about that and we're not gonna end there. We're gonna discuss how you can mitigate these threats. We're gonna give you the best practices and remediation.

Um we're gonna hit the high points on them, of course, we can't be exhaustive here, but I'm excited to be here with you. My name is Steve Bollers. I'm a Partner Solutions Architect for Security at AWS. And I have the pleasure of working with our security partners and our services teams.

How many security partners are here today? These security partners in the room? Excellent. Thank you for coming. It's great to have you here. Um I'm joined here by Fola Bolodeoku. Fola is a Security Engineer and he works with the Anti DDoS organization on our Shield Response team.

So how many people are glad that we have a 24 by 7 Shield Response team to help you with DDoS in case you ever have a DDoS event, right? Excellent. So I'm excited to have Fola here with me. Fola sits at the front lines, he sees these threats come in every day and he knows exactly what he's talking about and how to best protect against those.

So, with that, you know, this is our agenda, we're not gonna have a lot of extra time today. So we're not gonna be able to stop along the way for questions, but we will come down at the end and if you can spare the time, you can come talk to us, we'll answer any questions that you might have. Um and so feel free to email us if you can't.

And so what we're gonna do is I'm gonna share with you some data, we're gonna share data with you from several of our services that we've collected because again, this is a perspective of threats from the internet to AWS. And so we've collected data points from these various sources within AWS. Um and that's where we're gonna be sharing with you. So this is actual data, not theoretical, right? And so we think you're gonna find it interesting.

So take a look at those. Those are our sources. Also, as we go along, we're going to discuss different services and ways to mitigate threats and these services aren't necessarily security services, but you should be familiar with those because they help you to identify and detect threats as well as respond to them quickly. And so just be familiar with those as we go along a high level agenda here today.

Um so take a look at that. Um one thing I would ask upfront from you is please provide us with feedback. Let us know what you liked about this session if you appreciate us sharing this data. Um this is the first time we've done a session like this at Re:Invent where we've discussed the threat landscape from so many different perspectives. And so we really do value your feedback and would like to understand how this, how this data is useful to you so that we can better share in the future with that.

I'm gonna turn it over to Fola so he can kick us off with our first topic Fola.

Thank you, Steve. Hello, everyone. As Steve introduced, my name is Fola. I'm on the Shield Response team. We are incident responders that essentially help out with customers whenever they get attacked.

My team is within the Perimeter Protection organization. And I don't operate in isolation. I think if my team were on stage today, they would want you to take away certain things from this conversation.

The most important thing I think we want you to take away is that AWS does a lot of things for you in terms of protecting you from threats at the perimeter. And we would like you to know those things, but also equally importantly is that we would like for you to leverage the infrastructure and the best practices that I'll be showing you today so that you protect yourself against these common threats. And then we both can work together against those more nuanced threats that, you know, we may see depending on the use case or industry that you're in.

So let's take a look at what we have today. At AWS, security is a top priority and within the Perimeter Protection organization, the organization which I'm in, we are focused on ensuring that this infrastructure is always available regardless of the threats that we face because we do face threats.

Perimeter protection may be a new word or phrase to you. What it essentially is, is a group of services such as AWS Shield, AWS Web Application Firewall, AWS Network Firewall, AWS Firewall Manager, bunch of firewall services. I know, but we also have internal services and a bunch of brilliant engineers that work internally that don't face customers who build the services, build the mitigations that automatically detect and mitigate, build the systems that automatically detect and mitigate these threats.

I'd like you to turn your attention to the diagram up here. What you see is a representation of the AWS infrastructure. This infrastructure comprises of over 30 regions, over 96 availability zones, over 410 points of presences. Why do I say that it's important to know this? Because this means that AWS is put in a very unique position on the world stage. We are able to see a large chunk of the traffic on the internet. That's because most of the traffic on the internet is either going towards AWS or out of AWS because we've built one of the world's largest network infrastructures with this infrastructure.

We have the ability to see patterns and common threads that we use to create protections for you. And we would like you to leverage those protections that we create on your behalf.

There are common threats that we see here and some of our customers have the expectation to share with them the insights we see because as a customer, you see solely what you have in your console or you have within your point of view. But then when you come to, you know, the large scale AWS in terms of infrastructure, you'd like to know, what do you see? What are the trends you see?

So I just want to talk about some common threats that we see at the perimeter. These threats include things like, oh sorry, distributed denial of service, distributed denial of service or commonly known as DDoS is essentially an attack on the availability of your application.

The reason why this is still a really common threat is because it's really effective, it's cheap, right? Why do you need to spend so much money to have the same level of effect in terms of impacting somebody's availability when you can get something for that cheap? So there have been criminal organizations that have gathered around to provide this software as a service or DDoS as a service to bad actors on the internet.

And so this type of attack impacts the availability of your website or your application. Either that application, it resides on the infrastructure layer seven, custom tip ports or that application resides higher up the stack on the application layer. The objective of this kind of attack is to ensure that legitimate clients or legitimate users aren't able to access the website, right?

And there are many reasons why, but the objective is to do this for reasons such as financial or maybe they have competitive, they want to try to get competitive advantage over you or it could be that they are just testing their firepower to see, you know, where they are against others because there's actually competition between DDoS you know, organizations or bots.

The second common thread that we see is on the web application layer and this attack is web exploits, web exploits target or impact the availability, sorry, the integrity and the confidentiality of the application. The idea here is simply to leverage existing vulnerabilities within a software stack.

So if you build software using either your own intellectual property or you leverage an OEM if there's any vulnerability within that flow of the software, bad actors are actively scanning to see what those vulnerabilities are and then exploit them.

If you remember around this time last year, we had to spend a lot of time in the office because of Log4J, we had to create mitigations for that because it really disrupted the industry. And that's not because a party, right? But because software, it's essentially because we are humans, we are flawed. And so there's an expectation that there may be things that you know, we do, which we don't expect. And the outcome of that is vulnerabilities that could be exploited.

So this is another common thread we see. The final common one I would like to talk about today is botnets. Now, what we've realized is that with botnets, they are largely the contributors to distributed denial of service attacks and they are also contributors to what we see with web exploits.

And so you would notice that the same organizations that, you know, launch DDoS attacks are actually have an incentive to leverage the vulnerable internet devices we live in, in, you know, in the information age in 2022. There are a lot of internet devices connected that may not have owners or users who would love to keep them up to date. And again, bad actors look for this, try to acquire them and leverage them.

So we have a team within the Perimeter Protection organization known as the Threat Research team. This team proactively looks for new threats in the wild from an AWS point of view, right? We really focused on protecting you as our customers so that we can create downstream protection such as managed rules for you to leverage.

So let's start off with DDoS on what we've seen from Q1 through Q3 2022. We've seen about 670,000 volumetric events. A volumetric event could either be an infrastructure based event which occurs on layer 3 layer 4 of the OSI stack or it could be a layer 7 request flood layer 7 application attack.

And like I explained earlier, you know, it's just the objective is to restrain or to constrict or prevent legitimate clients from accessing your application. There are different vectors involved in this. We have vectors such as TCP SYN flood. On the web application layer, we have request flood, slow lorises, RUDY type of attacks. However, we are looking at the most common type of these kind of attacks.

If you notice, you see that there is a 39% increase from the same period last year. And this is due to what we attribute to largely proxies and botnets.

Now, what we noticed is that there have been a growth in the amount of proxies and botnets on the internet. What powers this proxy and botnets essentially are compromised or vulnerable devices across the internet.

Botnet families such as Mirai, which comprises of a lot of MikroTik routers. So if you do have a router at home, you don't know who the manufacturer is, go check it out. It may be MikroTik, make sure you change your password, make sure you keep it patched because there are always active scans to recruit your smart fridge, your smart oven, your smart TV into these networks. Or it could be a router, your router has considerably higher compute power that could be leveraged probably even changing the proxy settings so that it can be used to obfuscate source IPs.

So this is what we saw in terms of DDoS and the top five vectors are the most common vectors we see when it comes to DDoS. Largely are request floods on the web application layer, right? And then when we go further down the stack in the infrastructure layer, it's either going to be a UDP amplification attack or a TCP attack.

Now, the common threats or common vectors we saw for those two types of vectors for TCP particularly we were SYN flood. We have other types of TCP attacks such as push attacks, which we saw an increase in. We also saw an increase in reset attacks, but largely the most common that we saw for TCP was TCP SYN flood.

For UDP amplification attacks, you know, it still largely remains NTP, DNS. For the most part, there are also a lot of other vectors, but these are the ones that we saw the most.

And regarding this type of vectors, you really need to understand that for the infrastructure layer, they are more deterministic. We can predict what the type of attack is. At the web application layer, it's a bit different. The bad actors can actually blend into legit requests and it's, you know, it takes a bit harder or a bit longer to actually distinguish between what is legitimate and what's not legitimate.

So we really want you to understand what those common threads are and leverage the infrastructure that we provide to protect you.

How do we protect you against this? We have a service called Shield. Shield is a managed DDoS protection service. Essentially the point here is to protect you against some of those threats or all of those threats that we saw.

It's available in two tiers - Shield Standard and Shield Advanced. With Shield Standard, we provide comprehensive protection against all infrastructure based attacks when you use either CloudFront or Route 53. If you want to protect an L7 application, you need to use WAF and manage the WAF yourself.

Now some customers want more nuanced protection and so they subscribe to our second Shield service called Shield Advanced. And Shield Advanced is a DDoS protection service that provides a wider array of protective services.

We cover services such as the Elastic Load Balancer family. We add in Global Accelerator, we add in Elastic IPs as well. And some of the other benefits that Shield Advanced provides is access to my team, a bunch of brilliant engineers who are incident responders available 24/7 to assist you when there is a DDoS attack.

We also provide cost protection during those periods where you have to scale due to an increase in demand and we help recoup those costs or give a concession when you have scaled out. And so that's the mitigation that we have for you regarding DDoS.

Now let's take a look at the second common threat that we saw from the perimeter - web exploits. Web exploit, I mentioned earlier, is an attack on the integrity and confidentiality of the application. And the idea here is simple - when there is a sort of vulnerability, bad actors are trying to take the most important things either through data exfiltration or they try to change certain things or they try to get maybe loyalty rewards, they try to just get important information from your website.

Right? And so how do they get it? They need a foothold into this. We provide a service called AWS WAF or AWS Web Application Firewall. There's a feature within that service called AWS Managed Rules. So we use the Managed Rules to tell us what were the most attacked vectors or the most attacked vulnerabilities. And this is what the rule set told us, right?

And the common theme here is code injection. If you've taken a look at the Top 10 for 2022, it's been renewed. And so the OWASP Top 10 shows that the most common threat is code injection because attackers would love to leverage the edge to get into those back end services that have those exploits.

So they send things such as, you know, if you remember Log4J last year, they would leverage things like the JNDI to send certain kind of constructed exploits to elicit responses from vulnerable services. And so these are the, this is the breakout of what we saw last year.

And then we also have other attack factors within this type. But the most important thing we would love you to know here is that we do have a protection or mitigation against this.

And to mitigate these kind of attacks, we provide Web Application Firewall. With Web Application Firewall, we provide baseline protection which essentially means that we are trying to cater to the common denominator within our customer base. And so this baseline protection provides you with something that you can start off with.

If you have a more nuanced application type or use case, then you could leverage our use case specific rules. Now, the rules are not limited to the rules that AWS curates. And when I say AWS, the team that actually curates these rules are called the Threat Research team. Again, that's within the Perimeter Protection organization.

If for whatever reason, the research team doesn't have those custom rules, you can always reach out to or use or leverage the AWS partners. I saw that we had a partner in here. So some of our partners create most bespoke, more nuanced rules - partners such as F5, Imperva, they have years of experience in doing this and some customers already have relationships with these third party vendors and they use them, you know, to just keep on the relationship.

Finally, the AWS Web Application Firewall provides a really important mitigation rule set, which is called the IP Reputation List. Unlike the infrastructure layer where the source IP could easily be spoofed because it's either been reflected or it's just sending spoof traffic, at the web application layer, it's very difficult if not impossible to spoof your source IP.

And so when you know what the source IP of an attack is, you will just block it out. Right? That's where the reputation list comes in and we curate that list learning from our threat intelligence team from what they see in the world in terms of, you know, the known bad IPs that are actually hitting AWS customers.

So these are the protections we have for you against the web exploit.

The final attack type or threat type I would like to talk about is botnet malware. Remember I mentioned that botnet essentially is a group of network, is a group of exploited or vulnerable internet devices. In order for those internet devices to be recruited for nefarious purposes, the bad actors have to leverage a malware.

Malware is a set of instructions that is, you know, executing a malicious intent. And so the bad actors would scan the internet, list the vulnerable devices and list them into what is called a command and control center, a command and control network and they then send commands to those exploited devices to do whatever they want.

It could be things like DDoS, it could be DES, it could be, you know, setting up whatever they have different choices at that point. The idea is, is an arms race between these bad actors or cyber criminals on how much they can acquire and they leverage things like the Mirai botnet from a couple of years ago where there were IoT devices that were compromised and Mirai just came on the scene and obliterated that entire space becoming the top botnet family.

And so what we've seen is we use the threat intelligence of AWS by creating a system of distributed sensors across the globe. Again, you saw the massive infrastructure that we have. So we place sensors across the globe and we listen to what's coming in over the wire from the world so that we learn, we learn what these botnets are doing.

We learn things like the IP addresses, we learn things like the malwares that they drop on those listening sensors. And then we do things with that. We create rules, we create rules that we share within services such as AWS Network Firewall so that you as end users can just benefit from the hard work and experience that we are putting into this.

For those binaries or the malware that's been dropped on, on those sensors, we actually share that data with the threat intelligence or threat detection service called GuardDuty so that they can improve their own detection algorithm.

And within AWS we have a security community, we have intelligence that has been shared among each other so that we are creating the best value for customers. These are things that many customers may not know about. And that's why I'm just trying to peel back the layer a little bit. Obviously, I have to keep some secrets. But for the most part, I would like you to know some of what we do for you.

Now, when it comes to security, you may have seen this diagram before. It's called the Shared Responsibility Model. The reason why I just want to quickly reiterate on this point is that when you are building on AWS, there's a responsibility that AWS has and it's going to be that you have our responsibility security of the cloud, which essentially means that we are responsible for the infrastructure, we're responsible for creating content such as this, responsible for creating best practice and guidelines that you can use to improve your security posture.

While your responsibility is to ensure that you leverage the experience that we have, you leverage the infrastructure that we've built and you actually secure your systems because we can't do that on your behalf. There's still that shared responsibility between both of us.

So I'm going to talk to you about two examples of how we protect you and how you can protect yourself. The second one is going to be a quick story on a customer using Shield Advanced to protect themselves.

How does AWS protect you? I mentioned earlier that we have threat intelligence that tells us when they are outgoing DDoS attacks. So the threat intelligence team can see when there is an EC2 instance because it's within our backyard, we own, we own the environment so we can through the VPC flow logs which we use for billing on intra VPC or intra AWS communications and inter AWS communications.

We have VPC flow logs for contextual data. We're not peering into your data to see what's going on. We just have an idea of the contextual data and we see when a single EC2 instance is communicating with a non-AWS IP. When we see this kind of communication, we can shut that down, we can communicate with the customer using the team called Trust and Safety.

Trust and Safety or AWS Trust and Safety is a team within AWS responsible for communicating with customers when they are violating the Acceptable Use Policy or they are violating code of conduct that makes everyone within the AWS infrastructure safe. They tell these customers that your EC2 instance may be compromised due to an exploited vulnerability.

You have to take action. If the customers don't take action, then cross and safety would have to escalate to the next level of mitigation.

I want to tell you a quick story. This story is about a customer who had built a republic in not the most optimal manner. This happens for various reasons. Maybe they knew, but they had to quickly ship to prod and they thought they could change later further down the line. Unfortunately, whatever reason it was, they were attacked by sin float.

Now, if you look on the diagram, you see a network balancer behind a web server, not the most optimal architecture because network load balancer is a low latency, high throughput service designed to create a massive pipe to your back end just so you can receive as many connections as possible.

Now, the network balance I was not overwhelmed by this in flood. However, the web application server was. Now, if they had architected in a much more expected manner or best practice manner, they would have avoided this. However, it was what it was.

They reached out to us as srt show response team, we had to build them out by creating a mitigation for them, which is our responsibility. That's why you pay us. That's why we have a job to protect you. And after doing that, we told them, hey, listen, you need to change architecture and they said, no, no worries, we'll do that. That's fine. We'll do that cool.

Um several months later, unfortunately, they had not done what we told them to do. A attack returned now reached out to us again. Srt we need your help. No problem. Could you be wrong that mitigation you created earlier? We did that right. And we told them this time, listen, you still have to change architecture. We recommend cloud front as per our best practice. But if you can't change it because of the architecture, your use case put a global accelerator in the tcb sin flood can be protected with tcb syn proxy.

Syn proxy is available with cloud front and global accelerator. So you need to protect your service against this too. They put the global in there the next day or several days after there was a massive sin flood of 225 million packets per second customer. Had no idea about this. We had to tell them we were just attacked. We're like, oh really? Yeah, yeah, the sin floods are protected you. They had no idea and that's how we leverage or you leverage the infrastructure by just following the best practices.

We understand you have different use cases. And therefore we want you to understand that there is a general way of protecting your application regardless if it's a game, it's a web application, whatever it is, you have to use this best practice that we have up here, the prescriptive guidance, right?

We're going to share the resources. So don't worry about taking the pictures. You have all the links below. What i want you to know is that you have to leverage global isolation using edge services. And you also have to leverage elasticity or scaling within the bpc using elastic load balancer or using auto scaling.

Actually, i'm using auto scaling when it comes to the web application layer data protection. I would like to actually take a picture of these rules, having these rules will protect you against 80% or let me 80% most of the data that we see reputation lists, rate limiting and automatic mitigation.

Finally, when it comes to protection of um security, we are really interested in ensuring that you are protecting defense in depth, not just the parameter protection services, but other services that come into play observable using things like security hub. You also have to do not just ingress protection, but also egress protection is network firewall. And the like with that being said, we've seen examples of how you can leverage aws to protect your service.

And now that, you know, if you don't leverage the best practices, you are actually preventing yourself from being protected by aws. And that essentially tells you that if you don't prepare, you are planning to film with that, i will hand over to my core, steve to talk about um three ccs on the um account number. Thank you, steve.

Thank you for uh excellent. Excellent. Wow. I is that, do you guys find that helpful? Isn't that amazing? Great. Thank you so much. Thank you. Excellent.

So how many people are aws customers because you love the scalability across our global infrastructure? Yeah. Right. And you love that you can just elastically spin up resources and use them on demand, right?

Well, guess who else does bad actors? Right. And so you're in control of your account and you get to do that. But you know, there are others that would want to perhaps leverage those same resources without paying the bill. Um and perhaps there are, you know, bad actors out there interested in your data, right?

And so we want to be able to enable you to protect yourself and detect any kind of attempt to do this kind of thing, which is why we have a threat detection service. Amazon guard duty.

So, amazon guard duty works by continuously monitoring aws logs and networking activity to identify uh unauthorized or suspicious behavior within your account. Right? It does this through machine learning, anomaly detection and threat intelligence for both aws as fuller talked about and industry leading third party providers, what it generates for you are findings and each finding has a finding type which includes resources and a threat purpose which tells you the primary purpose of the threat, the type of attack or the stage of a potential attack in progress.

So tens of thousands of customers use amazon guard duty to protect their accounts, uh workloads and data, which provides a uh interesting thought. And so the thought was, i wonder if we could use guard duty, uh uh threat detection, uh metrics to understand what the trending threats are, right? Anyone interested in that? Ok.

So that's what we did. And so here's what it looks like, right? These are the top threat purposes along the bottom there for the top finding types. So to kind of uh elaborate on that, right? So we have amazon guard duty, protecting services like ec2 and amazon s3, right? We talked about compute and storage, um which are common targets of bad actors, right?

And so what we want to do today, we don't have time to dive into all of these, but i want to look at the top three which compose 50% of the total findings. We're going to dive in to the top three threat purposes, understand what they are. And then we're going to look at the findings associated with those threat purposes, ok.

Now, we're also going to dive into uh just the, the mitigation or how we can remediate some of these threats and some of the best practices to prevent them. So, let's dive in, i think he took pictures. Ok?

So the most common threat purposes were unauthorized access, unauthorized access means that guard duty detected suspicious activity from an unauthorized individual. Ok. And so guard duty is going to alert you to that policy. That means that guard duty is detecting either configuration or behavior within the account that goes against security best practices.

And then stealth means that guard duty has detected that an individual or an adversary is currently trying to hide their actions by making configuration changes within the account, um, primarily disabling some kind of logging, right?

And so this is, these are the top threat purposes we're going to look at, let's look at the findings under unauthorized access. These findings centered around ec2 so we have ec2 rdp brute force attack and ec2 ssh brute force attack, brute force attacks can be inbound. And this happened 98% of the time.

So what happens is the ec2 instance is the target of the brute force attack, right? And so a bad actor has detected some open inbound ports that are exposed to the internet. Ok? And they're sending a brute force attack, of course, it's programmatic, right? They'll be sitting there doing it manually anymore.

And so once these ports are discovered through a scan, the the um brute force attack takes place. Now, as i mentioned, ban actors are interested in your resources. Why? Because you know, they need resources to perform brute force attacks.

Am i doing something wrong? Hi. Is there something i can do over here to? Are we good? Ok.

So they're interested in using your ec2 instance to perform a brute force attack, right? We don't want that to happen, but you know, 2% of the time this happens. And so uh guard duty will flag this as a high severity finding because the incidence is likely to be compromised, right? And immediate remediation is necessary.

An inbound attack is a low severity finding, but still should be mitigated obviously, right? Because a successful attempt to um get uh access gain access to your ec2 instance can lead to a much more significant uh security event which um we we'll discuss some of those later but let's go on to an example.

So in a typical vpc, we know the best practice is to place two instances on the private subnet, right? Not expose them. If you have an application that needs to be accessed from the internet, you send a, you put a low balancer in front of it, right? Put that in the public zone as fuller showed you and then let that take the traffic exposed to the internet, right?

So, and of course, you can protect the low balancer with a w swf as uh fuller uh mentioned in and uh uh amazon cron. So that's the best practice. But you know, that's for uh application access. What about administrative access?

Well, a common, best practice or not. So best practice, a common practice is to put a bastion host into your public zone. Well, you do this to eliminate the exposure of all of your ec2 instances by putting just one and then restricting the traffic from that one uh to your other managed ec2 instances, right?

This might be a simple way to do administration, but it exposes that ec2 instance to inbound traffic from the internet which could then make it vulnerable to the brute force attack, right?

So how do we get around that? Well, anybody a fan of the 19 eighties karate kid movie franchise, right? I like the uh i like the quote from wise mr miyagi that says the best block is no, be there, right?

So don't expose inbound ports to the internet.

"Instead use Systems Manager, Session Manager, which allows you to connect through the AWS CLI without any inbound ports exposed to the internet. And you don't even need to have a bastion host then, right, you can eliminate that cost altogether. Um it also gives you a centralized place to control access to all your managed nodes through policy. And so this is really a great way to mitigate that and to prevent that uh exposure to the internet, let's move on to our next threat purpose.

So, policy, the findings for policy were IAM user root credential usage. What does that mean? Pretty much what it sounds like, right? The root credentials, which is the super user for your AWS account, which has access to all your resources, including your billing information is being used to interact with AWS services. Anyone think that's a good idea? Probably not, right? So uh GuardDuty is gonna flag that as a threat because this would uh be something that a threat actor would love to get a hold of. Right?

Um ok. The other ones are centered around S3. So S3 block public access disabled. What does that mean? Well S3 is one of our oldest services and you know, so many things have evolved and new things have come out since S3. But one of the ways that S3 was used was to allow public access to your bucket. So that you could have your, your data shared with other, other folks outside of your uh AWS account. Well, no longer a good practice. In fact, it's not been a good practice for a while. And so the block public access setting enables you to do exactly as it says. However, if it's disabled, it makes public access possible. Exposing once again your resource, your storage resource to the internet. Anonymous access granted means that you're allowing access to uh unauthorized users to your S3 bucket. Not a good idea, right? Because you want to know who's accessing. You want to make sure they're authorized to access your bucket. So if the two of these public access is granted and anonymous access is granted, this could be access from anyone on the internet threat actors, they could plant something there. I mean, it's just not a good idea. Data could be exposed that's unintended. So we want to avoid that. And so GuardDuty flags both of these as findings, threat findings.

Ok. So uh you know, we talked about root credentials, we know we want to protect our root credentials. So what's the best way? Well, obviously, you know, once you create your root credentials, user names and passwords can only protect you so much as a second factor. A multi factor authentication is the way to go. I recommend a hardware second factor that you can lock away and then put policy around escalation, break glass procedures. To justify if that should ever need to be used. Right. Once again, keep it away from thread actors. Another way to keep it away is to avoid creating access keys. Access keys are the way we access AWS services without user name and password programmatically using the API um those access keys could easily fall into the wrong hands if not, uh securely managed and then limit the use of the root credentials. There are very few reasons to use root account once you've set up your administrative roles, right? You don't need it. Um there's a, there's a list actually which by the way, full and mentioned at the end, we've got some resources for you. Um one of them is going to talk about best practices for root account and we'll give you that list of things that only root can do. But for the most part, you don't need it, lock away.

All right, S3 access best practices. Again, we wanna reduce the surface area, right, exposed to the internet. And so block public access, you can do that at the account level. When you do that, it blocks public access for all regions globally. I recommend doing that. That's the most effective way to block public access. Now, occasionally you're gonna want to share resources, static content, maybe a front end application from S3, right? Don't you need public access to do that? No, you don't. Um Amazon CloudFront once again allows you to make S3 a place where you can uh uh uh send people to through a secure connection and with an identity. Ok. So in origin access identity, you can put policy around it. You can restrict it to certain buckets and even using a TLS protocol. So I recommend you do that also if you want to grant access to other AWS services or applications use IAM roles, right? IAM roles are uh based on temporary credentials, right? You have to assume the role, you can expire the role session. And so you have much more control rather than using long term credentials, which can be again um borrowed by a bad actor, right?

Um and what you can also do is put policy for your IAM roles to implement privilege of least privileged access, right? The principle of least privilege. So use conditions to limit the actions of your roles to only under certain conditions and to only the resources necessary, encrypt your data as part of your defense in depth strategy, right? KMS keys um are really the best way to encrypt your data, customer manage keys, give you an extra layer of protection. You can put key policies in place that uh someone if they were to gain access to the bucket itself would also have to be have permissions to that KMS key in order to decrypt the data and make it useful. So encrypt your data.

Ok, let's talk about stealth. So with stealth as I mentioned you have a bad actor trying to stop logging uh of access to your S3 objects, right? So server access logging lets you know anytime an object within the bucket is being accessed when server access logging is disabled, GuardDuty will bring that up as a threat. Why? Because you have no visibility now, right? There's no way to audit who's accessing your data. And so this could mean that, you know, your account has been compromised or it could mean or credentials have been compromised. It could also mean that you have overly permissive access that needs to be remediated. And so this is uh something that whether you have um just, you know, common data or if you have even uh worse off sensitive data in your buckets, you definitely need to have a lock.

Um i recommend using um using CloudTrail data events if you have highly sensitive data in your bucket to log. Um but the first, the first thing you need to have is uh you know, server access logging or some kind of logging enabled for your bucket, right? You can't manage what you can't see. Um and so by all means enable that. Um and then how do you detect if server access logging has ever been disabled and remediate quickly? AWS Config right, Config manage rules, make it easy because we've already created them for you and you can just implement those rules and they constantly audit the um the configuration of your bucket to determine whether or not logging has been enabled. Once it has been disabled, you can then have an automated remediation step. And this is what that would look like.

So if AWS Config is seeing your S3 bucket and server access long has been disabled, it will trigger the automated remediation, which is by the way, already been uh created for you. The rules have been created for the automation documents have been created for you in Systems Manager. And so they will trigger using the configuration uh that you plug in for your bucket. The server access log going to be re enabled. You never have to do a thing. There's no programming, there's no coding involved here. You just have to set it up. I mean, you know, we can't decide to turn it on for you, but we have put it there uh for you. And so you'd want to know that happened at least, right? Even if you didn't have to do anything, the automatic remediation has happened. If you want to know what happened, you can set up an event rule. That event rule then can again without code, trigger a simple notification service to send an email to your security operations and let them know or let you know what has taken place again. Automatic remediation is absolutely essential when we're talking about um protecting resource and resource configuration and security.

All right. Now, I want to turn our attention to kind of a different uh a different data point. Ok. So up until now, we've been talking about GuardDuty, we've been talking about um threats that were detected, the top threats a across the GuardDuty findings. But another thing that i thought would be really interesting is to talk to our Customer Incident Response team. Anyone familiar with the Customer Incident Response team? Ok. So there are a group of professionals in AWS that provide threat detection and incident response support, ok? For customers who are actively experiencing a security event on the customer side of the shared responsibility model, right? So they help with things like ransom and ransomware, privileged escalation, unauthorized resource usage. And so customers call them and they help to remediate or to triage the situation. And so what i wanted to do was focus in on one of those types of events for the purpose of helping you to understand how they unfold and then what the primary, what the what the most common cause of this type, these types of events and really all of all security events that they've seen at AWS is so we're going to look at ransomware, ransomware, ransom data destruction. These are all forms of ransom uh security events, anybody concerned about ransomware or ransom events? Yeah, it's been in the news a lot. It seems like uh threat actors are becoming more sophisticated, right? Commoditizing ransomware um types of attacks. And so you know, we can't let our guard down. We have to be constantly, um, checking to see, you know, are we uh mitigating that risk? And by the way, that's one of the resources. Um, we don't have time to talk about uh ransomware in this session too, too much, but we do have a lot of good information on our website. So i've included that in a list of resources at the end. Please take a look at that"

Now, also we have sessions here at re:Invent on mitigating the risk of ransomware with AWS security controls. So check out WPS305 if you're interested in that, if you're interested in data protection and application recovery strategies for ransomware events, then check out STG305R1.

So that's available for you this week. But what I wanna do is again, just touch on a high level of the unfolding of these events so you can see the pattern.

So ransomware, we're familiar, we're pretty much familiar with ransomware, right? Some of them are listed there in that graphic. So with ransomware, an unauthorized user gains access and this is in the context of AWS, ok. They gain access to customer accounts through phishing emails or browsing a malicious website and picking up some form of malware or capturing credentials that captures their credentials. And then they typically will customers will log into an EC2 instance or access it from an endpoint outside of AWS where the malware gets deployed. Ok?

Once that malware is deployed, it creates that staging ground. Typically, EC2 instances are not operating in isolation, right? So they typically have access to a database, Amazon RDS, perhaps other EC2 instances, maybe even S3, right? And so the malware can encrypt that data, right? There's a pathway for it. Pathways to data are very important. Pay attention to your pathways to data, right? That's one tip.

Um because unnecessary pathways to data or overly permissive pathways to data, create a pathway for potential malware, right? And so once the data is encrypted, we know how it it works, right? The bad actors then make a ransom demand to have that data decrypted.

Alright. So what is a ransom event? Right, ransom event it's somewhat similar. Um but unauthorized users gain access perhaps through unintended keys or unintended disclosure to AWS access keys or secret say database passwords or something like that. What they typically do is they want to access the data and exfiltrate it to another location. Once it's in that location they're going and typically it's sensitive, highly sensitive data is is obviously the target, right?

Once it's in a separate location, they will make a claim and show that they have the data and then of course, hold that data for ransom until the ransom is paid.

Data destruction. What is data destruction. Well, it's actually also a ransom event. Um unauthorized users gain access in a similar fashion, right? Unintended disclosure of credentials. They start deleting data from your data resources. So RDS S3, maybe EC2 volumes. Um so once that data is deleted, they'll take responsibility, they'll send a message to the account owners and let them know, hey, you know, we've deleted some of your data and they make a ransom demand. Ok?

So whether or not the ransom gets paid, let me just tell you this data is gone. Ok? So how do we safeguard against that? Right? Obviously, we talked about many things already. We talked about pathways to data, we talked about limiting the exposure of your EC2 instances. And, and how you access EC2 instances, it's got to be done securely.

Um but this is also points to a need to have a clear backup and recovery strategy, right? A tested backup and recovery strategy. Ok? I don't want to tell you and I don't have the number, but I was told that many customers who experience this kind of event don't have a backup, they don't have one. So look without a backup, nobody wants to be the target of a ransom event or any other kind of security event, but without a backup, you can't recover, right? So you gotta have those things in place.

So all of these things are avoidable this happens to be the most common scenario, by the way, which is shocking, isn't it? But all these scenarios that I mentioned were 100% avoidable using some of the best practices we've already talked about. Right?

Now here's what the customer incident response team told us. Hopefully you saw a pattern throughout each of those types of events, here's what they said, the unintended disclosure of security credentials and secrets, 100% avoidable, right? 100% avoidable. How do we manage our credentials? Are we using the root account? Are we using long term credentials? Do we have a way to safeguard our accounts? With, with simply doing a better job of managing credentials?

Um the these events could be completely avoided. And so AWS has a service called AWS Health Dashboard. Is anyone familiar with AWS Health Dashboard? Yeah, a couple of people. Ok. So a Health Dashboard can scan popular code repositories. And what it does is if a developer accidentally exposes credentials, they would end up or this would end up creating an event within the AWS Health Dashboard that you can act upon, you can action upon. You can actually delete that exposed credential immediately again, automated remediation, automated remediation is the key.

Ok. We don't have time. If credentials are exposed, there's no time to discover using, you know, a human and then go and remediate that credential every moment counts. And so isn't it amazing that with just a very little. And by the way, this solution is out there on GitHub, so you can deploy this into an account play with it, test it out.

And I know that there's other types of solutions out there, but it can automatically delete the public exposed key using Amazon EventBridge using Step Functions and, and serverless Lambda. And again, all that code is out there if you want to look at it, it's not very complex, it can query CloudTrail to see what those, what that credential has recently done, what that identity has recently done and then send you an email or send your security operations, an email letting you know what that recent activity was and that, that credential was remediated, deleted, neutralize the threat automatically.

So, automatic remediation is the key. Well, we're getting to the end of our time and I wanna just review some key takeaways, right? Hopefully, you realize through all of this that the data is telling you that, hey, AWS has your back, right? We have a lot of protection in place as Fola mentioned, protect to protect you from threats coming from the internet.

And to give you the tools to protect your applications and your infrastructure, but it's up to you as well, right? It's a shared responsibility model. So you have to eat your veggies, do the things you know that keep good security hygiene to avoid being vulnerable to these types of threats that we've talked about today.

So Fola mentioned the DDoS prescriptive guidance. He showed you a slide with that. We also have a white paper that we've got a reference at the end for you to, look at and read more about, the AWS WAF manage rules which has all the goodness of our threat research that we're constantly in motion, putting better, you know, enhanced rules out there so that you can protect your web applications exposed to the internet.

And then from an account perspective, we talked about limiting the, the use of root accounts. But also I don't wanna, I don't wanna lose you on long term credentials. I know long term credentials sometimes need to be used. And when you do, you've got to rotate those access keys, right? But for the most part, avoid using long term credentials, use IAM roles, right? They're much more secure and there's really not too much of a need anymore for long term credentials.

Ensure that any pathways to your EC2 instances are secured, you know, so don't just trust because of the network location that the EC2 resources that you have in your account are secure, put additional protections in place, put zero trust, network access and zero trust, network, best practices in place.

And protect your EC2 instances as well as your S3 buckets, right. How many people are familiar with access points or, or, or gateway endpoints? Yeah. Yeah. So you can apply policy to those to scope down who and what has permissions to those resources. I absolutely recommend you doing that. Those are guard rails.

And you can also put the guard rails in place when applying the block public access. Did you know that you can apply a sort a service control policy that restricts the ability to change block public access? Yeah, you can do that. So don't, don't allow IAM users or, or identities to change that setting and then you don't have to worry about, you know it becoming public accidentally before you realize it. Right?

And so user defense in depth strategy is what we're getting at. We mentioned a number of things Fola mentioned about protecting your infrastructure. I talked about encryption for your resources and of course, zero trust network access. And there's so many other things that we couldn't get to today but put that defense in depth strategy in place.

And then I talked briefly about having a, a tested backup, AWS Backup will allow you to use policy based backup. You can enforce backups across your organization if you're not familiar with AWS Backup. And it, it is much, much easier to do that using policy.

You can also store it in secured encrypted vaults that are immutable. So threat actors would not be able to leverage that data in the event that you ever had a loss of data. You would have data available to you in your tested backup.

And then one other thing is, you know, having a recovery strategy is great, but a tested fail over and recovery strategy is better, right? If it's not tested, don't trust it. And it's essential to use a tool that makes that easy. So we have Elastic Disaster Recovery, we know that there's other partner solutions out there that make it easy. Whichever one you prefer, just make sure you use one and have that fail over. Recovery strategy tested.

I think that's all the time we have. Fola and I are gonna come down. These are the resources that we want to share with you. I'll leave that slide up, but I'll just ask you to please help us with feedback from the session survey and let us know how this is helpful to you. So we can again share with you even better in the future. Let us know where we can improve. We're gonna come down at the front, hopefully, we can take a few questions at the front, but that's it for our session. So thank you everyone for your time. Thank you for your attention. Really, appreciate you coming and have a great rest of your week at re:Invent.