In Lacework's security model, "violations" and "anomalies" represent two distinct classes of alerts, and understanding the difference is crucial for prioritizing your SOC workflow. At a high level, a violation is a breach of a defined rule, while an anomaly is a deviation from a learned baseline.
A **violation** is a straightforward policy failure. It's triggered when a resource or activity explicitly contravenes a rule you've configured (or that Lacework provides out-of-the-box). These are binary, deterministic events.
* Example: A cloud storage bucket is set to public-read. The rule "LW_S3_1" (which checks for world-readable S3 buckets) is violated.
* Example: A new user is added to the built-in administrators group. This matches a known policy for privilege escalation.
An **anomaly**, however, is based on behavioral profiling. Lacework uses machine learning to establish a baseline of "normal" activity for your environment over a learning period (typically 14 days). When an event statistically deviates from this baseline, it's flagged as an anomaly.
* Example: A process that normally only runs during business hours suddenly executes at 3 AM.
* Example: A user account that typically only accesses systems from the US suddenly initiates a session from a new country.
The key distinction is in their predictability:
* Violations are about **compliance** and **explicit rules**. You can audit for them.
* Anomalies are about **unexpected behavior** and **implicit threats**. You discover them.
In practice, your alert dashboard will categorize them separately. Violations often map directly to compliance frameworks (CIS, SOC2). Anomalies require more investigation, as they could be a sign of a novel attack or simply a new, legitimate pattern Lacework hasn't learned yet. Tuning your environment involves converting frequent, benign anomalies into allowed behaviors (updating the baseline) and codifying critical violations into enforceable policies.
benchmark or bust
benchmark or bust
Spot on. That learned baseline for anomalies is the real magic, but it's also why they can be noisy until the system really understands your patterns. We saw a ton of anomalies in the first few weeks after rolling it out, like "unusual outbound traffic volume" from our CI nodes on release days. It wasn't bad, just new. Took the system a bit to learn our deployment cadence.
Makes prioritization so much easier once it settles. Violations get paged immediately, anomalies go to a lower-priority dashboard for us to review during business hours. Saves the on-call from alert fatigue.
K8s enthusiast
That's a really good point about the initial noise. It's a common implementation hurdle people don't always anticipate.
Your example of CI traffic is perfect. We've seen teams get frustrated and tune out those alerts too aggressively in the early phase, which defeats the purpose. The patience during that learning period is key. It's also a good reminder to document your normal "burst" activities for the team, so when an anomaly pops up for a known event like a release, you can contextualize it faster.
Keep it constructive.
Ok, that makes sense! So a violation is like failing a checklist, and an anomaly is "this Tuesday feels weird".
Can you give a simple terraform example for a common violation? Like an S3 bucket policy that would definitely trigger one? I'm trying to connect the theory to something I'd actually see in my AWS account.
> "this Tuesday feels weird"
That's exactly it. Simple but correct.
For your Terraform example, this bucket would trigger a violation every single time. It's a guaranteed checklist fail.
```hcl
resource "aws_s3_bucket" "example" {
bucket = "my-public-data-bucket"
}
resource "aws_s3_bucket_acl" "example" {
bucket = aws_s3_bucket.example.id
acl = "public-read"
}
```
The `acl = "public-read"` violates the standard CSPM rule about world-readable buckets. No learning period needed, it just fires.
But a word of caution from my own tests: don't trust that a clean Terraform plan means no violations. If someone manually tweaks the bucket policy in the console after creation, Lacework will still flag it as a violation. The rule checks the live state, not your IaC.
-- bb
Yeah, "this Tuesday feels weird" is a great way to put it.
Your Terraform ask has been covered, but I'll add a caveat from procurement: don't assume all violations are priced equally. In a negotiation, vendors often highlight violations as the core value metric. But the real operational cost is in investigating anomalies. That's where the "unknown unknown" time-sink lives. Violations are fast to fix; deciding if an anomaly is actually dangerous is the slower, more expensive part for your team.
>Violations get paged immediately
That's a quick way to burn out your on-call. We learned this the hard way.
We set our S3 bucket violations to low-priority dashboard review for a month. 80% were intentional public buckets for static sites or logs. Paging on every violation meant waking someone up for approved architecture.
The real priority isn't violation vs anomaly. It's "can this cause damage in the next 30 minutes?" A weird process anomaly on a bastion host gets paged. A public-read bucket holding our public marketing PDFs does not.
show the math