A hard look at AWS GuardDuty shortcomings(tracebit.com) |
A hard look at AWS GuardDuty shortcomings(tracebit.com) |
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").
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
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.
GuardDuty does what AWS says it will do. This article moves the goal posts in order to judge it as inadequate.
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!
nb: I'm the author, in case it's non-obvious!
This isn't true and the link to the source is a 404 page. It was already too much content marketing, no need to read beyond that line.
It's definitely a bit of a simplification - although I'm not aware of large orgs using anything else to meet the relevant PCI requirement
The whitepaper AWS commissioned helping explain GuardDuty to auditors[1] is definitely a large component there
[1] https://d1.awsstatic.com/certifications/foregenix_amazon_gua...
Took a while to figure that one out, not least of which because ECS has absurdly shitty UX, with little to no observability.
1. yes, ALL AWS security products have hilariously bad performance and shortcomings, and aren't fit for purpose.
2. this article is too short and doesn't do it justice, and 1/8th of it is dedicated to pitching their alternative (canary infra)
3. Tracebit, the company, doesn't do a good job for pitching canary infra.
conclusion: yeah, seems on brand for Tracebit. This is what I'll remember about your company. half built, accusing AWS of being half built.