← All talks

Scaling Amazon GuardDuty: A Comprehensive Detection Strategy

BSides Ahmedabad · 202522:49366 viewsPublished 2025-05Watch on YouTube ↗
Speakers
Tags
CategoryTechnical
StyleTalk
About this talk
At #BSidesAhmedabad 0x05, Avinash Reddy Thumma took the stage 🎤 to talk about "Scaling Amazon GuardDuty: A Comprehensive Detection Strategy" 🚨 He broke down: ✅ How GuardDuty works ⚠️ Current detection challenges 🚀 His strategy for scaling and improving detection ✅ And wrapped it all up with a concise conclusion. This one’s for the defenders, builders & breakers out there! Don’t miss it! #CyberSecurityTalks #BSidesAhmedabad #AWS #GuardDuty #CloudSecurity #infosec #hacking #bugbounty #threatdetection #TechTalks
Show transcript [en]

Hi. So, how many of you are uh from the offensive side of security? All right. Okay. And defensive side of security. All right. Okay. Okay. Okay. So, you all right. So, um aa and we have done pen testing before. Offensive. Yes. Yes. Yes. All right. So today uh right now we'll be talking about uh AWS uh and uh finding uh and detecting threats. We have Amin here who is a lead threat detection uh engineer at Salesforce. So uh uh for both offensive and defensive it will be a really good uh deep dive inside about how do we detect uh threats in the AWS cloud environment. Up to you Amin. Thank you. Hello. Good evening all. I

hope you had a good time today. Today we'll speak about uh how we leverage guard duty in cloud and then do it effectively at scale. Uh as we move forward uh this is the uh flow that we'll go we'll do an introduction of what we are going to talk about and then we'll move about understanding what is basic guard duty. Guard duty does not need any introduction but we'll just touch base and then we'll address what are the current detection uh strategies that are being followed widely in the industry and then we'll we'll see why is it failing right now and then what is the proposed uh strategy that I I'm going to uh give a different perspective today

and then we'll do a small recap with a small story of what we discussed and then we'll conclude the uh session. About myself, I am Ainash Reddit Tuma, lead threat detection engineer at Salesforce. I have about uh 13 years of experience u in cyber field. Uh right now in detection but I have worked in different roles like IR, cloud, IR, cloud forensics etc. So in in my last 13 years I worked in five companies. So you can think I worked in different range of work streams and then worked with multiple teams. So the problem that we are going to talk today exists everywhere almost everywhere and why should you listen to me collectively that I'm going to prove

or I'm going to say that you will also realize that the way we are using guard duty is not really that effective and why is that then how is a new perspective that will be helpful for each of you if you're from red team or offensive team you will you will identify that there are so many loopholes within the current system and then how you could leverage easily and from defensive background and from pressures you will understand how how weakening is our detection system right now and then how we can leverage with a new perspective and if you're still wondering I don't care I think there are two exciting gifts today if you pay attention and

stay focused there are two challenges you could win uh it's up to you these are the two uh really interesting interesting gadgets. One is portable speaker and then one is&c earbuds I think. So you can keep your mobiles off and then stay focused. Uh as I said we'll move to understanding guard duty and guard duty does not need any introduction but considering there are freshers and new new folks to the industry. I'll just give a brief that guard duty is a native detection service that is offered by Amazon AWS and then it continuously monitors the uh cloud activity API calls within the AWS accounts and uh it identifies threats and then it throws out alerts and then if we consume in the

production setting we'll uh do a cloud IR of what's being suspicious and what's malicious and then respond accordingly and in Amazon terms uh they call it finding types which are essentially as signatures you could say where in the Amazon site itself there are about 180 different finding types that Amazon has right now for guard and then once you enable it uh foundational uh ones are free so they are enabled by default so it works against multiple resource types all of those 180 different signatures or finding types based off uh EC2 IM S3 etc etc there are multiple things And if you go deeper uh look at the findings table uh the first column is uh

the finding type meaning the signature name or the finding name. uh first one is discovery S3 anomalous behavior that's the finding type name and the second column is resource type meaning it's it's working on S3 type and the log that is being looked at is the foundational data source uh which is cloud trail data events of S3 and there is a finding severity given by default from the uh Amazon which is low high uh depending on the severity of the finding. Now that we have touched what the basics of guard is, let's move to the current challenges or the detection approach uh being followed widely across the industry. Yeah. So as I said I worked in

uh five companies and then at least I have uh four connections in each company and then they worked in multiple companies. When we meet we discuss what what are they doing in the cloud with guard duty and then how is the detection mechanism. This is what we see everybody if not for major 100% majorly about 75% of them are using just guard duty based on severity. If the uh log say severity is greater than seven we call it high severity and then uh keep it as an alert and then if if if the severity falls between four and seven we call it median and then operationalize. So we are narrowing down 180 different finding types or signatures and then creating

