6.4 セキュリティと脆弱性管理の指標

概要と動機

本トピックは、この部が構築してきた同じ信頼性の規律、目標設定、ガードレールの組み合わせ、正直なインシデントの報告を、異なるが密接に関連するリスク、システムが自然に失敗するかどうかではなく、誰かが意図的にそれを失敗させるか、あるいはそれを悪用するかに拡張することで第6部を締めくくります。脆弱性管理の指標は、組織がセキュリティの弱点を悪用される前にどれだけうまく見つけ修正するかを測定します。いくつの脆弱性が存在するか、それらはどれだけ深刻か、そして決定的に、発見された後それらがどれだけ速く是正されるかです。既知だが未修正の脆弱性は、組織が意図的にであれ怠慢によってであれ抱え続けることを選んだ、常在する定量化可能なリスクだからです。

本トピックの中心的な懸念は、トピック4.4の静的解析の発見の扱いを直接反映しています。生の脆弱性の件数は貧弱な指標であり、取るに足らない問題と深刻な問題を混同し、トピック1.2が一般的に説明する定義の狭め、抑圧、閾値のゲーミングとまったく同じゲーミングのリスクにさらされています。セキュリティの指標が必要とする特定の追加は、重大度に対して追跡された是正までの時間です。何ヶ月も未修正のまま放置された重大な脆弱性は、1日以内に捕捉され修正された同じ脆弱性とは根本的に異なるリスクを表し、単純な件数だけでは伝えられない情報です。

大規模なチームにとって、セキュリティの指標は即座の技術的リスクを超えた結果を伴います。企業組織は侵害からの契約上および評判上の露出に直面し、政府組織は国家安全保障、法的、公共の信頼の結果に直面し、これはセキュリティの指標を単なる内部エンジニアリングの懸念ではなく本物の公共の利益の問題にします。本トピックは、脆弱性管理を本書が一貫して適用する同じ厳密さと同じガードレールの組み合わせの規律で扱います。なぜなら、セキュリティの指標は本書が説明するあらゆるゲーミングのリスクにさらされており、そのゲーミングが成功したときに相応に高い賭け金を伴うからです。

重要な原則

重大度別の是正までの時間は生の脆弱性件数よりも重要である。 何ヶ月も未修正の重大な問題は、速く捕捉され修正された同じ問題とは根本的に異なるリスクです。
セキュリティの指標は静的解析の発見(トピック4.4)と同じゲーミングのリスクにさらされており、ゲーミングが成功したときにより高い賭け金を伴います。
重大度の分類は、純粋に内部の判断(寛大さに向かって漂流しうる)ではなく、可能な限り外部の標準化された基準を必要とする。
速やかに開示され修正された脆弱性は、隠すべき失敗ではなく健全なプロセスの兆候である。 開示を罰することは、このシステム全体が依存する報告を阻害します。
セキュリティの負債は技術的負債の一つのカテゴリーであり(トピック4.5)、同じ明示的で定量化された基準で優先順位づけられた是正の容量を競争すべきです。

推奨事項

重大度別の是正までの時間を主要な指標として追跡する

発見されたすべての脆弱性について、その重大度を記録し(該当する場合は共通脆弱性評価システム(CVSS)のような標準化された尺度を使用)、発見から本物の是正までの時間を追跡してください。チケットが閉じられることや修正がマージされたがまだデプロイされていないことまでではありません。重大度別に明示的な是正時間の目標を設定してください。一般的には重大な問題については日数で、より低い重大度の問題については週数で測定されます。そして、生の加重されていない脆弱性の件数ではなく、主要なセキュリティの健全性の指標として、それらの目標に対する準拠を追跡してください。

純粋に内部の判断ではなく標準化された重大度のスコアリングを使う

CVSSのような標準化された外部のスコアリングシステムが利用可能な場合、完全に内部の潜在的に一貫性のない判断に頼るのではなく、重大度分類の主要な基礎としてそれを使ってください。これはトピック5.1のエスケープした欠陥の分類の規律とトピック6.2のインシデントの分類の規律を反映しており、ここでは特にセキュリティに適用されています。そしてそれは、それらのトピックが警告する同じ寛大な漂流のリスクに抵抗します。外部に根拠づけられたスコアは、純粋に内部のものよりも静かに下方に再定義することが難しいからです。

本物に非懲罰的な脆弱性の開示と内部報告の文化を構築する

