# セキュリティにおけるインセンティブ不整合 (Incentive Misalignment in Security) ## 定義 システムを守る者(guard)と、それが失敗したときにコストを負う者(sufferer)が一致しないとき、セキュリティ上の問題が生じるという定式化である。2000年前後にセキュリティ経済学の研究者が到達した中心的な洞察であり、「security mechanisms are often designed deliberately to shift liability(セキュリティ機構はしばしば責任を転嫁するために意図的に設計される)」という、さらに一歩踏み込んだ観察を伴う。ネットワークの非セキュアさは大気汚染や渋滞と類比され、安全でない機器をインターネットに繋ぐ者は自分の行動の全コストを負担せず、正しく行動しようとする者が他人の不注意の副作用に苦しむ、という非対称な構造として説明される。(Source: [[@2020__Wiley__Security Engineering 3e - Chapter 8 Economics]] §8.1) 具体例として、Windowsのセキュリティ史(プラットフォーム覇権争いの初期にはセキュリティより互換性・アプリ開発者(complementer)の惹き付けが優先され、市場地位確立後に初めてセキュリティ投資が増える)、SSL/TLSの設計(証明書の評価と信頼判断のコストを銀行ではなくユーザーに転嫁したことでフィッシングを招いた)、"perversely motivated guards"(警察がサイバー犯罪の通報を抑制して犯罪率低下を演出する、銀行がマネーロンダリング対策を最小限の法令遵守に矮小化する、プラットフォームが不正クリックの検知を積極的に行うほど自らの広告収入を減らしてしまうなど、守る立場の主体が真剣に問題を発見・対処することへのインセンティブを持たない構造)が挙げられる。(Source: [[@2020__Wiley__Security Engineering 3e - Chapter 8 Economics]] §8.1, §8.6.1, §8.6.6) ## 横断的知見 - **第14章(Monitoring and Metering)のスマートメーター事例は、第8章の定式化を「規制産業のインフラ投資」という別の文脈で裏づける**。第8章は銀行・プラットフォームなど情報セキュリティ全般での不整合を扱ったが、第14章の英国・オンタリオのスマートメーター展開は、同じ「守る者と負担者の不一致」が物理インフラの投資判断でも起きることを示す。小売業者がメーターを所有する国(英国)では、スマートメーターが省エネによって「自らの収益(エネルギー販売)」を害するため、業者にはメーターを真に機能させるインセンティブがない——ドイツは正直な経済評価の結果、計画自体を放棄したが、英国は誤った前提を重ねて正の投資判断を捻出し、200億ポンドを投じてエネルギー削減効果ゼロという結果に終わった。オンタリオも同様に配電事業者が中央集権システムを構築したが、便益は5.9億ドルの見積もりに対し実質最大8800万ドルにとどまり、費用は20億ドルに膨張した。これは第8章が列挙した「perversely motivated guards」(警察・銀行・プラットフォーム)と同型の構造——負担者(消費者・政府)と意思決定者(メーター所有者)の分離——が、情報セキュリティ機構だけでなく大規模な物理インフラ投資の意思決定そのものに及ぶことを示す。(Source: [[@2020__Wiley__Security Engineering 3e - Chapter 14 Monitoring and Metering]] ch.14 §14.2.4, [[@2020__Wiley__Security Engineering 3e - Chapter 8 Economics]] ch.8 §8.1, §8.6.1) - **第14章はイタリアの成功例を対照させ、インセンティブが揃った場合には同じ技術が機能することを示す**。イタリアの電力会社ENELは2001年からスマートメーターを導入したが、目的は南部イタリアで暴力団に妨害される電力窃盗の防止という、配電事業者自身の直接的な利益に資するものだった。この事例では「守る者(ENEL)」と「便益を得る者(ENEL)」が一致しており、実際に成功と評価されている。第8章の定式化を裏返すと、インセンティブが一致する場合には同一の技術が正反対の結果(成功)を生むことが、同一書籍内の独立した事例で確認できる。(Source: [[@2020__Wiley__Security Engineering 3e - Chapter 14 Monitoring and Metering]] ch.14 §14.2.4) - **第24章のアクセサリ制御は、本概念を「規制産業のインフラ投資」からさらに「消費者製品の設計」へと拡張する第三の事例群である**: 第8章は情報セキュリティ機構(SSL/TLSの証明書判断コストの転嫁など)を、第14章は物理インフラ投資(スマートメーター)を扱ったが、第24章はJohn Deereのトラクター修理ロック(修理を認定ディーラーに限定し、農家が1回230ドルの出張費と時間135ドルを負担)、GE製冷蔵庫の水フィルタ強制交換、そしてCOVID-19下で3Mが人工呼吸器バッテリーを原価5ドルに対し200ドル超で販売しながら中国工場の国有化で他社への鍵供給を止めた事例を挙げる。いずれも「機器を設計・管理する主体(メーカー)」と「コストを負う主体(利用者・患者)」が分離しているという、第8章・第14章と同型の不整合であり、しかも3Mの事例では「持続可能性」だけでなくパンデミック下の医療従事者の安全性にまで直接的な被害が及んだ点で、不整合の帰結の深刻さが従来の2事例よりも一段上がっている。(Source: [[@2020__Wiley__Security Engineering 3e - Chapter 24 Copyright and DRM]] ch.24 §24.6, [[@2020__Wiley__Security Engineering 3e - Chapter 8 Economics]] ch.8 §8.1) - **第25章の自動運転車の賠償責任(liability)の議論は、本概念を「事故データの開示・報告」という第四の局面へ拡張する**: 第25章は、自動操縦作動時の事故についてメーカーが安全性の数値をめぐって「carmakers undercount crashes with autopilot activated(メーカーが自動操縦作動中の事故を過小計上している)」疑いがあると報告する。人間ドライバーが運転していれば「どちらの運転手に過失があったか」という争いになるところ、コンピュータが運転していれば製造物責任としてメーカーが支払う立場になる——このとき、事故データを収集・保有し安全性を評価できる立場にある主体(メーカー)自身が、自らの法的責任を軽くする方向にデータを解釈・開示する誘因を持つ。これは第8章の「perversely motivated guards」(警察がサイバー犯罪の通報を抑制する等)と同型の構造だが、対象が「犯罪データの通報」から「自社製品の安全性データの開示」へと広がっている点が新しい。(Source: [[@2020__Wiley__Security Engineering 3e - Chapter 25 New Directions?]] ch.25 §25.2.4, [[@2020__Wiley__Security Engineering 3e - Chapter 8 Economics]] ch.8 §8.1) - **第25章は選挙制度そのものを、本概念の「守る者と負担者の不一致」が最も先鋭化する事例として位置づける**: 第8章・第14章・第24章はいずれも企業と消費者の間の不整合を扱ったが、第25章は選挙という公共制度に同じ構造を見出す——「選挙の『顧客』は敗者の側であり、裁判所や次の投票箱を通じた是正の望みがなければ民主主義の仕組みへの信頼は失われかねない。しかしそこには『設計者』が存在せず、法律や仕組みが選挙サイクル全体で整合するよう保証する主体がいない。それどころか、法律を書き換え投票機を購入し自陣営に有利な状況を作り出すのは、通常は現職の側である」。ここでは「守る者」(選挙制度を設計・運用する現職の政府)と「失敗のコストを負う者」(敗者・有権者)が構造的に一致せず、しかも民間市場のように規制や競争で是正する外部の力も働きにくいという点で、企業間の不整合よりも是正が難しい事例である。(Source: [[@2020__Wiley__Security Engineering 3e - Chapter 25 New Directions?]] ch.25 §25.5.5) - **第28章のCommon Criteria評価モデル(Alice・Bob・Charlie・Dorothy・Eve)は、本概念が既に示すSSL/TLSの事例(証明書評価コストのユーザーへの転嫁)を、第三者認証者を明示的に含む一般モデルへと定式化し直す**: 本概念の定義はSSL/TLSについて「証明書の評価と信頼判断のコストを銀行ではなくユーザーに転嫁した」と述べるが、第28章§28.2.8は、AliceがBobの銀行に製品を売りCharlieという認証者に安全だと認めさせた後、Bobの顧客DorothyがEveを詐取して姿を消した場合、Bobは「業界標準どおりに運用していた(Charlieの認証を得ていた)」ことを盾にEveへの補償を拒めると説明する。ここでCharlieの役割は技術的権威ではなく責任の盾(liability shield)であり、Aliceは「Charlieを満足させる程度にしか」努力せず、認証者どうしは底辺への競争(race to the bottom)に陥る。これは本概念が繰り返し示す「守る者と負担者の不一致」を、二者間(銀行とユーザー)から三者間(製品提供者・認証者・被害者)のゲームへと明示的に一般化したものであり、実際に決済業界がこの問題への対応としてPCIを設立した経緯も、第8章が挙げる「perversely motivated guards」と同型の力学として読める。詳細は [[セキュリティ評価制度]] を参照。(Source: [[@2020__Wiley__Security Engineering 3e - Chapter 28 Assurance and Sustainability]] ch.28 §28.2.8, [[@2020__Wiley__Security Engineering 3e - Chapter 8 Economics]] ch.8 §8.1) - **第28章のBoeing 737 MAX事故は、規制当局そのものが評価対象企業に取り込まれる「規制の虜(regulatory capture)」を、本概念の「守る者と負担者の不一致」の極端な一事例として提示する**: 第25章は自動運転車のメーカーが自社に不利な事故データを過小計上する誘因を、第8章・第14章・第24章は企業が自らの利益のためにコストを消費者や第三者へ転嫁する構造を示したが、第28章§28.4.1はさらに踏み込んで、安全評価を行うはずの規制当局(FAA)自身が、被評価企業(Boeing)に安全評価・認証業務の多くを委譲していたことを報告する。BoeingがMcDonnell Douglasを買収して以降、経営陣が技術者からファイナンス系人材に交代し、単一の迎角センサーへの依存という設計上の欠陥が見過ごされた結果、2度の墜落・346人の死亡に至った。ここでは「守る者」であるはずの規制当局自身が被評価企業と利害を共有してしまっており、コストを負うのは規制からも企業の意思決定からも遠い乗客とパイロットである。この構造は、第25章の自動運転車メーカーの事故データ隠蔽よりもさらに一段深刻な不整合(評価する側と評価される側の融合)を示す。(Source: [[@2020__Wiley__Security Engineering 3e - Chapter 28 Assurance and Sustainability]] ch.28 §28.4.1, [[@2020__Wiley__Security Engineering 3e - Chapter 25 New Directions?]] ch.25 §25.2.4) - **『Building Secure and Reliable Systems』第19章のChromeセキュリティチームは、本概念がこれまで扱ってきた「不整合が放置される事例」の対極として、組織が意図的に正のインセンティブを設計してすり合わせを図った事例を提供する**: 本概念のこれまでの横断的知見(第8・14・24・25・28章)は一貫して、コストを負う者と意思決定する者が分離した結果、不整合が是正されずに放置される事例(スマートメーター、アクセサリ制御、事故データの過小計上、規制の虜)を扱ってきた。これに対しChrome第19章は、「セキュリティ上の良い行動はユーザーから見えにくく評価されにくい」という同型の不整合の芽——見えない貢献は放置されれば正当に評価されない——を認識した上で、ピアボーナスや上長への肯定的フィードバック、賞金付きファジングコンテストといった具体的な仕組みを整えることで、組織内部から意図的にインセンティブをすり合わせた事例である。これは第8章が示す「perversely motivated guards」(不整合を放置し自らの利益を守る主体)とは逆方向の、単一組織が自らのマネジメント慣行によって不整合を能動的に是正しようとする稀な実例であり、本概念に「是正は可能である」という反例を加える。(Source: [[@2020__Wiley__Security Engineering 3e - Chapter 8 Economics]] ch.8 §8.1, §8.6.1; [[@2020__OReilly__Building Secure and Reliable Systems - Chapter 19 Case Study - Chrome Security Team]] ch.19 §Security Is a Team Responsibility) ## 未解決の問い - Chrome第19章が示す「ピアボーナス・fuzzingコンテスト」による組織内のインセンティブ再設計は、本概念の他の事例(スマートメーター、規制の虜)のような企業間・規制当局間の不整合にも応用可能な処方箋たりうるか、それとも単一組織内の人事施策に限定される解法か、突き合わせは未着手。 - この定式化(「守る者と失う者が一致しない」)は、本書第1章(What Is Security Engineering?)や第2章(Who Is the Opponent?)でも同様の言葉遣いで導入されているか。導入時点まで遡って確認できていない。 - 「perversely motivated guards」の各事例(警察・銀行・広告プラットフォーム)に共通する設計上の対策(第三者による監査、開示義務、インセンティブの再設計)は何か。本章は事例を列挙するにとどまり、体系的な処方箋までは踏み込んでいない。 - SREの文脈における[[ゲーム理論とSRE]]の「囚人のジレンマ=デプロイ凍結」という定式化は、本概念と同型の「守る側と失敗コストを負う側の分離」として読めるか。両者を横断的知見として統合できるかは今後の検証課題。 - スマートメーターにおける「メーター所有者=小売業者」と「メーター所有者=配電事業者」の違いが結果を左右するなら、規制設計者は他の計量・監視インフラ(例えば第14章の外出禁止タグの運用委託企業Serco/G4S)でも「誰が機器を所有・運用すべきか」を同じ枠組みで問えるはずである。本書がこの一般化を明示的に行っているかは未確認。 ## 関連 - 概念: [[セキュリティ経済学]] / [[情報経済学]] / [[アクセサリ制御]](消費者製品の設計における同型の不整合) / [[自動運転車のセキュリティ]] / [[選挙システムのセキュリティ]] / [[セキュリティ評価制度]](第三者認証者を含む一般モデル) - source: [[@2020__Wiley__Security Engineering 3e - Chapter 8 Economics]] — この定式化を導入する一次資料 / [[@2020__Wiley__Security Engineering 3e - Chapter 14 Monitoring and Metering]] — スマートメーターの所有者インセンティブで裏づける事例 / [[@2020__Wiley__Security Engineering 3e - Chapter 24 Copyright and DRM]] — アクセサリ制御という消費者製品の事例で裏づける / [[@2020__Wiley__Security Engineering 3e - Chapter 25 New Directions?]] — 自動運転車の事故データ開示、および選挙制度そのものの不整合で裏づける / [[@2020__Wiley__Security Engineering 3e - Chapter 28 Assurance and Sustainability]] — 第三者認証(Common Criteria)の責任転嫁モデルと規制の虜(Boeing 737 MAX)で裏づける / [[@2020__OReilly__Building Secure and Reliable Systems - Chapter 19 Case Study - Chrome Security Team]] — 組織内部から不整合を能動的に是正した稀な反例 - 実体: [[Ross Anderson]] / [[Google Chrome]] ## 出典 - Ross Anderson, *Security Engineering: A Guide to Building Dependable Distributed Systems*, 3rd Edition, John Wiley & Sons, 2020, Chapter 8 (§8.1, §8.6.1, §8.6.6). - Ross Anderson, *Security Engineering: A Guide to Building Dependable Distributed Systems*, 3rd Edition, John Wiley & Sons, 2020, Chapter 14 (§14.2.4). - Ross Anderson, *Security Engineering: A Guide to Building Dependable Distributed Systems*, 3rd Edition, John Wiley & Sons, 2020, Chapter 24 (§24.6). - Ross Anderson, *Security Engineering: A Guide to Building Dependable Distributed Systems*, 3rd Edition, John Wiley & Sons, 2020, Chapter 25 (§25.2.4, §25.5.5). - Ross Anderson, *Security Engineering: A Guide to Building Dependable Distributed Systems*, 3rd Edition, John Wiley & Sons, 2020, Chapter 28 (§28.2.8, §28.4.1). - Heather Adkins et al. (eds.), *Building Secure and Reliable Systems*, O'Reilly Media, 2020, Chapter 19 (Written by Parisa Tabriz).