Delegating security remediation to employees via Slack

I’m noticing a new trend with security workflows in Slack: instead of relying solely on the security team to pass on a message or take an action to remediate an issue, another team is asked to and able to do so directly. This is shifting left, like in DevSecOps, but rather than meeting developers in their dev tools, we’re meeting employees in Slack.

SlackOps (or ChatOps) was pioneered by DevOps teams to take actions directly in Slack, not just receive notifications — to run commands to scale up your infrastructure, monitor the progress of a rollout, or even start a rollback in case of an incident. What I’m seeing in security is not only these operational actions, but also using Slack to help speed up the human interactions you might need as part of triage or remediation.

We can broadly categorize security interactions in Slack into four categories.

First off, we have security reminders. These are notifications to employees that security wants them to do something, that is, check a box. These reminders are asking your employees to complete security-critical tasks like taking a security awareness training, acknowledging a policy, or reviewing existing permissions.

Next, we have plain old alerts. These are notifications to the security team that something might be amiss, usually from a scanning or monitoring tool, like an open firewall port or a new user being added. These notifications come from anything that sends events to a webhook. Most security tools which do some kind of scanning and tell you, “hey, I found this” fall into this category, including Snyk, HackerOne, Truffle, Semgrep, and many more. They turn Slack into an inbox for the security team to triage issues.

With the advent of SlackOps, there’s a shift from just notifications to actions, allowing us to complete workflows in Slack.

For security, that’s a workflow for responding to an alert or another team’s request — “hey, security, can you review this product before launch? can I get access to that tool?” These effectively turn Slack into a ticketing system (but a ticketing system with memes), and lets the security team take action via Slackbots. In response to an alert of a suspicious login attempt, I might take an action like lock an account. PagerDuty lets you acknowledge an incident, assign a responder, run an incident response workflow, and even escalate — all without needing to leave Slack. Opal lets you approve an access request. And Tines lets you extend some of your existing security alerts to automatically take action, so that even if your tools are disparate and don’t come with native Slackbots, you can string them together to take action like block a domain based on threat intel about the URL. Organizations are also building Slackbots for their own internal workflows, like OpenAI’s bots for incident response, reviews, and triage.

Lastly, using Slack to delegate security alerts — this is the new trend I’m seeing. Rather than a security tool alerting the security team (in Slack), who then needs to find the right person to ping (also in Slack) — what if the tool just short circuited that and went right to the source (in Slack, of course). This is a change in who is alerted first. Rather than alerting Alice in security that Bob shared a Google doc with an external party, instead alert Bob and ask if he meant to share the doc — if he didn’t, then alert Alice. This applies to any situation where security needs to check: “did you mean to do that?” (This isn’t quite DevSecOps, and it’s not quite SlackOps, so maybe it’s SlackSecOps? I’m sorry.)

Kolide (now part of 1Password) seems to have popularized this first, notifying users in Slack that their devices don’t have disk encryption, have unencrypted SSH keys or account recovery passwords sitting around, and other failing osquery checks. And now, Nudge reaches out to SaaS app users to ask them to enable MFA, or confirm if they still need the account.

I think this is a huge opportunity to distribute security responsibility, and Kolide and Nudge really hit on something. There are many places this kind of workflow could be useful in security, where some enrichment or remediation action needs to take place, and the resource has a clear owner. The resource could be a device (Kolide), SaaS app (Nudge), file, database, …anything really. You could also do this with dev resources like VMs, containers, services, and GitHub repo, where you don’t otherwise have a natural place to provide an alert. (I’m not proposing duplicating alerts that already exist elsewhere, but rather replacing alerts that were previously manual). Where you have a defined policy, you can also propose a desired action to take rather than escalating the issue — to some extent, this is automating the first round of triage for exception management.

You could ask employees: Did you mean to share that Google doc with an external person? Do you still need that test instance that’s not getting traffic and you haven’t touched in a month? Did you mean to invite a contractor to use that app?

I understand why these types of workflows are emerging: security teams are spread very thin, and could always have more context on the business’ needs. Delegating these security alerts is removing the step of a human reaching out in Slack (no dreaded “hello”). Instead, the security team gets to spend more time on the exceptions that remain.