PEAKフレームワークによる仮説ドリブンハンティング

ご自分がサイバー探偵になって、自社ネットワークの暗がりに潜む隠れた脅威を暴く現場にいると想像してください。ワクワクしませんか？そう、仮説ドリブンハンティングとは、持てる探偵能力を研ぎ澄まし、常に敵よりも一歩先を行くことなのです。

PEAK脅威ハンティングフレームワークでは、ハンティングを大きく3つに分類しています。

• 仮説ドリブンハンティング
• ベースラインハンティング
• モデル支援脅威ハンティング(M-ATH)

この記事では、仮説ドリブンハンティングについて詳しくご説明します。脅威ハンターの多くにとって、この手法が出発点となります。なぜなら、これによって批判的思考と事前予防型の調査が促進されるからです。

(この記事はPEAK脅威ハンティングフレームワークシリーズの一部です。フレームワークの理解を深めて、効果的なハンティングにお役立てください。)

ハンティングの仮説を構築する

学校の理科系(特に科学)の授業で「仮説は科学的手法の主要な要素」という話を聞いた記憶はあるでしょうか。それには、十分な理由があります。

ハンティング仮説は、サイバー探偵活動を進める基盤となります。これは調査を導く指針となる「鋭い勘」または「知識に裏打ちされた推測」であり、直感や経験、研究が基盤になっていると考えてください。効果的なハンティング仮説を立てるためには、創造性と分析的思考の絶妙なバランスが必要です。

適切な仮説を立てるには、以下の3つのステップで進めます。

1. トピックを見つける：適切な仮説を立てるため、まずは懸念される領域を特定します。これはまだ仮説ではなく、ハンティングトピックと呼びます。脅威の状況、最近のインシデント、最新の傾向に関する知識を活用して、ネットワーク内の潜在的なリスクを正確に識別してください。自動検出システムに役立ちそうな典型的な挙動を見つけるために、自社の業界を標的にする主要な攻撃者を調査する方法もあります。どのような進め方でも、最初のステップは対象とするアクティビティのタイプを決めることです。
2. 検証可能な形にする：調査の対象が決まったら、それを検証可能な仮説(つまり、立証または棄却できる仮説)として記述します。たとえば、ハンティングトピックがデータ流出だとします。仮説は検証可能でなければならず、想定されるすべての流出タイプを検証するのはおそらく不可能です。そこで、特定のタイプの流出に絞って書き直します。「攻撃者が、DNSトンネリングを使って機密データを窃取している可能性がある」。
3. 必要に応じてさらに具体化する：これは仮説として十分に成り立ちますが、大規模な組織ではそれでもまだ検証が難しいとみなされる可能性があります。そこでさらに絞り込んで、次のようにしましょう。「攻撃者が、DNSトンネリングを使って機密財務データを窃取している可能性がある」。この仮説でしたら検証可能です。どのようなデータ流出を探していて、どんなタイプのデータが関係しそうかが分かるからです。以上で、「何らかのデータが、何らかの方法で窃取されている」という認識が、実際にハンティングが可能な状態にまで絞り込まれました。

仮説の構築は、特に最初のうちは難しく感じるかもしれません。どこから着手すべきか迷ったら、仮説構築に関するこちらのホワイトペーパー(英語)を参考にしてみてください。

もう1つ注意したいのは、科学の場合と同じことです。仮説は、固定されたものではありません。調査中に新しいインサイトが得られたら、それに合わせて仮説を見直すつもりでいてください。これについては、後ほど説明いたします。

ABLEを使ったハンティング

明確で検証可能な仮説を立てた後も、ハンティングを始める前に把握しておくべきことがまだあります。対象のアクティビティを示す兆候は何か、どのデータソースを調査すべきか、ネットワーク内でそのアクティビティが発生しそうな箇所はどこか、などです。

PEAKには、ハンティング仮説の重要な要素を把握するのに役立つ、以下のようなABLEフレームワークが組み込まれています。

