# インシデント対応時の運用セキュリティ ## 定義 インシデント対応時の運用セキュリティ(Incident Response OpSec)とは、侵害されている可能性のある組織が調査・対応活動そのものを攻撃者に気づかれないよう秘匿する実務を指す。攻撃者が対応組織の動きを監視している可能性があるという前提のもと、通信チャネルの分離・侵害端末への非ログイン・攻撃者インフラへの非接触・リモートフォレンジックエージェントの事前配備といった具体的な行動規範を伴う。目的は二重で、(1) 攻撃者に調査の進行を悟らせず証拠隠滅や逃亡・報復的破壊を防ぐこと、(2) 対応活動自体が調査中の環境の危険性(盗まれた認証情報の再利用等)にさらされないようにすることである。ただし、生命や重大なデータ・インフラが懸かる差し迫った(imminent)リスクがある場合は、この秘匿を意図的に犠牲にしてでも被害を止める判断が正当化される。(Source: [[@2020__OReilly__Building Secure and Reliable Systems - Chapter 17 Crisis Management]] §Operational Security, §Trading Good OpSec for the Greater Good) ## 横断的知見 - **「行動そのものが観測者に情報を与える」という核心原則は、組織のインシデント対応と個人のプライバシー防衛という全く異なる文脈で独立に到達されている**: 本概念(BSRS 17章)は、侵害されたサーバへのログインや攻撃者のC2サーバへの接続が、攻撃者のログに「不審な観測者」として記録され、調査に気づかれるリスクを具体的に列挙する。[[運用セキュリティ(OPSEC)とトレードクラフト]] が集約する『Security Engineering』3版25章は、個人が国家権力や不誠実な内部者から身を守る文脈で、暗号化ツールの使用自体が(利用者が少なければ)疑いを招くという「ネットワーク効果」の議論や、通信内容を暗号化してもトラフィック分析で相手・頻度という社会グラフは秘匿できないという限界を論じる。組織対攻撃者(BSRS)と個人対国家権力(Security Engineering)という全く異なる脅威モデル・スケールでありながら、両者は「秘匿すべきは通信内容だけでなく行動パターンそのものである」という同じ核心原則に独立に到達している。(Source: [[@2020__OReilly__Building Secure and Reliable Systems - Chapter 17 Crisis Management]] §Operational Security, [[@2020__Wiley__Security Engineering 3e - Chapter 25 New Directions?]] §25.4.1) - **フォレンジック対策の発想「大きな干し草の山を作る」と、BSRS の「事前配備したリモートエージェントで自分の認証情報を晒さない」という対策は、双方とも「有事に慌てて対策を講じるのではなく平時から備える」という時間軸の教訓で一致する**: [[運用セキュリティ(OPSEC)とトレードクラフト]] は、捜索された場合に何が見つかるかを事前に想定し「見つけてほしくない針があるなら、より大きな干し草の山を作る」という平時からの布石を説く。BSRS 17章も同様に「OpSec 計画は今日のうちに——インシデントが起きてから急いで考えるものではない」と明言し、リモートフォレンジックエージェントや鍵ベースアクセスをあらかじめ全システムに配備しておくことを推奨する。両者とも危機発生後では手遅れになりやすい対策を、平時の設計・配備の問題として扱っている点で収束する。(Source: [[@2020__OReilly__Building Secure and Reliable Systems - Chapter 17 Crisis Management]] §Operational Security, [[@2020__Wiley__Security Engineering 3e - Chapter 25 New Directions?]] §25.4.3) - **「良いOpSecを大局のために手放す」判断は、Security Engineering 3e25章が個人ごとに整理する「失敗のコスト」の一種の組織版として読める**: [[運用セキュリティ(OPSEC)とトレードクラフト]] は、脅威モデルの構成要素として「失敗のコスト(金銭的損失から生命の危険まで)」が利用者ごとに大きく異なることを指摘する。BSRS 17章が示すApple FaceTimeの例(2019年、悪用容易な公開済みバグに対しサーバを丸一日停止)は、まさに「秘匿を続けることの失敗コスト(ユーザーの生命・重大データへのリスク)」が「秘匿が破られることのコスト(攻撃者に気づかれる・可用性の喪失)」を上回ると経営陣が判断した組織的な事例であり、個人レベルの脅威モデル論を組織のインシデント対応における意思決定の具体例に接続できる。(Source: [[@2020__OReilly__Building Secure and Reliable Systems - Chapter 17 Crisis Management]] §Trading Good OpSec for the Greater Good, [[@2020__Wiley__Security Engineering 3e - Chapter 25 New Directions?]] §25.4.4) ## 未解決の問い - BSRS 17章は組織全体で一貫したOpSecルールを前提とするが、[[運用セキュリティ(OPSEC)とトレードクラフト]] が指摘する「信頼の確立は双方向のプロセスである」という知見(情報提供者と支援者が互いを見極める)は、組織内の一部メンバーだけに機密保持を課す IR チーム編成にどこまで応用できるか。 - チャットツールの自動リンク展開機能が攻撃者インフラへの意図しないアクセスを生む問題(BSRS 17章のサイドバー)は、[[運用セキュリティ(OPSEC)とトレードクラフト]] が扱う「暗号電話市場」のようなツール選択の議論と接続できるか。ツールの「親切な」自動化機能自体がOpSecの脅威になるという論点は、個人向けのプライバシーツール選定でも同様に生じるか。 - 「差し迫ったリスクがあればOpSecより被害の停止を優先する」という判断基準(BSRS 17章)を、定性的な「差し迫ったリスク」の判定から、より具体的な閾値・チェックリストへ落とし込んだ実務事例はあるか。 - 侵害調査における良いOpSecの実践(通信チャネルの分離・新規インフラの構築)と、[[インシデント調査戦略]] が扱う体系的/日和見的な調査戦略は、実際の対応でどう両立されているか。OpSec上の制約(攻撃者に見える操作を避ける)が調査戦略の選択自体を制限する場面はあるか。 ## 関連 - [[運用セキュリティ(OPSEC)とトレードクラフト]] — 個人・情報提供者を対象とする運用セキュリティ論。本概念とは脅威モデル(組織対攻撃者 vs 個人対国家権力)が異なるが核心原則が収束する - [[インシデント管理]] — 本概念が実践される文脈 - [[危機時の指揮系統]] — ICが確立する指揮系統の中でOpSecルールが策定・伝達される - [[インシデント調査戦略]] — 調査手法とOpSec上の制約の接点 - [[@2020__OReilly__Building Secure and Reliable Systems - Chapter 17 Crisis Management]] — 本概念の中心的ソース - [[@2020__Wiley__Security Engineering 3e - Chapter 25 New Directions?]] — 個人レベルの運用セキュリティを扱う姉妹ソース ## 出典 - Matt Linton (with Nick Soda and Gary O'Connor), "Crisis Management", in Heather Adkins et al. (eds.), *Building Secure and Reliable Systems*, O'Reilly Media, 2020, Chapter 17, §Operational Security, §Trading Good OpSec for the Greater Good. - Ross Anderson, *Security Engineering: A Guide to Building Dependable Distributed Systems*, 3rd Edition, John Wiley & Sons, 2020, Chapter 25, §25.4.1-§25.4.4.