[xyzzy123]

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.

[drodgers]

I couldn't have said it better myself.

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").