内容
はじめに
以前のブログ「SIEMだけで回せないセキュリティー運用を支援する SOARとFederated Searchの世界」では、SOARの必要性と価値について記しました。1つのSIEMに全てのイベントやアラートを集約できる場合も、あるいはハイブリッド・マルチクラウド環境においてSIEMへのログ集約が困難な場合も、インシデント対応においてSOARは重要な役割を果たしています。
また、ブログ「並列ワークフローが可能にするSOARダイナミック・プレイブックの作り方」では、「ダイナミック・プレイブック」の本質であるプレイブックの並列稼働について記しました。
今回は、より具体的なプレイブックの作成方法について取り扱います。
トップに戻る
プレイブックの作成単位
新しいプレイブック開発ツールであるPlaybook Designerが進化したことで、GUIからプレイブックの複製やエクスポート・インポート、引数付きのサブプレイブックなどの新しい要素を利用できるようになりました。
これにより、1つのプレイブックに多くのロジックを詰め込んでも、可視性を保ちながらインシデント対応タスクを整然と組み込むことができます。
一方で、並列ワークフローの実行エンジンは健在ですから、プレイブックを複数に分けて作成し、実行時にダイナミックに連携することもできます。
実際、QRadar SOARに標準で組み込まれているプレイブックでは、「DOS攻撃」、「マルウェア」、「フィッシング」、「システム侵入」、「TBD/不明」の5つのプレイブックとは別に、共通の処理を「General」というプレイブックに分離して記述しています。これにより、重複する要素を5つのプレイブックに何度も記述することなく、「General」プレイブックにまとめておくことができます。
このように、プレイブックは細かい単位で別々に作成することも、1つのプレイブックに全体のフローを記述することもできます。
以下に、ベースラインとなる基準を示します。
-
- 外部サービス(関数)の呼び出し (SIEMの検索、ITSMチケットのオープンなど)
- タスク(人間への指示)の追加
- 条件分岐、タイマー呼び出し、などのワークフロー制御
「同期処理」についても、必要に応じて別のプレイブックに分割することができます。
例えば、メインのプレイブックから特定のフィールドにTrueを設定することで別のプレイブックをトリガーしたり、別のプレイブックがフィールドに書き込んだ値をメインのプレイブックから読み取ったりすることができます。
ただし、メインのプレイブックから別のプレイブックをトリガーすることは容易ですが、別のプレイブックの処理完了を待って戻り値を受け取りたい場合は、少々面倒になります。そのようなユースケースでは、シンプルに「サブプレイブック」という機能を使って構造化することをお勧めします。
トップに戻る
SOARの外部連携
SOARを構成する重要な要素の1つが、外部システムとの連携です。
以前のブログでは、単に「オーケストレーション」という言葉で表現していましたが、今回はプレイブックを作成していきますので、より具体的な部分に踏み込む必要があります。
SOARは各種セキュリティーツールの「ハブ」であるため、様々な製品との接続機能である「関数」や「脅威ソース」を持っています。
「関数」は、外部システムに対するAPIやコマンド呼び出しの機能をラッピングしたもので、パラメーターを与えて処理の結果を受け取ります。上図のほとんどの接続は、「関数」によって実現されています。
「脅威ソース」は、外部の脅威インテリジェンス・サービスを呼び出して、アーティファクト(IOC: Indicator of Compromise)のリスク・チェック機能を提供します。IBM X-ForceのようにQRadar SOARに組み込まれているものと、スクリプト経由で「関数」を呼び出すものに大別されます。
トップに戻る
外部連携機能の実行基盤
「関数」の実体となるPythonコードはSDKで作成された「アプリ」であり、Edge Gateway (または App Host) と呼ばれるコンテナーベースの実行基盤の上で動作します。各アプリはコンテナーで分離されているため、相互干渉することなく安全に実行されます。
アプリはApp Exchangeサイトからダウンロードして、簡単な手順でインストールできます。執筆時点で、300 を超えるSOARのコンテンツがApp Exchangeで公開されています。IBMidでログインすることで、様々なアプリを無料でダウンロードできます。
アプリには、関数の本体だけでなく、それを活用するためのインシデント・フィールド、スクリプト、データテーブル、プレイブックなどが含まれており、すぐに利用を開始できます。
トップに戻る
LDAP連携アプリの例
一例として、LDAP and Active Directory Functions for SOARを見てみましょう。
このアプリは、SOAR プラットフォームのプレイブックから外部LDAPサーバーに対して検索、更新、パスワードの設定などを行うことができます。
まず、「関数」として、LDAP Utilities: Add、LDAP Utilities: Add to Group(s)、LDAP Utilities: Search、LDAP Utilities: Set Password などが用意されています。
UIから見えるラッパーが「関数」であり、実体となるPythonコードは、Edge Gateway内のコンテナーで動作します。
多くのアプリにとって、「関数」が最も重要な要素であることは確かですが、これだけでは動作せず、必ずプレイブックから呼び出す必要があります。各「関数」固有のパラメーターに適切な値を与えて、戻り値を適切に加工するなど、正しい使い方を知る必要があります。
「関数」の使い方については、App Exchangeの「文書」欄にある「表示」というハイパーリンクからダウンロードできるPDF文書に記述されています。
この文書は英語であり、日本の技術者には少し難読です。また、PDFから定義類をコピー・アンド・ペーストすると、特殊な文字コードが混入するなどの事故がしばしば発生します。
そこで、アプリに同梱されているサンプル・プレイブックを活用してください。
例えば、LDAPアプリには「Example: LDAP Utilities: Search (PB)」というサンプル・プレイブックが含まれています。
トリガー(アクティブ化の詳細)については後述しますが、このプレイブックは手動で呼び出すメニュー項目となっており、呼び出し時に表示される入力フォームから、LDAPドメイン、LDAPサーチベース、LDAPフィルター、LDAP属性をインプットすると、それがそのまま「LDAP Utilities: Search」関数のパラメーターとして渡され、LDAPの検索が行われるようになっています。
関数の後処理をしている「post-process」はPythonスクリプトで、「LDAP Utilities: Search」関数からの戻り値を処理します。
このスクリプトでは、戻り値を「ldap_query_results」というデータテーブルに格納しています。
このデータテーブルもアプリに含まれており、関数と一緒にインストールされます。
このように、アプリのパッケージには、機能を実現するために必要なパーツが揃っています。
| NOTE: 「プレイブック」を作成するためのPlaybook Designerツールは、ここ数年で急速に機能を成熟させてきたツールです。そのため、過去に作成されたアプリの中には、「プレイブック」形式のサンプルを含んでいないものがあります。 それらのアプリには、代わりに「ルール」+「ワークフロー」形式のサンプルが含まれており、「プレイブック」形式で作り直すことが可能です。(今のところ変換ツールは用意されていないので、手作業でスクリプト部分をコピー・アンド・ペーストするなどの作業が必要になります) |
トップに戻る
プレイブック開発の概要
各プレイブックは、Playbook DesignerというGUIツールを使用して作成できます。タスクやスクリプトなど、プレイブックの中で参照されるほとんどのコンポーネントを、同じ画面の中から作成できます。
(「インシデント・タイプ」など、一部でカスタマイズ・メニューから作成するものもあります)
直感的なGUIベースのツールを使用ことで、プレイブックの作成・編集の複雑さを軽減し、Python コーディングが必要な箇所を減らせます。これにより、短時間でSOARプレイブックを作成できるようになります。
トップに戻る
プレイブックの起動方法
プレイブックは、様々なトリガーによって呼び出すことができますが、「自動」と「手動」に大別されます。
自動プレイブックは、予め設定したトリガー条件を満たすことで、直ちに実行されるプレイブックです。そのため、条件の指定は必須項目となっています。
一方の手動プレイブックは、有効化してもそのままでは実行されません。必ず人間がGUIのメニューから呼び出す必要があります。条件指定もオプションであり、指定しなくても構いません。
手動プレイブックで条件を指定した場合は、メニューにプレイブックを表示するかどうかを制御できます。条件を指定しない場合は、常にメニューに表示されます。
トップに戻る
インシデント対応の流れとプレイブック
「プレイブックの作成単位」で説明したように、インシデント対応に関わるプレイブックは1つではありません。必要なタイミングで、様々なプレイブックを起動します。
以下の図は、インシデント対応のステップごとに、異なるプレイブックを呼び出すイメージで描かれています。(自動・手動は問いません)
-
ケース作成
- ケース作成時には、「インシデント・タイプ」(「マルウェア」「システム侵入」「フィッシング」など)を割り当てることがよくあります。このインシデント・タイプをトリガーとして、インシデント対応全体の流れを規定する「メインのプレイブック」を呼び出す設計がよく行われます。
- インシデント対応を開始する時点で、ケースの所有者やメンバーなどを自動で設定することもよくあります。組織全体で割り当てのロジックを一箇所で管理したい場合、このプレイブックをメインとは別の小さなプレイブックとして切り出すことができます。
(あるいは、サブプレイブックを作成してメインのプレイブック内に配置したり、処理が1つのスクリプトで完結する場合は、グローバル・スクリプト化して各プレイブックから呼び出したりする方法も考えられます。いずれにしても、ある程度の大きさを持つロジックは、保守性を考慮して一箇所で保守できるように実装しましょう)
-
分析
- ケース作成後に行う典型的な処理が、IOC(Indicator of Compromise)の分析です。SOARでは、IOCを「アーティファクト」というモデルで管理しています。
このアーティファクトは、ケース作成のタイミングで自動的に追加されることが多く、例えばEメールの受信をトリガーにケースを作成する場合、そのEメールの本文に含まれるテキストから自動的にIPアドレスやドメインなどが抽出され、アーティファクトに登録されます。(動作はカスタマイズできます)
また、SIEMやEDRからケースを作成する場合は、検知時に識別されたIOCがアーティファクトに追加されます。
- アーティファクトは、ケース作成後の別の処理で追加されたり、インシデント関係者に対するヒアリング結果などを、人間がGUIから手動で追加したりすることもあります。
- アーティファクトが追加されると、SOARに内蔵された脅威ソース(脅威インテリジェンス・サービスへの接続)への検索リクエストが自動的にトリガーされ、レピュテーション情報にヒットした場合はアーティファクトの記録に反映されます。
また、アーティファクトが追加されたことをトリガーとして、独自のプレイブックを呼び出すことができます。例えば、Eメールアドレスやユーザー名が追加された場合に、社内のLDAPやCMDBなどを自動検索し、該当社員のアカウント有無を確認するなどの使い方が考えられます。
- 最新のQRadar SOARにはUnified Analyst Experience (UAX)が実装されており、アーティファクトの情報とケースに含まれる日時の情報から、SIEMやEDRをルールとAIで自動調査(自動的に検索を実施)する機能があります。
この仕組みはプレイブックではありませんが、アーティファクトの自動チェックのタイミングと重なりますので、メインのプレイブックの対応フローを検討するにあたって、考慮しておくとよいでしょう。(例えば、以下の「脅威判定」でアーティファクトが脅威インテリジェンスにヒットしたかどうかを確認する場合、同じタイミングでUAXの自動分析結果も確認するなど)
-
脅威判定
- 脅威判定は、自動的に判断できるものを除いて、人間が行う必要があります。
- 自動的に判断できる例としては、例えばEDR製品が隔離を推奨するほど確度の高いアラートを出した場合(かつCMDB等で対象マシンがサーバーではなく端末であるなどの判断材料が揃う場合)や、複数の脅威インテリジェンス・サービスでアーティファクトのIOCが1件もヒットしなかった(あるいは低リスクであった)場合などが考えられます。
前者の場合は必要な対応を実施するフェーズに進みますし、後者の場合は過剰検知として自動的にケースをクローズするような選択肢があります。
- 自動で判断できないものは、その後の「調査」につながるフローとして、人間の判断を促す「タスク」を生成して通知し、担当者のコミュニケーションの履歴や、その後の「対応」につながる意思決定の結果を、SOARのデータとして残すようにします。SOAR内部にデータがあれば、それをトリガーとして別のプレイブックを起動したり、プレイブックのフローを分岐したりすることができます。
-
調査
- タスクは電子的な「指示書」ですので、誰が担当しても均質なインシデント対応ができるように、具体的な情報を記しておきます。
- ケース作成時と同様に、「タスク」の所有者や有効期限などを自動的に設定するためのプレイブックを、独立して用意することがあります。それ以外でも、タスクの追加をトリガーとして、個別のプレイブックを開始することができます。(各プレイブックは並行稼働します)
- 「脅威判定」の段階でシロと判断できなかったものも、「調査」で最終的にシロと判断される可能性があります。また、クロの場合は、この後の「対応」を行う際に必要な影響範囲などを調査する必要があります。
-
対応 および 自動対応
- 発生したインシデントが環境にインパクトをもたらすものであった場合、つまり誤検知ではなかった場合、何らかの対応をとる必要があります。これは、「SOARの外部連携」で説明した「③改善策の呼び出し」に該当する部分です。
- 対応が必要な対象が自社の管理するインフラであれば、直接的な連携によって対処を行うプレイブックを組み込むことができます。例えば、問題のあるIOCを境界防御システムの拒否リストに追加して、後続の被害を防止するなどが考えられます。
- もし「脅威判定」において、人間によるアドホックな確認なしに「対応」実施を判断できる場合は、「自動対応」のレベルを実現することができるでしょう。これは、「対応」のインパクトが小さいほど実現しやすく、インパクトが大きくなるほど慎重な判断ロジックを構築する必要があります。例えば、インシデントの被害抑止と社外向けサービス停止を秤にかけて、自動的に適切な判断を行うことは容易ではないはずです。
- 対応が必要な対象が自社の管理対象外であった場合は、関係者へのメール連絡など、間接的な「対応」にとどまることが考えられます。
トップに戻る
プレイブックの主な構成要素
プレイブックは、主に以下の構成要素の組み合わせで作成されます。
トリガー条件
プレイブックがどのようにアクティブ化されるかを決定します。オブジェクト・タイプは、プレイブックが処理するデータのクラスです。(インシデント、タスク、アーティファクト、データテーブル など)
「自動」を選択すると自動プレイブックに、「手動」 選択すると手動プレイブックになります。
条件を指定することで、プレイブックがどのように活動化されるかを定義することできます。自動プレイブックの場合は条件を満たすと起動され、手動プレイブックの場合は条件を満たすとメニューに表示されるようになります。
トップに戻る
タスク
フェーズ別に編成されたユーザーへの「指示書」です。担当者への指示や、フィールドに値を入力するなどの目的で使用します。
コメントや添付ファイルを付けることができ、担当者へのアサインや有効期限の設定ができます。
トップに戻る
関数
「アプリ」に含まれている外部連携機能の単位です。プレイブックから引数を与えて呼び出し、処理の結果を受け取ります。Python の SDKで 独自の関数も開発できます。
トップに戻る
スクリプト
Python3 で記述するスクリプトです。典型的な用途として、「関数」の戻り値の処理などに使用されます。
「ローカル」と「グローバル」の分類があり、ローカルはそのプレイブック内でのみ使用可能です。
製品内部で動作するため、インポートできるライブラリーに制限があります。
(SDKで独自に「関数」を開発する場合、そこで利用可能なPythonライブラリーに制限はありません)
array, base64, bs4, calendar, collections, datetime, email, enum, hashlib, html, html2text, json, random, re, regex, string, time, xml
トップに戻る
サブプレイブック
プレイブック内に含まれるプレイブックです。
サブプレイブックの目的は、タスク、スクリプト、関数を組み合わせて、再使用可能なプロセスを作成することです。複数のプレイブックからサブプレイブックを標準化して利用することで、プレイブックの設計を効率化することができます。
トップに戻る
決定ポイント
プレイブックのロジックに関わるコンポーネントです。
待機ポイント
このポイントに接続された、「全て」の着信パスが完了するまで待機します。(上図は2つのパスから接続されていますが、それより多くても構いません)
条件ポイント
ブール演算子を使用して着信データを評価し、その結果によってアクティブ化する発信パスを決定します。条件ポイントを使用して、着信データの値に基づいて論理的な決定を行うことができます。
終了ポイント
プレイブックの完了を示します。プレイブックには、複数の終了ポイントを含めることができます。
トップに戻る
プレイブック開発の基本的な流れ
ここからは、プレイブック作成と実行の流れを見ていきます。
プレイブックの作成
プレイブックの追加とトリガーの設定
- Playbook Designerで「プレイブックの作成」をクリックし、名前とAPI名を入力します
- 「アクティブ化の詳細」で「アクティブ化のタイプの選択」に「自動」、「オブジェクト・タイプの選択」に「インシデント」を指定します。
- 「条件の作成」を追加し、「インシデントが作成された時」 AND 「インシデント・タイプ」「次を含む」「デモ」を指定して、「追加」します。
トップに戻る
タスクの追加
- 左側のライブラリーで「タスクの追加」をクリックし、新しい「タスク名」「指示」を記入します。
- 「フィールドの追加」をクリックし、新たに「LDAPユーザー」というフィールドとAPI名を定義します。
- 作成した「LDAPユーザー」をタスクのレイアウトにドラッグして配置し、「作成」をクリックします。
- 作成したタスクをキャンバスに配置し、トリガーとタスクを線で結びます。
トップに戻る
関数の追加
- 左側のライブラリーで「LDAP Utilities: Search」をクリックし、キャンバスに関数を追加します。
- 先ほど作成した「LDAPユーザーを探して」タスクと「LDAP Utilities: Search」を線で結びます。
- 「保存」をクリックすると、プレイブックのエラーチェックが行われます。
- 関数の出力名として「output」を入力します。この出力名は、後でスクリプトから値を参照するために使用します。
- 関数の入力フィールドに、対象システムの情報(変化しない固定的な情報)を入力していきます。
- 関数の入力フィールド「ldap_search_param」については、検索条件によって値が変わりますので、固定値ではなく変数からの代入である必要があります。そのために、「プレイブック・スキーマ」の画面で、入力元となる変数を探します。
- ここでは、先ほど「LDAPユーザーを探して」タスクで作成した、「LDAPユーザー」フィールドのAPI名である「ldap_user」を選択します。これにより、「LDAPユーザーを探して」タスクでユーザーが入力した値を、「LDAP Utilities: Search」関数でパラメーターとして利用できます。
トップに戻る
スクリプトと終了ポイントの追加
- 左側のライブラリーで「スクリプトの作成」をクリックし、「ローカル」を選択してスクリプト名を入力します。
- 「プレイブック・スキーマ」を見ることで、関数の戻り値のスキーマを知ることができますので、それを参考にしながら、結果を処理するPythonスクリプトを記述します。この例では、単に結果の配列をループして「注記」に出力しています。
- 作成したスクリプトをキャンバスに配置し、「LDAP Utilities: Search」関数と線を結びます。
- まだ終了ポイントがないため、プレイブックはエラーとなります。左側のライブラリーから終了ポイントを選択してキャンバスに追加し、スクリプトとの間に線を結びます。
- 「保存」時のチェックで全てのエラーが解消したら、「プレイブックの有効化」をクリックしてプレイブックを有効化します。
トップに戻る
プレイブックの実行確認
ケースの作成とプレイブックの自動呼び出し
- プレイブックを実行するために、ケースを作成します。「インシデントの作成」をクリックし、「インシデント・タイプ」に「デモ」、「名前」に「デモンストレーション」を設定します。
- 先ほど作成したプレイブックのトリガー条件：「インシデントが作成された時」 AND 「インシデント・タイプ」「次を含む」「デモ」 を満たしているため、プレイブックが自動的に開始されます。
- 「プレイブックの進行状況」をクリックすると、「デモプレイブック」が実行中であることがわかります。
- 「LDAPユーザーを探して」タスクまで進んだところで保留となっていることがわかります。
トップに戻る
タスクの完了と関数の実行
- タスクリストに「LDAPユーザーを探して」タスクが追加されていることを確認し、クリックして開きます。
- タスクには、コメントを記入したり、コメントに返信したりすることができます。コメントや返信でメンション(@ユーザー名)することもでき、メンションされたユーザーは通知を受け取ることができます。
- タスクには、添付ファイルを付けることもできます。
- 「詳細」タブでは、タスクの所有者や期限を設定することができます。(スクリプトで自動化することが多い項目です)
- 先ほど「LDAPユーザーを探して」タスクで作成した「LDAPユーザー」フィールドに、「khrz」を入力します。入力した値はSOARのケースに格納され、プレイブックから参照可能になります。
「完了してクローズ」をクリックすると、このタスクは完了としてマークされます。
- 「プレイブックの進行状況」を見ると、「デモプレイブック」の全ての処理が完了しています。
- 「注記」タブを見ると、「関数」の処理結果を受け取った「スクリプト」が、LDAPユーザー名に該当する情報を書き込んでいることがわかります。
トップに戻る
おわりに
このブログでは、GUIベースのプレイブック開発の概要について、最初の一歩を踏み出すまでの流れを示しました。
QRadar SOARには多数のアプリが用意されており、その数だけ連携のシナリオがありますし、各企業のユースケースによって、プレイブックで実現したいフローも様々です。組織によって期待される運用レベルも異なっており、SOAR＝自動化という文脈で語られることもあれば、SOAR＝ケース/チケット管理というイメージを持たれていることもあります。
いずれにしても、SOARの根幹であるプレイブックはセキュリティーの運用監視プロセスに密着しており、プロセスの変化に対応していく必要があります。そのため、生産性や保守性も重要であり、段階的に育てていく必要があります。
トップに戻る
参考文献
#qradar#soar