# Security Level Objectives Navigation: [[index]] | [[_index|concepts]] ## 定義 SRE の[[サービスレベル目標|Service Level Objectives（SLO）]]をセキュリティ領域に転用した概念。[[John Benninghoff]] が [[サービスレベル目標|SLO]] との類比で提案した。サービスの可用性・レイテンシを測定する SLO と同様に、セキュリティリスクを代理測定する指標に閾値を設定し、閾値を下回ったときにセキュリティ改善へリソースを転用する意思決定ルールとして機能させる。 通常の SLO との本質的な違い: セキュリティ侵害損失には「許容できるレベル」の設定が困難（特に小規模組織は典型損失 $250K 超で年商を喪失しうる）。そのため「損失率の SLO」ではなく、**リスクと相関する先行指標（攻撃面・パッチ状況・認証強度）に対して閾値を設定する**という設計が現実的とされる（Source: [[@2025__SREcon25Americas__Is the S in SRE for Security]], p.26）。 ## 具体的な指標候補（Benninghoff 提案） - エンドポイント当たりの脆弱性数（Vulnerability rate per endpoint） - 公開サービス当たりの開放ポート数（Open ports per public service） - MFA 未使用エンドポイントの割合（% of endpoints not using MFA） - 孤立アカウントの割合（% of orphaned accounts） - ログイン失敗率（Login failure rate） - ログイン成功率（Login success rate） SLO と同様に、閾値を下回ったときにインフラチームが修正に集中するトリガーとなる。Benninghoff は2002年に脆弱性管理プログラムを始めた際、事後的に「これは SLO だった」と認識した（脆弱性が多すぎるとき、インフラ責任者がパッチ適用を指示するメールを送っていた）という実践例を挙げている。 ## 横断的知見 - SRE の SLO と Security Level Objectives の最大の構造的差異は「損失の分布」にある。アウテージ損失は $100–$10M（典型 $100K）であるのに対し、サイバーセキュリティ損失は $100–$10B（典型 $1M、95パーセンタイル $52M）と規模が桁違いに大きく、誤差バジェット的な損失許容モデルがそのまま適用しにくい。（Source: [[@2025__SREcon25Americas__Is the S in SRE for Security]], p.23） - **Benninghoff の指標ベース閾値と『Observability Engineering』第2版第31章のコンプライアンス階層は、どちらも「二値の合否判定」を「段階的な閾値・階層による意思決定」へ置き換えるという同型の設計転換を、異なる粒度で行っている**: Benninghoffは脆弱性数・MFA未使用率のような先行指標に閾値を設定し、下回ったときにインフラチームが修正へ集中するというサービス単体・指標単位のトリガー設計を提案する(Source: [[@2025__SREcon25Americas__Is the S in SRE for Security]])。一方、第31章は「ほとんどの環境は全てのコンプライアンス統制を必要としない」という前提のもと、複数のコンプライアンス階層・規制階層を用意しサービスを段階的に「卒業」させる仕組みを提案し、こちらは組織・環境単位の粒度で階層化する(Source: [[@2026__OReilly__Observability Engineering 2E - Chapter 31 Instrumentation for Observability Teams]])。両者を重ねると、Security Level Objectivesの個々の指標閾値は、第31章が描く環境単位のコンプライアンス階層を卒業するための**サービス単体の必要条件**として位置づけうるが、この接続を明示した一次資料は本 wiki にはまだない。 - **第31章が挙げる「証拠の重さ」というコンプライアンスの本質は、Benninghoffが指摘した「損失許容モデルが適用しにくい」という課題に対し、測定の自動化という別解を示唆する**: 第31章は規制環境で「証拠の重い負担」(暗号化しているか、証明できるか)が通常のエンタープライズ以上に問われると述べ、[[OTel Weaver]]によるスキーマ制御をCI上で機密データ非漏洩の証拠収集を自動化する具体策として挙げる(Source: [[@2026__OReilly__Observability Engineering 2E - Chapter 31 Instrumentation for Observability Teams]])。Security Level Objectivesが直面する「セキュリティ侵害損失の許容レベルが設定困難」という課題(Source: [[@2025__SREcon25Americas__Is the S in SRE for Security]])に対しては、損失そのものを許容するモデルではなく、Weaverのような自動証拠収集基盤で先行指標(脆弱性数・MFA未使用率等)を継続的・低コストに測定し続けることが、閾値設計の精度を上げる代替アプローチになりうる。 ## 未解決の問い - 既存の SLO インフラ（Alertmanager・SLO ダッシュボード）を Security Level Objectives の測定・アラートにそのまま転用できるか？ - 「ログイン成功率」「脆弱性数」などの指標は季節性・組織規模に応じてどう正規化するべきか？ - セキュリティインシデントの発生頻度（3–10年に1回）では SLO のウィンドウ設計（28日・四半期）が機能しない可能性がある。どう設計すべきか？ - Security Level Objectivesのサービス単位・指標単位の閾値設計と、第31章のコンプライアンス階層(環境単位の段階的卒業)は、どのように組み合わせられるべきか。ある環境が「卒業」する条件の一部として、配下の各サービスがSecurity Level Objectivesの閾値を満たしていることを要求する設計は成立するか。 ## 関連 - [[サービスレベル目標]] — 概念的親。SLI/SLO の設計原則が Security Level Objectives の基盤 - [[Safety-II]] — 「成功の増加」という思想的基盤。指標が「失敗の非発生」でなく「セキュリティ健全性の陽性指標」であるべきことを示唆 - [[SRE]] — セキュリティと SRE の共通基盤 - [[SLODLC]] — SLO 設計プロセス。Security Level Objectives の設計にも応用可能 - [[OpenTelemetry]] / [[OTel Weaver]] — スキーマ制御による証拠収集の自動化基盤候補 ## 出典 - [[@2025__SREcon25Americas__Is the S in SRE for Security]] — Benninghoff による概念の初出・具体化 - [[@2026__OReilly__Observability Engineering 2E - Chapter 31 Instrumentation for Observability Teams]] — コンプライアンス階層による段階的判定、証拠収集の自動化(OTel Weaver)