just two or three detections and then making it into production. But what is the problem with that? Because we are not having any environmental context or we are not doing any baselining. Uh what happens with with that is like it creates a lot of noise. It creates so many alerts that it creates alert fatigue among security analyst. And then in an operational setting we call it uh whenever there is a surge in alerts they constantly keep asking for allow list or excluding certain signatures and then it in turn leads uh to a situation where we kind of start excluding signatures or different finding types. So we create uh gaps in our own detection uh uh pipeline and

then there's a lot of false positives and because we are excluding all the signatures there are miss threads. It's like there is a ocean that we are trying to control with a small single gate without any context or without any uh profiling and as an outcome of that because of the increased alert volume there is alert alert fatigue within the security analyst and with the visibility gaps whenever there is a discussion about efficacy of guard duty in general uh within the executive because there is no threats identified or because of lower troop posate it tends to a situation where we feel that low confidence on graduate that it's not effective but is is that really

ineffective I don't think so but it just needs the right context to make it more effective and then how do we use it let's take a bare minimum example that uh let's install a security system within a home and then the security system says there is a threat with red colored garments in in the house and we can easily identify and then identify that yes there is a threat and that is true uh in in it sense but we expand the same system to a street and then call it because it worked in a single house uh it will work but in a street where there are hundreds of people and there are uh hundreds of uh people wearing in red

guard duty system still says that uh there is a threat in red color but which one we don't know because we don't have a profiling we did not have enviral environmental context text. So we'll end up in a situation where we have so many things to narrow down until we find out the actual threat. Let's take an example of one of the uh IM signature or the finding type. Uh this particular signature is meant to do a discovery uh pattern uh checks where it looks for get events or describe events list operations within the cloud account and then whenever there is uh event match that will trigger alerts and if we take a look at

the hits or alerts that it generates in a real setting or real environment there are so many like hundreds of alerts in the last 24 hours and if we narrow down and then uh see what are store user accounts that are generating so many uh accounts mostly we see they are from CSPM user accounts usually CSPM are the cloud security poster management ones right so they are meant to do discovery scans and they are meant to profile the environment and have an inventory so this is subjected to be benign activity in an environment in a large scale so if we expand the same single account concept to a multi- account we tend to see there's so much of noise and because

we operational uh this kind kind of alert within a severity based concept or approach. We see this alert or this finding type as noisy and then we get a request detection teams to exclude this signature because this is beni this is not even actually finding any threats. So because there is so much noise we tend to allow that as well and we kind of create our own gaps within the alert pipeline. This is like uh this is uh one home is happy home and then a single security system works better. But if we expand the same thing to multi accounts, we end up in a situation where uh there is lot of uncertaintity and lot of

noise. All right. So we discussed very fast that uh the current approach is being followed majorly across the industry and there are very less uh organizations that are very advanced. We think that uh doing complex things or more advanced things uh are the ones only to do it but we miss out on doing things very fundamental uh which are basic. Let's move to uh to a new perspective of how it can be done and then it there are multiple ways how you could do it but uh we'll just explore the one that worked for me and then one uh that could work for you as well. uh we'll go to the first step where we

identified there are 180 finding types in the uh Amazon AWS and then we map all of those 180 to uh the resource types like out of 180 there could be 20 for IM 15 for EC2 we categorize all of them and then map it to resource types and then the second part we should be knowing our own infrastructure we should lay out an uh uh learning curve that we understand our market architecture. What are the infrastructure components that are benign like we understood that CSPM user accounts are meant to do discovery scans. Those sort of things are something that we need to gather well beforehand before doing anything. And then we need to also baseline what is

normal in the environment and what is not. And the third step is that we need to bucket all the signatures or the finding types and associate them to each resource type. For example, there are number of finding types. So, EC2, S3 and then IM. So, the second step is bucketing all of these into different categories and then understand each finding type. It's not like okay we have hundreds of signatures and then we have a tendency or we have urgency to onboard the guard duty executives are asking to onboard for the coverage. We do a severity based detections. We end up in a same situation. So, we need to take some time. We need to do assessment of

all the signatures. What are relevant? What are not relevant? And what what does it say? What does it take and then the next step is to categorize an alert grouping. So let's take an example of IM. So let's say there are 20 finding types for IM and then we need to group closely related finding types to form one unique detection. For example, on the left side there are three finding types which is root credential usage, password policy change, console login success. All of these can form one single detection. They are very closely related uh to u policy violation or a compliance thing where we are users are not supposed to do in the production setting but they

are still doing it and and then on the right side or the on the down side there are all the anomalous signatures are combined to form one unique detection. It becomes easier in a production setting where if there is a noise or if there is a benign activity that we need to consider it as baseline and then all list we only do that exclusion to this particular signature and not to the entire alerting system uh like we do for the severity based detections. Uh this is one of the uh Splunk query for the IM detection that we just spoke. you uh include all the finding types and then in this third line we uh we apply this particular

