セキュリティ例外を「承認済み」で放置しない ─ 期限と残存リスクを回す5ステップ

パッチを適用できない。多要素認証に対応していない。管理画面を業務上インターネットへ公開せざるを得ない。標準設定を満たさないシステムを、期限付きで使い続ける必要がある。こうした状況で、現場の制約と事業継続を両立するためにセキュリティ例外を認めること自体は、必ずしも誤りではありません。

問題は、例外申請が承認された瞬間に管理が終わることです。「更改まで」「代替製品が出るまで」「業務が落ち着くまで」という条件だけでは、見直しのきっかけが曖昧です。担当者の異動やシステム変更を経て、当初は一時的だった判断が恒久的な弱点になり、脆弱性診断や監査のたびに同じ説明を繰り返す状態へ陥ります。

NIST IR 8286 Rev.1は、サイバーリスクを事業目的と結び付けてリスク登録簿に記録し、対応後に残るリスクを組織のリスク選好・許容度と照らして判断する考え方を示しています。例外は「基準を守らなくてよい許可証」ではなく、制約下で選んだリスク対応を、責任ある判断として追跡する仕組みです。

課題：例外台帳が、承認済み一覧で止まる

第一の課題は、例外の対象範囲が広すぎることです。「旧システムの脆弱性」「海外拠点の認証」のような件名だけでは、どの資産、機能、利用者、データ、通信経路が例外に含まれるのか分かりません。適用範囲が曖昧なまま環境が拡大すると、承認時に想定していなかった利用まで例外扱いになります。

第二の課題は、代替統制が実施予定のまま確認されないことです。ネットワーク分離、接続元制限、特権監視、追加ログ、手動確認などを申請書へ書いても、設定と運用が続いているかを確かめなければ、実際の残存リスクは評価できません。代替統制が別チームや委託先に依存する場合は、責任の空白も起きやすくなります。

第三の課題は、有効期限だけで管理することです。期限を設定しても、誰が何を見て更新・終了を判断するかが決まっていなければ、満了直前に自動更新されます。新たな脆弱性、攻撃の活発化、重要度の上昇、利用範囲の拡大、代替策の提供開始といった変化は、期限を待たずにリスクを変えます。

考え方：例外を「一時的なリスク判断」として管理する

例外管理の中心に置くのは、標準から外れた事実だけではありません。守る事業、想定する脅威、影響を受ける資産、現行の管理策、追加する代替統制、それでも残るリスク、判断者、期限、再評価条件、終了方法を一つの判断記録にします。これにより、技術担当は対応内容を、事業責任者は受け入れる影響を、承認者は判断根拠を同じ情報から確認できます。

NIST SP 1303は、NIST CSF 2.0の共通言語を使い、組織やプログラムをまたいでリスクの監視・評価・調整を統合する考え方を示しています。例外台帳も、個別システムの申請箱に閉じず、重要業務やリスク登録簿とつなぐことで、期限超過の件数ではなく事業として受け入れている残存リスクを説明できます。

英国NCSCは、リスクをゼロにできないことを前提に、回避、受容、低減、移転などの選択肢と将来の結果を、意思決定者が理解できる形で示す重要性を説明しています。例外を認めるときも、「技術的に直せないから」だけでなく、どの選択肢を比較し、なぜ現在の判断が事業にとって妥当なのかを残します。

実践手順：期限と残存リスクを回す5ステップ

1．例外の対象と事業影響を限定する

例外の対象を、資産ID、システム、機能、環境、利用者、データ、接続経路まで絞ります。標準のどの要求を、どの範囲で、いつから満たせないのかを明記し、同じ製品や部署へ自動的に横展開しないようにします。例外範囲を図や構成情報へひも付けると、変更時の照合が容易になります。

次に、悪用された場合のシナリオを一つ以上書きます。「機密性・完全性・可用性への影響」だけでなく、停止する業務、影響する顧客・取引先、法令・契約、復旧時間、他システムへの波及を整理します。例外の必要性と、例外を認めない場合の事業影響も並べることで、単なる技術都合ではなく選択肢の比較になります。

2．リスク所有者と判断根拠を記録する

申請者、実施責任者、リスク所有者、承認者を分けます。リスク所有者は、影響を受ける事業について権限と説明責任を持つ人です。セキュリティ部門は分析や条件設定を支援できますが、事業影響を受け入れる最終判断まで代理しないようにします。高い残存リスクや法令・契約に関わる例外は、あらかじめ定めた経営・法務・リスク管理の判断へ上げます。

判断記録には、検討した選択肢、採用しなかった理由、現在のリスク水準、目標とする残存リスク、承認条件を含めます。NIST IR 8286 Rev.1は、対応後の実際の残存リスクが目標残存リスク以下であるかを確認し、必要に応じて追加対応や回避を検討する流れを示しています。例外承認を、残存リスクを無条件に受容する行為と混同しないことが重要です。

3．代替統制を実装し、効いている証拠を残す

標準管理策を実施できない場合、攻撃可能性や影響を下げる代替統制を決めます。例えば、インターネット公開を止められない管理画面なら、専用のアクセス経路、送信元制限、フィッシング耐性のある認証、操作ログ、異常検知、緊急遮断手順を組み合わせます。パッチできない機器なら、分離、許可通信の限定、監視、保守端末の統制、交換計画を検討します。

