クイズの説明
Step 5「セキュリティメトリクスを定義しよう」の理解度を確認します。セキュリティメトリクス、ダッシュボード設計、成熟度モデルについて問います。
合格ライン: 80%（5問中4問正解）
問題
Q1. MTTRの定義
セキュリティメトリクスにおけるMTTR（Mean Time to Remediate）の正しい定義はどれですか？
- A. 攻撃が発生してからセキュリティチームが気づくまでの平均時間
- B. セキュリティインシデントの発生から完全復旧までの平均時間
- C. 脆弱性が検出されてから修正が完了するまでの平均時間
- D. セキュリティパッチが公開されてからベンダーが適用するまでの平均時間
答えを見る
正解: C
MTTR（Mean Time to Remediate）は、脆弱性が検出（SAST/DAST/SCA等で発見）されてから、修正が完了（コードの修正がデプロイされ、脆弱性が解消される）するまでの平均時間です。A（気づくまでの時間）はMTTD（Mean Time to Detect）です。B（発生から復旧まで）はインシデント対応のMTTR（Mean Time to Recover）であり、脆弱性管理のMTTRとは異なります。D（パッチ公開から適用まで）はパッチ適用時間（Patch Latency）です。
Q2. ダッシュボードの対象者設計
以下のメトリクスのうち、Executive（経営層向け）ダッシュボードに最も適切なものはどれですか？
- A. 個別のCVE-IDとその修正状況のリスト
- B. Semgrepのルール別検出件数
- C. セキュリティヘルススコアとコンプライアンス準拠率のトレンド
- D. DASTスキャンのHTTPリクエスト/レスポンス詳細
答えを見る
正解: C
Executiveダッシュボードは「全体の健全性」と「ビジネスリスク」を一目で把握できるものであるべきです。セキュリティヘルススコア（全体的な健全性の数値化）とコンプライアンス準拠率のトレンド（規制対応の状態と改善/悪化）は、経営判断に直結する情報です。A（個別CVEリスト）とD（HTTPリクエスト詳細）はOperationalレベルの情報であり、経営層には粒度が細かすぎます。B（ルール別検出件数）はTeamレベルの開発者向け情報です。
Q3. セキュリティヘルススコア
セキュリティヘルススコアを算出する際に、最も重要な設計原則はどれですか？
- A. スコアを常に80点以上に見えるように計算式を調整する
- B. すべてのカテゴリを同じ重みで計算し、公平性を確保する
- C. 各カテゴリに組織のリスク優先度に応じた重みを設定し、改善アクションに繋がるスコアにする
- D. 業界平均のスコアと比較できるように、標準化された計算式を使用する
答えを見る
正解: C
セキュリティヘルススコアの目的は「現在の状態を正確に反映し、改善すべきポイントを明確にする」ことです。組織のリスク優先度（例: PCI-DSS準拠が最優先の組織ではコンプライアンスの重みを上げる）に応じて重みを設定することで、スコアの変化が具体的な改善アクションに繋がります。A（80点以上に調整）は現実を隠蔽することになり危険です。B（同じ重み）は組織のコンテキストを反映しません。D（標準化）は理想的ですが、組織固有の事情を反映できないため最優先ではありません。
Q4. OWASP SAMMの活用
OWASP SAMMで「脅威モデリングがLevel 0（未実施）」と評価された組織が、Level 2を目指す場合の適切なアプローチはどれですか？
- A. 全システムを対象に脅威モデリングを一斉に実施する
- B. まず1つの重要システムで脅威モデリングを試行し（Level 1）、その後プロセスを文書化して組織全体に展開する（Level 2）
- C. 外部のペネトレーションテストを実施して脅威モデリングの代替とする
- D. 脅威モデリングツールを購入し、全チームにライセンスを配布する
答えを見る
正解: B
OWASP SAMMの成熟度は段階的に向上させるものです。Level 0からいきなりLevel 2を目指すのではなく、まずLevel 1（1つの重要システムで試行し、チームが脅威モデリングの手法を身につける）を経て、Level 2（プロセスを文書化し、組織全体に展開して体系的に実施）に進みます。A（一斉実施）は準備不足で形骸化するリスクが高いです。C（ペネトレーションテスト）は脅威モデリングの代替にはなりません。D（ツール購入）はツールの導入だけでは成熟度は向上しません。
Q5. アラート設計
セキュリティダッシュボードのアラート設計において、最も注意すべきことはどれですか？
- A. できるだけ多くのアラートを設定して、見逃しをゼロにする
- B. アラートの閾値を厳しくして、少しでも異常があれば通知する
- C. アクション可能なアラートのみ設定し、アラート疲れ（Alert Fatigue）を防ぐ
- D. すべてのアラートをメールで送信し、確実に受信できるようにする
答えを見る
正解: C
アラート設計で最も注意すべきは「アラート疲れ（Alert Fatigue）」の防止です。過剰なアラートは、重要なアラートが他のノイズに埋もれる原因となり、結果としてCriticalなアラートも無視されるようになります。アラートは「このアラートを受けた人が、具体的に何をすべきか」が明確なもの（Actionable Alert）のみ設定すべきです。A（できるだけ多く）とB（閾値を厳しく）はアラート疲れを引き起こします。D（メール送信）は通知手段の話であり、アラートの質の改善には繋がりません。
結果
合格（4問以上正解）
Step 5の内容をよく理解しています。セキュリティメトリクスの設計、ダッシュボードの構築、成熟度モデルの活用方法を身につけました。次のStep 6「セキュリティパイプラインを完成させよう」に進みましょう。
不合格（3問以下正解）
Step 5の内容を復習しましょう。特に以下のポイントを重点的に確認してください：
- MTTR — 脆弱性の検出から修正までの時間
- ダッシュボードの3層設計 — Executive、Operational、Teamの対象者別設計
- セキュリティヘルススコア — 重み付きスコアの算出と改善への活用
- 成熟度モデル — 段階的な向上と各レベルのチェックリスト
推定所要時間: 15分