<?xml version='1.0' encoding='utf-8'?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" version="3" category="info" ipr="trust200902" number="9424" docName="draft-ietf-opsec-indicators-of-compromise-04" obsoletes="" updates="" submissionType="IETF" consensus="true" xml:lang="en" tocInclude="true" tocDepth="4" symRefs="true" sortRefs="true" prepTime="2023-08-11T20:46:29" indexInclude="true" scripts="Common,Latin">
  <link href="https://datatracker.ietf.org/doc/draft-ietf-opsec-indicators-of-compromise-04" rel="prev"/>
  <link href="https://dx.doi.org/10.17487/rfc9424" rel="alternate"/>
  <link href="urn:issn:2070-1721" rel="alternate"/>
  <front>
    <title abbrev="Indicators of Compromise">Indicators of Compromise (IoCs) and Their Role in Attack Defence</title>
    <seriesInfo name="RFC" value="9424" stream="IETF"/>
    <author fullname="Kirsty Paine" initials="K." surname="Paine">
      <organization showOnFrontPage="true">Splunk Inc.</organization>
      <address>
        <email>kirsty.ietf@gmail.com</email>
      </address>
    </author>
    <author fullname="Ollie Whitehouse" initials="O." surname="Whitehouse">
      <organization showOnFrontPage="true">Binary Firefly</organization>
      <address>
        <email>ollie@binaryfirefly.com</email>
      </address>
    </author>
    <author fullname="James Sellwood" initials="J." surname="Sellwood">
      <address>
        <email>james.sellwood.ietf@gmail.com</email>
      </address>
    </author>
    <author fullname="Andrew Shaw" initials="A." surname="Shaw">
      <organization showOnFrontPage="true">UK National Cyber Security Centre</organization>
      <address>
        <email>andrew.s2@ncsc.gov.uk</email>
      </address>
    </author>
    <date month="08" year="2023"/>
    <area>General</area>
    <workgroup>OPSEC</workgroup>
    <keyword>IoC</keyword>
    <keyword>Attack Defence</keyword>
    <abstract pn="section-abstract">
      <t indent="0" pn="section-abstract-1">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.</t>
    </abstract>
    <boilerplate>
      <section anchor="status-of-memo" numbered="false" removeInRFC="false" toc="exclude" pn="section-boilerplate.1">
        <name slugifiedName="name-status-of-this-memo">Status of This Memo</name>
        <t indent="0" pn="section-boilerplate.1-1">
            This document is not an Internet Standards Track specification; it is
            published for informational purposes.  
        </t>
        <t indent="0" pn="section-boilerplate.1-2">
            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. 
        </t>
        <t indent="0" pn="section-boilerplate.1-3">
            Information about the current status of this document, any
            errata, and how to provide feedback on it may be obtained at
            <eref target="https://www.rfc-editor.org/info/rfc9424" brackets="none"/>.
        </t>
      </section>
      <section anchor="copyright" numbered="false" removeInRFC="false" toc="exclude" pn="section-boilerplate.2">
        <name slugifiedName="name-copyright-notice">Copyright Notice</name>
        <t indent="0" pn="section-boilerplate.2-1">
            Copyright (c) 2023 IETF Trust and the persons identified as the
            document authors. All rights reserved.
        </t>
        <t indent="0" pn="section-boilerplate.2-2">
            This document is subject to BCP 78 and the IETF Trust's Legal
            Provisions Relating to IETF Documents
            (<eref target="https://trustee.ietf.org/license-info" brackets="none"/>) 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.
        </t>
      </section>
    </boilerplate>
    <toc>
      <section anchor="toc" numbered="false" removeInRFC="false" toc="exclude" pn="section-toc.1">
        <name slugifiedName="name-table-of-contents">Table of Contents</name>
        <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1">
          <li pn="section-toc.1-1.1">
            <t indent="0" keepWithNext="true" pn="section-toc.1-1.1.1"><xref derivedContent="1" format="counter" sectionFormat="of" target="section-1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-introduction">Introduction</xref></t>
          </li>
          <li pn="section-toc.1-1.2">
            <t indent="0" keepWithNext="true" pn="section-toc.1-1.2.1"><xref derivedContent="2" format="counter" sectionFormat="of" target="section-2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-terminology">Terminology</xref></t>
          </li>
          <li pn="section-toc.1-1.3">
            <t indent="0" pn="section-toc.1-1.3.1"><xref derivedContent="3" format="counter" sectionFormat="of" target="section-3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-ioc-fundamentals">IoC Fundamentals</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.3.2">
              <li pn="section-toc.1-1.3.2.1">
                <t indent="0" keepWithNext="true" pn="section-toc.1-1.3.2.1.1"><xref derivedContent="3.1" format="counter" sectionFormat="of" target="section-3.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-ioc-types-and-the-pyramid-o">IoC Types and the Pyramid of Pain</xref></t>
              </li>
              <li pn="section-toc.1-1.3.2.2">
                <t indent="0" pn="section-toc.1-1.3.2.2.1"><xref derivedContent="3.2" format="counter" sectionFormat="of" target="section-3.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-ioc-lifecycle">IoC Lifecycle</xref></t>
                <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.3.2.2.2">
                  <li pn="section-toc.1-1.3.2.2.2.1">
                    <t indent="0" pn="section-toc.1-1.3.2.2.2.1.1"><xref derivedContent="3.2.1" format="counter" sectionFormat="of" target="section-3.2.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-discovery">Discovery</xref></t>
                  </li>
                  <li pn="section-toc.1-1.3.2.2.2.2">
                    <t indent="0" pn="section-toc.1-1.3.2.2.2.2.1"><xref derivedContent="3.2.2" format="counter" sectionFormat="of" target="section-3.2.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-assessment">Assessment</xref></t>
                  </li>
                  <li pn="section-toc.1-1.3.2.2.2.3">
                    <t indent="0" pn="section-toc.1-1.3.2.2.2.3.1"><xref derivedContent="3.2.3" format="counter" sectionFormat="of" target="section-3.2.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-sharing">Sharing</xref></t>
                  </li>
                  <li pn="section-toc.1-1.3.2.2.2.4">
                    <t indent="0" pn="section-toc.1-1.3.2.2.2.4.1"><xref derivedContent="3.2.4" format="counter" sectionFormat="of" target="section-3.2.4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-deployment">Deployment</xref></t>
                  </li>
                  <li pn="section-toc.1-1.3.2.2.2.5">
                    <t indent="0" pn="section-toc.1-1.3.2.2.2.5.1"><xref derivedContent="3.2.5" format="counter" sectionFormat="of" target="section-3.2.5"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-detection">Detection</xref></t>
                  </li>
                  <li pn="section-toc.1-1.3.2.2.2.6">
                    <t indent="0" pn="section-toc.1-1.3.2.2.2.6.1"><xref derivedContent="3.2.6" format="counter" sectionFormat="of" target="section-3.2.6"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-reaction">Reaction</xref></t>
                  </li>
                  <li pn="section-toc.1-1.3.2.2.2.7">
                    <t indent="0" pn="section-toc.1-1.3.2.2.2.7.1"><xref derivedContent="3.2.7" format="counter" sectionFormat="of" target="section-3.2.7"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-end-of-life">End of Life</xref></t>
                  </li>
                </ul>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.4">
            <t indent="0" pn="section-toc.1-1.4.1"><xref derivedContent="4" format="counter" sectionFormat="of" target="section-4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-using-iocs-effectively">Using IoCs Effectively</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.4.2">
              <li pn="section-toc.1-1.4.2.1">
                <t indent="0" pn="section-toc.1-1.4.2.1.1"><xref derivedContent="4.1" format="counter" sectionFormat="of" target="section-4.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-opportunities">Opportunities</xref></t>
                <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.4.2.1.2">
                  <li pn="section-toc.1-1.4.2.1.2.1">
                    <t indent="0" pn="section-toc.1-1.4.2.1.2.1.1"><xref derivedContent="4.1.1" format="counter" sectionFormat="of" target="section-4.1.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-iocs-underpin-and-enable-mu">IoCs underpin and enable multiple layers of the modern defence-in-depth strategy.</xref></t>
                  </li>
                  <li pn="section-toc.1-1.4.2.1.2.2">
                    <t indent="0" pn="section-toc.1-1.4.2.1.2.2.1"><xref derivedContent="4.1.2" format="counter" sectionFormat="of" target="section-4.1.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-iocs-can-be-used-even-with-">IoCs can be used even with limited resources.</xref></t>
                  </li>
                  <li pn="section-toc.1-1.4.2.1.2.3">
                    <t indent="0" pn="section-toc.1-1.4.2.1.2.3.1"><xref derivedContent="4.1.3" format="counter" sectionFormat="of" target="section-4.1.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-iocs-have-a-multiplier-effe">IoCs have a multiplier effect on attack defence efforts within
          an organisation.</xref></t>
                  </li>
                  <li pn="section-toc.1-1.4.2.1.2.4">
                    <t indent="0" pn="section-toc.1-1.4.2.1.2.4.1"><xref derivedContent="4.1.4" format="counter" sectionFormat="of" target="section-4.1.4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-iocs-are-easily-shared-betw">IoCs are easily shared between organisations.</xref></t>
                  </li>
                  <li pn="section-toc.1-1.4.2.1.2.5">
                    <t indent="0" pn="section-toc.1-1.4.2.1.2.5.1"><xref derivedContent="4.1.5" format="counter" sectionFormat="of" target="section-4.1.5"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-iocs-can-provide-significan">IoCs can provide significant time savings.</xref></t>
                  </li>
                  <li pn="section-toc.1-1.4.2.1.2.6">
                    <t indent="0" pn="section-toc.1-1.4.2.1.2.6.1"><xref derivedContent="4.1.6" format="counter" sectionFormat="of" target="section-4.1.6"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-iocs-allow-for-discovery-of">IoCs allow for discovery of historic attacks.</xref></t>
                  </li>
                  <li pn="section-toc.1-1.4.2.1.2.7">
                    <t indent="0" pn="section-toc.1-1.4.2.1.2.7.1"><xref derivedContent="4.1.7" format="counter" sectionFormat="of" target="section-4.1.7"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-iocs-can-be-attributed-to-s">IoCs can be attributed to specific threats.</xref></t>
                  </li>
                </ul>
              </li>
              <li pn="section-toc.1-1.4.2.2">
                <t indent="0" pn="section-toc.1-1.4.2.2.1"><xref derivedContent="4.2" format="counter" sectionFormat="of" target="section-4.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-case-studies">Case Studies</xref></t>
                <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.4.2.2.2">
                  <li pn="section-toc.1-1.4.2.2.2.1">
                    <t indent="0" pn="section-toc.1-1.4.2.2.2.1.1"><xref derivedContent="4.2.1" format="counter" sectionFormat="of" target="section-4.2.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-cobalt-strike">Cobalt Strike</xref></t>
                    <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.4.2.2.2.1.2">
                      <li pn="section-toc.1-1.4.2.2.2.1.2.1">
                        <t indent="0" pn="section-toc.1-1.4.2.2.2.1.2.1.1"><xref derivedContent="4.2.1.1" format="counter" sectionFormat="of" target="section-4.2.1.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-overall-ttp">Overall TTP</xref></t>
                      </li>
                      <li pn="section-toc.1-1.4.2.2.2.1.2.2">
                        <t indent="0" pn="section-toc.1-1.4.2.2.2.1.2.2.1"><xref derivedContent="4.2.1.2" format="counter" sectionFormat="of" target="section-4.2.1.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-iocs">IoCs</xref></t>
                      </li>
                    </ul>
                  </li>
                  <li pn="section-toc.1-1.4.2.2.2.2">
                    <t indent="0" pn="section-toc.1-1.4.2.2.2.2.1"><xref derivedContent="4.2.2" format="counter" sectionFormat="of" target="section-4.2.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-apt33">APT33</xref></t>
                    <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.4.2.2.2.2.2">
                      <li pn="section-toc.1-1.4.2.2.2.2.2.1">
                        <t indent="0" pn="section-toc.1-1.4.2.2.2.2.2.1.1"><xref derivedContent="4.2.2.1" format="counter" sectionFormat="of" target="section-4.2.2.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-overall-ttp-2">Overall TTP</xref></t>
                      </li>
                      <li pn="section-toc.1-1.4.2.2.2.2.2.2">
                        <t indent="0" pn="section-toc.1-1.4.2.2.2.2.2.2.1"><xref derivedContent="4.2.2.2" format="counter" sectionFormat="of" target="section-4.2.2.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-iocs-2">IoCs</xref></t>
                      </li>
                    </ul>
                  </li>
                </ul>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.5">
            <t indent="0" pn="section-toc.1-1.5.1"><xref derivedContent="5" format="counter" sectionFormat="of" target="section-5"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-operational-limitations">Operational Limitations</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.5.2">
              <li pn="section-toc.1-1.5.2.1">
                <t indent="0" pn="section-toc.1-1.5.2.1.1"><xref derivedContent="5.1" format="counter" sectionFormat="of" target="section-5.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-time-and-effort">Time and Effort</xref></t>
                <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.5.2.1.2">
                  <li pn="section-toc.1-1.5.2.1.2.1">
                    <t indent="0" pn="section-toc.1-1.5.2.1.2.1.1"><xref derivedContent="5.1.1" format="counter" sectionFormat="of" target="section-5.1.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-fragility">Fragility</xref></t>
                  </li>
                  <li pn="section-toc.1-1.5.2.1.2.2">
                    <t indent="0" pn="section-toc.1-1.5.2.1.2.2.1"><xref derivedContent="5.1.2" format="counter" sectionFormat="of" target="section-5.1.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-discoverability">Discoverability</xref></t>
                  </li>
                  <li pn="section-toc.1-1.5.2.1.2.3">
                    <t indent="0" pn="section-toc.1-1.5.2.1.2.3.1"><xref derivedContent="5.1.3" format="counter" sectionFormat="of" target="section-5.1.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-completeness">Completeness</xref></t>
                  </li>
                </ul>
              </li>
              <li pn="section-toc.1-1.5.2.2">
                <t indent="0" pn="section-toc.1-1.5.2.2.1"><xref derivedContent="5.2" format="counter" sectionFormat="of" target="section-5.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-precision">Precision</xref></t>
                <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.5.2.2.2">
                  <li pn="section-toc.1-1.5.2.2.2.1">
                    <t indent="0" pn="section-toc.1-1.5.2.2.2.1.1"><xref derivedContent="5.2.1" format="counter" sectionFormat="of" target="section-5.2.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-specificity">Specificity</xref></t>
                  </li>
                  <li pn="section-toc.1-1.5.2.2.2.2">
                    <t indent="0" pn="section-toc.1-1.5.2.2.2.2.1"><xref derivedContent="5.2.2" format="counter" sectionFormat="of" target="section-5.2.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-dual-and-compromised-use">Dual and Compromised Use</xref></t>
                  </li>
                  <li pn="section-toc.1-1.5.2.2.2.3">
                    <t indent="0" pn="section-toc.1-1.5.2.2.2.3.1"><xref derivedContent="5.2.3" format="counter" sectionFormat="of" target="section-5.2.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-changing-use">Changing Use</xref></t>
                  </li>
                </ul>
              </li>
              <li pn="section-toc.1-1.5.2.3">
                <t indent="0" pn="section-toc.1-1.5.2.3.1"><xref derivedContent="5.3" format="counter" sectionFormat="of" target="section-5.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-privacy">Privacy</xref></t>
              </li>
              <li pn="section-toc.1-1.5.2.4">
                <t indent="0" pn="section-toc.1-1.5.2.4.1"><xref derivedContent="5.4" format="counter" sectionFormat="of" target="section-5.4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-automation">Automation</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.6">
            <t indent="0" pn="section-toc.1-1.6.1"><xref derivedContent="6" format="counter" sectionFormat="of" target="section-6"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-comprehensive-coverage-and-">Comprehensive Coverage and Defence-in-Depth</xref></t>
          </li>
          <li pn="section-toc.1-1.7">
            <t indent="0" pn="section-toc.1-1.7.1"><xref derivedContent="7" format="counter" sectionFormat="of" target="section-7"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-iana-considerations">IANA Considerations</xref></t>
          </li>
          <li pn="section-toc.1-1.8">
            <t indent="0" pn="section-toc.1-1.8.1"><xref derivedContent="8" format="counter" sectionFormat="of" target="section-8"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-security-considerations">Security Considerations</xref></t>
          </li>
          <li pn="section-toc.1-1.9">
            <t indent="0" pn="section-toc.1-1.9.1"><xref derivedContent="9" format="counter" sectionFormat="of" target="section-9"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-conclusions">Conclusions</xref></t>
          </li>
          <li pn="section-toc.1-1.10">
            <t indent="0" pn="section-toc.1-1.10.1"><xref derivedContent="10" format="counter" sectionFormat="of" target="section-10"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-informative-references">Informative References</xref></t>
          </li>
          <li pn="section-toc.1-1.11">
            <t indent="0" pn="section-toc.1-1.11.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.a"/><xref derivedContent="" format="title" sectionFormat="of" target="name-acknowledgements">Acknowledgements</xref></t>
          </li>
          <li pn="section-toc.1-1.12">
            <t indent="0" pn="section-toc.1-1.12.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.b"/><xref derivedContent="" format="title" sectionFormat="of" target="name-authors-addresses">Authors' Addresses</xref></t>
          </li>
        </ul>
      </section>
    </toc>
  </front>
  <middle>
    <section numbered="true" toc="include" removeInRFC="false" pn="section-1">
      <name slugifiedName="name-introduction">Introduction</name>
      <t indent="0" pn="section-1-1">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 <xref target="PoP" format="default" sectionFormat="of" derivedContent="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, <xref target="Symantec" format="default" sectionFormat="of" derivedContent="Symantec"/> and
      <xref target="NCCGroup" format="default" sectionFormat="of" derivedContent="NCCGroup"/>, respectively). </t>
    </section>
    <section numbered="true" toc="include" removeInRFC="false" pn="section-2">
      <name slugifiedName="name-terminology">Terminology</name>
      <dl newline="true" spacing="normal" indent="3" pn="section-2-1">
        <dt pn="section-2-1.1">Attack defence:</dt>
        <dd pn="section-2-1.2">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. </dd>
        <dt pn="section-2-1.3">Command and control (C2) server:</dt>
        <dd pn="section-2-1.4"> 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".</dd>
        <dt pn="section-2-1.5">Domain Generation Algorithm (DGA):</dt>
        <dd pn="section-2-1.6">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.</dd>
        <dt pn="section-2-1.7">Kill chain:</dt>
        <dd pn="section-2-1.8">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 <xref target="KillChain" format="default" sectionFormat="of" derivedContent="KillChain"/>.</dd>
        <dt pn="section-2-1.9">Tactics, Techniques, and Procedures (TTPs):</dt>
        <dd pn="section-2-1.10">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.</dd>
        <dt pn="section-2-1.11">Control (as defined by US NIST):</dt>
        <dd pn="section-2-1.12">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 <xref target="NIST" format="default" sectionFormat="of" derivedContent="NIST"/>. </dd>
      </dl>
    </section>
    <section anchor="what" numbered="true" toc="include" removeInRFC="false" pn="section-3">
      <name slugifiedName="name-ioc-fundamentals">IoC Fundamentals</name>
      <section anchor="sec-pop" numbered="true" toc="include" removeInRFC="false" pn="section-3.1">
        <name slugifiedName="name-ioc-types-and-the-pyramid-o">IoC Types and the Pyramid of Pain</name>
        <t indent="0" pn="section-3.1-1">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:
        </t>
        <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-3.1-2">
          <li pn="section-3.1-2.1">IPv4 and IPv6 addresses in network traffic</li>
          <li pn="section-3.1-2.2">Fully Qualified Domain Names (FQDNs) in network traffic, DNS
          resolver caches, or logs</li>
          <li pn="section-3.1-2.3">TLS Server Name Indication values in network traffic</li>
          <li pn="section-3.1-2.4">Code-signing certificates in binaries</li>
          <li pn="section-3.1-2.5">TLS certificate information (such as SHA256 hashes) in network
          traffic</li>
          <li pn="section-3.1-2.6">Cryptographic hashes (e.g., MD5, SHA1, or SHA256) of malicious
          binaries or scripts when calculated from network traffic or file
          system artefacts</li>
          <li pn="section-3.1-2.7">Attack tools (such as Mimikatz <xref target="Mimikatz" format="default" sectionFormat="of" derivedContent="Mimikatz"/>) and their code structure and execution
          characteristics</li>
          <li pn="section-3.1-2.8">Attack techniques, such as Kerberos Golden Tickets <xref target="GoldenTicket" format="default" sectionFormat="of" derivedContent="GoldenTicket"/>, that can be observed in
          network traffic or system artefacts</li>
        </ul>
        <t indent="0" pn="section-3.1-3">The common types of IoC form a Pyramid of Pain <xref target="PoP" format="default" sectionFormat="of" derivedContent="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.</t>
        <figure anchor="pop_diagram" align="left" suppress-title="false" pn="figure-1">
          <artwork align="left" name="" type="" alt="" pn="section-3.1-4.1">
                          /\
                         /  \                             MORE PAIN
                        /    \                           LESS FRAGILE
                       /      \                          LESS PRECISE
                      /  TTPs  \
                     /          \                            / \
                    ==============                            |
                   /              \                           |
                  /      Tools     \                          |
                 /                  \                         |
                ======================                        |
               /                      \                       |
              / Network/Host Artefacts \                      |
             /                          \                     |
            ==============================                    |
           /                              \                   |
          /          Domain Names          \                  |
         /                                  \                 |
        ======================================                |
       /                                      \               |
      /              IP Addresses              \              |
     /                                          \            \ /
    ==============================================
   /                                              \       LESS PAIN
  /                   Hash Values                  \     MORE FRAGILE
 /                                                  \    MORE PRECISE