• 攻撃者(Actor)：ハンティングの対象となる攻撃者です。攻撃者タイプの大まかな限定にとどまる場合もあります。特定の攻撃者を示唆する情報は多くないため、具体的に指定しなくても結構です。しかし、もし特定できれば、ハンティングの他の部分に有用なコンテキストが得られます。
• 挙動(Behavior)：ハンティングの対象となるアクティビティです。TTP(戦術、技法、手順)とも呼ばれます。挙動については、キルチェーンの全段階にわたって探すのではなく、一度に1つか2つに絞ります。
• 場所(Location)：自社ネットワーク内で、目的の挙動が見つかりそうな箇所です(エンドユーザーのデスクトップ、インターネットに接続されたWebサーバーなど)。場所を特定できればハンティングの範囲が絞りこめるので、負担の軽減と効率の向上につながります。
• 証拠(Evidence)：アクティビティを発見するために調査が必要なデータソースと、アクティビティが実行されたときにデータソースはどう見えるかという情報の組み合わせです。データ収集の計画段階と、分析戦略の策定段階で、こうした情報が必要になります。

例：ABLEを活用して、DNS悪用によるデータ流出をハンティングする

例に沿って考えると、分かりやすいかもしれません。先ほどの仮説を使ってみましょう。「攻撃者が、DNSトンネリングを使って機密財務データを窃取している可能性がある」。ここでABLEフレームワークを適用すると、次のように分解できます。

• 攻撃者：この例では、特定の攻撃者に絞り込めません。財務データは、数多くのサイバー犯罪者にとって魅力的だからです。仮に、PIFFLING PANGOLINという名の攻撃者に自社データが窃取されている可能性があるとしましょう。この攻撃者について、たとえば、DNSトンネリングに使う既知のC2ドメインや特定のツールなどを調べることで、ハンティングの手がかりを得られる可能性があります。しかし、この例では、攻撃者どころか攻撃者のタイプさえ特定できていません。それでも、問題はありません。
• 挙動：ハンティングの対象となる挙動は、DNSトンネリングによるデータ流出です。この特定の戦術に集中することで、調査対象を絞り込み、関連する侵害の痕跡(IoC)の洗い出しに注力できます。
• 場所：上記の仮説から、標的は財務部門だと推測できます。この推測から、ネットワーク内で精査が必要な箇所を正確に特定でき、ハンティングの効率と効果が高まります。
• 証拠：DNSトンネリングを検出するためには、DNSクエリーのログやパッシブDNSの詳細ログが手元にあるならば、調べる必要があります。それが分かれば、分析戦略を立てる際に、サイズが異常に大きいか頻度が異常に高いDNSクエリー、不自然なDNSクエリータイプ、既知のDNSトンネリングツールの痕跡などを対象として組み込むことができます。

ABLEフレームワークをハンティング仮説に適用したことで、次のような実用的なハンティング計画が見えてきました。

• DNSログを収集する：財務部門で使用されるホストのログを収集します(ユーザーのデスクトップ、財務アプリケーションを運用するサーバーなど)。
• サイズが異常に大きいクエリーや応答を探す：これらはDNSトンネリングの典型的な痕跡です。
• 「正常な」トラフィックと判断できるDNSレコードタイプを特定する：それに基づいて、異常なレコードタイプが含まれたクエリーを調査します。
• 主要な既存のDNSトンネリングツールを調査する：同時に、各ツール独自のネットワークアーティファクトを探します。詳しくは、Pyramid of Pain(痛みのピラミッド)を参照してください。

PEAKによる仮説ドリブンハンティング

頼りになる仮説を立て、ABLEフレームワークを適用したので、ハンティングの3つのフェーズである準備、実行、対応に進む態勢ができました。

どのフェーズも、ネットワークの深みに隠された謎を解くうえで不可欠です。これらのガイダンスに沿って、初期の計画段階から、苦労して得た知見を共有する最後の対応段階まで進むことができます。では、フェーズごとに詳しく見ていきましょう。

PEAKフレームワークの仮説ドリブンハンティングプロセス

フェーズ1. 準備：ハンティングの環境を整える

「準備」フェーズでは、ハンティング成功の可能性を最大限に高めるために必要なすべての準備を行います。この記事をここまで読んでいれば、このフェーズを始めていることになります。

