Multi-stage attacks are the Final Fantasy bosses of security

0:00Hello, everyone, and welcome to the Stack Overflow podcast, a place to talk all things software and technology. I'm your host, Ryan Donovan, and today we are talking about multi-stage attacks and all the complex security issues that AI and ML have brought to the table. My guest today is G. Rittenhouse, who is VP of security services at AWS, so welcome to the show, G. Thanks, Ryan. Good to be here. Before we get into today's topic, we'd like to get to know our guests a little bit. Can you tell us a little bit about how you got started in software and technology? Yeah, so I've been in technology my whole career. It actually is fairly funny because I started just going deeper and deeper, and so I actually have a PhD in a quantum transistor, thinking about quantum computing long before then, and then I kind of worked my way back out of the quantum computation all the way back

1:04into software than in the industry for a long time. So you made your way from the very small to the complex and very large, right? Yes, yes. So today we're talking about multi-stage attacks. My dumb brain thinking about that is like, oh, that's like a final fantasy boss where it's like, they change his form or several times, but that's not what we're talking about here. What is a multi-stage attack? Yes, so you can kind of think about it as a sequence of events. You start something. Maybe it's a fishing attack where you get one of those emails, and unfortunately we can help ourselves. We click on the link and then stuff happens, and from there you go into maybe an account, and from that account you want to elevate your privileges to get more stuff, or you do reconnaissance. And as you kind of go along, these sequences of events kind of leaves a fingerprint, if you will, a trail. And so each one by themselves is like, huh, that's pretty suspicious.

2:07Like, you know, G is an acting the same way anymore, but, you know, okay, well, work human and things happen. But as you start to put the pieces together, you go, hey, wait a second, this is not right. And eventually at the end you say, hey, something's wrong and you flag it. And so each stage is interesting, but when you put it all together into a multi-stage context, the threat becomes much more evident at them. So for each individual stage, you might overlook the sort of signals coming out of it. What are those signals that will get overlooked? When we look at trying to detect threats, you can kind of think about it as searching for that needle, that proverbial needle, in a stack of needles. As developers, like we're in the code all the time, we're deploying code all the time, we're patching code all the time. So our execution and application environment is very complex.

3:08It's changing all the time. So it could be that I've got elevated privileges or I'm trying to do that because I've got an S2 and I need to get in there and break glass or do something there. And that is unusual for me, but it's not a threat. It's just an anomaly and it'll go away. So when we do have to kind of extract out that kind of threat context from just being unusual and that's when we have to stitch it all together to figure out the underlying issues. So part of it is understanding behavior of a user account, but I imagine there's also a traffic monitoring aspect to it for any sort of networked application like all you're getting is traffic, right? So how do you identify the sort of needles here? Yeah. One of the things that we have an advantage of in AWS and the cloud environment is that

4:11we have an immutable journal of all the transactions that occur in the cloud. And this is like the size of it is incredible, quadrillions of events happening. But every time I go into and change a resource configuration or every time even a new network flow is established, these things are recorded in logs. And so whether they're VPC flow logs or I am kind of policy change logs or configuration change logs. And so we are able to look at all of those logs. And like I said, tons and tons of them every single day and then extract out those needles. And so there are behavioral analytics to it. There's machine learning, AI rules, all of the kind of usual math that you would expect, find those needles. And then of course, just given the volume and the complexity of application environment,

5:16we have to stitch those needles together to get that overall multi-stage view of what's going on in the account. And so we have all these logs. If you flag an IP or a port or some sort of behavior as problematic, does that propagate to everybody's AWS account? Can you use the account of your scale to flag that? Yeah. So what we do is we want to make sure that of course once we detect an event, we are able to help our customers resolve it as fast as possible. These events can happen quickly and as you've probably heard from many reports, if you're not careful, data exaltation can happen in minutes. And so we want to get the relevant information to the relevant people as fast as possible. And so we generally have additional context of what's going on like the developer who committed that code or the admin for that account or the cloud admin or even the system admin

6:17or SRE. And so we're able to kind of filter these things and route them to the right people at the right time instead of like sending the alarm to everybody there. That just, we don't want to spam the individuals from that perspective. Right. Nobody wants to get a false page to in the morning. Yeah. Exactly. Exactly. You know, like you said, the speed of exaltation can be, you know, minutes, but obviously you're parsing, I'm sure it's massive amounts of data and the logs, right? How do you optimize that speed of parsing and also have it be kind of accurate to the signals you need to pick up? It depends on the classification of an issue. For example, say someone opens up their backend S3 bucket to the internet. That's a very dangerous situation, obviously. And so we have signals for that. And immediately when that happens and alarm goes off and we send it, there's no multi-stage

