Doing Threat Intel the Hard Way - Part 4: Operationalizing Threat Intelligence

This is the fourth post in a series on manual IOC management for threat intelligence. See the previous posts:Part 1: <a href="https://www.anomali.com/blog/introduction-to-manual-ioc-management-for-threat-intelligence">Manual IOC Management</a> Part 2: <a href="https://www.anomali.com/blog/doing-threat-intel-the-hard-way-capturing-threat-intelligence">Capturing Threat Intelligence</a> Part 3: <a href="https://www.anomali.com/blog/doing-threat-intel-the-hard-way-processing-threat-intelligence">Processing Threat Intelligence</a><h2>Operationalizing Threat Intelligence</h2>Although a database of indicators and contextual information is useful, it is not enough. Once a storehouse of normalized, vetted, enriched information has been created, organizations must devise a means to use this information in some way. In order to confer real-time, let alone proactive benefit, the collected intelligence may be provided to some other security technology already in place. Most often, this is the SIEM or log management solution, but can include other technologies as well. For example, firewalls that support it could be given a list of IPs, domains or URLs that will be automatically blocked. Similarly, web proxies could be given web or domain information to do the same for user web traffic. IDS/IPS is another possible integration point, and some might opt to deliver MD5 or SHA hashes to endpoint protection solutions to enhance the lists of malware for which they monitor.After identifying the technology or technologies you wish to integrate, the normalized intelligence data must be extracted and forwarded to that destination. In order to do this, you will need to determine which fields are useful to each technology, create queries to retrieve that information, reformat it into something that technology will understand, and then create a mechanism to forward that to the device or devices involved. For example, if you are using ArcSight, you will need to send it in the CEF format. For each additional integration, you will need to repeat this process with another forwarder. Each of these forwarders need to be maintained over time.Once the information has arrived at its destination, you must create “content” that will take advantage of the information. In the case of firewalls, it could be as simple as creating a block list and writing a rule to reference it. In the case of SIEMs, it might include custom parsers, lists, rules, alerts, dashboards and reports. Each integration will require its own content be created. Just as with every other component in the process, this content must be maintained and updated over time.The final task in this stage is to automate the indicator import and expiration process. Indicator import is obvious, but expiration is equally important to avoid overloading the integrated technologies with lists that grow ever larger over time. Without automation, you will have to establish and manage a manual import and expiration process.Up next in the series: <a href="https://www.anomali.com/blog/doing-threat-intel-the-hard-way-part-5-analyze-threat-intelligence">Analyzing Threat Intelligence</a>