Incident Response: Endgame

Written by

With the latest instalment of the Avengers series hitting the screens, we can take a light hearted look at incident response tools and techniques from an ‘Endgame’ point of view. We always talk about incident response “teams”, fortunately for us we don’t have to worry about losing half our team in the middle of an incident, but we do have the same mission to defeat our foes when all other defenses have failed!

So, let’s start with the core of this topic: “teams” both for staff and technologies. We all know there is no single silver bullet out there (no matter how good a job the sales teams do to try and persuade us otherwise) and while lots of organizations have their own superstars for incident response, they still have to sleep and even get time off work! So we have to build a team which is resilient, has the capability to respond to incidents and has a diverse pool of skills and tools.

We all know that you need a diverse set of skills to run an effective Incident (from triage all the way through to remediation and lessons learnt). Here I want to focus more on the toolsets required to be an effective team rather than the virtues of Open Source tools versus that of vendors, as we have to make the most of every tool that we have available to us as a team.

That said, we are incredibly fortunate these days with the number of projects being run supporting Incident Response teams such as TheHive Project, Cuckoo Sandbox and MISP to highlight but a few.

We need to work out what it is we, as an organization are seeking to achieve (the business decisions/risks etc.) and then build out either our security monitoring or incident response capability to match up to that mission.

As little as ten years ago that was achieved by something as simple as having your firewalls in place and dumping a few IDS/IPS’s at your gateways, that umbrella approach has changed radically since then.

SIEM’s have taken up part of the mantle of giving us the visibility we require (but are not really suited for IR teams) these coupled with network sensors (full packet capture etc.) and orchestration give organizations an “eyes on glass” security monitoring capability, but that is still not enough for incident response.

Responders do need access to all of this information, but be able to move forward from just knowing that an incident has happened to being able to do something about it, and this is where the incident response team earn their keep.

The core of an incident response team is their specialized tools and their skillset to use them (often in a manner which is forensically sound and will stand up in a court of law). Typically, these are to give us visibility into an issue (network, forensic, malware analysis) which in turn spin out our indicators of compromise and build out our threat picture/campaign knowledge (which feeds into future investigations); arguably this knowledge is our most important tool/component of any investigation.

This then leads into how to best make use of that information as part of your investigation and in most cases you are going to need multiple tools working in harmony. A good example of this is in forensic investigations which are dominated by the vendor toolsets from access data, guidance software and X-Ways.

However in every single incident or investigation, I have always had to use a suite of other specialized tools for specific tasks such as registry analysis (Regripper), memory analysis (Volatility), metadata analysis (ExifTool) or autorun locations (Sysinternals Autorun) (Note: other forensic tools are available!).

That really brings me to the core of this blog: just like having one extremely skilled member of a team (there is always one ninja in any team no matter the size) neither they nor their tools should be critical to an organization or team. A team is just that, we diversify and spread our knowledge and do the same with the tools which we use for our incidents.

We know there is no “silver bullet” so we have to get away from the idea of working with a singular or limited toolset. Let’s make sure that as incident responders we have access to the right tools for the job and ensure that we are cross training our staff to avoid any risk of failure (hey even Tony Stark created an alternate in the form of War Machine!). So, define your own origin story:

  • What your Mission is (Business requirements)
  • Who your team is
  • What your tools will be – and ensure they fulfil all of your IR requirements (there is no point being unable to analyze “X” on a client site and having to scrambling to acquire it)
  • Train your team in their tools and your procedures
  • Test them in real world scenarios – play for real!

I am not saying that a click of the fingers will solve all of your problems as there is a lot of hard work required, but working to expand your teams’ knowledge both from an IR and tooling point of view is going to reward you when you get to your Endgame.

What’s hot on Infosecurity Magazine?