Thoughts on creating a Cyber Threat Intelligence Program from scratch
Disclaimer
I’m writing this blog to share my path and experience building a Threat Intelligence capability. All views, ideas, and thoughts expressed are my own and do not represent in any way the opinions of any entity whatsoever with which I have been, am now, or will be affiliated. This blog does not contain any sensitive information that can affect in any way my current or former employee.
TL;DR
Cyber Threat Intelligence (or CTI for short) is a process and as such, it can be reviewed, extended, and enhanced to meet the intel goals of the organization at the time it scales, evolves, and matures.
CTI is much more than just Indicators of Compromise (IoC); it is the systematic approach to implementing and operationalizing Threat Intelligence in the organization in a way we can understand who is trying to attack us.
Introduction
One of the goodness of being a Security Engineer, it’s the fact that you can wear multiple hats during your career.
Contrary to the common belief, you can excel at multiple laterals of Cybersecurity, regardless if you have experience or not; You need to enjoy the journey, start small and keep going. I’m not necessarily talking about becoming a Jack of all trades, you can certainly become in one, but you can also become a subject matter expert in one or many areas of Cybersecurity and you can do it well.
Fundamentally when you are facing a thought problem, your experience will speak for you, and all the learned lessons, mistakes, and opportunities that your young self experienced will pay off. I’m mentioning this statement as a motivation to keep you going and put into practice your past experience when challenged with novel problems.
Not long ago, I had the unique experience to help an organization create the building blocks for their Cybersecurity Threat Intelligence Program. Since this was a new initiative for the organization, there was a lot of freedom and research avenues to provide a proposal (and an execution roadmap) to the upper manager to meet their threat intelligence goals.
I love this approach because it gives you the opportunity to innovate, explore and learn, however, you need to be mindful not to fall into the proverbial Analysis Paralysis. That is, you need to understand the problem, look for avenues to address it, choose one or two alternatives, make a decision on one of them and give it a try.
In the past, I worked with Cyber Threat Intelligence and at least I had a general idea of what to bring to the table, I was very familiar with the CTI process, the tooling available, and how to operationalize it at the Big Data scale for Security Operations.
However, building such a program from scratch requires a lot of pragmatism, specifically if you need it to scale and start bringing value to the organization in the very short term. You also look for an incremental approach in which the program can mature at the time it helps the organization to proactively analyze threats.
I learned a lot during this process. Despite I had no previous experience in building such a program I believe what matters most is the approach you want to follow. Something important to bear in mind is that you need to understand the organization you are working for.
Every organization is different it is so cliché that it has to be true. Most likely you want to start asking some of these questions to understand where you are standing:
- Does the organization have a Security Operations function at all?
- Is there any Incident Response capability?
- Do they perform Threat Hunting?
- Do they have a Threat Intel role in place?
Those are just some of the questions to ask in order to understand the organization and how intelligence should be applied.
Regardless, always start small, you still need to keep looking at the forest (big picture) and make sure you are communicating effectively with the team and the manager so the work is aligned with the strategy and you are on track with deliverables and proof of concepts.
A key learning item during my path to building the CTI program was the fact that you need to identify who your stakeholders are; those are the folks that you will help to answer threat-related questions and you will be supporting them during risk assessments, incident response, forensic investigations, audits, threat modeling exercises, board meetings, etc.
As I will elaborate on later, sometimes you will find that your stakeholders don’t know what their threat intelligence goals are and what are their requirements. In those cases, you need to pair up with them and help them to define those. It is all about building trusting relationships with the stakeholders.
I had the first and foremost important question when I was starting the journey: Is there a Cyber Threat Intelligence framework/program already that I could use as a blueprint for my program?
Note that I was not trying to follow the buzzwords, I was essentially looking for a mature framework that allowed me to get some direction and tropicalize it accordingly to the needs of the current organization. In the end, you do not want to reinvent the wheel, do you?
Although every organization is different, having such guidance or structure helps a lot because you then can focus purely on the implementation (or operationalization). What I’m talking about here is more about adopting (and possibly tropicalizing a framework) that works for you and for the organization. If such a framework comes from a recognized body such as NIST, even better.
In my particular case, I could not find a mature framework to follow from beginning to end. This could be in part because CTI is a relatively new discipline, yet when done correctly, it brings a lot of value to the organization because, in the end, Threat Intelligence is a supportive discipline for other organizational units in the organization.
Regardless of the approach you are going to follow, it is important to understand who your audience is; that is who are your potential stakeholders and what problems are you trying to solve for them ( did I mention that Threat Intelligence is a supportive discipline?).
Types of Threat Intelligence
Generally speaking, there are predominantly three types of Cyber Threat Intelligence:
Understanding those types of intelligence is a key element of the Threat Intel Program because you need to make sure that objectives and goals are oriented to serve those areas and their respective intelligence requirements.
But who are they? — You might ask. Depending on the organization and its size, this could be multiple departments. For the sake of simplicity, let's focus on the general audience:
The success of your Threat Intelligence depends in part on understanding who your audience is and what are their needs ( what are the questions/goals they have that you can help them to answer).
The cycle of CTI
The Cyber Threat Intelligence cycle defines the phases for successfully building a Threat Intel program/function. For a good understanding of this cycle, I recommend you to watch the presentation from Katie Nickels called The Cycle of Cyber Threat Intelligence:
As an abstraction of this great presentation, we understand that the cycle of Cyber Threat Intelligence predominantly covers the following phases:
- Planning and Direction: This is by far the most important phase of the CTI process because it helps you to define the Intelligence Requirements (IR). If you have some background in Software Engineering you probably understand and appreciate well-defined requirements. If you have poorly defined requirements you cannot expect quality software because all the time, effort, and money are spent on building a piece of software that addresses a weak requirement. Same here, During this phase you need to work on defining the Intelligence Requirements for your audience (tactical, technical, operational). Let me highlight the importance of this phase: Essentially you want to make sure to get this done correctly from the requirements gathering phase because that will dictate the sources you subscribe to and the processing you need to do into that data to be able to answer your stakeholder’s questions. Remember though, that this is a cycle, you can later come and refine your requirements or even add new requirements to the process, just make sure to spend the required amount of time and effort to collect and document the right requirements.
- Collection: A collection management framework is a mechanism that helps analysts to visualize the multiple sources of intelligence (where the data is coming from). Such a framework is very relevant because once requirements are defined, you need to make sure you have the right data for answering those questions. The best way for this is to have a way to visualize it. This is in part true. In addition to the collection framework, you will also need other utilities such as surveys to capture feedback from your stakeholders and improve based on that feedback. Such a collection framework can be as simple as a spreadsheet or another visual tool. When it comes to data collection keep in mind that you do not necessarily need to rely on external data sources; there is huge value in internal data sources (this can be operationalized using a framework such as Lockheed Martin Killchain).
- Processing and Exploitation: This phase is about organizing collected data in buckets, using a restructured approach you can rely on a framework to be able to identify patterns. Such frameworks include MITRE ATT&CK Framework, Lockheed Martin Killchain, and Diamon Models among others.
- Analysis and Production: During the analysis process you need to be mindful of Confirmation Biases, in order to reduce these biases, Nickels recommends the following Structured Analytic Techniques (SATs):
- Devil’s advocated
- Brainstorming
- Red Team Analysis
A recommended approach for analyzing data is called Correlating Clusters (cluster together activities based either on threat actors, campaigns, intrusion sets, or activity groups). It appears that the Diamond Model of Intrusion Analysis is a good tool for cluster activity groups.
5. Dissemination: In the previous section we discussed the importance of knowing your audience, this is a key item to sharing intelligence. As we discussed earlier, different stakeholders have different needs, objectives, and intel requirements. You also need to understand what format your audience is expecting, this could be a finished intel report or a human-readable JSON format, or even a spreadsheet.
Can Threat Modelling help you during the Planning and Direction Phase?
Threat Modelling is a systematic approach to identifying threats and vulnerabilities within your organization. Adam Shostack defines Threat Modelling as “Threat Modelling is about using models to find security problems. Using a model means abstracting away a lot of details to provide a look at the bigger picture, rather than the code itself. You model because it enables you to find issues in things you haven’t built yet and because it enables you to find problems before it starts”.
It seems like multiple people have multiple definitions for Threat Modelling and sometimes use the concept erroneously. However, when done frequently, this mechanism becomes a first-class citizen for identifying threats. You can threat model a Web Service API, a Web Application, and even you can threat model an organization.
By taking advantage of the foundations of Threat Modelling, a Threat Intelligence Analyst can help the organization to define and refine its security requirements. I personally find Shostack’s four questions method very effective during the Threat Modelling process:
- What are you building?
- What can go wrong?
- What should you do about those things that can go wrong?
- Did you do a decent job of analysis?
Note that there are several approaches for Threat Modelling. When implementing an Asset-Centric approach, you create a list of the assets of the organization that you want to protect and then focus on the multiple ways a threat actor could threaten it. Once you identify those threats you can define mitigations around them.
The asset-Centric approach could help you to define your requirements by focusing on protecting your crown jewels. I personally follow Shostacks’s four questions approach when conducting threat modeling exercises; another value-added of learning how to perform threat modeling is that it will help you in your career and it will give you tools and guidance on how to think in terms of risks and threats for the organization you are working on and more importantly identify those risks before they occur.
An EASY Button Framework for building a Cyber Threat Intel Capability
The CTI cycle is a great framework to start with, it defines the different stages of CTI, yet it’s not prescriptive and it is possible that you will have questions on how to implement it in your organization.
As I continued to do research, I spent some time watching this great presentation from Chris Cochran called: The Threat Intelligence EASY Button. The presentation Chris gave on SANS DFIR definitely hit home for me.
The problems he described there were exactly the same I experienced and his approach to dealing with such issues and simply them definitely helped me during my program. Probably it is just a confirmation bias for me, but I feel very identified with Chris’s approach and the fact that past experiences are relevant and valuable when dealing with different sets of problems.
Here is the video from Chris’s presentation:
In summary, the EASY Button approach described by Cochrans is as follows:
- Elicit Requirements: Requirements start with the stakeholder. It’s necessary to spend time identifying who are those people and what they do and what intel requirements they need and their mission. It is all about building a relationship with those stakeholders. Sometimes stakeholders don't know what they need hence you need to spend time with them to build those requirements together.
- Assess Collection Point: Identify the collection points (internal or external sources) that help you to meet the requirements. Like when writing a software application, if you change your requirements it is more likely you need to change the collection sources. Cochran emphasizes the need to add metrics to your collection sources in such a way you can understand which sources add value to the program.
- Strive for Impact: Providing reports that are actionable and show value. Don't underestimate the power of metrics for helping you to understand if the outcomes you are providing are adding value to your stakeholders.
- Yield the Feedback: Be receptive to feedback. If for any reason the stakeholder provides criticism feedback about the information and outcomes you are providing then, it is probably time to rethink the approach and talk to them and find out what needs to be adjusted and move on. Keep it simple, as long as it is tailored you can get instant feedback.
This presentation is a testament to keeping things simple, it really helped me to clarify my thoughts and overengineering that I had put together.
Seeking for Perfection
One of the learned lessons for me was that I was putting too much effort into finding the perfect solution. I was sacrificing action by spending too much time on doing the right and structured plan, and elements. Nothing particularly wrong with this approach, but what you really want to have is to test out your approach as soon as possible and get feedback and criticism as early as possible.
Things can get improved in the future; nothing is ever perfect, use something that works for you and keep the ball rolling, capture feedback, and improve accordingly, that's the only way to grow and verify that your Threat Intel program is actually giving value to the organization and to your stakeholders.
Challenges I faced during the implementation of the Threat Intelligence Program
I have walked you through my mental model and the sort of resources I reviewed that helped me to build a program. I faced some challenges during the process and I would like to share them with you in the event that you have to deal with a similar situation.
- Determining the scope of the program: Identifying the scope of the program you are implementing is a must. I will recommend having a big picture planning and breakdown of activities accordingly to each phase. Keep in mind that you do not necessarily have to implement the stages of your program in order. In my particular case, I had to start providing insights into the business without having the program started, actually, it was in the early stages. Be pragmatic about the planning and make sure to add a way to measure your deliverables (collecting feedback from surveys or meetings).
- Understanding the organization: Your program needs to support other business areas to answer their intel requirements and goals. One of the challenges for me was to understand who those stakeholders were, what they have done, and how the program could help them to achieve their goals. You need to be aware that there is historic background on some processes within the organization and you’ll need to deal with it.
- Overengineering: This is an issue when you are a thought engineer. When you are working with something new where there is not too much guidance, keeping things simple is paramount. Overengineering arises when you cannot see clearly. Whenever possible, choose simplicity.
- Not asking for feedback earlier: As I was focused too much on execution, I realized I was not asking for feedback either from the stakeholders or other security engineers within the team. I was purely focused on my understanding of how CTI should work. This was not necessarily an issue but I learned a lot from the team when they challenged my biases.
- Not having a prescriptive guide for the Program: Let’s face it, things are smoother when you have a blueprint or structure to follow. Unfortunately, things are not always that easier. You need to struggle and feel uncomfortable. Since I did not have a clear guide for the program, I spent a lot of effort at the beginning on shaping the program and the respective planning. This is not particularly bad, I feel it was very much necessary but it was a challenge being able to abstract and provide some shape and guidance to the program.
- Challenge my biases: Bias is always going to be there, you need to pay attention to them and be mindful about them, utilize tools when you feel you might be oriented or have an affinity for a particular option available. Whenever possible, engage other security engineers and ask them for their input. You’ll be surprised by the rich this exercise is.
Conclusion
Implementing a Cyber Threat Intelligence capability within your organization is a must. As Cyberattacks become more sophisticated and organizations continue to get compromised, It is more clear than ever that we need to implement a proactive approach to understanding security threats targeting our organization.
Defining a Threat Intelligence Program allows you to understand the intelligence requirements of your stakeholders. It is more than just providing low-hanging fruit Indicators of Compromise (IoC); it is all about understanding what questions the organization aims to answer from the intel perspective, and what are their objectives and requirements in a way that you can make an informed decision on what data sources (either internal or external) you have to use to be able to provide that clarity to your team.
CTI is a process and as such, it can be implemented and adapted to your organization, don’t look for perfection, look for effectiveness. Be agile, start small and be pragmatic in identifying the intelligence requirements for your organization.
Lastly, add feedback loops as needed to help you to understand the effectiveness of your outputs. Accept critical feedback with humility, correct it, and move forward. Remember that CTI is a supportive discipline that can grow with trust with your stakeholders.
References
Here are the sources I followed not only to write this article but to succeed in my Threat Intelligence Program.
