SAP-C02-111 · セクション 13 / タスク 3.2
既存環境のSecurity Postureを評価する
セキュリティ体制 / 既存の制御 / 設定ミス / 露出 / 脆弱性 / リスク / 修復優先度
既存環境のセキュリティを改善するとき、最初から新しいセキュリティサービスや制御を追加するとは限りません。
すでに多くのセキュリティ制御が実装されていても、
- 一部のリソースには適用されていない
- 設定ミスによって意図した保護が成立していない
- 複数の弱点が組み合わさってリスクが高くなっている
- 重要なリスクより修正しやすい問題を優先している
といった状況では、環境全体として十分なセキュリティ体制とは評価できません。
まず、
現在どの制御が存在するか
↓
実際にどこまで機能しているか
↓
制御後に何のリスクが残っているか
↓
何から修復するかを評価します。
ゴール
既存環境について、
- 現在のセキュリティ体制を証拠から評価する
- 既存の制御の存在と実効性を区別する
- 複数のセキュリティシグナルを環境の文脈と組み合わせる
- 既存の制御を考慮した残差リスクを評価する
- 修復優先度を単一の重要度や件数だけで決めない
- 修復後にリスクが実際に低下したことを確認する
ことを目指します。
1. セキュリティ体制は「導入済み機能の一覧」ではない
セキュリティ体制を評価するとき、
暗号化している
ログを取得している
アクセス制御がある
脆弱性を検出しているといった機能の存在だけを確認しても不十分です。
重要なのは、
期待している保護
↓
実際の環境
↓
差異を確認することです。
例えば、組織標準として特定の制御を定義していても、一部のリソースが対象外なら、その部分には保護の抜けがあります。
したがって、「制御があるか」ではなく「必要な対象で期待どおり機能しているか」を確認します。
2. 評価には実環境の証拠を使う
設計書や運用ルールは、
本来どうなっているべきかを示します。
一方、セキュリティ体制を評価するには、
現在どうなっているかを示す証拠も必要です。
例えば、
現在のリソース設定
制御の適用状況
例外となっているリソース
検出されている問題
到達可能性
既存の制御による保護などを確認します。
期待状態
+
実環境の証拠
↓
差異を特定という形で評価します。
3. 既存の制御は「存在・範囲・実効性」で見る
既存の制御を評価するときは、導入済みかどうかだけでは判断しません。
存在
必要な制御自体があるか。
適用範囲
保護すべき対象へ実際に適用されているか。
実効性
期待しているリスク低減につながっているか。
例えば、
制御あり
↓
100個中90個のリソースへ適用
↓
10個は対象外なら、「制御を導入済み」という事実だけから、「すべての対象が保護されている」とは評価できません。
また、制御が設定されていても、設定内容が期待状態から外れていれば、想定したリスク低減にはなりません。
4. 個々の検出結果ではなく組み合わせを見る
設定ミス、脆弱性、到達可能性などの基本概念は既習です。
セキュリティ体制の評価では、それぞれを単独で再評価するのではなく、
検出された弱点
+
到達可能性
+
対象の重要性
+
既存の制御
↓
現在残っているリスクのように組み合わせます。
例えば、同じ脆弱性が存在していても、
重要な本番システム
外部から到達可能
有効な追加制御がない場合と、
検証環境
外部から到達不可
複数の制御で利用経路を限定されている場合では、残っているリスクが同じとは限りません。
ここで重要なのは、検出結果を分類し直すことではなく、複数の事実をセキュリティ体制の評価へ結び付けることです。
5. 既存の制御を考慮して残差リスクを見る
セキュリティ体制を評価するときは、
問題が見つかった
=
その問題の最大リスクがそのまま残っているとは考えません。
既存の制御が実際に機能していれば、悪用可能性や影響が低減されている場合があります。
問題そのものが持つリスク
↓
既存の制御による低減
↓
それでも残る残差リスクを確認します。
ただし、
制御あり
→ リスク0でもありません。
さらに、1つの制御がすべてのリスク要因を低減するとは限りません。
例えば、
ある攻撃経路を制限する制御が有効でも、
別の経路
過剰な権限
認証情報の悪用などまで同時に解消するとは限りません。
そのため制御について、
どの対象へ適用されているか
実際に機能しているか
どのリスク要因を低減しているか
何が低減されずに残っているかを確認したうえで、残差リスクを評価します。
6. 同じ検出結果でも環境によってリスクは変わる
例えば、同じ重要度の問題が2つのリソースで検出されたとします。
リソースA
本番
外部から利用可能
重要な業務を処理
リソースB
検証環境
利用経路を制限
既存の制御も有効検出された問題そのものが同じでも、環境内でのリスクが同じとは限りません。
確認するのは、
悪用される可能性
対象へ到達できる条件
対象リソースの重要性
想定される影響
既存の制御です。
個々の検出結果の重要度は、最終的な修復優先度を決める材料の1つとして扱います。
7. 複数のシグナルを1つのリスクとして捉える
実環境では、1つの問題だけを見ると重要性を判断しにくい場合があります。
例えば、
単独では限定的な設定ミス
+
到達可能な経路
+
重要なデータが同じリソースや経路上で関連していれば、個別の検出結果だけを見るより高いリスクになる可能性があります。
逆に、重大な検出結果でも、
利用経路が制限されている
+
既存の制御が実際に有効
+
対象の業務影響が限定的なら、他の問題を先に修復する合理的な場合があります。
したがって、
検出結果を個別に並べるだけではなく、
関連するシグナル
↓
環境の文脈
↓
既存の制御
↓
残差リスクとして評価します。
8. 修復優先度は「件数」だけで決めない
例えば、
低い残差リスク
50件と、
重大な業務へ影響する
高い残差リスク
1件が存在するとします。
件数だけを減らすなら50件を先に直したくなります。
しかし、セキュリティ改善で見るべきなのは、どの修復が大きなリスク低減につながるかです。
修復優先度を考える材料には、
悪用される可能性
到達可能性
想定される影響
対象の重要性
既存の制御の実効性などがあります。
9. 重要度と修復優先度は同じとは限らない
検出された問題には、重大、高、中、低などの重要度が付く場合があります。
重要度は有用な判断材料ですが、
重要度
=
自社環境での最終優先度とは限りません。
例えば同じ重要度でも、
外部から容易に悪用可能
既存の制御によって利用経路が強く制限では、残差リスクが異なる可能性があります。
したがって、
問題そのものの重要度
+
環境の文脈
+
既存の制御
↓
残差リスク
↓
修復優先度として判断します。
10. セキュリティスコアだけで全体を判断しない
多数のチェック結果を集約したスコアや準拠率は、セキュリティ体制を把握する材料になります。
ただし、
ほとんどのチェックが正常だからといって、
重大な残差リスクがないとは限りません。
例えば、100個のチェックのうち99個が正常でも、残り1個が重要なシステムへの大きなリスクにつながっていれば、その問題を無視できません。
スコアや準拠率は、セキュリティ体制を評価する証拠の1つとして扱います。
11. 修復したら再評価する
設定を変更したり、弱点を修正したりしたら、その作業が正常終了しただけで完了とはしません。
問題を特定
↓
リスクを評価
↓
修復
↓
実環境を再確認
↓
残差リスクを再評価と進めます。
例えば外部到達経路を修正した場合も、
変更処理成功だけではなく、
本当に到達できなくなったか
別の経路が残っていないか
期待した制御が有効かまで確認します。
セキュリティ体制は一度評価して終わるものではなく、環境変更や新しい問題の発生に応じて変化します。
12. 評価の全体フロー
既存環境では、次の順序で考えます。
期待するセキュリティ状態を確認
↓
既存の制御を確認
↓
実環境の証拠を確認
↓
期待状態との差異を特定
↓
関連するセキュリティシグナルを確認
↓
既存の制御と環境の文脈を加える
↓
残差リスクを評価
↓
修復優先度を決める
↓
修復
↓
再評価この段階では、
どのAWSサービスで修復するかよりも、
現在どのリスクが残っているか
何から対応するべきかを明らかにすることが先です。
13. 混同しやすいポイント
| 誤りやすい判断 | 正しい考え方 |
|---|---|
| 制御を導入済みだから安全 | 適用範囲と実効性も確認する |
| 検出結果が重大なら必ず最優先 | 環境内の残差リスクを確認する |
| 問題数が多いカテゴリを優先 | リスク低減効果で優先する |
| スコアが高ければ重大リスクはない | 個々の残差リスクも確認する |
| 修復処理が成功すれば完了 | 修復後の状態と残差リスクを再評価する |
14. アンチパターン
導入済み制御の数で評価する
多くの制御があっても、必要な対象へ適用されていなければ十分ではありません。
検出結果を個別にしか見ない
複数のシグナルやリソース関係を組み合わせると、単独では見えにくいリスクが明確になる場合があります。
重要度だけで修復順を決める
環境の文脈や既存の制御を考慮しないと、実際の残差リスクと修復順序がずれる可能性があります。
修復したことを検証しない
変更処理の成功と、リスクが実際に低減したことは同じではありません。
15. SAP-C02での判断手順
シナリオでは、次の順序で確認します。
1. 期待されるセキュリティ状態は何か
↓
2. 既存の制御は何か
↓
3. 必要な対象で実際に機能しているか
↓
4. どのセキュリティシグナルが存在するか
↓
5. それらはどのように関連しているか
↓
6. 既存の制御で何が低減されているか
↓
7. 現在の残差リスクは何か
↓
8. 修復優先度を決定問題文に多数のセキュリティ機能が登場しても、「導入済みか」ではなく「現在のリスクをどこまで低減できているか」を確認します。
まとめ
既存環境のセキュリティ体制は、
制御の数
セキュリティ製品の数
検出結果の件数だけでは評価できません。
重要なのは、
期待する状態
↓
実際の制御
↓
実環境の証拠
↓
関連するセキュリティシグナル
↓
既存の制御による低減
↓
残差リスク
↓
修復優先度という関係です。
特に、
制御の存在
≠
制御の実効性
検出結果の重要度
≠
環境内の残差リスク
残差リスク
→
修復優先度を区別します。
修復後も状態を再評価し、実際にリスクが低下したことまで確認します。