An RFC on IoCs – playing our part in international standards

In August 2023, the IETF published the document Indicators of compromise (IoCs) and their role in attack defence as RFC9424. There are a lot of terms to unpack in that sentence, and we’ll get to that later. The headline point is that, working with partners from UK industry – Kirsty Paine, James Sellwood and Ollie Whitehouse, before he became our new CTO – the NCSC have written an IETF RFC. It’s the first document the NCSC has authored in the IETF, a major international standards body, and it details one of the most important tools in a cyber defender’s arsenal – indicators of compromise.

This is the culmination of over three years of work, and we think it’s a really valuable reference and set of considerations on these vital techniques for internet protocol designers and the wider community.

More about ‘standards’

First things first, what are ‘standards’ in this context? I’m referring here to documents, agreed between different parties, that define how things should be made, or that lay out the best practice.

The world of standards is vast. There are standards for everything from charging cables and paper sizes to dishwashers. Not all standards are relevant to cyber security of course, but standards for how the internet works most certainly are. Internet standards don’t just ensure interoperability and easy communication – the design decisions that standards bodies take have significant consequences for computer and network security.

IETF and RFCs

Now to unpack some of that first sentence! The IETF is the Internet Engineering Task Force – the international standards body responsible for designing the most important protocols on the internet today. This includes IP (Internet Protocol), TLS (Transport Layer Security), QUIC (which stands for, um, QUIC) and many, many others.

Anyone can participate in the IETF. Most participants are from industry, but academia, government and not-for-profit groups are all represented too. The IETF publishes standards called RFCs, which can define protocols or provide an informative reference, as our document does. Taking an IETF document from a first draft to a published RFC can be a long process. The authors carry out many rounds of revisions and improvements based on feedback until the document is deemed to have ‘rough consensus’ from the IETF community. It can then be published as an RFC.

More about our RFC

Our document is an introduction to indicators of compromise, or as we define them in the RFC, ‘observable artefacts associated with an attacker’. They can be things like domain names for phishing sites, IP addresses of malware command and control servers, or cryptographic hashes of malicious executables. They provide a relatively simple way to detect malicious activity and tie it to a specific actor, while also being very easy to share quickly between organisations.

In the document, we cover the IoC lifecycle from discovery to deployment, through to end of life, while the ‘pyramid of pain’ shows on a scale how different types of IoC are more or less painful for an attacker to change in order to evade detection. We also include some real examples of how IoCs were used to respond to threats and cover how IoCs are used as part of a defence-in-depth strategy, and outline some considerations for their use.

The ‘pyramid of pain’ rendered in ASCII art in RFC9424.

An example of a TTP might be if an attacker always uses phishing as the initial access vector, and then pivots to other machines on the internal network. The TTP doesn’t guarantee that it’s the same attacker, but is robust against changes to the phishing email, or exploits used to move laterally. Whereas, towards the bottom of the pyramid, an attack coming from the same IP address as previously seen is very likely to be the same attacker; but it is much easier to lose track of if the attacker moves to a new service provider (or even reboots their router!)

This is a topic that will be bread and butter to those of you working in network defence and sharing threat intelligence. But it’s a topic that not everyone involved in the IETF and designing the future internet will be hugely familiar with.

We hope our document will go some way to changing that.

Why standards bodies matter in cyber resilience

Standards bodies like the IETF are where the design decisions that will define the internet of the future are made. Getting involved is a great opportunity not only to see these new ideas long before they’re deployed, but, more importantly, a chance to be part of the design process. This could mean bringing your own technology or idea to the table, or applying your expertise to improve other standards. Going to standards meetings is also just a great way to meet some really smart people and talk about the future of technology.

The NCSC has been participating in the IETF for a number of years now, contributing in a range of working groups and research groups – we’re now also writing a draft on terminology for the use of post-quantum cryptography in internet protocols. We’ve found participating in standards bodies really useful to help us understand the future of the internet. It’s also very rewarding to be able to contribute our cyber security and cryptographic expertise to something bigger.

Call to get involved

This is far from the only work the NCSC is doing in the world of international standards, across far more topics than just internet protocols. From the Internet of Things (IoT) to 5G, industrial control systems and AI, standards are vital to both the NCSC and UK national security. So we really want to encourage more subject matter experts and stakeholders from UK academia and industry to engage in relevant standards bodies.

Bringing technical experience of real-world attack and defence considerations to these forums, along with operational insights, are important bedrocks to achieve and maintain UK cyber resilience.

Andrew S
Senior Internet Standards Researcher, NCSC

Original Source: ncsc[.]gov[.]uk