So far, we have covered ground on the cybersecurity landscape, identified what cyber threat intelligence actually is, and introduced some of the core concepts for conducting CTI and the approaches behind it. So you may feel more confident about the core understanding of what you want or need to do to get started or develop your capability, but now you need to figure out how you’re going to do that with whatever (possibly nonexistent) budget you have available, right?
The good news is that a lot of the concepts we’ve covered so far don’t need much money thrown at them for you to adopt them, or to bring them into your business as usual (BAU) workflows, so hooray for that! When it comes to frameworks, standards, and analytical approaches, all of this can be used and adopted for free, which in the world of cyber, I think we can all agree that’s a rare treat. No sales pitches on this one, hurrah!
However, with all things considered, you will need some sort of budget to stand up an intelligence function. It doesn’t have to be grandiose and fully fledged end to end at this point, particularly if you’re only starting out on this particular journey. Let’s start with the basics. You need an analyst (or analysts), and you need to identify what your business actually wants from its intelligence team. And here my new intelligence-loving friend is where this magical idea of formal intelligence requirements come in!
Now, you may be reading this and thinking “My intelligence requirements are to provide context on cyber threats,” and you would be correct of course, but this field is so broad and every organization is unique. Therefore, having a formalized process for developing intelligence requirements should be a fundamental part of your intelligence journey. Suppose we recall the intelligence cycle that we briefly touched on from Chapter 2. In that case, the planning and direction phase of the cycle dictates that you receive a requirement/question/request for intelligence on a specific topic. It is the team’s job to figure out how to collect the relevant information, process it, analyze it, provide the appropriate reporting back, and then solicit feedback (as per the intelligence cycle). While this sounds straightforward, there is a common argument in cybersecurity circles around who the CTI team’s key stakeholders are.
On the one hand, you might think the SOC or collective security teams are the main customers, and therefore they trump everyone else. But in a large organization, with different products, services, and various geographical operations, you’ll likely find your remit for customers is a lot bigger than just security staff. Of course, if you’re a Managed Security Service Provider (MSSP) or small organization, maybe it’s the security team and the CEO who you report into, and that’s about it. As I’ve said a lot, each organization is different, and thus hammering out your intelligence requirements in a formalized process is the first step to ensuring that you’re aiding the business in what it truly cares about and that you’re not creating products that people won’t use – the absolute bain of any intelligence team.
It’s this last point I should expand on. It’s one of the biggest problems for pretty much every intelligence producing team in pretty much any organization – soliciting feedback from consumers of their reporting. As mentioned within the intelligence cycle, the final stage is getting feedback from customers and then using that to fine-tune, adjust, or drop the previous line of reporting. In a world where we’re all busy, all the time, it’s challenging to find the time to get this from people every time you issue a report. While that is understandable to a degree, if you can overcome this obstacle and ensure your customers are giving you the feedback on products you need (such as if it’s helpful, if they want more/less of a particular type of report, if they have questions you can help answer, if they don’t find it actionable or need different information, etc.), you are going to find yourself further ahead on the journey for a mature intelligence function than the vast majority of teams out there.
As someone fortunate enough to see the world of intelligence across pretty much all spectrums in the UK, I feel I have a reasonably unique insight on this subject than the majority. Still, the problems exist in every single realm of intelligence across the entire globe, and I’m pretty confident about that. I do, however, think that this isn’t the absolute disaster it may sound like. I believe this is one instance where you can create some bureaucracy for good. I know, it astounds me too. I urge you to hear me out on this.
I hope you’re seeing the value of having formal requirements, so let’s see how we can create some formal policy/bureaucracy/red tape (however you like to think of it!) and use it as a force for good for your new intelligence team.
Who Are Your Customers?
Who you’re creating reporting for might seem obvious, but believe me, it’s probably not as simple as you think. Depending on your business, its products, and the range of different operations you have, you could find that the CTI team can benefit a wide raft of teams and business units and establish relationships to aid investigations from a cyber perspective. For example, your organization may have a flagship product that has millions of customers; also, you may have two or three different product offerings that compete in different markets or industries.
An excellent example of this is Sky in the UK. Sky operates the largest TV broadcasting service in Europe but also has telephone, Internet, mobile, and streaming services within its product range. That’s a lot of verticals that don’t necessarily mesh together in a one-size-fits-all approach, and has a large number of different moving parts and business areas that could/should require intelligence support (from a cyber perspective – think exploited vulnerabilities, campaigns targeting similar organizations, etc.). Whereas if your company is small and only has one product, you’re going to have a much easier time identifying who’s who and what you can provide them.
Likely Collection of Data Types Required by Different Customer Set
Team | Data Types |
|---|---|
Security operations center (SOC) | Reporting, IOCs, TTPs, Courses of Action (CoA) |
Threat hunting | IOCs, TTPs, Yara rules, detection signatures |
CISO | Reporting |
Threat and vulnerability management | Reporting, Common Vulnerabilities and Exposures (CVEs), CoAs |
Executives (CEO et al.) | Reporting |
Broader security team | Reporting |
Fraud | Reporting, indicators |
Product owners (e.g., different products your business sells) | Reporting, CVEs, CoAs |
Wider staff | Awareness reporting |
Table 4-1 isn’t intended as a comprehensive list but should help give you an idea on the range of different customers you might have and the types of data they likely want to consume from you and your team.
When formalizing your intelligence requirements, you must identify all the stakeholders you think need to or want to consume your products and then identify their needs. The best way to do this is to schedule regular (every quarter or 6 months) meetings with those stakeholders to initially gather their requirements and subsequently review how you are meeting them and tweaking to suit. From this point, you’ll collate all the information across all your stakeholders together to help you form your organizational priorities. It’s up to you how to track this, but you might find a spreadsheet useful that can allow you to build formulas and add weighting and build graphs from.
Once you have all the requirements from across your stakeholders, and you’ve weighted them across the business, you should be able to see your organization’s top requirements. From a cyber perspective, these will probably cover things like ransomware, APT activity, zero-day vulnerabilities, and attacks against technology you have in place. Still, you might be surprised at the range and responses. Doing it this way also allows you to ensure that if your customers ask why you’re not doing something, you can establish that it isn’t a priority for the business, based on the collective feedback. For a head start on working toward this goal, the intelligence vendor Intel4711 publishes for free its General Intelligence Requirements (GIR) handbook, which I recommend as a starting point; it’s comprehensive and can help you to gain momentum with this process. Quite helpfully, it isn’t tied into you having to use their services either, so a win-win if you’re particularly budget-conscious or don’t have the requirement for that kind of service just yet.
So with the requirements process understood and moving forward, I think it’s also worth bearing in mind at this stage that there’s a range of different report types within intelligence and that different customers might need different types of reporting, so let’s break that down a little bit within the next section.
Intelligence Reporting
Tactical
Operational
Strategic
Others (Yes, I’m using a get out of jail free card here. Trust me, we will come back to this.)
Tactical Intelligence
You may be hugely surprised to discover that tactical intelligence reporting is aimed at providing contextual and actionable information to its consumers at the tactical level. According to INSA2 (Intelligence and National Security Alliance), tactical intelligence is focused on the strengths and vulnerabilities of an organization’s network defense and the TTPs adopted by adversaries.
In real terms, this means that you’re providing teams like SOC and threat hunting with reporting relating to threats that your organization should worry about. You’ll provide IOCs, TTPs, and remediation advice, as well as high-level overviews of the threat and the risk to the business. Some of this information can be provided in an automated fashion, such as through the ingestion and sharing of threat feeds or automated malware analysis. Traditionally, this kind of report will be shared with the SOC and relevant security teams.
Tactical intelligence is about the short-term, here–and-now moments you face daily. The content can be highly technical depending on the data available and often involves sharing IOCs across systems such as IDS/IPS, firewalls, and SIEM systems. It’s the CTI team’s job to ensure that the data being shared with those systems is timely and relevant to the organization. As this is an approach that can be fairly easy to set up, but incredibly difficult to master, regular evaluation of sources and data from automated feed sharing is definitely recommended.
Reporting from tactical intelligence will often contain details about malware, what it does, and the indicators and TTPs to look for. By its nature though, it is unlikely to be overly detailed, as it’s typically produced in response to an event or incident.
Operational Intelligence
Operational intelligence is the next step up from tactical intelligence. These reports usually take a long-form approach and include detailed breakdowns of particular threats (specific malware, campaigns, threat actors, incidents, etc.). Of course, there are overlaps between tactical and operational reporting. Often, a tactical report may be followed up by an operational one once more information is available, and context can be fully derived.
Operational reports will usually be shared with specific audiences, such as the SOC, threat hunting, and vulnerability management. They will be more detailed than tactical reports and should offer more detailed insight into their subject matter. For example, an initial tactical report may include some IOCs and initial TTPs for a specific incident and then be followed up by an operational report that looks at other campaigns using the same TTPs, how this has evolved over a defined period of time, and the risks to the business as a result. It will usually end with a series of recommendations for the recipient to action. This may include deploying detection or Yara rules, ensuring vulnerabilities are patched and scanning for particular network activity, such as the creation of registry keys or unusual access requests/patterns.
The goal of the operational report is to give a more detailed and rounded view of a specific threat that can enable the organization to respond appropriately and swiftly in full view of the facts.
Strategic Intelligence
Unfortunately, there are no prizes for guessing this one. Strategic intelligence is designed to take a broader, more holistic view of the overall landscape and provide contextualized intelligence as a result. It is usually aimed at more senior readers within the organization.
Strategic reports can cover a wide variety of topics, but usually things like broad threats (phishing, ransomware), industry sectors (finance, telecommunications, etc.), or geopolitical events. The point is to provide the reader with an overview of the subject and the context in why it matters to the organization and the high-level potential impact if the organization were to be affected. With this in mind, you’ll usually find these reports don’t include detailed breakdowns of malware along with technical IOCs or TTPs and instead look at the overall trend or potential risk that can arise from the subject at hand.
Strategic reports can be consumed by anyone from the CEO down and may be provided in written form or briefed as part of a presentation or indeed both. A strategic report aims to help the business make better risk-based decisions based on the intelligence facts available at the time of publication. If you can get the organization to approach security with this intelligence-first mindset, then you’ve probably won CTI. Congratulations! Jesting aside, maximizing the value of strategic reporting is the best way to get buy-in from the very top of the organization, which will subsequently filter down to the rest of the business. So ensuring you’re able to provide executives with timely and relevant intelligence can go a long way to achieving those aims. Effective strategic intelligence should also help drive budgeting decisions when it comes to spending on cybersecurity. So, if you can identify gaps in the business security posture, using your reporting effectively should help to fill any holes you find, in a perfect utopia, of course.
Other Types of Intelligence Reporting
Now, I know I said there were three types of reporting, and mostly that’s true, especially across any textbook or traditional intelligence literature. However, you will find things you produce that might not necessarily fit into those tidy little boxes we just identified, and fear not because that’s OK. So let’s have a look at some of the other types of report you might find yourself creating as part of your duties.
Awareness Reporting
Self-explanatory I imagine, but awareness reporting is where you may issue a report to a broad audience to document a current or emerging threat that you don’t currently have enough information on to provide a tactical or operational report on. For example, if a large organization suffers a “cyber attack” (with no further information), you may wish to make your stakeholders aware of what appears to be the situation, with some hypothesis and initial thoughts, but without any concrete IOCs or TTPs, as they’re not yet available.
This kind of reporting can be shared at all levels of the organization, depending on the threat and the relevancy to your organization.
Executive/VIP Profile Reporting
We’ll touch more on open source intelligence (OSINT) later . Still, it’s not uncommon for CTI teams to research a business’s executive leadership to help them become more secure online. In an age where any determined attacker can probably find information on any individual they wish, this is a beneficial practice and can be eye-opening for the victim – I mean, recipient.
These kinds of reports aim to check the online footprint (or presence if you like) of the individual in question. This will cover things like social media, forums, general information, data breaches they appear in, and anything else you can tie to them (such as usernames, email addresses, phone numbers, websites owned, companies owned, etc.). It goes without saying that is always highly sensitive work and thus is shared with the strictest audience (usually the person in question and maybe the security leads who can assist them). Still, this line of reporting can be valuable in helping people to understand the risk to themselves for blackmail, extortion, kidnapping, etc. By connecting the dots available online, usually without too much effort, you can make a huge impact. I find this kind of reporting incredibly rewarding personally as it’s one of the rare times where you can see the direct impact of your intelligence reporting.
Spot/Flash Reporting
Spot or flash reporting, as the name may suggest, is about providing quick heads-up information on an emerging threat. Think of it as breaking news with a cyber context. You’d usually send these reports to executives as a heads-up of something you think they should be aware of, as well as providing the SOC with the same report. Usually, you might have a concise (a single paragraph at most) summary of what the report is about, followed by some analytical comment on why this is relevant to the business.
Be prepared to follow this kind of report up with something more formal in due course for the broader teams (including IOCs, TTPs, etc.) and potentially fielding questions by the grown-ups in charge. I think it’s worth noting that not every organization will need or want this kind of product from its CTI team, but for completeness, I think it’s worth including as it can and does happen.
Summary Reporting
I considered not including summary reporting at all, as it’s very similar to strategic reporting, but I think it has value, so let’s cover it. Summary reporting is where you may take a specific subject and provide tactical teams with a regular overview over a defined time period. For example, a monthly vulnerability report, monthly report identifying staff credentials in data breaches, quarterly ransomware review, etc.
I think the main difference here between this kind of report and a strategic report though is with the audience. You may choose not to share a summary report with your CISO and executive team, but instead with your tactical teams across security. While the reports would likely be high level, they can give busy readers an adequate level of awareness of a situation that they may not directly be able to support. Of course, if you’re doing a vulnerability report, you may try to identify which vulnerabilities your organization has yet to patch and apply remediating actions with that, which could arguably push it into a tactical/operational sphere, but for the sake of argument here, I think having its own heading is probably about right.
I believe this to be the types of reporting you may get asked to cover. I want to emphasize that this isn’t a binary process; there are overlaps and crossovers across pretty much all types of reporting you may get asked. You may come across over types of report that aren’t included here, but I think for the majority of organizations, the report types covered here should align with what your business expects and needs. Now, let’s take a look at how most intelligence reports are structured so that you can set off on the right foot.
Intelligence Report Structure
Key points
Summary
Details
Recommendations
Appendices
Each section should be fairly self-explanatory, but let’s briefly summarize what they are.
Key Points
Key points are usually presented at the very front of the report, in bullet point format, and highlight what the main takeaways are from the intelligence product. The aim is to provide a quick rundown of what the report contains, so the reader can identify what’s relevant to them immediately.
Summary
The summary is similar to the key points, but it will be a highly condensed overview of the report but will provide a little more information and detail than can be found in key points. You might find some organizations choose to have one or the other rather than both, and to be honest it makes sense to choose one of them, as they both cover the same ground.
Details
The details section makes up the bulk of the reporting product. The fine details and analytical comments help the audience understand the context and why this report is important to the organization. You’ll find detailed breakdowns, hypotheses, and analyses within this section.
Recommendations
The recommendations section of the report will usually outline the actions that the business should take to mitigate the specific threat outlined in the report. This will include details such as patching specific vulnerabilities and systems, identifying IOCs within the network, monitoring for adversary TTPs, etc.
Appendices
The back of the report may include useful images, a full list of IOCs, TTPs, or affected software versions, etc. The details section will likely refer to this part of the report for full information.
I Have Requirements! I Have Report Templates! Now What?
At this stage, I think it’s time for a beer (or reward of your choosing!). You deserve it for standing up formal requirements and getting your reporting templates ready to rock and roll! Unfortunately, though, in the world of CTI, the party is only just getting started. With your prioritized requirements, you have an incredible idea of what your intelligence customers need from you, so now is the time to figure out how to meet those needs.
Business Needs
Looking across your business, its services, and your intelligence requirements, are you in a position to provide the intelligence your customers are asking of you? At this stage, you might need to think about loosening the purse strings to add some capability. But before you dive in, let’s consider what you can do from day one, because we all know trying to procure something new is a laborious and soul-consuming process.
You probably have access to some tools, systems, and services that can help provide you with some context to your intelligence requirements already. Try to identify those systems and services and figure out how to maximize their value based on your customers’ needs. Many security tools will offer “intelligence” functionality, be that looking up data from different sources and providing enrichment of what they already have. For example, you likely have a SIEM that has integration to other systems. It might not be pretty and may not give you the full STIX and ATT&CK magic we’ve previously discussed, but it’s a starting point.
From here, look for other tools that could integrate into the SIEM so you can at least contextualize data across several sources; you may hit hard API limits if you have no budget, but as a starting block, it could be worse. I would then look to other systems and what other teams have to see if you could similarly leverage those systems. While this is clunky and hardly efficient, it may be the quickest way to standing up some level of capability. We will look for a more efficient solution here in a short while, promise!
Automation – Can This Help?
One of the big things in CTI is automation; no matter how you want to face it, if you can’t automate things, you will get left behind, both technologically and when the criminals have the keys to your kingdom. Something neither of us wants to happen.
Suppose you can identify ways of automating the ingestion or processing of some CTI data. In that case, that will help save your analysts time and effort in manually checking each individual threat. Now, we are currently in a position where cyber attacks are growing exponentially year-on-year, and there’s also a massive shortage in skilled talent on the market, so this is not a problem that’s going away any time soon. So I imagine you’re thinking “What do I automate?”, “Why should I automate?”, and possibly “What on god’s green earth have I gotten myself into?!”. Fear not, my friend, we’ve all been there, especially that last one.
IOC ingestion
IOC sharing
IOC enrichment
Report sharing
Each of these platforms has their own features and structure, and you may also find that they may be challenging to maintain or offer little to no customization, but they are there and can be leveraged to help you automate some of these processes. You may find in time that you may need a commercial solution that has a broader feature set more aligned to your goals, but that’s a conversation you can have later.
Away from TIPs, you’ll be considering enrichment of data from your sources. Be that free threat feeds or commercial data. The largest and most apparent enrichment sources tend to be things like VirusTotal for detections and context on what a file, IP, or domain may be linked to and passive DNS lookups. Again, depending on what already exists within your environment, you may find tools you can leverage for this. And be sure to check the resources section at the back of this book for tools you can look to leverage.
It’s also worth considering what internal talent you may have that can help you with building your own capabilities. For example, you can use API functionality to create tools that can help you automate parts of your collection. For example, set up a tool that automatically queries email addresses in HaveIBeenPwned when you suspect staff may have been in data breaches, or utilize functionality to have a tool that checks Twitter for keywords or specific actors so you can be alerted in near real time when they may be active. Utilizing creative approaches to build your own capabilities will definitely give you a firm push when it comes to automating and processing data. If you can bring that data into one place and then manipulate and query it, then all the better, especially if you can do it aligned to STIX and ATT&CK, in my humble opinion.
Of course, I recognize that this might not necessarily be easily achieved with your current position, but I think it’s worth you bearing in mind for the future. The world of CTI is continuously evolving as threat actors develop new and innovative techniques to achieve their aims, and we’re usually stuck playing catch-up. Thinking about new and creative ways to solve problems is something every intelligence analyst should be conscious of. After all, today’s solutions can easily be nonexistent tomorrow.
What If the Business Doesn’t Know What It Wants?
Run. Run very fast and don’t look back. Seriously, keep running! If running isn’t an option, then this can be a difficult position to be in, especially if you’re not able to get buy-in to establish the intelligence requirements you clearly need. That said, I don’t think all hope is lost in this situation; it’s just far from ideal.
In the event that you find yourself with a business unwilling to adapt or support your plans for world domination, take a step back and look at the basics and how you can provide that to the relevant teams across security. Similar to the requirements gathering process, you can probably guess the topics that are likely to be of interest to people and start from there. Scour blogs, news, and social media (especially Twitter) for things you think are relevant and interesting, and start building reports based on those. You can take IOCs from threat reports, run them against different services, and record anything interesting you find. With time and persistence, you’ll hopefully find that people come on board more, especially if you’re providing timely reporting that impacts the business and the systems in place.
Ultimately, CTI is not an exact science, and there is definitely no one golden egg solution for absolutely everyone. While I believe some of the core concepts and standards (such as STIX and ATT&CK) should be applied universally, the approach you take, the tools you have (and can afford), and the risks you face are what makes each organization unique, and with that, such are the challenges and threats you will face as well. If there is one thing in this book I think is absolutely vital to building a successful intelligence team, it’s having the buy-in at the top of the business. If you can get that, you’ll see everything else filter down over time. In the next chapter, we’ll discuss how we can implement CTI regardless of budget to build on what we’ve discussed in this chapter.
Key Takeaways
It’s imperative that any intelligence team has formalized and tracked intelligence requirements. These allow you to understand the organization’s priorities based on the feedback of your key stakeholders and tie directly into the intelligence cycle and feedback process.
Knowing your customer and what kind of reporting they need is crucial. If you’re always sending executives highly technical reports they’ll never read, then they won’t read the reports that matter. Establish what each customer needs and give them that; don’t give everyone the same products.
Intelligence reports largely follow the same format and have crossover; don’t get too concerned about specific report types and whether something needs to be tactical or operational. Remember the requirement, the customer, and the actions the report is recommending.
Identifying business needs away from requirements is important, as is understanding what you can do in the here and now to get started. Utilize open source and community tools to help you on the journey, and don’t be afraid to build your own capabilities where you can and where it makes sense.
CTI isn’t one-size-fits-all. Every organization is unique and so are its challenges. Embrace that and build solutions and a team that serves the business, not a cookie-cutter model of what you think CTI has to be.