この疑問に対して、Gartnerのケビン・シュミット氏（ディレクターアナリスト）が「CYBERSECURITY DIVE」に寄稿した内容を以下に紹介する（注1）。同氏はセキュリティオペレーションにおいて、GartnerのGTP Secure Infrastructureチームを支援しており、セキュリティオペレーションの領域におけるAI（人工知能）の活用についても研究している。

　シュミット氏によれば、セキュリティリーダーは誤った自動化の他、ユースケースの優先順位付けや自動化すべき対象、その中でどの部分を自動化するのかについて判断に苦しむことがあるという。

　セキュリティの自動化を進めるにはまずユースケースを作り上げなければならない。システムと相互作用するアクター（外部の人やシステム）の特定はもちろん、シナリオや目標をはっきりさせる必要がある。

　ユースケースを作り上げるにはフレームワークが必要だ。このとき、4段階のアプローチに従わなければならない。そうすれば自動化の優先度が高い領域を特定したり、技術者が自動化戦略を構築、展開したりする際の要件を収集できる。

第1段階　事前準備

　第1段階でセキュリティリーダーがまず実行しなければならないのは、自動化の要件を収集することだ。適切な要件がなければ、自動化のための自動化になってしまう。

　何を自動化できるのかを確認するのは、エンジニアにとっても挑戦だ。だが、多くの場合、自動化にかかる費用と労力に見合った結果は得られない。

　その代わり、運用におけるニーズ評価を始めよう。自動化の最有力候補と、候補を自動化するために必要な作業量の特定が目的だ。この段階で収集したデータは後の段階でユースケースを特定、開発、実装する際の指針になる。

　自動化で得られるはずの利益を分析し、成功指標を特定し、採点方法に基づいて候補をランク付けする。

　ユースケースを選定する際の目標は時間の短縮の他、インシデント対応についての予測可能性の向上や対応から封じ込めまでの時間の短縮、既存のスタッフの力を倍増させるようなセキュリティ自動化項目の特定だ。

　最終的な目標はセキュリティオペレーションセンター（SOC）と組織にとっての長期的な成果だ。自動化の目標は戦術的な成果だが、戦略的な成果につなげることを忘れてはならない。

第2段階　ユースケースの選定

　事前準備で自動化の候補リストを作成したら、ユースケースの選定に移る。

　セキュリティリーダーが注意しなければならないのは、事前作業で特定した候補の全てを自動化してはならないことだ。自動化の目標の達成に役立つ重要なタスクを選定しなければならない。

　まず、自社のユースケースについて利益分析を試みよう。自動化による潜在的な利益について社内で共有する際に効果的なのは、基準値に対する改善を示すことだ。分析には時間がかかるため、最初のステップでは自動化の最有力候補に限定して利益分析を始める。

　自動化の最有力候補を決める際、作業に必要な総所要時間の順にリストを並べるとよい。頻度も確認しよう。週に数回ではなく、1日に何度も発生するタスクがあるかどうかを調べる。

　利益分析についてセキュリティリーダーが取るべき6つのステップは次の通りだ。

（1）事前作業で特定した自動化候補を絞り込む　候補があまりにも多い場合、全てを利益分析にかけることは難しいだろう。効果が高い上位5～10個の候補を特定する。おそらく、頻度の高い活動が対象になるだろう。頻度の低い活動には焦点を当てないようにしよう。

（2）各ツールの実際の作業内容を記録する　作業を最も細かい単位で記録し、各作業の実行に必要だと考えられる平均時間を見積もる。

（3）特定した候補の効果を見積もる　作業1回当たりに節約できる時間（またはその他の利益）を見積もる。節約できる時間を導き出す方法は色々ある。過去のデータや経験則に従って推測するか、事前テストした際の実測値を使うことが一般的だろう。

（4）全てのタスクで節約できる時間を合計する　自動化が最大の利益をもたらすような活動の優先順位リストを作成する。このとき、タスクごとの節約時間を特定することが目的だという点に注意してほしい。

