レガシーSIEMからElasticへのセキュリティ運用のより広範な近代化の一環として、VisaのサイバーセキュリティエンジニアリングチームはSOCで最初のエージェント型AIワークフローを構築しました。これは、IR対応のケースを生成するために制約付きかつヒューマンインザループのAIステップを使用する4段階のパイプラインです。以前は手動の2次クエリーを必要とした重大なメインフレーム検出では、トリアージ時間は10〜20分から数秒に短縮され、同じ制御された監査可能なパターンが今では他の検出でも再利用可能になりました。
概要
Visaは従来のSIEMからElasticに移行しており、その移行中にサイバーセキュリティエンジニアリングチームは概念実証として最初のElastic Workflowsパイプラインを構築しました。選択された検出である重要なメインフレームのID検出は、以前はアナリストがアラートからフォローアップ検索に切り替えて責任のあるユーザーを特定する必要があり、その結果はメインフレームログに関するアナリストの経験によって大きく異なっていました。チームは2つのElasticsearch Query Language（ES|QL）クエリーを連結し、IRチーム向けに構造化された要約を生成する制約付きAIステップを追加し、Webhookを使用してケースをIRチケットシステムに直接配信しました。アラートが発動すると、トリアージは10～20分ではなく数秒で完了し、同じ4段階のパターンが他の検出にも適用できるようになりました。
アラートは作業の始まりに過ぎない
Visaは世界最大級の決済環境を保護しています。従来のSIEMからElasticへの広範な近代化の一環として、サイバーセキュリティエンジニアリングチームは、Visaがまだ大規模には実用化していないもの、つまりセキュリティ業務内でAIを使用するための、制御された防御可能な方法の構築に着手しました。その基準は具体的なものでした。AIのステップはすべて、監査可能で、範囲が狭く、チームが管理するデータに検証可能な形で紐付けられていなければなりませんでした。その基準がテストされた最初の領域は、高リスクのメインフレームのアイデンティティ検出で、すべてのアラートでは、インシデントレスポンスチームが調査を開始する前の段階で、コンテキスト収集を10～20分かけて手動で行う必要がありました。
レガシーSIEMでその検出が作動したとき、インシデントレスポンスチームはログインし、二回目の検索を実行し、どのユーザーがそのアクティビティの背後にいるかを突き止める必要がありました。検出によりイベントが特定されても、アナリストはまだ人物を特定しなければなりませんでした。
「アラートが発動すると、IRチームはアラートを受け取り、レガシーシステムにログインして二回目の検索を実行する必要があります。データを精査して、ユーザーに対して正しい端末を見つけられるようにしても、実際に犯人が誰かは分かっていません。そのため、二回目の検索を実行し、その端末を最後に使用した人物を特定してから、メインフレームチームに連絡します。それら全ては、とにかく時間がかかりすぎたんです。」
チームの枠組みはシンプルでした：IRチームが行動する前に、すべての実行可能なアラートが2次クエリーを必要とする場合、パイプラインは不完全です。2次クエリーをアップストリームにパイプライン自体へ移動させると、IRチームはレビュー用にすでに強化され、要約され、メインフレームチームに引き渡す準備ができたケースを受け取ります。
Visaが現在に至った経緯：創造性を発揮できる余地のある移行
Visaのより広範なプロジェクトは、レガシーSIEMからElasticへの検出ロジックの移行です。その種の移行は、たいてい集中してルール変換を行う傾向があります。チームは、エンジニアが変換作業と並行して新しいプラットフォーム機能を試す余地を意図的に作りました。
「Elasticのおかげで、さらに前進できることが分かりました。技術的な限界については、今まで考えたことすらありません。このツールで実現できることがわかったので、創造性を発揮してアイデアを生み出せます。プロセスを改善する方法、どうすれば効率が上がるかを考え出すことができます。"
チームのサイバーセキュリティエンジニアがElastic Workflowsのトレーニングを受け、すでによく知っている検出を選び、Elasticソリューションアーキテクトと協力して最初のバージョンを構築しました。Elasticチームは、エンジニアが提供したサンプルから代表的なテストデータを生成し、スターターワークフローをゼロから構築し、エンジニアが拡張できるテンプレートとして返しました。
既存のアプローチでは提供できなかったのは、データと同じセキュリティプラットフォーム内に存在するネイティブな自動化です。Visaでは、SOARスタイルのオーケストレーションは別の自動化チームが担当し、検出自体とは別のプラットフォームで実行されます。Elastic Workflowsを使用すると、検出、エンリッチメント、検証、デリバリーの全パイプラインが1か所で実行されます。すべてネイティブで、エンジニアが1つの画面で読み、編集できる1つのYAMLファイルに含まれています。
ワークフローは特定の理由から正しい出発点でもありました。Visaは、AIステップが受け取ったもの、それが生成したもの、そしてすべての決定の検証方法について完全な制御が必要でした。規制の厳しい金融サービス環境において、そのような監査可能性は、セキュリティ業務においてAIを信頼するための前提条件です。Workflowsにより、チームは全面的に定量化し説明可能なパターンを獲得し、Elasticのロードマップ上の他のエージェント機能に拡張する前に、各ステップを単一のYAMLファイルで可視化できました。
導入以前：アラート、2回目の検索、そして引き継ぎ
以前のワークフローでは、アラートの後に調査を行い、検出が起動し、IRチームは従来のSIEMにログオンします。彼らはフォローアップ検索を実行し、イベントを端末とユーザーに関連付けます。メインフレームのログは、その作業に適した環境ではありません。
以前の状態がコスト高となった理由は以下の3つです。
- 二度目の検索が避けられなかった。端末には一度に1人しか割り当てられませんが、端末の値は再利用されます。フラグが立てられたイベントの背後にいるユーザーを特定するために、アナリストは、そのイベントの時間帯に、そのメインフレームパーティション上の、その端末への直近のログインをクエリする必要がありました。
- アナリストのスキルが大きく影響。経験豊富なアナリストで、クエリ言語とメインフレームのイベントコードを知っていれば、すぐに作業を実行できました。経験の浅いアナリストやメインフレームログに詳しくないアナリストの場合は、明らかに時間がかかりました。その結果、時間と品質の両面でばらつきが生じました。
- メインフレームのイベントコードが複雑。イベントを結果にマッピングする単一の経路はありません。アナリストは、意味が文脈に依存するシステムコードを解釈しなければならないことが多く、そのため作業が遅くなり、結果の標準化が難しくなっていました。
時間と品質の両方が2回目の検索作業に割り当てられていました。検出によってイベントが特定されても、アナリストは、検出結果の一部であるはずの調査をまだ行っていました。
アーキテクチャ： 5分のスケジュールで動作する4段階のパイプライン
新しいパイプラインはElastic Workflows内で4つの連鎖した段階として実行されます。
- 検出（プライマリES|QLクエリー）：5分間のタイマーと10分間のルックバックウィンドウで、ワークフローはメインフレームのログに対して高速かつ限定的なES|QLクエリーを実行し、対象となるアイデンティティのアクティビティを検索します。検出は意図的に厳密です。チームは1回の実行で1つか2つのヒットより多くは期待しておらず、過去にはアラートは年に数回しか発動していません。
- エンリッチメント（セカンダリES|QLクエリー）：返されるイベントごとに、ワークフローはフォローアップのES|QLクエリーを実行します。このクエリーは、プライマリイベントの端末値とLPAR（メインフレームパーティション）を取得し、その端末の直近のログインを検索します。端末は再利用されますが、一度に割り当てられるユーザーは1人だけです。直近のログインがアクティビティの背後にいるユーザーを識別します。検証は迅速です。結果を生み出した同じクエリーをエンジニアがすぐに確認できます。
- AI検証：エンリッチメントされたイベントは、大規模言語モデル（LLM）がサポートするステップに渡されます。このモデルは、制約付きのプロンプトを受け取ります。これは、端末は一度に1人しか使用できないという前提、プライマリアラートの詳細、およびセカンダリクエリーの結果です。その役割は、データが結論を支持していることを確認し、ユーザーの名前とID、元のアラートが検出した内容、およびこの人物が識別されたアクターである理由を含む体系的な要約を作成することです。エスカレーションするかどうかを決めるのはモデルではなく、IRチームです。
- 配信（Webhook）：要約はWebhookを介してIRチケットシステムに配信されます。チケットが作成された時点で、IRエンジニアはケースを確認しており、組み立てているわけではありません。
ここで最も重要なアーキテクチャの選択は、セキュリティデータと同じプラットフォーム内でパイプライン全体がネイティブに実行されることです。SOARが別に存在せず、保守する別のオーケストレーションシステムもなく、検出とワークフローの間に仲介役のようなものもありません。
技術的なハイライト
- ES|QLのプライマリクエリーは5分のタイマーで、10分のルックバックを使用します
- ES|QLのセカンダリクエリーは、プライマリイベントからターミナルとLPARを取得して、直近のログインを見つけます
- 以前必要とされていた手動の二次クエリー手順を行うアナリストの負担が大きいため、この検出方法が選択されました
- LLMによる検証ステップは、制約された構造化プロンプトを受け取り、自由形式の分析は行いません
- コンテキストウィンドウ処理：関連するレコードのうち、直近5～15分間のデータのみがモデルに渡されるため、送信されるトークン数が削減され、モデルの動作コンテキストが厳選されます
- Visaはプロバイダー間で移動しており、プラットフォームはモデルに非依存です
- ワークフローは、コードエディターのように、1つのKibana画面で作成およびテストされる単一のYAMLファイルです
- Webhookは、体系的な要約をIRチケットシステムに直接配信します
機能
連鎖的なES|QLの検出とエンリッチメントを1つのワークフローで
検出とエンリッチメントをアナリストが介在する2つのステップではなく、連鎖的な1つのフローとして扱うことで、パイプラインの残りの部分が可能になりました。ES|QLのパイプ型モデルにより、チームはフローを宣言的に表現できます: プライマリクエリーはフラグ付きイベントを識別し、セカンダリクエリーはターミナルからユーザーへのマッピングを重ね合わせて、それを行ったであろうユーザーを決定します。間にアナリストのコンソールセッションはなく、ログインする二番目のツールもありません。ワークフローの構造は、何かが起こったか？で止まるのではなく、アナリストの実際の質問（誰がこれをしたのか？）の構造と一致するようになりました。
意図的に範囲を狭めた制約付きのAIステップ
AIのステップは、1つの特定の仕事を行っています。それは、エンリッチメントデータが結論をサポートしていることを確認し、IRチームが数秒で読める体系的な要約を作成することです。検出ロジックは生成されず、エスカレーションするかどうかを決めるわけでもありません。分析の前提となる仮定（端末は一度に一人しか使用できない）が伝えられ、その仮定に照らして評価するために、直近のログイン情報が与えられます。
「以前は、IRチームは別のツールにログにログインして他の検索を実行する必要がありました。今では、利用可能なすべてのデータが入ったアラートを受け取るだけです。すべてがとても分かりやすく整理されています。」
この狭さこそがポイントです。チームの選択は、「モデルに調査させる」のではなく、「クエリーですでに返された内容をモデルに検証して要約させる」ことでした。パイプライン内のすべてのAIの判断は、チームが閲覧できるデータと、チームが管理する基準に基づいて評価されています。これが検証を不透明ではなく監査可能なものにしています。
トークン効率の良いコンテキストウィンドウ処理
モデルは必要以上のデータを見ることはありません。パイプラインは、イベントのタイムウィンドウ、つまり最後の5～15分に関連するレコードのみに絞り込み、検出の枠組みに一致させます。その結果、コンテキストウィンドウが小さくなり、意思決定あたりのトークン数が減少し、推論がより厳密になります。これは、モデルが質問と無関係なレコードを解釈しようとしないためです。
セキュリティプラットフォーム内のネイティブ自動化
パイプライン全体が、データと連携してElastic内で稼働しています。別途保守するオーケストレーションプラットフォームはなく、インシデント時に脆弱な統合を維持する必要もなく、ワークフローを調整するための別のチームもありません。YAMLで作成されたワークフローは、HTTP経由で他のシステムを呼び出すことができるため、ネイティブ環境をあきらめることなくプラットフォームの利用範囲が広がります。特にVisaの場合、これは重要な意味を持ちます。現在、別の自動化チームが、セキュリティデータとは異なるプラットフォームでのSOARスタイルのオーケストレーションを担当しています。そのチームはすでにElasticへのAPIアクセスをリクエストしており、サイバーセキュリティエンジニアリングチームは、現在他のツールで行われている対応作業をWorkflowsで吸収する準備ができています。Visaの社内では、単一のネイティブ自動化プラットフォームに統合するという取り組みは、もはや理論上の話ではありません。
アナリストの専門知識にばらつきがある場合の標準化
最も目に見える成果はスピードですが、運用上重要な成果は一貫性です。メインフレームログの解釈は、以前はVisaのトリアージの中で最も変動の大きい部分の1つでした。経験豊富なアナリストは2次クエリーの作業を迅速に完了できましたが、経験の浅いアナリストやメインフレームイベントコードにあまり馴染みのないアナリストは、はるかに長い時間を要し、より変動の大きい結果を生み出しました。
「レガシーなクエリ言語に精通した、より経験豊富なアナリストは、すぐに答えを見つけることができました。これはより経験の浅いアナリストにとっては、難しいところでしょう。一般的に、彼らはメインフレームのログにあまり詳しくありません。単純に、専門性が違うのです。質の違いが出てくるのはその点で、まさにそこにAIの真価が発揮されると考えました。AIを使えば、物事を素早く明確にすることができるでしょう。」
アセンブリとサマリーをパイプラインにプッシュすることで、レガシークエリ言語やメインフレームイベントコードに関するアナリストの熟練度に依存していたワークフローの部分は、もはやアナリストの仕事ではなくなりました。IRエンジニアは体系的な要約を読み、行動を起こすべきかどうかを判断します。
実際の運用モデル
検出自体はめったに発生せず、過去には年に数回しか起こっていません。これは意図的なものです。チームがそれを選択したのは、これが低頻度で重要度の高いアラートであり、手動による2次クエリごとのコストを削減する価値が明確にあったからです。より重要な点は、これがVisaにとって初めての本番ワークフローであり、確立された4段階のパターンが他の検出にも適用可能になったことです。
「以前はアラート1件につきアナリストが10分から20分かけて作業する必要があったものが、今では数秒で完了します。IRチームは、調査開始を必要とする生シグナルを受信しなくなりました。彼らは意思決定の準備が整っている全面的に文脈化されたアラートを受け取っています。」
このアラートが発生したときに、現在VisaのIRエンジニアが見ているのは、名前が付けられてIDで識別でき、元のイベント、識別されたユーザー、理由、および基礎となるデータへのリンクを含むチケットです。パイプラインが2次クエリーを実行し、LLMが検証して要約し、Webhookがチケットを作成しました。エンジニアの最初の行動は、クエリ構成ではなく判断です。
意思決定者は依然として人間です。パイプラインが組立を行い、AIが検証と要約を行います。エンジニアは、エンジニアにしかできないことを行います。それは判断し、検証し、必要に応じてエスカレーションすることです。上流に押し上げられる作業は、再現可能な作業です。エンジニアに残される作業は、判断力を必要とする作業です。
ビフォーアフター
| 導入前 | 導入後 | |
|---|---|---|
| アラート管理 | ユーザーを特定するために、追跡調査を必要とする生イベント | 意思決定の準備が整えられ、強化された、AIによって要約されたチケットがIRに到達 |
| 運用コスト | 2回目の検索作業およびメインフレームログの解析で、1回のアラートあたり10～20分 | 全工程が秒単位 |
| 調査の流れ | アラート後、別のツールで2次クエリーを実行 | 単一の連鎖したワークフローで検出、強化、検証、提供 |
| アナリストのスキルとの依存関係 | 経験豊富なアナリストは迅速に対応できる一方、従来のクエリ言語とメインフレームのイベントコードにより、経験の浅いアナリストは処理が遅くなります。 | 体系的な要約は、レガシークエリ言語への習熟度依存を排除します。 |
| ツールの限界 | レガシーSIEMでのアラート、レガシーSIEMでのフォローアップ、別のオーケストレーションツールでのチケット | 検出、強化、検証、配信はすべてElasticにネイティブで、IRチケットシステムへのWebhookハンドオフも可能 |
| アナリストの役割 | 手動コンテキスト収集、2回目の検索実行、メインフレームログの解釈 | 体系的なケースを読み、結果を判断し、エスカレーションする |
4段階パターンが教えてくれること
これがVisaの最初のWorkflowプロジェクトですが、最後のプロジェクトにはならないでしょう。4段階の構成が汎用的だからです。今回の検出は固有のものです。しかし、その周辺の運用パターンは違います。アナリストの対応前に、検出が既知かつ繰り返し可能なフォローアップ検索を必要とする場合は、いつでも同じ4つの段階を応用できます。
「彼らにとって、それはランブックの一部です。パイプラインは最初のステップを実行し、IRチームの調査対象から不要な工程を排除します。」
このビルドから転送された3つの原則は、2次クエリーがボトルネックとなるあらゆる検出に適用できます。ランブックの既知の部分をパイプライン内で自動化します。フォローアップが常に同じ方法で実行される場合、それはアナリストの仕事ではありません。AIステップには監査可能な範囲で仕事を与えてください。制約されたプロンプト、構造化されたインプット、エンジニアがデータと照合して検証できる要約です。コンテキストを区切り、モデルがクエリが返した全データではなく、イベントの時間に関連する情報のみを受け取るようにします。最初の原則が最も汎用性があります。残りの2つはAIの説明可能性を維持するものです。
次のステップ
検出、強化、検証、配信の4段階パターンは移植可能です。チームは移行範囲内の他の検出についても、同じ連鎖的な、AIで要約した、Webhookで配信する手法の恩恵を受けられることをすでに特定しています。チームはAttack Discoveryを積極的に評価しており、マーティン氏によれば、この機能こそが彼らがそもそもElasticに惹かれた理由だと言います。順序付けは明確な意図を持って行われました。WorkflowsによってVisaは、全面に定量化・検証可能パターンを確立し、その後、より多くの相関ロジックを内部で実行する機能に拡張しました。これは、規制対象の金融サービスSOCにとって適切な方法です。チームは、並行して脅威ハンティング用のAIエージェントを構築しており、現在別の自動化グループが処理している対応作業をWorkflowsがどのように吸収できるかを検討しています。Elasticのリリース頻度に遅れずに追いつくことも、今の仕事の一部です。
「Elasticが次々と新しいものをリリースするせいで、私はすっかり気が多くなってしまうんです。」
「Attack Discoveryは、おそらく我々のリストのトップに入っています。私たちがElasticに惹かれた理由は、ワークフローではなく、Attack Discoveryの機能でした。私たちはこのツールをAIファーストのSIEMとして売り込み、Visaのサイバー部門の多くのグループに、Elasticを広めようとしています。」
Visaは世界最大の決済ネットワークの1つであり、そのセキュリティ業務のスケールはそれを反映しています。お客様の組織は現在、Visaほどの規模で移行しているわけではないかもしれませんが、最初の検出を転換していたり、総合的なSOCを再構築している場合は、同じ原則が適用されます。アラートがアクションを取る前に2次クエリーを必要とする場合、パイプラインは不完全であり、4段階のパターンはあらゆる規模のステップで機能します。
Elastic Workflowが検出パイプラインの上流で調査を進める方法をご覧ください。