Hi
@GavinRook,
There isn't really a one size fits all process that our customers go through with Indicators as each customer is usually focused on specific indicator types. However, here is a loose framework that you might want to consider when ingesting or using threat feeds for indicator enrichment.
- Collection: This is the initial stage where indicators are gathered from various sources. These sources can include threat intelligence feeds, internal network monitoring, logs, endpoint detection systems, and external reports.
- Validation and Enrichment: After collection, each indicator needs to be validated to ensure it's relevant and not a false positive. Enrichment involves adding context to the indicator, such as its source, the type of threat it signifies, historical information, and how it relates to known threats or attacks.
- Analysis: This phase involves a deeper investigation of the indicators to understand their implications. This could include analyzing the behavior associated with an IoC, assessing its impact, and determining the threat actor's tactics, techniques, and procedures (TTPs).
- Integration and Implementation: Here, the validated and analyzed indicators are integrated into security systems such as firewalls, SIEMs, endpoint protection platforms, and other defensive tools. This integration allows for automated detection and response based on these indicators.
- Monitoring and Response: The indicators are continuously monitored. If an indicator is matched in the environment, it triggers a response which could be automated or manual. The response could involve further investigation, containment, and remediation actions.
- Review and Update: Indicators can change or become obsolete over time. Regular reviews are necessary to update the indicator database, remove outdated entries, and adjust strategies based on the evolving threat landscape.
- Sharing: Sharing indicators with trusted partners or industry-specific ISACs (Information Sharing and Analysis Centers) can be crucial. This helps in collective defense and gaining insights from a wider community.
When considering the implementation of automated processes in threat intelligence and indicator lifecycle management, it's crucial to first identify specific use cases and understand the underlying reasons for these choices. This step is especially important if there is any uncertainty about the objectives to be achieved.
Ask yourself: What are the specific goals your organization wants to accomplish with automation in threat intelligence? Identifying clear use cases helps in designing a system that is tailored to your unique requirements and challenges.
For instance, consider where your team can save time and improve your security posture by automating tasks currently done manually.
A couple of examples include:
- Automated Threat Hunting: This involves setting up systems to automatically collect and analyze data from various sources to identify potential threats. The goal here might be to proactively discover hidden threats, reduce detection time for advanced persistent threats, or handle large volumes of security data more efficiently.
- Automatically Creating Blocklists/Allowlists: This use case focuses on using automated systems to fetch and analyze indicators from threat intelligence feeds and categorize them into blocklists or allowlists. The automation can be configured to update firewall rules and endpoint protections dynamically. The primary goal here could be to minimize the risk of malicious traffic and ensure only trusted applications run on your systems.
In each case, clearly articulate the 'why' behind these choices. Is it to reduce manual workload, increase the speed of response, improve the accuracy of threat detection, or maintain continuous monitoring? Understanding the rationale behind your use cases will guide your strategy in implementing these automated processes effectively.
