Blocklist in Sekoia
On a calm Friday afternoon, rumors of a new active threat starts hitting the vario 2024-12-3 18:46:39 Author: blog.sekoia.io(查看原文) 阅读量:14 收藏

On a calm Friday afternoon, rumors of a new active threat starts hitting the various social network websites. Your CSIRT team starts checking the private channels they have with other CERTs and starts compiling a list of Indicators of Compromise (IoCs). After careful consideration, they decided to block all communications with these IoCs on the company’s firewalls. However the network administrator is off, enjoying an early week-end with his family.

Your security analysts might also be providing IoCs, through their investigation of alerts or incidents: they can come across specific technical artifacts such as IP addresses, domain names or URLs that characterize the presence of a threat to your information system. After proper qualification, these artifacts could become IoCs and could be leveraged proactively in security solutions to enhance detection and/or prevention.

Minemeld would have been my top choice to implement a blocklist in a centralized tool and distribute easily the content to third party solutions, but it has been announced as end of life by Palo Alto in 2021 and the public repository has been archived in 2023.

Let’s see how we can implement a blocklist using the Sekoia SOC platform capabilities!

Using Sekoia’s IOC Collections as blocklists

Using Sekoia IoC Collections as blocklists

In the Sekoia SOC platform, custom IoCs can be stored in IoC Collections: they are defined in STIX format, linked to threats and possess validity dates allowing analysts to provide context around the IoCs and reduce the risk of false positives.

A security analyst can create a detection rule to detect these IoCs in the events collected in the Sekoia SOC platform, perform threat hunting through the telemetry reports or automatically: Sekoia.io’s solution includes an automatic retro hunt engine searching through all the events stored in the platform for any new indicator added to an IoC Collection.

This centralized storage of IoCs is also key to ease lives of security analysts, network engineers and system administrators for proactively blocking threats as the Sekoia SOC platform allows to disseminate the blocklist content into various third-party solutions. Using the validity dates and revocation features of IOC Collections, security analysts can also easily extend the retention period of an IoC in a blocklist or remove them from the blocklist.

IoCs shared by another CERT

Sekoia’s recommendation is to create one IOC Collection per IOC type that will be disseminated to third party solutions, to ease the integration in these tools and the maintainability of the IOC collections.

Finally, security analysts can enrich and grow IOC Collections quickly from Alerts using the pre-built playbook templates available in the Sekoia SOC platform.

Add Destination IP address to IoC collection

Implementing the blocklist in a network firewall

The easiest option to perform automatic blocking of IP addresses on network firewalls is to use the native firewall capabilities to retrieve external lists. Depending on the vendor, the functionality can take various names : External Dynamic List (Palo Alto), Custom Intelligence Feed (CheckPoint), External Block List (Fortinet)…

The IoC Collection content can be retrieved in various formats to meet the network firewalls specifications: our public documentation describes how an IoC Collection can be retrieved.

Implementing the blocklist in third party solutions using playbook actions

The Sekoia SOC platform also comes with a native SOAR engine, allowing security analysts to launch automations manually or automatically on Alerts or Incidents, without having to switch to another solution or interface.

These automation features can also be used to retrieve the IoCs in the IoC Collection and push them to various security solutions such as EDR (CrowdStrike, SentinelOne, …) or SWG solutions (Zscaler).

Some of these solutions allow to define expiration dates on imported indicators – others do not, which can lead to some difficulties in maintaining the list of indicators. When the appropriate API endpoints are available, specific calls to these APIs were implemented in the automation action code to remove expired indicators from the third party solutions. You can check the code of our automation actions in our public Github repository.

Wrapping it up

Automating blocklist implementation across various security solutions is a great way to save time it takes for security analysts, network engineers and system administrators to put protective measures in place when facing a threat.

The native capabilities of the Sekoia SOC Platform allow you to implement this automated process without having to rely on an intermediary solution.

Share this post:


文章来源: https://blog.sekoia.io/blocklist-in-sekoia/
如有侵权请联系:admin#unsafe.sh