（5）1カ月当たりの総利益を見積もる　タスクの実行頻度や手動で実行した際の時間に基づいて計算する。手作業で1時間かかっていたタスクが、自動化によってわずか5分に短縮できるかもしれないが、その作業は月に1回しか起きないかもしれない。このようなタスクを自動化することで本当にメリットがあるかどうかを検討すべきだ。

（6）利益分析レポートを作成する　全ての収集データを統合し、どの自動化を実施するか、どれを保留にするか、どれに手を付けずにおくかについての意思決定できるようにする。

第3段階　自動化とプレイブックの開発

　何を自動化できるのか、どうすれば自動化できるのか、その可能性を探ることは技術者目線では挑みがいのあるチャレンジだ。しかし、上述したように、自動化のための開発要件では利益分析を通じて決定することを強く推奨する。

　第3段階では特定のプロセスや手順を体系的に記述したドキュメントやガイドライン、つまりプレイブックを開発する。利益分析の結果から、セキュリティリーダーはプレイブック開発を推進するために必要なプロセスとタスクについて着想が得られているはずだ。

　また、利益分析によって成功指標も得られたはずだ。成功指標を自動化開発に必要な労力を検証する目的で使える。展開後のプレイブックと実装戦略は、期待通りの利益をもたらすことができるかどうかに注目する。

　目的をプロセスやタスクに分割する利点の一つは、自社の目的は自社に固有かもしれないが、目的を達成するために必要な活動は共通だということだ。一般的な活動は、すでに他の専門家グループによって開発されている可能性が高い。

　あらゆる開発作業と同様に、テストと検証を設計要件が満たされていることを確認するためにおろそかにしてはならない。

　テストではタスク機能が期待通りに動作していることを確認する。APIは期待通りの反応を返すのか、配信に遅れはないのか、配信エラーは発生していないのか。これらは全て、プレイブックが設計通りに動作することを確認するための重要なテストだ。

第4段階　実装

　第4段階では、プレイブックが要件を満たすよう設計通りに動作し、計画通りに運用でも動作することを検証しなければならない。この段階では、プレイブックを本番運用に投入し、計画した利益を得ることを目指す。

　運用プロセス自体も、プレイブックを投入した後の状況を反映するように更新しなければならない。プレイブックの分量や種類はさまざまなため、どのプレイブックをいつどのように使用するかを文書化しておく。プレイブックの使用方法はプロセス文書の目的レベルで文書化する。このレベルの文書化は使用ガイドラインの指示だけでなく、プロセスレベルの依存関係やブレークポイントの追跡にも役立つ。

　また、セキュリティリーダーは自動化によって実現した実際の利益はもちろん、定期的に見直すべきレポーティングのための指標を実装チームに伝えておく必要がある。一部の自動化プロバイダーはツールにプレイブックレベルの使用状況追跡機能を搭載しており、レポーティングに役立つ。

　そのような機能がない場合、プレイブックの使用状況を追跡し、定期的な報告のために各インスタンスの利益を記録する方法を取り入れるのが最善だ。

　一人のオペレーターが実行する活動の種類はあまり変わらないはずだが、その個人の活動やタスクへの関わり方は異なるだろう。各役割に割り当てられる意思決定の種類は、ルーティングや分類、アクションなど一貫したものでなければならない。オペレーターはそのような意思決定の方法についてトレーニングを受けなければならない。

　コードでもよく言われているように、プレイブックにも賞味期限がある。メンテナンスが必要で、最終的には破棄する必要がある。プレイブックごとに、そのプレイブックの状態を保つ責任を誰が負うのかを決めておく。

　カスタムプレイブックの維持管理は社内の責任だ。開発プロセスにおいて、プレイブック内の依存関係（サードパーティーのAPI、ログのフォーマット、OSやアプリケーションのバージョンなど）を文書化しておく。

　セキュリティリーダーが以上の4段階に従えば、攻撃の一歩先を行く最新のセキュリティトレンドを維持するという全社的な目標の達成に役立つはずだ。