トピック6.2の非難のない事後検証の原則をセキュリティに直接適用してください。自分が導入した脆弱性を発見し報告するエンジニア、あるいは外部で発見されたものを責任を持って開示する研究者は、失敗を告白しているのではなく価値あるサービスを提供していると扱われるべきです。内部からであれ外部の研究者からであれ開示を罰することは、脆弱性管理システム全体が依存するまさにその報告を確実に阻害し、本物のリスクを管理された是正のプロセスにではなく、地下に追いやります。

セキュリティの負債を技術的負債バックログ内の一つのカテゴリーとして扱う

競合する優先順位のために意図的にまだ是正されていない、既知の受け入れられたリスクの脆弱性を、トピック4.5で説明された同じ可視化され定量化された技術的負債バックログに、同じ修正コスト対抱え続けるコストの枠組みづけで組み込んでください。これは、セキュリティのリスクが見えない文書化されていない「私たちはそれを知っている」という状態に消えてしまうことも、その優先順位のための明示的で定量化された事例なしに機能の仕事と不公平に競争することも防ぎます。

脆弱性の指標を露出と悪用可能性の文脈と組み合わせる

同じ名目上の重大度スコアを持つすべての脆弱性が同じ実際のリスクを伴うわけではありません。外部ネットワークへの露出のない内部ツールにおける重大な脆弱性は、顧客データを扱うインターネットに面したサービスにおける同じ名目上の重大度とは異なるリスクです。可能な場合、重大度スコアだけでなく実際の露出と悪用可能性の文脈によって優先順位づけを重み付けし、是正の容量が本物に最もリスクの高い項目に最初に集中するようにしてください。

トレードオフ:長所と短所

アプローチ	長所	短所
生の脆弱性件数	報告が単純	取るに足らない問題と深刻な問題を混同する。抑圧によって容易にゲーミングされる
重大度加重の是正までの時間の追跡	時間をかけて実際のリスクの露出を反映する	規律ある一貫した分類と追跡が必要
純粋に内部の重大度の判断	柔軟で文脈に合わせられる	寛大な漂流とチーム間の一貫性のなさを招きやすい
標準化された外部のスコアリング(例:CVSS)に文脈の重み付けを加える	一貫性があり外部に根拠づけられ、ゲーミングに抵抗する	本物に正確な優先順位づけのために追加の文脈分析が必要

中心にある緊張関係は一貫性と文脈です。純粋に標準化されたスコアリングのアプローチは一貫性がありゲーミングに抵抗しますが、実際のリスクを決定する本物の文脈(露出と悪用可能性)を見逃すことがあります。純粋に文脈的で内部で判断されたアプローチはニュアンスを捉えますが、本書が他のすべての分類に依存する指標について警告する同じ寛大な漂流のリスクを招きやすいです。この緊張を、どちらかの極端だけではなく、標準化されたスコアリングを一貫した基準として根拠づけ、その上に文書化され監査可能な文脈の重み付けを適用することで解消してください。

チームで話し合うべき問い

私たちは重大度別の是正までの時間を追跡しているでしょうか、それとも生の脆弱性件数だけでしょうか。 実際の現在の指標を取り出し、それが何ヶ月も未修正のまま放置されている重大な問題を1日以内に修正されたものから区別しているかを確認してください。生の件数はこれらの非常に異なるリスクのある状況を同一に扱うからです。
私たちは標準化された外部の重大度スコアリングシステムを使っているでしょうか、それとも分類は純粋に内部の潜在的に一貫性のない判断に頼っているでしょうか。純粋に内部のものであるなら、CVSSのような標準を採用することが現在の分類の実践について何を変えるかを話し合ってください。
脆弱性を導入しそれを報告したエンジニアは、そうすることに安全を感じるでしょうか、それとも罰を恐れるでしょうか。 これはトピック6.2の非難のない文化の問いの直接のセキュリティ特有版であり、ここでの正直な答えは、あなたの脆弱性データがそもそも信頼できるかどうかに非常に重要です。
私たちは既知の受け入れられたリスクの脆弱性の可視化され定量化されたバックログを持っているでしょうか、それとも「私たちはそれを知っている」という状態が時間とともに静かに見えなくなり対処されないままになるでしょうか。あなたのセキュリティの負債が、あなたの一般的な技術的負債バックログ(トピック4.5)と同じ厳密さで追跡されているかを確認してください。
私たちの是正の優先順位づけは実際の露出と悪用可能性を考慮しているでしょうか、それとも文脈にかかわらず純粋に名目上の重大度スコアに頼っているでしょうか。同様の名目上の重大度を持つ二つの脆弱性が非常に異なる実際のリスクを伴っていた実際の事例を一つ選び、あなたの現在のプロセスがそれらを正しく優先順位づけしていたかどうかを話し合ってください。
脆弱性の重大度分類が、明確な正当化なしに時間とともに下方に漂流したことがあるでしょうか。 これはトピック1.2とトピック6.2の両方が警告する定義のゲーミングのパターンを反映しています。この特定のリスクについてあなたの最近の分類のサンプルを監査してください。

