セキュリティインシデントが、最初から明確に分類された状態で発生することはほとんどありません。
現代のクラウドおよびSaaS環境において、最も対応が難しいのは明確な攻撃ではありません。一見すると善意に基づく正当な操作に見えながらも、危険な形で実行され、信頼されたアイデンティティを介して、あるいは想定外の場所から、予期しない挙動として現れます。こうした状況では、経験豊富なセキュリティチームでさえ判断に迷います。シグナル自体は確かであっても、その意図が不明確だからです。
本記事は、エクサフォース社内で実際に発生したインシデントに基づいています。内容は匿名化されており、かつ正確で、日々セキュリティチームが直面する課題を代表するものです。
迅速な検知とトリアージ
自社で自社製品を運用しているため、当社環境にはリアルタイムのデータソースが取り込まれており、重大度P1のアラートがプラットフォーム上に即時に生成されました。エクサフォースは関連するシグナルを即座に相関分析し、単一のインシデントとして統合しました。その後、設計どおりMDRプロセスが起動し、アラートはSLA内でトリアージされました。
この時点で観測されたテレメトリからは、「侵害でないと証明されるまでは侵害として扱う」という判断が妥当でした。十分なコンテキストはまだ得られておらず、このアクティビティが悪意によるものか、あるいは予期しない（しかし正当な）第三者の挙動なのかは不明でしたが、シグナルは侵害と整合していました。
人手による調査前にプラットフォームが検知した内容
このアクティビティには、サードパーティのSaaSインテグレーションに関連付けられた非人間アイデンティティが関与していました。具体的には、GitHub Appトークンを用いてJWTを生成し、公開ドキュメントリポジトリのコンテンツを不明なラップトップへクローンするための認証が行われていました。このアイデンティティの挙動は従来一貫しており予測可能でしたが、そのベースラインが突如として変化しました。本件はプロダクションコードには影響していませんが、この挙動パターンは懸念されるものであり、相応の対応を実施しています。なお、本番システムおよび機密性の高いプロダクションコードへのアクセスを防ぐ強固な制御が実装されており、この種の事象が非公開リポジトリの範囲を超えて拡大しないよう設計されています。
短時間のうちに、以下の複数の逸脱が同時に発生しました：
- 新しい国からのアクセスが発生
- ソースネットワークが家庭用ISPへ変更
- ユーザーエージェントがワークステーションのGitクライアントへ変化
- リポジトリのフルクローンが短時間に複数回実行
- 同時に、同一アイデンティティが通常のクラウド環境からも継続して動作
これらのシグナルはいずれも、単体で見れば珍しいものではありません。地理的な異常はノイズが多く、ネットワークの変化も日常的に発生します。リポジトリアクセスも正当な場合があります。多くのセキュリティツールはこれらを個別にアラートとして検知しますが、多くのチームは次第にそれらを無視するようになります。ここで重要だったのは、これらが「同時に発生していた」という点です。
同一のアイデンティティが、異なる2つの環境で同時に活動していました。この重複により、ボットアイデンティティにとって不可能な移動（impossible travel）が成立し、リスク評価が変化しました。
従来の検知手法が苦戦する理由
一般的な環境では、このような事象は以下のような個別アラートとして生成されます：
- 地理的異常アラート
- ネットワーク／ASN変更アラート
- リポジトリアクセスアラート
- サードパーティインテグレーション関連アラート
各アラートは個別かつ独立して発報され、タイムスタンプも異なり、コンテキストも限定的です。そのため、経験豊富なアナリストであっても、シグナルを手動で相関分析し、タイムラインを再構築したうえで、そのアクティビティが偶発的なものか、設定ミスか、あるいは侵害かを判断する必要があります。
このプロセスには時間がかかります。そしてその時間こそが、攻撃者が頼りにするものであり、正当であっても想定外のアクティビティによって消費されるものでもあります。
エクサフォースによる対応の違い
これらのシグナル群から、エクサフォースは意味のある単一のインシデントを生成しました。
アイデンティティ挙動を起点とした分析
対象のアイデンティティは、人間ではなくボットとして分類されていました。ボットアイデンティティは、移動したり、家庭用ブロードバンドを使用したり、OSを切り替えたり、対話的に操作したりすることはありません。こうしたパターンが現れた場合、それは想定される挙動からの重大な逸脱を意味します。この挙動の逸脱だけでも、インシデントをエスカレーションする十分な根拠となりました。
タイムラインの自動再構築
エクサフォース Agentic SOCプラットフォームは、一連のイベントを自動的に再構築し、クラウドインフラストラクチャから発生した正常な自動アクティビティと、家庭用ネットワークから発生した異常な手動アクティビティを区別しました。また、同時利用を示す時間的な重複も特定しました。この再構築には、手動クエリ、ダッシュボード、ログのつなぎ合わせは不要であり、タイムラインはインシデントコンテキストの一部として即時に利用可能でした。
AI支援トリアージと人間にとって明確な判断
プラットフォームは、過去のベースライン、アイデンティティ種別、アクセスパターン、環境コンテキストを総合的に評価し、経験豊富なアナリストがこの状況を判断する方法と整合する明確な結論に達しました。すなわち、「侵害でないと証明されるまでは侵害として扱うべき」という判断です。この判断の枠組みにより、チームは完全な確証を待たずに、迅速かつ断固として行動できました。
エクサフォースチームの対応
インシデントのスコープとコンテキストが明確だったため、対応は迅速かつ適切に実施されました。短時間のうちに、P1インシデントのレビュー、MDR（マネージド検知・対応）チームの直接関与、サードパーティインテグレーションの停止、管理者認証の無効化、フォレンジック証拠を添えたベンダーのセキュリティチームへの連絡が行われ、事態は数時間以内に解決しました。プラットフォームがすでに相関分析を完了していたため、チームはシグナル同士の関連性を議論する必要がありませんでした。
結果と、なお重要である理由
ベンダーとの共同調査の結果、このアクティビティは侵害ではなく、善意によるものではあるものの、安全ではないサポート対応であったことが確認されました。SREがベンダー側の不具合から復旧するため、非人間アイデンティティを使用して、当社のリポジトリを個人用ラップトップへ手動でクローンしていたのです。迅速に対応してサービスを復旧する意図はあったものの、ボットアイデンティティを使用し、顧客への事前通知なしに、ベンダーの通常の本番インフラストラクチャ外で顧客コードへアクセスすることは不適切であり、有効な侵害指標を生み出しました。
今回のケースでは、リポジトリに含まれていたのは公開向けのプラットフォームドキュメントであったため、直接的な影響は最小限でした。しかし、同じパターンが内部アーキテクチャドキュメント、ランブック、機密データを含むリポジトリに対して発生していた場合、重大な結果を招いていた可能性があります。より広い教訓は、制御とコンテキストが不足していると、正当ではあるものの時間に追われた判断が、いかに容易に侵害と区別できなくなるか、そして困難な状況であっても、このようなことは起きてはならないという点にあります。
曖昧なシグナルから確実な検知へ
本件は侵害ではありませんでしたが、シグナルは実在し、リスクも実在していました。ツールがその違いを迅速かつ確信を持って判断できない場合、運や人間の属人的な対応力に依存していることになります。エクサフォースのプラットフォームは、何が起きているのか、なぜ重要なのか、どれほど緊急なのかをリアルタイムで把握していました。これこそが、単に反応することと、備えができていることの違いです。
エクサフォースが複雑なシグナルを単一の一貫したインシデントに統合する仕組みを確認したい場合は、エクサフォースのデモをリクエストしてください。
