Security Experts:

CISO Perspective: Process is Key to Your Threat Intelligence Program

Continuing our examination of the cyber threat intelligence mind map, we move from the different levels of threat intel (Strategic, Operational, Tactical) and how that all ties in with managing your digital risk to what I consider to be a glue-like component - process.

Process isn’t something you can buy from a vendor (although there are plenty of vendors who will try to sell you on why their process is great). It’s not a technology. It’s how you go about leveraging all of your tools and data in the most effective way possible to achieve your desired outcome.

Threat Intelligence ProcessWhen it comes to threat intelligence, having a sound process is critical. When thinking about intelligence, before you buy a data feed, platform, service, etc. you should have a defined process in place that supports a defined strategy. This should cover what it is you are aiming to gain from the threat intelligence, what areas you want to monitor and collect data against, who will be responsible for analyzing the data and producing usable intel, how that will be communicated to the right stakeholders and how that intel should ultimately be used. There should be a continuous loop where users and consumers of that intel deliver important inputs back into the collection and analysis process.

My company uses the following process:

Define/establish your plan - The first thing to determine is your goals - especially with your key stakeholders. For example, who are the decision makers (anyone who decides a course of action for their area of responsibility)? Has the decision maker’s intent been defined? What concerns do they have and where is there a lack of insight? What are key risk areas for your business? All of these items are used to create your cyber risk profile and once you have your higher-level strategy and goals defined, then you must determine what types of data you want to collect.

Threat data collection - Once you’ve defined your goals, risks, etc. you now have a target in terms of data collection and this is the step where that data collection occurs.  What are your threat intelligence data sources? Internal? External? OSINT? Dark Web? What’s the quality of the data source? How accurate/reliable is it? How relevant is the threat intel data to the decision makers? One common pitfall with data collection is that having lots of data doesn’t mean it’s good. You also should not focus on one area alone - there is valuable and relevant data across many different sources.  

Analysis - How many vendors boast about having the largest database of malware hashes, threats, IOCs, etc.? There’s tons of data out there and while yes it’s important to be comprehensive, getting data is not the tough part… the tough part is sifting through all of that data to find the gold. Of those millions upon millions of records, what’s important to you based on your environment, your risk areas, the threat itself and its potential impact on your business?

Both automated and human analysis is necessary. Automation can help filter out the irrelevant data and ultimately create a more manageable workload for human analysis. At SurfWatch, we evaluate our intel using a combination of automation and human analysis. Automation is used to both vet the accuracy of the event data itself (did the cyber event actually occur) and it’s relevance to a customer before it is passed onto a human analyst to continue the evaluation process and produce something “finished”.

Alerting and Reporting - Now alerting can be a dirty word in cybersecurity because as a former practitioner, I have experienced the deluge of alerts that can basically have you running around like a chicken with its head cut off. Everyone does alerting, but what’s the accuracy level of that notification? How valuable and necessary is each alert? Are there things that you should’ve been notified about that fell through the cracks? A major part of intel work is communicating the findings as quickly as possible to the right people in the right format - so that they can quickly consume it and take the best course of action.

In our world, alerts are quick-hitting pieces of relevant intel while reports are more in-depth - for example an Actor Profile that examines a malicious actor, their motivations, their target history, their tactics, techniques and procedures, IOCs, Malware families and some course of action recommendations or as I like to call them “go-do’s”.

Continuous Risk Monitoring - Another important aspect of an intelligence process is that intel is not static… things always change. New risks, new threats, new targets, and so on. Having a function/capability that is continuously looking at the threat environment based on your company risk profile (which also should evolve over time) is critical to ensure things aren’t missed.

How this all loops together is that when valuable intelligence is created and communicated to a customer, the customer must have a process to consume the intel and take action. For example, is there intel that can feed into an ongoing incident or breach response process? What investments or changes to resources need to be made based on intelligence provided to the executive team and potentially even to the board? Do you know what your fraud footprint looks like in various underground sources? When fraud is found do you have a process to react to the finding?

In simple terms, I typically look at cyber threat intelligence process in two ways:

1. The process used to generate intelligence

2. The process used to consume intelligence

In many cases organizations jump into #1 without thinking through what to do for #2 and thus the intel is overwhelming or underwhelming and generally a burden to the team because it is not serving an immediate purpose even though you are applying resource cycles to it. If you are in the process of building out an intel program, I recommend you place emphasis on #2 - the process used to consume intelligence. This way whether you are producing it in house or have it outsourced to a vendor you are applying initial focus on consuming it and making it usable for the organization, which is the ultimate goal.

view counter
Adam Meyer is Chief Security Strategist at SurfWatch Labs. He has served in leadership positions in the defense, technology, and critical infrastructure sectors for more than 15 years. Prior to joining SurfWatch Labs, he was CISO for the Washington Metropolitan Area Transit Authority. He formerly served as the Director of Information Assurance and Command IA Program Manager for the Naval Air Warfare Center, Naval Air Systems Command one of the Navy's premier engineering and acquisition commands. Mr. Meyer holds undergraduate and graduate degrees from American Military University and Capitol College.