業種別の視点

スタートアップ。 正式な脆弱性管理のプロセスは非常に早い段階ではしばしば不要ですが、最初から基本的な自動依存関係スキャンと単純で正直な内部報告の規範を採用することはほとんどコストがかからず、チームがそれに体系的に対処する能力を持つ前にセキュリティの負債が目に見えない形で蓄積することを防ぎます。

中小企業。 ほとんどの現代の開発プラットフォームは、依存関係のための無料あるいは低コストの自動脆弱性スキャンを含んでいます。これを早期に有効にし、専任のセキュリティ機能や洗練されたツールがなくても、重大だと警告されたものについて是正までの時間を追跡してください。

企業。 一貫した標準化された重大度のスコアリングと本物に非懲罰的な開示文化は、どちらも不可欠であり、どちらも規模が大きくなると維持がより難しくなります。数十のチームにわたる一貫性のなさと、深刻なインシデントの後の非難を求める文化的な漂流が絶え間ないリスクだからです。分類の一貫性を維持し開示文化を積極的に保護するために専任のセキュリティガバナンス機能に投資してください。

政府。 ここでのセキュリティの指標は、しばしば国家安全保障、規制の遵守、公共の信頼に直接交差し、深刻で不適切に処理された脆弱性は典型的な民間部門の侵害をはるかに超える結果をもたらす可能性があります。厳密で外部に根拠づけられた重大度の分類を維持し、内部および外部の開示文化を積極的に保護し、本トピックが推奨する透明性と優先順位づけの厳密さでセキュリティの負債を扱ってください。公共インフラにおける文書化されていない静かに受け入れられた重大な脆弱性は、本物に深刻な監査可能なリスクだからです。

事例

企業。 あるソフトウェア会社のセキュリティチームは、何年もの間、リーダーシップに生の脆弱性件数だけを報告していました。その数字は横ばいの傾向にあり、誤った安定感を与えていました。改訂された重大度加重の是正までの時間の分析は、総件数が横ばいである一方で、重大な脆弱性は平均して90日以上かかって是正されていたことを明らかにしました。これはどんな合理的な目標をもはるかに超えており、専任の保護された容量なしに、すべての計画サイクルで機能の仕事に対して不成功に競争していたからです。トピック4.5の技術的負債の配分モデルを反映した保護されたセキュリティ負債是正の容量に裏付けられた、重大な脆弱性に対する厳格な7日間の是正目標を確立することは、2四半期以内に平均重大是正時間を5日未満に引き下げました。

政府。 ある国家インフラ機関は、外部のセキュリティ監査の後、内部のエンジニアが、自分たちのコードで発見した脆弱性を報告することを非公式に避けていたことを発見しました。それが彼らのパフォーマンスレビューに悪く反映されることを恐れていたからであり、これはトピック6.2の非難駆動のインシデントの過小報告のパターンの明確な類似です。機関は、内部の脆弱性の報告者をあらゆるパフォーマンスの結果から保護する明示的で公に伝えられたポリシーを、非難のないインシデント対応の実践を直接モデルとして導入し、内部の脆弱性の報告は翌年以内に実質的に増加しました。機関のリーダーシップは、この結果を、コードの品質の低下の証拠としてではなく、検知と正直な報告の改善の証拠として正しく解釈し、上昇する数字が必ず物事が悪化したことを意味するに違いないという自然だが間違った結論を避けました。

ビジネスケース:動機、ROI、総所有コスト

