A few weeks ago, I had an old friend ask about making graphing, commenting on and bulk loading indicators to feeds, from Slack. I've touched on some of these- but the questions do highlight how operators think about threat intel and how they'd like to interact with it. I'll be the first to admit, i'm terrible at things like threat intel viz. This is probably the biggest reason you don't see a lot of that in the various CSIRTG frameworks.
That's a good thing though, the less time spent on viz, the more time spent on things like APIs and integrations. If you think about it, that means it's trivial to integrate things like CIF and CSIRTG into your everyday workflow. One less "Yet Another Console" to log into on a regular basis to get at your data. API first means a steeper learning curve, but a more frictionless experience in the long run. I'm happy to leave the art of the console to the professionals.
If you think about it- how many tools have you come across where the user experience was nice [and shiny] at first. However, the moment you try to automate anything, you discover their API was clearly as an afterthought? Written by a programmer who doesn't have good solid security operations experience. I know consoles help communicate to non-technical folks the power of a platform, but at the same time- why is scale such an afterthought?
The tricky thing here- is both enabling a frictionless experience (eg: automatically adding the right indicators from Slack) while weeding out things that clearly shouldn't go into a feed. To help work-through this, i've added a few new settings in CSIRTG to give you more control over this. If you leave these blank, you'll still need to "+1" the Slack bot responses to get them into a feed. If you tick the box, when the Slack bot predicts something which it thinks is highly accurate, it'll automatically shove that into a feed for you.
Interactions
Slack has recently introduced the concept of diologs to the their platform which almost seems like a perfect fit for platforms like CSIRTG. I imagine at some point in the future you'll start seeing some of that functionality built in. The challenge is striking the balance between flexibility and a frictionless experience. The goal here shouldn't be "a human has to manipulate the feed", rather, with a few hints, 90% of the time the bot does the right thing.
Most platforms that focus on the UX tend to create features around the human interactions rather than automation. The problem with this, over time all those features add up and create a massively complicated experience. At each UX decision point you should ask, 'how do I enable that to be automated 90% of the time?'. When you do this, you end up with a different set of answers to the problem.
It's a bit harder in the beginning, especially since it's trivial to add "Yet Another Dialog Box" and solve an immediate problem. In the long run, those small 'frictionless improvements' scale your solution to other tools built on your API. Future users now get to enjoy the investments you've made in your platform in their native toolsets. They don't don't have to re-learn your UX and UX decisions because the features they need are both automated and baked into your API.
Yes, while this bulk indicator prediction and loading is somewhat baked into a Slack integration, the pattern that the API uses behind the scenes is pretty generic. It can be abstracted a bit to work with just about any other type of communications client (Email, Skype, … Alexa?). I don't care what endpoint application you're comfortable with, I just want you to have a frictionless experience when it comes to working indicators, feeds and predictions.
