Threat Hunting

This section is under development

Objective

The definition is not fully agreed upon, however is described in a similar fashion by multiple sources.[1][2][3][4][5]

"Threat hunting is a proactive and iterative approach to detecting threats." (Lee and Bianco, 2016)

The objective of Threat Hunting[6] is a proactive search of systems for adversaries and compromise. Whereas Continuous Monitoring is a reactive service, Threat Hunting strives to actively search logs, controls, countermeasures and activity to identify signs of compromise before they are detected.

Hunting activity is related to other services as it feeds into Content Engineering, Continuous Monitoring, Log Management and Compliance and Risk Management.

Hunting also receives inputs from Threat Intelligence, Enterprise Intelligence, Content Engineering and Risk Management.

Process

These processes are ranked by complexity, starting with the least complex to the most complex.

• Known IOC Hunting

"Hunters should be careful about relying too much on IOCs. In the industry today there are many threat data feeds that lack the context to make them true indicators." (Lee and Bianco, 2016)

• Hypothesis Method[7][8]
• Exploratory Data Science[9][10][11][12]

Tooling

• SIEM, log management or other log collection and analysis tools
• Data analytics tools
• There is a vast array of tools capable of performing threat hunting & assisting with analysis.

Ticketing

From experience, Threat Hunting can be ticketing using multiple methods including existing ticket systems. They should, however, be notated as "Threat Hunting" so that effective metrics can obtained.

In addition, it is advisable to keep records of successful versus unsuccessful threat hunts.

Reporting

Threat Hunting is a specific service that can provide value in numerous ways to numerous different units inside an organization. The proactive nature of hunting identifies issues which the organization may not be aware of. Therefore, good communication lines are important as well as strategizing reporting in advance.

Reporting can be broken down into two separate levels in the enterprise.

• Internal between security teams
• Metrics and reporting to the enterprise

Here are some reporting subjects which are useful:

• Successful versus Unsuccessful Hunts - This is a ratio which helps indicate the accuracy of Threat Hunts. It is expected that this ratio should not be 100% or close to that. By definition, hunting explores and so your organization should set a threshold that it considers acceptable based on practitioner input.
• Gaps in Controls - Some organizations will find that hunting identifies gaps in controls. There should be a reporting mechanism for when this occurs. Best practice is to utilize existing ticketing systems and workflows throughout the enterprise.
• Adversary Intelligence - What did the threat hunt find? Does that tie back to an adversary? What other techniques does that adversary use? What is at risk (Confidentiality, Integrity, Availability)? What data would that adversary want? This feeds both Threat Intelligence and Enterprise Intelligence.
• Dwell Time - If the threat is significant, or, if your organization is mature and can extract the metrics, for many/most/all incidents, how long was it between when the compromise occurred and when the incident was identified?

Staffing

Staffing for Threat Hunting should be orientated to the desired maturity level.

• Known IOC threat hunting does not require the most senior analysts, though deep knowledge is helpful when investigating.
• Hypothesis Threat Hunting requires more senior hunters as they are generating the hypothesis. More senior resources will be capable of creating better and more accurate hypothesis.
• Exploratory Data Science requires a marriage of Cyber Security analyst experience and data science techniques. This is different from machine learning as it asks the data to describe itself instead of asking an algorithm to identify anomalies.

Threat Hunting activity, once started, will likely produce inputs to other teams that require action. Those teams should be communicated to in advance of these action items. It may also be advisable to understand that those additional teams may not be prepared to absorb the inputs generated from the Threat Hunting team.

Additionally, Computer Security Incident Response should be in place to absorb the incidents once hunting starts to identify them.

Budget

In addition to the budget for Threat Hunting staff, analytic tools and analysis environments may be required. These may be difficult to budget for at the onset as experienced staff must identify what tools are missing, required or will provide force multipliers.

When budgeting to create a Threat Hunting service, it is advisable to factor in some budget dollars for tool requires once the service become staffed.

Communications

A Threat Hunting team will, from experience, communicate as follows:

• Gaps in controls - Threat Hunting exposes gaps in controls. These can take the form of logs which are not parsed correctly, misconfigurations, log compliance gaps, control policy issues and log retention modifications. It is best to have a communications channel to the Security Engineering or IT Engineering teams. Architecture teams will likely also be engaged.
• Continuous Monitoring Use Cases - Successful Threat Hunts may be converted into Continuous Monitoring use cases in the SOC
• Security Control Policy Recommendations - When identifying TTPs[13], the Hunting team may identify or collaborate with Engineers responsible for Security Controls. Those will likely produce recommendations to modify the controls to stop the TTPs from being successful.
• Logging Recommendations - The Threat Hunting team may, independently or in collaboration with Threat Intelligence, identify recommendations to modify controls.
• Data Governance - The Threat Hunting team may identify adversaries which are acting against the enterprise and identify targeted data elements. This information should be fed to the Data Governance team or via the Threat Intelligence team to the rest of the enterprise.

The Threat Intelligence team should also be communicating to the Threat Hunting team about relevant information so the hunting team may adapt to changing circumstances. The Continuous Monitoring team may also communicate to Threat Hunters for exchange of information or meaningful trends they are seeing.

Documentation

The Threat Hunting team will likely produce a robust Knowledge Base, both in observations as well as in interpretation. Having a repository for that information is helpful and advisable.

Trends may also be documented in conjunction with the Threat Intelligence team and when married with the Threat Hunting function, produces Enterprise Intelligence.

Any adversaries identified by the Threat Hunting team will also be valuable information that should be enriched and distributed to stakeholders and policy makers.

Lessons Learned | Pain Points

• When starting out, evaluate existing tools and modify them to get the most value prior to making large investments
• Utilize a code repository so that hunting scripts, automation tools and techniques can be distributed and reused
• Consider a Security Engineering or development function to team up with Threat Hunters
• Some commercial tools are available to operationalize cognitive functions. They are good force multipliers.

Citations

Robert M. Lee and David Bianco. 2016. Generating Hypotheses for Successful Threat Hunting. Retrieved from https://www.sans.org/reading-room/whitepapers/threats/generating-hypotheses-successful-threat-hunting-37172

Additional Resources

https://www.threathunting.net/ - Has done a good job of collecting resources and special thanks to them.

https://www.darkreading.com/risk/cyber-hunting-5-tips-to-bag-your-prey/a/d-id/1319634