SOCless: Security ChatOps
Slack is a place where people communicate, make decisions, and work on operational tasks. That makes it a natural interface for security workflows too.
But there is an important distinction between sending security alerts to Slack and using Slack to perform security operations.
The first one is just notification.
The second is ChatOps.
At inDrive, I build Slack-based security workflows around a simple idea: if a security alert requires context from a user, why should a security analyst be the one to investigate it first?
For example, imagine a detection for a suspicious login.
The traditional approach is straightforward:
Suspicious login → SOC → investigate → identify owner → contact owner → wait
A SOCless approach asks whether the alert can instead be routed directly to the person or team that has the relevant context.
Security Bot
We detected a login to your account from Limassol. Was this you?
If the user confirms the activity, the workflow may be able to close or downgrade the event without involving the security team, depending on the detection and its risk.
If the user denies it, the event can be escalated with that additional context already attached.
This is the foundation of SOCless built by Twilio Security Operations team.
From alerts to interactions
Security operations traditionally rely heavily on centralized analysis.
A security tool detects something, the security team receives it, and an analyst determines what happened and whether action is required.
But many alerts contain a question that the security team cannot answer from technical data alone:
"Did you mean to do that?"
A security analyst can investigate the surrounding activity, but the person who performed the action may be able to answer that question immediately.
This creates an opportunity to move part of the investigation to the person who has the context.
Slack makes this particularly practical because the interaction can happen where employees already work.
Instead of:
we can have:
The security team is still involved, but only when the event requires security expertise.
This is where SOCless comes in
The goal is to remove unnecessary centralized SOC triage by moving appropriate decisions to system owners, automating predictable responses, and having security engineers build and own the detection and response capabilities.
A large portion of security triage consists of establishing context:
- Did the user actually perform this action?
- Was this deployment expected?
- Does this person still need this access?
- Is this cloud resource intentionally public?
- Did the developer create this API key?
- Was this OAuth application intentionally authorized?
These questions are often better answered by the owner of the account, application, device, or resource.
So instead of making the SOC responsible for answering every question, we can distribute some of that work.
The SOC defines the detection, the policy and the response.
The owner provides the context.
Automation handles the predictable parts.
Slack is the interface connecting them.
Some practical examples
The pattern works for much more than suspicious logins.
External file sharing
A DLP system detects that an employee shared a sensitive document externally.
Instead of immediately creating an alert:
Security Bot
You shared financial-results.xlsx with an external user. Did you intend to do this?
"No" could trigger removal of the external permission and escalate the event to security.
New OAuth application
A user authorizes a new application to access their corporate account.
Slack can ask:
Security Bot
You authorized ExampleApp to access your account. Did you authorize this?
If the answer is no, the workflow can revoke the authorization and notify security.
New production API key
A new API key is created for a production service.
The service owner receives:
Security Bot
A new API key was created for payments-api. Was this expected?
A confirmation closes the event. An unexpected response can trigger key revocation and an investigation.
Key requirements
For security interactions to become part of an automated workflow, several things need to work well.
- Mature detections — the team should understand what the signal means and what constitutes a meaningful event.
- Defined response plans — there should be a clear understanding of who should respond and what actions should be taken.
- Good ownership data — if you don't know who owns an application, device, repository or cloud resource, you cannot delegate the investigation.
- Reliable APIs — security tools need to expose APIs so the workflow can retrieve context and perform actions.
- Strong authentication and authorization — especially for workflows that allow users to approve, deny, or trigger security actions.
- Auditing — every decision and automated action should be recorded for accountability and investigation.
- Someone should own the detection - If an engineer writes a detection, there should be a clear owner for its quality, response plan and operational health. Otherwise, decentralized alerting can simply move the burden around without actually reducing it.
Automating a noisy detection will only create a more efficient way of annoying people.
The opportunity for security teams
The value of this approach isn't simply reducing the number of alerts reaching the SOC.
It is about changing who handles security decisions and where that work happens.
Security teams don't need to own every step of every investigation. When the right context already exists with a user, system owner, or another team, the workflow can take the question directly to them.
The security team defines the detection, the policy and the response. The owner provides the context. Automation handles the predictable parts.
Sometimes the most effective security workflow is simply to ask the right person the right question at the right time and let the workflow take care of what happens next.
That is the opportunity I see in SOCless: moving routine security operations away from centralized triage and closer to the people and systems that have the context to make the decision.