One of the things that motivates me to write is either being really pissed off or finding someone I really respect and having a different opinion. This blog is about the latter. Richard Bejtlich tweeted (oh the horror) that to him, hunting is just another form of detection. Now his real argument is of course more nuanced and well thought out but for the purpose of my blog and putting forth my view I’ll try to make his as simplistic as possible.
For me, “hunt” is just a form of detection. I don’t see the need to build a “hunt” team. IR teams detect intruders using two major modes: matching and hunting. Junior people spend more time matching. Senior people spend more time hunting. Both can and should do both functions. https://t.co/nyNO1q4LIl
— Richard Bejtlich (@taosecurity) November 18, 2018
Now in reality, debating with Richard about topics related to detection, network security monitoring, and consequently threat hunting is probably similar to debating Plato about societies in the Republic. But I’ve always found myself learning more from debating smart people about small disagreements than debating the ones I outright disagree with. So enough compliments, let’s get into it.
The Argument
The heart of the argument, as I’m positioning it, is about what hunting is and is not and thus how folks use it. The initial prompt was from Twitter user @hellor00t about where “hunt teams” should be placed in the CIRT and whether or not hunt is just a new term for IR analyst. The comment was “seems like title semantics to me.” Which is totally fair. Richard, as previously stated, noted that hunt is just a form of detection. That incident response teams detect intruders using two major modes: matching and hunting. There’s a lot to unravel here but I’ll bypass the modes of detection argument slightly to say I actually agree but wouldn’t call one mode hunting. You’re either matching knowns (behaviors of adversaries, indicators, behaviors of users, etc.) or exploring unknowns (anomalies). You should cover your knowns first and then explore the unknowns but your strategy for detection should be more well thought out. I covered that topic with Sergio Caltagirone in a paper on the four types of threat detection which actually lines up nicely with Richard’s point (except the term hunting) here.
My Position
Honestly you can do whatever you want that gets you excited about security and proves to be an efficient and effective way to do your job for the organization. But I do think hunting goes beyond Richard’s point. I’ve written about threat hunting (not nearly as much as Richard) previously a few times before but here are two papers that help phrase my “school of thought” a bit that I wrote with David Bianco on generating hypotheses and another about what hunting is and isn’t with the “other” Rob Lee at SANS. My main thought process is that threat hunting is a proactive and iterative approach to detecting threats. It seems to align directly with what Richard wrote but I’d add that it really isn’t, to me, about detecting threats. I know that’s super confusing so I’ll go into depth a bit more.
Hunting is a hypothesis-led approach to testing your environment for threats. The purpose, to me, is not in finding threats but in determining what gaps you have in your ability to detect and respond to them. As an example, how do you know whether or not your organization would ever be able to detect and respond to the latest tradecraft observed by $ActivityGroup? You should generate a hypothesis about how that tradecraft would look in your environment played out against what you have to protect. You could determine the “route” the intrusion might take based on what you’ve observed previously and see if you have the people, process, and technology required at each point to successfully detect the tactics and procedures of the threat as well as the ability to respond to them. That’s only one way to generate hypotheses but hopefully serves as a tangible example. You’re looking to achieve a layered defense while figuring out your gaps. As an output of hunting, you should have gaps to address as well as detections you can now create as a result of your hunting (i.e. threat hunting cannot be fully automated but the output of your hunting should be more automation in your environment against the threats you hunted for). You could also create playbooks, or step-by-step guidance, on what an analyst should do to validate malicious activity and how to respond based on what you learned. Additionally, you could update your collection management framework (a topic I’ve talked about before and will have a paper out later this month on) to discuss what collection and data sources you do and don’t have in your own environment.
In short, hunting, to me, is a way to assess your security (people, process, and technology) against threats while extending your automation footprint to better be prepared in the future. Or simply stated, it’s incident response without the incident that’s done with a purpose and contributes something. Ad-hoc hunting to me isn’t hunting, it’s just proactively searching for threats in your environment (although admittedly saying you’re “hunting for threats” rolls off the tongue a lot better than “log correlating and searching”). Responding to alerts isn’t hunting either, it’s just triaging and investigating alerts. However, there are many “schools of thought” and you’re welcome to do whatever works for you in your environments.
Threat hunting is also an extremely useful way to measure the effectiveness and breadth of your threat intelligence efforts. Dan Gunter wrote an excellent Masters paper at SANS here on the topic.
Back to the original question of “where do you put your hunt team?” I really wouldn’t have a dedicated threat hunting team. I’d treat threat hunting as a multiple times a year or at least once a year assessment against the scenarios that are most concerning to you and your organization. Bringing together people from across the security organization and even outside that organization can be really useful to thinking outside the box about your hypotheses generation efforts. Having a dedicated team can make the process stale and cause too much group think. I’d rather see people “take turns” in that role if there’s a need to have a dedicated function.
In Conclusion
In conclusion (for now I assume) I will note I probably don’t disagree with Richard much but it was a useful prompt to have me think about threat hunting and put some thoughts in a blog to hopefully help others flesh out their views. My view is that hunting is not a form of detection, or isn’t just a form of detection. If you’re measuring the value of threat hunting on how many threats you find you’re likely not to be able to justify it at all compared to just doing proactive security work. Threat hunting, in my opinion, should be a much more structured test against hypotheses that is pushing your organization forward and ensuring you’re prepared against “styles” of threats. I do completely agree with Richard’s view though that Response is too narrowly defined as just incident response and after the fact to folks. I talk about “detection and response” largely because the terms can be useful in communication and when defining skill sets of folks. However, I do agree that detection and response both should be tightly coupled in people, process, and technology and that response is, in its best form, proactive.
Definitions and history are at play here. I learned my craft in the Air Force Computer Emergency *Response* Team (AFCERT). We did detection *and* response. For me, “response” has always been “proactive.” I have never liked any separation between “detection” and “response.” #DFIR https://t.co/oJY2LMFPV4
— Richard Bejtlich (@taosecurity) November 18, 2018