doc: Add RFC documents

1 files changed, 1357 insertions, 0 deletions

diff --git a/doc/rfc/rfc9424.txt b/doc/rfc/rfc9424.txt
new file mode 100644
index 0000000..e29947d
--- /dev/null
+++ b/doc/rfc/rfc9424.txt
@@ -0,0 +1,1357 @@
+
+
+
+
+Internet Engineering Task Force (IETF)                          K. Paine
+Request for Comments: 9424                                   Splunk Inc.
+Category: Informational                                    O. Whitehouse
+ISSN: 2070-1721                                           Binary Firefly
+                                                             J. Sellwood
+                                                                        
+                                                                 A. Shaw
+                                       UK National Cyber Security Centre
+                                                             August 2023
+
+
+    Indicators of Compromise (IoCs) and Their Role in Attack Defence
+
+Abstract
+
+   Cyber defenders frequently rely on Indicators of Compromise (IoCs) to
+   identify, trace, and block malicious activity in networks or on
+   endpoints.  This document reviews the fundamentals, opportunities,
+   operational limitations, and recommendations for IoC use.  It
+   highlights the need for IoCs to be detectable in implementations of
+   Internet protocols, tools, and technologies -- both for the IoCs'
+   initial discovery and their use in detection -- and provides a
+   foundation for approaches to operational challenges in network
+   security.
+
+Status of This Memo
+
+   This document is not an Internet Standards Track specification; it is
+   published for informational purposes.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Not all documents
+   approved by the IESG are candidates for any level of Internet
+   Standard; see Section 2 of RFC 7841.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   https://www.rfc-editor.org/info/rfc9424.
+
+Copyright Notice
+
+   Copyright (c) 2023 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (https://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Revised BSD License text as described in Section 4.e of the
+   Trust Legal Provisions and are provided without warranty as described
+   in the Revised BSD License.
+
+Table of Contents
+
+   1.  Introduction
+   2.  Terminology
+   3.  IoC Fundamentals
+     3.1.  IoC Types and the Pyramid of Pain
+     3.2.  IoC Lifecycle
+       3.2.1.  Discovery
+       3.2.2.  Assessment
+       3.2.3.  Sharing
+       3.2.4.  Deployment
+       3.2.5.  Detection
+       3.2.6.  Reaction
+       3.2.7.  End of Life
+   4.  Using IoCs Effectively
+     4.1.  Opportunities
+       4.1.1.  IoCs underpin and enable multiple layers of the modern
+               defence-in-depth strategy.
+       4.1.2.  IoCs can be used even with limited resources.
+       4.1.3.  IoCs have a multiplier effect on attack defence efforts
+               within an organisation.
+       4.1.4.  IoCs are easily shared between organisations.
+       4.1.5.  IoCs can provide significant time savings.
+       4.1.6.  IoCs allow for discovery of historic attacks.
+       4.1.7.  IoCs can be attributed to specific threats.
+     4.2.  Case Studies
+       4.2.1.  Cobalt Strike
+         4.2.1.1.  Overall TTP
+         4.2.1.2.  IoCs
+       4.2.2.  APT33
+         4.2.2.1.  Overall TTP
+         4.2.2.2.  IoCs
+   5.  Operational Limitations
+     5.1.  Time and Effort
+       5.1.1.  Fragility
+       5.1.2.  Discoverability
+       5.1.3.  Completeness
+     5.2.  Precision
+       5.2.1.  Specificity
+       5.2.2.  Dual and Compromised Use
+       5.2.3.  Changing Use
+     5.3.  Privacy
+     5.4.  Automation
+   6.  Comprehensive Coverage and Defence-in-Depth
+   7.  IANA Considerations
+   8.  Security Considerations
+   9.  Conclusions
+   10. Informative References
+   Acknowledgements
+   Authors' Addresses
+
+1.  Introduction
+
+   This document describes the various types of IoCs and how they are
+   used effectively in attack defence (often called "cyber defence").
+   It introduces concepts such as the Pyramid of Pain [PoP] and the IoC
+   lifecycle to highlight how IoCs may be used to provide a broad range
+   of defences.  This document provides suggestions for implementers of
+   controls based on IoCs as well as potential operational limitations.
+   Two case studies that demonstrate the usefulness of IoCs for
+   detecting and defending against real-world attacks are included.  One
+   case study involves an intrusion set (a set of malicious activity and
+   behaviours attributed to one threat actor) known as "APT33", and the
+   other involves an attack tool called "Cobalt Strike".  This document
+   is not a comprehensive report of APT33 or Cobalt Strike and is
+   intended to be read alongside publicly published reports (referred to
+   as "open-source material" among cyber intelligence practitioners) on
+   these threats (for example, [Symantec] and [NCCGroup], respectively).
+
+2.  Terminology
+
+   Attack defence:
+      The activity of providing cyber security to an environment through
+      the prevention of, detection of, and response to attempted and
+      successful cyber intrusions.  A successful defence can be achieved
+      through blocking, monitoring, and responding to adversarial
+      activity at the network, endpoint, or application levels.
+
+   Command and control (C2) server:
+      An attacker-controlled server used to communicate with, send
+      commands to, and receive data from compromised machines.
+      Communication between a C2 server and compromised hosts is called
+      "command and control traffic".
+
+   Domain Generation Algorithm (DGA):
+      The algorithm used in malware strains to periodically generate
+      domain names (via algorithm).  Malware may use DGAs to compute a
+      destination for C2 traffic rather than relying on a pre-assigned
+      list of static IP addresses or domains that can be blocked more
+      easily when extracted from, or otherwise linked to, the malware.
+
+   Kill chain:
+      A model for conceptually breaking down a cyber intrusion into
+      stages of the attack from reconnaissance through to actioning the
+      attacker's objectives.  This model allows defenders to think
+      about, discuss, plan for, and implement controls to defend against
+      discrete phases of an attacker's activity [KillChain].
+
+   Tactics, Techniques, and Procedures (TTPs):
+      The way an adversary undertakes activities in the kill chain --
+      the choices made, methods followed, tools and infrastructure used,
+      protocols employed, and commands executed.  If they are distinct
+      enough, aspects of an attacker's TTPs can form specific IoCs as if
+      they were a fingerprint.
+
+   Control (as defined by US NIST):
+      A safeguard or countermeasure prescribed for an information system
+      or an organisation designed to protect the confidentiality,
+      integrity, and availability of its information and to meet a set
+      of defined security requirements [NIST].
+
+3.  IoC Fundamentals
+
+3.1.  IoC Types and the Pyramid of Pain
+
+   IoCs are observable artefacts relating to an attacker or their
+   activities, such as their tactics, techniques, procedures, and
+   associated tooling and infrastructure.  These indicators can be
+   observed at the network or endpoint (host) levels and can, with
+   varying degrees of confidence, help network defenders to proactively
+   block malicious traffic or code execution, determine a cyber
+   intrusion occurred, or associate discovered activity to a known
+   intrusion set and thereby potentially identify additional avenues for
+   investigation.  IoCs are deployed to firewalls and other security
+   control points by adding them to the list of indicators that the
+   control point is searching for in the traffic that it is monitoring.
+   When associated with malicious activity, the following are some
+   examples of protocol-related IoCs:
+
+   *  IPv4 and IPv6 addresses in network traffic
+
+   *  Fully Qualified Domain Names (FQDNs) in network traffic, DNS
+      resolver caches, or logs
+
+   *  TLS Server Name Indication values in network traffic
+
+   *  Code-signing certificates in binaries
+
+   *  TLS certificate information (such as SHA256 hashes) in network
+      traffic
+
+   *  Cryptographic hashes (e.g., MD5, SHA1, or SHA256) of malicious
+      binaries or scripts when calculated from network traffic or file
+      system artefacts
+
+   *  Attack tools (such as Mimikatz [Mimikatz]) and their code
+      structure and execution characteristics
+
+   *  Attack techniques, such as Kerberos Golden Tickets [GoldenTicket],
+      that can be observed in network traffic or system artefacts
+
+   The common types of IoC form a Pyramid of Pain [PoP] that informs
+   prevention, detection, and mitigation strategies.  The position of
+   each IoC type in the pyramid represents how much "pain" a typical
+   adversary experiences as part of changing the activity that produces
+   that artefact.  The greater pain an adversary experiences (towards
+   the top), the less likely they are to change those aspects of their
+   activity and the longer the IoC is likely to reflect the attacker's
+   intrusion set (i.e., the less fragile those IoCs will be from a
+   defender's perspective).  The layers of the PoP commonly range from
+   hashes up to TTPs, with the pain ranging from simply recompiling code
+   to creating a whole new attack strategy.  Other types of IoC do exist
+   and could be included in an extended version of the PoP should that
+   assist the defender in understanding and discussing intrusion sets
+   most relevant to them.
+
+                             /\
+                            /  \                             MORE PAIN
+                           /    \                           LESS FRAGILE
+                          /      \                          LESS PRECISE
+                         /  TTPs  \
+                        /          \                            / \
+                       ==============                            |
+                      /              \                           |
+                     /      Tools     \                          |
+                    /                  \                         |
+                   ======================                        |
+                  /                      \                       |
+                 / Network/Host Artefacts \                      |
+                /                          \                     |
+               ==============================                    |
+              /                              \                   |
+             /          Domain Names          \                  |
+            /                                  \                 |
+           ======================================                |
+          /                                      \               |
+         /              IP Addresses              \              |
+        /                                          \            \ /
+       ==============================================
+      /                                              \       LESS PAIN
+     /                   Hash Values                  \     MORE FRAGILE
+    /                                                  \    MORE PRECISE
+   ======================================================
+
+                                  Figure 1
+
+   On the lowest (and least painful) level are hashes of malicious
+   files.  These are easy for a defender to gather and can be deployed
+   to firewalls or endpoint protection to block malicious downloads or
+   prevent code execution.  While IoCs aren't the only way for defenders
+   to do this kind of blocking, they are a quick, convenient, and
+   nonintrusive method.  Hashes are precise detections for individual
+   files based on their binary content.  To subvert this defence,
+   however, an adversary need only recompile code, or otherwise modify
+   the file content with some trivial changes, to modify the hash value.
+
+   The next two levels are IP addresses and domain names.  Interactions
+   with these may be blocked, with varying false positive rates
+   (misidentifying non-malicious traffic as malicious; see Section 5),
+   and often cause more pain to an adversary to subvert than file
+   hashes.  The adversary may have to change IP ranges, find a new
+   provider, and change their code (e.g., if the IP address is hard-
+   coded rather than resolved).  A similar situation applies to domain
+   names, but in some cases, threat actors have specifically registered
+   these to masquerade as a particular organisation or to otherwise
+   falsely imply or claim an association that will be convincing or
+   misleading to those they are attacking.  While the process and cost
+   of registering new domain names are now unlikely to be prohibitive or
+   distracting to many attackers, there is slightly greater pain in
+   selecting unregistered, but appropriate, domain names for such
+   purposes.
+
+   Network and endpoint artefacts, such as a malware's beaconing pattern
+   on the network or the modified timestamps of files touched on an
+   endpoint, are harder still to change as they relate specifically to
+   the attack taking place and, in some cases, may not be under the
+   direct control of the attacker.  However, more sophisticated
+   attackers use TTPs or tooling that provides flexibility at this level
+   (such as Cobalt Strike's malleable command and control [COBALT]) or a
+   means by which some artefacts can be masked (see [Timestomp]).
+
+   Tools and TTPs form the top two levels of the pyramid; these levels
+   describe a threat actor's methodology -- the way they perform the
+   attack.  The tools level refers specifically to the software (and
+   less frequently, hardware) used to conduct the attack, whereas the
+   TTPs level picks up on all the other aspects of the attack strategy.
+   IoCs at these levels are more complicated and complex -- for example,
+   they can include the details of how an attacker deploys malicious
+   code to perform reconnaissance of a victim's network, pivots
+   laterally to a valuable endpoint, and then downloads a ransomware
+   payload.  TTPs and tools take intensive effort to diagnose on the
+   part of the defender, but they are fundamental to the attacker and
+   campaign and hence incredibly painful for the adversary to change.
+
+   The variation in discoverability of IoCs is indicated by the numbers
+   of IoCs in AlienVault, an open threat intelligence community
+   [ALIENVAULT].  As of January 2023, AlienVault contained:
+
+   *  Groups (i.e., combinations of TTPs): 631
+
+   *  Malware families (i.e., tools): ~27,000
+
+   *  URL: 2,854,918
+
+   *  Domain names: 64,769,363
+
+   *  IPv4 addresses: 5,427,762
+
+   *  IPv6 addresses: 12,009
+
+   *  SHA256 hash values: 5,452,442
+
+   The number of domain names appears out of sync with the other counts,
+   which reduce on the way up the PoP.  This discrepancy warrants
+   further research; however, contributing factors may be the use of
+   DGAs and the fact that threat actors use domain names to masquerade
+   as legitimate organisations and so have added incentive for creating
+   new domain names as they are identified and confiscated.
+
+3.2.  IoC Lifecycle
+
+   To be of use to defenders, IoCs must first be discovered, assessed,
+   shared, and deployed.  When a logged activity is identified and
+   correlated to an IoC, this detection triggers a reaction by the
+   defender, which may include an investigation, potentially leading to
+   more IoCs being discovered, assessed, shared, and deployed.  This
+   cycle continues until the IoC is determined to no longer be relevant,
+   at which point it is removed from the control space.
+
+3.2.1.  Discovery
+
+   IoCs are discovered initially through manual investigation or
+   automated analysis.  They can be discovered in a range of sources,
+   including at endpoints and in the network (on the wire).  They must
+   either be extracted from logs monitoring protocol packet captures,
+   code execution, or system activity (in the case of hashes, IP
+   addresses, domain names, and network or endpoint artefacts) or be
+   determined through analysis of attack activity or tooling.  In some
+   cases, discovery may be a reactive process, where IoCs from past or
+   current attacks are identified from the traces left behind.  However,
+   discovery may also result from proactive hunting for potential future
+   IoCs extrapolated from knowledge of past events (such as from
+   identifying attacker infrastructure by monitoring domain name
+   registration patterns).
+
+   Crucially, for an IoC to be discovered, the indicator must be
+   extractable from the Internet protocol, tool, or technology it is
+   associated with.  Identifying a particular exchange (or sequence of
+   exchanged messages) related to an attack is of limited benefit if
+   indicators cannot be extracted or, once they are extracted, cannot be
+   subsequently associated with a later related exchange of messages or
+   artefacts in the same, or in a different, protocol.  If it is not
+   possible to determine the source or destination of malicious attack
+   traffic, it will not be possible to identify and block subsequent
+   attack traffic either.
+
+3.2.2.  Assessment
+
+   Defenders may treat different IoCs differently, depending on the
+   IoCs' quality and the defender's needs and capabilities.  Defenders
+   may, for example, place differing trust in IoCs depending on their
+   source, freshness, confidence level, or the associated threat.  These
+   decisions rely on associated contextual information recovered at the
+   point of discovery or provided when the IoC was shared.
+
+   An IoC without context is not much use for network defence.  On the
+   other hand, an IoC delivered with context (for example, the threat
+   actor it relates to, its role in an attack, the last time it was seen
+   in use, its expected lifetime, or other related IoCs) allows a
+   network defender to make an informed choice on how to use it to
+   protect their network (for example, simply log it, actively monitor
+   it, or outright block it).
+
+3.2.3.  Sharing
+
+   Once discovered and assessed, IoCs are most helpful when deployed in
+   such a way to have a broad impact on the detection or disruption of
+   threats or shared at scale so many individuals and organisations can
+   defend themselves.  An IoC may be shared individually (with
+   appropriate context) in an unstructured manner or may be packaged
+   alongside many other IoCs in a standardised format, such as
+   Structured Threat Information Expression [STIX], Malware Information
+   Sharing Platform (MISP) core [MISPCORE], OpenIOC [OPENIOC], and
+   Incident Object Description Exchange Format (IODEF) [RFC7970].  This
+   enables distribution via a structured feed, such as one implementing
+   Trusted Automated Exchange of Intelligence Information [TAXII], or
+   through a Malware Information Sharing Platform [MISP].
+
+   While some security companies and some membership-based groups (often
+   dubbed "Information Sharing and Analysis Centres (ISACs)" or
+   "Information Sharing and Analysis Organizations (ISAOs)") provide
+   paid intelligence feeds containing IoCs, there are various free IoC
+   sources available from individual security researchers up through
+   small trust groups to national governmental cyber security
+   organisations and international Computer Emergency Response Teams
+   (CERTs).  Whoever they are, sharers commonly indicate the extent to
+   which receivers may further distribute IoCs using frameworks like the
+   Traffic Light Protocol [TLP].  At its simplest, this indicates that
+   the receiver may share with anyone (TLP:CLEAR), share within the
+   defined sharing community (TLP:GREEN), share within their
+   organisation and their clients (TLP:AMBER+STRICT), share just within
+   their organisation (TLP:AMBER), or not share with anyone outside the
+   original specific IoC exchange (TLP:RED).
+
+3.2.4.  Deployment
+
+   For IoCs to provide defence-in-depth (see Section 6) and so cope with
+   different points of failure, correct deployment is important.
+   Different IoCs will detect malicious activity at different layers of
+   the network stack and at different stages of an attack, so deploying
+   a range of IoCs enables layers of defence at each security control,
+   reinforcing the benefits of using multiple security controls as part
+   of a defence-in-depth solution.  The network security controls and
+   endpoint solutions where they are deployed need to have sufficient
+   privilege, and sufficient visibility, to detect IoCs and to act on
+   them.  Wherever IoCs exist, they need to be made available to
+   security controls and associated apparatus to ensure they can be
+   deployed quickly and widely.  While IoCs may be manually assessed
+   after discovery or receipt, significant advantage may be gained by
+   automatically ingesting, processing, assessing, and deploying IoCs
+   from logs or intelligence feeds to the appropriate security controls.
+   As not all IoCs are of the same quality, confidence in IoCs drawn
+   from each threat intelligence feed should be considered when deciding
+   whether to deploy IoCs automatically in this way.
+
+   IoCs can be particularly effective at mitigating malicious activity
+   when deployed in security controls with the broadest impact.  This
+   could be achieved by developers of security products or firewalls
+   adding support for the distribution and consumption of IoCs directly
+   to their products, without each user having to do it, thus addressing
+   the threat for the whole user base at once in a machine-scalable and
+   automated manner.  This could also be achieved within an enterprise
+   by ensuring those control points with the widest aperture (for
+   example, enterprise-wide DNS resolvers) are able to act automatically
+   based on IoC feeds.
+
+3.2.5.  Detection
+
+   Security controls with deployed IoCs monitor their relevant control
+   space and trigger a generic or specific reaction upon detection of
+   the IoC in monitored logs or on network interfaces.
+
+3.2.6.  Reaction
+
+   The reaction to an IoC's detection may differ depending on factors
+   such as the capabilities and configuration of the control it is
+   deployed in, the assessment of the IoC, and the properties of the log
+   source in which it was detected.  For example, a connection to a
+   known botnet C2 server may indicate a problem but does not guarantee
+   it, particularly if the server is a compromised host still performing
+   some other legitimate functions.  Common reactions include event
+   logging, triggering alerts, and blocking or terminating the source of
+   the activity.
+
+3.2.7.  End of Life
+
+   How long an IoC remains useful varies and is dependent on factors
+   including initial confidence level, fragility, and precision of the
+   IoC (discussed further in Section 5).  In some cases, IoCs may be
+   automatically "aged" based on their initial characteristics and so
+   will reach end of life at a predetermined time.  In other cases, IoCs
+   may become invalidated due to a shift in the threat actor's TTPs
+   (e.g., resulting from a new development or their discovery) or due to
+   remediation action taken by a defender.  End of life may also come
+   about due to an activity unrelated to attack or defence, such as when
+   a third-party service used by the attacker changes or goes offline.
+   Whatever the cause, IoCs should be removed from detection at the end
+   of their life to reduce the likelihood of false positives.
+
+4.  Using IoCs Effectively
+
+4.1.  Opportunities
+
+   IoCs offer a variety of opportunities to cyber defenders as part of a
+   modern defence-in-depth strategy.  No matter the size of an
+   organisation, IoCs can provide an effective, scalable, and efficient
+   defence mechanism against classes of attack from the latest threats
+   or specific intrusion sets that may have struck in the past.
+
+4.1.1.  IoCs underpin and enable multiple layers of the modern defence-
+        in-depth strategy.
+
+   Firewalls, Intrusion Detection Systems (IDSs), and Intrusion
+   Prevention Systems (IPSs) all employ IoCs to identify and mitigate
+   threats across networks.  Antivirus (AV) and Endpoint Detection and
+   Response (EDR) products deploy IoCs via catalogues or libraries to
+   supported client endpoints.  Security Incident Event Management
+   (SIEM) platforms compare IoCs against aggregated logs from various
+   sources -- network, endpoint, and application.  Of course, IoCs do
+   not address all attack defence challenges, but they form a vital tier
+   of any organisation's layered defence.  Some types of IoC may be
+   present across all those controls while others may be deployed only
+   in certain layers of a defence-in-depth solution.  Further, IoCs
+   relevant to a specific kill chain may only reflect activity performed
+   during a certain phase and so need to be combined with other IoCs or
+   mechanisms for complete coverage of the kill chain as part of an
+   intrusion set.
+
+   As an example, open-source malware can be deployed by many different
+   actors, each using their own TTPs and infrastructure.  However, if
+   the actors use the same executable, the hash of the executable file
+   remains the same, and this hash can be deployed as an IoC in endpoint
+   protection to block execution regardless of individual actor,
+   infrastructure, or other TTPs.  Should this defence fail in a
+   specific case, for example, if an actor recompiles the executable
+   binary producing a unique hash, other defences can prevent them
+   progressing further through their attack, for instance, by blocking
+   known malicious domain name lookups and thereby preventing the
+   malware calling out to its C2 infrastructure.
+
+   Alternatively, another malicious actor may regularly change their
+   tools and infrastructure (and thus the indicators associated with the
+   intrusion set) deployed across different campaigns, but their access
+   vectors may remain consistent and well-known.  In this case, this
+   access TTP can be recognised and proactively defended against, even
+   while there is uncertainty of the intended subsequent activity.  For
+   example, if their access vector consistently exploits a vulnerability
+   in software, regular and estate-wide patching can prevent the attack
+   from taking place.  However, should these preemptive measures fail,
+   other IoCs observed across multiple campaigns may be able to prevent
+   the attack at later stages in the kill chain.
+
+4.1.2.  IoCs can be used even with limited resources.
+
+   IoCs are inexpensive, scalable, and easy to deploy, making their use
+   particularly beneficial for smaller entities, especially where they
+   are exposed to a significant threat.  For example, a small
+   manufacturing subcontractor in a supply chain producing a critical,
+   highly specialised component may represent an attractive target
+   because there would be disproportionate impact on both the supply
+   chain and the prime contractor if it were compromised.  It may be
+   reasonable to assume that this small manufacturer will have only
+   basic security (whether internal or outsourced), and while it is
+   likely to have comparatively fewer resources to manage the risks that
+   it faces compared to larger partners, it can still leverage IoCs to
+   great effect.  Small entities like this can deploy IoCs to give a
+   baseline protection against known threats without having access to a
+   well-resourced, mature defensive team and the threat intelligence
+   relationships necessary to perform resource-intensive investigations.
+   While some level of expertise on the part of such a small company
+   would be needed to successfully deploy IoCs, use of IoCs does not
+   require the same intensive training as needed for more subjective
+   controls, such as those using machine learning, which require further
+   manual analysis of identified events to verify if they are indeed
+   malicious.  In this way, a major part of the appeal of IoCs is that
+   they can afford some level of protection to organisations across
+   spectrums of resource capability, maturity, and sophistication.
+
+4.1.3.  IoCs have a multiplier effect on attack defence efforts within
+        an organisation.
+
+   Individual IoCs can provide widespread protection that scales
+   effectively for defenders across an organisation or ecosystem.
+   Within a single organisation, simply blocking one IoC may protect
+   thousands of users, and that blocking may be performed (depending on
+   the IoC type) across multiple security controls monitoring numerous
+   different types of activity within networks, endpoints, and
+   applications.  The prime contractor from our earlier example can
+   supply IoCs to the small subcontractor and thus further uplift that
+   smaller entity's defensive capability while protecting itself and its
+   interests at the same time.
+
+   Multiple organisations may benefit from directly receiving shared
+   IoCs (see Section 4.1.4), but they may also benefit from the IoCs'
+   application in services they utilise.  In the case of an ongoing
+   email-phishing campaign, IoCs can be monitored, discovered, and
+   deployed quickly and easily by individual organisations.  However, if
+   they are deployed quickly via a mechanism such as a protective DNS
+   filtering service, they can be more effective still -- an email
+   campaign may be mitigated before some organisations' recipients ever
+   click the link or before some malicious payloads can call out for
+   instructions.  Through such approaches, other parties can be
+   protected without direct sharing of IoCs with those organisations or
+   additional effort.
+
+4.1.4.  IoCs are easily shared between organisations.
+
+   IoCs can also be very easily shared between individuals and
+   organisations.  First, IoCs are easy to distribute as they can be
+   represented concisely as text (possibly in hexadecimal) and so are
+   frequently exchanged in small numbers in emails, blog posts, or
+   technical reports.  Second, standards, such as those mentioned in
+   Section 3.2.3, exist to provide well-defined formats for sharing
+   large collections or regular sets of IoCs along with all the
+   associated context.  While discovering one IoC can be intensive, once
+   shared via well-established routes, that individual IoC may protect
+   thousands of organisations and thus all of the users in those
+   organisations.  Quick and easy sharing of IoCs gives blanket coverage
+   for organisations and allows widespread mitigation in a timely
+   fashion -- they can be shared with systems administrators, from small
+   to large organisations and from large teams to single individuals,
+   allowing them all to implement defences on their networks.
+
+4.1.5.  IoCs can provide significant time savings.
+
+   Not only are there time savings from sharing IoCs, saving duplication
+   of investigation effort, but deploying them automatically at scale is
+   seamless for many enterprises.  Where automatic deployment of IoCs is
+   working well, organisations and users get blanket protection with
+   minimal human intervention and minimal effort, a key goal of attack
+   defence.  The ability to do this at scale and at pace is often vital
+   when responding to agile threat actors that may change their
+   intrusion set frequently and hence change the relevant IoCs.
+   Conversely, protecting a complex network without automatic deployment
+   of IoCs could mean manually updating every single endpoint or network
+   device consistently and reliably to the same security state.  The
+   work this entails (including locating assets and devices, polling for
+   logs and system information, and manually checking patch levels)
+   introduces complexity and a need for skilled analysts and engineers.
+   While it is still necessary to invest effort both to enable efficient
+   IoC deployment and to eliminate false positives when widely deploying
+   IoCs, the cost and effort involved can be far smaller than the work
+   entailed in reliably manually updating all endpoint and network
+   devices.  For example, legacy systems may be particularly
+   complicated, or even impossible, to update.
+
+4.1.6.  IoCs allow for discovery of historic attacks.
+
+   A network defender can use recently acquired IoCs in conjunction with
+   historic data, such as logged DNS queries or email attachment hashes,
+   to hunt for signs of past compromise.  Not only can this technique
+   help to build a clear picture of past attacks, but it also allows for
+   retrospective mitigation of the effects of any previous intrusion.
+   This opportunity is reliant on historic data not having been
+   compromised itself, by a technique such as Timestomp [Timestomp], and
+   not being incomplete due to data retention policies, but it is
+   nonetheless valuable for detecting and remediating past attacks.
+
+4.1.7.  IoCs can be attributed to specific threats.
+
+   Deployment of various modern security controls, such as firewall
+   filtering or EDR, come with an inherent trade-off between breadth of
+   protection and various costs, including the risk of false positives
+   (see Section 5.2), staff time, and pure financial costs.
+   Organisations can use threat modelling and information assurance to
+   assess and prioritise risk from identified threats and to determine
+   how they will mitigate or accept each of them.  Contextual
+   information tying IoCs to specific threats or actors and shared
+   alongside the IoCs enables organisations to focus their defences
+   against particular risks.  This contextual information is generally
+   expected by those receiving IoCs as it allows them the technical
+   freedom and capability to choose their risk appetite, security
+   posture, and defence methods.  The ease of sharing this contextual
+   information alongside IoCs, in part due to the formats outlined in
+   Section 3.2.3, makes it easier to track malicious actors across
+   campaigns and targets.  Producing this contextual information before
+   sharing IoCs can take intensive analytical effort as well as
+   specialist tools and training.  At its simplest, it can involve
+   documenting sets of IoCs from multiple instances of the same attack
+   campaign, for example, from multiple unique payloads (and therefore
+   with distinct file hashes) from the same source and connecting to the
+   same C2 server.  A more complicated approach is to cluster similar
+   combinations of TTPs seen across multiple campaigns over a period of
+   time.  This can be used alongside detailed malware reverse
+   engineering and target profiling, overlaid on a geopolitical and
+   criminal backdrop, to infer attribution to a single threat actor.
+
+4.2.  Case Studies
+
+   The following two case studies illustrate how IoCs may be identified
+   in relation to threat actor tooling (in the first) and a threat actor
+   campaign (in the second).  The case studies further highlight how
+   these IoCs may be used by cyber defenders.
+
+4.2.1.  Cobalt Strike
+
+   Cobalt Strike [COBALT] is a commercial attack framework used for
+   penetration testing that consists of an implant framework (beacon), a
+   network protocol, and a C2 server.  The beacon and network protocol
+   are highly malleable, meaning the protocol representation "on the
+   wire" can be easily changed by an attacker to blend in with
+   legitimate traffic by ensuring the traffic conforms to the protocol
+   specification, e.g., HTTP.  The proprietary beacon supports TLS
+   encryption overlaid with a custom encryption scheme based on a
+   public-private keypair.  The product also supports other techniques,
+   such as domain fronting [DFRONT], in an attempt to avoid obvious
+   passive detection by static network signatures of domain names or IP
+   addresses.  Domain fronting is used to blend traffic to a malicious
+   domain with traffic originating from a network that is already
+   communicating with a non-malicious domain regularly over HTTPS.
+
+4.2.1.1.  Overall TTP
+
+   A beacon configuration describes how the implant should operate and
+   communicate with its C2 server.  This configuration also provides
+   ancillary information such as the Cobalt Strike user licence
+   watermark.
+
+4.2.1.2.  IoCs
+
+   Tradecraft has been developed that allows the fingerprinting of C2
+   servers based on their responses to specific requests.  This allows
+   the servers to be identified, their beacon configurations to be
+   downloaded, and the associated infrastructure addresses to be
+   extracted as IoCs.
+
+   The resulting mass IoCs for Cobalt Strike are:
+
+   *  IP addresses of the C2 servers
+
+   *  domain names used
+
+   Whilst these IoCs need to be refreshed regularly (due to the ease of
+   which they can be changed), the authors' experience of protecting
+   public sector organisations shows that these IoCs are effective for
+   disrupting threat actor operations that use Cobalt Strike.
+
+   These IoCs can be used to check historical data for evidence of past
+   compromise and deployed to detect or block future infection in a
+   timely manner, thereby contributing to preventing the loss of user
+   and system data.
+
+4.2.2.  APT33
+
+   In contrast to the first case study, this describes a current
+   campaign by the threat actor APT33, also known as Elfin and Refined
+   Kitten (see [Symantec]).  APT33 has been assessed by the industry to
+   be a state-sponsored group [FireEye2]; yet, in this case study, IoCs
+   still gave defenders an effective tool against such a powerful
+   adversary.  The group has been active since at least 2015 and is
+   known to target a range of sectors including petrochemical,
+   government, engineering, and manufacturing.  Activity has been seen
+   in countries across the globe but predominantly in the USA and Saudi
+   Arabia.
+
+4.2.2.1.  Overall TTP
+
+   The techniques employed by this actor exhibit a relatively low level
+   of sophistication, considering it is a state-sponsored group.
+   Typically, APT33 performs spear phishing (sending targeted malicious
+   emails to a limited number of pre-selected recipients) with document
+   lures that imitate legitimate publications.  User interaction with
+   these lures executes the initial payload and enables APT33 to gain
+   initial access.  Once inside a target network, APT33 attempts to
+   pivot to other machines to gather documents and gain access to
+   administrative credentials.  In some cases, users are tricked into
+   providing credentials that are then used with Ruler [RULER], a freely
+   available tool that allows exploitation of an email client.  The
+   attacker, in possession of a target's password, uses Ruler to access
+   the target's mail account and embeds a malicious script that will be
+   triggered when the mail client is next opened, resulting in the
+   execution of malicious code (often additional malware retrieved from
+   the Internet) (see [FireEye]).
+
+   APT33 sometimes deploys a destructive tool that overwrites the master
+   boot record (MBR) of the hard drives in as many PCs as possible.
+   This type of tool, known as a wiper, results in data loss and renders
+   devices unusable until the operating system is reinstalled.  In some
+   cases, the actor uses administrator credentials to invoke execution
+   across a large swathe of a company's IT estate at once; where this
+   isn't possible, the actor may first attempt to spread the wiper
+   manually or use worm-like capabilities against unpatched
+   vulnerabilities on the networked computers.
+
+4.2.2.2.  IoCs
+
+   As a result of investigations by a partnership of the industry and
+   the UK's National Cyber Security Centre (NCSC), a set of IoCs were
+   compiled and shared with both public and private sector organisations
+   so network defenders could search for them in their networks.
+   Detection of these IoCs is likely indicative of APT33 targeting and
+   could indicate potential compromise and subsequent use of destructive
+   malware.  Network defenders could also initiate processes to block
+   these IoCs to foil future attacks.  This set of IoCs comprised:
+
+   *  9 hashes and email subject lines
+
+   *  5 IP addresses
+
+   *  7 domain names
+
+   In November 2021, a joint advisory concerning APT33 [CISA] was issued
+   by the Federal Bureau of Investigation (FBI), the Cybersecurity and
+   Infrastructure Security Agency (CISA), the Australian Cyber Security
+   Centre (ACSC), and NCSC.  This outlined recent exploitation of
+   vulnerabilities by APT33, providing a thorough overview of observed
+   TTPs and sharing further IoCs:
+
+   *  8 hashes of malicious executables
+
+   *  3 IP addresses
+
+5.  Operational Limitations
+
+   The different IoC types inherently embody a set of trade-offs for
+   defenders between the risk of false positives (misidentifying non-
+   malicious traffic as malicious) and the risk of failing to identify
+   attacks.  The attacker's relative pain of modifying attacks to
+   subvert known IoCs, as discussed using the PoP in Section 3.1,
+   inversely correlates with the fragility of the IoC and with the
+   precision with which the IoC identifies an attack.  Research is
+   needed to elucidate the exact nature of these trade-offs between
+   pain, fragility, and precision.
+
+5.1.  Time and Effort
+
+5.1.1.  Fragility
+
+   As alluded to in Section 3.1, the PoP can be thought of in terms of
+   fragility for the defender as well as pain for the attacker.  The
+   less painful it is for the attacker to change an IoC, the more
+   fragile that IoC is as a defence tool.  It is relatively simple to
+   determine the hash value for various malicious file attachments
+   observed as lures in a phishing campaign and to deploy these through
+   AV or an email gateway security control.  However, those hashes are
+   fragile and can (and often will) be changed between campaigns.
+   Malicious IP addresses and domain names can also be changed between
+   campaigns, but this may happen less frequently due to the greater
+   pain of managing infrastructure compared to altering files, and so IP
+   addresses and domain names may provide a less fragile detection
+   capability.
+
+   This does not mean the more fragile IoC types are worthless.  First,
+   there is no guarantee a fragile IoC will change, and if a known IoC
+   isn't changed by the attacker but wasn't blocked, then the defender
+   missed an opportunity to halt an attack in its tracks.  Second, even
+   within one IoC type, there is variation in the fragility depending on
+   the context of the IoC.  The file hash of a phishing lure document
+   (with a particular theme and containing a specific staging server
+   link) may be more fragile than the file hash of a remote access
+   trojan payload the attacker uses after initial access.  That in turn
+   may be more fragile than the file hash of an attacker-controlled
+   post-exploitation reconnaissance tool that doesn't connect directly
+   to the attacker's infrastructure.  Third, some threats and actors are
+   more capable or inclined to change than others, and so the fragility
+   of an IoC for one may be very different to an IoC of the same type
+   for another actor.
+
+   Ultimately, fragility is a defender's concern that impacts the
+   ongoing efficacy of each IoC and will factor into decisions about end
+   of life.  However, it should not prevent adoption of individual IoCs
+   unless there are significantly strict resource constraints that
+   demand down-selection of IoCs for deployment.  More usually,
+   defenders researching threats will attempt to identify IoCs of
+   varying fragilities for a particular kill chain to provide the
+   greatest chances of ongoing detection given available investigative
+   effort (see Section 5.1.2) and while still maintaining precision (see
+   Section 5.2).
+
+5.1.2.  Discoverability
+
+   To be used in attack defence, IoCs must first be discovered through
+   proactive hunting or reactive investigation.  As noted in
+   Section 3.1, IoCs in the tools and TTPs levels of the PoP require
+   intensive effort and research to discover.  However, it is not just
+   an IoC's type that impacts its discoverability.  The sophistication
+   of the actor, their TTPs, and their tooling play a significant role,
+   as does whether the IoC is retrieved from logs after the attack or
+   extracted from samples or infected systems earlier.
+
+   For example, on an infected endpoint, it may be possible to identify
+   a malicious payload and then extract relevant IoCs, such as the file
+   hash and its C2 server address.  If the attacker used the same static
+   payload throughout the attack, this single file hash value will cover
+   all instances.  However, if the attacker diversified their payloads,
+   that hash can be more fragile, and other hashes may need to be
+   discovered from other samples used on other infected endpoints.
+   Concurrently, the attacker may have simply hard-coded configuration
+   data into the payload, in which case the C2 server address can be
+   easy to recover.  Alternatively, the address can be stored in an
+   obfuscated persistent configuration within either the payload (e.g.,
+   within its source code or associated resource) or the infected
+   endpoint's file system (e.g., using alternative data streams [ADS]),
+   thus requiring more effort to discover.  Further, the attacker may be
+   storing the configuration in memory only or relying on a DGA to
+   generate C2 server addresses on demand.  In this case, extracting the
+   C2 server address can require a memory dump or the execution or
+   reverse engineering of the DGA, all of which increase the effort
+   still further.
+
+   If the malicious payload has already communicated with its C2 server,
+   then it may be possible to discover that C2 server address IoC from
+   network traffic logs more easily.  However, once again, multiple
+   factors can make discoverability more challenging, such as the
+   increasing adoption of HTTPS for malicious traffic, meaning C2
+   communications blend in with legitimate traffic and can be
+   complicated to identify.  Further, some malwares obfuscate their
+   intended destinations by using alternative DNS resolution services
+   (e.g., OpenNIC [OPENNIC]), by using encrypted DNS protocols such as
+   DNS-over-HTTPS [OILRIG], or by performing transformation operations
+   on resolved IP addresses to determine the real C2 server address
+   encoded in the DNS response [LAZARUS].
+
+5.1.3.  Completeness
+
+   In many cases, the list of indicators resulting from an activity or
+   discovered in a malware sample is relatively short and so only adds
+   to the total set of all indicators in a limited and finite manner.  A
+   clear example of this is when static indicators for C2 servers are
+   discovered in a malware strain.  Sharing, deployment, and detection
+   will often not be greatly impacted by the addition of such indicators
+   for one more incident or one more sample.  However, in the case of
+   discovery of a DGA, this requires a reimplementation of the algorithm
+   and then execution to generate a possible list of domains.  Depending
+   on the algorithm, this can result in very large lists of indicators,
+   which may cause performance degradation, particularly during
+   detection.  In some cases, such sources of indicators can lead to a
+   pragmatic decision being made between obtaining reasonable coverage
+   of the possible indicator values and theoretical completeness of a
+   list of all possible indicator values.
+
+5.2.  Precision
+
+5.2.1.  Specificity
+
+   Alongside pain and fragility, the PoP's levels can also be considered
+   in terms of how precise the defence can be, with the false positive
+   rate usually increasing as we move up the pyramid to less specific
+   IoCs.  A hash value identifies a particular file, such as an
+   executable binary, and given a suitable cryptographic hash function,
+   the false positives are effectively nil (by "suitable", we mean one
+   with preimage resistance and strong collision resistance).  In
+   comparison, IoCs in the upper levels (such as some network artefacts
+   or tool fingerprints) may apply to various malicious binaries, and
+   even benign software may share the same identifying characteristics.
+   For example, threat actor tools making web requests may be identified
+   by the user-agent string specified in the request header.  However,
+   this value may be the same as that used by legitimate software,
+   either by the attacker's choice or through use of a common library.
+
+   It should come as no surprise that the more specific an IoC, the more
+   fragile it is; as things change, they move outside of that specific
+   focus.  While less fragile IoCs may be desirable for their robustness
+   and longevity, this must be balanced with the increased chance of
+   false positives from their broadness.  One way in which this balance
+   is achieved is by grouping indicators and using them in combination.
+   While two low-specificity IoCs for a particular attack may each have
+   chances of false positives, when observed together, they may provide
+   greater confidence of an accurate detection of the relevant kill
+   chain.
+
+5.2.2.  Dual and Compromised Use
+
+   As noted in Section 3.2.2, the context of an IoC, such as the way in
+   which the attacker uses it, may equally impact the precision with
+   which that IoC detects an attack.  An IP address representing an
+   attacker's staging server, from which their attack chain downloads
+   subsequent payloads, offers a precise IP address for attacker-owned
+   infrastructure.  However, it will be less precise if that IP address
+   is associated with a cloud-hosting provider and is regularly
+   reassigned from one user to another; it will be less precise still if
+   the attacker compromised a legitimate web server and is abusing the
+   IP address alongside the ongoing legitimate use.
+
+   Similarly, a file hash representing an attacker's custom remote
+   access trojan will be very precise; however, a file hash representing
+   a common enterprise remote administration tool will be less precise,
+   depending on whether or not the defender organisation usually uses
+   that tool for legitimate system administration.  Notably, such dual-
+   use indicators are context specific, considering both whether they
+   are usually used legitimately and how they are used in a particular
+   circumstance.  Use of the remote administration tool may be
+   legitimate for support staff during working hours but not generally
+   by non-support staff, particularly if observed outside of that
+   employee's usual working hours.
+
+   For reasons like these, context is very important when sharing and
+   using IoCs.
+
+5.2.3.  Changing Use
+
+   In the case of IP addresses, the growing adoption of cloud services,
+   proxies, virtual private networks (VPNs), and carrier-grade Network
+   Address Translation (NAT) are increasing the number of systems
+   associated with any one IP address at the same moment in time.  This
+   ongoing change to the use of IP addresses is somewhat reducing the
+   specificity of IP addresses (at least for specific subnets or
+   individual addresses) while also "side-stepping" the pain that threat
+   actors would otherwise incur if they needed to change IP address.
+
+5.3.  Privacy
+
+   As noted in Section 3.2.2, context is critical to effective detection
+   using IoCs.  However, at times, defenders may feel there are privacy
+   concerns with how much and with whom to share about a cyber
+   intrusion.  For example, defenders may generalise the IoCs'
+   description of the attack by removing context to facilitate sharing.
+   This generalisation can result in an incomplete set of IoCs being
+   shared or IoCs being shared without clear indication of what they
+   represent and how they are involved in an attack.  The sharer will
+   consider the privacy trade-off when generalising the IoC and should
+   bear in mind that the loss of context can greatly reduce the utility
+   of the IoC for those they share with.
+
+   In the authors' experiences, self-censoring by sharers appears more
+   prevalent and more extensive when sharing IoCs into groups with more
+   members, into groups with a broader range of perceived member
+   expertise (particularly, the further the lower bound extends below
+   the sharer's perceived own expertise), and into groups that do not
+   maintain strong intermember trust.  Trust within such groups often
+   appears strongest where members interact regularly; have common
+   backgrounds, expertise, or challenges; conform to behavioural
+   expectations (such as by following defined handling requirements and
+   not misrepresenting material they share); and reciprocate the sharing
+   and support they receive.  [LITREVIEW] highlights that many of these
+   factors are associated with the human role in Cyber Threat
+   Intelligence (CTI) sharing.
+
+5.4.  Automation
+
+   While IoCs can be effectively utilised by organisations of various
+   sizes and resource constraints, as discussed in Section 4.1.2,
+   automation of IoC ingestion, processing, assessment, and deployment
+   is critical for managing them at scale.  Manual oversight and
+   investigation may be necessary intermittently, but a reliance on
+   manual processing and searching only works at small scale or for
+   occasional cases.
+
+   The adoption of automation can also enable faster and easier
+   correlation of IoC detections across different log sources and
+   network monitoring interfaces across different times and physical
+   locations.  Thus, the response can be tailored to reflect the number
+   and overlap of detections from a particular intrusion set, and the
+   necessary context can be presented alongside the detection when
+   generating any alerts for defender review.  While manual processing
+   and searching may be no less accurate (although IoC transcription
+   errors are a common problem during busy incidents in the experience
+   of the authors), the correlation and cross-referencing necessary to
+   provide the same degree of situational awareness is much more time-
+   consuming.
+
+   A third important consideration when performing manual processing is
+   the longer phase monitoring and adjustment necessary to effectively
+   age out IoCs as they become irrelevant or, more crucially,
+   inaccurate.  Manual implementations must often simply include or
+   exclude an IoC, as anything more granular is time-consuming and
+   complicated to manage.  In contrast, automations can support a
+   gradual reduction in confidence scoring, enabling IoCs to contribute
+   but not individually disrupt a detection as their specificity
+   reduces.
+
+6.  Comprehensive Coverage and Defence-in-Depth
+
+   IoCs provide the defender with a range of options across the PoP's
+   layers, enabling them to balance precision and fragility to give high
+   confidence detections that are practical and useful.  Broad coverage
+   of the PoP is important as it allows the defender to choose between
+   high precision but high fragility options and more robust but less
+   precise indicators depending on availability.  As fragile indicators
+   are changed, the more robust IoCs allow for continued detection and
+   faster rediscovery.  For this reason, it's important to collect as
+   many IoCs as possible across the whole PoP to provide options for
+   defenders.
+
+   At the top of the PoP, TTPs identified through anomaly detection and
+   machine learning are more likely to have false positives, which gives
+   lower confidence and, vitally, requires better trained analysts to
+   understand and implement the defences.  However, these are very
+   painful for attackers to change, so when tuned appropriately, they
+   provide a robust detection.  Hashes, at the bottom, are precise and
+   easy to deploy but are fragile and easily changed within and across
+   campaigns by malicious actors.
+
+   Endpoint Detection and Response (EDR) or Antivirus (AV) are often the
+   first port of call for protection from intrusion, but endpoint
+   solutions aren't a panacea.  One issue is that there are many
+   environments where it is not possible to keep them updated or, in
+   some cases, deploy them at all.  For example, the Owari botnet, a
+   Mirai variant [Owari], exploited Internet of Things (IoT) devices
+   where such solutions could not be deployed.  It is because of such
+   gaps, where endpoint solutions can't be relied on, that a defence-in-
+   depth approach is commonly advised, using a blended approach that
+   includes both network and endpoint defences.
+
+   If an attack happens, then the best situation is that an endpoint
+   solution will detect and prevent it.  If it doesn't, it could be for
+   many good reasons: the endpoint solution could be quite conservative
+   and aim for a low false-positive rate, it might not have ubiquitous
+   coverage, or it might only be able to defend the initial step of the
+   kill chain [KillChain].  In the worst cases, the attack specifically
+   disables the endpoint solution, or the malware is brand new and so
+   won't be recognised.
+
+   In the middle of the pyramid, IoCs related to network information
+   (such as domains and IP addresses) can be particularly useful.  They
+   allow for broad coverage, without requiring each and every endpoint
+   security solution to be updated, as they may be detected and enforced
+   in a more centralised manner at network choke points (such as proxies
+   and gateways).  This makes them particularly useful in contexts where
+   ensuring endpoint security isn't possible, such as Bring Your Own
+   Device (BYOD), Internet of Things (IoT), and legacy environments.
+   It's important to note that these network-level IoCs can also protect
+   users of a network against compromised endpoints when these IoCs are
+   used to detect the attack in network traffic, even if the compromise
+   itself passes unnoticed.  For example, in a BYOD environment,
+   enforcing security policies on the device can be difficult, so non-
+   endpoint IoCs and solutions are needed to allow detection of
+   compromise even with no endpoint coverage.
+
+   One example of how network-level IoCs provide a layer of a defence-
+   in-depth solution is Protective DNS (PDNS) [Annual2021], a free and
+   voluntary DNS filtering service provided by the UK NCSC for UK public
+   sector organisations [PDNS].  In 2021, this service blocked access to
+   more than 160 million DNS queries (out of 602 billion total queries)
+   for the organisations signed up to the service [ACD2021].  This
+   included hundreds of thousands of queries for domains associated with
+   Flubot, Android malware that uses DGAs to generate 25,000 candidate
+   command and control domains each month (these DGAs [DGAs] are a type
+   of TTP).
+
+   IoCs such as malicious domains can be put on PDNS straight away and
+   can then be used to prevent access to those known malicious domains
+   across the entire estate of over 925 separate public sector entities
+   that use NCSC's PDNS.  Coverage can be patchy with endpoints, as the
+   roll-out of protections isn't uniform or necessarily fast.  However,
+   if the IoC is on PDNS, a consistent defence is maintained for devices
+   using PDNS, even if the device itself is not immediately updated.
+   This offers protection, regardless of whether the context is a BYOD
+   environment or a managed enterprise system.  PDNS provides the most
+   front-facing layer of defence-in-depth solutions for its users, but
+   other IoCs, like Server Name Indication values in TLS or the server
+   certificate information, also provide IoC protections at other
+   layers.
+
+   Similar to the AV scenario, large-scale services face risk decisions
+   around balancing threat against business impact from false positives.
+   Organisations need to be able to retain the ability to be more
+   conservative with their own defences, while still benefiting from
+   them.  For instance, a commercial DNS filtering service is intended
+   for broad deployment, so it will have a risk tolerance similar to AV
+   products, whereas DNS filtering intended for government users (e.g.,
+   PDNS) can be more conservative but will still have a relatively broad
+   deployment if intended for the whole of government.  A government
+   department or specific company, on the other hand, might accept the
+   risk of disruption and arrange firewalls or other network protection
+   devices to completely block anything related to particular threats,
+   regardless of the confidence, but rely on a DNS filtering service for
+   everything else.
+
+   Other network defences can make use of this blanket coverage from
+   IoCs, like middlebox mitigation, proxy defences, and application-
+   layer firewalls, but are out of scope for this document.  Large
+   enterprise networks are likely to deploy their own DNS resolution
+   architecture and possibly TLS inspection proxies and can deploy IoCs
+   in these locations.  However, in networks that choose not to, or
+   don't have the resources to, deploy these sorts of mitigations, DNS
+   goes through firewalls, proxies, and possibly a DNS filtering
+   service; it doesn't have to be unencrypted, but these appliances must
+   be able to decrypt it to do anything useful with it, like blocking
+   queries for known bad URIs.
+
+   Covering a broad range of IoCs gives defenders a wide range of
+   benefits: they are easy to deploy; they provide a high enough
+   confidence to be effective; at least some will be painful for
+   attackers to change; and their distribution around the infrastructure
+   allows for different points of failure, and so overall they enable
+   the defenders to disrupt bad actors.  The combination of these
+   factors cements IoCs as a particularly valuable tool for defenders
+   with limited resources.
+
+7.  IANA Considerations
+
+   This document has no IANA actions.
+
+8.  Security Considerations
+
+   This document is all about system security.  However, when poorly
+   deployed, IoCs can lead to over-blocking, which may present an
+   availability concern for some systems.  While IoCs preserve privacy
+   on a macro scale (by preventing data breaches), research could be
+   done to investigate the impact on privacy from sharing IoCs, and
+   improvements could be made to minimise any impact found.  The
+   creation of a privacy-preserving method of sharing IoCs that still
+   allows both network and endpoint defences to provide security and
+   layered defences would be an interesting proposal.
+
+9.  Conclusions
+
+   IoCs are versatile and powerful.  IoCs underpin and enable multiple
+   layers of the modern defence-in-depth strategy.  IoCs are easy to
+   share, providing a multiplier effect on attack defence efforts, and
+   they save vital time.  Network-level IoCs offer protection, which is
+   especially valuable when an endpoint-only solution isn't sufficient.
+   These properties, along with their ease of use, make IoCs a key
+   component of any attack defence strategy and particularly valuable
+   for defenders with limited resources.
+
+   For IoCs to be useful, they don't have to be unencrypted or visible
+   in networks, but it is crucial that they be made available, along
+   with their context, to entities that need them.  It is also important
+   that this availability and eventual usage cope with multiple points
+   of failure, as per the defence-in-depth strategy, of which IoCs are a
+   key part.
+
+10.  Informative References
+
+   [ACD2021]  UK NCSC, "Active Cyber Defence - The Fifth Year", May
+              2022, <https://www.ncsc.gov.uk/files/ACD-The-Fifth-Year-
+              full-report.pdf>.
+
+   [ADS]      Microsoft, "File Streams (Local File Systems)", January
+              2021, <https://docs.microsoft.com/en-
+              us/windows/win32/fileio/file-streams>.
+
+   [ALIENVAULT]
+              AlienVault, "AlienVault: The World's First Truly Open
+              Threat Intelligence Community",
+              <https://otx.alienvault.com/>.
+
+   [Annual2021]
+              UK NCSC, "NCSC Annual Review 2021: Making the UK the
+              safest place to live and work online", 2021,
+              <https://www.ncsc.gov.uk/files/
+              NCSC%20Annual%20Review%202021.pdf>.
+
+   [CISA]     CISA, "Iranian Government-Sponsored APT Cyber Actors
+              Exploiting Microsoft Exchange and Fortinet Vulnerabilities
+              in Furtherance of Malicious Activities", November 2021,
+              <https://www.cisa.gov/uscert/ncas/alerts/aa21-321a>.
+
+   [COBALT]   "Cobalt Strike", <https://www.cobaltstrike.com/>.
+
+   [DFRONT]   Infosec, "Domain Fronting", April 2017,
+              <https://resources.infosecinstitute.com/topic/domain-
+              fronting/>.
+
+   [DGAs]     MITRE, "Dynamic Resolution: Domain Generation Algorithms",
+              2020, <https://attack.mitre.org/techniques/T1483/>.
+
+   [FireEye]  O'Leary, J., Kimble, J., Vanderlee, K., and N. Fraser,
+              "Insights into Iranian Cyber Espionage: APT33 Targets
+              Aerospace and Energy Sectors and has Ties to Destructive
+              Malware", September 2017,
+              <https://www.mandiant.com/resources/blog/apt33-insights-
+              into-iranian-cyber-espionage>.
+
+   [FireEye2] Ackerman, G., Cole, R., Thompson, A., Orleans, A., and N.
+              Carr, "OVERRULED: Containing a Potentially Destructive
+              Adversary", December 2018,
+              <https://www.mandiant.com/resources/blog/overruled-
+              containing-a-potentially-destructive-adversary>.
+
+   [GoldenTicket]
+              Mizrahi, I. and Cymptom, "Steal or Forge Kerberos Tickets:
+              Golden Ticket", 2020,
+              <https://attack.mitre.org/techniques/T1558/001/>.
+
+   [KillChain]
+              Lockheed Martin, "The Cyber Kill Chain",
+              <https://www.lockheedmartin.com/en-us/capabilities/cyber/
+              cyber-kill-chain.html>.
+
+   [LAZARUS]  Kaspersky Lab, "Lazarus Under The Hood",
+              <https://media.kasperskycontenthub.com/wp-
+              content/uploads/sites/43/2018/03/07180244/
+              Lazarus_Under_The_Hood_PDF_final.pdf>.
+
+   [LITREVIEW]
+              Wagner, T., Mahbub, K., Palomar, E., and A. Abdallah,
+              "Cyber Threat Intelligence Sharing: Survey and Research
+              Directions", January 2019, <https://www.open-
+              access.bcu.ac.uk/7852/1/Cyber%20Threat%20Intelligence%20Sh
+              aring%20Survey%20and%20Research%20Directions.pdf>.
+
+   [Mimikatz] Mulder, J., "Mimikatz Overview, Defenses and Detection",
+              February 2016, <https://www.sans.org/white-papers/36780/>.
+
+   [MISP]     "MISP", <https://www.misp-project.org/>.
+
+   [MISPCORE] Dulaunoy, A. and A. Iklody, "MISP core format", Work in
+              Progress, Internet-Draft, draft-dulaunoy-misp-core-format-
+              16, 26 February 2023,
+              <https://datatracker.ietf.org/doc/html/draft-dulaunoy-
+              misp-core-format-16>.
+
+   [NCCGroup] Jansen, W., "Abusing cloud services to fly under the
+              radar", January 2021,
+              <https://research.nccgroup.com/2021/01/12/abusing-cloud-
+              services-to-fly-under-the-radar/>.
+
+   [NIST]     NIST, "Glossary - security control",
+              <https://csrc.nist.gov/glossary/term/security_control>.
+
+   [OILRIG]   Cimpanu, C., "Iranian hacker group becomes first known APT
+              to weaponize DNS-over-HTTPS (DoH)", August 2020,
+              <https://www.zdnet.com/article/iranian-hacker-group-
+              becomes-first-known-apt-to-weaponize-dns-over-https-doh/>.
+
+   [OPENIOC]  Gibb, W. and D. Kerr, "OpenIOC: Back to the Basics",
+              October 2013, <https://www.fireeye.com/blog/threat-
+              research/2013/10/openioc-basics.html>.
+
+   [OPENNIC]  "OpenNIC", <https://www.opennic.org/>.
+
+   [Owari]    UK NCSC, "Owari botnet own-goal takeover", 2018, <https://
+              webarchive.nationalarchives.gov.uk/ukgwa/20220301141030/
+              https://www.ncsc.gov.uk/report/weekly-threat-report-8th-
+              june-2018>.
+
+   [PDNS]     UK NCSC, "Protective Domain Name Service (PDNS)", August
+              2017, <https://www.ncsc.gov.uk/information/pdns>.
+
+   [PoP]      Bianco, D., "The Pyramid of Pain", March 2013,
+              <https://detect-respond.blogspot.com/2013/03/the-pyramid-
+              of-pain.html>.
+
+   [RFC7970]  Danyliw, R., "The Incident Object Description Exchange
+              Format Version 2", RFC 7970, DOI 10.17487/RFC7970,
+              November 2016, <https://www.rfc-editor.org/info/rfc7970>.
+
+   [RULER]    MITRE, "Ruler",
+              <https://attack.mitre.org/software/S0358/>.
+
+   [STIX]     OASIS Cyber Threat Intelligence (CTI), "Introduction to
+              STIX", <https://oasis-open.github.io/cti-
+              documentation/stix/intro>.
+
+   [Symantec] Symantec, "Elfin: Relentless Espionage Group Targets
+              Multiple Organizations in Saudi Arabia and U.S.", March
+              2019, <https://www.symantec.com/blogs/threat-intelligence/
+              elfin-apt33-espionage>.
+
+   [TAXII]    OASIS Cyber Threat Intelligence (CTI), "Introduction to
+              TAXII", <https://oasis-open.github.io/cti-
+              documentation/taxii/intro.html>.
+
+   [Timestomp]
+              MITRE, "Indicator Removal: Timestomp", January 2020,
+              <https://attack.mitre.org/techniques/T1099/>.
+
+   [TLP]      FIRST, "Traffic Light Protocol (TLP)",
+              <https://www.first.org/tlp/>.
+
+Acknowledgements
+
+   Thanks to all those who have been involved with improving cyber
+   defence in the IETF and IRTF communities.
+
+Authors' Addresses
+
+   Kirsty Paine
+   Splunk Inc.
+   Email: kirsty.ietf@gmail.com
+
+
+   Ollie Whitehouse
+   Binary Firefly
+   Email: ollie@binaryfirefly.com
+
+
+   James Sellwood
+   Email: james.sellwood.ietf@gmail.com
+
+
+   Andrew Shaw
+   UK National Cyber Security Centre
+   Email: andrew.s2@ncsc.gov.uk