🛡️

RFC 9424: 能動的防御におけるセキュリティ侵害指標(IoC)とその役割

2024/06/03に公開

Security

RFC

tech

要旨

サイバー防御担当者は、ネットワークやエンドポイントにおける悪意のある活動を特定、追跡、ブロックするために、セキュリティ侵害指標(IoC)を頻繁に利用している。本文書では、IoCの使用に関する基本、機会、運用上の制限、および推奨事項を点検する。インターネット・プロトコル、ツール、テクノロジーの実装において、IoCを検出できるようにする必要性を強調し ─ IoCの最初の発見と検出における使用の両方で ─ ネットワーク・セキュリティにおける運用上の課題に対するアプローチの基礎を提供する。

⚠️ IoCについて

Indicators of Compromise(IoC)とは(「侵害指標」、「痕跡指標」、「セキュリティ侵害インジケータ」などとも呼ばれる)、情報システムがサイバー攻撃を受けたことや、その範囲を判断するための指標をいい、攻撃者やマルウェアの活動の痕跡や、システムやネットワークが受けた影響を示すデータを集めたものである。簡単に言えば、攻撃の記録と言える。

IoCは主にセキュリティ装置・ソフトウェアによって生成されるが、代表的なデータ形式に、STIX、MISP、OPENIOC、IODEFなどがある(セクション3.2.3参照)。

本文書の位置付け

本文書はインターネット標準化過程の仕様書ではない。情報提供を目的として公開する。

本文書はインターネット・エンジニアリング・タスク・フォース(IETF)の成果物である。IETFコミュニティのコンセンサスを表すものである。文書は公開レビューを受けており、インターネット・エンジニアリング・ステアリング・グループ(IESG)によって公開が承認されている。IESGによって承認されたすべての文書が、あらゆるレベルのインターネット標準の候補となるわけではない。RFC 7841のセクション2を参照のこと。

文書の現在の位置付け、正誤表、フィードバックの提供方法に関する情報は、https://www.rfc-editor.org/info/rfc9424 で入手できる。

著作権表示

