[要約] RFC 9424は、サイバー防衛者がネットワークやエンドポイントでの悪意ある活動を特定し、追跡し、ブロックするためにIndicators of Compromise（IoCs）に頻繁に依存していることを要約しています。この文書は、IoCの基本、機会、運用上の制約、および使用に関する推奨事項を検討し、IoCの検出可能性の重要性を強調し、ネットワークセキュリティにおける運用上の課題へのアプローチの基盤を提供しています。
Internet Engineering Task Force (IETF) K. Paine
Request for Comments: 9424 Splunk Inc.
Category: Informational O. Whitehouse
ISSN: 2070-1721 Binary Firefly
J. Sellwood
A. Shaw
UK National Cyber Security Centre
August 2023
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.
サイバーディフェンダーは、ネットワークまたはエンドポイントで悪意のあるアクティビティを識別、追跡、およびブロックするために、妥協の指標（IOC）に依存することがよくあります。このドキュメントでは、IOCの使用に関する基本、機会、運用上の制限、および推奨事項をレビューします。IOCSの最初の発見と検出における使用の両方のために、IOCがインターネットプロトコル、ツール、およびテクノロジーの実装で検出可能であることを強調し、ネットワークセキュリティにおける運用上の課題へのアプローチの基盤を提供します。
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントは、インターネット標準の追跡仕様ではありません。情報目的で公開されています。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are candidates for any level of Internet Standard; see Section 2 of RFC 7841.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。IESGによって承認されたすべてのドキュメントが、インターネット標準のあらゆるレベルの候補者であるわけではありません。RFC 7841のセクション2を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9424.
このドキュメントの現在のステータス、任意のERRATA、およびそれに関するフィードバックを提供する方法に関する情報は、https：//www.rfc-editor.org/info/rfc9424で取得できます。
Copyright (c) 2023 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2023 IETF Trustおよび文書著者として特定された人。無断転載を禁じます。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（https://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、改訂されたBSDライセンスで説明されている保証なしで提供されるように、改訂されたBSDライセンステキストを含める必要があります。
1. Introduction
2. Terminology
3. IoC Fundamentals
3.1. IoC Types and the Pyramid of Pain
3.2. IoC Lifecycle
3.2.1. Discovery
3.2.2. Assessment
3.2.3. Sharing
3.2.4. Deployment
3.2.5. Detection
3.2.6. Reaction
3.2.7. End of Life
4. Using IoCs Effectively
4.1. Opportunities
4.1.1. IoCs underpin and enable multiple layers of the modern
defence-in-depth strategy.
4.1.2. IoCs can be used even with limited resources.
4.1.3. IoCs have a multiplier effect on attack defence efforts
within an organisation.
4.1.4. IoCs are easily shared between organisations.
4.1.5. IoCs can provide significant time savings.
4.1.6. IoCs allow for discovery of historic attacks.
4.1.7. IoCs can be attributed to specific threats.
4.2. Case Studies
4.2.1. Cobalt Strike
4.2.1.1. Overall TTP
4.2.1.2. IoCs
4.2.2. APT33
4.2.2.1. Overall TTP
4.2.2.2. IoCs
5. Operational Limitations
5.1. Time and Effort
5.1.1. Fragility
5.1.2. Discoverability
5.1.3. Completeness
5.2. Precision
5.2.1. Specificity
5.2.2. Dual and Compromised Use
5.2.3. Changing Use
5.3. Privacy
5.4. Automation
6. Comprehensive Coverage and Defence-in-Depth
7. IANA Considerations
8. Security Considerations
9. Conclusions
10. Informative References
Acknowledgements
Authors' Addresses
This document describes the various types of IoCs and how they are used effectively in attack defence (often called "cyber defence"). It introduces concepts such as the Pyramid of Pain [PoP] and the IoC lifecycle to highlight how IoCs may be used to provide a broad range of defences. This document provides suggestions for implementers of controls based on IoCs as well as potential operational limitations. Two case studies that demonstrate the usefulness of IoCs for detecting and defending against real-world attacks are included. One case study involves an intrusion set (a set of malicious activity and behaviours attributed to one threat actor) known as "APT33", and the other involves an attack tool called "Cobalt Strike". This document is not a comprehensive report of APT33 or Cobalt Strike and is intended to be read alongside publicly published reports (referred to as "open-source material" among cyber intelligence practitioners) on these threats (for example, [Symantec] and [NCCGroup], respectively).
このドキュメントでは、さまざまなタイプのIOCと、攻撃防御（「サイバー防衛」と呼ばれることが多い）で効果的に使用される方法について説明します。痛みのピラミッド[POP]やIOCライフサイクルなどの概念を導入して、IOCを使用して広範な防御を提供する方法を強調しています。このドキュメントは、IOCと潜在的な運用制限に基づいたコントロールの実装者に提案を提供します。実際の攻撃を検出および防御するためのIOCの有用性を示す2つのケーススタディが含まれています。1つのケーススタディには、「APT33」として知られる侵入セット（1つの脅威アクターに起因する悪意のあるアクティビティと行動のセット）が含まれ、もう1つは「コバルトストライク」と呼ばれる攻撃ツールを伴います。このドキュメントは、APT33またはコバルトストライキの包括的なレポートではなく、これらの脅威（たとえば[Symantec]および[NCCGroup）に関する公開されたレポート（サイバーインテリジェンス実践者の間で「オープンソース資料」と呼ばれる）と一緒に読むことを目的としています。]、 それぞれ）。
Attack defence:
攻撃防御：
The activity of providing cyber security to an environment through the prevention of, detection of, and response to attempted and successful cyber intrusions. A successful defence can be achieved through blocking, monitoring, and responding to adversarial activity at the network, endpoint, or application levels.
予防、検出、および成功したサイバー侵入の検出、および応答を通じて、サイバーセキュリティを環境に提供する活動。ネットワーク、エンドポイント、またはアプリケーションレベルでの敵対的な活動にブロック、監視、および対応することにより、防御を成功させることができます。
Command and control (C2) server:
コマンドとコントロール（C2）サーバー：
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".
侵害されたマシンからの通信、コマンドの送信、および受信に使用される攻撃者制御サーバー。C2サーバーと侵害されたホスト間の通信は、「コマンドおよび制御トラフィック」と呼ばれます。
Domain Generation Algorithm (DGA):
ドメイン生成アルゴリズム（DGA）：
The algorithm used in malware strains to periodically generate domain names (via algorithm). Malware may use DGAs to compute a destination for C2 traffic rather than relying on a pre-assigned list of static IP addresses or domains that can be blocked more easily when extracted from, or otherwise linked to, the malware.
マルウェア株で使用されるアルゴリズムは、（アルゴリズムを介して）定期的にドメイン名を生成します。マルウェアは、DGAを使用して、静的IPアドレスまたはドメインの事前に割り当てられたリストに依存するのではなく、C2トラフィックの宛先を計算することができます。
Kill chain:
チェーンを殺す：
A model for conceptually breaking down a cyber intrusion into stages of the attack from reconnaissance through to actioning the attacker's objectives. This model allows defenders to think about, discuss, plan for, and implement controls to defend against discrete phases of an attacker's activity [KillChain].
偵察から攻撃者の目的への行動への攻撃の段階へのサイバー侵入を概念的に分解するためのモデル。このモデルにより、防御者は、攻撃者の活動の個別のフェーズを防御するために、コントロールについて考え、議論し、計画し、実装することができます[Killchain]。
Tactics, Techniques, and Procedures (TTPs):
戦術、テクニック、手順（TTPS）：
The way an adversary undertakes activities in the kill chain -- the choices made, methods followed, tools and infrastructure used, protocols employed, and commands executed. If they are distinct enough, aspects of an attacker's TTPs can form specific IoCs as if they were a fingerprint.
敵がキルチェーンでの活動を引き受ける方法 - 行われた選択、方法、使用されたツールとインフラストラクチャ、プロトコルの採用、および実行されたコマンド。それらが十分に明確である場合、攻撃者のTTPの側面は、まるでそれらが指紋であるかのように特定のIOCを形成できます。
Control (as defined by US NIST):
コントロール（US NISTで定義されています）：
A safeguard or countermeasure prescribed for an information system or an organisation designed to protect the confidentiality, integrity, and availability of its information and to meet a set of defined security requirements [NIST].
情報システムまたはその情報の機密性、整合性、および可用性を保護し、定義されたセキュリティ要件のセットを満たすために設計された組織に規定されている保護または対策。
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:
IOCは、攻撃者またはその戦術、テクニック、手順、関連するツールおよびインフラストラクチャなどの活動に関連する観察可能なアーティファクトです。これらの指標は、ネットワークまたはエンドポイント（ホスト）レベルで観察でき、自信の程度がさまざまで、ネットワークディフェンダーが悪意のあるトラフィックまたはコードの実行を積極的にブロックしたり、サイバー侵入が発生したか、既知の侵入セットにアソシエイトのアクティビティが発生したことを決定することができます。それにより、調査のための追加の手段を潜在的に特定する可能性があります。IOCは、制御点が監視中のトラフィックで検索されているインジケーターのリストに追加することにより、ファイアウォールやその他のセキュリティ制御ポイントに展開されます。悪意のあるアクティビティに関連する場合、以下はプロトコル関連のIOCの例です。
* IPv4 and IPv6 addresses in network traffic
* ネットワークトラフィックのIPv4およびIPv6アドレス
* Fully Qualified Domain Names (FQDNs) in network traffic, DNS resolver caches, or logs
* ネットワークトラフィック、DNSリゾルバーキャッシュ、またはログの完全資格のドメイン名（FQDNS）
* TLS Server Name Indication values in network traffic
* ネットワークトラフィックのTLSサーバー名表示値
* Code-signing certificates in binaries
* バイナリのコード署名証明書
* TLS certificate information (such as SHA256 hashes) in network traffic
* ネットワークトラフィック内のTLS証明書情報（SHA256ハッシュなど）
* Cryptographic hashes (e.g., MD5, SHA1, or SHA256) of malicious binaries or scripts when calculated from network traffic or file system artefacts
* ネットワークトラフィックまたはファイルシステムアーティファクトから計算された場合の悪意のあるバイナリまたはスクリプトの暗号化（MD5、SHA1、またはSHA256）
* Attack tools (such as Mimikatz [Mimikatz]) and their code structure and execution characteristics
* 攻撃ツール（Mimikatz [Mimikatz]など）とそのコード構造と実行特性
* Attack techniques, such as Kerberos Golden Tickets [GoldenTicket], that can be observed in network traffic or system artefacts
* ネットワークトラフィックやシステムアーティファクトで観察できるKerberos Goldenチケット[Goldenticket]などの攻撃技術
The common types of IoC form a Pyramid of Pain [PoP] that informs prevention, detection, and mitigation strategies. The position of each IoC type in the pyramid represents how much "pain" a typical adversary experiences as part of changing the activity that produces that artefact. The greater pain an adversary experiences (towards the top), the less likely they are to change those aspects of their activity and the longer the IoC is likely to reflect the attacker's intrusion set (i.e., the less fragile those IoCs will be from a defender's perspective). The layers of the PoP commonly range from hashes up to TTPs, with the pain ranging from simply recompiling code to creating a whole new attack strategy. Other types of IoC do exist and could be included in an extended version of the PoP should that assist the defender in understanding and discussing intrusion sets most relevant to them.
IOCの一般的なタイプは、予防、検出、および緩和戦略を通知する痛みのピラミッド[POP]を形成します。ピラミッドの各IOCタイプの位置は、そのアーティファクトを生成する活動を変えることの一部として、典型的な敵の経験がどれほどの「痛み」を表しています。痛みが大きいほど、敵の経験（上部に向かって）、彼らの活動の側面を変える可能性が低くなり、IOCが攻撃者の侵入セットを反映する可能性が低くなります（つまり、これらのIOCがディフェンダーのものから壊れやすいほど視点）。POPの層は、一般的にハッシュからTTPSまでの範囲であり、痛みは単純に再コンパイルコードからまったく新しい攻撃戦略の作成に至るまでの範囲です。他のタイプのIOCは存在し、POPの拡張バージョンに含まれる可能性があります。これは、ディフェンダーが侵入セットを理解し、議論するのを支援する必要があります。
/\
/ \ MORE PAIN
/ \ LESS FRAGILE
/ \ LESS PRECISE
/ TTPs \
/ \ / \
============== |
/ \ |
/ Tools \ |
/ \ |
====================== |
/ \ |
/ Network/Host Artefacts \ |
/ \ |
============================== |
/ \ |
/ Domain Names \ |
/ \ |
====================================== |
/ \ |
/ IP Addresses \ |
/ \ \ /
==============================================
/ \ LESS PAIN
/ Hash Values \ MORE FRAGILE
/ \ MORE PRECISE
======================================================
Figure 1
On the lowest (and least painful) level are hashes of malicious files. These are easy for a defender to gather and can be deployed to firewalls or endpoint protection to block malicious downloads or prevent code execution. While IoCs aren't the only way for defenders to do this kind of blocking, they are a quick, convenient, and nonintrusive method. Hashes are precise detections for individual files based on their binary content. To subvert this defence, however, an adversary need only recompile code, or otherwise modify the file content with some trivial changes, to modify the hash value.
最も低い（そして最も痛みが少ない）レベルは、悪意のあるファイルのハッシュです。これらは、ディフェンダーが収集するのが簡単で、ファイアウォールまたはエンドポイント保護に展開して、悪意のあるダウンロードをブロックしたり、コードの実行を防ぎます。IOCは、ディフェンダーがこの種のブロッキングを行う唯一の方法ではありませんが、迅速で便利で侵入しない方法です。ハッシュは、バイナリコンテンツに基づいた個々のファイルの正確な検出です。ただし、この防御を破壊するには、敵のコードを再コンパイルするだけで、他の方法では、ハッシュ値を変更するために、いくつかの些細な変更でファイルコンテンツを変更する必要があります。
The next two levels are IP addresses and domain names. Interactions with these may be blocked, with varying false positive rates (misidentifying non-malicious traffic as malicious; see Section 5), and often cause more pain to an adversary to subvert than file hashes. The adversary may have to change IP ranges, find a new provider, and change their code (e.g., if the IP address is hard-coded rather than resolved). A similar situation applies to domain names, but in some cases, threat actors have specifically registered these to masquerade as a particular organisation or to otherwise falsely imply or claim an association that will be convincing or misleading to those they are attacking. While the process and cost of registering new domain names are now unlikely to be prohibitive or distracting to many attackers, there is slightly greater pain in selecting unregistered, but appropriate, domain names for such purposes.
次の2つのレベルは、IPアドレスとドメイン名です。これらとの相互作用は、さまざまな偽陽性率（悪意のあるトラフィックを悪意があると誤認する;セクション5を参照）でブロックされる可能性があり、多くの場合、ファイルハッシュよりも敵により多くの痛みを引き起こします。敵は、IP範囲を変更し、新しいプロバイダーを見つけ、コードを変更する必要がある場合があります（たとえば、IPアドレスが解決されるのではなくハードコーディングされている場合）。同様の状況がドメイン名にも当てはまりますが、場合によっては、脅威アクターが特定の組織に装ったり、攻撃している人を説得または誤解を招く協会を誤って暗示または主張するために、これらを具体的に登録しています。新しいドメイン名を登録するプロセスとコストは、多くの攻撃者に禁止されたり気を散らしたりする可能性は低いですが、そのような目的のために、未登録の、しかし適切なドメイン名を選択することには少し大きな痛みがあります。
Network and endpoint artefacts, such as a malware's beaconing pattern on the network or the modified timestamps of files touched on an endpoint, are harder still to change as they relate specifically to the attack taking place and, in some cases, may not be under the direct control of the attacker. However, more sophisticated attackers use TTPs or tooling that provides flexibility at this level (such as Cobalt Strike's malleable command and control [COBALT]) or a means by which some artefacts can be masked (see [Timestomp]).
ネットワーク上のマルウェアのビーコンパターンやエンドポイントで触れたファイルの変更されたタイムスタンプなどのネットワークおよびエンドポイントのアーティファクトは、発生する攻撃に特に関連するため、まだ変化するのが難しく、場合によっては、攻撃者の直接制御。ただし、より洗練された攻撃者は、このレベルで柔軟性を提供するTTPまたはツールを使用します（コバルトストライクの順応性コマンドとコントロール[コバルト]など）またはいくつかのアーティファクトをマスクできる手段（[Timestomp]を参照）。
Tools and TTPs form the top two levels of the pyramid; these levels describe a threat actor's methodology -- the way they perform the attack. The tools level refers specifically to the software (and less frequently, hardware) used to conduct the attack, whereas the TTPs level picks up on all the other aspects of the attack strategy. IoCs at these levels are more complicated and complex -- for example, they can include the details of how an attacker deploys malicious code to perform reconnaissance of a victim's network, pivots laterally to a valuable endpoint, and then downloads a ransomware payload. TTPs and tools take intensive effort to diagnose on the part of the defender, but they are fundamental to the attacker and campaign and hence incredibly painful for the adversary to change.
ツールとTTPは、ピラミッドの上位2レベルを形成します。これらのレベルは、脅威アクターの方法論、つまり攻撃の実行方法を説明しています。ツールレベルは、攻撃の実施に使用されるソフトウェア（およびそれほど頻繁ではないハードウェア）を特に指しますが、TTPSレベルは攻撃戦略の他のすべての側面を取り上げます。これらのレベルでのIOCはより複雑で複雑です。たとえば、攻撃者が悪意のあるコードを展開して被害者のネットワークの偵察を実行し、側面に向かって側面にピボットし、ランサムウェアペイロードをダウンロードする方法の詳細を含めることができます。TTPSとツールは、ディフェンダーの側で診断するために集中的な努力を払っていますが、それらは攻撃者とキャンペーンの基本であり、したがって敵が変化するために非常に苦痛です。
The variation in discoverability of IoCs is indicated by the numbers of IoCs in AlienVault, an open threat intelligence community [ALIENVAULT]. As of January 2023, AlienVault contained:
IOCの発見可能性の変動は、オープンな脅威インテリジェンスコミュニティ[AlienVault]であるAlienVaultのIOCの数によって示されます。2023年1月の時点で、ElienVaultには以下が含まれていました。
* Groups (i.e., combinations of TTPs): 631
* グループ（つまり、TTPの組み合わせ）：631
* Malware families (i.e., tools): ~27,000
* マルウェアファミリ（つまり、ツール）：〜27,000
* URL: 2,854,918
* URL：2,854,918
* Domain names: 64,769,363
* ドメイン名：64,769,363
* IPv4 addresses: 5,427,762
* IPv4アドレス：5,427,762
* IPv6 addresses: 12,009
* IPv6アドレス：12,009
* SHA256 hash values: 5,452,442
* SHA256ハッシュ値：5,452,442
The number of domain names appears out of sync with the other counts, which reduce on the way up the PoP. This discrepancy warrants further research; however, contributing factors may be the use of DGAs and the fact that threat actors use domain names to masquerade as legitimate organisations and so have added incentive for creating new domain names as they are identified and confiscated.
ドメイン名の数は、他のカウントと同期していないように見えます。これにより、ポップの途中で減少します。この矛盾はさらなる研究を保証します。ただし、貢献要因は、DGAの使用と、脅威アクターがドメイン名を使用して合法的な組織を装ったため、特定され没収された新しいドメイン名を作成するためのインセンティブを追加するという事実である可能性があります。
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.
防御者に役立つために、IOCは最初に発見、評価、共有、展開する必要があります。記録されたアクティビティがIOCに識別され、相関すると、この検出はディフェンダーによる反応を引き起こします。これには、調査が含まれ、より多くのIOCが発見、評価、共有、展開される可能性があります。このサイクルは、IOCが関連性がなくなると判断されるまで続き、その時点で制御スペースから削除されます。
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).
IOCは、最初は手動調査または自動分析を通じて発見されます。それらは、エンドポイントやネットワーク（ワイヤー上）を含むさまざまなソースで発見できます。ログ監視プロトコルパケットキャプチャ、コード実行、またはシステムアクティビティ（ハッシュ、IPアドレス、ドメイン名、ネットワークまたはエンドポイントアーティファクトの場合）から抽出するか、攻撃アクティビティまたはツールの分析を通じて決定する必要があります。場合によっては、発見は、残された痕跡から過去または現在の攻撃からのIOCが識別される反応的なプロセスである場合があります。ただし、過去のイベントの知識から外挿された潜在的な将来のIOCのプロアクティブな狩猟（ドメイン名登録パターンを監視することにより攻撃者のインフラストラクチャを識別するなど）から発見が生じる場合もあります。
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.
重要なのは、IOCを発見するには、インターネットプロトコル、ツール、または関連するテクノロジーからインジケータが抽出可能でなければなりません。攻撃に関連する特定の交換（または交換されたメッセージのシーケンス）を識別することは、インジケーターを抽出できない場合、または抽出されたら、その後のメッセージまたはアーティファクトのアーティファクトの後の交換、または別の、プロトコル。悪意のある攻撃トラフィックのソースまたは宛先を決定することができない場合、その後の攻撃トラフィックを特定してブロックすることもできません。
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.
ディフェンダーは、IOCの品質とディフェンダーのニーズと能力に応じて、異なるIOCを異なる方法で扱う場合があります。たとえば、ディフェンダーは、ソース、新鮮さ、信頼レベル、または関連する脅威に応じて、IOCに異なる信頼を配置する場合があります。これらの決定は、発見の時点で回収された関連するコンテキスト情報に依存するか、IOCが共有されたときに提供されます。
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).
コンテキストのないIOCは、ネットワーク防御にあまり役に立ちません。一方、コンテキストで配信されたIOC（たとえば、攻撃におけるその役割、使用中に最後に見られた時期、予想される寿命、またはその他の関連するIOC）を提供するIOCは、ネットワークディフェンダーがネットワークを保護するためにそれを使用する方法について情報に基づいた選択をします（たとえば、単にログ、積極的に監視したり、完全にブロックしたりします）。
Once discovered and assessed, IoCs are most helpful when deployed in such a way to have a broad impact on the detection or disruption of threats or shared at scale so many individuals and organisations can defend themselves. An IoC may be shared individually (with appropriate context) in an unstructured manner or may be packaged alongside many other IoCs in a standardised format, such as Structured Threat Information Expression [STIX], Malware Information Sharing Platform (MISP) core [MISPCORE], OpenIOC [OPENIOC], and Incident Object Description Exchange Format (IODEF) [RFC7970]. This enables distribution via a structured feed, such as one implementing Trusted Automated Exchange of Intelligence Information [TAXII], or through a Malware Information Sharing Platform [MISP].
発見および評価されると、IOCは、脅威の検出または中断に幅広い影響を与えるように展開するときに最も役立ちます。IOCは、構造化された脅威情報式[STIX]、マルウェア情報共有プラットフォーム（MISP）コア[MISPCORE]など、非構造化された方法で個別に（適切なコンテキストで）他の多くのIOCと一緒にパッケージ化される場合があります。openioc [openioc]、およびインシデントオブジェクト説明交換形式（IODEF）[RFC7970]。これにより、インテリジェンス情報の信頼できる自動交換[TAXII]を実装するなど、構造化されたフィードを介した配布が可能になり、マルウェア情報共有プラットフォーム[MISP]を介して配布が可能になります。
While some security companies and some membership-based groups (often dubbed "Information Sharing and Analysis Centres (ISACs)" or "Information Sharing and Analysis Organizations (ISAOs)") provide paid intelligence feeds containing IoCs, there are various free IoC sources available from individual security researchers up through small trust groups to national governmental cyber security organisations and international Computer Emergency Response Teams (CERTs). Whoever they are, sharers commonly indicate the extent to which receivers may further distribute IoCs using frameworks like the Traffic Light Protocol [TLP]. At its simplest, this indicates that the receiver may share with anyone (TLP:CLEAR), share within the defined sharing community (TLP:GREEN), share within their organisation and their clients (TLP:AMBER+STRICT), share just within their organisation (TLP:AMBER), or not share with anyone outside the original specific IoC exchange (TLP:RED).
一部のセキュリティ会社と一部のメンバーシップベースのグループ（多くの場合、「情報共有および分析センター（ISACS）」または「情報共有分析組織（ISAO）」と呼ばれる）がIOCを含む有料インテリジェンスフィードを提供していますが、から利用可能なさまざまな無料のIOCソースがあります個々のセキュリティ研究者は、小規模な信託グループを通じて、中央政府のサイバーセキュリティ組織および国際コンピューター緊急対応チーム（CERTS）に登場します。彼らが誰であれ、共有者は一般に、信号プロトコル[TLP]などのフレームワークを使用して、受信機がIOCをさらに配布できる範囲を示しています。これは、その最も簡単なことに、受信者が誰でも共有（TLP：CLEAR）、定義された共有コミュニティ（TLP：Green）内で共有し、組織とそのクライアント（TLP：Amber Strict）内で共有することができることを示しています。（TLP：Amber）、または元の特定のIOC Exchange以外の人と共有しないでください（TLP：RED）。
For IoCs to provide defence-in-depth (see Section 6) and so cope with different points of failure, correct deployment is important. Different IoCs will detect malicious activity at different layers of the network stack and at different stages of an attack, so deploying a range of IoCs enables layers of defence at each security control, reinforcing the benefits of using multiple security controls as part of a defence-in-depth solution. The network security controls and endpoint solutions where they are deployed need to have sufficient privilege, and sufficient visibility, to detect IoCs and to act on them. Wherever IoCs exist, they need to be made available to security controls and associated apparatus to ensure they can be deployed quickly and widely. While IoCs may be manually assessed after discovery or receipt, significant advantage may be gained by automatically ingesting, processing, assessing, and deploying IoCs from logs or intelligence feeds to the appropriate security controls. As not all IoCs are of the same quality, confidence in IoCs drawn from each threat intelligence feed should be considered when deciding whether to deploy IoCs automatically in this way.
IOCが詳細な防御を提供し（セクション6を参照）、さまざまな障害点に対処するためには、正しい展開が重要です。さまざまなIOCは、ネットワークスタックの異なる層と攻撃のさまざまな段階で悪意のあるアクティビティを検出するため、IOCの範囲を展開することにより、各セキュリティ制御で防御層を展開し、防御の一部として複数のセキュリティコントロールを使用する利点を強化できます。詳細なソリューション。展開されているネットワークセキュリティコントロールとエンドポイントソリューションは、IOCを検出し、それらに作用するために、十分な特権と十分な可視性を必要とする必要があります。IOCが存在する場所には、セキュリティ制御と関連する装置が迅速かつ広く展開できるようにするために、それらを利用できるようにする必要があります。IOCは発見または受領後に手動で評価される場合がありますが、ログまたはインテリジェンスフィードから適切なセキュリティ制御にIOCを自動的に摂取、処理、評価、展開することにより、大きな利点が得られる場合があります。すべてのIOCが同じ品質ではないため、各脅威インテリジェンスフィードから引き出されたIOCに対する信頼を考慮する必要があります。この方法でIOCを自動的に展開するかどうかを決定する必要があります。
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.
IOCは、最も広い影響を及ぼしてセキュリティ制御に展開されたときに悪意のあるアクティビティを緩和するのに特に効果的です。これは、各ユーザーがそれを行うことなく、セキュリティ製品またはファイアウォールの開発者がIOCの製品の配布と消費のサポートを直接追加することで達成できます。自動化された方法。これは、最も広い開口部（たとえば、エンタープライズ全体のDNSリゾルバー）がIOCフィードに基づいて自動的に作用できるようにすることにより、企業内で達成できます。
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.
展開されたIOCSを備えたセキュリティ制御は、関連する制御スペースを監視し、監視されたログまたはネットワークインターフェイスでのIOCの検出時に一般的または特定の反応をトリガーします。
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.
IOCの検出に対する反応は、展開されている制御の機能や構成、IOCの評価、および検出されたログソースの特性などの要因によって異なる場合があります。たとえば、既知のボットネットC2サーバーへの接続は問題を示している可能性がありますが、特にサーバーが他の正当な機能を実行している侵害されたホストである場合、それを保証しません。一般的な反応には、イベントロギング、アラートのトリガー、アクティビティのソースのブロックまたは終了が含まれます。
How long an IoC remains useful varies and is dependent on factors including initial confidence level, fragility, and precision of the IoC (discussed further in Section 5). In some cases, IoCs may be automatically "aged" based on their initial characteristics and so will reach end of life at a predetermined time. In other cases, IoCs may become invalidated due to a shift in the threat actor's TTPs (e.g., resulting from a new development or their discovery) or due to remediation action taken by a defender. End of life may also come about due to an activity unrelated to attack or defence, such as when a third-party service used by the attacker changes or goes offline. Whatever the cause, IoCs should be removed from detection at the end of their life to reduce the likelihood of false positives.
IOCがどの程度有用であるかはさまざまであり、IOCの初期信頼レベル、脆弱性、精度などの要因に依存します（セクション5でさらに説明します）。場合によっては、IOCは初期特性に基づいて自動的に「熟成」される可能性があるため、事前に決められた時期に終末期に達することがあります。それ以外の場合、IOCは、脅威アクターのTTPの変化（たとえば、新しい開発やその発見による結果）またはディフェンダーによる修復作用により、無効になる可能性があります。攻撃者が使用するサードパーティのサービスがオフラインになったときなど、攻撃や防御に関係のない活動のために、終末期は生まれるかもしれません。原因が何であれ、IOCは、誤検知の可能性を減らすために、人生の終わりに検出から削除する必要があります。
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.
IOCは、現代のディフェンスの詳細な戦略の一部として、サイバーディフェンダーにさまざまな機会を提供します。組織の規模に関係なく、IOCは、過去に攻撃された可能性のある最新の脅威または特定の侵入セットからの攻撃のクラスに対して、効果的でスケーラブルで効率的な防御メカニズムを提供できます。
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.
ファイアウォール、侵入検知システム（IDS）、および侵入予防システム（IPSS）はすべてIOCを使用して、ネットワーク全体の脅威を特定して軽減します。アンチウイルス（AV）およびエンドポイント検出および応答（EDR）製品は、カタログまたはライブラリを介してIOCを展開してサポートされているクライアントエンドポイントを展開します。セキュリティインシデントイベント管理（SIEM）プラットフォームは、IOCをさまざまなソース（ネットワーク、エンドポイント、アプリケーション）からの集約ログと比較します。もちろん、IOCはすべての攻撃防衛の課題に対処するわけではありませんが、組織の階層化された防御の重要な層を形成します。一部のタイプのIOCがこれらすべてのコントロールに存在する場合がありますが、他のタイプは、詳細なソリューションの特定のレイヤーにのみ展開される場合があります。さらに、特定のキルチェーンに関連するIOCは、特定のフェーズで実行されたアクティビティを反映する場合があるため、侵入セットの一部としてキルチェーンを完全にカバーするために、他のIOCまたはメカニズムと組み合わせる必要があります。
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.
例として、オープンソースマルウェアは、それぞれ独自のTTPとインフラストラクチャを使用して、多くの異なるアクターによって展開できます。ただし、アクターが同じ実行可能ファイルを使用している場合、実行可能ファイルのハッシュは同じままであり、このハッシュは、個々のアクター、インフラストラクチャ、または他のTTPに関係なく、実行をブロックするためにエンドポイント保護のIOCとして展開できます。たとえば、特定のケースでこの防御が失敗した場合、俳優がユニークなハッシュを生成する実行可能バイナリを再コンパイルする場合、他の防御は、既知の悪意のあるドメイン名の検索をブロックし、それによってマルウェアを防ぐことにより、攻撃を通じてさらに進行するのを防ぐことができますC2インフラストラクチャを呼びかけます。
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.
あるいは、別の悪意のある俳優は、さまざまなキャンペーンで展開されているツールとインフラストラクチャ（したがって、侵入セットに関連するインジケーター）を定期的に変更する場合がありますが、アクセスベクトルは一貫性があり、よく知られたままである可能性があります。この場合、このアクセスTTPは、意図したその後の活動の不確実性がある場合でも、認識され、積極的に防御することができます。たとえば、アクセスベクトルがソフトウェアの脆弱性を一貫して活用している場合、定期的および不動産全体のパッチングは攻撃の発生を防ぐことができます。ただし、これらの先制措置が失敗した場合、複数のキャンペーンで観察された他のIOCは、キルチェーンの後期段階で攻撃を防ぐことができる可能性があります。
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.
IOCは安価でスケーラブルで、展開が簡単で、特に重大な脅威にさらされている場合、より小さなエンティティにとって特に有益です。たとえば、サプライチェーンが侵害された場合、サプライチェーンとプライム請負業者の両方に不均衡な影響があるため、重要で高度に専門化されたコンポーネントを生成するサプライチェーン内の小規模な下請業者は魅力的なターゲットを表す可能性があります。この小規模メーカーは基本的なセキュリティのみ（内部または外部委託）しか持っていないと仮定するのが合理的かもしれません。大きな効果。このような小規模なエンティティは、IOCを展開して、リソースのある、成熟した防御チームにアクセスすることなく、リソース集約型の調査を実行するために必要な脅威インテリジェンス関係にアクセスすることなく、既知の脅威に対するベースライン保護を提供できます。IOCSをうまく展開するには、このような小さな企業の一部のある程度の専門知識が必要ですが、IOCの使用は、機械学習を使用しているものなど、さらなる手動分析を必要とするような、より主観的なコントロールに必要なものと同じ集中トレーニングを必要としません。特定されたイベントのうち、実際に悪意があるかどうかを確認します。このようにして、IOCの魅力の大部分は、リソース能力、成熟度、洗練のスペクトルにわたって組織にある程度の保護を提供できることです。
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.
個々のIOCは、組織またはエコシステム全体のディフェンダーを効果的にスケーリングする広範な保護を提供できます。単一の組織内では、1つのIOCをブロックするだけで数千人のユーザーを保護する可能性があり、そのブロッキングは（IOCタイプに応じて）実行される可能性があり、複数のセキュリティコントロールで、ネットワーク、エンドポイント、アプリケーション内のさまざまな種類のアクティビティを監視することができます。以前の例の主要な請負業者は、IOCを小さな下請業者に供給することができ、したがって、小規模なエンティティの防御能力をさらに高揚させ、同時に自分自身とその利益を保護します。
Multiple organisations may benefit from directly receiving shared IoCs (see Section 4.1.4), but they may also benefit from the IoCs' application in services they utilise. In the case of an ongoing email-phishing campaign, IoCs can be monitored, discovered, and deployed quickly and easily by individual organisations. However, if they are deployed quickly via a mechanism such as a protective DNS filtering service, they can be more effective still -- an email campaign may be mitigated before some organisations' recipients ever click the link or before some malicious payloads can call out for instructions. Through such approaches, other parties can be protected without direct sharing of IoCs with those organisations or additional effort.
複数の組織は、共有IOCを直接受け取ることから恩恵を受ける可能性があります（セクション4.1.4を参照）が、使用するサービスへのIOCのアプリケーションの恩恵を受けることもあります。進行中の電子メールフィッシングキャンペーンの場合、IOCは個々の組織が迅速かつ簡単に監視、発見、展開できます。ただし、保護DNSフィルタリングサービスなどのメカニズムを介して迅速に展開されている場合、それらはさらに効果的になる可能性があります - 一部の組織の受信者がリンクをクリックしたり、悪意のあるペイロードを呼び出す前に、電子メールキャンペーンを軽減することができます説明書。このようなアプローチを通じて、他の関係者は、IOCをそれらの組織と直接共有したり、追加の努力をすることなく保護できます。
IoCs can also be very easily shared between individuals and organisations. First, IoCs are easy to distribute as they can be represented concisely as text (possibly in hexadecimal) and so are frequently exchanged in small numbers in emails, blog posts, or technical reports. Second, standards, such as those mentioned in Section 3.2.3, exist to provide well-defined formats for sharing large collections or regular sets of IoCs along with all the associated context. While discovering one IoC can be intensive, once shared via well-established routes, that individual IoC may protect thousands of organisations and thus all of the users in those organisations. Quick and easy sharing of IoCs gives blanket coverage for organisations and allows widespread mitigation in a timely fashion -- they can be shared with systems administrators, from small to large organisations and from large teams to single individuals, allowing them all to implement defences on their networks.
IOCは、個人と組織間で非常に簡単に共有できます。第一に、IOCはテキストとして簡潔に表現できるため、簡単に配布できます（おそらく16進数）、電子メール、ブログ投稿、または技術レポートで少数で頻繁に交換されます。第二に、セクション3.2.3に記載されているような標準は、すべての関連するコンテキストとともに、大規模なコレクションまたは通常のIOCセットを共有するための明確な形式を提供するために存在します。1つのIOCを発見することは、確立されたルートを介して共有されると集中的になりますが、個々のIOCは何千もの組織、したがってそれらの組織のすべてのユーザーを保護する可能性があります。IOCの迅速かつ簡単な共有は、組織のブランケットカバレッジを提供し、タイムリーな方法で広範囲にわたる緩和を可能にします。それらは、システム管理者、小規模から大規模な組織から大規模なチームから単一の個人まで共有でき、すべてが彼らに防御を実装できるようにします。ネットワーク。
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.
IOCを共有し、調査の取り組みの重複を節約することで時間の節約があるだけでなく、多くの企業にとって大規模にそれらを自動的に展開することはシームレスです。IOCの自動展開がうまく機能している場合、組織とユーザーは、最小限の人間の介入と最小限の努力でブランケット保護を受けます。これは、攻撃防御の重要な目標です。大規模でペースでこれを行う能力は、頻繁に侵入セットを変える可能性のあるアジャイルな脅威アクターに対応する場合、多くの場合不可欠です。逆に、IOCの自動展開なしで複雑なネットワークを保護することは、すべてのエンドポイントまたはネットワークデバイスを一貫して同じセキュリティ状態に手動で更新することを意味します。これに伴う作業（資産とデバイスの検索、ログとシステム情報のポーリング、パッチレベルの手動でのチェックなど）は、複雑さと熟練したアナリストとエンジニアの必要性をもたらします。IOCの効率的な展開を有効にするために努力を投資する必要がありますが、IOCを広く展開するときに誤検知を排除するためには、すべてのエンドポイントとネットワークデバイスを確実に手動で更新することに伴う作業よりもはるかに少ない場合があります。たとえば、レガシーシステムは、更新するのが特に複雑であるか、不可能である場合があります。
A network defender can use recently acquired IoCs in conjunction with historic data, such as logged DNS queries or email attachment hashes, to hunt for signs of past compromise. Not only can this technique help to build a clear picture of past attacks, but it also allows for retrospective mitigation of the effects of any previous intrusion. This opportunity is reliant on historic data not having been compromised itself, by a technique such as Timestomp [Timestomp], and not being incomplete due to data retention policies, but it is nonetheless valuable for detecting and remediating past attacks.
ネットワークディフェンダーは、ログに登録されたDNSクエリや電子メールの添付ファイルのハッシュなどの歴史的なデータと組み合わせて、最近取得したIOCを使用して、過去の妥協の兆候を探しています。この手法は、過去の攻撃の明確な絵を構築するのに役立つだけでなく、以前の侵入の効果の遡及的緩和も可能にします。この機会は、Timestomp [Timestomp]などの手法によって、歴史的なデータが妥協されていないことであり、データ保持ポリシーのために不完全ではありませんが、それでも過去の攻撃を検出して修正するのに役立ちます。
Deployment of various modern security controls, such as firewall filtering or EDR, come with an inherent trade-off between breadth of protection and various costs, including the risk of false positives (see Section 5.2), staff time, and pure financial costs. Organisations can use threat modelling and information assurance to assess and prioritise risk from identified threats and to determine how they will mitigate or accept each of them. Contextual information tying IoCs to specific threats or actors and shared alongside the IoCs enables organisations to focus their defences against particular risks. This contextual information is generally expected by those receiving IoCs as it allows them the technical freedom and capability to choose their risk appetite, security posture, and defence methods. The ease of sharing this contextual information alongside IoCs, in part due to the formats outlined in Section 3.2.3, makes it easier to track malicious actors across campaigns and targets. Producing this contextual information before sharing IoCs can take intensive analytical effort as well as specialist tools and training. At its simplest, it can involve documenting sets of IoCs from multiple instances of the same attack campaign, for example, from multiple unique payloads (and therefore with distinct file hashes) from the same source and connecting to the same C2 server. A more complicated approach is to cluster similar combinations of TTPs seen across multiple campaigns over a period of time. This can be used alongside detailed malware reverse engineering and target profiling, overlaid on a geopolitical and criminal backdrop, to infer attribution to a single threat actor.
ファイアウォールフィルタリングやEDRなどのさまざまな最新のセキュリティコントロールの展開には、保護の幅と、誤検知のリスク（セクション5.2を参照）、スタッフの時間、および純粋な財務コストなど、さまざまなコストの間に固有のトレードオフがあります。組織は、脅威モデリングと情報保証を使用して、特定された脅威からリスクを評価および優先順位付けし、それらがそれぞれを緩和または受け入れる方法を決定することができます。IOCを特定の脅威またはアクターに結び付け、IOCと共有するコンテキスト情報により、組織は特定のリスクに反対する防御を集中させることができます。このコンテキスト情報は、IOCを受け取った人が一般的に予想されます。これにより、リスクの自由と能力がリスクのアッピット、セキュリティ姿勢、防御方法を選択できるようになります。セクション3.2.3で概説されている形式のために、IOCと一緒にこのコンテキスト情報を共有しやすく、キャンペーンやターゲット全体の悪意のあるアクターを簡単に追跡できます。IOCを共有する前にこのコンテキスト情報を作成することで、集中的な分析的努力と専門のツールとトレーニングを受けることができます。最も簡単に言えば、同じ攻撃キャンペーンの複数のインスタンス、たとえば複数の一意のペイロード（したがって、異なるファイルハッシュ）から同じソースから、同じC2サーバーに接続することから、IOCのセットを文書化することができます。より複雑なアプローチは、一定期間にわたって複数のキャンペーンで見られるTTPの同様の組み合わせをクラスター化することです。これは、詳細なマルウェアリバースエンジニアリングとターゲットプロファイリングとともに使用でき、地政学的および犯罪的背景にオーバーレイされ、単一の脅威アクターへの帰属を推測できます。
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.
次の2つのケーススタディは、脅威アクターのツール（最初）と脅威アクターキャンペーン（2番目）に関連してIOCがどのように特定されるかを示しています。ケーススタディは、これらのIOCがサイバーディフェンダーによってどのように使用されるかをさらに強調しています。
Cobalt Strike [COBALT] is a commercial attack framework used for penetration testing that consists of an implant framework (beacon), a network protocol, and a C2 server. The beacon and network protocol are highly malleable, meaning the protocol representation "on the wire" can be easily changed by an attacker to blend in with legitimate traffic by ensuring the traffic conforms to the protocol specification, e.g., HTTP. The proprietary beacon supports TLS encryption overlaid with a custom encryption scheme based on a public-private keypair. The product also supports other techniques, such as domain fronting [DFRONT], in an attempt to avoid obvious passive detection by static network signatures of domain names or IP addresses. Domain fronting is used to blend traffic to a malicious domain with traffic originating from a network that is already communicating with a non-malicious domain regularly over HTTPS.
コバルトストライク[コバルト]は、インプラントフレームワーク（ビーコン）、ネットワークプロトコル、およびC2サーバーで構成される浸透テストに使用される商用攻撃フレームワークです。ビーコンとネットワークのプロトコルは非常に順応性があります。つまり、プロトコル表現は、攻撃者によって簡単に変更され、トラフィックがプロトコル仕様、たとえばHTTPに適合するようにすることで合法的なトラフィックと溶け込むことができます。独自のビーコンは、官民のキーペアに基づいたカスタム暗号化スキームでオーバーレイされたTLS暗号化をサポートしています。この製品は、ドメイン名またはIPアドレスの静的ネットワーク署名による明らかなパッシブ検出を回避するために、ドメインフロント[dfront]などの他の手法もサポートしています。ドメインフロンティングは、httpsを介して定期的に非悪質なドメインと既に通信しているネットワークからのトラフィックと、悪意のあるドメインとトラフィックを融合するために使用されます。
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.
ビーコン構成では、インプラントがどのように動作してC2サーバーと通信するかを説明します。この構成は、コバルトストライクユーザーライセンス透かしなどの補助情報も提供します。
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.
特定の要求への応答に基づいて、C2サーバーのフィンガープリントを可能にするTradeCraftが開発されました。これにより、サーバーを識別し、ビーコン構成をダウンロードし、関連するインフラストラクチャアドレスをIOCとして抽出することができます。
The resulting mass IoCs for Cobalt Strike are:
コバルトストライキのための結果として生じる質量IOCは次のとおりです。
* IP addresses of the C2 servers
* C2サーバーのIPアドレス
* domain names used
* 使用されるドメイン名
Whilst these IoCs need to be refreshed regularly (due to the ease of which they can be changed), the authors' experience of protecting public sector organisations shows that these IoCs are effective for disrupting threat actor operations that use Cobalt Strike.
これらのIOCは定期的にリフレッシュする必要がありますが（変更が容易なため）、公共部門の組織を保護する著者の経験は、これらのIOCがコバルトストライキを使用する脅威アクターの運用を破壊するのに効果的であることを示しています。
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.
これらのIOCを使用して、過去の妥協の証拠を確認し、将来の感染をタイムリーに検出またはブロックするために展開された証拠を確認し、それによりユーザーとシステムのデータの損失の防止に貢献できます。
In contrast to the first case study, this describes a current campaign by the threat actor APT33, also known as Elfin and Refined Kitten (see [Symantec]). APT33 has been assessed by the industry to be a state-sponsored group [FireEye2]; yet, in this case study, IoCs still gave defenders an effective tool against such a powerful adversary. The group has been active since at least 2015 and is known to target a range of sectors including petrochemical, government, engineering, and manufacturing. Activity has been seen in countries across the globe but predominantly in the USA and Saudi Arabia.
最初のケーススタディとは対照的に、これは脅威俳優APT33による現在のキャンペーン、エルフィンおよび洗練された子猫としても知られています（[Symantec]を参照）。APT33は、業界が国家が後援するグループ[FiREEYE2]として評価されています。しかし、このケーススタディでは、IOCSは依然として防御者にこのような強力な敵に対する効果的なツールを与えました。このグループは、少なくとも2015年以来活動しており、石油化学、政府、エンジニアリング、製造を含むさまざまなセクターを対象とすることが知られています。活動は世界中の国で見られていますが、主に米国とサウジアラビアで見られています。
The techniques employed by this actor exhibit a relatively low level of sophistication, considering it is a state-sponsored group. Typically, APT33 performs spear phishing (sending targeted malicious emails to a limited number of pre-selected recipients) with document lures that imitate legitimate publications. User interaction with these lures executes the initial payload and enables APT33 to gain initial access. Once inside a target network, APT33 attempts to pivot to other machines to gather documents and gain access to administrative credentials. In some cases, users are tricked into providing credentials that are then used with Ruler [RULER], a freely available tool that allows exploitation of an email client. The attacker, in possession of a target's password, uses Ruler to access the target's mail account and embeds a malicious script that will be triggered when the mail client is next opened, resulting in the execution of malicious code (often additional malware retrieved from the Internet) (see [FireEye]).
この俳優が採用している技術は、州が後援するグループであることを考えると、比較的低いレベルの洗練を示しています。通常、APT33は、合法的な出版物を模倣したドキュメントルアーを使用して、スピアフィッシング（限られた数の事前に選択された受信者にターゲットの悪意のある電子メールを送信する）を実行します。これらのルアーとのユーザーインタラクションは、初期ペイロードを実行し、APT33が初期アクセスを得ることができます。ターゲットネットワーク内に入ると、APT33は他のマシンにピボットしてドキュメントを収集し、管理資格情報にアクセスしようとします。場合によっては、ユーザーは、電子メールクライアントの活用を可能にする自由に利用可能なツールであるRuler [Ruler]で使用される資格情報を提供するようにだまされます。攻撃者は、ターゲットのパスワードを所有していますが、ルーラーを使用してターゲットのメールアカウントにアクセスし、メールクライアントが次に開かれたときにトリガーされる悪意のあるスクリプトを埋め込み、悪意のあるコード（多くの場合、インターネットから追加のマルウェアを再取得するマルウェアが追加されることがよくあります。）（[fireeye]を参照）。
APT33 sometimes deploys a destructive tool that overwrites the master boot record (MBR) of the hard drives in as many PCs as possible. This type of tool, known as a wiper, results in data loss and renders devices unusable until the operating system is reinstalled. In some cases, the actor uses administrator credentials to invoke execution across a large swathe of a company's IT estate at once; where this isn't possible, the actor may first attempt to spread the wiper manually or use worm-like capabilities against unpatched vulnerabilities on the networked computers.
APT33は、できるだけ多くのPCでハードドライブのマスターブートレコード（MBR）を上書きする破壊ツールを展開することがあります。ワイパーとして知られるこのタイプのツールは、データ損失をもたらし、オペレーティングシステムが再インストールされるまでデバイスを使用できません。場合によっては、俳優は管理者の資格情報を使用して、会社のITエステートの大規模なスワスで実行を呼び出します。これが不可能な場合、俳優は最初にワイパーを手動で広めようとするか、ネットワーク化されたコンピューターの未収脆弱性に対してワームのような機能を使用しようとします。
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:
業界と英国の国立サイバーセキュリティセンター（NCSC）のパートナーシップによる調査の結果、ネットワークディフェンダーがネットワークでそれらを検索できるように、一連のIOCが編集および共有されました。これらのIOCの検出は、APT33ターゲティングを示している可能性が高く、破壊的なマルウェアの潜在的な妥協とその後の使用を示す可能性があります。ネットワークディフェンダーは、これらのIOCをブロックして将来の攻撃を阻止するプロセスを開始することもできます。このIOCのセットは次のとおりです。
* 9 hashes and email subject lines
* 9ハッシュおよび電子メールの件名
* 5 IP addresses
* 5つのIPアドレス
* 7 domain names
* 7ドメイン名
In November 2021, a joint advisory concerning APT33 [CISA] was issued by the Federal Bureau of Investigation (FBI), the Cybersecurity and Infrastructure Security Agency (CISA), the Australian Cyber Security Centre (ACSC), and NCSC. This outlined recent exploitation of vulnerabilities by APT33, providing a thorough overview of observed TTPs and sharing further IoCs:
2021年11月、APT33 [CISA]に関する共同アドバイザリーが、連邦捜査局（FBI）、サイバーセキュリティおよびインフラストラクチャセキュリティ局（CISA）、オーストラリアサイバーセキュリティセンター（ACSC）、およびNCSCによって発行されました。これには、APT33による脆弱性の最近の搾取が概説されており、観測されたTTPの徹底的な概要を提供し、さらにIOCを共有しています。
* 8 hashes of malicious executables
* 悪意のある実行可能ファイルの8つのハッシュ
* 3 IP addresses
* 3つのIPアドレス
The different IoC types inherently embody a set of trade-offs for defenders between the risk of false positives (misidentifying non-malicious traffic as malicious) and the risk of failing to identify attacks. The attacker's relative pain of modifying attacks to subvert known IoCs, as discussed using the PoP in Section 3.1, inversely correlates with the fragility of the IoC and with the precision with which the IoC identifies an attack. Research is needed to elucidate the exact nature of these trade-offs between pain, fragility, and precision.
さまざまなIOCタイプは、誤検知のリスク（悪意のあるトラフィックを悪意と誤解する）と攻撃を特定できないリスクの間の防御者のトレードオフのセットを本質的に具体的に具体化します。セクション3.1でPOPを使用して議論されているように、既知のIOCを破壊する攻撃者の相対的な痛みは、IOCの脆弱性とIOCが攻撃を識別する精度と逆相関します。痛み、脆弱性、精度の間のこれらのトレードオフの正確な性質を解明するには、研究が必要です。
As alluded to in Section 3.1, the PoP can be thought of in terms of fragility for the defender as well as pain for the attacker. The less painful it is for the attacker to change an IoC, the more fragile that IoC is as a defence tool. It is relatively simple to determine the hash value for various malicious file attachments observed as lures in a phishing campaign and to deploy these through AV or an email gateway security control. However, those hashes are fragile and can (and often will) be changed between campaigns. Malicious IP addresses and domain names can also be changed between campaigns, but this may happen less frequently due to the greater pain of managing infrastructure compared to altering files, and so IP addresses and domain names may provide a less fragile detection capability.
セクション3.1で言及されているように、ポップは、攻撃者の痛みだけでなく、ディフェンダーの脆弱性の観点から考えることができます。攻撃者がIOCを変更するのが痛いほど、IOCが防御ツールとしてより脆弱です。フィッシングキャンペーンでルアーとして観察されたさまざまな悪意のあるファイル添付ファイルのハッシュ値を決定し、AVまたは電子メールゲートウェイセキュリティコントロールを介してこれらを展開することは比較的簡単です。ただし、これらのハッシュは壊れやすく、キャンペーン間で変更される可能性があります（そして多くの場合）。悪意のあるIPアドレスとドメイン名もキャンペーン間で変更される可能性がありますが、ファイルの変更と比較してインフラストラクチャを管理することの痛みが大きいため、これはあまり頻繁に発生する可能性があります。そのため、IPアドレスとドメイン名は脆弱な検出機能を提供する可能性があります。
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.
これは、より脆弱なIOCタイプが価値がないという意味ではありません。第一に、脆弱なIOCが変更される保証はありません。既知のIOCが攻撃者によって変更されないがブロックされていない場合、ディフェンダーはそのトラックでの攻撃を停止する機会を逃しました。第二に、1つのIOCタイプ内であっても、IOCのコンテキストに応じて脆弱性に変動があります。フィッシングルアードキュメントのファイルハッシュ（特定のテーマと特定のステージングサーバーリンクを含む）は、最初のアクセス後に攻撃者が使用するリモートアクセスのファイルハッシュよりも脆弱である場合があります。これは、攻撃者のインフラストラクチャに直接接続しない攻撃者が管理する爆発後の偵察偵察ツールのファイルハッシュよりも脆弱な場合があります。第三に、一部の脅威と俳優は他の脅威よりも能力があるか、変化する傾向があるため、IOCの脆弱性は、他の俳優の同じタイプのIOCとは非常に異なる場合があります。
Ultimately, fragility is a defender's concern that impacts the ongoing efficacy of each IoC and will factor into decisions about end of life. However, it should not prevent adoption of individual IoCs unless there are significantly strict resource constraints that demand down-selection of IoCs for deployment. More usually, defenders researching threats will attempt to identify IoCs of varying fragilities for a particular kill chain to provide the greatest chances of ongoing detection given available investigative effort (see Section 5.1.2) and while still maintaining precision (see Section 5.2).
最終的に、脆弱性は、各IOCの継続的な有効性に影響を与えるディフェンダーの懸念であり、終末期に関する決定を考慮します。ただし、展開のためにIOCのダウン選択を要求する大幅に厳格なリソースの制約がない限り、個々のIOCの採用を妨げるべきではありません。より通常、脅威を研究しているディフェンダーは、特定のキルチェーンのさまざまな脆弱性のIOCを特定し、利用可能な調査努力（セクション5.1.2を参照）を与えられた継続的な検出の最大の可能性を提供し、精度を維持しながら（セクション5.2を参照）。
To be used in attack defence, IoCs must first be discovered through proactive hunting or reactive investigation. As noted in Section 3.1, IoCs in the tools and TTPs levels of the PoP require intensive effort and research to discover. However, it is not just an IoC's type that impacts its discoverability. The sophistication of the actor, their TTPs, and their tooling play a significant role, as does whether the IoC is retrieved from logs after the attack or extracted from samples or infected systems earlier.
攻撃防御に使用するには、最初に積極的な狩猟またはリアクティブ調査を通じて発見する必要があります。セクション3.1で述べたように、POPのツールとTTPSレベルのIOCは、発見するために集中的な努力と研究が必要です。ただし、発見可能性に影響を与えるのはIOCのタイプだけではありません。俳優、TTP、および彼らのツールの洗練は、攻撃後にIOCがログから取得されるか、サンプルまたは感染システムから抽出されたかどうかと同様に、重要な役割を果たします。
For example, on an infected endpoint, it may be possible to identify a malicious payload and then extract relevant IoCs, such as the file hash and its C2 server address. If the attacker used the same static payload throughout the attack, this single file hash value will cover all instances. However, if the attacker diversified their payloads, that hash can be more fragile, and other hashes may need to be discovered from other samples used on other infected endpoints. Concurrently, the attacker may have simply hard-coded configuration data into the payload, in which case the C2 server address can be easy to recover. Alternatively, the address can be stored in an obfuscated persistent configuration within either the payload (e.g., within its source code or associated resource) or the infected endpoint's file system (e.g., using alternative data streams [ADS]), thus requiring more effort to discover. Further, the attacker may be storing the configuration in memory only or relying on a DGA to generate C2 server addresses on demand. In this case, extracting the C2 server address can require a memory dump or the execution or reverse engineering of the DGA, all of which increase the effort still further.
たとえば、感染したエンドポイントでは、悪意のあるペイロードを識別してから、ファイルハッシュやそのC2サーバーアドレスなどの関連するIOCを抽出することができる場合があります。攻撃者が攻撃全体で同じ静的ペイロードを使用した場合、この単一のファイルハッシュ値はすべてのインスタンスをカバーします。ただし、攻撃者がペイロードを多様化した場合、そのハッシュはより脆弱になる可能性があり、他の感染したエンドポイントで使用される他のサンプルから他のハッシュを発見する必要があります。同時に、攻撃者は単にハードコーディングされた構成データをペイロードに持っている可能性があります。その場合、C2サーバーアドレスは簡単に回復できます。あるいは、アドレスは、ペイロード（そのソースコードまたは関連リソース内）または感染したエンドポイントのファイルシステム（例：代替データストリーム[ADS]を使用）のいずれか内で難読化された永続的な構成に保存できます。発見する。さらに、攻撃者はメモリのみに構成を保存しているか、DGAに依存してC2サーバーアドレスをオンデマンドで生成する場合があります。この場合、C2サーバーアドレスを抽出するには、DGAのメモリダンプまたは実行またはリバースエンジニアリングが必要になる場合があります。これらはすべて、さらに取り組みを増加させます。
If the malicious payload has already communicated with its C2 server, then it may be possible to discover that C2 server address IoC from network traffic logs more easily. However, once again, multiple factors can make discoverability more challenging, such as the increasing adoption of HTTPS for malicious traffic, meaning C2 communications blend in with legitimate traffic and can be complicated to identify. Further, some malwares obfuscate their intended destinations by using alternative DNS resolution services (e.g., OpenNIC [OPENNIC]), by using encrypted DNS protocols such as DNS-over-HTTPS [OILRIG], or by performing transformation operations on resolved IP addresses to determine the real C2 server address encoded in the DNS response [LAZARUS].
悪意のあるペイロードが既にC2サーバーと通信している場合、ネットワークトラフィックログからC2サーバーがIOCをより簡単にアドレス指定することを発見することが可能かもしれません。ただし、繰り返しになりますが、複数の要因により、悪意のあるトラフィックに対するHTTPの採用が増加するなど、発見可能性がより困難になります。つまり、C2通信は合法的なトラフィックと融合し、識別するのが複雑になる可能性があります。さらに、一部のマルウェアは、代替DNS解像度サービス（例：Opennic [Opennic]）を使用して、DNS-Over-HTTPS [Oilrig]などの暗号化されたDNSプロトコルを使用するか、解決されたIPアドレスで変換操作を実行して実行することにより、意図した目的地を難読化します。DNS応答[Lazarus]でエンコードされた実際のC2サーバーアドレス。
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.
多くの場合、マルウェアサンプルで発見された、またはマルウェアサンプルで発見されたアクティビティから生じるインジケーターのリストは比較的短いため、限られた方法ですべてのインジケーターの合計セットにのみ追加されます。これの明確な例は、C2サーバーの静的インジケーターがマルウェア株で発見された場合です。共有、展開、および検出は、もう1つのインシデントまたはもう1つのサンプルにそのような指標を追加することによって大きな影響を受けないことがよくあります。ただし、DGAの発見の場合、これにはアルゴリズムの再実装が必要であり、実行してドメインの可能なリストを生成する必要があります。アルゴリズムに応じて、これにより、特に検出中にパフォーマンスの劣化を引き起こす可能性があるインジケータの非常に大きなリストが生じる可能性があります。場合によっては、そのような指標の原因は、考えられる指標値の合理的なカバレッジを取得することと、考えられるすべてのインジケーター値のリストの理論的完全性を取得することとの間に実用的な決定につながる可能性があります。
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.
痛みと脆弱性に加えて、ポップのレベルは、防御がどれほど正確であるかという点でも考慮することができます。これは、ピラミッドをより特定のIOCに移動するにつれて、偽陽性率が通常増加します。ハッシュ値は、実行可能なバイナリなどの特定のファイルを識別し、適切な暗号化ハッシュ関数を与えられると、誤検知は効果的にゼロです（「適切」では、プリイメージ抵抗と強い衝突抵抗を意味します）。それに比べて、上位レベルのIOC（一部のネットワークアーティファクトやツールフィンガープリントなど）は、さまざまな悪意のあるバイナリに適用される場合があり、良性ソフトウェアでさえ同じ識別特性を共有する場合があります。たとえば、Webリクエストを作成する脅威アクターツールは、リクエストヘッダーで指定されたユーザーエージェント文字列によって識別される場合があります。ただし、この値は、攻撃者が選択するか、一般的なライブラリの使用を通じて、合法的なソフトウェアが使用するものと同じである場合があります。
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.
IOCがより具体的であればあるほど、より脆弱であることは驚くことではありません。物事が変わるにつれて、彼らはその特定の焦点の外に移動します。壊れやすいIOCは、その堅牢性と長寿にとって望ましいものである可能性がありますが、これは、その広大さからの誤検知の可能性の増加とバランスが取れなければなりません。このバランスが達成される1つの方法は、インジケーターをグループ化し、それらを組み合わせて使用することです。特定の攻撃の2つの低分のIOCは、それぞれが誤検知の可能性を持つ可能性がありますが、一緒に観察すると、関連するキルチェーンの正確な検出のより大きな自信を提供する可能性があります。
As noted in Section 3.2.2, the context of an IoC, such as the way in which the attacker uses it, may equally impact the precision with which that IoC detects an attack. An IP address representing an attacker's staging server, from which their attack chain downloads subsequent payloads, offers a precise IP address for attacker-owned infrastructure. However, it will be less precise if that IP address is associated with a cloud-hosting provider and is regularly reassigned from one user to another; it will be less precise still if the attacker compromised a legitimate web server and is abusing the IP address alongside the ongoing legitimate use.
セクション3.2.2で述べたように、攻撃者がそれを使用する方法など、IOCのコンテキストは、IOCが攻撃を検出する精度に等しく影響する可能性があります。攻撃者のステージングサーバーを表すIPアドレスは、攻撃チェーンがその後のペイロードをダウンロードすると、攻撃者が所有するインフラストラクチャに正確なIPアドレスを提供します。ただし、そのIPアドレスがクラウドホスティングプロバイダーに関連付けられ、あるユーザーから別のユーザーに定期的に再割り当てされている場合、それほど正確ではありません。攻撃者が正当なWebサーバーを侵害し、進行中の正当な使用とともにIPアドレスを乱用している場合、それはまだそれほど正確ではありません。
Similarly, a file hash representing an attacker's custom remote access trojan will be very precise; however, a file hash representing a common enterprise remote administration tool will be less precise, depending on whether or not the defender organisation usually uses that tool for legitimate system administration. Notably, such dual-use indicators are context specific, considering both whether they are usually used legitimately and how they are used in a particular circumstance. Use of the remote administration tool may be legitimate for support staff during working hours but not generally by non-support staff, particularly if observed outside of that employee's usual working hours.
同様に、攻撃者のカスタムリモートアクセストロイの木馬を表すファイルハッシュは非常に正確です。ただし、ディフェンダー組織が通常正当なシステム管理にそのツールを使用するかどうかに応じて、一般的なエンタープライズリモート管理ツールを表すファイルハッシュの正確さは低くなります。特に、このような二重使用インジケーターは、通常正当に使用されるかどうか、特定の状況でどのように使用されるかの両方を考慮して、コンテキスト固有です。リモート管理ツールの使用は、特にその従業員の通常の労働時間以外で観察された場合、勤務時間中はサポートスタッフにとっては正当なものではありません。
For reasons like these, context is very important when sharing and using IoCs.
このような理由から、IOCを共有して使用するときにコンテキストが非常に重要です。
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.
IPアドレスの場合、クラウドサービス、プロキシ、仮想プライベートネットワーク（VPNS）、およびキャリアグレードのネットワークアドレス翻訳（NAT）の採用の増加により、同じ瞬間に1つのIPアドレスに関連付けられているシステムの数が増加しています。時間。IPアドレスの使用に対するこの継続的な変更は、IPアドレスの特異性をいくらか減少させます（少なくとも特定のサブネットまたは個々のアドレスの場合は）。また、脅威アクターがIPアドレスを変更する必要がある場合に脅迫される痛みを「サイドステップ」します。
As noted in Section 3.2.2, context is critical to effective detection using IoCs. However, at times, defenders may feel there are privacy concerns with how much and with whom to share about a cyber intrusion. For example, defenders may generalise the IoCs' description of the attack by removing context to facilitate sharing. This generalisation can result in an incomplete set of IoCs being shared or IoCs being shared without clear indication of what they represent and how they are involved in an attack. The sharer will consider the privacy trade-off when generalising the IoC and should bear in mind that the loss of context can greatly reduce the utility of the IoC for those they share with.
セクション3.2.2で述べたように、IOCを使用した効果的な検出にはコンテキストが重要です。ただし、時には、ディフェンダーは、サイバー侵入についてどれだけ、誰と共有するかについてプライバシーの懸念があると感じるかもしれません。たとえば、ディフェンダーは、共有を容易にするためにコンテキストを削除することにより、IOCSの攻撃の説明を一般化することができます。この一般化により、IOCが共有されていない、またはIOCが共有される可能性があります。共有者は、IOCを一般化する際にプライバシーのトレードオフを検討し、コンテキストの喪失により、共有する人のIOCの有用性を大幅に減らすことができることに留意する必要があります。
In the authors' experiences, self-censoring by sharers appears more prevalent and more extensive when sharing IoCs into groups with more members, into groups with a broader range of perceived member expertise (particularly, the further the lower bound extends below the sharer's perceived own expertise), and into groups that do not maintain strong intermember trust. Trust within such groups often appears strongest where members interact regularly; have common backgrounds, expertise, or challenges; conform to behavioural expectations (such as by following defined handling requirements and not misrepresenting material they share); and reciprocate the sharing and support they receive. [LITREVIEW] highlights that many of these factors are associated with the human role in Cyber Threat Intelligence (CTI) sharing.
著者の経験では、共有者による自己検閲は、IOCをより多くのメンバーとグループに共有すると、より広範で広範囲に見えます。専門知識）、および強力なインターメンバーの信頼を維持しないグループへ。そのようなグループ内の信頼は、メンバーが定期的にやり取りする場合に最も強く見えます。共通の背景、専門知識、または課題があります。行動の期待に準拠しています（定義された取り扱い要件に従って、共有する資料を誤って伝えないように）。そして、彼らが受け取る共有とサポートを往復させます。[Litreview]これらの要因の多くは、サイバー脅威インテリジェンス（CTI）共有における人間の役割に関連していることを強調しています。
While IoCs can be effectively utilised by organisations of various sizes and resource constraints, as discussed in Section 4.1.2, automation of IoC ingestion, processing, assessment, and deployment is critical for managing them at scale. Manual oversight and investigation may be necessary intermittently, but a reliance on manual processing and searching only works at small scale or for occasional cases.
IOCは、セクション4.1.2で説明したように、さまざまなサイズとリソースの制約の組織で効果的に利用できますが、IOC摂取、処理、評価、展開の自動化は、それらを大規模に管理するために重要です。手動での監視と調査が断続的に必要になる場合がありますが、手動処理と検索に依存すると、小規模または時折の場合にのみ機能します。
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.
また、自動化の採用により、異なるログソースにわたるIOC検出と、さまざまな時間や物理的な位置にわたってネットワーク監視インターフェースのより速く、より簡単に相関することもできます。したがって、応答は、特定の侵入セットからの検出の数とオーバーラップを反映するように調整することができ、Defenderレビューのアラートを生成するときに必要なコンテキストを検出とともに提示できます。手動の処理と検索はそれほど正確ではありませんが（著者の経験で忙しい事件の際にはIOC転写エラーは一般的な問題ですが）、同じ程度の状況認識を提供するために必要な相関と相互参照ははるかに時間です。消費する。
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.
手動処理を実行する際の3番目の重要な考慮事項は、IOCが無関係になったり、より重要なことに不正確になったりするにつれて、IOCを効果的に老化させるために必要なより長い位相監視と調整です。手動の実装は、多くの場合、IOCを単純に含めるか除外する必要があります。これは、より粒状が時間がかかり、複雑であるため、IOCを除外する必要があります。対照的に、自動化は信頼スコアリングの徐々に減少することをサポートし、IOCが貢献できるようにしますが、特異性が低下するにつれて個別に検出を混乱させることはできません。
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.
IOCは、ポップのレイヤー全体にあるさまざまなオプションをディフェンダーに提供し、精度と脆弱性のバランスをとって、実用的で有用な高い信頼検出を提供することができます。POPの幅広いカバレッジは、ディフェンダーが高精度であるが高い脆弱性オプションと、可用性に応じてより堅牢ではあるがより正確なインジケーターを選択できるため、重要です。脆弱な指標が変更されると、より堅牢なIOCが継続的な検出とより速い再発見を可能にします。このため、ディフェンダーにオプションを提供するために、ポップ全体でできるだけ多くのIOCを収集することが重要です。
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.
POPの頂点では、異常検出と機械学習を通じて特定されたTTPは、誤検知をもたらす可能性が高く、自信が低くなり、virtめたに訓練されたアナリストが防御を理解して実装する必要があります。ただし、これらは攻撃者が変更するのが非常に苦痛なため、適切に調整すると、堅牢な検出が提供されます。下部のハッシュは正確で展開しやすいですが、壊れやすく、悪意のある俳優によってキャンペーン内およびキャンペーン全体で簡単に変更されます。
Endpoint Detection and Response (EDR) or Antivirus (AV) are often the first port of call for protection from intrusion, but endpoint solutions aren't a panacea. One issue is that there are many environments where it is not possible to keep them updated or, in some cases, deploy them at all. For example, the Owari botnet, a Mirai variant [Owari], exploited Internet of Things (IoT) devices where such solutions could not be deployed. It is because of such gaps, where endpoint solutions can't be relied on, that a defence-in-depth approach is commonly advised, using a blended approach that includes both network and endpoint defences.
エンドポイント検出と応答（EDR）またはウイルス対策（AV）は、多くの場合、侵入から保護するための最初の呼び出しポートですが、エンドポイントソリューションは万能薬ではありません。1つの問題は、それらを更新するか、場合によってはそれらを展開することができない多くの環境があることです。たとえば、Miraiバリアント[Owari]であるOwari Botnetは、そのようなソリューションを展開できなかったモノのインターネット（IoT）デバイスを活用しました。エンドポイントソリューションを信頼できないこのようなギャップが原因で、ネットワークとエンドポイントの防御の両方を含むブレンドアプローチを使用して、より詳細なアプローチが一般的に推奨されます。
If an attack happens, then the best situation is that an endpoint solution will detect and prevent it. If it doesn't, it could be for many good reasons: the endpoint solution could be quite conservative and aim for a low false-positive rate, it might not have ubiquitous coverage, or it might only be able to defend the initial step of the kill chain [KillChain]. In the worst cases, the attack specifically disables the endpoint solution, or the malware is brand new and so won't be recognised.
攻撃が発生した場合、最良の状況は、エンドポイントソリューションがそれを検出および防止することです。そうでない場合、それは多くの正当な理由である可能性があります：エンドポイントソリューションは非常に保守的であり、低い偽陽性レートを目指している可能性があります。キルチェーン[Killchain]。最悪の場合、攻撃はエンドポイントソリューションを具体的に無効にするか、マルウェアが新品であるため、認識されません。
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.
ピラミッドの中央では、ネットワーク情報（ドメインやIPアドレスなど）に関連するIOCが特に役立ちます。それらは、ネットワークチョークポイント（プロキシやゲートウェイなど）でより集中化された方法で検出および実施される可能性があるため、すべてのエンドポイントセキュリティソリューションを更新する必要なく、幅広いカバレッジを可能にします。これにより、独自のデバイス（BYOD）、モノのインターネット（IoT）、レガシー環境など、エンドポイントのセキュリティが不可能なコンテキストで特に役立ちます。これらのネットワークレベルのIOCは、妥協自体が気付かれない場合でも、これらのIOCがネットワークトラフィックの攻撃を検出するために使用される場合、侵害されたエンドポイントからネットワークのユーザーを保護できることに注意することが重要です。たとえば、BYOD環境では、デバイス上のセキュリティポリシーを実施することは困難な場合があるため、エンドポイントカバレッジがなくても妥協の検出を可能にするために、非エンドポイントIOCとソリューションが必要です。
One example of how network-level IoCs provide a layer of a defence-in-depth solution is Protective DNS (PDNS) [Annual2021], a free and voluntary DNS filtering service provided by the UK NCSC for UK public sector organisations [PDNS]. In 2021, this service blocked access to more than 160 million DNS queries (out of 602 billion total queries) for the organisations signed up to the service [ACD2021]. This included hundreds of thousands of queries for domains associated with Flubot, Android malware that uses DGAs to generate 25,000 candidate command and control domains each month (these DGAs [DGAs] are a type of TTP).
ネットワークレベルのIOCが詳細な解決策の層を提供する方法の1つの例は、英国NCSCが英国の公共部門組織[PDNS]に提供する自由で自発的なDNSフィルタリングサービスである保護DNS（PDNS）[Annual2021] [PDNS]です。2021年、このサービスは、サービスに登録された組織[ACD2021]の1億6,000万DNSクエリ（合計6,000億クエリのうち）へのアクセスをブロックしました。これには、DGAを使用して毎月25,000の候補コマンドとコントロールドメインを生成するAndroidマルウェアに関連付けられたドメインの数十万のクエリが含まれます（これらのDGA [DGA]はTTPの一種です）。
IoCs such as malicious domains can be put on PDNS straight away and can then be used to prevent access to those known malicious domains across the entire estate of over 925 separate public sector entities that use NCSC's PDNS. Coverage can be patchy with endpoints, as the roll-out of protections isn't uniform or necessarily fast. However, if the IoC is on PDNS, a consistent defence is maintained for devices using PDNS, even if the device itself is not immediately updated. This offers protection, regardless of whether the context is a BYOD environment or a managed enterprise system. PDNS provides the most front-facing layer of defence-in-depth solutions for its users, but other IoCs, like Server Name Indication values in TLS or the server certificate information, also provide IoC protections at other layers.
悪意のあるドメインなどのIOCは、すぐにPDNSに置くことができ、その後、NCSCのPDNを使用する925を超える別々の公共部門エンティティの不動産全体にわたる既知の悪意のあるドメインへのアクセスを防ぐために使用できます。保護のロールアウトは均一ではないか、必ずしも高速ではないため、カバレッジはエンドポイントでパッチが多い場合があります。ただし、IOCがPDNSにある場合、デバイス自体がすぐに更新されなくても、PDNを使用したデバイスの一貫した防御が維持されます。これは、コンテキストがBYOD環境かマネージドエンタープライズシステムであるかに関係なく、保護を提供します。PDNSは、ユーザーに最も前向きなディフェンスソリューションの最前線のレイヤーを提供しますが、TLSまたはサーバー証明書情報のサーバー名表示値など、他のIOCも他のレイヤーでIOC保護を提供します。
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.
AVシナリオと同様に、大規模なサービスは、誤検知からのビジネスへの影響との脅威のバランスをとることに関するリスクの決定に直面しています。組織は、自分の防御でより保守的になる能力を維持することができる必要があります。たとえば、商用DNSフィルタリングサービスは幅広い展開を目的としているため、AV製品と同様のリスク許容度がありますが、政府ユーザー（PDNなど）を対象としたDNSフィルタリングは、より保守的ですが、それでも比較的幅広い展開があります。政府全体を意図した場合。一方、政府部門または特定の企業は、自信に関係なく、特定の脅威に関連するものを完全にブロックするために、混乱のリスクを受け入れ、ファイアウォールまたは他のネットワーク保護装置を手配するかもしれませんが、他のすべてのDNSフィルタリングサービスに依存しています。
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.
他のネットワーク防御は、Middlebox Mitigation、Proxy Defenses、アプリケーション層ファイアウォールなど、IOCからのこのブランケットカバレッジを利用できますが、このドキュメントの範囲外です。大規模なエンタープライズネットワークは、独自のDNS解像度アーキテクチャを展開し、場合によってはTLS検査プロキシを展開する可能性が高く、これらの場所にIOCを展開できます。ただし、これらの種類の緩和を展開することを選択しない、またはリソースを持っていないネットワークでは、DNSはファイアウォール、プロキシ、および場合によってはDNSフィルタリングサービスを通過します。暗号化されていない必要はありませんが、これらのアプライアンスは、既知の悪いURIのクエリをブロックするなど、それを使用するためにそれを復号化できる必要があります。
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.
幅広いIOCをカバーすることで、ディフェンダーは幅広い利点を提供します。展開しやすいです。彼らは効果的であるのに十分な自信を与えます。少なくとも攻撃者が変化するのは苦痛なものもあります。そして、インフラストラクチャの周りの分布により、さまざまな障害点が可能になるため、全体的にディフェンダーが悪い俳優を混乱させることができます。これらの要因の組み合わせは、限られたリソースを持つ防御者にとって特に価値のあるツールとしてIOCをセメントします。
This document has no IANA actions.
このドキュメントにはIANAアクションがありません。
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.
このドキュメントは、システムセキュリティに関するものです。ただし、展開が不十分な場合、IOCはオーバーブロッキングにつながる可能性があり、一部のシステムには可用性の懸念が生じる可能性があります。IOCはマクロスケールでプライバシーを保持していますが（データ侵害を防止することにより）、IOCの共有によるプライバシーへの影響を調査するための調査が行われ、見つかった影響を最小限に抑えるために改善を行うことができます。ネットワークとエンドポイントの両方の防御がセキュリティと階層化された防御を提供することを許可するIOCを共有するプライバシー提示方法の作成は、興味深い提案です。
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.
IOCは多用途で強力です。IOCSは、近代的な防御戦略の複数の層を支えて有効にします。IOCは共有しやすく、攻撃防衛の取り組みに乗数効果を提供し、重要な時間を節約できます。ネットワークレベルのIOCは保護を提供します。これは、エンドポイントのみのソリューションでは十分ではない場合に特に価値があります。これらのプロパティは、使いやすさとともに、IOCSを攻撃防御戦略の重要なコンポーネントにし、特にリソースが限られているディフェンダーにとって価値があります。
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.
IOCが有用であるためには、ネットワークで暗号化されていない、または目に見える必要はありませんが、それらを必要とするエンティティがコンテキストとともに利用できるようにすることが重要です。また、この可用性と最終的な使用法は、IOCが重要な部分である詳細な戦略に従って、複数の障害点に対処することも重要です。
[ACD2021] UK NCSC, "Active Cyber Defence - The Fifth Year", May
2022, <https://www.ncsc.gov.uk/files/ACD-The-Fifth-Year-
full-report.pdf>.
[ADS] Microsoft, "File Streams (Local File Systems)", January
2021, <https://docs.microsoft.com/en-
us/windows/win32/fileio/file-streams>.
[ALIENVAULT]
AlienVault, "AlienVault: The World's First Truly Open
Threat Intelligence Community",
<https://otx.alienvault.com/>.
[Annual2021]
UK NCSC, "NCSC Annual Review 2021: Making the UK the
safest place to live and work online", 2021,
<https://www.ncsc.gov.uk/files/
NCSC%20Annual%20Review%202021.pdf>.
[CISA] CISA, "Iranian Government-Sponsored APT Cyber Actors
Exploiting Microsoft Exchange and Fortinet Vulnerabilities
in Furtherance of Malicious Activities", November 2021,
<https://www.cisa.gov/uscert/ncas/alerts/aa21-321a>.
[COBALT] "Cobalt Strike", <https://www.cobaltstrike.com/>.
[DFRONT] Infosec, "Domain Fronting", April 2017,
<https://resources.infosecinstitute.com/topic/domain-
fronting/>.
[DGAs] MITRE, "Dynamic Resolution: Domain Generation Algorithms",
2020, <https://attack.mitre.org/techniques/T1483/>.
[FireEye] O'Leary, J., Kimble, J., Vanderlee, K., and N. Fraser,
"Insights into Iranian Cyber Espionage: APT33 Targets
Aerospace and Energy Sectors and has Ties to Destructive
Malware", September 2017,
<https://www.mandiant.com/resources/blog/apt33-insights-
into-iranian-cyber-espionage>.
[FireEye2] Ackerman, G., Cole, R., Thompson, A., Orleans, A., and N.
Carr, "OVERRULED: Containing a Potentially Destructive
Adversary", December 2018,
<https://www.mandiant.com/resources/blog/overruled-
containing-a-potentially-destructive-adversary>.
[GoldenTicket]
Mizrahi, I. and Cymptom, "Steal or Forge Kerberos Tickets:
Golden Ticket", 2020,
<https://attack.mitre.org/techniques/T1558/001/>.
[KillChain]
Lockheed Martin, "The Cyber Kill Chain",
<https://www.lockheedmartin.com/en-us/capabilities/cyber/
cyber-kill-chain.html>.
[LAZARUS] Kaspersky Lab, "Lazarus Under The Hood",
<https://media.kasperskycontenthub.com/wp-
content/uploads/sites/43/2018/03/07180244/
Lazarus_Under_The_Hood_PDF_final.pdf>.
[LITREVIEW]
Wagner, T., Mahbub, K., Palomar, E., and A. Abdallah,
"Cyber Threat Intelligence Sharing: Survey and Research
Directions", January 2019, <https://www.open-
access.bcu.ac.uk/7852/1/Cyber%20Threat%20Intelligence%20Sh
aring%20Survey%20and%20Research%20Directions.pdf>.
[Mimikatz] Mulder, J., "Mimikatz Overview, Defenses and Detection",
February 2016, <https://www.sans.org/white-papers/36780/>.
[MISP] "MISP", <https://www.misp-project.org/>.
[MISPCORE] Dulaunoy, A. and A. Iklody, "MISP core format", Work in
Progress, Internet-Draft, draft-dulaunoy-misp-core-format-
16, 26 February 2023,
<https://datatracker.ietf.org/doc/html/draft-dulaunoy-
misp-core-format-16>.
[NCCGroup] Jansen, W., "Abusing cloud services to fly under the
radar", January 2021,
<https://research.nccgroup.com/2021/01/12/abusing-cloud-
services-to-fly-under-the-radar/>.
[NIST] NIST, "Glossary - security control",
<https://csrc.nist.gov/glossary/term/security_control>.
[OILRIG] Cimpanu, C., "Iranian hacker group becomes first known APT
to weaponize DNS-over-HTTPS (DoH)", August 2020,
<https://www.zdnet.com/article/iranian-hacker-group-
becomes-first-known-apt-to-weaponize-dns-over-https-doh/>.
[OPENIOC] Gibb, W. and D. Kerr, "OpenIOC: Back to the Basics",
October 2013, <https://www.fireeye.com/blog/threat-
research/2013/10/openioc-basics.html>.
[OPENNIC] "OpenNIC", <https://www.opennic.org/>.
[Owari] UK NCSC, "Owari botnet own-goal takeover", 2018, <https://
webarchive.nationalarchives.gov.uk/ukgwa/20220301141030/
https://www.ncsc.gov.uk/report/weekly-threat-report-8th-
june-2018>.
[PDNS] UK NCSC, "Protective Domain Name Service (PDNS)", August
2017, <https://www.ncsc.gov.uk/information/pdns>.
[PoP] Bianco, D., "The Pyramid of Pain", March 2013,
<https://detect-respond.blogspot.com/2013/03/the-pyramid-
of-pain.html>.
[RFC7970] Danyliw, R., "The Incident Object Description Exchange
Format Version 2", RFC 7970, DOI 10.17487/RFC7970,
November 2016, <https://www.rfc-editor.org/info/rfc7970>.
[RULER] MITRE, "Ruler",
<https://attack.mitre.org/software/S0358/>.
[STIX] OASIS Cyber Threat Intelligence (CTI), "Introduction to
STIX", <https://oasis-open.github.io/cti-
documentation/stix/intro>.
[Symantec] Symantec, "Elfin: Relentless Espionage Group Targets
Multiple Organizations in Saudi Arabia and U.S.", March
2019, <https://www.symantec.com/blogs/threat-intelligence/
elfin-apt33-espionage>.
[TAXII] OASIS Cyber Threat Intelligence (CTI), "Introduction to
TAXII", <https://oasis-open.github.io/cti-
documentation/taxii/intro.html>.
[Timestomp]
MITRE, "Indicator Removal: Timestomp", January 2020,
<https://attack.mitre.org/techniques/T1099/>.
[TLP] FIRST, "Traffic Light Protocol (TLP)",
<https://www.first.org/tlp/>.
Thanks to all those who have been involved with improving cyber defence in the IETF and IRTF communities.
IETFコミュニティとIRTFコミュニティでのサイバー防衛の改善に関与してくれたすべての人に感謝します。
Kirsty Paine
Splunk Inc.
Email: kirsty.ietf@gmail.com
Ollie Whitehouse
Binary Firefly
Email: ollie@binaryfirefly.com
James Sellwood
Email: james.sellwood.ietf@gmail.com
Andrew Shaw
UK National Cyber Security Centre
Email: andrew.s2@ncsc.gov.uk