SOARツール：評価の方法と、適切なセキュリティオーケストレーションプラットフォームの選び方
SOARツール、すなわちセキュリティオーケストレーション・自動化・対応のプラットフォームの購買判断は、誤った基準で下されがちです。ベンダーが洗練されたフィッシング対応のプレイブックをデモし、インテグレーションのカタログには400のロゴが並び、評価チームは好印象を抱いて帰ります。その18か月後、同じチームは、足元で変わり続けるAPIに対して30本のプレイブックを動かし続けるために、専任のエンジニアを一人張り付けています。
デモと運用の現実とのあいだにある隔たりは予測できるものであり、何を試すべきかを知っていれば評価の段階で測ることができます。ここからはそのためのフレームワークと、そもそもSOARプラットフォームを買わないことが正解である場合についての率直な議論をお伝えします。
インテグレーションの数は虚栄の指標です
どのベンダーもインテグレーションの数を宣伝します。しかしその数字はほとんど何も語りません。インテグレーションは深さが大きく異なるからです。「対応済み」のインテグレーションが、読み取り専用のアクションを3つ提供するだけのこともあれば、ベンダーのAPI全体を双方向同期とともに提供することもあります。
これを現実的に見極めるには、想定しているプレイブックを、MITRE ATT&CKのうち自社が最も重視するテクニックに対応づけ、必要な対応アクションのそれぞれが、頼ろうとしているコネクタに存在するかを確認することです。
これは具体的に検証してください。プレイブックが最も多く触れる5つのシステムを選び、それぞれで利用できるアクションをすべて列挙するようベンダーに求め、PoCの期間中に自社テナントに対して2つを実際に動かして見せてもらいます。封じ込めは書き込み操作に依存するため、読み取りだけでなく書き込みが必要なアクションについて明確に確認してください。そのうえで、インテグレーションが対応していないアクションが必要になった場合どうなるかを尋ねます。その答えが、自社でカスタムコードを書くことになるのか、そしてそれがどれほどの負担になるのかを決めます。
二つ目の問いは、誰がそのインテグレーションを保守するのかです。ベンダーが保守するコネクタは、上流のAPIが変わったときに更新されます。コミュニティが保守するものは、更新されることもあります。自社で作ったものは、永久に自社のものです。大手プラットフォーム提供者で大きなAPIバージョン変更があった際の、コネクタ更新に関するベンダーの実績を確認し、顧客にどのように通知されたかも尋ねてください。
SOARツールのオーサリングモデルが、保守コストを決めます
SOARツールは一般に、ビジュアルなドラッグ&ドロップのビルダー、コードファーストのインターフェース、あるいはその両方を提供します。この選択は評価の段階では見た目の問題に見えますが、実際には長期的なコストを左右する最大の要因になります。
ビジュアルビルダーは、開発者ではないアナリストにとっての敷居を下げます。プレイブックが3本のうちは、これは確かな利点です。しかし30本になると、独自形式のJSONとして保存されたビジュアルなグラフは、差分を取ることも、レビューすることも、テストすることも、全体像を把握することも非常に難しくなります。コードファーストのオーサリングは、バージョン管理、コードレビュー、ユニットテストをもたらしますが、その代わりにPythonを書いて保守できる人材を必要とします。
尋ねる価値があるのは、プレイブックを人がプルリクエストで読めるテキスト形式にエクスポートできるか、本番に触れずに記録済みのアラートに対してプレイブックを実行できるテスト環境があるか、そしてステージング環境から変更を昇格できるか、という三点です。この三つすべてにきちんと答えられるベンダーはまれであり、その答えは、そのプラットフォームが2年目にどう持ちこたえるかと強く相関します。
上流のAPIが変わったときに何が起きるか
これはSOARプラットフォームの評価において最も有効な診断的質問ですが、ほとんどの評価チームは決して尋ねません。
ベンダーがエンドポイントを廃止したりフィールド名を変更したりしたとき、自社がどれだけ影響を受けるかは三つの要素で決まります。コネクタが大きな音を立てて失敗するのか、それとも静かに失敗するのか。プラットフォームがステップごとの失敗率を、実際に目を通すダッシュボードに表示するのか。そしてベンダーがどれだけ速く更新されたコネクタを出すのか。危険なのは静かな失敗です。例外を捕捉して処理を続けるプレイブックは、実行されなかった補強情報をもとに、ケースを無害として閉じてしまうからです。
実行状況を監視する画面を見せてもらってください。実行回数の合計だけでなく、プレイブックの失敗率でアラートを出せるかを尋ねてください。失敗したステップが既定でワークフローを停止させるのか、それとも素通りするのかも確認します。ベンダーがこれを実環境で見せられないのであれば、使える形では存在しないと考えてください。
ケース管理、承認、そしてアナリストの体験
注目が集まるのはオーケストレーションエンジンですが、アナリストが時間を過ごすのはケース管理の画面です。ここは独立した製品として評価してください。補強で得られた情報がケースの中に読みやすい形で収まるのか、それとも生のJSONの壁として現れるのか。タイムラインは、自動化が何をなぜ行ったのかを示すのか。アナリストはコンソールを切り替えることなく、ケースの中から手動のアクションを実行できるのか、といった点を見ます。
承認のワークフローも同じだけの精査に値します。NIST SP 800-61の対応フェーズに対応づけ、封じ込め、根絶、復旧の各アクションにそれぞれ定められた権限があるようにしてください。承認が深刻度だけでなくアクションの種類でも振り分けられるか、担当者が普段使っている場所に届くか、そして保留中の承認にタイムアウトと定められたフォールバックがあるかを確認します。タイムアウトのない承認ゲートは、深夜3時に永遠に止まったままのプレイブックです。
もう一つ、誰もプレイブックを書かなかったアラートをそのプラットフォームがどう扱うのかという問題があります。多くの導入では、それが大多数を占めます。それらが単に人の処理待ちの列に並ぶだけであれば、アナリストの処理能力をめぐるSOCの課題は何も動いていません。
価格モデルと、コストが隠れる場所
よくある価格モデルは三つです。ユーザー単位、アクションまたは実行単位、そしてプラットフォーム一括のライセンスです。実行単位の課金は公平に聞こえますが、ゆがんだ動機を生みます。支出を抑えるためにチームが自動化を出し惜しみするようになり、それは目的と正反対だからです。ユーザー単位の課金は、SOCのより多くのメンバーをツールに引き入れることに罰を与えます。
どのモデルであっても、ライセンス費用が最大の項目になることはめったにありません。多くのチームが最終的に雇うことになる導入パートナーの費用、プレイブックを構築・保守するエンジニアリングの時間、そしてベンダーが対応していない自社環境のツール向けのコネクタ開発を見込んでおいてください。有効な現実確認として、プレイブックの保守に費やされるエンジニア一人分の時間を人件費として概算し、ライセンス費用と比べてみることです。その比率に驚いたのであれば、その比率こそが要点です。
支出に対する効果は、プレイブックの本数ではなく封じ込めの速さで捉えてください。IBMのデータ侵害のコスト調査は、特定と封じ込めが速いほど侵害にかかるコストが明確に低くなることを繰り返し示しています。予算が実際に買っているのは、その成果です。
買うか作るか、そしてSOARが答えにならない場合
汎用のワークフローツールの上に自前で構築するのは現実的な選択肢であり、大規模なチームの中にはそれをうまくやっているところもあります。すでにプラットフォームエンジニアがいて、商用のコネクタでは合わないほど自社の環境が特殊で、かつ担当者を立てて一つのプロダクトとして保守し続ける覚悟がある場合には理にかなっています。うまくいかなくなるのは、それが誰か一人の片手間の仕事になったときです。
また、候補に挙がっているSOARツールのいずれも適切な買い物ではない、という状況もあります。
- アラートの量が十分に少なく、文書化された少数の手動ランブックと優れたチケットシステムのほうが役に立つ場合。
- 検知の質が低い場合。この状態で対応を自動化すれば、ノイズを減らすどころか増幅させることになります。
- 基盤となるツールに、実行したいアクションに必要なAPIが備わっていない場合。オーケストレーション層に、指揮する相手がいないことになります。
- 本当のボトルネックが実行ではなく調査にある場合。これは最もよくあるケースであり、SOARが最も苦手とする領域です。
この最後の点が決定的です。アナリストが遅いのは、コンソールをクリックして回っているからではなく、曖昧な証拠について推論しているからだとすれば、決定論的なプレイブックエンジンは助けになりません。これは検知と対応を比べるSIEMとSOARの議論とは別の問いです。ここで問われているのは、自動化したい仕事がルールとして表現できるかどうかです。
Verizonのデータ漏洩・侵害調査報告書（DBIR）は、侵害のうちどれほど大きな割合が人的要素と認証情報の悪用に関わるかを、毎年繰り返し記録しています。これらはまさに、調査における判断がコード化に最も抵抗する領域です。
評価においてエージェンティックプラットフォームが位置づく場所
ボトルネックが調査にあるのなら、比較対象は従来型のSOARソリューションの外側まで広がります。Exaforceは、マルチモデルAIエンジンの上に構築されたエージェンティックSOCプラットフォームです。ログ、クラウドの構成情報、コード、アイデンティティ、脅威フィードを解釈するセマンティックモデル、アイデンティティ・資産・拠点のベースラインを学習するビヘイビアモデル、そして推論と動的なワークフローを担うナレッジモデルを備えています。
評価の基準もそれに応じて変わります。コネクタがいくつあるかを尋ねる代わりに、PoCに持ち込んだアラートに対してシステムが自らの推論を示せるか、ExaforceのExabotsが、信頼してオートパイロットに任せられるようになるまでコパイロットモードで動作できるか、そしてAdvanced Data Explorerによってアナリストが自然言語で結論を問いただせるかを尋ねることになります。報告されている成果には、誤検知が最大80パーセント減少、平均対応時間が最大70パーセント改善、SIEMコストが40パーセント削減といったものがあります。SOC自動化プラットフォームの比較では、これらのカテゴリーがどう並ぶのかを扱っています。
まとめ
SOARツールをうまく評価するとは、後になって初めて表面化するものを先に試すということです。実際に使う5つのシステムにおけるインテグレーションの深さ、2年目にもチームが保守できるオーサリングモデル、上流のAPIが動いたときに目に見える形で扱われる失敗、影響範囲に結びついた承認の振り分け、そして自動化を増やすほど課税されることのない価格モデルです。
これらを検証すれば、自社に合うSOARプラットフォームが見つかるか、あるいは制約はそもそもオーケストレーションではなかったと分かるかのどちらかです。後者であれば、より有用な作業は、実際に抱えている調査の課題に対してSOC自動化ツールをどう選ぶかを考えることです。