Skip to content
Notifications
Clear all

Made a simple connector to push high-severity items to Slack.

3 Posts
3 Users
0 Reactions
1 Views
(@devops_dad_v2)
Estimable Member
Joined: 4 months ago
Posts: 122
Topic starter   [#3980]

We've been using CrowdStrike Falcon for a while, and while the console is great, our on-call engineers needed faster, more contextual alerts for critical items—things that need immediate human review. The default email notifications were getting lost.

I built a lightweight connector using Falcon's APIs and a small Go service. It filters for high-severity detections (`severity >= 80`) and pushes a formatted, actionable message to a dedicated Slack channel. This gives the team immediate visibility without console-juggling.

Here's the core logic of the filter and the Slack message construction. It runs in a simple Kubernetes pod, triggered by a cron schedule to poll the API.

```go
// Simplified filter logic
func filterHighSeverity(detections []Detection) []Detection {
var highSeverity []Detection
for _, d := range detections {
if d.Severity >= 80 && d.Status == "new" {
highSeverity = append(highSeverity, d)
}
}
return highSeverity
}

// Slack block builder (using Slack's Block Kit)
func buildSlackBlock(d Detection) slack.Block {
fields := []*slack.TextBlockObject{
{Type: "mrkdwn", Text: fmt.Sprintf("*Host:*n%s", d.Hostname)},
{Type: "mrkdwn", Text: fmt.Sprintf("*Severity:*n%d", d.Severity)},
{Type: "mrkdwn", Text: fmt.Sprintf("*Technique:*n%s", d.Technique)},
}
return slack.NewSectionBlock(nil, fields, nil)
}
```

Key design choices:
* **Stateless:** The service queries for `new` detections only, relying on Falcon's API filters. State management is left to CrowdStrike.
* **Idempotent:** Runs every 5 minutes; duplicate alerts are de-duplicated by the detection ID within Slack's own system.
* **Minimal IAM:** The service uses a principle with read-only access to detections, following least privilege.

The result has cut our mean time to acknowledge (MTTA) for critical detections significantly. The main pitfall to watch is API rate limiting—implementing exponential backoff and respecting the `X-RateLimit-Reset` header is crucial. For teams already in Slack, this simple bridge creates a much tighter feedback loop.



   
Quote
 amyt
(@amyt)
Estimable Member
Joined: 1 week ago
Posts: 77
 

This is such a great move. That "console-juggling" you mentioned is a real productivity killer for on-call. We did something similar for Salesforce critical error alerts, and the speed-up in response time was huge.

Have you thought about adding a direct link back to the Falcon detection in the Slack message? We found adding a single clickable button that opens the exact item in our dashboard cut down the "context switch" time even more. It makes Slack the notification hub, not just another alert inbox.

Love that you're using the severity >= 80 filter. Smart to bake in the `d.Status == "new"` check too, keeps the channel from getting noisy with repeats.



   
ReplyQuote
(@devops_barbarian_v3)
Reputable Member
Joined: 3 months ago
Posts: 132
 

Good call on the `d.Status == "new"` check. That saved us from a notification storm during a major incident replay.

You polling with a cron pod? I'd slap that into a proper deployment and add liveness/readiness probes. Makes it survive node evictions. Also, consider a backoff if the Falcon API starts throttling you.



   
ReplyQuote