XSOAR + Threat Intelligence

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Announcements

XSOAR + Threat Intelligence

L0 Member

Hi, All!

 

I am working on integrating more threat intelligence into our XSOAR platform. Our latest efforts have been integrating other free sources of IOCs (AlienVault, Abuse.ch, etc...) and then we are going to work that into playbooks to create logic based off of the new IOCs we are bringing in. For example, if an event is created where it shows an IP that might be malicious, a few of our integrations might look up this IP, find that it is not malicious and then auto close the incident. Short example.

 

But I am very curious as to what others are doing! I am new to this and want to be as effective as possible to the least amount of money as possible.

P.S. - I am not referring to implementing Palo Alto's Threat Intelligence platform that integrates with XSOAR. That is a separate product.

 

2 REPLIES 2

L0 Member

I do not know the whole setup that you use, but based on your example, I would not recommend such an approach. There might be cases in which IOC is known to only one TI source. Besides, there should be more to look at in such an event besides the presence of an IOC. Better leave decision-making for analysts.

L1 Bithead
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:
  1. 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.
  2. 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.
  • 1229 Views
  • 2 replies
  • 0 Likes
Like what you see?

Show your appreciation!

Click Like if a post is helpful to you or if you just want to show your support.

Click Accept as Solution to acknowledge that the answer to your question has been provided.

The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!

These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!

The LIVEcommunity thanks you for your participation!