7:20to that. It's like, hey, just shut this down. And so on that, it's pretty straightforward. You just look for that signal as soon as it's detected go. Other things are more nuanced in that I may be looking for credentials and that could be suspicious, but as a developer, I may say, look, I want to know where my credentials are and if they're hardwired in the code, remove them and improve the security. So it's natural that I'm looking for credentials. It's what's the intent behind that that makes it a threat versus something that we as developers do every single day. And so that intent takes a bit of time to establish. Sometimes the intent can be recognized because let's say the threat is more a smash and grab. I get in and I'm just really looking for these things to extract the data quickly. Other times it can be over weeks or months as I'm trying to go through this undetected

8:26step by step doing it and hope that I'm not noticed. So it really depends on the approach, the technique that people are using. We call them tactics and techniques and processes. Depends on which one of those are being used and we have lots of math and things like that to kind of parse that out for us. Just sort of clarify something from my own thinking. You talk a lot about user access, user account configuration, elevated privileges. How much of these attacks you're talking about come from validated user access and how much is from sort of security holes like bad token configuration or something? Yeah, I don't have the exact numbers. But what we see the overwhelming point of entry is a compromised credential. And this is a legitimate credential that's been hijacked. We are generally not the source of these things, we're the target of these things.

9:29So somewhere upstream somebody clicked on something or something happened, the count gets taken over and then they enter AWS and then we detect that suspicious activity and push it back. And we have a kind of classic pattern for us is again, we see something suspicious happening with an account, let's say my account, we notify the developer or the account owner. And then from that they realize, oh, their broader enterprise has been compromised and feeds back and they come back and say, oh, thanks for finding that because we didn't even realize there was a broader attack happening at the time and we were the first to notice it and help them out. Yeah, that makes sense that it's like, it's easier to do a social engineering attack than to figure out some sort of zero day or feel like with AI now, those sort of social engineering attacks are getting easier to automate and run at scale. Are you seeing any sort of new flags for that, any sort of greater volume of phishing attacks

10:34or otherwise? I don't know about the volume because we don't measure that again, that's upstream, but we do see an increase in the sophistication. It used to be a random prince, you know, has $10 million if you just click on this link and stuff like that, misspellings and everything else. These things are getting quite good nowadays and so you really have to eat your security vegetables and get trained on what, like, hey, she doesn't normally send me an email asking for this information and kind of put the broader context. I will say, both in terms of the compromised credentials, that's one path that comes in, even with a lockdown system. The other one, of course, is the, to your point, the vulnerabilities or misconfiguration. I made a mistake, I left it open or I've got some old code in there that I haven't patched and that can be exploited by people without the compromised credentials.

11:37And so compromised credentials and bone vulnerabilities are the two things that are pretty much the two largest threat vectors that we see inside of AWS. Yeah, and I feel like now with so much easy code gen AI, we're getting a lot more of these sort of security flaws. I think I heard of one where it's just like compromised a token, found a token that could be used anywhere and just gave them the right access to the databases that happens. We do see, again, as you kind of think about the application of AI and whatnot, the approach has remained the same. Let's say I get compromised as a credential or I've left something open, somebody gets in. And the first thing that they do is reconnaissance and, you know, they're using red jacks or bash commands and they're trying to find things out and whatnot. With LLM's built into the IDEs and the developer and I just asked the LLM, hey, where's my token or something?

12:38And it says, here you go, I've scanned all your code, I've scanned all your repositories, here's what's going on, your search, your credentials. So it does accelerate these kind of attacks and you just have to be mindful of what you're doing there. Yeah. I wonder if the sort of AI code gen ubiquity has a sort of other knock on effect where like like you said, you could flag them as doing all these rex, looking at all the code. But now it's like, that's what the code gen does every day, exactly. And the other thing is is that in kind of classic software development, you're writing the code, but there's a senior manager or principal engineer, they're doing code reviews, they're saying, hey, this isn't right in our environment. And if LLMs are like generating a lot of code quickly and also doing the code reviews, you better hope you've got a pretty good one there. You don't want to learn the code at two in the morning with a P0 on your desk.

13:38That's not a good time. Exactly. That's sort of like AI code gen, AI scanning. Have you had to adjust what the signals are based on different behaviors by developers? No. But what we have to do then is include either LLMs or agents into the calculus. So it used to be in kind of a classic software architecture. The users were on the outside, separated by a firewall or a WAF or CDM, whatever it is. And then the code was on the inside. Now the agents are on the inside and they're operating there and they're able to do things. And so depending on what they're allowed to do and when and what not, it's a very different dynamic. And so you now have to kind of think about, in some ways like an insider threat inside of your environment and make sure that you're applying minimum privileged access or temporary