代替統制には、所有者、実装期限、確認方法、確認頻度、証跡の保存先を設定します。「監視を強化する」ではなく、「誰が、どのログを、どの条件で確認し、何を検知したら誰へ連絡するか」まで具体化します。設定画面、テスト結果、ログサンプル、訓練記録などを残し、例外の有効期間中も機能していることを確認します。

4．有効期限とイベント起点の再評価条件を設定する

有効期限は、単に一年後と置くのではなく、恒久対応に必要な調達、更改、開発、契約、検証の計画と合わせます。期限までのマイルストーン、予算、依存関係、完了条件を設定し、例外の更新が対応計画の代わりにならないようにします。長期対応が必要な場合も、短い確認周期で代替統制とリスクを点検します。

さらに、期限前でも再評価するイベントを決めます。重大な脆弱性の公開、悪用の確認、インシデント、資産の重要度変更、データ種別の変更、利用者増加、外部公開範囲の拡大、委託先変更、代替製品の提供開始、代替統制の停止などです。NIST SP 800-37 Rev.2が示す継続的監視とイベント起点の判断を、例外管理にも組み込みます。

5．終了・更新・上位判断を証跡で閉じる

期限や再評価イベントが来たら、元の申請書をコピーして日付だけ変えないようにします。対象範囲、脅威、事業影響、代替統制の実効性、残存リスク、恒久対応の進捗を再確認し、「終了」「条件付き更新」「追加対応」「利用停止・回避」「上位判断」のいずれかを選びます。更新回数や累積期間が閾値を超えた例外は、自動更新を禁止して投資判断へ上げます。

終了時は、標準準拠の確認、代替統制の撤去、監視ルールの整理、台帳・構成情報・手順の更新まで行います。例外が不要になっても、暫定的に開けた通信や追加アカウントが残れば別の弱点になります。閉鎖証跡を残し、同種の例外が繰り返されていないかを振り返って、標準や調達要件の改善へ戻します。

注意点：厳しくするだけでは、例外は減らない

• 例外ゼロを目標にしない：隠れた未準拠を増やさず、事業上必要な判断を見える形にすることが目的です。
• 軽微な案件まで同じ会議へ上げない：事業影響、外部公開、データ、法令、期間などで承認レベルを分けます。
• 有効期限だけをKPIにしない：残存リスク、代替統制の有効性、累積期間、再発、終了率を併せて見ます。
• 申請者と承認者だけで閉じない：実際に代替統制を運用する担当者と、事業リスクを所有する責任者を含めます。
• 自動更新を標準にしない：変更がないことを確認した証拠がなければ、現状維持とは判断できません。
• 機微情報の扱いを決める：脆弱性、構成、残存リスクを含むため、閲覧範囲、保存期間、外部共有を管理します。

最初の30日で作るべき成果物

最初の10日で、現在有効な例外を集め、対象資産、承認者、期限、代替統制、恒久対応、証跡の有無を一覧にします。すべてを一度に作り直すのではなく、期限超過、外部公開、重要業務、機微データ、代替統制未確認の条件で優先する数件を選びます。

次の10日で、一件を判断記録へ変換します。事業影響、残存リスク、所有者、代替統制、確認方法、期限、再評価イベント、終了条件を埋め、関係者が同じ説明をできるか確認します。最後の10日で代替統制をテストし、終了または更新の判断まで一周させます。その結果から、申請様式、承認レベル、通知、台帳、会議体を最小限に整えます。

まとめ

セキュリティ例外の成熟度は、申請件数の少なさや承認の速さだけでは測れません。対象と事業影響が限定され、残存リスクを所有する人が判断し、代替統制が検証され、期限と変化で再評価され、最後に終了証跡まで残る状態が重要です。例外は標準の外側に置くものではなく、標準へ戻るまでの管理された経路として設計します。

FourthWallは、セキュリティ基準と例外ポリシーの整備、リスク登録簿・構成情報との連携、承認レベルとワークフロー、代替統制の設計・検証、期限・イベント監視、経営向けリスク報告を、既存の組織とツールに合わせて設計する支援を行います。最初の一歩は、期限超過の一件を責めることではなく、その一件を「誰が、どのリスクを、どの条件で、いつまで受け入れ、どう閉じるか」という判断記録へ変えることです。

参考資料

• NIST IR 8286 Rev.1 “Integrating Cybersecurity and Enterprise Risk Management (ERM)”（2025年12月）
• NIST SP 1303 “NIST Cybersecurity Framework 2.0: Enterprise Risk Management Quick-Start Guide”
• NIST SP 800-37 Rev.2 “Risk Management Framework for Information Systems and Organizations”
• UK NCSC “The fundamentals and basics of cyber risk”
• NIST IR 8183A Vol.2 “Cybersecurity Framework Manufacturing Profile: Low Impact Level Example Implementations Guide”

本記事は公開資料に基づく一般的な情報提供を目的とし、個別の法務、契約、監査、内部統制、情報セキュリティ、個人情報保護に関する専門的助言ではありません。実際の例外判断、承認権限、残存リスク、代替統制、期限、法令・契約上の扱いは、事業、システム、データ、組織の権限、リスク選好を踏まえ、関係する専門家と確認してください。