It doesn't particularly matter because, like WAF, Guard Duty is for customers who need to tick a particular box with absolutely minimum effort and hassle.
It just needs to plausibly allow you to state to your auditor that "all hosts have anti-malware protection". Auditors almost always look at this closely. It's like TLS settings (who ever got hacked coz they were on TLS 1.1 and not 1.2???) - one of the brown M&Ms clauses of audits.
The alternatives are generally worse for reasons such as a) they interfere with your kernel b) have a console you have to deploy somewhere and requires babysitting c) they introduce their own attack surface on hosts d) they are not particularly effective in any case, etc etc (I have a long litany of complaints about this class of security product which probably doesn't need to be repeated here).
The control plane monitoring is "just OK" (as usual for an AWS add-on service), you can't customise it, you can't define your own rules, you just plumb it to monitoring and that's it.
Which is optimal if you barely care but have to do something. There is generally no hard requirement for effective control plane monitoring because it's too nuanced for auditors to verify.
The actual product could be much better, but I actually think AWS is perfectly placed to run network and host intrusion detection; they can hook into the hardware when needed, they can instrument all the routers and switches, they can correlate patterns across many clients, all while not opening up the monitored systems to a third party over the internet.
> they introduce their own attack surface on hosts
I think this is a hugely underrated problem. Installing a kernel module with an internet-connected control plane is not a great way to improve security (especially when that control plane is run by a third party who might — hypothetically — push code updates through a server which accepts the password "solarwinds123").
I don't know any big organizations that solely rely on GuardDuty. IMO, GuardDuty is great for a smaller company that wants something and doesn't want to have to buy/onboard/maintain a vendor.
There's at least one thing that GuardDuty does that is much more difficult to do without it: the detection of instance credential usage from outside the account/VPC. I'm sure there's a way to do this with cloudtrail logs but it's not straight forward.
My biggest problem with GuardDuty is that it's all or nothing (for the most part). We'd love to have the cloudtrail/DNS/ML monitoring but disable flow logs, which are by far the most expensive part of GD for large orgs. AWS refuses to give us that option. And if they're going to charge us a fortune for flow logs with GD at least let us download or view them.
I also find the DNS based cryptomining detections pretty handy, and high enough signal.
Great point on VPC Flow Logs! With the move to SKU off various GuardDuty features (S3 protection, Runtime, etc.) ... it'd be nice if GuardDuty monitoring of VPC Flow logs were more configurable
That's definitely aligned with what we see, we work with orgs where we're the next step after Guard Duty and some who already have more in place.
Certainly for the base usage, switching GuardDuty on can be a no brainer, as we touch on in the article - it's the additional SKUs where things a get a bit less clear.
What do you view as AWS' commitments around GuardDuty? I see pretty clear positioning by AWS of GuardDuty as a one-and-done solution for threat detection.
Top level marketing claims include:
* "Protect against ransomware and other types of malware" - which is why I looked at how viable GuardDuty would be against the most common form of S3 "ransomware"
* "Detect suspicious activity in your generative AI workloads" - but they don't actually have coverage of the vast majority of GenAI Services
* "Continuous monitoring across AWS accounts and workloads without added cost" - except the service is expensive (if worthwhile for the foundational data sources!) and has unpredictable costs
> competing product/service
I see canary infrastructure as complimentary to Guardduty (w/ foundational data sources) - which is explicitly stated in the piece!
That doesn’t mean that they’re saying Guard Duty is required but rather that it’s one way to satisfy that need. If you picked a different product, you could disable that control in Security Hub.
Guarduty's biggest shortcoming is how expensive it is.... Otherwise I know of no other solution that will deliver so much AWS security monitoring value with such little effort to enable.
My only experience with GuardDuty was when Security unilaterally rolled it out, and it promptly began eating CPU in ECS containers. Unfortunately, this included PgBouncer, and their throughput plummeted.
Took a while to figure that one out, not least of which because ECS has absurdly shitty UX, with little to no observability.
It just needs to plausibly allow you to state to your auditor that "all hosts have anti-malware protection". Auditors almost always look at this closely. It's like TLS settings (who ever got hacked coz they were on TLS 1.1 and not 1.2???) - one of the brown M&Ms clauses of audits.
The alternatives are generally worse for reasons such as a) they interfere with your kernel b) have a console you have to deploy somewhere and requires babysitting c) they introduce their own attack surface on hosts d) they are not particularly effective in any case, etc etc (I have a long litany of complaints about this class of security product which probably doesn't need to be repeated here).
The control plane monitoring is "just OK" (as usual for an AWS add-on service), you can't customise it, you can't define your own rules, you just plumb it to monitoring and that's it.
Which is optimal if you barely care but have to do something. There is generally no hard requirement for effective control plane monitoring because it's too nuanced for auditors to verify.