ISO 27001:2022 – 5.7 Threat Intelligence

In the recent 2022 update of ISO/IEC 27001, we briefly discussed the seven new controls that were added. Of these, the first is around threat intelligence. This is completely new for 27001 and may be difficult for organisations to understand and comply with if they have never engaged in threat intelligence work, or have not gathered and leveraged threat intel data to help secure their organisation.

At Morrisec, we perform a lot of threat intelligence work. It’s actually a critical component of basically every one of our solutions as it provides great value and critical context when it comes to managing cyber risk, so I for one welcome this addition to the standard.

As we have a strong background in this area, hopefully, you can leverage some of our knowledge to help you address your threat intelligence requirements. Whether you align, comply or certify to ISO/IEC 27001:2022 or not, threat intel should be a major component of your cybersecurity program to ensure you are addressing all the risks your organisation faces.

One caveat before we start. What I present in this article is not the definitive guide to how you should be performing threat intel. We aren’t performing threat intelligence to the level ASIO or the NSA would, and we don’t need to go to their level to provide value. There are many methodologies out there, and ISO/IEC 27001 is intentionally vague in this regard. This is so you can adopt the methodology that suits your business, or keep using what you have if you already perform threat intelligence. I will discuss what ISO/IEC 27002:2022 advises, but again, you don’t need to use 27002 at all. You can use other control frameworks, as I discussed in my recent article. So if you already have a methodology or plan on using one different from what we use, go for it. As long as it addresses ISO/IEC 27001’s intent for this control, you will be fine. I discuss this at the end of the article.

What is threat intelligence?

So what exactly is threat intelligence?

Threat intelligence refers to the collection, analysis, and dissemination of information about potential or existing threats. This includes the types of active threat actors and the tactics, techniques, and procedures (TTPs) they are currently using. The goal of threat intelligence is to provide insights into the types of attacks that your organisation may face. Armed with this knowledge, the idea is that you can help anticipate and defend against these threats. It is also a critical piece in prioritising remediation efforts. We all have limited time, and risk remediation tasks take time. Normally you would prioritise risks based on their risk rating, that is, impact and likelihood. Having relevant and up-to-date threat intelligence provides additional inputs to these risk ratings.

To use a simple example, and a recent issue for many organisations, you have a whole bunch of servers that need patches applied. They all have high risk ratings. One of them is a WordPress server with an exploitable plugin. Your threat intelligence tells you that there is an active campaign where threat actors are targeting this specific plugin. Armed with this knowledge, the updating of that plugin becomes a priority and gets patched before all other servers, protecting your organisation. Without that campaign knowledge gained through threat intelligence, you may have spent weeks patching servers in no particular order, and that WordPress server may have been compromised before being patched.

It’s a pretty simple concept and one you can see immediate value from. This is just one of many scenarios.

What does ISO 27001 Annex A 5.7 expect?

ISO/IEC 27001:2002’s Annex A 5.7 Threat Intelligence states:

“Information relating to information security threats shall be collected and analysed to produce threat intelligence.”

As I said, very vague. The intent is that you will collect information that relates to information security threats, you will analyse that information, and then use that information to help reduce risk.

Though we don’t have to use ISO/IEC 27002 to comply with ISO/IEC 27001, it does provide us contextual information on what 27001 expects to see to satisfy its expectations.

ISO 27002 threat intelligence implementation advice

Firstly I will run through what ISO/IEC 27002 advises to satisfy the threat intelligence requirement, then in the next section, I will discuss one methodology we use that will align with or even go beyond what ISO suggests. This will ensure you not only satisfy the requirement but that you are also getting real value out of your threat intel. If you treat compliance as a box-ticking exercise, you are missing the point of standards like ISO/IEC 27001 and missing out on providing true value and risk reduction from your efforts.

ISO/IEC 27002 provides us ‘Purpose‘ for the control and then 18 bullet points of ‘Guidance‘.

The purpose of the control is defined as:

“To provide awareness of the organization’s threat environment so that the appropriate mitigation actions can be taken.”

So reading this, we are definitely on track for what we thought 27001’s intent was, to provide contextual information that can be used to reduce risk.

ISO/IEC 27002’s guidance provides a few additional areas we want to make sure we address with whatever methodology we choose. After all, your external auditor will be leveraging this information when auditing you to ensure you have met the intent.

First is what 27002 calls ‘layers‘ and other methodologies call ‘audience‘ or ‘categories‘. In 27002 these are:

“a) strategic threat intelligence: exchange of high-level information about the changing threat landscape (e.g. types of attackers or types of attacks);

