[HN Gopher] A hard look at AWS GuardDuty shortcomings
       ___________________________________________________________________
        
       A hard look at AWS GuardDuty shortcomings
        
       Author : tracebit
       Score  : 54 points
       Date   : 2024-07-16 10:49 UTC (12 hours ago)
        
 (HTM) web link (tracebit.com)
 (TXT) w3m dump (tracebit.com)
        
       | travismcpeak wrote:
       | 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.
        
         | tracebit wrote:
         | 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.
        
         | bink wrote:
         | 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.
        
           | ramimac wrote:
           | Agreed - I find the credential exfil alerts meaningful. I
           | appreciate that AWS has invested in making them better in
           | recent years (bypass details in
           | https://hackingthe.cloud/aws/avoiding-detection/steal-
           | keys-u...)!
           | 
           | 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
        
       | pluto_modadic wrote:
       | 3 points:
       | 
       | 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.
        
       | ezekiel68 wrote:
       | Thinly veiled advertisement for a competing product/service.
       | 
       | GuardDuty does what AWS says it will do. This article moves the
       | goal posts in order to judge it as inadequate.
        
         | ktbwrestler wrote:
         | to be fair, Rami did specify that this was just outlining the
         | shortcomings, and IMO, is not just trying to sell something
         | here
        
         | ramimac wrote:
         | > GuardDuty does what AWS says it will do
         | 
         | 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!
        
       | arpinum wrote:
       | > GuardDuty's role as a required control for PCI DSS and
       | NIST.800-53.r5
       | 
       | 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.
        
         | ramimac wrote:
         | Not sure how the link got munged, but the root is
         | https://docs.aws.amazon.com/securityhub/latest/userguide/gua...
         | 
         | 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...
        
           | acdha wrote:
           | 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.
        
       | Narkov wrote:
       | Advertisement.
        
       | xyzzy123 wrote:
       | 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.
        
       | sgarland wrote:
       | 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.
        
       ___________________________________________________________________
       (page generated 2024-07-16 23:01 UTC)