Indicators of Compromise and their role in attack defence

By on 27 May 2024

Category: Tech matters

Tags: , , ,

Blog home

'Red flag' adapted from rivage's original at Unsplash.

RFC 9424 is a recent, informational RFC all about making life tougher for the bad guys trying to sneak into global networks. Titled ‘Indicators of Compromise (IoCs) and Their Role in Attack Defence’, this document dives into how you can use IoCs to spot, track, and block those sneaky cyber threats. It is a guidebook for network engineers and security pros to beef up their defence game by understanding and deploying IoCs effectively. This post will reflect on the important topics addressed by RFC 9424, using a real-world example.

Since March 2020, the authors Kirsty Paine, Ollie Whitehouse, James Sellwood, and Andrew Shaw have been working on various drafts and iterations of RFC 9424, until it was formalized in August 2023. The RFC comprehensively discusses the use of observable artefacts (IoCs) related to an attacker or their activities, such as tactics, techniques, and procedures (TTPs) and associated tooling and infrastructure.

Kirsty Paine, Field CTO and Strategic Advisor at Splunk, notes in her LinkedIn post that an often-overlooked issue in cybersecurity is the minimal interaction between protocol engineers and defenders. RFC 9424 aims to foster better understanding and technical outcomes between these groups.

Objectives of RFC 9424

The document provides a comprehensive overview of the role and significance of IoCs in cybersecurity defence strategies. The key takeaways are:

  1. Significance of IoCs: The document emphasizes the importance of IoCs in identifying, tracing, and blocking malicious activities in networks or on endpoints.
  2. Role in defence strategies: It highlights that IoCs underpin and enable multiple layers of modern defence-in-depth strategies, playing a crucial role in cybersecurity.
  3. Detectability in implementations: The RFC stresses the need for IoCs to be detectable in implementations of Internet protocols, tools, and technologies for their initial discovery and use in detection.

Defining IoCs

IoCs are artefacts that serve as forensic evidence of potential intrusions on a host system or network. In the context of cybersecurity, IoCs play a crucial role in threat detection, allowing organizations to identify and mitigate the impact of security breaches and malicious activities.

IoCs can include unusual inbound and outbound network traffic or geographic irregularities, such as traffic from economies or locations where the organization does not have a presence. They can also be unknown applications within the system or unusual activity from administrators or privileged accounts.

These examples serve as digital clues that help information security professionals identify malicious activity or security breaches, such as data breaches, insider threats, or malware attacks.

The RFC further expands the IoC definition with the use of the Pyramid of Pain (Figure 1).

David Bianco’s pyramid of pain, first defined in 2013.
Figure 1 — David Bianco’s pyramid of pain, first defined in 2013. Source.

The Pyramid of Pain is a concept in cybersecurity that illustrates the varying levels of difficulty that attackers face when defenders use different types of IoCs to thwart their efforts. This model is particularly useful for understanding how certain types of information can impact an adversary’s operations.

The higher up the Pyramid of Pain, the more ‘painful’ it becomes for attackers to change their methods, and the longer the duration the IoC remains effective for defenders. This concept helps cybersecurity professionals prioritize which IoCs to focus on for the greatest impact on disrupting adversaries.

Lifecycle of IoCs

The lifecycle of IoCs, as outlined in RFC 9424, is a critical concept for managing cybersecurity threats effectively. Understanding this lifecycle helps professionals not just react to threats but anticipate and mitigate them proactively. The lifecycle of IoCs involves several key stages, from their initial creation to their deployment and eventual retirement.

  • Discovery: This stage is all about detection. It’s where network engineers use tools and strategies to uncover potential threats. Whether it’s through automated systems scanning for anomalies or manual sleuthing based on the latest threat intelligence, discovery is the first line of defence.
  • Assessment: This phase emphasizes the importance of contextual information. Without it, IoCs are less useful. Defenders treat IoCs differently based on their quality and the defender’s needs and capabilities. Trust in IoCs varies with their source, freshness, confidence level, and the associated threat. Detailed documentation of an IoC is essential for sharing knowledge within your team or across the cybersecurity community. It typically includes the nature of the IoC, how it was discovered, and its potential impact, making it easier for others to understand and act on.
  • Sharing: The sharing phase deals with the different ways an IoC can be shared — individually in an unstructured manner, or packaged in a standardized format such as STIX, MISP core, OpenIOC, or IODEF, enabling distribution via a structured feed such as TAXII or MISP.
  • Deployment: Suitable deployment of IoCs is essential to provide defense-in-depth and manage various failure points. Different IoCs detect threats at different network layers and attack stages, enabling layered defense. Security controls and endpoint solutions need adequate privilege and visibility to detect and act on IoCs, which should be quickly and widely accessible. Automating the intake, processing, and deployment of IoCs from logs or intelligence feeds is advantageous. Effective IoC deployment can be achieved by integrating IoC support into security products and firewalls, and ensuring wide-reaching control points, like enterprise-wide DNS resolvers, can act on IoC feeds automatically.
  • Detection: In this phase, security systems look for activity that matches any deployed IoCs so that an appropriate response action can be triggered.
  • Reaction: The reaction to an IoC’s detection varies based on the control’s capabilities, the IoC assessment, and the properties of the log source. For instance, a connection to a known botnet C2 server might indicate an issue but isn’t definitive if the server also performs legitimate functions. Common reactions include logging events, triggering alerts, and blocking or terminating the source of the activity.
  • End of life: Finally, retire IoCs that are no longer relevant due to changes in the threat landscape or advancements in technology. This keeps your defence measures current and focused.