b) tactical threat intelligence: information about attacker methodologies, tools and technologies involved;

c) operational threat intelligence: details about specific attacks, including technical indicators.”

These layers provide different types of intelligence data that different people across the organisation can use. For example, the intelligence provided under strategic will be used by decision-makers, like executives or board members, whereas operational intel will be used by SOCs, incident responders and other security staff.

Next, 27002 states that threat intelligence should be:

“a) relevant (i.e. related to the protection of the organization);

b) insightful (i.e. providing the organization with an accurate and detailed understanding of the threat landscape);

c) contextual, to provide situational awareness (i.e. adding context to the information based on the time of events, where they occur, previous experiences and prevalence in similar organizations);

d) actionable (i.e. the organization can act on information quickly and effectively).”

These all come down to threat intelligence data being usable. There is zero point in collecting masses of data that isn’t relevant or contextual to your specific organisation. It would provide zero value. The last point is also critical. It must be actionable. You must be able to do something with the data, or again, it serves no purpose. I will discuss these further in the next section as relevancy and being actionable are often not addressed when organisations start gathering intelligence data with no defined plan.

27002 goes on to address the activities that should be undertaken to have relevant and usable threat intelligence. This covers:

• Established objectives
• Choosing your sources of information
• Collecting the information
• Processing the information
• Analysing the information
• Communicating the information

Each of these steps is critical. Miss one and the rest either falls apart or you limit the usability of the information and therefore limit any benefit your may gain from it.

Lastly, ISO/IEC 27002 makes sure you are actually using the information and provides three areas it can be leveraged:

1. Implementing the information in the risk management process
2. As additional inputs to technical controls like firewalls, IPS, and anti-malware
3. As input to security testing processes and techniques.

The outline from 27002 is pretty exhaustive, and if followed, will provide solid value to any organisation in addressing current and emerging threats.

What threat intelligence methodology should I follow?

As I mentioned earlier, there are many threat intelligence methodologies out there, and I won’t venture to say any are better than others. Like most frameworks and methodologies, you must choose what suits you and your organisation best, and that may mean taking something and modifying it for your specific purposes, or using parts of multiple methodologies.

At Morrisec, we have found the EU Agency for Cybersecurity’s (ENISA) Cybersecurity Threat Landscape (CTL) Methodology to be a solid starting point. It’s laid out exceptionally well and easy to follow. It goes to great depth if needed but you can also take what is relevant for your purpose and run at a more high level. You don’t need to address everything it recommends. It’s a 43-page document, so very exhaustive and explains everything in great detail. For an example of a report leveraging the CTL methodology, take a look at ENISA’s Threat Landscape for Supply Chain Attacks report.

I won’t cover everything in the CTL, just the pieces that are relevant to addressing ISO/IEC 27001’s threat intelligence requirements.

The CTL methodology defines five steps that encompass ISO/IEC 27002’s six activities:

Step 1 – Direction

Direction establishes the purpose, the audience and the stakeholders. The most important takeaway from this section and one of the most poorly managed areas I see, is defining what you actually want to get out of your threat intelligence gathering ie. the purpose. This will define the type of data you need to collect which is actually a major consideration.

For anyone that has performed open-source intelligence (OSINT) before, you can go down a MASSIVE rabbit hole trying to find information on your target. You can invest huge amounts of time and collect all sorts of data but in the end, the data provides little value. Instead of just going out and collecting everything you can, take the time to work out what the objective is you want to achieve, and this will dictate the data you need. Instead of scouring the Internet and dark web for every piece of data you can find, you can invest time looking in the right places for the right data that will provide value to your organisation. This will also give you more time to spend in the later stages of the process.

This step defines the audience, or what ISO 27002 called its three layers: strategic, tactical and operational.

The ENISA CTL defines four audiences and provides more details on who these audiences are. This makes it clearer what type of information is relevant for each audience.

“Strategic: information about general risks or developments associated with threats that can be used to drive a high-level strategy. Consumed by security strategist or other senior decision-makers, it can even reach board level.

Tactical: information about tactics, techniques and procedures used by threat actors to conduct their attacks. This information is consumed by architects (network, system, product or process), security control owners and HR related roles, red/blue/purple teams, incident responders, threat hunters and digital forensics.

Operational: information about precursory and indicatory signals of impending attacks. Usually generated by monitoring the threat environment, even from events in the real world, it is consumed by incident responders and high-level security staff, such as security managers.

