Playbook of the Week: Automating EDL Management

When a Typo Cripples a Company

A few years back when I was doing professional services at a financial company, I talked with one of the security operations center (SOC) analysts about one of the worst days in their career.

It started with a mundane phishing investigation that led to the blocking of a domain. Due to a typo, instead of blocking {}.com, the analyst added {}*.com to the EDL blocklist, and the organization was crippled for a few hours until the root cause of the issue was discovered.

This is a case where automating such a task could have prevented this simple case of human error.

What is an EDL?

An EDL (External Dynamic List) is a text file hosted on an external web server so multiple security products across your organization, including firewalls, EDRs, SIEMs, threat intel platforms (TIPs), can import objects such as IP addresses, URLs, domains to be included in the list for policy enforcement.

In order to save time and effort, security teams use EDLs to manage their firewall allow and block lists. As the security teams modify the block lists, the security products dynamically import the list to enforce a policy without the need to make a configuration change. This is less invasive than manually pushing policy change to firewalls and it also enables automatic blocking of malicious traffic.

Cortex XSOAR & EDLs

As customers transition their security operations to Cortex XSOAR, and use it to manage all their security incidents from one location, there is also a consolidation of indicators of compromise (IOCs) from various sources within XSOAR. As of XSOAR 5.5, the platform allows the hosting of specific files that automatically consolidate these indicators within XSOAR, eliminating the need for maintaining a text file on a dedicated web server.

The playbooks profiled in this Playbook of the Week are part of the Generic Export Indicators Service pack, which was created to automate the distribution of indicators from XSOAR to enforcement points in the network. With this pack, users can generate a list based on their threat intel library, and export it to any enforcement point in their network, such as their firewalls, EDRs or SIEMs. Additionally, the pack includes safeguards to prevent incorrect insertions of domains, like the typo mentioned above.

This pack not only provides a simple, automated process to modify and update EDLs within XSOAR, it can also replace existing manual processes for updating firewall allow lists and block lists. By doing so, analysts may make these changes directly in XSOAR by simply adding or removing indicators from the EDL.

In turn, customers can auto digest and update their allow and block lists, and distribute it across all of their security products, with XSOAR acting as a single source of truth for EDL maintenance.

Best Practices for Managing EDLs within XSOAR

In order to create the automated EDL flow within Cortex XSOAR, we recommend the following steps:

1. Before implementing the playbook, ask yourself the following questions:
   1. Which systems do I want to push IOCs to?
   2. What are my sources? Are they threat feeds, manual IOCs, or text files?
   3. Should the lists be distributed by region, by severity, by IOC type?
   4. How often do I want to update my lists?
   5. Will the lists be updated on a preset cadence or on-demand only?
2. Install the Generic Export Indicators Service pack from the Marketplace.

1. Subscribe to the pack (from version 6.8)
2. Ingest indicators to XSOAR from:
   1. Feeds
   2. Investigations
   3. Files
   4. Manually
3. Tag indicators to create allow and block lists. You can tag them manually from the indicators page, by adding tags at the feed configuration level, or by using the Indicator Auto-Processing pack.

1. Create different instances of the Generic Export Indicators Service integration for different lists (by tag) in order to manage your EDLs effectively.

1. Use the EDLs in security products to enforce policies.( e.g, use a blocklist EDL as a destination in a security rule in your NGFW firewall that is designated to block traffic.)
2. Validate that the EDL changes that you made in XSOAR affects your security policies. As an example, for a PAN-OS firewall policy, you can test it via XSOAR to see if it matches a security policy.

1. Use safeguards to prevent incorrect insertions of domains
   1. Maximum CIDR network prefix bits size - “I missed a 1, typed 204.63.64.0/8 instead of 204.63.64.0/18 and can now only talk with 127.0.0.1”
   2. Exclude top level domainGlobs - “I created a {}*.com instead of {}.com and now all of the traffic is blocked”
2. Have a fail-check mechanism. For example, run a recurring job that tests the network access to your organization's most critical assets, e.g, the main exchange server. If you cannot access these assets, it is a business critical alert, as you will not be able to conduct your day-to-day business activities.
3. Commit to the process. Do not create alternative security policies that override the EDL you have configured or that bypass the process. Enforce the discipline of using XSOAR as a single source of truth for managing your EDLs.

For more information on the Generic Export Indicators Service Pack and other XSOAR packs and playbooks, visit our Cortex XSOAR Developer Docs reference page.

Don’t have Cortex XSOAR? Download our free Community Edition today to test out this playbook and hundreds more automations for common use cases you deal with daily in your security operations or SOC.