Detection & Response That Scales: A 4-Pronged Approach

This article was originally published on Dark Reading.

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 year's 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.

From Reactive to Proactive

"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 doesn't scale. We need the rest of the organization to be in lockstep with us and working alongside us — that's what defines a modern detection and response approach."

Related:What Is Data Tracing? How Does It Enhance Security?

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 everybody's on the incident response team when there's 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."

Understanding, Aligning Skill Sets

In the design and development phase, understanding and aligning skill sets are crucial to avoid building tools beyond the team's 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.

It's 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.

Buying and Product Building

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, you're building something new, you're 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 what's important about any platform is the incorporation of modern principles that allow security teams to build automation modifications the way they see fit. 

"Because I'm an engineer, I love to build — sometimes that's 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 we're going to buy it, but there is going to be lots of building'."

Metrics That Tell a Story

The final phase involves improvement of the evaluation and reporting processes through using metrics that tell a story about how the program is performing.

"It's important to have a full picture of the different type of threat techniques you can detect — and the ones you can't 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 doesn't 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 you're 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.

"That's what you need to build a roadmap of what you know you can see, what you can't see, and develop a vision of how you're going to accomplish it technically," he says. "Here's 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."