14:41access, monitoring these things so that as a software developer and an operator, you're able to see what this agent is doing and is it looking suspicious or what not, even well before there's a security event. I could imagine before agents, anytime there's a activity going on without a user connection, you'd be like, oh, that's clearly bad. Yeah. Yeah. Exactly. Yeah. That is not a good thing. But now we have them all over the code. And so it's one of those things. And again, the whole point of an agent is the probabilistic behavior of it. It's not just a workflow that you would, you know, deterministic workflow that you know and understand these things can take a left turn. And it could be a left turn, not just from, let's say your rag database or something, but you asked it, it went off onto the web. It hit some website that had some malicious code in it and now it's behaving differently

15:42through this kind of indirect prompt injection capability. As somebody who builds threat detection software, what's better, a false positive or a false negative? Well, we try to minimize both, but from our perspective, there's really no difference. If I'm sending you false positives and you're investigating everyone, they might as well have been true positives, right? You've spent the resources, you've interrupted the team, you're going through all of this. And so that's bad. A false negative is also bad because you eventually find it and now it's a breach. And so we want to minimize both of those and take great care in doing so. So is there a way you can test those sort of things in simulated environments? Can you have like fake threats or, you know, real threat actors? Yeah, we do. Finally, for AWS, we have a lot of users building code on AWS.

16:43And so we see a lot, but we also have managed services and internal security teams that are able to see things. And so we call a flywheel where we detect things, our security teams or our managed services, others find things. And we can close that loop. And so we're constantly going around that loop to improve the systems, improve the algorithms and whatnot just by the sheer size and scale of the data that we process every day, both on the detection side as well as the investigation and the response side. To that size and scale point, I imagine there are some attacks that, you know, actually come from within the house, right, whether it's a compromised EC2 instance or some bad actor who got Cloud compute, are there different protocols for handling those sort of attacks? Well, what we do is we also use our own data to evaluate that.

17:45You know, we have our internal security teams looking at that. We use that data in two ways. One is we eat our own dog food or drink our own champagne or whatever way you want to look at it. And so again, we have that kind of large flywheel. But we can also inject known malware or the latest kind of TDPs or things like that in there so that we're constantly stressing the system. You can kind of think about as like chaotic monkeys for security, if you will. And so whether it's an actual individual or fictitious one, we're constantly trying to stress the system to improve our responses and response capabilities. It is interesting. So it seems like there's a kind of an economy of scale where it's like you have all of the data for the AWS Cloud as a whole. One of the benefits that AWS has in some sense being first to market, one of the early

18:47questions from from day one that AWS encountered was, why would I move my workloads from my on-premises environment that I've locked down. I know well and send it way out into the cloud. And because that was the primary overwhelming question in the early days of AWS, AWS was built from the first line of code with security in mind because we had to deal with that problem. Like if you entered the cloud market today, it's like, oh, yeah, it's a cloud. And so let's look at cost or performance. But being first, you had to really think hard and convince the largest governments and companies and whatnot that we were actually secure than what could be possible on-prem. And so by doing chip attestation, we have our own hypervisors, we have our own like network,

19:51like all of that stuff is in the background, which again, enables us for our customers today to be able to look at all that information and gather all of that in ways that if you didn't consider that from day one, would be very, very difficult to build bolt on and evaluate. You know, having that overview of it, do you have to consider, you know, the risk of leaking information and logs? We do have to protect AWS, you know, I don't know the number, but a significant amount of the internet traffic comes through AWS. And so we have to protect it both for ourselves and our customers. And so all of that data, we collected logs and kept logs from the very beginning because you never know, like if something happened, you have to trace it back, like where was that original point? And so, yes, these are very much locked down, the systems are locked down, the customer data is locked down, both by processes as well as technology and mechanisms and things.

20:57We take that very carefully, our CISO, Steve Smith, and I'm really fortunate because Steve as well as our former CISO Andy Jassy, they came together in a minemail to really get all these things from the ground up, locked down. It's interesting, the sort of cloud concerns, like I worked on a cloud security book eight years ago or something. And one of the big concerns was multi-tenancy, and I don't think I've heard anybody talk about multi-tenancy in years. Through your research, I'm sure you find out, like to do it right, to really make sure, like you can't even SSH into the chip, right? Like, even if you ask me, hey, gee, could you go in there and do these things? I was like, nope, can't, because just at the fundamental atomic level, these things are locked down. It's pretty impressive, for sure. It seems like the ways that people broke in were like security researchers doing a wild thing where they put a fake input, output device on, or they had a video file that compromised