厳密で、よく分類され、正直に報告された脆弱性管理からの見返りは、回避された侵害のコストです。深刻なセキュリティインシデントについては、積極的な是正のコストを何倍も凌駕することが頻繁にあり、加えて回避された規制上、契約上、評判上の損害です。上記のソフトウェア会社の例は特定のメカニズムを示しています。セキュリティの負債は、保護された是正の容量がそれを直接修正するまで、何年もの間、機能の仕事に対する優先順位づけの競争に静かに負け続けていました。これはまさにトピック4.5が技術的負債全般について警告するパターンです。

総所有コストには、自動スキャンのツール、本トピックが割り当てることを推奨する保護された是正の容量、そして非懲罰的な開示の実践への持続的な文化的投資が含まれます。そのコストは、積極的でよく優先順位づけられた是正がそれが悪用される前に十分に捕捉し修正していたであろう、深刻で成功裏に悪用された脆弱性のコストと比較して穏やかです。

アンチパターンと落とし穴

生の脆弱性件数だけを追跡する。 取るに足らない問題と深刻な問題を混同し、実際のリスクにかかわらず誤った安定感あるいは危機感を与えます。
純粋に内部の標準化されていない重大度分類。 寛大な漂流とチーム間の一貫性のなさを招きやすいです。
内部からであれ外部からであれ脆弱性の開示を罰する。 本物のリスクを管理された是正のプロセスにではなく地下に追いやります。
可視化され定量化されたバックログのないセキュリティの負債。 既定で機能の仕事に対する優先順位づけの競争に負けます。
露出と悪用可能性の文脈を無視して名目上の重大度スコアだけで優先順位づける。 限られた是正の容量を誤導します。
報告自体が改善したかどうかを確認せずに、上昇する脆弱性の報告件数を品質の低下の証拠として解釈する。 トピック1.6の交絡変数の罠の特定の事例です。

成熟度モデル

レベル1、開始: 脆弱性は、追跡されているとしても、重大度加重も是正時間の追跡もなく、懲罰的な開示文化を伴う生の件数として追跡されています。
レベル2、発展: いくつかの重大度分類が存在しますが、基準は一貫性がなく、是正時間は明示的な目標に対して追跡されていません。
レベル3、標準化: 標準化され外部に根拠づけられた重大度のスコアリングと重大度別の明示的な是正時間の目標が、本物に非懲罰的な開示文化とともに一貫して適用されています。
レベル4、管理: セキュリティの負債は、保護された是正の容量を伴う可視化され定量化されたバックログで追跡されています。優先順位づけは重大度だけでなく露出と悪用可能性の文脈を考慮しています。
レベル5、最適化: 組織は、重大な是正時間における具体的で測定可能な削減を指し示すことができ、正直で包括的な脆弱性データを生み出す持続的で信頼された開示文化を実証できます。

議論のためのアイデア

私たちの現在の重大な脆弱性の平均是正までの時間はどれくらいで、それは明示的な目標を満たしているでしょうか。
脆弱性を導入したエンジニアは、自分でそれを報告することに安全を感じるでしょうか。
私たちは既知の受け入れられたリスクのセキュリティ負債の可視化され定量化されたバックログを持っているでしょうか。
私たちの是正の優先順位づけは実際の露出を考慮しているでしょうか、それとも名目上の重大度だけでしょうか。
重大度の分類が明確な正当化なしに時間とともに下方に漂流したことがあるでしょうか。

主な要点

主要なセキュリティの健全性の指標として、生の脆弱性件数ではなく重大度別の是正までの時間を追跡してください。
純粋に内部の判断が招く寛大な漂流のリスクに抵抗する一貫した基準として標準化された外部の重大度のスコアリング(CVSSなど)を使ってください。
本物に非懲罰的な開示文化を構築してください。報告を罰することは本物のリスクを地下に追いやります。
セキュリティの負債を技術的負債の一つのカテゴリーとして扱い(トピック4.5)、保護された是正の容量を公平に競争させてください。
重大度スコアだけでなく実際の露出と悪用可能性によって優先順位づけを重み付けしてください。

参考文献とさらなる読書

FIRST.orgの共通脆弱性評価システム(CVSS)仕様。
脆弱性管理と安全なソフトウェア開発ライフサイクルの実践に関するOWASP財団のリソース。
Site Reliability Engineering: How Google Runs Production Systems, Betsy Beyer、Chris Jones、Jennifer Petoff、Niall Richard Murphy 編。
NIST特別刊行物800-40、Guide to Enterprise Patch Management Planning。