detection only to certain accounts right we are not doing the same alerting for the entire BUS or all the BU that you have you select a certain uh environments or uh BUS and then know their environment their baselining and then you apply that individually we are not going to apply the same thing for every BU so each production environment might have a different uh compliance or uh policies and then the test environment might might not have anything at all. So we need to treat everything differently. Uh and then at the end you can have its own allow list or exclusions where we learn the baseline when we productionize the alert and then have the baselining added to the current

existing detections in in a similar way like how we did for IM. we could expand that assessment towards all the 180 uh different signatures and then form multiple variance alerts. So in in a current setting we only have maybe two or three high critical or high, medium, low but we go from that direction to a more granular alerting system where we have plenty of alerts associated with resource types or combination of uh patterns that we need to identify and detect. So binding it together we learned that what is guard duty and then how many signatures are there and then why we need to understand all of those finding types individually uh learn what it is and then learn our own

infrastructure our own architecture uh do a baselining of what's normal what's not normal and funnel all these signatures or threats that are relevant to your own uh infrastructure uh when you enable guard duty fundamental guard duty enables certain signatures by defa fault but let's say there is EKS or Kubernetes usage uh heavily in your environment you need to enable uh EKS additional advanced protection as well so that is something that you will need to do it on your own it's just a direction that this is the way we have to do it and then you add that to your alert pipeline and then use orchestration to make analyst lives easier. So as an outcome of this

particular new approach, it's not a rocket science. It's very simple thing. It's very fundamental uh perspective that doing this drastically reduces the alert volume but keeping the actual threats intact where we identify uh the real threats and then increased true positive increases the morale of security analyst and reduce false positives obviously leads to uh no alert fatigue. And just to recap or do a summary that we learned that one single security system at home works very well but we expand that to the uh entire street without any uh environmental context or profiling it fails to do its job. And we also learned that uh controlling an ocean or a flood with a single gate might not be very uh bright idea. But

understanding to build a a dam and then have multiple gates to control the flood and then release water as and when required is something that uh is needed and the profiling is something that we need to do for sure. In the same example of that particular street, we profile each individual within the street that who is a neighborhood, who is a resident and who is not. And when we do the profiling and then apply the same security to the street, we end up catching the actual threat no matter how many red colored uh clothing uh people are there within the street and at the end we tend to catch the threat and then uh finally reward

for our own work. All of these images are AI generated. Uh they're not very complex to design. And uh let's move to conclusion. So key takeaways is that it's not very uh complex uh that doing the new approach is uh uh very tight or tough. It's very simple to understand what are the signatures available within the guard duty. What is relevant to our own infrastructure? what are the accounts that are uh production that are dev and then what is the baseline for the environment and apply this particular perspective uh to the uh alerting. Thank

you. I I remember so I think uh this this holds good. The first challenge uh it's very simple. Uh open up your LinkedIn uh apps and then search my profile. The moment you see the next slide uh there is a challenge. We have 1 minute and then uh it goes like this. You see a challenge and then you find out what's the answer and then DM me the uh answer whatever it is. Whoever gives the correct answer first I think that will be the winner of the first one. It's the same thing for the second one as well. So when you're when you're ready, just give me a wave so that I'll I'll move to the next

slide. I mean, this is self-promoting, but it's okay. It requires premium to DM you right now. What's that? I I can't hear. It requires premium to DM you on LinkedIn. Hindi? Oh, is it? Oh, no.

Is it for everyone? Mobile [Laughter] number. Who wants to go first? Uh, write down my mobile number. 99 622 143 20 all good taked Identify one guard duty finding type that is specifically related to Bitcoin and DM or LinkedIn LinkedIn is not relevant anymore yes bitcoin related finding type all right why lakani who's that Perfect. Okay. Okay. Don't don't send any any more uh answers. Let's have second one. Ready? Identify one graduity finding type that is specifically related to pentest. Who is N Gupta? Okay, got it. I think both of you can come down to stage. Can we have some claps for those?

I I don't want to be biased. So come down here and then close your eyes. Pick anyone.

Thank you. Thank you for nice. I think we can have a Q&A if anyone has. Hello. Hello. Uh hi, my name is Prat. So my question is uh so where are you collecting this uh finding types and uh if it is publicly uh is it publicly available or is there or uh is it a closed source completely? It is publicly available. Uh once you go to Amazon Guard Duty doc site, all the finding types are publicly available. Okay. So all are open source. All of those. Yes. Perfect. Thank you. Hello. So how does uh guard duty handle false positive in its threat detection process? What's that? How does guard duty handle false positives in its threat detection

process? False positives. Yeah. Okay. So, uh when we ask false positive, is it the finding type itself is not actually detecting right or it's not relevant as a threat in your environment? Not relevant. Not relevant. Yeah. So if it's not relevant that's something that we need to feed back or give proper feedback to the guard duty where they'll fine tune the signature. If it's something that that is false positive due to the nature of benigness within your environment that is something we need to work within environment.