Technical: observed objects associated with specific threats, usually identified during response to an incident or through forensic processes and typically feeds preventive and monitoring solutions. It is ideally consumed through technical and automated means, and is consumed by administrators, security operations centre analysts and forensic experts.”

Step 2 – Collection

The collection step defines your collection requirements and where you will collect this data from. Mapping your intelligence requirements to your collection requirements is a crucial step and will ensure you are meeting your threat intel objectives.

For example, if your organisation is a health provider, and one of your intelligence requirements is to identify the most common attacks against health providers in Australia in the last 12 months, your collection requirements would include a number of sources that provide this type of information and statistics, such as OAIC’s last two Notifiable Data Breaches Reports. You would also define if this data was strategic, tactical or operational and how often the data was to be collected. In the case of the OAIC’s reports, they come out twice a year.

Step 3 – Processing

Processing of data takes the information and puts it into usable form. 100-page vendor reports or thousands of lines of logs aren’t very useful to most people, or far too time intensive to be beneficial. So being able to take this data, extract it and put it in usable form is critical for it to be usable. Threat intelligence data is only useful if you can act on it in a timely manner. A lot of threat intelligence information, especially that data consumed by the tactical and operational audiences, may only be relevant for a short timeframe. If it takes too long to collect, process and analyse, by the time it’s usable its outlived its usefulness.

We have fully automated the collection of data from a lot of threat sources we use. This way it is automatically collected at certain intervals or collected autonomously as needed for specific client needs. Automate where you can.

Step 4 – Analysis & Production

Analysis is where you revisit the purpose you defined in Step 1 and use the processed data to answer the questions initially posed. You want to provide meaningful conclusions that will lead to actionable recommendations.

Going back to our previous example of the healthcare provider, ignoring the fact we have only looked at one source for this example, the most recent OAIC Notifiable Data Breach report places health service providers as the top sector for notified breaches in Australia. From this report, the highest type of breach was ransomware. Recommendations from the analysis may then focus on reducing the risk of a successful ransomware attack. Again this is generalised as an example.

Step 5 – Dissemination

Dissemination delivers the relevant information to the correct stakeholders that we defined in Step 1. The format and how it’s delivered may be completely different based on the stakeholder. Strategic stakeholders may have a fancy report with graphs and statistics that easily present current risks to the business. supporting strategic and financial decisions. Operational stakeholders may prefer some type of threat feed or have it delivered straight into a threat management platform.

This all sounds like a lot of work, but once you have worked through it the first time, it becomes quite easy to collect, process and use the data, especially if you use automation. I can’t express this enough. One thing we seem to forget when it comes to computers is that they are there to help us do things quicker, not make life more complicated. Use their built-in ability.

How do I comply with ISO 27001:2022?

We have covered a lot for a one sentence requirement in ISO/IEC 27001, but the key takeaways to ensuring you comply with the requirement AND gaining value from complying:

• Define what you are trying to achieve by performing threat intelligence. You must have objectives.
• Define your stakeholders. The data has to go to someone to be usable and to be actioned, otherwise, it’s worthless.
• Map your intelligence requirements to your collection requirements. This ensures you collect the right information to achieve your objectives. This will make sure your data is relevant, insightful and contextual.
• Collect and process your data into a usable form. It must be in a form usable by the stakeholders you identified so they can leverage the data in a timely manner.
• Analyse the data to provide actionable recommendations.
• Deliver the information to the stakeholders so it can be actioned.
• Ensure the information is leveraged within your risk management processes. It should provide additional inputs to impact and likelihood discussions.

Also remember, when certifying to ISO/IEC 27001, document your processes and keep proof that you are following your processes. Remember when you were back in school doing maths, and it wasn’t good enough to just have the answer? You had to show your working out i.e. how you got to the answer. It’s the same here. Welcome to ISO High! 😉 Your auditor will be looking for this proof to ensure you comply and remain complying with the 5.7 Threat Intelligence control. This control will be a common one for organisations to neglect. They will do it once and never again, or do it and not use the outputs for anything useful.

The whole idea of 5.7’s threat intelligence requirement is so you keep your finger on the pulse of what is going on in the world, the threat actors, active campaigns, the types of attacks and evolving TTPs. By following the above points, you ensure you have relevant, usable threat intelligence data that provides actionable data so you can reduce the risk posed by current and emerging threats.

If you need help setting up your threat intelligence program or control, reach out and we can help you. Following the methodology above, we will create processes that support and benefit your individual business, ensure compliance with ISO/IEC 27001:2022 Annex A – 5.7 Threat Intelligence, and provide you ongoing threat intelligence data that minimises your risk.