セキュリティ評価報告書

これは何か

セキュリティ評価報告書は、システムの安全性を決めた範囲と方法で調べ、見つかった弱点（脆弱性）と、その対応の状況を、判断する人に報告する成果物です。

脆弱性とは、悪用されると情報の漏えいや改ざん、システムの停止などにつながる弱点のことです。報告書は「安全です」と宣言する文書ではありません。何を調べ、何を調べていないかをはっきりさせたうえで、見つかったことを示します。

なぜ作るか

• 判断する人が、見つかった弱点と対応の状況を1か所で確かめられる
• 調べた範囲と調べていない範囲を分け、「調べていないのに安全と思い込む」ことを防ぐ
• 直さずに残す弱点がある場合、その理由と受け入れた人を記録に残す
• 次の評価で、前回からの変化を確かめられる

誰が使うか・いつ作るか

• 作る人：評価を行う担当（社内のセキュリティの担当、または外部の評価の専門家）
• 読む人：セキュリティの責任者、システムの担当、稼働の判断に関わる人
• 一般的には、評価の時期と範囲をプロジェクトの計画で決め、評価のたびに作ります。いつ・何回行うかは、プロジェクトごとに決めます
• アステリア案件の評価の範囲・方法・時期・結果は、正本に記載がありません。未確定

アステリア案件で、誰がどの範囲を評価し、何が見つかり、どう扱われたかは、正本に記載がありません。未確定 危機演習で扱う出来事は、危機演習の中で扱います。

主な項目

一般的には、次の項目で構成します。

1. 目的と範囲：何のために、どのシステム・機能・環境を調べたか。調べていないものも書く
2. 方法：どのような調べ方をしたか（設計の確認、設定の確認、専門のツールによる検査、専門家による疑似的な攻撃の試験など）
3. 時期と版：いつ、どの版のシステムを調べたか
4. 見つかったことの一覧：弱点ごとに、内容・場所・重大度・再現の手順・対応の案
5. 重大度の基準：重大度を何で決めたか
6. 対応の状況：直した、直す予定、直さずに受け入れる、の区別と期限
7. 残るリスク：直さずに残す弱点と、その理由・受け入れた人
8. 評価者と日付

読み方

1. まず「調べていない範囲」を読む。そこは安全とも危険とも言えない
2. 調べた時期と版が、今のシステムと同じか（その後に変わった部分はないか）
3. 重大度の高いものから、状態と期限を見る
4. 「修正済み」に、直ったことを再び確かめた記録があるか
5. 直さずに受け入れるものに、理由と受け入れた人が書かれているか

書き方

1. 評価の前に、目的・範囲・方法・重大度の基準を決め、関係者と合意する
2. 評価を行い、見つかったことを1件ずつ、再現の手順とともに記録する
3. 重大度を、決めた基準で付ける（感覚で付けない）
4. システムの担当と、対応の案・期限を決める
5. 直したものは、もう一度確かめてから「修正済み」にする
6. 残るものは、受け入れるかどうかを判断する人に上げる

何を書いてはいけないか

• 範囲を書かずに「問題なし」とだけ書く
• 直ったことを確かめていないのに「修正済み」とする
• 弱点を悪用する具体的な手順を、多くの人が見られる場所に書く（報告書の扱いを限定する）

よくある失敗

• 見つかったことを、直す担当のチームに具体的に伝えない
• 報告書を受け取っただけで、対応の進み具合を追いかけない
• 重大度の低いものを放置し続け、組み合わさって大きな弱点になる

関係するUnit・成果物・危機演習

• Unit：08-01 ログインできれば安全なのか、10-05 障害の重大度をどう決めるのか、10-06 テストをいつ終了してよいのか、12-05 誰が本番稼働を決めるのか
• 成果物：SEC-001 セキュリティ基本方針、SEC-002 権限設計表、CUT-005 本番稼働判定資料、PRG-006 課題・リスク管理表
• 危機演習：CR10 重大な脆弱性が発見される（学習上の接続です。正式な対応関係ではありません）

いつ使うか

この教材では STAGE 08｜誰に何を許可するのか の文脈で扱います。 アステリア案件での正式な作成・使用時期（月）は正本に記載がないため、未確定としています。