本文書は、BCP 78および文書の発行日において有効なIETF文書に関するIETFトラストの法的規定(https://trustee.ietf.org/license-info)に従うものとする。これらの文書には、本文書に関するあなたの権利と制限が記載されているため、注意深く確認して欲しい。文書から抽出されたコード・コンポーネントには、トラスト法的条項のセクション4.eに記載されている改訂BSDライセンスのテキストを含まなければならず、改訂BSDライセンスに記載されているように保証なしで提供する。

1. はじめに

本文書は、さまざまなタイプのIoCと、能動的防御(しばしば「サイバー防御」と呼ばれる)においてIoCがどのように効果的に使用されるかについて説明する。痛みのピラミッド(Pyramid of Pain)[PoP]やIoCライフサイクルといった概念を紹介し、IoCがどのように広範な防御を提供するために使用されるかを強調する。本文書は、IoCに基づく制御の実装者に対する提案と、潜在的な運用上の制限を提供する。現実世界の攻撃を検知し防御するためのIoCの有用性を実証する2つのケーススタディが含まれている。1つは、「APT33」として知られる一連の侵入(1人の脅威アクターによる一連の悪意のある活動や行動)が関係しており、もう1つは、「Cobalt Strike」と呼ばれる攻撃ツールが関するケーススタディである。本文書は、APT33やCobalt Strikeの包括的な報告書ではなく、これらの脅威に関する公開報告書(サイバー・インテリジェンス専門家の間では「オープンソース資料」と呼ばれる) (例えば、[Symantec]や[NCCGroup])を併読することを意図している。

2. 用語

能動的防御(アクティブディフェンス):
サイバー侵入の試みと成功を防止、検出、対応を通じて、環境にサイバー・セキュリティを提供する活動。防御の成功は、ネットワーク、エンドポイント、アプリケーションの各レベルにおける敵対的な活動をブロックし、監視し、対応する必要がある。

⚠️ 能動的防御について

能動的防御(アクティブディフェンス)は元々は軍事用語で(積極的防御、アクティブ・サイバー・デフェンス(能動的サイバー防御)とも言われる)、攻撃を受けるのを待つのではなく、敵の攻撃の兆候を捉え、事前に防いだり、弱めたりする防御をいう。

SANSが公表しているホワイトペーパー『The Sliding Scale of Cyber Security』には、受動的防御、能動的防御、攻撃者への攻撃(オフェンス)の違いが整理されている。セキュリティを考慮したシステム設計を行う「アーキテクチャ」から始まり、外部に存在する攻撃者への攻撃を行う「オフェンス」まで5段階で整理されている。能動的防御はその中間付近に位置する。

sans-cybersecurity

コマンドアンド・コントロール(C2)サーバ:
セキュリティ侵害されたマシンと通信し、コマンドを送信し、データを受信するために使われる、攻撃者が管理するサーバ。C2サーバとセキュリティ侵害されたホスト間の通信は、「コマンド・アンド・コントロール・トラフィック」と呼ばれる。

ドメイン生成アルゴリズム(DGA):
マルウェアの系統で使用されるアルゴリズムで、(アルゴリズムを介して)ドメイン名を定期的に生成する。マルウェアは、C2トラフィックの宛先を計算するために、より簡単にブロックできる静的IPアドレスやドメインの事前割り当てリストに頼るのではなく、マルウェアから抽出するかマルウェアにリンクしてDGAを使用する場合がある。

キルチェーン:
サイバー侵入を、偵察から攻撃者の目的実行までの攻撃のステージを概念的に分解するためのモデル。このモデルにより、防御者は攻撃者の活動[KillChain]の個別のステージを防御するためのコントロールについて考え、議論し、計画し、実装することができる。

戦術、技術、手順 (TTP):
攻撃者がキルチェーンで行動を実行する方法、つまり選択したもの、実行した方法、使用したツールやインフラ、使用したプロトコル、実行したコマンドなどである。それらが十分に明確であれば、攻撃者のTTPの側面は、あたかも指紋のように特定のIoCを形成できる。

コントロール (米国NISTの定義):
情報の機密性、完全性、可用性を保護し、一連の定義されたセキュリティ要件を満たすように設計された情報システムまたは組織に対して規定された防御措置または対策。[NIST]。

3. IoCの基礎

3.1. IoCの種類と痛みのピラミッド

IoCとは、攻撃者の戦術、テクニック、手順、関連するツールやインフラなど、攻撃者またはその活動に関連する観察可能なアーティファクトである。これらの指標は、ネットワークまたはエンドポイント(ホスト)レベルで観察することができ、程度の差こそあれ、ネットワーク防御者が悪意のあるトラフィックやコードの実行を積極的にブロックしたり、サイバー侵入が発生したと判断したり、発見された活動を既知の侵入セットに関連付けたりするのに役立ち、それによって、追加の調査手段を明確化する可能性がある。IoCは、コントロール・ポイントが監視しているトラフィックの中から検索する指標のリストにIoCを追加することで、ファイアウォールや他のセキュリティ・コントロール・ポイントに展開される。悪意のある活動に関連する場合、プロトコル関連のIoCの例を以下に挙げる:

ネットワーク・トラフィック内のIPv4及びIPv6アドレス
ネットワーク・トラフィック、DNSリゾルバ・キャッシュ、またはログに含まれる完全修飾ドメイン名(FQDN)
ネットワーク・トラフィック中のTLSサーバ名表示値
バイナリ内のコード署名証明書
ネットワーク・トラフィック中のTLS証明書情報(SHA256ハッシュなど)
ネットワーク・トラフィックやファイル・システムのアーティファクトから計算された悪意のあるバイナリやスクリプトの暗号化ハッシュ(MD5、SHA1、SHA256など)
攻撃ツール (Mimikatz[Mimikatz]など)とそのコード構造及び実行特性
ネットワーク・トラフィックやシステムのアーティファクトで観測されるKerberos Golden Tickets[GoldenTicket]などの攻撃手法

IoCの一般的なタイプは、予防、検出、緩和戦略に情報を与える痛みのピラミッド[PoP]を形成する。ピラミッドにおける各IoCタイプの位置は、典型的な敵対者がそのアーティファクトを生成する活動を変更する際に経験する「痛み」の程度を表している。敵対者が経験する痛みが大きければ大きいほど(上位に向かうほど)、敵対者はその活動の側面を変更する可能性が低くなり、IoCが攻撃者の侵入セットを反映する可能性が大きくなる(つまり、防御者の視点から見て、それらのIoCの脆弱性が低くなる)。PoPのレイヤは一般的にハッシュからTTPまで多岐に渡り、単にコードを再コンパイルするものから、全く新しい攻撃戦略を作成するものまで、さまざまな痛みを伴う。他のタイプのIoCも存在し、防御側が最も関連性の高い侵入セットを理解し、議論するのに役立つPoPの拡張バージョンに含めることもできる。

fig1
図1 痛みのピラミッド(Pyramid of Pain)

⚠️ 痛みのピラミッド

痛みのピラミッドは、上に行けば行くほど攻撃者にとって痛みが増すことを示した図である。一番下位のハッシュ値は簡単に変更できてしまうため、ハッシュ値が与えるダメージは少ない。TTPは防御者にとって作成は難しいが、きちんと作成して実装できれば、攻撃者に対して大きなダメージを与える。

最も低い(そして最も苦痛の少ない)レベルでは、悪意のあるファイルのハッシュがある。これらは防御者にとって簡単に収集できるため、悪意のあるダウンロードをブロックしたり、コードの実行を阻止するためにファイアウォールやエンドポイント防御に展開することができる。IoCは、防御者がこの種のブロッキングを行う唯一の方法ではないが、迅速かつ便利で、非侵入的な方法である。ハッシュは、バイナリ・コンテンツに基づいて個々のファイルを正確に検出する。しかし、この防御を覆すには、攻撃者はコードを再コンパイルするか、ファイルの内容に些細な変更を加えてハッシュ値を変更するだけで済む。

次の2つのレベルはIPアドレスとドメイン名である。これらとのやり取りは、さまざまな誤検知率(悪意のないトラフィックを悪意のあるトラフィックと誤認する、セクション5を参照)でブロックされる可能性があり、多くの場合、ファイルハッシュよりも攻撃者にとって妨害する手間が大きくなる。攻撃者は、IPレンジを変更し、新しいプロバイダを見つけ、コードを変更しなければならない(例えば、IPアドレスが解決されずに、ハードコーディングされている場合)。似たような状況はドメイン名にも当てはまるが、場合によっては、攻撃者が特定の組織になりすましたり、攻撃対象を納得させたり、誤解させたりするように関連性を偽ったり、主張したりするために、特別にドメイン名を登録していることもある。ドメイン名を新規登録のプロセスやコストは、現在では多くの攻撃者にとって法外なものであったり、注意を逸らすものであったりする可能性は低いが、このような目的のために未登録だが適切なドメイン名を選択することには、若干の痛みが伴う。

ネットワーク上のマルウェアのビーコン・パターンやエンドポイントで変更されたファイルのタイムスタンプなど、ネットワークやエンドポイントのアーティファクトは、行われている攻撃に特化したものであり、場合によっては、攻撃者の直接的な制御下にないこともあるため、変更するのがさらに難しい。しかし、より洗練された攻撃者は、このレベルでの柔軟性を提供するTTPやツール(Cobalt Strikeの順応性のあるコマンドとコントロール[COBALT ]など)、あるいはいくつかのアーティファクトをマスクできる手段([Timestomp]を参照)を使用している。

ツールとTTPはピラミッドの上位2つのレベルを形成している。これらのレベルは、脅威アクターの方法論、つまり攻撃を実行する方法を表す。ツールレベルは、攻撃の実行に使用されるソフトウェア(頻度は低いが、ハードウェア)を具体的に指すのに対し、TTPレベルは攻撃戦略の他のすべての側面を取り上げる。これらのレベルのIoCは、より入り組んで複雑である。例えば、攻撃者がどのように悪意のあるコードを展開し、被害者のネットワークを偵察し、貴重なエンドポイントにピボットし、ランサムウェアのペイロードをダウンロードさせるのか、その詳細を含むことができる。TTPとツールは、防御側の診断に多大な労力を要するが、攻撃者とキャンペーンにとって基本的なものであるため、敵対者にとって変更するのはとてつもなく骨が折れる。

IoCの発見可能性のばらつきは、オープンな脅威インテリジェンス・コミュニティ[ALIENVAULT]であるAlienVaultのIoCの数によって示されている。2023年1月の時点で、AlienVaultには以下のものが含まれている:

グループ (TTPの組み合わせ): 631
マルウェア・ファミリ (ツールなど): 〜27,000
URL: 2,854,918
ドメイン名: 64,769,363
IPv4アドレス: 5,427,762
IPv6アドレス: 12,009
SHA256ハッシュ値: 5,452,442

ドメイン名の数は、他の数と同期していないように見えるが、PoPが上がるにつれて減少する。この食い違いはさらなる調査が必要である。しかし、その一因は、DGAの使用と、脅威アクターが正規の組織を装うためにドメイン名を使用し、特定され没収されるにつれて新しいドメイン名を作成するインセンティブが増すという事実が考えられる。

3.2. IoCライフサイクル

防御者にとってIoCが有用であるためには、まず検出され、評価され、共有され、展開されなければならない。ログに記録された活動が特定され、IoCと関連付けられると、この検出は防御者による反応を引き起こすが、これには調査が含まれる可能性があり、より多くのIoCが発見され、評価され、共有され、展開される可能性がある。このサイクルは、IoCがもはや関連性がなくなったと判断されるまで続き、その時点でコントロール・スペースから削除される。

3.2.1. 検出

IoCは最初、手動調査または自動分析によって発見される。IoCは、エンドポイントやネットワーク(回線上)を含む、さまざまなソースから検出できる。IoCは、プロトコルのパケット・キャプチャ、コード実行、システムの活動(ハッシュ、IPアドレス、ドメイン名、ネットワークやエンドポイントのアーティファクトの場合)を監視するログから抽出されるか、攻撃活動やツールの分析によって確定されなければならない。場合によっては、検出は事後的なプロセスとなる場合があり、過去または現在の攻撃のIoCが残された痕跡から特定される。しかし、検出とは、過去のイベントの知識から推定される将来の潜在的なIoCを積極的に探索することから生じることもある(例えば、ドメイン名の登録パターンを監視して、攻撃者のインフラの特定することなど)。

重要なことは、IoCを検出するためには、その指標が関連付けられているインターネット・プロトコル、ツール、テクノロジーから抽出可能でなければならないということである。指標を抽出できない、あるいは抽出できても、同じプロトコルまたは異なるプロトコルで、後に関連するメッセージまたはアーティファクトの交換に関連付けることができない場合、攻撃に関連する特定の交換(または交換されたメッセージのシーケンス)を識別することのメリットは限定的である。悪意のある攻撃トラフィックの送信元または送信先を特定できなければ、後続の攻撃トラフィックを特定してブロックすることはできない。

3.2.2. 評価

防御者は、IoCの品質と防御者のニーズと能力に応じて、異なるIoCを異なるように扱うかもしれない。例えば、防御者は、情報源、鮮度、信頼度、または関連する脅威によって、IoCに異なる信頼を置くかもしれない。これらの決定は、IoCが検出された時点で回復された、あるいはIoCの共有時に提供された、関連するコンテキスト情報に依存する。

コンテキストのないIoCは、ネットワーク防御にはあまり役に立たない。一方、コンテキスト(例えば、それが関連する脅威アクター、攻撃における役割、それが使用されているのが最後に確認された時刻、予想される使用期限、他の関連するIoC)と共に配信されたIoCは、ネットワーク防御者がネットワークを防御するためにそれをどのように使用する(例えば、単にログに記録する、積極的に監視する、または完全にブロックする)かについて情報に基づいた選択をすることを可能にする。

3.2.3. 共有

一旦検出され、評価されると、IoCは脅威の検出や阻止に広範な影響を与えるような方法で展開したり、多くの個人や組織が自己防衛できるような規模で共有するときに最も役立つ。IoCは、非構造化の方法で(適切なコンテキストを使用して)個別に共有されることもあれば、脅威情報構造化記述形式[STIX]、マルウェア情報共有プラットフォーム(MISP)コア[MISPCORE]、OpenIOC [OPENIOC]、インシデント・オブジェクト記述交換形式(IODEF)[RFC7970]などの標準化されたフォーマットで他の多くのIoCと一緒にパッケージ化することもできる。これにより、Trusted Automated eXchange of Intelligence Information (インテリジェンス情報の信頼できる自動交換) [TAXII]のような構造化されたフィードを実装したものや、Malware Information Sharing Platform (マルウェア情報共有プラットフォーム) [MISP]を介した配信が可能になる。

⚠️ STIXとTAXIIの参考資料

情報処理推進機構より(2018年)。

一部のセキュリティ企業や会員制のグループ(「情報共有分析センター(ISAC)」や「情報共有分析組織(ISAO)」と呼ばれる)が、IoCを含む有料のインテリジェンス・フィードを提供している一方で、個人のセキュリティ研究者から小規模な信頼グループを経て、政府のサイバーセキュリティ組織や国際的なコンピュータ緊急対応チーム(CERT)まで、さまざまな無料のIoCソースが利用可能である。彼らが誰であろうと、共有者は一般的に、Traffic Light Protocol [TLP]のようなフレームワークを使用して、受信者がさらにIoCを配布できる範囲を示す。最も単純に言えば、これは、受信者が誰とでも共有できること(TLP:CLEAR)、定義された共有コミュニティ内で共有できること(TLP:GREEN)、自分の組織とそのクライアント内で共有できること (TLP:AMBER+STRICT)、自分の組織内だけで共有できること(TLP:AMBER)、元の特定のIoC交換以外の誰とも共有できないこと(TLP:RED)を示す。

3.2.4. 展開

IoCが多層防御(セクション6を参照)を提供し、さまざまな障害点に対処するには、的確な展開が重要である。さまざまなIoCは、ネットワーク・スタックのさまざまなレイヤと攻撃のさまざまなステージで悪意のある活動を検出するため、さまざまなIoCを展開すると、各セキュリティ・コントロールで防御のレイヤを形成することが可能になり、複数のセキュリティ・コントロールを多層防御ソリューションの一部としてを使用するメリットが強化される。ネットワーク・セキュリティ・コントロールとエンドポイント・ソリューションは、IoCを検出して対処するために十分な権限と十分な可視性を持つ必要がある。IoCが存在するところであればどこでも、迅速かつ広範囲に展開できるように、セキュリティ・コントロールと関連装置がIoCを利用できるようにする必要がある。IoCは、発見後または受信後に手動で評価することもできるが、ログまたはインテリジェンス・フィードからIoCを自動的に取り込み、処理し、評価し、適切なセキュリティ・コントロールに展開することで、大きなメリットが得られるかもしれない。すべてのIoCが同じ品質であるわけではないため、この方法でIoCを自動的に展開するかどうかを決定する場合は、各脅威インテリジェンス・フィードから引き出されたIoCの信頼性を考慮する必要がある。

IoCは、最も広範な影響を及ぼすセキュリティ・コントロールに展開した場合、悪意のある活動を軽減するのに特に効果的である。これは、セキュリティ製品やファイアウォールの開発者が、IoCの配布と消費のサポートを製品に直接追加することによって実現できる。各ユーザが行う必要はない。これにより、機械的に拡張可能で、自動化された方法で、ユーザベース全体の脅威に一度に対処することができる。これは、広い範囲の穴(aperture)をカバーするコントロール・ポイント(例えば、企業全体のDNSリゾルバ)がIoCフィードに基づいて自動的に動作できるようにすることで、企業内でも実現できる。

3.2.5. 検出

展開されたIoCを持つセキュリティ・コントロールは、関連するコントロール・スペースを監視し、監視対象のログやネットワーク。インタフェース上でIoCが検出されると、一般的または特定の反応を引き起こす。

3.2.6. 反応

IoCの検出に対する反応は、それが展開されているコントロールの機能と構成、IoCの評価、検出されたログ・ソースの特性などの要因によって異なる場合がある。例えば、既知のボットネットC2サーバへの接続は問題を示すかもしれないが、特にそのサーバがまだ他の正当な機能を実行している侵害されたホストであれば、それを保証するものではない。一般的な反応としては、イベントのロギング、アラートのトリガー、活動源のブロックまたは停止などがある。

3.2.7. 使用期限

IoCがいつまで役に立つかはさまざまであり、IoCの初期信頼度、壊れやすさ、精度などの要因に左右される(セクション5でさらに論じる)。場合によっては、IoCはその初期特性に基づいて自動的に「エージング」され、あらかじめ決められた時期に使用期限を迎える。他のケースでは、IoCは脅威アクターのTTPの変化(例えば、新しい開発やその発見の結果)や、防御者による修復措置のために無効化されるかもしれない。また、サポート終了は、攻撃者が使用するサードパーティのサービスが変更されたり、オフラインになったりした場合など、攻撃や防御に関係のない活動によって終了することもある。原因が何であれ、IoCは誤検知の可能性を減らすために、寿命が来たら検出から外す必要がある。

4. IoCの効果的な使用

4.1. 機会

IoCは、最新の多層防御戦略の一環として、サイバー防御者にさまざまな機会を提供する。組織の規模に関係なく、IoCは、最新の脅威や過去に発生した可能性のある特定の侵入からの攻撃クラスに対して、効果的でスケーラブルかつ効率的な防御メカニズムを提供することができる。

4.1.1. IoCは、最新の多層防御戦略の複数層を支え、実現する

ファイアウォール、侵入検知システム(IDS)、侵入防御システム(IPS)はすべて、ネットワーク全体の脅威を特定して軽減するため、IoCを採用している。アンチウイルス(AV)及びエンドポイント検出と応答(EDR)製品は、カタログまたはライブラリを介して、サポートされているクライアント・エンドポイントにIoCを展開する。セキュリティ・インシデント・イベント管理(SIEM)プラットフォームは、ネットワーク、エンドポイント、アプリケーションなどのさまざまなソースから集約されたログとIoCを比較する。もちろん、IoCはすべての能動的防御の課題に対処するわけではないが、あらゆる組織の多層防御の重要なレイヤを形成する。IoCのタイプによっては、すべてのコントロールに存在するものもあれば、多層防御ソリューションの特定のレイヤにのみ展開されるものもある。さらに、特定のキルチェーンに関連するIoCは、特定のフェーズの間に実行された活動のみを反映する場合があるため、侵入の一部としてキルチェーンを完全にカバーするためには、他のIoCやメカニズムと組み合わせる必要がある。

一例として、オープンソースのマルウェアは多くのさまざまなアクターによって展開される可能性があり、それぞれが独自のTTPとインフラを使用している。しかし、アクターが同じ実行ファイルを使用する場合、実行ファイルのハッシュ値は同じままであり、このハッシュをエンドポイント防御のIoCとして展開することで、個々のアクター、インフラ、その他のTTPに関係なく実行をブロックすることができる。この防御が特定のケースで失敗した場合、例えば、アクターが実行ファイルのバイナリを再コンパイルして一意のハッシュ値を生成した場合、他の防御によって、例として既知の悪意のあるドメイン名の検索をブロックして、マルウェアがC2インフラへの出動を阻むなどして、攻撃のさらなる進行を阻止することができる。

代わりに、別の悪意のあるアクターは、さまざまなキャンペーンに展開されているツールやインフラ(したがって、侵入に関連する指標)を定期的に変更するかもしれないが、アクセス・ベクトルは一貫してよく知られたままかもしれない。この場合、意図されたその後の活動が不確実であっても、このアクセスTTPを認識し、積極的に防御することができる。例えば、アクセス・ベクトルが一貫してソフトウェアの脆弱性を悪用している場合、定期的かつ資産全体にパッチを適用することで、攻撃を未然に防ぐことができる。しかし、このような先制的対策が失敗した場合、複数のキャンペーンで観測された他のIoCが、キルチェーンの後のステージで攻撃を防ぐことができるかもしれない。

4.1.2. IoCは限られたリソースでも使用できる

IoCは安価で、拡張性があり、展開が容易であるため、特に重大な脅威にさらされている小規模な企業にとって、その利用は特に有益である。例えば、重要で高度に専門化されたコンポーネントを生産するサプライチェーン内の小規模な製造下請け業者は、セキュリティ侵害を受けた場合、サプライチェーンと元請け業者の両方に不均衡な影響があるため、魅力的なターゲットとなる可能性がある。このような小規模メーカーは、(社内か外部委託かに関係なく)基本的なセキュリティしか持っていないと考えるのが妥当かもしれない。また、大手パートナーと比較して、直面するリスクを管理するためのリソースが比較的少ないと考えられるが、依然としてIoCを活用して、大きな効果を上げることはできる。このような小規模な企業であれば、リソースが豊富で成熟した防御チームや、リソースを大量に消費する調査を行うために必要な脅威インテリジェンス関係へのアクセスがなくても、IoCを展開して既知の脅威に対するベースラインの防御を行うことができる。IoCの展開を成功させるためには、このような小規模な企業でもある程度の専門知識が必要になるが、IoCの使用には、機械学習を使用するような、より主観的なコントロールに必要な集中的なトレーニングは必要ない。特定されたイベントが本当に悪意のあるものであるかどうかを検証するために、さらなる手動による分析が必要となる。このように、IoCの魅力の大部分は、リソースの能力、成熟度、洗練度のスペクトルを超えて、組織にある程度の防御を提供できることである。

4.1.3. IoCは、組織内の能動的防御の取り組みに相乗効果をもたらす

個々のIoCは、組織やエコシステム全体の防御者に効果的に拡張する広範な防御を提供することができる。1つの組織内では、1つのIoCをブロックするだけで、何千人ものユーザを保護することができ、そのブロックは、ネットワーク、エンドポイント、アプリケーション内のさまざまな種類の活動を監視している複数のセキュリティ・コントロール全体にわたって(IoCの種類によっては)実行されるかもしれない。先ほどの例の元請け業者は、小規模な下請け業者にIoCを提供することで、自社とその利益を守ると同時に、その小規模な企業の防御能力をさらに向上させることができる。

複数の組織は、共有されたIoCを直接受け取ることでメリットを得るかもしれない(セクション4.1.4を参照)が、彼らが利用するサービスにIoCが適用されることでもメリットを得るかもしれない。進行中の電子メール・フィッシング・キャンペーンの場合、IoCは個々の組織が迅速かつ容易に監視、発見、展開することができる。しかし、防御DNSフィルタリング・サービスのようなメカニズムによって、IoCが迅速に展開されれば、さらに効果的である。ある組織の受信者がリンクをクリックする前に、あるいは悪意のあるペイロードが指示を呼び掛ける前に、メール・キャンペーンを緩和することができる。このようなアプローチにより、他の組織とIoCを直接共有したり、追加の労力をかけることなく、努力をしたりすることなく他の関係者を保護することができる。

4.1.4. IoCは組織間で簡単に共有できる

IoCはまた、個人や組織間で非常に簡単に共有することができる。まず、IoCはテキスト(おそらく16進数)として簡潔に表現できるため、配布が容易であり、電子メール、ブログ投稿、または技術レポートにおいて、少数の情報が頻繁に交換される。第2に、セクション3.2.3で言及されているような標準は、IoCの大規模なコレクションや定期的なセットを、関連するすべてのコンテキストと共に共有するための、明確に定義されたフォーマットを提供するために存在する。1つの IoCを検出するのは集中的な作業になるかもしれないが、一旦確立されたルートを通じて共有されれば、その個々のIoCは何千もの組織、ひいてはそれらの組織内のすべてのユーザを保護することができる。IoCを迅速かつ簡単に共有することで、組織を包括的にカバーし、タイムリーに広範な緩和策が可能になる ─ IoCは、小規模な組織から大規模な組織、または大規模なチームから個人まで、システム管理者と共有できるため、全員がネットワーク上で防御を実装することができる。

4.1.5. IoCは大幅な時間の節約をもたらす

IoCを共有することで時間を節約し、調査作業の重複を省くだけでなく、多くの企業にとっては、IoCを大規模に自動展開することは継ぎ目なく行うことができる。IoCの自動展開がうまくいっている場合、組織とユーザは能動的防御の重要な目標である最小限の人的介入と最小限の労力で、包括的な防御を得ることができる。これを大規模かつ一定のペースで実行する能力は、侵入セットを頻繁に変更し、関連するIoCを変更する可能性のある俊敏な脅威アクターに対応する場合に非常に重要である。逆に、IoCを自動展開せず、複雑なネットワークを防御することは、すべてのエンドポイントやネットワーク・デバイスを一貫して確実に同じセキュリティ状態に手作業で更新する必要があることを意味する。これに伴う作業(資産やデバイスの場所を特定したり、ログやシステム情報のポーリングしたり、手作業でパッチ・レベルを確認するなど)は複雑になり、熟練したアナリストやエンジニアが必要になる。効率的なIoCの展開を可能にし、IoCを広範囲に展開する際に誤検知を排除するためには依然として労力を投資する必要はあるが、そのコストと労力は、すべてのエンドポイントとネットワーク・デバイスを手作業で確実に更新する作業に比べればはるかに小さい。例えば、レガシー・システムは特に複雑で、更新が不可能な場合もある。

4.1.6. IoCは過去の攻撃を発見できる

ネットワーク防御者は、ログに記録されたDNSクエリや電子メールの添付ファイルのハッシュなどの履歴データと組み合わせて、最近取得したIoCを使用して、過去のセキュリティ侵害の兆候を探すことができる。この技術は、過去の攻撃を明確に把握するのに役立つだけでなく、過去の侵入の影響を遡って軽減することもできる。この機会は、Timestomp[Timestomp]のような手法によって、履歴データ自体がセキュリティ侵害されていないこと、データ保持ポリシーのために不完全でないことに依存するが、それでも、過去の攻撃を検出し、修復するためには貴重な情報である。

4.1.7. IoCは特定の脅威に起因する可能性がある

ファイアウォール・フィルタリングやEDRのようなさまざまな最新のセキュリティ対策を展開する場合、防御の範囲と、誤検知のリスク(セクション5.2を参照)、スタッフの時間、純粋な財務費用などのさまざまなコストとの間に、本質的なトレードオフが生じる。組織は、脅威モデリングと情報保証を使用して、特定された脅威によるリスクを評価し、優先順位を付け、それぞれの脅威をどのように軽減するか、または受け入れるかを決定する。IoCを特定の脅威やアクターと結び付け、IoCとともに共有されるコンテキスト情報によって、組織は特定のリスクに対する防御に重点を置くこともできる。このようなコンテキスト情報は、一般に、IoCを受け取る側に、リスク選好度、セキュリティ体制、防御方法を選択する技術的自由と能力を与えるため、期待されている。セクション3.2.3で概要を説明したフォーマットによるところもあるが、IoCと一緒にこのコンテキスト情報を共有することが容易なため、キャンペーンやターゲットにまたがって悪意のあるアクターを追跡することが容易になる。IoCを共有する前にこのコンテキスト情報を作成するには、専門的なツールやトレーニングだけでなく、集中的な分析作業が必要になることがある。最も単純な方法は、例えば、同じソースから同じC2サーバに接続する複数の一意のペイロード(したがって、異なるファイルハッシュを持つ)からの同じ攻撃行動の複数の実例からIoCセットを文書化することである。より複雑なアプローチとしては、一定期間にわたり複数のキャンペーンで見られたTTPの類似した組み合わせをクラスタ化する方法がある。これは、詳細なマルウェアのリバース・エンジニアリングやターゲットのプロファイリングと並行して、地政学的・犯罪的背景に重ね合わせることで、単一の脅威アクターに帰属することを推測するために使用できる。

4.2. ケーススタディ

以下の2つのケーススタディは、脅威アクターのツール(1つ目)と脅威アクターの行動(2つ目)に関連して、IoCがどのように特定されるかを示している。ケーススタディではさらに、これらのIoCがサイバー防御者によってどのように利用されるかを強調している。

4.2.1. Cobalt Strike

Cobalt Strike[COBALT]は、侵入テストに使用される商用攻撃フレームワークで、インプラント・フレームワーク(ビーコン)、ネットワーク・プロトコル、C2サーバで構成される。ビーコンとネットワーク・プロトコルは非常に可鍛性に富んでおり、トラフィックがHTTPなどのプロトコル仕様に確実に準拠していることを確認することで、攻撃者が「ネットワーク上の」プロトコル表現を容易に変更して、正規のトラフィックに紛れ込ませることができる。独自のビーコンは、公開鍵と秘密鍵のペアに基づくカスタム暗号化スキームでオーバーレイされたTLS暗号をサポートする。この製品は、ドメイン名やIPアドレスの静的ネットワーク署名による明らかな受動的検出を回避する試みとして、ドメイン・フロンティング[DFRONT]などの他の技術もサポートしている。ドメイン・フロンティングは、悪意のあるドメインへのトラフィックと、既にHTTPS経由で定期的に悪意のないドメインと通信しているネットワークから発信されるトラフィックを混在させるために使用される。

4.2.1.1. 全体のTTP

ビーコン設定は、インプラントがどのように動作し、C2サーバと通信すべきかを記述する。この設定は、Cobalt Strikeユーザ・ライセンスのウォーターマークなどの補助情報も提供する。

4.2.1.2. IoC

特定のリクエストに対する応答に基づいて、C2サーバのフィンガープリントを取得できるようにTradecraftが開発された。これにより、サーバを識別し、ビーコン設定をダウンロードし、関連するインフラ・アドレスをIoCとして抽出することができる。

Cobalt Strikeの結果として得られる大量IoCは以下の通りである:

C2サーバのIPアドレス
使用ドメイン名

これらのIoCは(容易に変更できるため)定期的に更新する必要があるが、筆者らの公的機関の防御経験から、これらのIoCはCobalt Strikeを使用する脅威アクターの活動を妨害するのに有効であることが分かっている。

これらのIoCを使用して、過去のセキュリティ侵害の証拠となる履歴データをチェックするために使用することができ、将来の感染をタイムリーに検出またはブロックするために展開することができる。これにより、ユーザデータやシステムデータの損失防止に役立つ。

4.2.2. APT33

最初のケーススタディとは対照的に、このケーススタディでは、ElfinやRefined Kittenとしても知られる脅威アクターAPT33による現在の活動について説明する([Symantec]を参照)。APT33は、業界では国家の支援を受けたグループであると評価されている[FireEye2]。しかし、このケーススタディでは、IoCは依然として、このような強力な敵対者に対して効果的なツールを防御者に提供している。このグループは少なくとも2015年から活動しており、石油化学、政府、エンジニアリング、製造業など、幅広いさまざまなセクターを標的としていることが知られている。活動は世界各国で確認されているが、主に米国とサウジアラビアで見られる。

4.2.2.1. TTP全体

このアクターが使用するテクニックは、国家の支援を受けたグループであることを考えると、比較的低レベルの洗練度を示している。通常、APT33は、正規の出版物を模倣した文書ルアーを使って、スピア・フィッシング(事前に選択した限られた受信者に標的型の悪意のある電子メールを送信)を行う。これらのルアーにユーザが接触することで、初期ペイロードが実行され、APT33は初期アクセスを獲得できるようになる。標的のネットワーク内に入ると、APT33は他のマシンにピポットして文書を収集し、管理者の資格情報へのアクセスを試みる。場合によっては、ユーザを騙して資格情報を提供させ、電子メール・クライアントを悪用できるフリーで利用可能なツールであるRuler[RULER]を使用させる。攻撃者は、標的のパスワードを入手した上で、Rulerを使用して標的のメール・アカウントにアクセスし、メール・クライアントを開いたときにトリガーされる悪意のあるスクリプトを埋め込む。その結果、悪意のあるコード(多くの場合、インターネットから取得した追加のマルウェア)が実行される。([FireEye]を参照)。

APT33は、可能な限り多くのPCのハードドライブのマスターブートレコード(MBR)を上書きする破壊的なツールを展開することがある。ワイパーとして知られるこのタイプのツールを使用すると、データが失われ、オペレーティング・システムが再インストールされるまでデバイスが使用できなくなる。場合によっては、アクターは管理者の資格情報を使用して、企業のIT資産の大部分で一度に発動する。これが不可能な場合、アクターはまず手動でワイパーの拡散を試みたり、ネットワークに接続されたコンピュータ上のパッチが適用されていない脆弱性に対して、ワームのような機能を使用しようとする。

4.2.2.2. IoC

業界とイギリスの国家サイバー・セキュリティ・センター(NCSC)のパートナーシップによる調査の結果、IoCセットがまとめられ、ネットワーク防御者がネットワーク内でIoCを検索できるように、公共部門と民間部門の両方の組織で共有された。これらのIoCの検出は、APT33が標的としている可能性が高く、潜在的なセキュリティ侵害とその後の破壊的マルウェアの使用を示す可能性がある。ネットワーク防御者は、将来の攻撃を阻止するために、これらのIoCをブロックするプロセスを開始することもできる。このIoCセットは以下のように構成されている:

9件のハッシュと電子メールの件名
5つのIPアドレス
7つのドメイン名

2021年11月、連邦捜査局(FBI)、サイバーセキュリティ・インフラストラクチャ・セキュリティ庁(CISA)、オーストラリア・サイバー・セキュリティ・センター(ACSC)、NCSCによって、APT33[CISA]に関する共同勧告が発表された。これは、APT33による最近の脆弱性の悪用の概説し、観察されたTTPの徹底的な概要を提供し、さらなるIoCを共有するものである:

悪意のある実行ファイルの8つのハッシュ
3つのIPアドレス

⚠️ AA21-321A.stix

APT33のIoC(STIX形式)

https://www.cisa.gov/sites/default/files/publications/AA21-321A.stix.xml

5. 運用上の制限

さまざまなIoCのタイプは、防御者にとって、誤検知(悪意のないトラフィックを悪意があると誤認すること)のリスクと攻撃を特定できないリスクとの間のトレードオフを本質的に内包している。セクション3.1でPoPを用いて説明したように、既知のIoCを破壊するために攻撃を修正する攻撃者の相対的な痛みは、IoCの脆さやIoCが攻撃を識別する精度と逆相関する。痛み、脆さ、精度の間のトレードオフの正確な性質を解明するには調査が必要である。

5.1. 時間と労力

5.1.1. 脆さ

セクション3.1で言及したように、PoPは攻撃側の痛みだけでなく、防御側の脆さという観点からも考えることができる。攻撃者にとってIoCを変更することが苦痛でなければないほど、そのIoCは防御ツールとして脆いということになる。フィッシング・キャンペーンのおとりとして観察されるさまざまな悪意のある添付ファイルのハッシュ値を特定し、AVやメール・ゲートウェイのセキュリティ・コントロールを通じてこれらを展開することは比較的簡単である。しかし、これらのハッシュ値は脆く、活動の間で変更される可能性がある(しばしば変更される)。悪意のあるIPアドレスやドメイン名は、活動の間で変更されることもあるが、ファイルを変更するのに比べ、インフラを管理する手間が大きいため、このようなことはあまり起こらないかもしれない。そのため、IPアドレスとドメイン名は、それほど脆弱な検出能力を提供しないかもしれない。

これは、より脆いIoCタイプが価値がないという意味ではない。まず、脆いIoCが変更されるという保証はなく、もし既知のIoCが攻撃者によって変更されず、ブロックされなかったとしたら、防御側は攻撃を阻止する機会を逃したことになる。第2に、1つのIoCタイプであっても、IoCのコンテキストによって脆弱性にばらつきがある。フィッシング・ルアー文書(特定のテーマを持ち、特定のステージング・サーバ・リンクを含む)のファイル・ハッシュは、攻撃者が最初のアクセス後に使用するリモート・アクセスのトロイの木馬のペイロードのファイル・ハッシュよりも脆弱かもしれない。そしてこれは、攻撃者のインフラに直接接続しない、攻撃者が管理する侵入後の偵察ツールのファイルハッシュよりも脆弱かもしれない。第三に、ある脅威や攻撃者は、他の脅威や攻撃者よりも変化する能力が高かったり、変化する傾向が強かったりするため、ある脅威や攻撃者のIoCの脆さは、他の攻撃者に対する同じタイプのIoCとは大きく異なる可能性がある。

最終的に、脆さは各IoCの継続的な有効性に影響を与える防御側の懸念事項であり、サポート終了に関する決定にも影響する。しかし、展開のためにIoCの取捨選択を要求するような著しく厳しいリソース制約がない限り、個々のIoCの採用を妨げるものではない。より一般的には、脅威を調査している防御者は、利用可能な調査努力(セクション5.1.2を参照)を考慮し、精度を維持しながら(セクション5.2を参照)、継続的な検出の可能性を最大限に高めるために、特定のキルチェーンに対してさまざまな脆弱性を持つIoCを特定しようとする。

5.1.2. 発見可能性

能動的防御に使用するためには、まずプロアクティブなハンティングやリアクティブな調査を通じてIoCを発見しなければならない。セクション3.1で述べたように、PoPのツールとTTPレベルのIoCを発見するには、集中的な努力と調査が必要である。しかし、発見可能性に影響を与えるのはIoCのタイプだけではない。IoCが攻撃後にログから取得されたものなのか、それとも以前にサンプルや感染したシステムから抽出されたものなのかも同様で、アクター、そのTTP、そしてそのツールの洗練度が重要な役割を果たす。

例えば、感染したエンドポイント上で、悪意のあるペイロードを特定し、ファイルハッシュやC2サーバ・アドレスなどの関連するIoCを抽出できる可能性がある。攻撃者が攻撃全体を通して同じ静的ペイロードを使用した場合、この単一のファイルハッシュ値はすべてのインスタンスをカバーする。しかし、攻撃者がペイロードを多様化した場合、そのハッシュはより脆弱になる可能性があり、感染した他のエンドポイントで使用された他のサンプルから他のハッシュを検出する必要があるかもしれない。同時に、攻撃者は単純にペイロードに設定データをハードコードしている可能性もあり、その場合、C2サーバのアドレスは簡単に回復できる。あるいは、ペイロード内(例えば、ソースコードや関連リソース内)または感染したエンドポイントのファイルシステム (例えば、代替データストリーム[ADS]を使用)の難読化された永続的な設定に格納されている可能性もあり、その場合は発見するのに多くの労力を要する。さらに、攻撃者は設定をメモリ内にのみ保存しているか、DGAに依存してオンデマンドでC2サーバ・アドレスを生成している可能性もある。この場合、C2サーバ・アドレスの抽出するには、メモリ・ダンプ、DGAの実行またはリバース・エンジニアリングが必要になる可能性があり、これらすべての労力がさらに増加する。

悪意のあるペイロードがすでにC2サーバと通信している場合、ネットワーク・トラフィック・ログからC2サーバのアドレスIoCをより容易に発見できる可能性がある。しかし、悪意のあるトラフィックにHTTPSが採用されるようになっているため、C2の通信が正規のトラフィックに紛れ込んでしまい、特定が複雑になるなど、複数の要因によって発見が困難になる可能性がある。さらに、一部のマルウェアは、代替のDNS解決サービス(OpenNIC[OPENNIC]など)を使用したり、DNS-over-HTTPS[OILRIG]などの暗号化されたDNSプロトコルを使用したり、DNS応答に符号化された実際のC2サーバ・アドレスを特定するために解決されたIPアドレスに対して変換処理を実行したりすることで、意図した宛先を難読化指定る[LAZARUS]。

5.1.3. 完全性

多くの場合、活動の結果として得られる指標のリストやマルウェア・サンプルで発見された指標は比較的短いため、限定的かつ有限な方法ですべての指標の合計セットに追加されるだけである。この明確な例は、C2サーバの静的指標がマルウェア株で発見された場合である。インシデントやサンプルが1つ増えたからといって、そのような指標が追加されても、共有、展開、検出に大きな影響を受けない。しかし、DGAが検出された場合は、アルゴリズムを再実装し、可能性のあるドメインのリストを生成するために実行する必要がある。アルゴリズムによっては、この結果、指標のリストが非常に大きくなり、特に検出時の性能劣化を引き起こす可能性がある。場合によっては、このような指標のソースは、可能な指標値の合理的な範囲の取得と、可能なすべての指標の値のリストの理論的な完全性を得ることの間で、実用的な決定を下すことにつながる。

5.2. 精度

5.2.1. 特異性

PoPのレベルは、痛みや脆さと並んで、防御が正確さの観点からも考えることができる。通常、ピラミッドの上位に行くほど、特定性の低いIoCになるほど誤検知率は高くなる。ハッシュ値は実行バイナリのような特定のファイルを識別するもので、適切な暗号ハッシュ関数があれば、誤検知はは事実上ゼロになる(「適切」とは、プリイメージ耐性と強い衝突耐性を持つものを意味する)。それに比べ、上位レベルのIoC(ネットワーク・アーティファクトやツールのフィンガープリントなど)は、さまざまな悪意のあるバイナリに適用される可能性があり、良性のソフトウェアであっても同じ識別特性を共有する可能性がある。例えば、ウェブのリクエストを行う脅威アクター・ツールは、リクエスト・ヘッダで指定されたユーザ・エージェント文字列によって識別される場合がある。しかし、この値は、攻撃者の選択または共通ライブラリの使用によって、正規のソフトウェアが使用するものと同じである可能性がある。

IoCが具体的であればあるほど、より脆くなるのは当然のことである。物事が変化すると、その特定の焦点から外れてしまう。脆さが低いIoCは、その堅牢性と長い寿命のために望ましいかもしれないが、その広範さによる誤検知の可能性の増大とバランスを取らなければならない。このバランスを達成する1つの方法は、指標をグループ化し、それらを組み合わせて使用することである。特定の攻撃に対する特異性の低い2つのIoCは、それぞれ誤検知の可能性があるが、一緒に観察すると、関連するキルチェーンの正確な検出の信頼性が高まるかもしれない。

5.2.2. 二重使用と不正使用

セクション3.2.2で述べたように、攻撃者がIoCを使用する方法などのIoCのコンテキストは、IoCが攻撃を検出する精度に同じように影響を与える可能性がある。攻撃者のステージング・サーバを表すIPアドレスは、攻撃者の攻撃チェーンが後続のペイロードをダウンロードするものであり、攻撃者が所有するインフラの正確なIPアドレスを提供する。しかし、そのIPアドレスがクラウド・ホスティング・プロバイダに関連付けられており、あるユーザから別のユーザに定期的に再割り当てされている場合、その精度は低くなる。また、攻撃者が正規のウェブサーバをセキュリティ侵害し、進行中の正当な使用と並行してIPアドレスを悪用している場合、その精度はさらに低くなる。

同様に、攻撃者のカスタム・リモート・アクセスのトロイの木馬を表すファイル・ハッシュは非常に正確だが、一般的な企業のリモート管理ツールを表すファイル・ハッシュは、防御組織が通常そのツールを正規のシステム管理に使用しているかどうかによって、精度が低くなる。注目すべきは、このような二重使用の指標は、それらが通常合法的に使用されているかどうかと、特定の状況でどのように使用されているかの両方を考慮した、コンテキスト固有のものである。リモート管理ツールの使用は、サポートスタッフにとっては勤務時間内であれば合法的な使用かもしれないが、サポートスタッフ以外、特にその従業員の通常の勤務時間外に観察された場合は、一般的には合法ではない。

このような理由から、IoCを共有して使用する際には、コンテキストが非常に重要である。

5.2.3. 用途の変更

IP アドレスの場合、クラウドサービス、プロキシ、仮想プライベート・ネットワーク(VPN)、キャリアグレードのネットワーク・アドレス変換(NAT)の採用が増加するにつれ、同時に1つのIPアドレスに関連付けられるシステムの数が増えている。IPアドレスの使用に対するこの継続的な変化は、(少なくとも特定のサブネットまたは個々のアドレスに対する)IPアドレスの特異性をいくらか低下させている一方で、IPアドレスを変更する必要がある場合、脅威アクターが被るであろう痛みを「回避」(side-stepping)している。

5.3. プライバシー

セクション3.2.2で述べたように、IoCを使った効果的な検出にはコンテキストが重要である。しかし、時には防御者は、サイバー侵入についてどこまで、誰と共有するかについて、プライバシー上の懸念があると感じるかもしれない。例えば、防御者は、共有を容易にするためにコンテキストを削除することで、攻撃のIoCによる説明を一般化するかもしれない。このような一般化は、不完全なIoCセットが共有されたり、IoCが何を表し、どのように攻撃に関与しているかを明確に示されないまま共有されたりすることになる。共有者は、IoCを一般化する際に、プライバシーのトレードオフを考慮し、コンテキストの喪失が共有する人々にとってのIoCの有用性が大幅に低下させる可能性があることに留意する必要がある。

著者らの経験では、IoCを共有するメンバーの数が多いグループ、メンバーの専門知識の認識範囲が広いグループ(特に、下限が共有者の認識する専門知識よりも下であればあるほど、その傾向は強くなる)、メンバー間の信頼関係が強く維持されていないグループにおいて、共有者による自己検閲はより蔓延し、より多く見られるようだ。このようなグループ内の信頼は、メンバーが定期的に交流し、共通の背景や専門知識、課題を持ち、期待される行動に合致し(例えば、定義された処理要件に従うこと、共有する資料について虚偽の説明をしないことなど)、分かち合いや支援を受けることで互恵的である場合に、最も強く現れる。[LITREVIEW]は、これらの要因の多くがサイバー脅威インテリジェンス(CTI)の共有における人間の役割と関連していることを強調している。

5.4. オートメーション

セクション4.1.2で説明したように、IoCはさまざまな規模やリソース制約のある組織で効果的に活用できるが、IoCを大規模に管理するには、IoCの取り込み、処理、評価、展開の自動化が不可欠である。手作業による監視と調査が断続的に必要になるかもしれない。しかし、手作業による処理と検索に頼るのは、小規模なケースや時折発生するケースにしか通用しない。

自動化を展開することで、さまざまな時間や物理的な場所でのさまざまなログ・ソースやネットワーク監視インタフェースにわたるIoC検出の相関関係をより迅速かつ容易に実行できるようになる。したがって、特定の侵入セットからの検出数と重複を反映するように応答を調整することができ、防御者のレビューのためにアラートを生成する際に、検出と共に必要なコンテキストを提示することができる。手作業による処理と検索もそれほど正確ではないかもしれないが(著者らの経験では、IoCの転記ミスは多忙なインシデント時によくある問題である)、同程度の状況認識を提供するために必要な相関と相互参照は、はるかに長い時間がかかる。

手作業で処理する場合の3つ目の重要な考慮事項は、IoCが無関係になったり、より重要な点として、不正確になった場合に、IoCを効果的にエージング(期限切れ)するために、より長いフェーズの監視と調整が必要である。手動による実装では、IoCを単純に含めたり除外したりしなければならないことが多い。これより詳細な実装は時間がかかり、管理も複雑になる。対照的に、自動化は信頼度スコアの段階的引き下げをサポートし、IoCが寄与することを可能にするが、その特異性が低下するにつれて検出を個別に中断することはない。

6. 包括的なカバレッジと多層防御

IoCは防御側にPoPのレイヤ全体にわたるさまざまな選択肢を提供し、精度と脆さのバランスをとり、実用的で有用な信頼性の高い検出を実現できるようにする。PoPを広範囲にカバーすることは、防御者が可用性に応じて、高精度だが脆さの高いオプション(選択肢)と、より堅牢だが精度が低い指標を選択できるようにするために重要である。脆さの指標が変更されると、より堅牢なIoCにより継続的な検出と迅速な再検出が可能になる。そのため、PoP全体で可能な限り多くのIoCを収集し、防御側に選択肢を提供することが重要である。

PoPの最上位では、異常検出と機械学習によって特定されたTTPは誤検知の可能性が高く、信頼性が低くなり、防御策を理解して実装するにはより優れた訓練を受けたアナリストが不可欠である。しかし、これらは攻撃者にとって変更するのは非常に骨の折れる作業であるため、適切にチューニングされれば堅牢な検出を行うことができる。一番下のハッシュは正確で展開が簡単だが、脆弱で、悪意のあるアクターによって活動内や活動間で容易に変更されてしまう。

エンドポイントの検出と対応(EDR)やウイルス対策(AV)は、侵入から防御するための最初の手段であることが多いが、エンドポイント・ソリューションは万能ではない。問題の一つは、それらをアップデートし続けることができない、あるいは場合によってはまったく展開できない環境が多く存在することだ。例えば、MiraiのバリアントであるOwariボットネット[Owari]は、そのようなソリューションを展開できないモノのインターネット(IoT)デバイスを悪用した。エンドポイント・ソリューションが頼りにならず、このようなギャップがあるからこそ、ネットワークとエンドポイントの両方の防御を含む混合アプローチを用いた、多層防御のアプローチが一般的に推奨されている。

攻撃が発生した場合、エンドポイント・ソリューションが攻撃を検出して阻止できることが最善の状況である。そうでないとすれば、多くの正当な理由が考えられる。エンドポイント・ソリューションがかなり保守的で、低い偽陽性率を目指しているかも知れないし、ユビキタス・カバレッジを持っていないかも知れないし、キルチェーン[KillChain]の最初のステップしか防御できないかも知れない。最悪の場合、攻撃によってエンドポイント・ソリューションが無効化されていたり、マルウェアが新しいため認識されなかったりする。

ピラミッドの中央では、ネットワーク情報(ドメインやIPアドレスなど)に関連するIoCが特に有用である。これらのIoCは、ネットワークのチョークポイント(プロキシやゲートウェイなど)において、より集中的な方法で検出され、強制される可能性があるため、すべてのエンドポイント・セキュリティ・ソリューションを一つ一つ更新することなく、広範囲に対応することができる。そのため、Bring Your Own Device (BYOD)、モノのインターネット(IoT)、レガシー環境など、エンドポイントのセキュリティを確保できない状況で特に有用となる。これらのネットワーク・レベルのIoCは、ネットワーク・トラフィックで攻撃を検出するために使用される場合、セキュリティ侵害そのものが気づかれない場合でも、セキュリティ侵害されたエンドポイントからネットワークのユーザを保護することもできることに留意することが重要である。例えば、BYOD環境では、デバイス上でセキュリティ・ポリシーを適用することが難しい場合があるため、エンドポイントをカバーしていない場合でもセキュリティ侵害を検出できるようにするには、エンドポイント以外のIoCとソリューションが必要となる。

ネットワーク・レベルのIoCが多層防御ソリューションのレイヤを提供する一例として、イギリスNCSCが公共機関向けに提供する無償の自主的なDNSフィルタリング・サービスであるProtective DNS(PDNS)[Annual2021]がある。2021年、このサービスは、サービスに登録した組織に対して、1億6,000万件以上のDNSクエリ(総クエリ数6,020億件のうち)へのアクセスをブロックした[ACD2021]。これには、DGAを使用して毎月25,000のコマンド・アンド・コントロール候補のドメインを生成するAndroidマルウェアであるFlubotに関連するドメインに対する数十万件のクエリが含まれていた(これらのDGA[DGA]はTTPの一種である)。

悪意のあるドメインなどのIoCは、すぐにPDNSに配置することができ、NCSCのPDNSを使用している925以上の個別の公共機関全体にわたって、既知の悪意のあるドメインへのアクセスを防ぐために使用することができる。防御の展開は均一ではなく、必ずしも迅速ではないため、エンドポイントの適用範囲は不均一になる可能性がある。しかし、IoCがPDNS上にあれば、デバイス自体がすぐに更新されなくても、PDNSを使用しているデバイスには一貫した防御が維持される。これにより、BYOD環境であるか、管理された企業システムであるかに関係なく、防御が提供される。PDNSは、多層防御ソリューションの最前面に位置するレイヤをユーザに提供するが、TLSのServer Name Indication値やサーバ証明書情報のような他のIoCも、他のレイヤでIoC防御を提供する。

AVのシナリオと同様、大規模サービスでは、誤検知によるビジネスへの影響と脅威のバランスを考慮したリスク判断が必要になる。組織は、防御の恩恵を受けつつも、自らの防御をより保守的に行う能力を維持できる必要がある。例えば、商用DNSフィルタリング・サービスは広範な展開を意図としているため、AV製品と同様のリスク許容度を持つが、政府ユーザ向けのDNSフィルタリング(PDNSなど)はより保守的であっても、政府全体を対象としている場合は比較的広範な展開が可能である。一方、政府部門や特定の企業では、混乱のリスクを受け入れ、信頼性に関係なく特定の脅威に関連するものを完全にブロックするよう、ファイアウォールや他のネットワーク防御デバイスを配備するが、それ以外についてはDNSフィルタリング・サービスに依存する場合がある。

他のネットワーク防御は、ミドルボックスの軽減策、プロキシ防御、アプリケーション層のファイアウォールのように、IoCによるこの包括的カバーを利用することができるが、本文書の範囲外である。大規模な企業ネットワークでは、独自のDNS解決アーキテクチャと、場合によってはTLS検査プロキシを配備する可能性があり、これらの場所にIoCを展開きる。しかし、このような緩和策を展開しないことを選択したネットワーク、あるいは展開するためのリソースを持たないネットワークでは、DNSはファイアウォール、プロキシ、場合によってはDNSフィルタリング・サービスを経由する。暗号化を解除する必要はないが、これらのアプライアンスは、既知の不正なURIに対するクエリをブロックするなど、何か有用なことを行うためには、それを復号化できなければならない。

広範なIoCをカバーすることで、防御側に様々なメリットがもたらされる。IoCは展開が容易であり、効果的であるために十分な信頼性を提供し、少なくとも一部は攻撃者にとって変更が痛みとなるだろう。また、インフラ周辺に分散させることで、さまざまな障害点が可能になるため、全体として、防御側が悪意のあるアクターを混乱させることができる。これらの要素の組み合わせにより、IoCはリソースが限られている防御者にとって、特に価値のあるツールとして定着する。

7. IANA に関する考慮事項

本文書にはIANAのアクションはない。

8. セキュリティに関する考慮事項

本文書は、すべてのシステムのセキュリティに関するものである。しかし、IoCの展開が不十分な場合、IoCはオーバー・ブロッキングにつながる可能性があり、システムによっては可用性の問題が発生する可能性がある。IoCはマクロスケールでは(データ漏洩を防ぐことで)プライバシーを保護するが、IoCを共有することによるプライバシーへの影響を調査し、見つかった影響を最小限に抑えるために改善が行うことができる。ネットワークとエンドポイントの両方の防御が、セキュリティと多層防御を提供できるような、IoCを共有するプライバシー保護方法の作成は、興味深い提案となるだろう。

9. 結論

IoCは多用途で強力である。IoCは、最新の多層防御戦略の複数レイヤを支え、有効にする。IoCは共有が容易で、能動的防御の取り組みに相乗効果をもたらし、バイタル時間を節約する。ネットワーク・レベルのIoCは、エンドポイントのみのソリューションでは不十分な場合に特に有用な防御を提供する。これらの特性と使いやすさにより、IoCはあらゆる能動的防御戦略の重要なコンポーネントとなり、リソースが限られている防御者にとって特に価値のあるものにしている。

IoCが有用であるためには、暗号化する必要も、ネットワーク上で可視化する必要もない。しかし、IoCを必要とするエンティティが、そのコンテキストとともに利用できるようにすることが重要である。また、この可用性と最終的な利用法が、IoCが重要な部分である多層防御戦略に従って、複数の障害点に対処することも重要である。

10. 参考規格

[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 Annual Review 2021.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 Threat Intelligence Sharing Survey and Research Directions.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-7th-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/>.

謝辞

IETF及びIRTFコミュニティでサイバーディフェンスの改善に関わってくれたすべての人々に感謝する。

著者のアドレス

カースティ・ペイン
Splunk Inc.
メール: kirsty.ietf@gmail.com

オリー・ホワイトハウス
Binary Firefly
メール: ollie@binaryfirefly.com

ジェームズ・セルウッド
メール: james.sellwood.ietf@gmail.com

アンドリュー・ショー
UK National Cyber Security Centre
メール: andrew.s2@ncsc.gov.uk

更新履歴

2024.6.3
2024.6.7: Errataを追加

GitHubで編集を提案

要旨