ISCでは、統制名を暗記するより、誰がどのリスクを受け入れ、どの証拠で有効性を確かめ、障害や侵害からどう復旧するかをつなげることが重要です。本稿はガバナンスから運用・インシデント対応までを同じフレームで復習するための実践ガイドです。
- 取締役会のリスク許容度・責任・監督はNIST CSFのGovernに置く
- 職務分掌はアカウント数ではなく、相反する承認・実行の役割を分ける
- 継続監視の頻度は影響度・脅威変動・システム変更を含むリスクベースで決める
- 証拠保全は取扱い履歴と完全性を残し、原因や攻撃者の断定とは分ける
- 可用性・処理完全性・プライバシーは目的と証拠の種類で見分ける
読んだ知識を、次の学習へ。
会員情報を確認しています。
1|Governから始めて、技術統制を組織目標に接続する
NIST Cybersecurity Framework 2.0のGovernは、組織の状況、戦略、方針、役割・責任、監督を扱います。取締役会がリスク許容度を承認し、経営目標との整合性を確認する場面は、ProtectやDetectより先にGovernへ分類します。
問題では、技術的な対策が書かれていても、その対策を誰が承認し、どのリスクを受け入れ、どの指標で監督するかを問う場合があります。資産の棚卸しや脆弱性スキャンだけでガバナンスの問いに答えないようにします。
- Govern:方針、戦略、責任、監督、リスク許容度
- Identify:資産、脅威、脆弱性、影響を理解する
- Protect/Detect/Respond/Recover:運用上の防御・検知・対応・復旧
2|職務分掌は「同じ人が相反する操作を完結できないか」で判断する
開発者が自分のコードを承認し、そのまま本番へデプロイできるなら、同一人物が相反する工程を完結できます。NIST SP 800-53の職務分掌を実装するには、独立した承認者と、承認後に別のリリース工程が実行する仕組みを組み合わせます。
個人に2つのアカウントを渡したり、操作を私的なメモへ記録させたりするだけでは、独立性や予防効果は生まれません。ロール、ワークフロー、ログ、緊急時の事後レビューを一組で確認します。
3|継続監視の頻度を固定カレンダーにしない
NIST SP 800-137の継続監視は、リスクベースでシステムの状態を可視化します。高影響システム、脅威が急速に変化する環境、変更頻度の高いアプリケーションでは、低影響で安定した資産より短い間隔・深い検証が必要になる可能性があります。
監視指標は、検知件数だけでなく、重大度、対応時間、未解決期間、変更率、例外の承認状況を組み合わせます。ベンダー推奨や年1回の予定をそのまま採用せず、組織の許容リスクと影響度で説明できるかを確認します。
- システムの機密性・完全性・可用性への影響
- 脅威・脆弱性の変動性と、構成変更の速さ
- 組織のリスク許容度、証拠の深度、担当者の対応能力
4|インシデント対応は証拠の完全性と復旧を別々に管理する
侵害が疑われるとき、フォレンジックイメージの収集・移転・アクセス・保管を記録するchain of custodyは、誰がいつ扱い、改変されていないかを後から検証するための仕組みです。これだけで攻撃者の身元や原因が確定するわけではありません。
NIST SP 800-61 Rev. 3の考え方では、準備、検知・分析、対応、復旧と、活動から得た改善を循環させます。事後に証拠を一括保存するのではなく、時刻同期、ログ保持、エスカレーション、法務・顧客への連絡条件を平時に定めます。
5|可用性はRTO・RPO・計画維持・テストで証拠化する
可用性の評価では、サービスを使える状態に戻す目標時間(RTO)と、失っても許容できるデータ時点(RPO)を、業務影響と対応策に結び付けます。バックアップが存在するだけでは、目標を満たすことや復元できることの証拠になりません。
NIST SP 800-34 Rev. 1のコンティンジェンシープランは、重要なアーキテクチャ変更や演習で回復前提が崩れた場合に更新します。復旧手順、依存サービス、担当者、連絡先、代替サイトを実際にテストし、結果を次の改訂へ反映します。
- RTO:サービス停止から復旧までの目標時間
- RPO:復旧時点で許容するデータ損失の時間幅
- テスト結果・未解決課題・依存関係を計画へ戻す
6|プライバシー・処理完全性・自動化統制を目的で見分ける
顧客へ収集データ、利用目的、プライバシー上の選択肢を説明するなら、NIST Privacy FrameworkのCommunicate-Pが中心です。個人が選択を実行できる仕組み(Control-P)や技術的保護(Protect-P)と関連しますが、設問の焦点を優先します。
AICPA Trust Services CriteriaのProcessing Integrityは、処理が完全・有効・正確・適時・承認済みかを扱います。システムが稼働しているかというAvailability、未承認開示を防ぐConfidentialityとは証拠が異なります。
PCAOB AS 2201の自動化統制では、基準時点からアプリケーション統制が変わっておらず、IT全般統制が有効に継続していることを検証できる場合、ベンチマーキングで同じ運用有効性テストの反復を減らせます。条件確認を省略してよいという意味ではありません。
7|ISCの誤答はリスク・統制・証拠の3列で復習する
問題を解いたら、左に守る対象とリスク、中央に最も直接的な統制、右に有効性を裏付ける証拠を書きます。例えば『未承認変更/独立承認と分離デプロイ/承認ログと変更チケット』のように一行でまとめると、別の技術やベンダー名が出ても判断を再利用できます。
最後に、ISCの問題演習へ進み、選択肢が同じ目的をどれだけ直接に満たすかを確認してください。NIST、AICPA、PCAOBの最新版や組織の契約・法務要件が優先されるため、基準の更新日も定期的に確認します。
公式情報・参考資料
制度や出題範囲は変更される場合があります。最終確認には以下の公式情報をご利用ください。
- NIST|Cybersecurity Framework 2.0 FAQs↗
- NIST SP 800-53 Rev. 5|Security and Privacy Controls↗
- NIST SP 800-61 Rev. 3|Incident Response Recommendations↗
- NIST SP 800-137|Information Security Continuous Monitoring↗
- NIST SP 800-34 Rev. 1|Contingency Planning Guide↗
- NIST|Privacy Framework↗
- AICPA|2017 Trust Services Criteria (revised points of focus 2022)↗
- PCAOB AS 2201|An Audit of Internal Control Over Financial Reporting↗
この記事を、解ける知識に変える。
同じ論点を短く復習し、問題で使い、Cheat Sheetへ戻る学習パスです。