Deploying Threat Intel with Slack

Getting a Slackbot to enhance your threat hunting is easy, but I still have to copy / paste the results into an IDS. The point of a good a platform is being where I am and better yet, anticipating what I want to do next. We used to copy paste indicators from email, IRC, slack .. my logs and build IDS rules by hand. OH WAIT, WE STILL DO THAT! All this "predictive intelligence analytics" garbage and most operators are still building IDS feeds, manually.

Remember when I stated CSIRTG is a platform? Platforms are powerful because you can build on top of them, in both directions. Obviously you can use them to search, the more powerful platforms will enable you to take the value you created and feed it right back in. This means, if you bring information into Slack from various sources, make something of it, the next logical step is taking that value and turning it back around quickly into your IDS, through CSIRTG. By simply reacting to a bot response with a "+1", the indicator will show up in your "slack" feed (if you've created that feed, go do this NOW!).

If you've already installed the CSIRTG Slack App, you'll need to re-install it. These newer features do require us to have a few more of those "creepy" message and reaction based read permissions. We have to be able to observe when you react with a "+1" (thumbs up) to something. We do our best internally to immediately throw away anything without an obvious indicator in it, as well as REDACT any non-meta data (eg: raw text, only channel / team_ids used for debugging, which has to be on) in our logs. In future versions we're working on a feature that'll enable you to limit what [public] channels the bot pays attention to too.

Zero Friction

The next logical question, if the bot comes back with a threat score of 84% or higher, shouldn't that just go right into a feed? YES! NOW YOU'RE COOKING WITH FIRE! Now that I think about it, that kind of feels like a paid feature (gotta keep the lights on somehow ;)). Getting the end to end solution implemented as fast as possible is the first step. This gives you insight as to how (and more importantly IF) the feature will be used.

We solved the problem of getting data out of Slack and into CSIRTG. The next set of steps is in tying together those human to human threat intel threads with those of your other bots (or apps). If those require changes, those changes can be deployed rather quickly now since the heavy lifting is done. CSIRTG obviously not the only app in your toolbox, but it's your last mile and we want to make that as frictionless as possible.

It's a Team Sport

Your team is the center of your Threat Hunting operation, you use many different tools whose intersection IS YOU. There are some places where these tools need to talk to each-other automatically and those should be pretty obvious. However, there are intersections where that's not always clear, rather than forcing those to be manual [copy, paste, click..], we need to find the most obvious ways of reducing that friction, Slack or otherwise.

Very quickly you start seeing the global threat intel problem, not from a set of dashboards, but from the results of a team conversation. Your team uncovered an indicator from a malware sandbox run, which dumped some of the IOCs into an #ops channel. A member of your teach reacted to them with a "+1" and the CSIRTG app fed that data right into your IDS. Your IDS sensor detected a hit on the indicator, dumped the alert back into your #ops channel. Another member of your firewall team reacted to the event with a "+1" which cut an incident notification (or ticket) to the help desk.

Sometimes isolated consoles are useful and less distracting than #ops channels, but they also create friction in the process. Threat Hunting is a team sport, sometimes you need to strike a balance between the two.

Did you learn something new?