あなたが選ばなかったSOAR

あなたが選ばなかったSOAR

セキュリティオーケストレーション・自動化・レスポンス（SOAR）プラットフォームが、どのようにして自社のシステム構成に組み込まれたのかを思い出してみてください。それは、特定のニーズに基づいた徹底的な評価の結果、意図的に決定されたものだったのでしょうか？それとも、より大規模な購入の一環として、たまたま導入されたものだったのでしょうか？

多くのセキュリティチームにとって、正直な答えは2番目だ。SOARは選ばれたわけではなく、たまたま導入されたのだ。.

その違いは、一見した以上に重要です。セキュリティ自動化は、アナリストの日々の業務のあり方を根本から変えます。対応の迅速性、拡張性、そしてツール間の連携の円滑さを左右するのです。これほど重要なプラットフォームは、その独自のメリットに基づいて選ばれるべきです。しかし、多くのチームにとって、それは実現していませんでした。.

SOARがバンドルされる理由

よくある流れだ。ベンダーは、SIEM、脅威インテリジェンス、エンドポイント、場合によってはマネージドサービスレイヤーといった、より広範なプラットフォームを提案する。SOARもそのプラットフォームに組み込まれている。調達チームは、契約内容が簡潔になり、管理すべきベンダーも少なくなることに気づく。書類上は理にかなっているように見える。そこで、契約条件にチェックが入る。SOARも一緒に導入されるのだ。.

誰も腰を据えて、その特定の自動化エンジンが環境に最適かどうかを議論しなかった。誰もそれを他の選択肢と比較検討しなかった。決定はパッケージ全体に関するものであり、SOARは単なるおまけだった。.

これは、これらのツールの背後にあるエンジニアリングを批判するものではありません。Palo Alto XSOAR、Splunk SOAR、FortiSOARはいずれも、優秀なチームによって開発された優れた製品です。しかし、これらのSOARプラットフォームは当時こそ素晴らしかったものの、ここ数年は改良が加えられておらず、今日の脅威に対応できるような設計にはなっていません。.

誰も声に出して読まない4つのトレードオフ

どのバンドルも、あなたが明示的に同意したことのない一連の妥協の産物です。それらはプレゼンテーション資料には記載されていません。後になって、日々の業務運営の中で明らかになります。引き継がれた適合性。SOARが大規模な取引の一部である場合、それはあなたの特定のワークフローではなく、ベンダーの販売に合わせて最適化されています。ツールがあなたに適応するのではなく、あなたがツールに適応することになります。時間が経つにつれて、あなたのチームはその限界に合わせてプロセスを構築し、その限界を当たり前のこととして扱うようになります。.

1. SOARエコシステムの偏り。. 

バンドル型SOARは、親プラットフォームとの関係を強化するように設計されています。ベンダーのエコシステムには美しく統合されますが、それ以外の部分では明らかに柔軟性に欠けます。ベンダーが推奨する統合は、自社製品の販売促進につながるものが多い傾向があります。しかし、実際のセキュリティ運用は単一のベンダーだけで行われるわけではありません。ほとんどの環境は複数のソースからリソースを調達しており、そのうちの1つを優先するSOARは、残りのソースを後回しにしてしまうのです。.

2. 従来のSOARでは柔軟性が低下していました 

半日あれば済むはずの変更作業に専門家が必要になる場合がある。アップデートはベンダーのスケジュールで進められ、あなたのスケジュールとは合わない。あなたが最も構築したい自動化が、プラットフォームのせいで最も実現が難しい場合もある。これらはどれも劇的なことではない。チームの時間と意欲をじわじわと奪っていく、地道な負担なのだ。.

3. SOARバンドルによるベンダーロックイン 

契約時にほとんど話題にならない点があります。閉鎖的なエコシステム内で構築するプレイブックが増えるほど、そこから抜け出すのが難しくなります。統合、ワークフロー、依存関係が増えるたびに、考えを変えるコストが増大します。パッケージは導入しやすいものです。その使いやすさこそが戦略なのです。本当に重要なのは、導入の容易さではなく、3年後にどれだけ身動きが取れなくなるかということです。.

4. 今は便利なSOARが、後々制約となる

バンドル化は調達上の問題を解決します。ベンダー管理を簡素化し、契約を整理します。これらは紛れもないメリットであり、それだけの価値があります。.

しかし、調達の利便性と運用上の現実は全く別物です。役員会では更新を容易にする決定でも、SOC（セキュリティオペレーションセンター）では事態を複雑にする可能性があります。購入されたものと実際に必要なものとのギャップを最も痛感するのは、アナリストたちなのです。.

こうして「十分使える」自動化は、チームの能力の限界を静かに押し上げてしまうのです。付属のツールは壊れているわけではありません。ただ、誰も疑問に思わない程度に機能するだけです。その間、チームは回避策を講じ、制約を当然のこととして受け入れ、自分たちを中心に構築されたプラットフォームが実際に何ができるのかを徐々に忘れていきます。.

SOARの再評価に関する率直な考察

いくつかの質問が、その目標達成に役立つでしょう。

• 貴社のSOARは、フルスタック全体にわたってスムーズに自動化を実現していますか、それとも特定のベンダーのツールのみを対象としていますか？
• 有意義なワークフローを構築または変更するにはどれくらいの時間がかかり、誰がそれを行う必要があるのか？
• もしあなたが辞めたいと思った場合、これまで築き上げてきたもののどれくらいをゼロから再構築しなければならないでしょうか？
• このプラットフォームは、単独で勝負しなければならないとしたら、あなたの環境で採用されるに値するでしょうか？

より良い未来への道

ここは スイムレーンタービン 何が起こり、なぜ私たちがその問題について異なる考え方をするのか。.

Turbineは、設計上、ベンダーに依存しません。特定のエコシステムを強化したり、特定のベンダーの製品をより多く購入するように促したりするために作られたものではありません。Turbineは、実際に存在する環境、つまり、多様なソースからのツールが混在し、進化し続ける環境をオーケストレーションするために作られています。自動化は、ベンダーのロードマップではなく、お客様のスタックに沿って行われます。.

そのオープン性こそが重要な点です。自動化のアプローチが特定のプラットフォームに縛られないことで、選択肢を広げ、迅速に適応し、承認された部分だけでなく、実行するすべてのものを連携させることができます。.

もし、移行によって既に作成したものをすべて再構築しなければならないのではないかと心配されているのであれば、それはもっともな懸念です。しかし、私たちはその問題を解決しました。Swimlaneは、現在お使いのプラットフォームから最大90%の既存ワークフローを移行できます。面倒な作業はほぼ開始前に処理されるため、気が変わっても最初からやり直す必要はありません。.

SIEMは自分で選びました。エンドポイントツールも自分で選びました。ですから、環境のオーケストレーション方法についても、そのメリットに基づいて、環境に合わせて、自分の条件で選択できるべきです。.

だから、自分自身に正直な問いを投げかけてみてください。そして、あなたのチームが本当にふさわしいものは何なのかを判断してください。.