Scott Roberts on intelligence-driven incident response

In this episode of the Security Podcast, I talk with Scott Roberts, security operations manager at GitHub. We discuss threat intelligence, incident response, and how they interrelate.

Here are some highlights:

Threat intelligence should affect how you identify and respond to incidents

Threat intelligence doesn’t exist on its own. It really can’t. If you’re collecting threat intelligence without acting upon it, it serves no purpose. Threat intelligence makes sense when you integrate it with the traditional incident response capability. Intelligence should affect how you identify and respond to incidences. The idea is that these aren’t really two separate things, they’re simply two pieces of one process. If you’re doing incident response without using threat intelligence then you’ll keep getting hit with the same attack time after time. Now, by the same token, if you have threat intelligence without incident response, you’re just shouting into the void. No one is taking the information and making it actionable.

The open-ended nature of incident response

It’s key to think about incidents as ongoing. There are very few times when an attacker will launch an attack once, be rebuffed, and simply go away. In almost all cases, there’s a continuous process. I’ve worked in organizations where we would do the work to identify an incident and promptly forget about it. Then three weeks later, we would suddenly stumble across the exact same thing. Ultimately, intelligence-driven incident response happens in those intervening three weeks. What are you doing in that time between incidents from the same actor, with the same target? And how are you using what you’ve learned to prepare for the next time? Regardless of the size of your organization, you can implement processes to better your defenses after each incident. It can be as simple as keeping good notes, thinking about root causes, and considering what could better protect your organization from the same or similar attackers in the future. Basically, instead of marking an incident closed as soon as you’ve dealt with the immediate threat, think beyond the current incident and try to understand what the attack is going to look like the next time. Even if you can’t identify the next iteration, you don’t want to get hit by the same thing again. As your team expands and matures, there are opportunities for more specialized types of analysis and processes, but intelligence-driven incident response is something you can adopt regardless of your size or maturity.

Why more threat intelligence data is not always better

When a team gets started with threat intelligence, their first impulse is to try collecting the biggest data set imaginable with the idea that there’s going to be a magic way to pick out the needle in the haystack. While I understand why that may seem like a logical place to start, that’s often a very abstract and time-intensive approach. When I look at intelligence programs, I first want to know what the team is doing with their own investigation data. The mass appeal of gathering a ton of information is all about trying to figure out which IP is most important to me or which piece of information I need to find. Often, I find that information is already available in a team’s incident response database or their incident management platform. I think the first place you should always look is internally. If you want to know what threats are going to be important to an organization, look at the ones you’ve already experienced. Once you’ve got all those figured out, then go look at what else is out there. The first place to be effective and truly know that you’re doing relevant work for your organization’s defense in the future is to look at your past.