Exabeam入社以前の生活

Exabeamに入社する前、私は10,000人の従業員が在籍する世界的に有名な企業でサイバーセキュリティ対策業務のリーダーを務めていましたが、そのセキュリティチームのメンバーはわずか5人のアナリストでした。多くの組織と同様に、私たちはサイバーセキュリティアナリスト、調査担当者、アーキテクト、連絡係としての業務をこなしていました。

組織でどのようなアクティビティを通常あるいは異常とみなすかについて、すべてのセキュリティアナリストが持つ内部知識のレベルは様々であるため、品質管理は不可欠です。これを踏まえ、私がチームを教育する中で強調したのは、主張するときには少なくとも2通りの方法で証明しなければならない、3通りならなお良い、ということでした。

従来型SIEMを用いてインシデントタイムラインを手作業で作成する方法が、大量のクエリを必要とする、多大な労力のかかるプロセスであることを私は身をもって知っています。この記事では、そのプロセスがどれほどの労力を要するかを見ていきます。そして、このシリーズの2番目の記事では、Exabeamがどのようにプロセス全体を自動化しつつ、手作業によるプロセスでは見逃されてしまう重要な情報も含めるかをまとめます。

通常行動の基準とは何かを問う

セキュリティ関連の事象に対するあらゆる質問は、次の質問にたどり着きます。「イベントの時系列タイムラインを作成するにあたって、各イベントが特定のユーザのアクティビティを正確に描写していると証明するために、どのようなクエリをSIEMで実行する必要があるでしょうか？」各アラートまたはイベントは、手作業で処理して全容を明らかにしてから、次のアラートまたはイベントに移行する必要があります。この点を図1に示します。私たちのタスクの目的は、最も関連性の高い情報をまとめることでした。

図1：インシデントレスポンスアナリストがたどるワークフローの例。

しかし、異常行動の検知は、業務全体のごく一部にすぎません。現実には、このような情報を生ログデータから検索することは非常に難しく、さらに骨の折れる作業です。

ほとんどの場合、以下のような疑問や可能性がさらに発生するため、ログから意味を読み取ることは困難です。

• ユーザにこのようなアクセス権があるのは、通常、問題ないのか？
• このアクティビティは、ユーザの職務権限と一致しているのか？
• このアクティビティは、ユーザがシステムやアプリと通常やりとりしている方法と一致しているのか？

コンテキストなしで、きわめて大量の生データから結論を導き出そうとすることは、とても大変なことでした。

別々の道をたどると同じ真実にたどり着かないことがある

手作業による脅威の調査とリスクの評価は、非常に時間がかかるうえ、ミスも起こりやすくなります。しかも、これらすべてのデータを精査するアナリストにも各自のバイアスがあり、それぞれが意味があると思った道をたどります。私の経験上、同じインシデントを2人のアナリストに割り当てると、2つの異なる結果が導かれます。それは、セキュリティオペレーションチームの信頼性にとって好ましい結果とは言えません。

図2：イベントを調査する際に、アナリストは多くの質問に答えなければならない。
この例では51種類の質問を挙げている。

手作業による調査のシミュレーション

私は最近、手作業のピボットやクエリを通じて調査を行う非効率性を示すために、従来型のSIEMプラットフォームのシミュレーションを行いました。

組織内でのアナリストのスキルレベルは、中程度を想定しました。つまり、異常状態、ユーザが使用するアプリ、どのリソースをどのユーザが使用するか、最新の攻撃手法に関する知識、脅威の可能性を示す指標のレピュテーションをチェックする場所（ドメインまたはIPレピュテーション、ファイルレピュテーション）に関する基本的な知識があるアナリストです。

また、クエリデータが問題のない速さで返される、比較的うまくチューニングされた環境を選定しました。現在ほどテクノロジーが進歩していなかった数年前の当時としては、ありえない想定です。

現実の企業では、チューニング不足の環境、不十分なログ取り込みによる可視性のギャップ、24時間態勢の監視が不可能な人員配置などにより、さらに検知や応答の時間に対する悪影響が考えられます。評価すべき変数や指標は、以下のように大量にあります。

• 組織にSOCはあるか？
• SOCには、24時間年中無休でセキュリティイベントを監視している従業員がいるか？
• 従業員の平均的な応答時間はどれくらいか？
• 監視担当者はパートタイムか？または、監視業務をアウトソーシングしているか？
• それぞれの場合のMTTD（平均検知時間）とMTTR（平均応答時間）はどのくらいか？
• ペネトレーションテスト、レッドチーム演習、あるいは別のシミュレーションを利用して定期的にテストしているか？
• SIEMは、必要な情報をすばやく返すように適切にメンテナンス（チューニング）されているか？
• 過去30日、60日、90日のクエリを返すためのSLAはどのようなものか？
• セキュリティ予算は、継続的なSIEMメンテナンスに対応しているか？