21:58the system. And I was like, this is a lot of work for a little bit of juice. The work that we do on my end is while that infrastructure is built for security from the ground up, users can still misconfigure something or click on something and come in, and that kind of what the customer is able to do versus what we're able to do, we try to really focus on making that easy and securing our customers. Everybody AI a little bit of the security side, but there's also AI on the attacker side. I think heard about an attack recently that was an entirely vibe coded or something that adapted as it went along. How are you thinking about addressing these sort of mutating viruses? You can imagine, is there a new attack vector? With these capabilities is something fundamentally changed, or is the attack vector is pretty

23:00much the same, but the approach or the execution of it is vastly different. What we're seeing today is more of the second. Imagine I go in, I've compromised the account, I go in, and instead of me as a single user, now I launch a thousand agents or so, attacker agents, but I still got in in that kind of same way. So, what we see is the sophistication of the attacks once the initial breach has happened, as well as the speed. These things, you can download data very, very quickly. You find the repos and do that, and so everybody has to be super sensitive as a developer to make sure that you have clean separation of certs and tokens in your code, and all of that is locked down, your privileges are locked down, because it happens so quickly

24:01with an agent. It sounds like the real point of failure is that user access control, once the breach happens, it seems like it's almost game over, right? And this is why time to detect is so important, but also time to respond. And this is where that kind of trade-off happens a bit that we talked about earlier around false positives, because imagine I'm misconfigured something, and I open something to the Internet, an S-read bucket or something. You'd want that to immediately be shut down. But if it was a false positive, and I did that, I could break the app, right? So you have to really be able to find that balance of being able to keep the app up so that your customers can be using it while also really locking it down from a security perspective. Do you allow people to be flexible with that? If I want to indulge in my paranoia and have everything that looks like the pair of an attack sent my inbox, can I do that?

25:02Yes, you can. You can adjust all those things and the criticality of it. We allow you to do that, because again, we have tons and tons of customers on AWS, and each one can be unique, heavily regulated, fast-bibing, or three people in a dorm room trying to start a company, just go fast, and you'll deal with things. So we want to make sure that everybody is secure and making it as easy as possible, but also flexible so that they can adjust to their own needs and requirements. What makes you nervous about security for the future? It's one of those things that you do have to be able to sleep at night, otherwise you can really go off the deep end. But one of the things that has always fascinated me about the security industry is that it comes in technology ways. It started with, you said about the worm, the morris worm with the network, and then

26:08all sudden, network and firewalls happened, or endpoints and nowware and through email. And so also an endpoint security became and cloud and whatnot. And so security is never ending. We now have the introduction of agents, and so we have to deal with agents. But you can't forget all the other things, right? So we constantly build on each other, and that's what makes it exciting. And what I find interesting is particularly in these early stage of technology adoption, while we're all learning together. I think we know email well, we know endpoints well, we know, there's still challenges for sure. I don't want to understate that. But when we're all learning, that's when you have to go fast. So just the speed of execution is what keeps me up at night in these early days. And then we'll move on.

27:10Yeah, we'll move on. One of the things that's interesting for me is, again, as we kind of think about this multi-stage attacks and dealing with it, you can kind of extend that same math or the same evaluation across many different signals. So we spoke about threats, but you could also extend it across vulnerabilities or misconfigurations or other things as well. And by doing so, you're able to add context. So it's not just, hey, something suspicious is happening. Well, if that's your hack-together lunchtime menu website, okay, fine, like something happened and then I'll get to it. If that's your backend billing system, like you want to get to it really fast. And so the other thing that we have done is started to expand the context across multi-dimensions of those signals so that we can help people prioritize as well. We're all busy, we're all coding, we're all trying to bring value to our customers.

28:12And so we want to be able to work on the most important things. And they may not be the most critical from a threat perspective. That context is important. And so I just want to remind the users and your users as you're developing code to have that we're working hard to bring that context in. So to really make the life of a developer much, much easier. Well, ladies and gentlemen, and otherwise, it is that time of the show where we shout out somebody who came on to Stack Overflow, dropped some knowledge, shared some curiosity and earned themselves a badge. Today we're shouting out a populous badge winner. Somebody who dropped an answer that was so good, it outscored the accepted answer. So congrats to James Cansey for dropping an answer on the spiral rule about declarations. When is it in error? If you're curious about that, we'll have it for you in the show notes. I'm Ryan Donovan, I edit the blog, host the podcast here at Stack Overflow.

29:15If you have questions, concerns, comments, topics to cover, et cetera, email me at podcast at StackOverflow.com. And if you want to reach out to me directly, you can find me on LinkedIn. Thanks Ryan. I'm G. Rittenhouse and thanks for the opportunity to get together and discuss all things security. You can find me on LinkedIn and Stack Overflow. Awesome to hear it. We'll talk to you next time.