IoCs and ISPs / network operators

Staying ahead of threats like malware is a priority for Internet Service Providers (ISPs). By integrating the principles of RFC 9424, ISPs can fortify their defences against sophisticated cyberattacks.

Let’s take a look at an example scenario and how to apply RFC 9424.

1. Understanding and identifying IoCs for Cuttlefish malware

Cuttlefish malware targets routers to manipulate traffic and steal sensitive data. Effective defence starts with identifying precise IoCs, such as:

  • IP addresses and domain names: Monitoring traffic to and from known malicious IPs associated with Cuttlefish.
  • DNS query patterns: Identifying unusual DNS requests that may indicate DNS hijacking attempts.
  • HTTP traffic anomalies: Watching for unexpected HTTP redirects or unusual outbound traffic patterns that suggest data theft or manipulation. Once identified these can be recorded as specific URLs.
  • Malware signature: Using updated antivirus systems to detect the known signatures of Cuttlefish malware.
  • SSL/TLS certificates: Checking for anomalies in certificate issuance that might indicate interception by the malware.

These IoCs are the first line of defence in recognizing and mitigating the impact of the malware on networks managed by ISPs.

2. Integrating IoCs into multi-layered defence strategies

RFC 9424 emphasizes the critical role of IoCs in robust, layered defence strategies. ISPs should implement network segmentation — this limits the spread of the malware if it breaches initial defences. They should also deploy advanced firewalls and an IDS / Intrusion Prevention System (IPS) configured with the latest IoCs to detect and block suspicious activities and use endpoint protection to catch any malware instances that penetrate perimeter defences.

This layered approach ensures multiple opportunities to stop the malware before it causes significant damage.

3. Enhancing IoC detectability with advanced technologies

To ensure that security systems can detect IoCs effectively, ISPs should upgrade their detection systems and implement advanced network monitoring tools that can automatically detect the IoCs associated with Cuttlefish.

They should also set up real-time alert systems for immediate notification when potential threats are detected, allowing for swift response. Of course, regular updates and patches are required to maintain the latest security patches and IoC databases.

4. Fostering collaboration and information sharing

Sharing knowledge and IoCs with other entities is vital. RFC 9424 recommends that ISPs should engage with CSIRTs/CERTs to receive updates on emerging threats and advice on handling incidents and participate in global threat intelligence platforms like MISP (which includes APNIC’s Community Honeynet Project data), where ISPs can share and receive actionable IoCs. Internal collaboration is just as important and information sharing between departments should be encouraged to enhance the overall security posture.

These collaborative efforts enhance the ability to respond to threats rapidly and effectively.

5. Continuously adapting to new threats

Adaptability is key in cybersecurity. Regular security audits are essential to identify potential vulnerabilities and areas for improvement in ISP networks. Training staff on the latest cybersecurity threats and defence mechanisms is key to adaptability as is implementing the right strategies and conditions to create feedback loops. Feedback loops are mechanisms to learn from security incidents and improve future responses.

By implementing the guidelines from RFC 9424, ISPs can create a robust framework for managing cyber threats like the Cuttlefish malware. This involves a proactive approach to security, leveraging the latest in technology and threat intelligence, and fostering a culture of continuous improvement and collaboration. Such a strategy not only enhances the ISP’s ability to protect its own infrastructure but also supports the broader goal of ensuring the security and resilience of the global Internet ecosystem.

Challenges and limitations

RFC 9424 outlines several challenges and complexities involved in effectively using IoCs. The first major challenge is timeliness. Due to the rapid evolution of cyber threats, IoCs must be identified, analysed, and integrated into defence mechanisms swiftly. The effectiveness of each IoC depends significantly on how quickly it can be deployed across systems to mitigate these emerging threats.

Accuracy is another critical factor. IoCs must not only be precise but also reliable to ensure they remain effective as cyber threats evolve. The inherent fragility of some IoCs can limit their usefulness over time, necessitating continual updates to maintain their relevance and accuracy in identifying threats.

Moreover, relevance is vital for IoCs to be actionable. They require a contextual understanding that involves knowledge about the source, associated attack methods, and potential impacts. This is crucial for making informed decisions. As the tactics, techniques, and procedures of threat actors evolve, some IoCs may lose their relevance, prompting their timely review and potential retirement.

Finally, effective use of IoCs requires their detectability across various implementations of Internet protocols, tools, and technologies. Achieving this broad coverage necessitates standardization and interoperability to ensure that different cybersecurity systems can uniformly detect and respond to the threats indicated by IoCs. These challenges underscore the need for a dynamic approach to managing IoCs, where constant assessment, adaptation, and communication are key to maintaining their effectiveness in an ever-changing threat landscape.

Conclusion and future implications

As we navigate through the technical nuances and real-world applications of IoCs, it’s evident that RFC 9424 is more than just a document — it’s a blueprint for building a resilient and defensible cyber environment. Whether you’re a seasoned security professional or new to the field, understanding the implications and applications of this RFC can significantly enhance your ability to safeguard networks against the ever-changing threat landscape.

View the official document for a deeper exploration of RFC 9424 and its comprehensive guidelines. It shares detailed insights on IoCs, how they can turn the tide in cybersecurity, and some of the challenges you might face while you’re at it. If you’re in the ‘biz’ of keeping networks safe, RFC 9424 is a must-read.

Rate this article

The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.

Leave a Reply

Your email address will not be published. Required fields are marked *

Top