Network Security
Vulnerability Management
Privileged Access Management
Endpoint Security
Threat Hunting
Unified Endpoint Management
Email & Collaboration Security
Contents:
A threat hunting framework is a collation of data-driven adversarial scenarios, backed up by hypothetical, field-tested, or time-honored TTPs (i.e., Tactics, Techniques, and Procedures). Serving a wide array of security-wise needs such as baselining, forecasting, threat modeling, vulnerability discovery, and incident response optimization. In this article, we’re going to explore model-based threat hunting, go over wireframing prerequisites, and cover a couple of framework-optimization aspects. Enjoy!
The Building Blocks of a Business-Tailored Threat Hunting Framework
Threat-hunting is more than a buzzword that polarizes the cybersecurity world; the new (i.e., proactive cyber-stance) doesn’t need to outtake the old (i.e., traditional cybersecurity), but to add more nuances, additional layers, additional granularity, and more control over the environment and its assets. In all regards, threat-hunting means arming the defenders with the tools they need to counter modern-day cyber threats.
This newfangled mindset factors two key pillars – defense and offense, as securing your assets is just as vital as going in guns blazing; and this is where the threat-hunting framework comes into play. If we’re to boil this cyber etch-and-sketch done to its bare essentials, it will look something like this: hypothesis, data collection, correlation, testing, and adoption. Looks a bit much like your high-school Phil 101 syllabus, doesn’t it? Well, you’re not wrong there. Anyway, with the intro behind us, let’s deep-dive into the threat-hunting framework.
Step 1. Formulating a functional threat-hunting hypothesis.
The cyber-world is a cacophony of facts, ideas, and concepts, however, not all of them are relevant. A functional threat-hunting hypothesis is the foundation of your framework and quite crucial; imagine building a house of rickety bedrock. So, to figure out where you stand, the first thing to do is to get your bearings; in our case, we need facts. Literally, every corner of the Internet is flooded by facts and information – even a rudimentary Google search such as “latest vulnerabilities” can unlock an array of data that can potentially be used to weave a functional threat-hunting hypothesis.
Your fact-finding tour can take you to a lot of places such as open-source/closed-source threat intelligence repositories (e.g., LookingGlass, AIS, TypeDB CTI, Yeti, proprietary databases), forums, social media circles, RSS feeds, etc. Unfortunately, abundance and variety do not equal relevancy; it just means putting in more time to swift through the junk and dampen all grey noise. No, we’re not back at square one; we have intel or, at least, have the means to acquire the necessary intel, be it tactic, high-level, case-sensitive, or general info, but how do we connect the dots? Try out this small Q list.
- Is this relevant to my industry?
- Is this relevant to my business?
- Do I need threat-hunting?
- How solid is my threat-hunting hypothesis?
- Can I afford to commit the necessary resources?
- Is my threat-hunting hypothesis aligned with my business goals?
After checking out all the items on the list, you’re left with a functional threat-hunting hypothesis; a solid, fact-supported conclusion, relevant to your industry/business, and necessary for mitigating risk and ensuring continuity.
Here are a couple of examples to get you started.
- A threat actor might be trying to infiltrate our systems and establish a foothold by exploiting a newly-discovered zero-day vulnerability.
- A threat actor might be leveraging a specific type of dropper to deploy cryptomining software.
- A threat actor could use an inherently vulnerable port (e.g. RDP) to exfiltrate data.
- Multiple intrusion alerts have been issued from the same user account.
- The number of newly-created accounts doesn’t match the number of hired employees.
- A surge in large-file transfers has been detected.
Step 2. Collecting relevant data.
Now that you’ve come up with a working theory, it’s time to gather the relevant data to back up your claim. As you probably know by now, data comes in many shapes and sizes – alerts and flags from your proprietary database, open-source stashes, forums, and even hearsay can help even the odds. One thing you must always keep in mind is that the data source you choose must be relevant to your hypothesis. For instance, if you have a hunch that a threat actor might be using an inherently unsecured port to exfiltrate data, it would be a good idea to pull out the firewall logs.
Similarly, if you believe that some of your machines are covertly communicating with a known C2 server, you may want to review your traffic logs. Also, take into account the size of the job – an endpoint-centric investigation is not that big of a deal, but a full-fledged, company-wide audit requires resourcefulness aka automation. In either case, you should definitely research tools that fast-track the data-gathering job such as SIEM, SOAR (i.e., to a certain extent), and data log management.
Step 3. Correlate with threat-hunting methodologies
Adversarial models are the go-to places if you want to rid yourself of confirmation bias, scoop out more data on a specific ATP, or, even better, research even more TTPs associated with a specific threat actor. There are many adversarial methodologies out there, each with its own quirks, methodology, event description, and, of course, availability. For newbies, it’s best to stick with the classics such as MITRE’s ATT&CK framework and NIST for defense reinforcement. However, for more advanced threat modeling, you could also try out STRIDE, Atomic Red Team, DumpsterFire, or Mordor (not a LOTR reference!).
Step 4. Create and test scenarios.
Steps one through three will help you devise a functional threat-hunting hypothesis, gather relevant data from multiple sources, and cross-reference your info against reputable industry standards. Now, this is where the fun truly begins; with everything in place, you can now start creating scenarios. So, what’s the difference between hypothesizing and creating/running scenarios? Besides the obvious fact that it would be an exercise in futility to run scenarios without one or more working hypotheses, scenarios usually leverage more than one theory.
Step 5. Automate threat-hunting jobs.
The final step towards building your very first threat hunting framework is to identify and automate low and medium-level jobs. This includes data collection, alerting, encoding standardization, reporting, and collaboration; and what better way to do that than with a platform capable of leveraging powerful reporting features, advanced threat intelligence, and digital forensics?
Introducing the Heimdal® Threat-Hunting and Action Center is a revolutionary platform that is fully integrated with the Heimdal solution suite. Designed to provide security teams with an advanced threat-centric view of their IT landscape, the solution employs granular telemetry to enable swift decision-making, using built-in hunting, remediation, and actioning capabilities – all managed from the Heimdal Unified Security Platform.
The solution is powered by the Extended Threat Protection (XTP) engine, Heimdal®’s retort to outstanding threat detection, prevention, and mitigation. XTP moves beyond file- and behavioral-based analysis, ushering in the era of evidence-based threat-hunting.
This achievement was made possible by imbuing our Threat-Hunting and Action Center solution with SIEM (i.e., Security Information and Event Management) and SOAR (i.e., Security Orchestration, Automation, and Response) capabilities, crucial assets in detecting and mitigating the aftereffects of next-generation malware.
- Granular telemetry across endpoints and networks.
- Equipped with built-in hunting and action capabilities.
- Pre-computed risk scores, indicators & detailed attack analysis.
- A single pane of glass for intelligence, hunting, and response.
Conclusion
Every threat hunting framework should contain the following elements: a functional, intelligence-driven hypothesis, data to back up the said theory, external, adversarial model-based correlation, plausible (and field-tested scenarios), and lots of automation. This concludes my article on how to articulate a robust and functional framework for your company. For any questions, inquiries, and compliments, contact me at vun@heimdalsecurity.com. Stay safe and happy holidays!
