Detection & Response That Scales: A 4-Pronged Approach

Building a resilient incident response team requires more than a simple combination of tools and on-call rotations.

Combating modern attackers demands a robust and comprehensive detection and response program, yet challenges such as
alert fatigue
, costly tools, talent acquisition difficulties, and an overworked team hinder progress.
At this years Black Hat Europe,
Allyn Stott, senior staff engineer with Airbnb, will discuss how a proper framework can help IT security leaders develop the essential capabilities of a modern program amid the relentless surge of incidents and demanding schedules.
Historically, detection and response programs have been very reactive, focused on alerts that indicate something bad has already happened, Stott explains. You want to be more on the proactive side and not just doing threat hunting but adopting a philosophy for detection that focuses on detecting threats as early in an attack as possible.
He adds with many legacy systems, the focus often lies on technology tools and vendors, as opposed to capabilities the security team has, and points out many of these systems are completely siloed off from the rest of the organization.
When you operate completely silent and disjointed, it puts your teams completely out of touch with your organization and inhibits their ability to work side by side with partner teams, he says. The detection capability doesnt scale. We need the rest of the organization to be in lockstep with us and working alongside us — thats what defines a modern detection and response approach.
Stott breaks down the implementation of
threat detection and response
modernization into four phases, starting with an assessment of the current state of the program.
This is when you learn about your organization or the technology challenges and your people challenges, he says. Who are the stakeholders for your organization, and who needs to be involved?
One of his favorite things about being in detection response is that there is an automatic way to get other stakeholder teams involved with the core security team because at some point the organization will experience a security incident.
This idea that everybodys on the incident response team when theres an incident really rings true, Stott says. In that first phase, you need to take a step back and see what the organization actually needs from detection and response.
In the design and development phase, understanding and aligning skill sets are crucial to avoid building tools beyond the teams capabilities.
How does your threat intelligence gathering interact with threat hunting or detection engineering, and how does it fit together with more classic incident response stuff — the triage, the analysis, the response, the forensics? Stott says.
Its important to home in on specific capabilities — for example, host isolation or memory forensics or the ability to do anomaly detection.
Think about the different technical capabilities you would need for each of those processes and then determining how those would interact, he says.
In phase three, product buying and product building determine how the planning and processes will be put into practice.
The reality is that when you are in detection response, youre building something new, youre still having to be operational, you still have alerts, you still have incidents, Stott says. You might want to consider bringing in a
third-party SOC
to [give] yourself some breathing room to build the program.
He says a good vendor solution should get you 65% of the way there, adding whats important about any platform is the incorporation of modern principles that allow security teams to build automation modifications the way they see fit.
Because Im an engineer, I love to build — sometimes thats what I really want to do, he admits. A good reminder to engineers and the folks that work on my team is to say, Yes were going to buy it, but there is going to be lots of building.
The final phase involves improvement of the evaluation and reporting processes through using metrics that tell a story about how the program is performing.
Its important to have a full picture of the different type of threat techniques you can detect — and the ones you cant detect, Stott says. Even maybe more important is knowing what environments you can detect and not detect. Maybe an organization has good endpoint coverage, but it doesnt have good coverage in their production.
From his perspective, being able to tell that story will also help bolster calls for more funding or additional headcount.
Instead of having all these alerts and not really providing a lot of meaning about them youre providing observability metrics, where you can see threats across different environments and discover where you have gaps, he says.
Part of telling that story is tying all those metrics to the top threats being observed, the top environments at risk, and the top incident trends currently being observed.
Thats what you need to build a roadmap of what you know you can see, what you cant see, and develop a vision of how youre going to accomplish it technically, he says. Heres what we need to fund it, here are the document items we need to have, and here is what we need to be able to build it. That wraps the whole thing up.

Last News
▸ ArcSight prepares for future at user conference post HP acquisition. ◂ Discovered: 07/01/2025 Category: security	▸ Samsung Epic 4G: First To Use Media Hub ◂ Discovered: 07/01/2025 Category: security	▸ Many third-party software fails security tests ◂ Discovered: 07/01/2025 Category: security

**Cyber Security Categories**
Google Dorks Database	Exploits Vulnerability	Exploit Shellcodes

CVE List

Tools/Apps

News/Aarticles

Phishing Database

Deepfake Detection

Trends/Statistics & Live Infos

Tags:
Detection & Response That Scales: A 4-Pronged Approach