So you're thinking about starting a cyber threat intelligence team...

What is cyber threat intelligence (CTI)?

CTI is analyzed information about adversaries that informs cybersecurity decision-making. Simply stated, it’s about understanding cyber threats and using that knowledge to make better decisions. There are many misconceptions about CTI out there, including that it’s all about ingesting feeds of indicators or identifying state-sponsored adversaries. While those can be part of CTI, it is a broader field than any specific tool or data source.

When discussing the vast field of CTI, it can be helpful to break it down into three levels based on the audience: strategic, operational, and tactical. This graphic from a whitepaper by Sergio Caltagirone explains each of these levels.

These levels can help teams think about their audience for CTI, which informs other plans for starting a team. These levels seem straightforward at first glance, but in reality there’s a lot of overlap between them. As you’re thinking through what level your team falls under, focus on the high-level goals, and don’t get too hung up on whether your audience is exactly at a certain level.

The Red Canary Intelligence Team started out of the Detection Engineering Team, which develops detection logic, discovers threats, and shares those with customers. Detection engineering naturally has a tactical focus: they seek to identify suspicious and malicious behaviors that might mean there are adversaries in a network. As the Intelligence Team formed, however, we realized that we should focus more operationally rather than just looking at tactical behaviors. We wanted to zoom out and look at how tactical day-to-day detections and threat behaviors connected, which would let us better inform internal and external stakeholders about how they should respond to threats. For us, it made the most sense to focus at the operational level, while also realizing our insights could be used at the tactical and strategic levels as well.

Understand your requirements

The best place to start if you think you may want to create a CTI team is to think about why you want the team and what you want it to do. There are many ways to use CTI to help your organization, so it’s important to understand why CTI matters for your specific operation. This will allow you to hire the right people and begin setting up the right processes for your specific needs.

Some common reasons why organizations choose to create CTI teams include:

• You’ve had a major intrusion and want to protect against another in the future.
• You have lots of questions about threat reporting in the news and need a team to contextualize and address what is relevant.
• Your security operations center (SOC) is struggling to keep up with and prioritize alerts from tools.
• You’ve heard from other teams that CTI teams can be useful.
• You want to better understand the threat landscape so that you can prioritize the threats that are most likely to affect your organization.

A high-level sense of why you want a CTI team is helpful, along with the audience level (strategic, operational, or tactical). Building on that foundation, organizations should create specific requirements they want the CTI team to address. Requirements are any problems or needs that can be addressed with CTI, often best expressed in the form of questions. A great source for building requirements is the audience who plans to consume CTI. Oftentimes, the CTI team will have the most success in developing requirements by having a back-and-forth dialogue with potential consumers, since many of them aren’t familiar with how CTI could help or what they should ask for.

Here are some sample requirements a team might start with for various audiences:

• Tactical: What behavioral analytics can we write to best identify malicious activity?
• Operational: What threat groups are likely to target our organization?
• Strategic: What is the risk of acquiring a new company based in a certain country?

Requirements vary by team. They are important because they give a new CTI team the foundation upon which to build. They help the team focus on what the organization needs and ensure the team is more likely to provide actionable output. A common challenge new CTI teams have is that they fail to start with requirements, and as a result, they produce reports that become “shelfware” and lack utility. Starting with requirements is the best way to ensure you make a solid investment in a CTI team.

Once you develop the requirements for what you want the CTI team to focus on, you may realize you don’t even need a separate CTI team. Your existing security tools or services may provide what you need to satisfy your requirements. You may also find that a SOC or threat hunting team could perform this. You don’t need to have a formal CTI team to practice CTI. For many years, that’s the approach we took at Red Canary. Our detection engineers and incident handlers practiced CTI long before we formed a formal intelligence team. As we formed the team, we thought about who our key consumers were and divided them into three categories: Canaries (our own employees, such as detection engineers), customers, and the broader infosec community. Creating these categories helped us realize that we have different types of consumers who have different needs.

For example, a requirement for our detection engineers asks: “What new threat behaviors are adversaries using that we should try to detect?” Our customers, on the other hand, have a collective requirement to know “what might happen after this malware is present on a machine and how should I respond?” We also want to help the broader community, so we levied the requirement upon ourselves to ask “what new activity clusters are in the wild that haven’t been shared?” When creating requirements, we found it helpful to start more broadly by thinking about our consumers and team mission, and then broke those ideas down into more granular requirements we could satisfy.

Your existing security tools or services may provide what you need to satisfy your requirements; you don’t need to have a formal CTI team to practice CTI.

Start with people

Once you have decided upon some initial requirements for the CTI team, you will likely realize that you need to hire people. CTI analysts come from a range of backgrounds, and do not necessarily need computer science degrees, though some level of cybersecurity knowledge is helpful. Look for candidates with a range of experiences, from former journalists to systems administrators. Another good way to create a CTI team is to bring together existing SOC analysts or other cybersecurity personnel from your organization who are interested in understanding threats.

This breakdown from INSA lists some common skill sets and traits to look for when hiring CTI analysts.

