Skip to main content

Manual threat intelligence management: Doing it the hard way - Part 3

 This is the final post in a three-part series. 

Everything we have discussed to this point is meant to deliver the right information to your analysts. The intelligence still has to be analysed. An analyst workflow process must be created including incident escalation and response processes.

This workflow must provide a repeatable process to analyse the output of the integrations you have created in the previous steps. For example, if the SIEM determines that a server is communicating with a known botnet command and control domain, your analyst must be notified in some fashion (on screen prompt, email, SMS, IM, etc.). The analyst must then evaluate the collected information and decide if this is, in fact, happening, and then take appropriate action based on that decision. If the analyst determines that the notification is not correct, they should document their findings for future reference and move on to the next analysis. If the analyst verifies that the notification is correct, they should begin a formal set of incident response steps. 

In addition to providing analysts a workflow, you must also provide them with the tools they need to gather information on incidents they analyse. This is where enrichment of the sort discussed in the processing step can be useful. Analysts use sites like SHODAN, Web of Trust, VirusTotal and more to gather additional information about indicators they see. If these sources of information can be integrated into your threat intelligence management platform, you can remove the need to go seek it out manually and save precious time when making an escalation decision.

One final tool you may wish to provide to analysts is the ability to do indicator expansion in their research. This refers to looking at indicators that are in some way related to the indicators seen in the local environment, and doing a secondary search to see if any of those indicators have also been present. Many organisations struggle with this due to short retention periods of gathered log data. An analyst can only go as far back as the data he has to work with.

If a threat has been found inside the network, the next steps are to find additional details about it to determine, as best as possible, where the infection came from, how it happened, and when it happened.  Traditional incident response practice kicks in here to ensure the threat is isolated and remediation steps are handled accordingly.

Threat intelligence maintenance

So far in this series we have covered everything from defining the sources of external intelligence to collection, processing, and analysing threat intelligence. Now, once an analyst has made a decision, the output of that decision must be captured and stored, preferably within the system. Both, a ‘threat’ and ‘non threat’ need to be documented appropriately. If it was determined to be a threat, additional output could be to include notes, reports, recommendations or other documentation. It can also include additional information gathered about the indicators themselves. 

All this should be easily available for future reference. Indicators must be maintained over time as well. Some methods of incorporating new information about existing indicators while retaining the previous information is required. Although today, an IP may be actively engaged in brute force attacks, then next week it might get cleaned up and reimaged. That same IP might be clean for two years before getting compromised again and being put into service as a botnet Command &Control IP. Analysts need to be able to see these changes over time in order to avoid confusion in analysis. 

Additionally, if integration content, such as SIEM alert rules, is based on categories or other elements that change over time, automated monitoring may fail to detect new threats and may identify threats incorrectly. 


Threat intelligence can offer concrete benefits to organisations, making security analysts more efficient and effective, but only if that intelligence has been managed correctly. Poorly managed threat intelligence can lead to incorrect decisions that may have lasting consequences for the business or organisation. I have attempted to lay out the steps necessary to create a manual threat intelligence management process. 

As you can see, it is a complex undertaking, which may require a lot of resources. Some organisations have the necessary skill in-house to develop such a program. Many do not.  Given the level of effort required around developing and maintaining a manual threat intelligence program, even those capable of building their own may opt for a commercial threat intelligence management platform. 

There are a lot of moving parts and all require a level of diligence to be done appropriately. It is important that you do an honest assessment of your own organisation before starting a project to develop a manual threat intelligence management program.

Chris Black, Sr. Sales Engineer, Anomali
Image source: Shutterstock/deepadesigns

Chris Black, Anomali senior sales engineer, has 20+ years of technology and business experience. He crafts strategies that solve problems and drive revenue. His specialties include intrusion prevention systems, two-factor authentication, vulnerability assessment, IT Risk Management.