こうしたセキュリティのギャップが大きなデータ侵害につながることを頻繁に見かけます。次の格言は、今でも当てはまります。「防御側はあらゆるインシデントを把握する必要があるが、攻撃側は1回成功するだけで良い」。この点に関して言えば、最大のリスクが潜むのは防御範囲のギャップです。既知のギャップを埋めるためには膨大な努力と集中が必要になります。また、これまで未知だったギャップを特定するために、セキュリティチームやより広い意味でのITチームを後押しする必要もあります。

多くのケースでは、アナリストがあるインシデントを調査すると、当初考えていたよりもはるかに広範囲に影響が及んでいることが判明します。デジタルフォレンジックにより、ラテラルムーブメントやその他の方法で常駐している証拠がしばしば見つかります。そして、最初のセキュリティ侵害が6か月以内のできごとではなかったことが初めてわかります。セキュリティ侵害は、何年も進行していたのです。

前提を立てる

本番環境では、1つのシステムで1日当たり200～400のプロセスを実行している場合が珍しくありません。ヘビーユーザなら4桁に達するかもしれません。200と仮定すると、アナリストは通常、80対20の法則を適用します。つまり、80%のプロセスについては、発生している理由について自信を持って説明し、何回かの検索を実行して検証し、すばやく除外できると考えられます。それでも、アナリストが詳しく調査する必要のあるプロセス実行が約40残ります。

従来型のSIEM環境において、イベント全体の流れを説明するために必要なインシデントタイムラインを作成するためには96件の異なるクエリが必要でした。各クエリを実行して結果を分析するためには、平均12.9分かかりました。合計で20.64時間かかることになり、これは作業者1人の平均勤務時間を大幅に上回ります。調査結果はアナリスト間で引き継がれることになるため、調査で得られた知見の一部が、引き継ぎによって失われるおそれが出てきます。

この一連の攻撃シミュレーションで、Frederick Weberというユーザが目立っていました。現実世界の調査では、Weber自身がアカウント上で観察されたアクティビティを実行しているのか、それともWeberのアカウントを使っている攻撃者がいるのかを判断する必要があります。一方で、インシデントが本当にWeberを指し示していた場合、Weberが外部の者に買収されていたり、脅されていたりする内部不正の可能性があるかどうかも考える必要があります。手作業の場合、アナリストが大規模なデータセット全体にわたって通常行動から逸脱した行動を確実に検知するのは非常に難しいことです。非常に労力がかかる作業で、ミスも起こりやすくなります。

シミュレーションにおけるWeberのタイムラインに注目し、私は短期の検索クエリを最初のタブ（Tab 1）に設定し、長期のクエリを2番目のタブ（Tab 2）に設定しました。これにより、Weberのアクティビティを、ユーザ本人（Weber）と組織全体の過去の標準的な状況と切り替えて比較するスピードが向上します。

その後、シミュレーション環境からいくつかの結論を推定しました。

タイムラインのピース同士をつなぐ

まず、conhost.exeの調査から始めました。これは、Tab 1に示されている、Weberが実行していたホストプロセスです（図3参照）。Tab 2に切り替えて3月から5月の期間を観察すると、conhost.exeには1,243のエントリーがあります。このような人手による分析では、この環境にconhost.exeが頻繁に現れるのは通常どおりである、という解釈もありえます。マルウェアである、あるいは攻撃者が活用している、という懸念は持たないかもしれません。

図3：Tab 1は、対象者Frederick Weberによるconhost.exeプロセス実行の
アクティビティに関する、短期間の検索を示す。

自信がなかったので、SOCチームのメンバーに、conhost.exeについて確認しました。このメンバーは、ピアグループでの使用状況を確認することを勧めてくれました。Frederick Weberはウェブ開発者のグループに属しています。すると、ピアグループ内で2か月間にconhost.exeを実行しているのはWeberだけではないことがわかりました（図4参照）。

図4：Tab 2は、Frederick Weberのピアグループによるconhost.exeプロセス実行の
アクティビティに関する、長期間の検索を示す。

結局、conhost.exeは、ユーザがコマンドプロンプトウィンドウを開くたびに実行される、コンソールウィンドウホストでした。そのことがわかるかどうかはアナリスト次第です。しかもコマンドプロンプトはWeber以外にも多くの人が利用すると考えられます。

ここでは、限定されたテストデータを用いたシミュレーションにおいて、アナリストが何を把握できている可能性があるかを見ています。時間が刻々と過ぎていく中で、私はconhost.exeが誤検知であると判断しました。

ところで、Tab 1のbarbarian.jarは何でしょう。このファイルが、Tab 2に示す2か月間のタイムラインで1度しかヒットしないのはなぜでしょう。この環境で、Weber以外にこのファイルを以前に実行したユーザはいないようです。これは明らかに異常であり、さらなる調査が必要です。

さて、一旦休憩しましょう。 次の記事では、別々のログとエビデンスからタイムラインを構築する方法、必要な質問、そして調査のタイムラインを作成するために信頼性の高い自動システムを利用する方法について説明します。

Erik Randall
Exabeam, Inc. セールスエンジニア