Understanding cyber threats helps organizations to assess their security posture against prevalent risks and make well-informed decisions around the most relevant cyber risks. These organizations are under constant pressure to identify an efficient and unified mechanism that can:
- Detect threats.
- Investigate incidents.
- Respond with a strategic risk mitigation plan.
This is not easy. Adversaries have access to sophisticated tools and resources available for-hire in the Dark Web. It often feels like they’re onto the next attack while your security team is trying to understand the last one.
For their part, organizations are looking for robust processes that are well defined and can consistently combat the persistent security risks. But with threats that are constantly changing shape, traditional Security Information and Event Management (SIEM) tools and the Security Operations Center (SOC) process frameworks can struggle to improve your security posture.
That means there is an opportunity here: taking a more strategic approach to risk mitigation across the Threat Detection, Investigation and Response (TDIR) lifecycle is crucial.
What is TDIR?
Threat Detection, Investigation and Response (TDIR) is a risk-based approach to mitigate cybersecurity threats and to more efficiently detect threats.
TDIR is a direct response to the “sole use of historical indicators of compromise of even TTP-based detection models”, which Gartner says are not sufficient for staying in front of sophisticated threat actors.
The TDIR lifecycle process involves four key steps:
- Aggregate data pertaining to valuable assets, operations and processes. This information may be collected from predefined data sources, integrations and cloud sources.
- Use threat detection models and tools to discover and map assets, create a risk profile and acquire business context. Use mappings such as MITRE ATT&CK to better understand the risk severity and process.
- Investigate the incidents and risk exposure using new data; understand how data transmission and network traffic deviate from the expected behavior. Prioritize alerts using business context enrichment.
- Develop and execute an efficient response strategy that reduces risks based on the available business context. Use turnkey playbooks for custom incident types and prebuilt incident timelines for all enterprise IT assets.
Example of traditional threat detection: lacking context
Consider the case of a threat detection alert: a suspected IP address wants to connect with your application servers. It may be possible that the application is vulnerable to a known attack and your IT has isolated some network resources to investigate the scope of risk.
A security analyst is tasked to discover any false positive alerts and gather information about the target servers. Because the analyst may not have access to the threat alert process, they are likely to:
- Spend a long time investigating the threat source, target server and the affected nodes.
- Perform manual processes such as issuing tickets to the IT department and analyzing network logs.
Once the issue is escalated, SOC teams may investigate additional data sources relevant to the incident. In order to classify the incident as anomalous or unexpected, the SOC analysts conduct a thorough investigation. These analysts investigate the workflow and route taken by the threat and collect logs from all dependent network nodes and endpoints.
This information is run through a threat detection model to develop a risk profile of the IT assets that may be classified as potential targets. There is a problem here: that without any available business context on these target assets, the analyst may have to engage multiple functional groups to acquire the additional knowledge.
Without asset context, incident response teams may end up resolving threats that do not qualify as high-severity risk incidents—which has some knock-on effects.
This increased workload on incident response teams has a snowball effect on how the SOC can prioritize and optimize a response plan to combat real security threats. The lack of an enriched threat detection and investigation mechanism means that:
- SOC resources are not optimally distributed.
- The response teams may fail to yield high performance on critical metrics such as Mean Time to Detection (MTTD) and other service-level objectives.
Using the TDIR Lifecycle to resolve these limitations: TDIR best practices
Using the TDIR lifecycle can help you avoid these inherent limitations. Here’s some best practices for aligning with it:
Define goals for SOC workflows & playbooks
Start with defining the goals and objectives for your SOC workflows and risk mitigation playbook guidelines:
- Identify your compliance requirements, risk exposure and appetite for risk.
- Map your processes and data sources into a cyberattack map; the asset information may include asset records of authority as defined in the CMDB as well as dynamically discovered assets.
- Extract threat exposure information from security control validation tools. This information can include vulnerability enumeration, risk indicators, attack path mapping as well as known IT risks.
Standardize TDIR workflows
Standardize TDIR workflows to provide a well-guided response strategy. Map the threat processes and behavior to the most relevant techniques (such as those in the MITRE ATT&CK framework). Consider these techniques as a playbook adopted by the adversary and use this knowledge to guide a response plan based on the threat lifecycle.
Adopt a modular approach to automate every stage of the TDIR lifecycle:
- Operationalize the use of threat-centric tools.
- Evaluate the threat process lifecycle based on contextual business knowledge.
- Focus your efforts on the most impactful threat vectors.
Cover all threat types
Finally, provide coverage for all types of threats: compromised and malicious insiders as well as external threat actors. The mode of attacks may range from malware and phishing attacks to data exfiltration and compromise of physical security of target assets.
What is Splunk?
This posting does not necessarily represent Splunk's position, strategies or opinion.