自律型のセキュリティ運用の達成: トイルの削減

※この投稿は米国時間 2021 年 11 月 30 日に、Google Cloud blog に投稿されたものの抄訳です。

約 20 年にわたり、サイト信頼性エンジニアリング（SRE）は、ソフトウェア エンジニアリング プラクティスを従来のインフラストラクチャとオペレーションの管理に組み込む価値を証明してきました。並行して Google では、同様の原則により、インフラストラクチャとオペレーションの課題に悩まされている領域であるセキュリティ オペレーション センター（SOC）の成果を大幅に改善できることを見いだしています。デジタル トランスフォーメーションに取り組む組織の増加に伴い、極めて効率的な脅威管理機能を構築することの重要性が高まっており、こうした組織の最優先事項の一つとなっています。Google のドキュメント「自律型のセキュリティ運用: セキュリティ運用センターの 10X 変換」では、セキュリティ運用のモダナイゼーションのアプローチについて説明しています。

セキュリティ運用のモダナイゼーションの過程において中核となる要素の一つは、「トイル」の排除を徹底することです。トイルとは SRE ブックで「本番環境サービスの実行に関連し、手作業、繰り返される、自動化が可能、戦術的、長期的な価値がない、サービスの成長に比例して増加する、といった特徴を持つ作業」と定義されている SRE 用語です。セキュリティ アナリストであれば、トイルの選別が、最も重要で負担の大きい職務の一つであることにお気づきでしょう。一部のアナリストにとっては、すべてのワークロードが「トイル」の SRE 定義に当てはまります。

トイルの別の定義として、同ブックには、「タスクを終了した後もサービスが同じ状態のままだった場合、そのタスクはおそらくトイルです」という記述もあります。心当たりがある方もいるかもしれません。ほとんどの SOC の作業は本質的にこのようなものである、と言う方もいます。すなわち、攻撃者が出現し、アラートがトリガーされ、トリアージ、調査、調整、対応、除去、反復処理を行うといった作業です。Google のインフラストラクチャがこういった作業の後も同じ状態である場合は、それが望んだ結果かもしれませんが、アナリストの負担を増大させるオペレーション上の課題はすべて残されたままです。

では、優れた SRE チームが行っているように SOC を機能させるにはどうすればよいか見ていきましょう。

まず、ドキュメントで述べられている 10 倍の改善はどのようにして達成されるのでしょうか。攻撃の増加に伴い、保護する資産や環境の複雑さが増大した場合、「トイルベースの」SOC はこれらの変化に対応して少なくとも直線的に成長する必要があります。攻撃数や保護対象が 2 倍に増えると（クラウドが SOC の対象範囲に追加された場合など）、人員を 2 倍にし、場合によってはツールに費やす予算も 2 倍にする必要が生じます。

ただし、ASO（自律型のセキュリティ運用）のドキュメントで説明している原則に基づいて SOC を変革する場合、データと複雑さが増大しても、人員と予算を 2 倍にする必要があるとは限りません（この 2 つが多くのセキュリティ リーダーにとって最も難しい問題です）。最新のスケールで安全なシステムを運用する場合、セキュリティ運用全般、特に SOC の有効性における進展は、エンジニアリング ファーストのマインドセットを推進することに大きく依存します。最新の SOC に対してお好きな方法で「運用」はできませんが、お好きな方法で「開発」することはできます。Chronicle など、最新の検出および調査用ツールの使用も目標達成に役立ちます。

それでは、こうして得られた SRE の知見を SOC で活かすにはどうすればよいでしょうか。

まず、SRE の理念を SOC に導入する方法についてチームを指導します。チームビルディングを実践する機会を見つけて、チームが組織文化の変革を定義できるように支援してください。組織文化の変革を推進するには、意欲的で触発された、規律あるチームが必要です。

学習プログラムに投資してアナリストのスキルアップを図り、エンジニアリング スキルをさらに向上させます。チームのキャリアへの投資は、ポジティブな感情の増大や人員のモチベーション アップ、ひいては従来の運用チームよりもソリューション志向のチームの確立につながります。

運用時間の 50% 削減を目指します。「自動化ファースト」のマインドセットで残りの 50% をシステムと検出の改善に費やすようにします。なお、エンジニアリングはコードの記述とは異なります。  「エンジニアリング作業とは、新規性を備え、本質的に人間の判断を必要とします。サービスの永続的な改善を生み出し、戦略によって導かれます。」

SOC で、「適切なエンジニアリングを実行して、週ごとに少しずつトイルの排除に注力します。」SOC での例としては、非実用的なアラートを生成するルールの調整、コンテキスト データを使用中にアラートを自動クローズするための SOAR ハンドブックの作成、ログ収集が最適に実行されるためのテストのスクリプト記述などがあります。

その他の検討分野として、運用の経験がある、または迅速に改良を行えるセキュリティ自動化エンジニアの採用を検討してください。適切な人員は、チーム全体を「SRE で主導された」SOC の 10X 変換へと導くよう方向づけることができます。

Google サイバーセキュリティ対応チームは、規模や能力を問わず、あらゆる組織が「自律型のセキュリティ運用」（ASO）を達成できるように支援いたします。SOC を悩ます課題は乗り越えられないように思えることもありますが、エンジニアリングの漸進的な改善によって飛躍的な成果がもたらされます。脅威管理機能のモダナイゼーションに関するロードマップの策定を検討されている場合、Google はパートナーとして全面的に協力いたします。

より自律型のセキュリティ運用への移行に関する視点を提供するその他のリソースを以下にご紹介します。

「SOC のモダナイゼーション ... 自律型のセキュリティ運用の導入」

「自律型のセキュリティ運用: セキュリティ運用センターの 10X 変換」

「進化し続ける大規模かつ複雑な組織における SOC」（Google Cloud Security Podcast ep26）および「検出工学の謎の解明」（ep27）

「クラウドでの脅威検出を試行した SOC … 判明した驚きの事実」

- セキュリティ ソリューション マネージャー Iman Ghanizada

- ソリューション戦略担当責任者 Anton Chuvakin