トピックの選択：最初のステップとして、手応えがあって興味が引かれるトピックを選びます。仮説としてはまだ不十分なものですが、これをもとに完全な仮説を構築します。たとえば、この記事でサンプルに取り上げたトピックは「データ流出」でした。

トピックの調査：トピックが決まったら、書籍やインターネットで調査を進めます。得られる限りすべての情報を収集し、専門家を目指すくらいのつもりで取り組んでください。知識は力なのです(「知ることは戦いの半分」とも言えます)。DNSの例で言えば、次のようなことです。

• 代表的なデータ流出メカニズムとツールについて学びます。
• 自社でデータ流出を検出する既存の方法を確認し、検出について不足している部分も把握します。
• ハンティングのサンプルを、運よく誰かが公開しているかもしれません。これを利用すれば、有利なスタートを切れます。
• 特定の攻撃者を想定している場合は、その常套手段やツールを調べてみます。ここでは、CTIチームや脅威インテリジェンスサービスのベンダーが良質な情報源になるでしょう。

仮説の構築：調査に基づき、自社ネットワーク内の潜在的な脅威とそのアクティビティに関する仮説を立てます。仮説は必ず検証可能なもの、すなわちハンティング過程で実際に立証または棄却できる形にしてください。ここでの仮説は、「攻撃者が、DNSトンネリングを使って機密財務データを窃取している可能性がある」です。

ハンティングの範囲設定：調査するシステム、データ、期間を決めて、ハンティングの範囲を設定します。期間については、制限を設けてもよいでしょう。たとえば、最長3日間と決めておくのです。その間に悪質なアクティビティが見つからなければ、その脅威はおそらく発生していないと考えられます。ABLEのうち「場所」と「証拠」が、範囲を決める鍵となります。

計画：調査で得られた知識とABLEのデータをもとに、仮説の検証に必要なツール、手法、リソースを大まかに策定します。次の事項を考慮してください。

• 必要なデータを収集する具体的な方法
• ハンティング対象のアクティビティを検出するための分析手法
• 個人ではなくチームでのハンティングの場合、各メンバーが担当する作業

的確な計画が作成できれば後続の「実行」フェーズがスムーズに進められるので、このステップには一定の時間をかける価値があります。

フェーズ2. 実行：攻撃者を根絶する

ハンティング計画を行動に移すのが「実行」フェーズです。これこそ「本当のハンティング」に思えるかもしれません。しかし、大切なので理解しておきたいのは、ハンティングが成功して効果を発揮するには3つのフェーズすべてが必要だということです。すべてのフェーズが「本当」なのです。

データの収集：計画が用意できたら、次に証拠を収集し、すべての情報を1カ所にまとめて分析します。このステップは、すでに完了している場合もあります(たとえば、必要なDNSログをSplunkインデックスに取り込み済みの場合)。そうでなければ、証拠が得られそうなサーバーやディスクを特定して、データを収集します。

データの前処理：残念なことに、必要なデータがすぐに分析できる状態になっているとは限りません。特に、手動で収集した場合はそうです。その場合、たとえば以下のような作業が必要です。

• 形式を変換する(JSONからCSVなど)
• 2つの異なるソリューションから収集した同等のログを正規化して、1つの共通スキーマにする
• 欠損値や無意味な値を含むレコードを取り除く

データがクリーンかつ一貫性が確保されていると、分析が非常に楽になります。

分析：データを詳しく調査して、仮説の裏付けか棄却につながるパターン、異常、その他の証拠を探します。ここは直感と分析スキルの見せどころです。分析には、以下のようなさまざまな手法があります。

• 最小/最大発生頻度
• クラスタリング
• 可視化

個別の手法については、今後のブログで詳しくご紹介します。ここでは、整備士がさまざまな工具を揃えるように、多くの脅威ハンターが新しい分析手法を取り入れていることだけ押さえておいてください。ハンティングの回数を重ねるほどに使える手法は増えていき、目の前の作業に適した手法をすばやく選択できるようになります。

