Skip to content
Notifications
Clear all

Anyone else getting flooded with 'suspicious behavior' on DevOps engineering machines?

1 Posts
1 Users
0 Reactions
35 Views
(@sre_mom)
Eminent Member
Joined: 5 months ago
Posts: 18
Topic starter   [#367]

Hello everyone. I've been seeing a pattern emerge across our DevOps and platform engineering teams over the last few months, and I'm curious if others are experiencing the same. Our SentinelOne agent is generating a significant volume of "Suspicious Behavior" alerts, primarily on our CI/CD runners, build servers, and developer workstations where engineers run automation scripts.

The alerts themselves aren't false positives in the traditional sense—the agent is correctly identifying anomalous behavior against its model. However, the behaviors are overwhelmingly legitimate DevOps activities. We're talking about alerts triggered by:

* **Processes spawned by package managers** (e.g., `pip`, `npm`, `go build`) downloading and executing artifacts.
* **Terraform/Ansible/Pulumi** creating temporary files and executing providers or modules.
* **Custom in-house tooling** that performs code generation or orchestration, often using interpreters like Python or PowerShell.
* **Container build processes** (`docker build`, `kaniko`) where a lot of shell activity and file creation happens in quick succession.

The sheer volume is creating alert fatigue for our security analysts and adding noise to our central dashboard. More critically, it's causing a "cry wolf" scenario where real threats might be buried.

We've started to adapt by creating exclusions, but it's a careful balancing act. We don't want to disable the protection. Our current approach involves building a more detailed allow-list based on process, script path, and even signed certificates where possible. For example, we added an exclusion for our trusted internal code-signing certificate, which helped reduce alerts on our signed orchestration tools.

Here's a sanitized snippet of the type of policy rule we've been implementing, focusing on a specific, trusted directory for our automation:

```json
{
"type": "exclusion",
"title": "Trusted Automation Directory",
"scope": "global",
"paths": [
"/opt/company-automation/**"
],
"processes": [
"python3.9",
"bash"
],
"description": "Exclude alerts from our signed, internal automation framework running from its dedicated directory."
}
```

Has anyone else navigated this? I'm particularly interested in:
* How you've structured your exclusions to remain secure while reducing noise.
* Whether you've engaged with SentinelOne support for tuned behavioral models for developer/DevOps workloads.
* If you've integrated these alerts into your observability stack (e.g., Splunk, Datadog) to correlate them with deployment events, creating a richer context for triage.

I believe this is a common challenge as EDR platforms mature in engineering environments. Sharing our runbooks and postmortems on these operational issues would benefit everyone.


pagerduty certified lifer


   
Quote