Blog

ProjectBlog: Alexa, play my DFIR playlist

Blog: Alexa, play my DFIR playlist


Lately I’ve been spending a lot of time re-thinking my approach to one of my favourite areas of Cyber, and in fact, all of IT Systems. A really common saying you’ll find amongst not just sysadmins, but software developers and general IT crowds is “if I have to do anything more than twice, I’ll automate it,” and I’m one of those people who has tried to live by this principle.

One of my favourite roles was channelling this energy straight into an emerging market I think has a lot of potential, automating Cyber defence. Platforms like Demisto, or the recently acquired Phantom Cyber, are really good at this, allowing you to write python based “Playbooks” that will execute when a certain event happens, reducing loads on analysts and streamlining DFIR processes. But at the risk of sounding ungrateful, that is all they do. When a very specific event happens, a very specific logic flow will execute, that includes automating a bunch of things so you don’t have to, and it’s very powerful, and very helpful, but it’s this “very specific” part that I’m not a massive fan of.

I’ve spent a great deal of time building these Playbooks, and after a while they all start to feel very familiar. There also feels like there is a capability gap that is missing. These playbooks are not reactions, they’re impulses. There is no consideration for what they do, nor how they do it, beyond their predefined actions, they lack context, experience, and cohesion. Conditions A, B, and C have been met, and whilst condition D was only met 90%, it wasn’t 100%, so I won’t do anything at all.

Say we have a Playbook that runs when “malware A” lands on an endpoint. And the Playbook looks something like:

  1. Grab a copy of the artefact and sandbox it for later analysis
  2. Potentially boot the endpoint off the NAC
  3. Calculate the observables and upload them to Virus Total for inspection
  4. Create a ticket for the incident, including the VT data, and some context from threat intelligence
  5. Look through the mail-server for more samples of this malware, and remove them

This is a very common Playbook, I write it a few dozen times for each client, all very similar but all slightly nuanced. This represents my first issue with these platforms.

Let’s take our above example, and apply it to “malware B.” It’s very similar to the first one, but has dropped additional artefacts that were not collected in the first execution of the Playbook because we forgot to add this part when we were scoping the Playbook, or we hadn’t gotten around to implementing it yet. Now instead, our analyst has to manually go and get the samples, check them against VT, and update the ticket, rather than being able to simply to re-run the same Playbook, or better still, just ask for the new observables, and have the rest of these actions be implied.

Clippy for the SOC anyone?

Yes what I’m harping on about here, is in fact, a DFIR / SOC / ${ROLE} assistant.

I’ve given this a lot of thought as well, from a design perspective, and the reoccurring theme that I was running into, was the lack of data you would need in order to build something effective. There’s a simple case that you can just take some generic automation techniques, layer them on top of an Alexa skill, and boom, Alexa for the SOC, but I want to go back to the original premise of this blog. I find myself writing basically the same Playbooks time and time again, for very small nuances. I don’t want to do this anymore. I want a “something happened” thing, that doesn’t act on pre-determined impulse, but can react based on previous experience.

What we’re now talking about is an actual ML based approach that can look at a scenario, and imply what is supposed to happen next, based off of very lightweight, top level ideas, that get more and more refined as it learns. Something that that doesn’t just fire because of an alert mapped to a Playbook, but responds to predicates.

This all sounds well and good, and a great basis for our “SOC Assistant”, but very shortly into development you realise, we simply don’t have the data required to build something like this. Let’s talk a step back and look at a simplistic example that demonstrates this. Facebook. When content comes down and you interact with it on Facebook, whether you like it, comment on it, share it, whatever, that interaction produces data. Data that that interaction ever occurred, when it occurred, the general classifications and labels of the content, are all recorded on a single event. When the frequently vilified “algorithm” decides what content to show you next, it does so based on this “meta-data”. It’s not the actual content, the actual data, we care about so much, but the meta-data about that interaction, and that it even occurred, that’s more important. From that we can build a model, of what that person does and does not want to see.

If we want to build a model to know what to do under cyber events, we need the meta-data about the interactions, responses, and decisions that are taken, not only of the automation itself, but the interactions of the user.

Our meta-data messages need to be structured in such a way that it makes it easy to build our models, debug logs are cool, but single message defining the event is better, where we can clearly see the raw input, derived predicate, context, and then the taken action. These are all essential to be able to form a granular understanding of interactions taken, whether they were taken by an actual human, or if we just automated that part out already

Now when an event is read off the event queue, rather than looking for a specific match in its list of Playbooks, it analyses the event to understand some top level insights, has malware actually landed on the endpoint, has a honeypot been triggered, is this a NIDS alert, and then implements not an entire Playbook, but just the start of one, and we can extend it even further, because now we have broken it out into something more granular, and added the ability to make this a conversation, rather than an impulse, we have the basis for an actual assistant.

Let’s go back to our earlier example. Malware lands on an endpoint, and an alert has been created to be picked up. Our assistant, monitoring the alerts event stream, takes the event of the queue and derives its insights. It’s malware, on an endpoint. However instead of it being mapped to an exact Playbook to run, it knows that when “malware” is “on an endpoint” it needs to exec the following tasks:

  1. Notify Slack that it is looking at this issue
  2. Sample the artefacts it finds on the endpoint
  3. Potentially boot the endpoint of the NAC
  4. Upload the observables to VT for analysis
  5. Update a ticket with all the facts it currently knows

It knows to do all of these things, because of the second model that we had to build. The assistant knows how to handle the predicates that the platform creates, not just raw input.

And now what about if we need to get our hands on the new observables that have been dropped on the endpoint? Well rather than doing it by hand, we can just ask our assistant to help us. The input data is going to be different, rather than it being an alert event, it could be a user request, be that an API call, or a voice request that gets converted

“Alexa get the new observables from host-01”

the raw input should land us with the same predicate; get observables from an endpoint. Our assistant takes our predicate, and the supporting context, goes off and gets our new observables, but because we built a model that is staged and granular, we don’t need to do any more work for it to go and take these new observables, check them against VT, and update the ticket, because it has been trained on interaction data into knowing, if you’ve done this, go and do this other task with the result.

And whilst all of this is happening, our assistant and our users are still constantly generating the very data that we needed in order to build our assistant, and like most ML models, the more data you have on something, the better the end model is.

Source: Artificial Intelligence on Medium

Leave a Reply

Your email address will not be published. Required fields are marked *

Back To Top
a

Display your work in a bold & confident manner. Sometimes it’s easy for your creativity to stand out from the crowd.

Social