Our team started with former detection engineers who had a knack for digging into threats, and we soon added a new team member with a background in threat hunting. As we build our team, we look to add different skill sets and strengths with each hire. Diversity of thought is particularly important in intelligence teams because it lets us challenge each others’ thinking and hedge against cognitive biases like groupthink. Our team divides our positions into intelligence analysts, malware analysts, and intelligence engineers to best align to individual skill sets and focus areas. We have team members from many different backgrounds, including a former system administrator and a former professional dancer!

Acquire data

Once you have requirements and people, you will need some type of data sources to help you produce intelligence. When the CTI team considers the data they will use, consider the requirements they need to meet.

While teams often focus on external data sources, internal data from your organization can be one of the most valuable sources to use for CTI purposes. Endpoint or network data, malware analysis, SOC alerts, or other internal sources can help a CTI team focus on the threats an organization is facing, especially if external sources become overwhelming.

For many CTI teams, as they expand to external sources, it makes sense to start with open source data because there are a wealth of sources available. Once the team finds that they cannot mature without more data, that’s a good time to evaluate additional sources such as commercial intelligence services or feeds.

Some common open sources for CTI teams to start with might include:

• online sandboxes like VirusTotal and any.run (free and paid versions are often available)
• Abuse.ch
• Twitter/TweetDeck (focusing on hashtags of groups and malware of interest)
• RSS feeds of cybersecurity blogs and sources

Depending on the team’s requirements, other sources or collection methods (such as searching data on the dark web) may be helpful. Information sharing with other teams, either formally or informally, can also be a good source of data. For example, some CTI teams choose to join organizations like Information Sharing and Analysis Centers (ISAC). Information sharing can add value and expand the data collection a CTI team has, but it can also pose challenges because most information sharing groups expect two-way sharing. If a CTI team is just starting, they may not have much information to share. Joining formal information sharing groups (with expectations of sharing back) may be something to consider after a CTI team has already shown value within their own organization.

As our team matured, we intentionally chose to focus on internal data from detections we observed. We focused on determining what threats were present in those detections, because doing so helped us figure out what might happen next so we could advise on responding (going back to our initial requirements). For example, over the past year, we’ve focused heavily on identifying ransomware precursors, including malware families like Qbot, Bazar, and many others. By identifying ransomware precursors, we are able to advise customers to take quick action before ransomware is deployed. We’ve found that open sources like those listed above have been very helpful for us to identify those malware families.

To help us meet the requirement of identifying new threat behaviors happening in the wild, we’ve found monitoring threat researchers on Twitter and new publications from security teams have been useful collection sources (and of course, listening to our own Threat Research team!).

Use appropriate tools

The team will need tools to assist their analysis. Starting with the team’s requirements is a good way to select tools, and you should also examine what tools your organization already has that could help CTI analysts. For example, some security information and event management (SIEM) tools may have the ability to track information of interest to CTI analysts. A common mistake organizations make is to buy a CTI tool before determining what the team should be doing or what they need out of a tool. Buying a tool for a newly formed team is a risk because it may not meet the needs or help the team accomplish its work. Too many teams have purchased expensive tools that they intend to use but do not actually need.

One common tool CTI teams use include threat intelligence platforms (TIP). Open source TIPs like MISP are available as well as a range of commercial options. Many CTI teams also use link analysis tools to help visualize data and find patterns. Many tools have link analysis visualizations built in, or tools like Maltego can provide this functionality.

However, one of the most common tools used by nearly every CTI team is spreadsheets. For a CTI team that is just starting out, a TIP or link analysis tool may be unnecessary, so using simple spreadsheets is a good starting point. At the point when a team has too much data to manage, that’s a good time to consider acquiring another tool.

Like so many teams, the Red Canary Intelligence Team started by using spreadsheets. Of course, spreadsheets do have limitations, which is why we’re currently evaluating other options for storing and querying data. We’ve also used our own Red Canary security operations platform (where a wealth of threat data is stored) during our analysis. Each team is different, but for us, it made more sense to use a tool we already had rather than try to stand up an entirely new tool before we were sure what analysis we wanted it to perform.

One of the most common tools used by nearly every CTI team is spreadsheets.

Establish products

Now that you have requirements, people, data, and tools, your CTI team has to actually conduct analysis and produce something! As with other parts of the team, it’s key to base production on your requirements and consumers.

Some common products a CTI team might produce include:

• short “situational awareness” summaries about threats or incidents
• long-form reports about threats
• malware analysis reports
• signatures, indicators, or behavioral analytics for defenders
• prioritized list of threats or alerts for defenders to focus on
• requests or recommendations for action
• presentations

The same intelligence analysis your team performs might be used to create different products. For example, our team decided that one of our key products is Intelligence Profiles that are available in our security operations platform to customers. These profiles provide detailed information about malware and group behaviors, as well as how we detect them. We carefully tailored the format of these profiles based on our requirements—including identifying where we have detection gaps based on threats we track. We take the same analysis used to produce those profiles and use them for other outputs we share regularly with the community, such as blog posts, tweets, and our Threat Detection Report. As we investigate threats, we also identify new ideas for how we could detect them, which we send to our Detection Engineering team so we can collaboratively create new detection analytics.

While products will vary by organization, focusing on the consumers’ needs will help a team ensure their products are useful. Once you start creating products, make sure to regularly ask your consumers for feedback on what they like and don’t like about your products—this will let you adjust and/or create new products as needed.