自律型のセキュリティ運用の達成: パフォーマンス増強装置としての自動化
Google Cloud Japan Team
※この投稿は米国時間 2022 年 2 月 11 日に、Google Cloud blog に投稿されたものの抄訳です。
「自律型のセキュリティ運用の達成: トイルの削減」で説明したように、セキュリティ オペレーション センター（SOC）はサイト信頼性エンジニアリング（SRE）からいくつも教訓を得ることができます。つまり、ソフトウェア エンジニアリングのプラクティスをセキュリティ運用の課題に適用することで、組織のセキュリティを根本的に改善できます。この投稿では、SRE のもう一つの基本方針である自動化を、SOC でより良い結果を達成するための手段として活用する方法について説明します。
最初に明確にしておくべきは、人間の介入を必要としない、完全に自動化されたセキュリティ オペレーション センターは今のところ存在しないということです。自律型のセキュリティ運用の本質は、組織は非自発的にオンデマンドで脅威管理機能をスケーリングする必要があり、そのスケーリング速度が脅威や保護すべきアセットの成長速度よりも速くなければならないという考え方です。SOC がアセット、脅威、複雑さの増大に対して常に先手を打つことができれば、組織内に「自律的」に存在する状態を効果的に実現できます。
このようなことは、テクノロジー構築の側面ではすでに達成されています。DevOps の採用により、ソフトウェア チームがいかに「自律的」になったか考えてみてください。こうした環境では、企業はテクノロジー チームの順応性を気にすることなく新しい市場に参入し、必要に応じて新しいサービスを構築できます。これらの機能は完全には自動化されていないため、これらとの類似点により一つの同じ理論に導かれます。理想的な状態に向かう道のりは、同じイデオロギーから出発しているという理論です。したがって、Google は自律型のセキュリティ運用を、理念、実践、ツールを組み合わせたものと定義しています。適応型、アジャイル、高度に自動化された脅威管理アプローチを通じて、組織がセキュリティ攻撃に耐え得る能力を向上させます。
SOC がサイト信頼性エンジニアリングから学べる具体的な例と原則を確認しましょう。
当然ながら、脅威管理に対して自律的なアプローチを構築するということは、できる限り自動化を実装することが SOC の全担当者が目指すべき原則であるということを意味しています。セキュリティ エンジニア、アナリスト、インシデント対応担当者、アーキテクトのいずれであっても、運用を自動化する創造的な方法（最初は日常的なタスクから開始）により、チームの運用の負担を軽減する力を増強できます。
この力は SRE の領域における立ち位置と相対しています。しかし、SRE ブックには、「力を数倍に向上させても、その力が加えられる場所の精度は自然に変わることはありません」とも付け加えられています。崩壊したプロセスを自動化すると、さらに崩壊が進むということや、SOC にとって状況改善にならないものや体系的でないものを自動化しても、少し良くなるだけだということを再認識させられます。
実際には、自動化は、SOC のさまざまな領域やロールに適用されています。事例の範囲は、応答アクティビティ（Siemplify のようなツールやその他の SOAR プロダクトを使用）、データの強化、マネージド セキュリティ サービスへのプロセスのリンク、SOC 内の他の無限のワークフローを対象としたハンドブックの作成にまでおよびます。繰り返しの業務を行う際は、その業務を創造的に自動化できるかどうかを常に自問してみてください。
自動化の価値は、もっぱら時間を節約することだとよく言われます。実際、Google の SRE 担当者たちは、「自動化は単なる時間の節約以上の効果をもたらすため、単純に時間の消費と節約を比較した計算結果から推奨されるケース以外にも、より多くのケースで実装する価値がある」ことを教えてくれます。SOC 担当者と SRE 担当者の双方が、スケーリングと同様に、一貫性も自動化の中心的な要素であることに同意しています（「スケーリングは自動化の明らかな動機です」）。
具体的には、一貫性によってプロセスの欠陥を解決することもできます。多くの場合、欠陥は信頼性と関連していますが、セキュリティにおける信頼性とは、システムの信頼性とシグナルの信頼性の両方であると考えてみましょう。ツールや手法において、ダウンタイムをできる限り短くし、ノイズを最小限に抑え、真陽性を最大化する必要があります。これにより、システムとシグナルの信頼性が向上し、チームは継続的な解決と防御の改善に集中できます。
また、SOC の作業には、アナリスト主導のプロセスである脅威の探査など、ツールによって支援されるものの、手動作業として設計されているものがあると考えてください。理想的には、探査中に脅威を特定および無効化したら、攻撃者の戦術と手法の背後にあるデータを活用して、検出のユースケースを改善し、可能な限り自動化を実現する必要があります。
自動化に関する SRE の議論では、依然として速度が頻繁に話題に上ります。結局のところ、「人間は通常、機械ほど速く反応することはありません。」過去、特に 1 日の応答タイムラインが 200 件程だった時代には、1 秒未満の速度はセキュリティにおいてほとんど問題とされませんでした。今日、ランサムウェアによって状況は変化し、速度が重要になっています。
なお、速度は必ずしも検出速度と相関したり、平均検出時間を削減したりする必要はないことにご注意ください。本番環境のワークロードに影響を与えている可能性のあるものを検出し、プロジェクト所有者にアクションを含むリクエストを送信する自動化機能があるとしましょう。影響を受けるチームが応答せず、ブレークグラスを行う必要がある場合は、それに対応する速度が結果を左右することがあります。そのため、パフォーマンスのボトルネックを自動化する方法を確認してください。
結果として、SOC の自動化が SRE から獲得する主要な教訓とは、「一貫性、迅速性、および信頼性の要素が、自動化の実行のトレードオフに関するほとんどの議論の中心になる」ということです。これらの教訓は、直面する脅威や、IT アセットの成長スピードよりもさらに速く SOC をスケーリングするために取り組むときに効果を発揮します。
さらに、私たちは SRE ブックからある新しい知見をピックアップしました。それは、自動化によって操作がオペレータから分離されるということです（「オペレータから操作を引き離すことは非常に影響力があります」）。具体的には、「自動化でタスクをカプセル化すると、誰でもそのタスクを実行できるようになります。」これによって解決できる問題として、SOC における人材不足の問題などが挙げられます。これでまた、脅威やアセットの増加を上回る速度でスケールリングできる機会が得られます。
SRE の世界から SOC に適用できる非常に便利な助言がもう一つあります。それは、「自動システムもプラットフォームを提供する」ということです。これは、記述したスクリプトがマイナーなタスクをいくつか自動化したとしても、プラットフォームではないという意味です。Google の考え方では、プラットフォームはプログラム可能なエンティティであり、他の重要なものを開発するための基盤です（たとえば、優れた SOAR はプラットフォームです）。これは、ユーザーにはアクティビティの自動化をより体系的にするチャンスがあることを意味します。
しかし、少し逆説的な結論もあります。「プラットフォームではミスも一元化されます。言い換えると、コード内で修正されたバグは、そこで永久に修正されます。」少し考えてみてください。これは、SOC がやって来てミスを犯すのに最適な場所だということではありません。50 以上のツールと 200 か所のオフィスでミスを追いかけるのではなく、1 か所にアクセスしてミスを探せばよいという事実です。ミスを一元化することは、継続的な改善を加速するための優れた方法です。
最後に、「プラットフォームとしての自動化」によって、役立つ指標を得ることができます。「プラットフォームでは、パフォーマンスに関する指標をエクスポートしたり、以前は知らなかったプロセスの詳細を発見したりできます。」自律型のアプローチを行っている SOC 実践者の場合、サービスレベル目標（SLO）のクオリティは、システム内にあるデータに依存します。
Google の SRE 担当者たちはまた、自動化の持ついくつかの欠点とそのリスクについても指摘しています。あらゆる SOC チームが強調している非常に明白なトピックは、自動応答が正しく計画されていない場合、悲惨な結果がもたらされる可能性があるということです。これは、IT 運用とセキュリティの両方で発生する可能性があります。SRE ブックには、大手テクノロジー企業の多くの本番環境システムが自動化によって削除され、驚異的な規模と効果を備えた完全なゴミへと再イメージ化されてしまった例が記載されています。自動化にはこのような可能性があるため、自動応答を開発する際には、ピアレビュー、QA とテスト、細部まで詳細を記したハンドブック、その他のプロセスを用意することが重要です。
また、SRE では、「自動化では暗黙の『安全』シグナルに依存することに注意する必要があります。」SOC の典型的な例は、ビジネス上の重要性をチェックせずに、悪意に基づいたアクセスをブロックすることです。アクセスをブロックすることが安全であると示唆していますが、「このマシンは自動ブロックしても問題ありません」という明示的なリストはあるでしょうか？安全にシャットダウンできるでしょうか？アクセスをブロックしても安全ですか？自動化における明示的な安全性シグナルの使用は、SOC に実装するための有用な知見です。
これまで、セキュリティ運用の世界に関連するその他の課題について学んできました。たとえば、SOAR ユーザーの中には、セキュリティ ツールが変更されたときに SOAR システムが必ずしも十分に素早く機能するとは限らないと不満を漏らす人がいます。これは SRE の世界ではよく知られている問題です。自動化は「主要なシステムとは別に維持されるため、『ビット劣化』（基盤となるシステムが変更されても変更しないなど）に悩まされます。」
多くのセキュリティ オペレーション センターで明らかになり始めたもう一つの教訓は、まれな攻撃インジケータを確認して実行されるハンドブックなど、頻度の低い自動化はテストが難しい、ということです。「重要なものの実行頻度が低く、テストが難しい自動化は、フィードバック サイクルが長いため、特に脆弱になることは珍しいことではありません。」1 日に 10 回実行される効率的なハンドブックを改良するのは簡単ですが、今年発生するかどうかという特定のタイプの高度な攻撃を対象としたハンドブックをテストして改善するのは非常に困難です。改善するには、より多くの自動化を用いましょう。この場合は自動化とシミュレーションをテストします。
ほとんどの主要なセキュリティ オペレーション センターや、SRE ブックの奥深くには、もう一つの重要な教訓があります。それは「最も機能的なツールは通常、それらを使用する人によって作成される」ということです。これは多くの検出エンジニアリングの記事で議論されていますが、多くの主流の SOC では一般的でないことは明らかです。Google の ASO ワークショップで、「SOC アナリスト」と「検出エンジニア」をまとめて 1 つにする必要があると説明しているのはそのためです。
冒頭で、自律型のセキュリティ運用のプラクティスの考え方について説明しましたが、手動アプローチから始めて自動化に進化することにより、自律システム自体（外部の自動化を必要としない）に到達するまでの道筋を示す SRE から得られる教訓もあります。SRE ブックの自動化の進化の例は次の通りです。
「オペレータによってトリガーされる手動アクション（自動化なし）
オペレータ作成のシステム固有の自動化
外部で維持される一般的な自動化
内部で維持される、システム固有の自動化
人間による操作を必要としない自律システム」
上に挙げたうちのいくつかは SOC との関連が明確ではありませんが、明らかに類似点があります。
自動化は魔法の薬でも、単一で購入できるツールでもないことは明らかですが、すべてを合わせたものが、システムを安全で、効率的で、信頼性の高いものにし、社員が夜間に働くことなく眠れる状況を実現します。
チーム各自の役割において自動化できる重要な領域について、ブレインストーミングの演習やワークショップを行うように、チームを刺激してみてください。創造的に考えるようにスタッフを動機付けるこのような変化は、非常に広範囲で成功を収めている DevOps と SRE が行っている方法です。また、現代のテクノロジー フットプリントの複雑さを先取りしたい場合、自動化は成功の中心的原則です。
関連する投稿
- ソリューション戦略担当責任者 Anton Chuvakin
- セキュリティ ソリューション マネージャー Iman Ghanizada
