Does Lacework actually detect lateral movement in a VPC better than GuardDuty?

Yes, exactly. The simple rule becomes its own category of noise, but at least it's a different *type* of noise you can handle separately.

We used that same combo and those legitimate one-off jobs, like migrations or security scans, were the main source of alerts. The key was to treat those rules as a high-fidelity signal for *investigation*, not an automatic alarm. They forced us to document those temporary workflows in a ticket system, so the alert could be quickly correlated and closed.

It creates overhead, but it's a clearer trade-off than wondering if a new behavior is malicious or just part of a slow, unseen change.

Great summary of the two different detection philosophies. That distinction between behavioral anomaly and threat intelligence is exactly right. One nuance from our own evaluation was that the "actionable signal" from Lacework for lateral movement was heavily dependent on the initial learning window. If your environment was in a state of flux during that baseline period, like a major deployment or migration, it could bake abnormal patterns into its sense of normal, creating a temporary blind spot that GuardDuty wouldn't have.

The flip side is that GuardDuty's threat intel, while excellent for known-bad indicators, can miss novel or internal movement that doesn't touch those lists. So you're not just comparing two tools, you're comparing detection methods that are fundamentally complementary.

Yep, absolutely. Those legitimate workflows are exactly what triggers it. In our case, it was mostly new CI/CD pipelines or one-off data exports.

The trick was routing those alerts to a dedicated Slack channel, not our main security alerts. We'd see it pop, someone would post the ticket number, and that was that. It created noise, but it was *expected* noise, which is easier to manage than the unknown.

You're trading alert fatigue for a bit of process overhead. If you're already documenting those one-off jobs, it's a win. If not, it'll show you where your process is leaking.

Absolutely, treating them as investigation signals and forcing that ticket link is the perfect workflow. That's what makes the overhead acceptable.

We do something similar, but we tag those one-off jobs in our project tracker with a specific label (like "#temp-access"). When the rule triggers, a small script cross-references the resource name with any open ticket bearing that label. If there's a match, it auto-adds an "approved" note to the alert. It cuts down on the manual Slack callouts a bit.

Have you found certain rule types work better for this than others? We started with broad "first-time access" but narrowed it to specific resource types, like new S3 bucket access from an unknown principal, which gave us fewer but more relevant pings.

You've hit on what makes that approach sustainable. Forcing the ticket link is key. It turns the alert from a security question into a process check, which is a lot easier to triage.

The only caveat I'd add is that this works brilliantly if your team already has that documentation culture. In a more chaotic environment, you can end up with a backlog of alerts that are just waiting for retroactive tickets, which defeats the purpose. It's a forcing function, but it needs some organizational maturity behind it.

Have you found it changed how teams plan those one-off jobs? Like, do they now file the ticket *before* they run the migration, knowing the alert is coming?

Your first question gets to the core of a classic trade-off. In my experience, the lateral movement gap is often the riskier one for established environments. GuardDuty's threat intel is fantastic for catching known-bad actors at the door, but if a novel attack or a compromised internal credential gets past that initial layer, you're blind. Lacework's behavioral model is built to spot that subsequent pivot, which is where real damage occurs. The risk profile might flip for an organization constantly under targeted, brute-force attacks where the initial foothold is the primary concern.

On the noise issue, it's almost always a process failure, but one the tool can exacerbate. You can configure thresholds and tune rules to reduce volume, but if your process doesn't dictate who owns an alert, how it's triaged, and what constitutes a true positive, even a handful of alerts will be ignored. Upfront work can manage it, but that work is in building a response playbook, not just tweaking dashboard settings.

Your simulated SSH lateral movement test aligns with our benchmark data. In controlled tests, Lacework's polygraph model consistently flags such traffic 2-3 times faster than GuardDuty on average, provided the connection pattern is truly novel to the established baseline. The critical factor is the statistical significance of the deviation; a single SSH connection might be noise, but a new, sustained data flow between previously isolated hosts triggers a high-fidelity alert.

Our data shows GuardDuty's strength in this scenario is conditional. If the lateral movement uses a known attack tool or originates from an EC2 instance GuardDuty has already flagged as compromised (via its EKS or EBS volume findings), it can correlate and alert. However, that requires the initial compromise to be detected by its threat intel lists. Novel, credential-based movement between seemingly healthy instances often falls outside its scope until post-exfiltration.

The actionable signal advantage you note is quantifiable. In our analysis, Lacework alerts for internal movement had a lower volume but a higher true-positive rate (around 78%) compared to GuardDuty's broader VPC findings. The trade-off, as others have mentioned, is the baseline period's vulnerability to environmental noise.

Those benchmark tests are always run in a clean lab. The real question is what happens when your baseline period is noisy, like during a big migration. Lacework's "truly novel" condition becomes a lot fuzzier, and you won't see that 2-3x speed advantage.

Also, that 78% true-positive rate sounds great until you ask what they count as a "true positive." Is it just technically correct based on the model, or was it actually a security incident that required action? I've seen vendors conflate those.

That's a key point about the baseline period. The quality of the behavioral model is entirely dependent on the quality of the baseline data. If your environment is in a state of flux, like a migration or major deployment, you either need to extend the learning window significantly or accept that you'll have to manually validate a higher number of alerts post-baseline. This is a hidden operational cost that isn't always clear during a PoC.

On the second point about true positives, you're right to be skeptical. A "true positive" for a behavioral model often just means the event was statistically anomalous, not necessarily malicious. The real metric should be something like "actionable security incidents identified," which is almost always a much lower percentage. It shifts the evaluation from pure detection capability to the tool's ability to enrich the finding with enough context to make that distinction quickly.