仮説の見直し：分析で新たなインサイトが明らかになったり、期待していた情報が見つからなかったりした場合は、ためらわずに仮説を見直してください。それは、脅威ハンティングでは当然のことであり、標準プロセスの一部です。いつも1回目で成功するとは限りません。たいていの場合、仮説を再検討して練り上げるサイクルが何回か必要となります。

重大な発見のエスカレーション：ハンティング中に不審または悪質なアクティビティが見つかったら、しめたものです。直ちにインシデント対応チームにエスカレーションして、早急に対処してもらいます。最終的に、サイバーセキュリティの世界では、時間が命運を分けるのです。

フェーズ3. 対応：調査結果をまとめる

綿密な計画を立てて適切に実行しても、ハンティングで得たナレッジを記録して活用できなければ意味がありません。「対応」フェーズのポイントはそこにあります。

ハンティングの記録：苦労した経験を無駄にしないでください。ハンティングで使ったデータ、ツール、手法などを記録し、今後の参考としたり、他のサイバー探偵と共有したりしましょう。多くのチームは、ハンティングごとにWikiページを使っています。データへのリンク、分析プロセスの説明、主な調査結果やメトリクスのサマリーなどを記載するのです。

ハンティングの際、過去の類似例を探して参考にするハンターは珍しくありません。後世のハンターのためにも、時間を取って仕事内容を記録しておきましょう。

調査結果の文書化：調査結果に関する詳細なレポートを作成します。レポートには、仮説を立証したか棄却したか、データや検出に関して発見した不備、特定した設定ミス、そしてもちろん、エスカレーションした潜在的なインシデントを含めます。これが今回のハンティングプロセス全体から得られた教訓です。こうした調査結果と、見つかった問題に対処するためのアクションは、組織のセキュリティ体制の継続的改善に大いに役立ちます。

検知手段の作成：今後同じような脅威の捕捉に使えるように、調査結果から本稼働用の検出ルールまたはシグネチャを作成します。組織の体制によっては、詳細な調査結果を検知エンジニアに回すこともあります。いずれにしても、ハンティングを通じた自動検出機能の強化は、セキュリティ体制の継続的改善を大きく推進するもう1つの要因となります。

バックログへの新しいトピックの追加：ハンティングの最中に、新たな調査の方向が見えてくることはよくあります。その場合は、進行中の調査に引き続き集中しましょう。ただし、新たな対象のことは、今後のハンティングでのトピックや仮説の候補として書き留めておきます。チームとしてそのような候補をハンティングのバックログにまとめている場合(そうすべきです)は、そこに追加して、後日参照できるようにしておきましょう。

調査結果の報告：伝説の名探偵が関係者全員を応接間に集めてすべてを明らかにするのと同じように、ハンティングにおいてもこのステップはまさにクライマックスと言えます。調査結果を関係者に報告して、全体的なセキュリティ体制の改善につなげられるようにします。SOCの幹部や調査対象となったシステム/データのオーナーに、個々のハンティングの結果をメールで伝えたり、月に1回、セキュリティチームでハンティングに関するブリーフィングを行ったりします。チームと関係者の双方にとって最適なコミュニケーション方法を考えましょう。ナレッジは何といっても、共有されたときに最大の効果を発揮するのです。

まとめ

仮説ドリブン脅威ハンティングは効果的で魅力のあるアプローチであり、人間の直感、創造性、分析スキルを組み合わせて自社のネットワークセキュリティを強化するものです。

効果的なハンティング仮説にABLEフレームワークを適用して実践的な計画に落とし込むことで、ハンティングを成功に導く強固な基盤が築かれます。PEAKフレームワークの「準備」、「実行」、「対応」の各フェーズに沿って進めれば、的確なハンティングを体系的かつ効果的に行うことができます。仮説ドリブンハンティングの威力を活用し、自社のデジタル資産の保護を強化する取り組みに着手しましょう。

PEAK脅威ハンティングフレームワークについて詳しくは、E-book『PEAK脅威ハンティングフレームワーク』もご覧ください。

ぜひ、効果的なハンティングにお役立てください。