自律型のセキュリティ運用の達成: あまり正しく知られていない、指標が重要である理由
Google Cloud Japan Team
※この投稿は米国時間 2022 年 7 月 27 日に、Google Cloud blog に投稿されたものの抄訳です。
セキュリティ運用チームが直面しうる最も困難な問題はなんでしょうか。「誰が攻撃してくるのか」という人、もしくは「どのサイバー攻撃を検出できるのか」という人もいるかもしれません。チームは「正しい」決定をするための十分な情報が集まったことをどのように判断するのでしょうか。指標は、これらの問題への回答を知るのに役立ちます。しかし、ミッション クリティカルな危機やビジネス クリティカルな危機の最中に、どの指標が最も信頼できるのかを知る方法はあるのでしょうか。
ブログ「自律型のセキュリティ運用の達成: トイルの削減」や「自律型のセキュリティ運用の達成: パフォーマンス増強装置としての自動化」で述べたように、セキュリティ オペレーション センター（SOC）は、サイト信頼性エンジニアリング（SRE）の変革の間に開発された IT オペレーションから多くを学ぶことができます。この投稿では、この教訓をどのように SOC に適用させるかを、SRE のもう一つの原則であるサービスレベル目標（SLO）を中心にご説明します。
業界での定義は多岐にわたっていますが、SLI、SLO、SLA は特定の意味を持っていると、電子書籍「Site Reliability Engineering: How Google runs production systems（サイト信頼性エンジニアリング: Google の本番環境システムの運用方法）」の著者は、サービスレベル目標のチャプターで述べています。（以降の引用はすべてこの本の SLO チャプターからの引用です。また、これ以降はこの本を「SRE ブック」と呼びます。）
SLI: 「SLI はサービスレベル指標です。つまり、提供されるサービスのレベルのいくつかの側面に関して慎重に定義された定量的な基準です。」
SLO: 「SLO はサービスレベル目標です。SLI で測定されるサービスレベルの目標値や範囲のことです。」
SLA: SLA は上述についてのサービスレベル契約のことです。「ユーザーとの明示的または暗示的な契約で、SLO を満たす（または満たさない）場合の結果を含みます。」
実際には、何かを測定し（SLI）そして目標値を設定します（SLO）。そして、それに関しての合意（SLA）を行います。
これは「成果が測れることは必ず成し遂げることができる」というような決まり文句のことではありません。しかし指標と SLI / SLO は、SOC の運命を決めるのに大きな割合を占めます。たとえば、「アラート対応時間」に執着する SOC（マネージド セキュリティ サービス プロバイダを含む）は、結果としてセキュリティの有効性を減少させることになります。平均検知時間（MTTD）と「アラート対応時間」を同一視しアナリストにその時間を短縮させた場合、防御者が何か見落としているときに、攻撃者は優位に立ちます。
追跡する指標の選び方
指標の 1 つの見解として、1 秒あたりの攻撃数や 1 人あたりのインシデント数などの「悪いとされるもの」を減らす必要があり、成功、信頼性、稼働時間などの「良いとされるもの」を増やす必要があるということです。
しかし SRE エクスペリエンスでは、優れた指標は最適なレベルを持つ場合があり、さらに信頼性もあるのです（そしてもしかするとセキュリティさえも優れているかもしれません）。この書籍の著者である Chris Jones、John Wilkes、Niall Murphy、Cody Smith は、一般常識に反する、信頼性が非常に高いサービスの例を引用しています。
「滅多に起こらないことですが、高い信頼性で誤った安心感を与えていた原因は、サービスの利用ができなかった際にサービスが適切に機能しなかったせいです。SRE は、グローバル サービスがサービスレベル目標を満たし、そして超過しないようにします」と述べています。
SOC の教えによると、いくつかのセキュリティ指標には最適な値があります。上述の検出時間は、組織ごとに最適な値があります。他の例を挙げると、フィッシングのインシデント数には実は最適値があります。もし誰もフィッシングしないのであれば、それはおそらく、お客様のシステムの多くにアクセス可能な認証情報を得ているということです。SOC では、SLI の最適化を考慮し、指標がゼロもしくは無限だと自動的に推定することはありません。
SRE ブックからの 3 つの引用から、「優れた指標」は、やみくもに押し上げるものではなく、他の指標とのバランスをとる必要がある場合があることがわかります。
「ユーザー向けサービス提供システムでは、一般的に可用性、レイテンシ、スループットを重要視しています。」
「ストレージ システムはレイテンシ、可用性、耐久性に重きを置いています。」
「データ処理パイプラインなどのビッグデータ システムでは、スループットやエンドツーエンド レイテンシが重要視される傾向があります。」
SOC では、これは脅威を素早く検出し、インシデントに関するすべての内容を確認し、脅威の調査を深く行うことを意味します。しかし、さまざまな脅威に対して結果が異なる場合があります。4 つめの道しるべは、なぜ SOC がこのようなことまで注意しなければならないのかを説明します。「特定のサービスが SLA を有しているかにかかわらず、SLI と SLO を定義し、サービスを管理するために使用することは価値があります。」実際、SLI と SLO は SOC にとって、SLA やその他の合意より重要であるということに同意します。
指標は重要だが、柔軟性も重要
セキュリティ運用チームが直面しうる最も困難な問題について考えるとき、どのように指標を評価するかについて知ることは、正確な答えにたどり着くためには非常に重要です。この本から他の知見を考えてみましょう。「ほとんどの指標は平均ではなく、分布として考える方がよいでしょう。」
アラート対応の平均時間が 20 分だったとしましょう。この場合、「すべてのアラートに 18 分から 22 分で対応している」と言えるでしょうか。「1 つを除きすべてのアラートは 5 分で対応しているが、6 時間かかっているものが 1 件ある」かもしれません。この答えの違いは、運用環境の非常に大きな違いを表しています。
SOC で私たちが見てきたことは、1 つの異常値イベントが最も問題であるということです。「対応時間のばらつきが大きくなればなるほど、一般的なユーザー エクスペリエンスはロングテール行動の影響を受けます」と著者は述べています。つまり、セキュリティの世界では、対応に 6 時間かかる 1 件のアラートが、検知された最も危険なアクティビティに関連している可能性が高いのです。
これに対処するには、「パーセンタイルで表示することで分布の形状を考慮することができます」と、記載されています。Google の検出チームは、平均値だけでなく、5% と 95% の値もトラッキングしています。
SRE のもう 1 つの有用なコンセプトは、「エラー バジェット」です。SLO の未達が許されるレートであり、一日単位または週単位で追跡します。これは他の SLO を満たすための SLO です。
この SOC 値はすぐに明らかにはならないかもしれませんが、テクノロジーにおいて、セキュリティが占める独自の役割を理解するためには重要です。セキュリティにおいて、指標は邪魔になる場合があります。なぜなら本当の勝負は、脅威が目的を達成するのを阻止することだからです。私たちの経験から、ほとんどのブルーチームは SLO を見逃して、脅威を環境内で捕らえることを優先します。防御側が勝利するのは、「SLA に準拠している」ときではなく、攻撃者が負けたときなのです。ここでエラー バジェットのコンセプトはお客様の強い味方となるかもしれません。
SRE ブックでは、このことについてさらに進んだ考えを持っています。「SLO が 100% になると主張するのは非現実的であり、望ましくありません。そうなると、イノベーションとデプロイの速度が低下するかもしれません。」
もっと大まかに言えば、SOC に関する Google と Deloitte による最新の論文で述べているとおり、厳格な服従はそれ自体が脆弱性となります。「サポートプロセスがどれだけよく計画されていたとしても、プロセスへの執着と SOC に対する批判的な思考や創造性の欠如は、潜在的な攻撃者に環境内で脆弱性を利用する別の機会を与えることになります。」
組織の防御を成功させるには、SOC は曲がらない樫の木のようではなく、しなやかで弾力のある柳の木のようでなければなりません。
指標を追跡しながら、脅威を注視し続ける
SRE の仲間による 3 つめの興味深いパズルは、「現在のパフォーマンスに基づいて目標を設定してはいけない」です。
仕事を改善したいと思って、現在のパフォーマンスに基づいて改善の目標値を選択することは、決して悪いことには見えません。しかし、その結果、非現実的、もしくは役に立たない、あるいはひどく不十分な目標を設定することで、予測は利点より欠点の方が多くなるのです。
例を挙げてみましょう。あるアナリストは（SLI に基づき）1 日に 30 件のアラートを処理しますが、マネージャーが 15% の改善を望んでいるので SLO を 1 日 35 件のアラートに設定したとします。しかし、アラートは何件あるのでしょうか。SOC に適した SLI かどうかという問題はさておき、もしアラートが 5,000 件あったとしたら 4,970 件を取りこぼしていることになります。「改善」したとしても、まだ 4,965 件も取りこぼしています。これは良い SLO でしょうか？いいえ、違います。すべきことは、SOC での採用、自動化、フィルタリング、調整、その他の変更であり、今日の数字を改善したように見えるより良い SLO 目標を設定することではありません。
これに対して、SRE の仲間は次のように話します。「結果として、指標を選んでから目標を設定するより、希望の目的から特定の指標を逆算する方がうまくいくことがあります。何を測れるかから始めるのではなく、ユーザーが何を気にしているのか考える（もしくは見つける）ことから始めるのです。」
SOC において、これは、現在のアラート パイプライン パフォーマンスではなく、脅威モデルとユースケースから開始するということを意味します。
SOC ガイダンスは、私たちが思っているよりも不可解な場合があります。1 つは、一般的な SOC で本当に必要な指標はいくつなのか、という問題です。SRE はここで哲学的になります。「システムの属性をカバーするために十分な数の SLO を選択する」です。
私たちの経験では、10 を超える指標で成功したチームはありません。また、3 つ未満の指標で SOC パフォーマンスを説明し、最適化したチームもありません。しかし、SRE は有用で簡潔なテストを提供します。「もし、特定の SLO を引き合いに出して、優先順位についての対話に勝てないのであれば、その SLO を持つ価値はありません。」
SLO は SOC を定義します。つまり、理想の SOC になるように SLO を定義すればよいと、この本では述べられているのです。「厳しい目標を選んで達成不可能だとわかるよりも、緩い目標から始めて徐々に狭める方が良いのです。SLO は、SRE と製品開発者の仕事の優先順位を決めるにあたり、重要な要因になることができますし、またそうあるべきです。なぜならそれはユーザーが気にしていることを反映しているからです。」
重要なのは、SOC のための SLO を社内で透明化することです。SRE は「SLO の公開はシステムの動作に期待を持たせる」と述べています。このメリットは、SLO に合意したパフォーマンスであれば、パフォーマンスが悪くても誰も責められることがないということです。
最後に、これは Google チームで使用している指標の例です。エスカレーションされたアラートを確認することに加えて、毎週以下を収集し、確認します。
イベント ボリューム
イベント ソース カウント
パイプライン レイテンシ
トリアージ タイムの中央値
95% のトリアージ タイム
これらの指標を分析することで、検出と対応チームに SRE の原則とアイデアを適用するための有益なガイダンスを見つけることができます。
イベント ボリューム: ここで把握すべきことは、ボリュームは何に左右されているかということです。イベント ボリュームは通常か、高いか、低いか。そしてその理由は何なのか。メッセージが殺到したのか。新しいデータソースがボリューム増大の原因なのか、何が原因なのか。異常なシグナルはないか。追加の設定を実装するために、戦略的フォローアップを必要とするビジネスの問題領域があるのか。
イベント ソース カウント: 異常な動きをしているシグナルや自動化はないか。新しい自動化が誤作動していないか。各ソースコールのイベントを数えることで、優れた SLI を実現します。
パイプライン レイテンシ: Google では、イベント発生から 1 時間以内に検出を確認することを目標としています。理想時間は 5 分です。つまり、イベント パイプライン レイテンシは、徹底的に追跡しなければいけません。これは、自動化のレイテンシを徹底的に検査するべきであるということを意味します。この目標を達成するため、異常なシグナルや異常な自動化を隠さないように、自己原因のレイテンシを取り除くようにしています。
中央値と 95% の時間をトリアージ: イベント対応時間を追跡しています。SRE ブックが指摘するように、1 つの平均値だけを追跡すると、すぐにトラブルが発生します。トリアージ時間とは、解決までの時間ではなく、攻撃者が見つかるまでの滞留時間です。
インシデント解決時間: SLI があっても SLO がない場合、これは議論すべき明らかな問題で、「良い方へ進む」のではなく「早く進む」ためのありとあらゆる種類の悪いインセンティブを生む可能性があります。特に、SLI なしの SLO は、分析を早急に解決するよう促すので障害が生じ、特に、微妙な信号が発生した場合に重大なセキュリティ インシデントを見逃すリスクが増加します。
アラートのエスカレーションを確認する際は、十分な分析がなされているか、ハンドオフに対応チームにとって正しい情報が含まれているか、アナリストの疲労度などを判断します。もしアナリストのノートがいい加減になっていたら、それは特定のシグナルを超えているか、重複するインシデントが大量にあるというサインなので、何とかしてビジネスを変化させる必要があります。
これらの要素や他の要素を測定することで、各検出のコストを削減することができます。これにより、最終的に、検出と対応オペレーションは脅威を上回るスピードでスケールすることができます。
関連する投稿
- Google 検出および対応担当ディレクター Tim Nguyen
- ソリューション戦略担当責任者 Anton Chuvakin