======================================================
</artwork>
        </figure>
        <t indent="0" pn="section-3.1-5">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.</t>
        <t indent="0" pn="section-3.1-6">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 <xref target="sec-operational-limitations" format="default" sectionFormat="of" derivedContent="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.</t>
        <t indent="0" pn="section-3.1-7">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 <xref target="COBALT" format="default" sectionFormat="of" derivedContent="COBALT"/>) or a means by which some artefacts can be masked
        (see <xref target="Timestomp" format="default" sectionFormat="of" derivedContent="Timestomp"/>).</t>
        <t indent="0" pn="section-3.1-8">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.</t>
        <t indent="0" pn="section-3.1-9">The variation in discoverability of IoCs is indicated by the
        numbers of IoCs in AlienVault, an open threat intelligence community
        <xref target="ALIENVAULT" format="default" sectionFormat="of" derivedContent="ALIENVAULT"/>. As of January 2023,
        AlienVault contained:
        </t>
        <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-3.1-10">
          <li pn="section-3.1-10.1">Groups (i.e., combinations of TTPs): 631</li>
          <li pn="section-3.1-10.2">Malware families (i.e., tools): ~27,000</li>
          <li pn="section-3.1-10.3">URL: 2,854,918</li>
          <li pn="section-3.1-10.4">Domain names: 64,769,363</li>
          <li pn="section-3.1-10.5">IPv4 addresses: 5,427,762</li>
          <li pn="section-3.1-10.6">IPv6 addresses: 12,009</li>
          <li pn="section-3.1-10.7">SHA256 hash values: 5,452,442</li>
        </ul>
        <t indent="0" pn="section-3.1-11">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.</t>
      </section>
      <section numbered="true" toc="include" removeInRFC="false" pn="section-3.2">
        <name slugifiedName="name-ioc-lifecycle">IoC Lifecycle</name>
        <t indent="0" pn="section-3.2-1">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.</t>
        <section numbered="true" toc="include" removeInRFC="false" pn="section-3.2.1">
          <name slugifiedName="name-discovery">Discovery</name>
          <t indent="0" pn="section-3.2.1-1">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).</t>
          <t indent="0" pn="section-3.2.1-2">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.</t>
        </section>
        <section anchor="sec-assessment" numbered="true" toc="include" removeInRFC="false" pn="section-3.2.2">
          <name slugifiedName="name-assessment">Assessment</name>
          <t indent="0" pn="section-3.2.2-1">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.</t>
          <t indent="0" pn="section-3.2.2-2">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).</t>
        </section>
        <section anchor="sec-sharing" numbered="true" toc="include" removeInRFC="false" pn="section-3.2.3">
          <name slugifiedName="name-sharing">Sharing</name>
          <t indent="0" pn="section-3.2.3-1">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 <xref target="STIX" format="default" sectionFormat="of" derivedContent="STIX"/>, Malware Information Sharing Platform (MISP) core
          <xref target="I-D.dulaunoy-misp-core-format" format="default" sectionFormat="of" derivedContent="MISPCORE"/>,
          OpenIOC <xref target="OPENIOC" format="default" sectionFormat="of" derivedContent="OPENIOC"/>, and Incident
          Object Description Exchange Format (IODEF) <xref target="RFC7970" format="default" sectionFormat="of" derivedContent="RFC7970"/>. This enables distribution via a structured feed,
          such as one implementing Trusted Automated Exchange of Intelligence
          Information <xref target="TAXII" format="default" sectionFormat="of" derivedContent="TAXII"/>, or through a
          Malware Information Sharing Platform <xref target="MISP" format="default" sectionFormat="of" derivedContent="MISP"/>.</t>
          <t indent="0" pn="section-3.2.3-2">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 <xref target="TLP" format="default" sectionFormat="of" derivedContent="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).</t>
        </section>
        <section numbered="true" toc="include" removeInRFC="false" pn="section-3.2.4">
          <name slugifiedName="name-deployment">Deployment</name>
          <t indent="0" pn="section-3.2.4-1">For IoCs to provide defence-in-depth (see <xref target="depth" format="default" sectionFormat="of" derivedContent="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.</t>
          <t indent="0" pn="section-3.2.4-2">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.</t>
        </section>
        <section anchor="sec-ioc-detection" numbered="true" toc="include" removeInRFC="false" pn="section-3.2.5">
          <name slugifiedName="name-detection">Detection</name>
          <t indent="0" pn="section-3.2.5-1">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.</t>
        </section>
        <section numbered="true" toc="include" removeInRFC="false" pn="section-3.2.6">
          <name slugifiedName="name-reaction">Reaction</name>
          <t indent="0" pn="section-3.2.6-1">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.</t>
        </section>
        <section numbered="true" toc="include" removeInRFC="false" pn="section-3.2.7">
          <name slugifiedName="name-end-of-life">End of Life</name>
          <t indent="0" pn="section-3.2.7-1">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 <xref target="sec-operational-limitations" format="default" sectionFormat="of" derivedContent="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.</t>
        </section>
      </section>
    </section>
    <section numbered="true" toc="include" removeInRFC="false" pn="section-4">
      <name slugifiedName="name-using-iocs-effectively">Using IoCs Effectively</name>
      <section numbered="true" toc="include" removeInRFC="false" pn="section-4.1">
        <name slugifiedName="name-opportunities">Opportunities</name>
        <t indent="0" pn="section-4.1-1">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.</t>
        <section numbered="true" toc="include" removeInRFC="false" pn="section-4.1.1">
          <name slugifiedName="name-iocs-underpin-and-enable-mu">IoCs underpin and enable multiple layers of the modern defence-in-depth strategy.</name>
          <t indent="0" pn="section-4.1.1-1">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.</t>
          <t indent="0" pn="section-4.1.1-2">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.</t>
          <t indent="0" pn="section-4.1.1-3">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.</t>
        </section>
        <section anchor="sec-limited-resources" numbered="true" toc="include" removeInRFC="false" pn="section-4.1.2">
          <name slugifiedName="name-iocs-can-be-used-even-with-">IoCs can be used even with limited resources.</name>
          <t indent="0" pn="section-4.1.2-1">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.</t>
        </section>
        <section numbered="true" toc="include" removeInRFC="false" pn="section-4.1.3">
          <name slugifiedName="name-iocs-have-a-multiplier-effe">IoCs have a multiplier effect on attack defence efforts within
          an organisation.</name>
          <t indent="0" pn="section-4.1.3-1">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.</t>
          <t indent="0" pn="section-4.1.3-2">Multiple organisations may benefit from directly receiving
          shared IoCs (see <xref target="sec-easy-sharing" format="default" sectionFormat="of" derivedContent="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.</t>
        </section>
        <section anchor="sec-easy-sharing" numbered="true" toc="include" removeInRFC="false" pn="section-4.1.4">
          <name slugifiedName="name-iocs-are-easily-shared-betw">IoCs are easily shared between organisations.</name>
          <t indent="0" pn="section-4.1.4-1">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
          <xref target="sec-sharing" format="default" sectionFormat="of" derivedContent="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.</t>
        </section>
        <section numbered="true" toc="include" removeInRFC="false" pn="section-4.1.5">
          <name slugifiedName="name-iocs-can-provide-significan">IoCs can provide significant time savings.</name>
          <t indent="0" pn="section-4.1.5-1">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.</t>
        </section>
        <section numbered="true" toc="include" removeInRFC="false" pn="section-4.1.6">
          <name slugifiedName="name-iocs-allow-for-discovery-of">IoCs allow for discovery of historic attacks.</name>
          <t indent="0" pn="section-4.1.6-1">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
          <xref target="Timestomp" format="default" sectionFormat="of" derivedContent="Timestomp"/>, and not being
          incomplete due to data retention policies, but it is nonetheless
          valuable for detecting and remediating past attacks.</t>
        </section>
        <section numbered="true" toc="include" removeInRFC="false" pn="section-4.1.7">
          <name slugifiedName="name-iocs-can-be-attributed-to-s">IoCs can be attributed to specific threats.</name>
          <t indent="0" pn="section-4.1.7-1">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 <xref target="sec-precision" format="default" sectionFormat="of" derivedContent="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 <xref target="sec-sharing" format="default" sectionFormat="of" derivedContent="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.</t>
        </section>
      </section>
      <section numbered="true" toc="include" removeInRFC="false" pn="section-4.2">
        <name slugifiedName="name-case-studies">Case Studies</name>
        <t indent="0" pn="section-4.2-1">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.</t>
        <section numbered="true" toc="include" removeInRFC="false" pn="section-4.2.1">
          <name slugifiedName="name-cobalt-strike">Cobalt Strike</name>
          <t indent="0" pn="section-4.2.1-1">Cobalt Strike <xref target="COBALT" format="default" sectionFormat="of" derivedContent="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
          <xref target="DFRONT" format="default" sectionFormat="of" derivedContent="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.</t>
          <section numbered="true" toc="include" removeInRFC="false" pn="section-4.2.1.1">
            <name slugifiedName="name-overall-ttp">Overall TTP</name>
            <t indent="0" pn="section-4.2.1.1-1">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.</t>
          </section>
          <section numbered="true" toc="include" removeInRFC="false" pn="section-4.2.1.2">
            <name slugifiedName="name-iocs">IoCs</name>
            <t indent="0" pn="section-4.2.1.2-1">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.</t>
            <t indent="0" pn="section-4.2.1.2-2">The resulting mass IoCs for Cobalt Strike are:
            </t>
            <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-4.2.1.2-3">
              <li pn="section-4.2.1.2-3.1">IP addresses of the C2 servers</li>
              <li pn="section-4.2.1.2-3.2">domain names used</li>
            </ul>
            <t indent="0" pn="section-4.2.1.2-4">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.</t>
            <t indent="0" pn="section-4.2.1.2-5">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.</t>
          </section>
        </section>
        <section numbered="true" toc="include" removeInRFC="false" pn="section-4.2.2">
          <name slugifiedName="name-apt33">APT33</name>
          <t indent="0" pn="section-4.2.2-1">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 <xref target="Symantec" format="default" sectionFormat="of" derivedContent="Symantec"/>). APT33 has
          been assessed by the industry to be a state-sponsored group <xref target="FireEye2" format="default" sectionFormat="of" derivedContent="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.</t>
          <section numbered="true" toc="include" removeInRFC="false" pn="section-4.2.2.1">
            <name slugifiedName="name-overall-ttp-2">Overall TTP</name>
            <t indent="0" pn="section-4.2.2.1-1">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 <xref target="RULER" format="default" sectionFormat="of" derivedContent="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 <xref target="FireEye" format="default" sectionFormat="of" derivedContent="FireEye"/>).</t>
            <t indent="0" pn="section-4.2.2.1-2">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.</t>
          </section>
          <section numbered="true" toc="include" removeInRFC="false" pn="section-4.2.2.2">
            <name slugifiedName="name-iocs-2">IoCs</name>
            <t indent="0" pn="section-4.2.2.2-1">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:
            </t>
            <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-4.2.2.2-2">
              <li pn="section-4.2.2.2-2.1">9 hashes and email subject lines</li>
              <li pn="section-4.2.2.2-2.2">5 IP addresses</li>
              <li pn="section-4.2.2.2-2.3">7 domain names</li>
            </ul>
            <t indent="0" pn="section-4.2.2.2-3">In November 2021, a joint advisory concerning APT33 <xref target="CISA" format="default" sectionFormat="of" derivedContent="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:
            </t>
            <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-4.2.2.2-4">
              <li pn="section-4.2.2.2-4.1">8 hashes of malicious executables</li>
              <li pn="section-4.2.2.2-4.2">3 IP addresses</li>
            </ul>
          </section>
        </section>
      </section>
    </section>
    <section anchor="sec-operational-limitations" numbered="true" toc="include" removeInRFC="false" pn="section-5">
      <name slugifiedName="name-operational-limitations">Operational Limitations</name>
      <t indent="0" pn="section-5-1">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 <xref target="sec-pop" format="default" sectionFormat="of" derivedContent="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.</t>
      <section numbered="true" toc="include" removeInRFC="false" pn="section-5.1">
        <name slugifiedName="name-time-and-effort">Time and Effort</name>
        <section numbered="true" toc="include" removeInRFC="false" pn="section-5.1.1">
          <name slugifiedName="name-fragility">Fragility</name>
          <t indent="0" pn="section-5.1.1-1">As alluded to in <xref target="sec-pop" format="default" sectionFormat="of" derivedContent="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.</t>
          <t indent="0" pn="section-5.1.1-2">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.</t>
          <t indent="0" pn="section-5.1.1-3">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 <xref target="sec-discoverability" format="default" sectionFormat="of" derivedContent="Section 5.1.2"/>)
          and while still maintaining precision (see <xref target="sec-precision" format="default" sectionFormat="of" derivedContent="Section 5.2"/>).</t>
        </section>
        <section anchor="sec-discoverability" numbered="true" toc="include" removeInRFC="false" pn="section-5.1.2">
          <name slugifiedName="name-discoverability">Discoverability</name>
          <t indent="0" pn="section-5.1.2-1">To be used in attack defence, IoCs must first be discovered
          through proactive hunting or reactive investigation. As noted in
          <xref target="sec-pop" format="default" sectionFormat="of" derivedContent="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.</t>
          <t indent="0" pn="section-5.1.2-2">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 <xref target="ADS" format="default" sectionFormat="of" derivedContent="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.</t>
          <t indent="0" pn="section-5.1.2-3">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 <xref target="OPENNIC" format="default" sectionFormat="of" derivedContent="OPENNIC"/>), by using
          encrypted DNS protocols such as DNS-over-HTTPS <xref target="OILRIG" format="default" sectionFormat="of" derivedContent="OILRIG"/>, or by performing transformation
          operations on resolved IP addresses to determine the real C2 server
          address encoded in the DNS response <xref target="LAZARUS" format="default" sectionFormat="of" derivedContent="LAZARUS"/>.</t>
        </section>
        <section anchor="sec-completeness" numbered="true" toc="include" removeInRFC="false" pn="section-5.1.3">
          <name slugifiedName="name-completeness">Completeness</name>
          <t indent="0" pn="section-5.1.3-1">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.</t>
        </section>
      </section>
      <section anchor="sec-precision" numbered="true" toc="include" removeInRFC="false" pn="section-5.2">
        <name slugifiedName="name-precision">Precision</name>
        <section numbered="true" toc="include" removeInRFC="false" pn="section-5.2.1">
          <name slugifiedName="name-specificity">Specificity</name>
          <t indent="0" pn="section-5.2.1-1">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.</t>
          <t indent="0" pn="section-5.2.1-2">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.</t>
        </section>
        <section numbered="true" toc="include" removeInRFC="false" pn="section-5.2.2">
          <name slugifiedName="name-dual-and-compromised-use">Dual and Compromised Use</name>
          <t indent="0" pn="section-5.2.2-1">As noted in <xref target="sec-assessment" format="default" sectionFormat="of" derivedContent="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.</t>
          <t indent="0" pn="section-5.2.2-2">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.</t>
          <t indent="0" pn="section-5.2.2-3">For reasons like these, context is very important when
          sharing and using IoCs.</t>
        </section>
        <section numbered="true" toc="include" removeInRFC="false" pn="section-5.2.3">
          <name slugifiedName="name-changing-use">Changing Use</name>
          <t indent="0" pn="section-5.2.3-1">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.</t>
        </section>
      </section>
      <section numbered="true" toc="include" removeInRFC="false" pn="section-5.3">
        <name slugifiedName="name-privacy">Privacy</name>
        <t indent="0" pn="section-5.3-1">As noted in <xref target="sec-assessment" format="default" sectionFormat="of" derivedContent="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.</t>
        <t indent="0" pn="section-5.3-2">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. <xref target="LITREVIEW" format="default" sectionFormat="of" derivedContent="LITREVIEW"/>
        highlights that many of these factors are associated with the human role in
        Cyber Threat Intelligence (CTI) sharing.</t>
      </section>
      <section numbered="true" toc="include" removeInRFC="false" pn="section-5.4">
        <name slugifiedName="name-automation">Automation</name>
        <t indent="0" pn="section-5.4-1">While IoCs can be effectively utilised by organisations of various
        sizes and resource constraints, as discussed in <xref target="sec-limited-resources" format="default" sectionFormat="of" derivedContent="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.</t>
        <t indent="0" pn="section-5.4-2">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.</t>
        <t indent="0" pn="section-5.4-3">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.</t>
      </section>
    </section>
    <section anchor="depth" numbered="true" toc="include" removeInRFC="false" pn="section-6">
      <name slugifiedName="name-comprehensive-coverage-and-">Comprehensive Coverage and Defence-in-Depth</name>
      <t indent="0" pn="section-6-1">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.</t>
      <t indent="0" pn="section-6-2">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.</t>
      <t indent="0" pn="section-6-3">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 <xref target="Owari" format="default" sectionFormat="of" derivedContent="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.</t>
      <t indent="0" pn="section-6-4">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 <xref target="KillChain" format="default" sectionFormat="of" derivedContent="KillChain"/>. In the
      worst cases, the attack specifically disables the endpoint solution, or
      the malware is brand new and so won't be recognised.</t>
      <t indent="0" pn="section-6-5">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.</t>
      <t indent="0" pn="section-6-6">One example of how network-level IoCs provide a layer of a
      defence-in-depth solution is Protective DNS (PDNS) <xref target="Annual2021" format="default" sectionFormat="of" derivedContent="Annual2021"/>, a free and voluntary
      DNS filtering service provided by the UK NCSC for UK public sector
      organisations <xref target="PDNS" format="default" sectionFormat="of" derivedContent="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
      <xref target="ACD2021" format="default" sectionFormat="of" derivedContent="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 <xref target="DGAs" format="default" sectionFormat="of" derivedContent="DGAs"/> are a type of TTP).</t>
      <t indent="0" pn="section-6-7">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.</t>
      <t indent="0" pn="section-6-8">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.</t>
      <t indent="0" pn="section-6-9">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.</t>
      <t indent="0" pn="section-6-10">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.</t>
    </section>
    <section anchor="IANA" numbered="true" toc="include" removeInRFC="false" pn="section-7">
      <name slugifiedName="name-iana-considerations">IANA Considerations</name>
      <t indent="0" pn="section-7-1">This document has no IANA actions.</t>
    </section>
    <section anchor="Security" numbered="true" toc="include" removeInRFC="false" pn="section-8">
      <name slugifiedName="name-security-considerations">Security Considerations</name>
      <t indent="0" pn="section-8-1">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.</t>
    </section>
    <section numbered="true" toc="include" removeInRFC="false" pn="section-9">
      <name slugifiedName="name-conclusions">Conclusions</name>
      <t indent="0" pn="section-9-1">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.</t>
      <t indent="0" pn="section-9-2">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.</t>
    </section>
  </middle>
  <back>
    <displayreference target="I-D.dulaunoy-misp-core-format" to="MISPCORE"/>
    <references pn="section-10">
      <name slugifiedName="name-informative-references">Informative References</name>
      <reference anchor="ACD2021" target="https://www.ncsc.gov.uk/files/ACD-The-Fifth-Year-full-report.pdf" quoteTitle="true" derivedAnchor="ACD2021">
        <front>
          <title>Active Cyber Defence - The Fifth Year</title>
          <author>
            <organization showOnFrontPage="true">UK NCSC</organization>
          </author>
          <date month="May" year="2022"/>
        </front>
      </reference>
      <reference anchor="ADS" target="https://docs.microsoft.com/en-us/windows/win32/fileio/file-streams" quoteTitle="true" derivedAnchor="ADS">
        <front>
          <title>File Streams (Local File Systems)</title>
          <author>
            <organization showOnFrontPage="true">Microsoft</organization>
          </author>
          <date month="January" year="2021"/>
        </front>
      </reference>
      <reference anchor="ALIENVAULT" target="https://otx.alienvault.com/" quoteTitle="true" derivedAnchor="ALIENVAULT">
        <front>
          <title>AlienVault: The World's First Truly Open Threat Intelligence Community</title>
          <author>
            <organization showOnFrontPage="true">AlienVault</organization>
          </author>
        </front>
      </reference>
      <reference anchor="Annual2021" target="https://www.ncsc.gov.uk/files/NCSC%20Annual%20Review%202021.pdf" quoteTitle="true" derivedAnchor="Annual2021">
        <front>
          <title>NCSC Annual Review 2021: Making the UK the safest place to live and work online</title>
          <author>
            <organization showOnFrontPage="true">UK NCSC</organization>
          </author>
          <date year="2021"/>
        </front>
      </reference>
      <reference anchor="CISA" target="https://www.cisa.gov/uscert/ncas/alerts/aa21-321a" quoteTitle="true" derivedAnchor="CISA">
        <front>
          <title>Iranian Government-Sponsored APT Cyber Actors Exploiting Microsoft Exchange and Fortinet Vulnerabilities in Furtherance of Malicious Activities</title>
          <author>
            <organization showOnFrontPage="true">CISA</organization>
          </author>
          <date month="November" year="2021"/>
        </front>
      </reference>
      <reference anchor="COBALT" target="https://www.cobaltstrike.com/" quoteTitle="true" derivedAnchor="COBALT">
        <front>
          <title>Cobalt Strike</title>
          <author>
            <organization showOnFrontPage="true"/>
          </author>
        </front>
      </reference>
      <reference anchor="DFRONT" target="https://resources.infosecinstitute.com/topic/domain-fronting/" quoteTitle="true" derivedAnchor="DFRONT">
        <front>
          <title>Domain Fronting</title>
          <author>
            <organization showOnFrontPage="true">Infosec</organization>
          </author>
          <date month="April" year="2017"/>
        </front>
      </reference>
      <reference anchor="DGAs" target="https://attack.mitre.org/techniques/T1483/" quoteTitle="true" derivedAnchor="DGAs">
        <front>
          <title>Dynamic Resolution: Domain Generation Algorithms</title>
          <author>
            <organization showOnFrontPage="true">MITRE</organization>
          </author>
          <date year="2020"/>
        </front>
      </reference>
      <reference anchor="FireEye" target="https://www.mandiant.com/resources/blog/apt33-insights-into-iranian-cyber-espionage" quoteTitle="true" derivedAnchor="FireEye">
        <front>
          <title>Insights into Iranian Cyber Espionage: APT33 Targets Aerospace and Energy Sectors and has Ties to Destructive Malware</title>
          <author fullname="Jacqueline O'Leary" initials="J." surname="O'Leary">
            <organization showOnFrontPage="true">FireEye</organization>
          </author>
          <author fullname="Josiah Kimble" initials="J." surname="Kimble">
            <organization showOnFrontPage="true">FireEye</organization>
          </author>
          <author fullname="Kelli Vanderlee" initials="K." surname="Vanderlee">
            <organization showOnFrontPage="true">FireEye</organization>
          </author>
          <author fullname="Nalani Fraser" initials="N." surname="Fraser">
            <organization showOnFrontPage="true">FireEye</organization>
          </author>
          <date month="September" year="2017"/>
        </front>
      </reference>
      <reference anchor="FireEye2" target="https://www.mandiant.com/resources/blog/overruled-containing-a-potentially-destructive-adversary" quoteTitle="true" derivedAnchor="FireEye2">
        <front>
          <title>OVERRULED: Containing a Potentially Destructive Adversary</title>
          <author fullname="Geoff Ackerman" initials="G." surname="Ackerman">
            <organization showOnFrontPage="true">FireEye</organization>
          </author>
          <author fullname="Rick Cole" initials="R." surname="Cole">
            <organization showOnFrontPage="true">FireEye</organization>
          </author>
          <author fullname="Andrew Thompson" initials="A." surname="Thompson">
            <organization showOnFrontPage="true">FireEye</organization>
          </author>
          <author fullname="Alex Orleans" initials="A." surname="Orleans">
            <organization showOnFrontPage="true">FireEye</organization>
          </author>
          <author fullname="Nick Carr" initials="N." surname="Carr">
            <organization showOnFrontPage="true">FireEye</organization>
          </author>
          <date month="December" year="2018"/>
        </front>
      </reference>
      <reference anchor="GoldenTicket" target="https://attack.mitre.org/techniques/T1558/001/" quoteTitle="true" derivedAnchor="GoldenTicket">
        <front>
          <title>Steal or Forge Kerberos Tickets: Golden Ticket</title>
          <author fullname="Itamar Mizrahi" initials="I." surname="Mizrahi">
            <organization showOnFrontPage="true">MITRE</organization>
          </author>
          <author fullname="Cymptom" surname="Cymptom">
            <organization showOnFrontPage="true">MITRE</organization>
          </author>
          <date year="2020"/>
        </front>
      </reference>
      <reference anchor="KillChain" target="https://www.lockheedmartin.com/en-us/capabilities/cyber/cyber-kill-chain.html" quoteTitle="true" derivedAnchor="KillChain">
        <front>
          <title>The Cyber Kill Chain</title>
          <author>
            <organization showOnFrontPage="true">Lockheed Martin</organization>
          </author>
        </front>
      </reference>
      <reference anchor="LAZARUS" target="https://media.kasperskycontenthub.com/wp-content/uploads/sites/43/2018/03/07180244/Lazarus_Under_The_Hood_PDF_final.pdf" quoteTitle="true" derivedAnchor="LAZARUS">
        <front>
          <title>Lazarus Under The Hood</title>
          <author>
            <organization showOnFrontPage="true">Kaspersky Lab</organization>
          </author>
        </front>
      </reference>
      <reference anchor="LITREVIEW" target="https://www.open-access.bcu.ac.uk/7852/1/Cyber%20Threat%20Intelligence%20Sharing%20Survey%20and%20Research%20Directions.pdf" quoteTitle="true" derivedAnchor="LITREVIEW">
        <front>
          <title>Cyber Threat Intelligence Sharing: Survey and Research Directions</title>
          <author fullname="Thomas Wagner" initials="T." surname="Wagner">
            <organization showOnFrontPage="true">Birmingham City University</organization>
          </author>
          <author fullname="Khaled Mahbub" initials="K." surname="Mahbub">
            <organization showOnFrontPage="true"/>
          </author>
          <author fullname="Esther Palomar" initials="E." surname="Palomar">
            <organization showOnFrontPage="true"/>
          </author>
          <author fullname="Ali Abdallah" initials="A." surname="Abdallah">
            <organization showOnFrontPage="true"/>
          </author>
          <date month="January" year="2019"/>
        </front>
      </reference>
      <reference anchor="Mimikatz" target="https://www.sans.org/white-papers/36780/" quoteTitle="true" derivedAnchor="Mimikatz">
        <front>
          <title>Mimikatz Overview, Defenses and Detection</title>
          <author fullname="Jim Mulder" initials="J." surname="Mulder">
            <organization showOnFrontPage="true">SANS</organization>
          </author>
          <date month="February" year="2016"/>
        </front>
      </reference>
      <reference anchor="MISP" target="https://www.misp-project.org/" quoteTitle="true" derivedAnchor="MISP">
        <front>
          <title>MISP</title>
          <author>
            <organization showOnFrontPage="true"/>
          </author>
        </front>
      </reference>
      <reference anchor="I-D.dulaunoy-misp-core-format" target="https://datatracker.ietf.org/doc/html/draft-dulaunoy-misp-core-format-16" quoteTitle="true" derivedAnchor="MISPCORE">
        <front>
          <title>MISP core format</title>
          <author initials="A." surname="Dulaunoy" fullname="Alexandre Dulaunoy">
            <organization showOnFrontPage="true">Computer Incident Response Center Luxembourg</organization>
          </author>
          <author initials="A." surname="Iklody" fullname="Andras Iklody">
            <organization showOnFrontPage="true">Computer Incident Response Center Luxembourg</organization>
          </author>
          <date month="February" day="26" year="2023"/>
          <abstract>
            <t indent="0">   This document describes the MISP core format used to exchange
   indicators and threat information between MISP (Open Source Threat
   Intelligence Sharing Platform formerly known as Malware Information
   Sharing Platform) instances.  The JSON format includes the overall
   structure along with the semantic associated for each respective key.
   The format is described to support other implementations which reuse
   the format and ensuring an interoperability with existing MISP
   [MISP-P] software and other Threat Intelligence Platforms.

            </t>
          </abstract>
        </front>
        <seriesInfo name="Internet-Draft" value="draft-dulaunoy-misp-core-format-16"/>
        <refcontent>Work in Progress</refcontent>
      </reference>
      <reference anchor="NCCGroup" target="https://research.nccgroup.com/2021/01/12/abusing-cloud-services-to-fly-under-the-radar/" quoteTitle="true" derivedAnchor="NCCGroup">
        <front>
          <title>Abusing cloud services to fly under the radar</title>
          <author fullname="Wouter Jansen" initials="W." surname="Jansen">
            <organization showOnFrontPage="true">NCC Group</organization>
          </author>
          <date month="January" year="2021"/>
        </front>
      </reference>
      <reference anchor="NIST" target="https://csrc.nist.gov/glossary/term/security_control" quoteTitle="true" derivedAnchor="NIST">
        <front>
          <title>Glossary - security control</title>
          <author>
            <organization showOnFrontPage="true">NIST</organization>
          </author>
        </front>
      </reference>
      <reference anchor="OILRIG" target="https://www.zdnet.com/article/iranian-hacker-group-becomes-first-known-apt-to-weaponize-dns-over-https-doh/" quoteTitle="true" derivedAnchor="OILRIG">
        <front>
          <title>Iranian hacker group becomes first known APT to weaponize DNS-over-HTTPS (DoH)</title>
          <author fullname="Catalin Cimpanu" initials="C." surname="Cimpanu">
            <organization showOnFrontPage="true">ZDNet</organization>
          </author>
          <date month="August" year="2020"/>
        </front>
      </reference>
      <reference anchor="OPENIOC" target="https://www.fireeye.com/blog/threat-research/2013/10/openioc-basics.html" quoteTitle="true" derivedAnchor="OPENIOC">
        <front>
          <title>OpenIOC: Back to the Basics</title>
          <author fullname="Will Gibb" initials="W." surname="Gibb">
            <organization showOnFrontPage="true">FireEye</organization>
          </author>
          <author fullname="Devon Kerr" initials="D." surname="Kerr">
            <organization showOnFrontPage="true"/>
          </author>
          <date month="October" year="2013"/>
        </front>
      </reference>
      <reference anchor="OPENNIC" target="https://www.opennic.org/" quoteTitle="true" derivedAnchor="OPENNIC">
        <front>
          <title>OpenNIC</title>
          <author>
            <organization showOnFrontPage="true"/>
          </author>
        </front>
      </reference>
      <reference anchor="Owari" target="https://webarchive.nationalarchives.gov.uk/ukgwa/20220301141030/https://www.ncsc.gov.uk/report/weekly-threat-report-8th-june-2018" quoteTitle="true" derivedAnchor="Owari">
        <front>
          <title>Owari botnet own-goal takeover</title>
          <author>
            <organization showOnFrontPage="true">UK NCSC</organization>
          </author>
          <date year="2018"/>
        </front>
      </reference>
      <reference anchor="PDNS" target="https://www.ncsc.gov.uk/information/pdns" quoteTitle="true" derivedAnchor="PDNS">
        <front>
          <title>Protective Domain Name Service (PDNS)</title>
          <author>
            <organization showOnFrontPage="true">UK NCSC</organization>
          </author>
          <date month="August" year="2017"/>
        </front>
      </reference>
      <reference anchor="PoP" target="https://detect-respond.blogspot.com/2013/03/the-pyramid-of-pain.html" quoteTitle="true" derivedAnchor="PoP">
        <front>
          <title>The Pyramid of Pain</title>
          <author fullname="David Bianco" initials="D." surname="Bianco">
            <organization showOnFrontPage="true">Enterprise Detection &amp; Response</organization>
          </author>
          <date month="March" year="2013"/>
        </front>
      </reference>
      <reference anchor="RFC7970" target="https://www.rfc-editor.org/info/rfc7970" quoteTitle="true" derivedAnchor="RFC7970">
        <front>
          <title>The Incident Object Description Exchange Format Version 2</title>
          <author fullname="R. Danyliw" initials="R." surname="Danyliw"/>
          <date month="November" year="2016"/>
          <abstract>
            <t indent="0">The Incident Object Description Exchange Format (IODEF) defines a data representation for security incident reports and indicators commonly exchanged by operational security teams for mitigation and watch and warning. This document describes an updated information model for the IODEF and provides an associated data model specified with the XML schema. This new information and data model obsoletes RFCs 5070 and 6685.</t>
          </abstract>
        </front>
        <seriesInfo name="RFC" value="7970"/>
        <seriesInfo name="DOI" value="10.17487/RFC7970"/>
      </reference>
      <reference anchor="RULER" target="https://attack.mitre.org/software/S0358/" quoteTitle="true" derivedAnchor="RULER">
        <front>
          <title>Ruler</title>
          <author>
            <organization showOnFrontPage="true">MITRE</organization>
          </author>
        </front>
      </reference>
      <reference anchor="STIX" target="https://oasis-open.github.io/cti-documentation/stix/intro" quoteTitle="true" derivedAnchor="STIX">
        <front>
          <title>Introduction to STIX</title>
          <author>
            <organization showOnFrontPage="true">OASIS Cyber Threat Intelligence (CTI)</organization>
          </author>
        </front>
      </reference>
      <reference anchor="Symantec" target="https://www.symantec.com/blogs/threat-intelligence/elfin-apt33-espionage" quoteTitle="true" derivedAnchor="Symantec">
        <front>
          <title>Elfin: Relentless Espionage Group Targets Multiple Organizations in Saudi Arabia and U.S.</title>
          <author>
            <organization showOnFrontPage="true">Symantec</organization>
          </author>
          <date month="March" year="2019"/>
        </front>
      </reference>
      <reference anchor="TAXII" target="https://oasis-open.github.io/cti-documentation/taxii/intro.html" quoteTitle="true" derivedAnchor="TAXII">
        <front>
          <title>Introduction to TAXII</title>
          <author>
            <organization showOnFrontPage="true">OASIS Cyber Threat Intelligence (CTI)</organization>
          </author>
        </front>
      </reference>
      <reference anchor="Timestomp" target="https://attack.mitre.org/techniques/T1099/" quoteTitle="true" derivedAnchor="Timestomp">
        <front>
          <title>Indicator Removal: Timestomp</title>
          <author>
            <organization showOnFrontPage="true">MITRE</organization>
          </author>
          <date month="January" year="2020"/>
        </front>
      </reference>
      <reference anchor="TLP" target="https://www.first.org/tlp/" quoteTitle="true" derivedAnchor="TLP">
        <front>
          <title>Traffic Light Protocol (TLP)</title>
          <author>
            <organization showOnFrontPage="true">FIRST</organization>
          </author>
        </front>
      </reference>
    </references>
    <section anchor="Acknowledgements" numbered="false" toc="include" removeInRFC="false" pn="section-appendix.a">
      <name slugifiedName="name-acknowledgements">Acknowledgements</name>
      <t indent="0" pn="section-appendix.a-1">Thanks to all those who have been involved with improving cyber
      defence in the IETF and IRTF communities.</t>
    </section>
    <section anchor="authors-addresses" numbered="false" removeInRFC="false" toc="include" pn="section-appendix.b">
      <name slugifiedName="name-authors-addresses">Authors' Addresses</name>
      <author fullname="Kirsty Paine" initials="K." surname="Paine">
        <organization showOnFrontPage="true">Splunk Inc.</organization>
        <address>
          <email>kirsty.ietf@gmail.com</email>
        </address>
      </author>
      <author fullname="Ollie Whitehouse" initials="O." surname="Whitehouse">
        <organization showOnFrontPage="true">Binary Firefly</organization>
        <address>
          <email>ollie@binaryfirefly.com</email>
        </address>
      </author>
      <author fullname="James Sellwood" initials="J." surname="Sellwood">
        <address>
          <email>james.sellwood.ietf@gmail.com</email>
        </address>
      </author>
      <author fullname="Andrew Shaw" initials="A." surname="Shaw">
        <organization showOnFrontPage="true">UK National Cyber Security Centre</organization>
        <address>
          <email>andrew.s2@ncsc.gov.uk</email>
        </address>
      </author>
    </section>
  </back>
</rfc>
