header image

Building Detection and Response Capabilities

Here is the thing about building detection and response capabilities: It can be a daunting task. You are setting out to create a team that will ingest massive amounts of data from your network, make sense of the collected noise, respond to threats across your organization, and discover and stop potential breaches… while keeping your head cool.
At NIL815, we can help you navigate this undertaking and avoid the common pitfalls when hiring people, creating processes, selecting tools, and building use cases using a proven methodology. We also can augment or help improve your existing capability if you need an analyst-for-hire.
There are three overarching areas in building a detection and incident response capability: people, processes, and tools. From these three areas, all other activities are derived.


Analysts and incident responders are a particular breed of security professionals. They need to follow agreed-upon processes and be critical thinkers – 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 to get the job done. To some degree, the analysts’ skills will affect the choice of tools. For example, when choosing an EDR with a heavy focus on forensics, the team should have the qualifications to use that capability or be trained accordingly.
Decide what people you need: analysts, detection engineers, threat hunters, threat intelligence analysts, and responders. Some of them overlap in skill sets and are interchangeable in roles. Consider using a 3rd party to complement your workforce either during the starting period or as a supplement or continuous partner.
Do not let the team be internal free-for-all consultants or the policy police of your organization, except there those policies directly translate to a tangible threat with actionable information and incidents. The team’s time should not be spent on other activities like physical security, IT hygiene, or vulnerability and patch management. Instead, these efforts should be located elsewhere in the organization to retain the team’s focus on detection and response.


A good team needs an operations framework to ensure all analysts are aligned. An overall Incident Response Plan (IRP) can support this. The IRP should hook into existing processes in the organization and ideally be internal to the team lest it uses valuable time to create a plan for the entire organization.
Keep hard-cut processes at a minimum to retain agility. Too many strict procedures create a team good at following processes but not solving problems. Processes must have a maturity level to the 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 ensuring the team operates under a particular umbrella and runs somewhat coordinated in the same direction. You should work towards a team with the self-discipline to document what is needed.
You should create use cases to make sure your efforts cover actual threats and that the data you choose to collect and the capabilities at your 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 its 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 rely on common sense and expertise. They must always relate to the real world and the organization’s possible threats.


Tools and capabilities are where most of your focus should be. Without the proper tools and capabilities, your team quickly becomes inept.
Choosing the right tool for the job is fundamental to your analysts and responders and will determine the team’s success. No process or amount of talent will be able to compensate for significant gaps in capability or visibility.
A detection and response capability should be able to perform what they are set out to do: detect and respond. For example, a SIEM primarily focusing on data analytics and where logs and telemetry are first-class citizens will cover your analysts’ needs for detection and investigation. In contrast, an EDR focusing heavily on remote forensics and containment functionality will put the response in Incident Response.
In general, being able to choose the proper tools is determining the correct requirements. For example, do you want an EDR with more weight on remote forensics or endpoint telemetry? Do you want the SIEM to be the king of automation or data analytics?
This does not mean the blind acquisition of the latest and hottest technology is the way to go. Instead, you should be careful when mapping existing capabilities. For example, your AV may already be able to contain an endpoint, and a GPO exists that disables all remote accesses for a user. You can use whatever is already 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 organization. There is a high chance that the existing tools and technologies must be designed or implemented to support security investigations and incident response. This means more work for the team using the 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 organization. Therefore, the team should be able to work as independently as possible. Get the team’s tools as far away as possible from the organization’s network and SSO solutions. Putting your SIEM on the same network you are monitoring, forcing the analysts to use standard corporate laptops, and hooking every tool up to your SSO means that any large-scale compromise can render your team inoperable.
The decisions made on tools will affect the team for years to come and will directly impact time-to-remediation; choose wisely.