header image

INCIDENT RESPONSE UNIT –
CREATION AND ASSISTANCE

Here is the thing about building a unit performing detection and response: it can be a daunting task. You are setting out to create a team that will ingest massive amounts of data, make sense of the collected noise, respond to threats manifested across an entire organisation, track and remove any adversary footholds….and keep a cool head while doing it.

Reach out for assistance to navigate this undertaking of building a SOC or SAC and avoid the common pitfalls when hiring, creating processes, selecting tools, bulding use cases, or if you just need an Analyst-for-Hire to get some return of investment right of the bat.

There are three overarching areas in building a detection and incident response unit: staff, processes, and tools. From these three areas all others activities are derived


Staff


Analysts and incident responders are a certain breed of security professionals. They need to follow agreed upon processes and think outside the box – at the same time.

A good team dealing in analytics and response uses the tools available and expands the arsenal on the fly, using whatever they can get their hands on. The skills of the analysts will to some degree affect the choice of tools. When choosing an EDR with a heavy focus on forensics, the team should have the qualifications to actually use that capability or be trained accordingly.

Decide what type of personnel you need: 1st level analysts, 2nd level analysts, threat hunters, and responders. Some of them overlap in skill sets and are interchangeable in roles. Consider using a 3rd party to complement your work force either during the starting period og in general as a supplement or continuous partner.

Do not let the team be internal free-for-all consultants or the policy police of your organisation, except there those policies directly translate to a tangible threat with actionable information and incidents. Neither must any time be wasted on physical security, it hygiene, or vulnerability and patch management. These efforts should be located elsewhere in the organisation.

Processes


A SOC needs a framework to operate under to make sure all analysts are aligned. An overall Incident Response Plan (IRP) can support this. The IRP should hook into existing processes in the organisation and ideally be internal to the team lest it uses valuable time to create a plan for the entire organisation.

Keep processes at a minimum to retain agility. Too many and strict processes creates a team that is good at following processes not solving problems. Processes must have a maturity level of “defined” to a degree that the team can operate freely under it, respecting different approaches by individuals to reach an agreed upon outcome. The most important thing is to make sure that the team operates under a certain umbrella and running somewhat coordinated in the same direction. Work towards a team that has self-discipline to document what is needed.

Create use cases to make sure your efforts cover actual threats and that the data you choose to collect and the capabilities at disposal support these. The threat landscape is evolving and your list of use cases should not be a limiting factor. While some use cases are high level enough to allow for threat hunting, threat hunting should be considered an activity in it’s own right and be completely unconstrained as new use cases can emerge from threat hunting. Consider using a good framework to map your build up of use cases, such as the MITRE ATT&CK framework; or don’t use a framework and realy on common sense and expertise. They must always relate to the real world and the possible threats facing the organisation.

Tools


Tools and skills is where the action is at and the majority of your focus should be aimed here. Without the right tools your team is dead in the water. Choosing the right tool for the job is fundamental to your analysts and responders and will determine the success of the team. No process or talent will be able to close insurmountable capability gaps.

An analytics and response team should be able to perform what they are set out to: detect and respond. A SIEM with a primary focus on data analytics where logs and telemetry are first class citizens will cover detection, while an EDR with a heavy focus on remote forensics and containment functionality puts the response in Incident Response.

In general choosing the right tools is determining the right requirements. Do you want the EDR to put more weight on remote forensics or end point telemetry? Do you want the SIEM to be king of automation or king of data analytics?

This does not mean that blind acquisition of the latest and hottest technology is the way to go. Be meticulous when mapping existing capabilities. Maybe the AV can already contain an end point and a GPO exists that disables all remote accesses for a user. Use whatever is already present on your network and map it to the needed capabilities to run your team efficiently.

There is, however, a trade off when using existing capabilities in the organisation. Chances are high that existing tools and technologies were either not designed or implemented with analysis and incident response in mind. This means more work for the team using time they do not have and often results in a never ending up-hill struggle to shoehorn the IT operations team’s tools to suit their need. Furthermore, the team will be dependent on the organisation. The team should be able to work as independently as possible. Get the teams own tools as far away as possible from the organisation’s network and SSO solutions. Putting your SIEM on the same network that you are monitoring, forcing the analysts to use standard corporate laptops, and hooking every tool up to your SSO essentially means that any large scale compromise renders your team inoperable.

The decision made on tools will affect the team for years to come and will have a direct impact time-to-remediation; choose wisely.