# 運用セキュリティ(OPSEC)とトレードクラフト ## 定義 運用セキュリティ(opsec)とは、通信の暗号化そのものではなく、行動パターン全体を通じて正体・意図・関係を秘匿する実践を指す。本書は宣教師・10歳の娘・精神分析医・人権活動家・投資銀行アナリスト・性的少数者・治安判事・難民支援者・調査報道記者・選挙候補者という10人の架空の利用者を例に、プライバシー上の脅威モデルが利用者ごとにいかに異なるかを示す——脅威の強度(散発的な関心から常時監視まで)、内部者の性質(不誠実な内部者か不注意な内部者か)、成功・失敗の閾値(合理的疑いを超える証明が必要か、証拠の優越で足りるか、単なる疑いで十分か)、失敗のコスト(金銭的損失から生命の危険まで)がそれぞれ全く異なるため、画一的な技術的解には還元できない。(Source: [[@2020__Wiley__Security Engineering 3e - Chapter 25 New Directions?]] ch.25 §25.4, §25.4.4) opsecを組み立てる思考の順序として、本章は4つの要因を挙げる。第一に、既に共有されているプラットフォームや慣習(「クラブ」)を確認すること——中国のように主要サービスが遮断された環境でも、LinkedInやGitHubのようにユーザー投稿を許す暗号化通信手段が残っていることがある。第二に、脅威モデルを見極めること——多くの利用者にとって脅威は間欠的であり、大規模な秘密警察組織でも同時に扱えるファイル数には限りがある。第三に、能力(支援体制を含む)と動機を評価すること。第四に、フォレンジック対策——捜索された場合に何が見つかるかを想定し、「見つけてほしくない針があるなら、より大きな干し草の山を作る」という発想を持つこと。(Source: 同上 ch.25 §25.4.3) 暗号化アプリ(Signal、WhatsApp等)は必要条件だが十分条件ではない。第一に、少数の人しかそのツールを使っていなければ、使用していること自体が疑いを招く——ネットワーク効果により、多くの人が同じツールを使うほど個々の利用が目立たなくなる。第二に、通信内容を暗号化しても、通信の有無・相手・頻度(トラフィック分析で得られる社会グラフ)は暗号化されない。第三に、押収された端末に残る証拠(誰が誰と何をやり取りしたか)という法的リスクは、暗号化だけでは解決しない。この文脈で「暗号電話(crypto phone)」市場——通話・メッセージの暗号化に加えてアプリ実行不可・マイクとカメラの物理無効化・電話番号ではなくユーザーIDでの識別を提供する専用端末——が生まれたが、ネットワーク効果ゆえに一つのシステムが広く使われるようになるたびに当局の摘発対象となり、新しい後継システムに取って代わられるという興亡パターンが繰り返されている(Ennetcom→PGP Safe→Iron Chat→Phantom Secure→EncroChatの摘発の連鎖)。(Source: 同上 ch.25 §25.4.1) 信頼の確立は双方向のプロセスである。情報提供者(ソース)を持つ側は相手が本物か・話に裏付けがあるか・挑発ではないかを見極める必要があり、情報提供者の側は自らの匿名性集合の大きさ(何人が情報源でありえたか)に応じて、単純な匿名性を求めるべきか、それとも発覚後の弁明(plausible deniability)を準備すべきかが変わる。社会的支援(social support)——内部告発者が孤立せず信頼できる相手と経験を共有できること——が、技術的な対策と同等かそれ以上に重要である。(Source: 同上 ch.25 §25.4.2) ## 横断的知見 - 現時点では本章(Security Engineering 3e 第25章)が唯一のソースであり、横断的な突き合わせはまだ行えていない。[[信頼関係]] が集約する「信頼は破られたときに初めて分かる」というBurgess/Andersonの一般論(第1章・第11章・第12章)と、本ページの「情報提供者の信頼性を見極める双方向プロセス」という具体的な実務知見をどう接続できるかは、後続ソースでの検証課題として残す。 - **個人の脅威モデルを扱う本ページと、組織のインシデント対応を扱う[[インシデント対応時の運用セキュリティ]]は、「行動そのものが観測者に情報を与える」という核心原則を全く異なる文脈(個人対国家権力/内部者 vs 組織対攻撃者)で独立に共有する**: 本ページはトラフィック分析による社会グラフの露出や暗号化ツール使用自体が疑いを招くネットワーク効果を論じるが、[[@2020__OReilly__Building Secure and Reliable Systems - Chapter 17 Crisis Management]] は侵害されたサーバへのログインや攻撃者C2サーバへの接続が攻撃者のログに不審な観測者として記録されるリスクを、組織のセキュリティインシデント対応という別スケールの文脈で具体的に列挙する。両者とも「秘匿すべきは通信内容だけでなく行動パターンそのものである」という同じ結論に至っており、詳細は [[インシデント対応時の運用セキュリティ]] に集約した。(Source: 本ページ ch.25 §25.4.1, [[@2020__OReilly__Building Secure and Reliable Systems - Chapter 17 Crisis Management]] §Operational Security) ## 未解決の問い - 本ページが扱う個人の脅威モデル論(失敗のコストが利用者ごとに異なる)は、[[インシデント対応時の運用セキュリティ]] が示す「差し迫ったリスクがあれば秘匿より被害の停止を優先する」という組織的判断基準にどこまで一般化できるか。個人が「秘匿を諦めて逃げる」判断をする閾値と、組織が「OpSecを犠牲にしてでもシステムを止める」判断をする閾値は、同じ枠組みで比較できるか。 - 「living off the land」という発想(特別なツールを買わず手元にあるものを最大限活用する)は、[[プライバシーエンジニアリング]] が扱う企業内のプライバシー実践(アクセス制御・データ最小化)とは全く異なる文脈(個人が国家権力から身を守る)から出てきている。両者に共通する設計原則は抽出できるか。 - 暗号電話市場の「ネットワーク効果ゆえに摘発されるまで拡大し続ける」という興亡パターンは、[[情報経済学]] が扱うネットワーク外部性の議論とどこまで同型か。本ページのソース(ch.25)は経済学的な分析を明示的には行っていない。 - 本章が示す10人の利用者の脅威モデルの分類(脅威の間欠性・内部者の性質・成功失敗の閾値・失敗のコスト)は、[[計量システムの脅威モデル]] が扱う脅威モデルの一般的な構成要素とどこまで対応するか。 - 「信頼の確立は双方向のプロセスである」という本章の主張(情報提供者の評価と、情報提供者による支援者の評価が同時に進む)は、[[信頼関係]] の「信頼の移転」モデルにおける具体的な一事例として位置づけられるか、詳細な突き合わせが必要。 ## 関連 - 概念: [[プライバシーエンジニアリング]] / [[データのプライバシーと同意]] / [[信頼関係]] / [[情報経済学]] / [[インシデント対応時の運用セキュリティ]](組織のインシデント対応版OpSec) - source: [[@2020__Wiley__Security Engineering 3e - Chapter 25 New Directions?]](§25.4.1-§25.4.5) - 実体: [[Ross Anderson]] / [[Tor]] / [[Signal]] ## 出典 - Ross Anderson, *Security Engineering: A Guide to Building Dependable Distributed Systems*, 3rd Edition, John Wiley & Sons, 2020, Chapter 25 (§25.4.1-§25.4.5).