はじめに
以前のブログ「
SIEMだけで回せないセキュリティー運用を支援する SOARとFederated Searchの世界」では、「SIEMだけで回せない」状況を改善する方法として、近代的なセキュリティー運用のハブであるSOARを構築することを紹介しました。その中で、特に説明なしに「ダイナミック・プレイブック」という用語を使用していました。
SOARプラットフォームは企業や組織のニーズを満たすようにカスタマイズして使用しますが、そのカスタマイズの中心にあるのが「プレイブック」です。
プレイブックは辞書的には「脚本、計画、戦略」などの意味を持つ言葉ですが、IT用語に限定しても言葉が指すものは様々で、手順書やワークフローのようなものであったり、もっと具体的な自動化定義のようなものであったりします。SOARに限っても、製品によってニュアンスが完全には一致していません。
「ダイナミック・プレイブック」は、QRadar SOAR (Resilient) が製品機能を表現するために使ってきた用語ですが、わかりにくい点は否めません。わざわざ「ダイナミック・プレイブック」と言っている以上、ダイナミック
ではない「プレイブック」も存在するということになりますが、違いを一言で説明しにくい面があります。
そこで、このブログでは「ダイナミック・プレイブック」という言葉を、筆者自身の理解をもとに説明してみたいと思います。
トップに戻る
プレイブックとは
SOARにおける「プレイブック」は、各種セキュリティー・ツール等とのオーケストレーションと自動化を実現する一方で、SOCアナリストなど人間が行うタスクを示す必要もあります。そのため、自動化定義やスクリプトのようなものではなく、人間との対話や指示書の要素とツール連携を組み合わせた、ワークフローのようなイメージになります。実際、ほとんどのSOAR製品にはワークフロー機能が搭載されています。
従来 QRadar SOAR (Resilient)では、ルール、条件とアクティビティー、フェーズとタスク、スクリプト、ワークフローなどを構成することで、プレイブックを作成していました。V40.2 以降のバージョンでは、新たに Playbook Designerが搭載され、ルールとワークフローを組み合わせた「プレイブック」という構成要素も追加されています。(それまで「プレイブック」という名前がついた構成要素はありませんでした)
新旧いずれの方法にも共通するのは、「ワークフロー」がプレイブックの中心にあることです。新しい Playbook Designerは、開発の専門家ではない人をターゲットとして想定しており、やはりワークフローを中心に据えたほうが一般的に理解しやすいということでしょう。
トップに戻る
ダイナミック・プレイブックとは
それでは、「ダイナミック・プレイブック」(動的プレイブック) とは何でしょうか。
Resilient V39のマニュアル には、「動的プレイブック とは、インシデントへの対応に使用する一連のルール、条件、ビジネス・ロジック、ワークフロー、およびタスクです」とあります。
つまり、QRadar SOAR (Resilient) で作成したプレイブックは、全てダイナミック・プレイブックなのでしょうか。
一方、
V40のマニュアル(英語版) には、以下のように「以前は動的プレイブックと呼ばれていました」と書かれています。
つまり、新しい Playbook Designer で作成したプレイブックは、もはや「ダイナミック・プレイブック」ではないのでしょうか。
There are two methods you can use to organize your customizations into a playbook:
プレイブックをカスタマイズするために使用できる方法は 2つあります。
- Playbook designer. A graphic-based tool that allows you to define the conditions to trigger the playbook, and organize various customizations into a comprehensive set of actions.
- プレイブック・デザイナー。 プレイブックをトリガーする条件を定義し、さまざまなカスタマイズを包括的な一連のアクションに編成できるグラフィックベースのツール。
- Rules and workflows, formerly referred to as dynamic playbooks. Rules allow you to define the conditions to trigger the playbook and the subsequent activities. Workflows are a graphically designed set of activities you use to create a complex set of actions using various customizations.
- ルールとワークフロー。以前は動的プレイブックと呼ばれていました。 ルールを使用すると、プレイブックとそれに続くアクティビティーをトリガーする条件を定義できます。 ワークフローは、さまざまなカスタマイズを使用して複雑な一連のアクションを作成するために使用する、グラフィカルに設計された一連のアクティビティーです。
|
実際には、そのどちらでもありません。
QRadar SOAR (Resilient) の上で作成すれば、誰がどのように構築しても「ダイナミック・プレイブック」になるわけではありません。どのように作成すればダイナミック・プレイブックを実現できるのかを理解しておく必要があります。
また、一見すると「ワークフロー」そのものである Playbook Designer で作成したプレイブックも、正しく設計すれば「ダイナミック・プレイブック」になります。ただし、一般ユーザーにも操作しやすいGUIであるため、プレイブック作成に関する基本ルールやデザイン方針を決めないまま運用すると、変更困難なプレイブックを量産してしまう可能性は考えられます。
トップに戻る
動的なタスク・リストは特徴の1つにすぎない
QRadar SOAR (Resilient) を知る人が「ダイナミック・プレイブック」の特徴としてイメージするものは、動的にアップデートされるタスク・リストかもしれません。
例えば情報漏えいインシデントの発生時に、「暗号化されている」場合と「暗号化されてなかった」場合によって対応するタスクを動的に変更し、適切な対応を取る必要があります。内部関係者が加担していたのか? 犯罪性はあるのか? なども同様です。
調査が進むにつれて新たな事実が判明する傾向があるインシデント対応において、これは重要な特徴です。
図1. 動的なタスク・リストの例
しかし、ワークフローでタスク・リストの更新ができないわけではありません。
むしろ、ステップごとに新しい「タスク」を「タスク・リスト」に追加することは、ワークフローの基本的な機能です。
ワークフローは手続きを記述するのに適した構造をしており、プログラムのフローチャート図にも似て、手順に関わるロジックの多くを表現できます。
トップに戻る
単一ワークフローの限界
では、ダイナミック・プレイブックを実現するにあたって、ワークフローでは何が足りないのでしょうか。
それは、メンテナンス性とスケーラビリティーです。
多くのSOAR製品は、1つのインシデントごとに1つのワークフローを起動します。
ワークフローにはSOARに必要な様々なロジックを組み込むことができますが、ロジックが複雑になればワークフローも当然複雑になります。
前述のように、インシデント対応では調査が進むにつれて新たな事実が判明する傾向があります。
例えば、インシデント対応を開始した当初はマルウェア感染であるという認識でプレイブックを開始したものの、実は情報を海外へ送信する動作が確認され、個人情報の漏えいが判明。さらにGDPRに関連するデータであったため、GDPRの対応手順も必要になったとすると、これを単一のワークフローで表現することは困難です。
1つのワークフロー内に分岐を作ってあらゆる可能性を組み込んでおくことにも限界があるので、結果としてワークフローごとにインシデント(ケース)を分割するという妥協案にたどり着きます。何月何日以降はあっち、それまではこっち、などと関連データも複数のレコードに分かれてしまい、時間の経過とともに一覧性が悪くなります。
図2. 静的なプレイブック
もちろん、ワークフローの中でもできることはあります。
単一ワークフローがシングル・タスクというわけではありませんので、同時に実行できるタスクは並列表記をしておくことができます。
また、繰り返し実行される部分はサブルーチンのように別のワークフローに分けておき、それを呼び出すことができます。サブ・ワークフローをうまく使うことで、プレイブック全体の流れや順序の理解がしやすくなります。
図3. サブ・ワークフローと並列タスク
ただ、並列実行するタスクを全て最初から洗い出しておくことは難しいですし、サブ・ワークフローに分離しても静的に繋がりを定義された箇所はアップデートが必要になる可能性があるので、ワークフローへのメンテナンスはそれなりに発生します。
このように、メンテナンス性とスケーラビリティーが単一ワークフローの制約となっています。
トップに戻る
ダイナミック・プレイブックを実現する並列ワークフロー
前述のように、QRadar SOAR (Resilient) の上で作成すれば、どのように構築しても「ダイナミック・プレイブック」になるわけではありません。
QRadar SOAR (Resilient) においても、プレイブックを単一のワークフローだけで実現しようとすれば、単一ワークフローの限界に至ります。
QRadar SOAR (Resilient) を特徴づけているのは、ワークフローの並列実行です。それがなければダイナミック・プレイブックの実現は困難であり、製品に同梱されているプレイブックも、並列実行できるエンジンが搭載されていることを前提に設計されています。
QRadar SOAR (Resilient) は、SOARの目的に特化した、ある種のローコード基盤のような側面があります。製品の用意したデータ・モデルと実行エンジンに沿ってプレイブックを作成することで、ダイナミック・プレイブックを実現しやすくなります。
図4. ダイナミック・プレイブック
QRadar SOAR (Resilient) でダイナミック・プレイブックを実現するための重要な要素が、「フィールド」と「トリガー」です。
トリガーは、実際に製品の中でそのような用語が表示されているわけではなく、「ルール」や「プレイブック」の呼び出し/アクティブ化の「条件」がそれに該当します。
「フィールド」は状態管理のために重要な役割を果たしており、このデータを参照しながら必要なプレイブックが次々とトリガーされ、並列実行により必要なタスクをタスク・リストに追加したり、オーケストレーションを呼び出したりします。
「タスク・リスト」は重複排除の機能が働くため、並列実行により各プレイブック内のタスクが重複しても問題ありません。
「フィールド」の中には、「インシデント・タイプ」や「フェーズ」など、QRadar SOAR (Resilient) が最初から用意しているものと、ユーザーがカスタムで作成するものがあります。どちらも「トリガー」の条件として使用できます。
図5. 並列ワークフロー
本来、並列実行されるワークフローにメインもサブもなく、その意味を決めているのはプレイブック全体の設計者です。
単一ワークフローのように、「呼び出し側」というものはなく、呼び出しているように見えて、実際には「状態」を適切な状態にアップデートしているだけです。
呼ばれているように見える方も、呼ばれているのではなく、「状態」を見て「条件」に合致した際に動作を開始しているだけです。
「インシデント・タイプ」など QRadar SOAR (Resilient) が最初から用意しているフィールドは、製品に同梱されているプレイブックが動作する前提になっています。そのため、特に意識しなくても、複数のインシデント・タイプが混在する場合には複数のプレイブックが自動的に並列実行され、タスク・リストが動的にアップデートされます。
自ら設計したプレイブックの場合は、プレイブックのどの部分を1つのワークフローで表現し、どの部分を並列ワークフローに切り出すのかを設計する必要があります。単一ワークフローの制約を克服したダイナミック・プレイブックの並列ワークフローではありますが、プレイブック全体の流れや順序の理解・制御はやや難しくなるかもしれません。複数のタスクを完全に決められた順序で実施させたいなら、1つのワークフローで定義するほうが容易です。(メンテナンス性はともかく)
逆に並列ワークフローの方が、プレイブック設計者が把握しておくべき範囲を限定できる場合もあります。例えば、SOCチームとCSIRTチームがSOARを使用する環境において、SOCチームからCSIRTチームにエスカレーションするシナリオを考えてみましょう。
もし単一ワークフローで実現しようとすれば、条件分岐で対応することになります。重大度によって最初から参画を依頼する場面もあれば、インシデント・タイプや情報漏えいの有無などによって場合分けされることもありえます。ワークフローの様々な箇所で呼ばれる可能性があるので、サブ・ワークフローに分離することも考えるかもしれません。
「状態」管理と並列ワークフローを前提に考えると、別の方法も考えられます。例えば、「CSIRTチームの参画 = Yes/No」というフィールドを用意しておき、このフィールドをトリガーとしてCSIRTチームのプレイブックを呼び出す案です。
呼び出す側はフィールドに書き込むだけであり、そこから先のロジックをワークフロー内で表現する必要はありません。CSIRTチームのプレイブックの名前が変わったり、作り直されたりしても、呼び出す側のワークフローがアクセスするのは相変わらず「CSIRTチームの参画」フィールドだけですので、呼び出し箇所が増えたりしなければ、メンテナンスは発生しません。
呼ばれる側も「CSIRTチームの参画」フィールドや、必要に応じてその他のフィールドとのAND/OR条件でワークフローをトリガーすればよく、呼び出す側のワークフローの細部を気にする必要はありません。
代わりに気にする必要があるのは、「状態」データモデルの適切なライフサイクルであり、両方のワークフローがそれを理解しておく必要があります。
トップに戻る
おわりに
ダイナミック・プレイブックを実現する並列実行は、強力な機能です。しかし、その動作を理解して使用する必要があります。
あまり意識しなくても、「インシデント・タイプ」ごとに複数のプレイブックを並列実行することは容易にできますので、まずはそこから開始しましょう。
そして、複数のプレイブックで共通のタスクがあれば、それを別のワークフローに切り出します。
例えば、「図1. 動的なタスク・リストの例」の右側下方の黒い矢印には、「フィールド更新：犯罪または不正あり」と書かれています。
この例は、「状態」を表すフィールド「犯罪または不正あり」を「Yes」に設定したことによって、別のワークフローがトリガーされるダイナミック・プレイブックの仕組みになっています。
タスクの順序を重視したい場合は、単に1つのワークフローにロジックを集約するほうが容易なこともあり、QRadar SOAR (Resilient) でも単一ワークフローへの集約は可能です。一方で、単一ワークフローしか実行できないエンジンで並列ワークフローは実現できませんので、幅広いプレイブックの設計余地を考慮すると、ダイナミック・プレイブックは1つの柔軟な選択肢であると考えられます。
新旧のプレイブック定義方法や単一ワークフロー/並列ワークフローが混在しているような環境でも、それらによって呼ばれる様々なタスクが重複排除されながら1つのタスク・リストに統合され、ダイナミック・プレイブックとして動作します。
トップに戻る
参考文献