# セキュリティの持続可能性 ## 定義 セキュリティの持続可能性(sustainability)とは、システムが安全かつ安全な状態でどれだけ長く動作し続けられるか、という問題を指す。*Security Engineering* 第3版は、これを2020年版で新たに扱うべき論点として導入し、著者は第3版の序文で「今日2020年にカーナビゲーションソフトを書いているとして、2033年・2043年・2053年にもセキュリティパッチを提供し続けられるか」という問いを、耐久財のパッチ供給問題を象徴するwicked problem(一筋縄ではいかない難問)として提示している(印刷ページxxxviii-xxxix)。第28章はこの問題を具体化し、耐久財(自動車・医療機器・IoT機器)に組み込まれたソフトウェアを何年にもわたってパッチし続けられるかという課題として、保証(assurance)・コンプライアンスと並ぶ本章の三本柱の一つに据える。(Source: [[@2020__Wiley__Security Engineering 3e - Chapter 28 Assurance and Sustainability]] ch.28 §28.1, §28.5) 背景には次の非対称性がある。スマートフォンは数年でセキュリティパッチが提供されなくなり買い替えを前提とするが、自動車は平均15年、電気系統は数十年使われる。新車の製造時に排出されるCO2(embedded carbon)は生涯の燃料燃焼量にほぼ匹敵するため、ソフトウェアの陳腐化を理由に車の廃棄年数を6年程度まで早めることは環境コスト上受け入れがたく、電気自動車への転換も内燃機関車と同程度の走行距離(平均15万km)を前提にしている。したがって「壊れたら早く直す・古くなったら買い替える」という消費財のセキュリティ運用モデルは、耐久財にはそのまま適用できない。(Source: [[@2020__Wiley__Security Engineering 3e - Chapter 28 Assurance and Sustainability]] ch.28 §28.5) これに対応する法制度として、EUは2019年にSales of goods directive(2021年施行)を成立させ、「デジタル要素を含む財」を販売する企業に対し、販売後最低2年、消費者が合理的に期待する場合はそれ以上の期間、当該要素(組み込みソフトウェア・関連オンラインサービス・アプリ)を保守する義務を課した。既存の耐久財規制(自動車・洗濯機は最低10年の部品供給義務)を踏まえると、セキュリティパッチもそれに準じる長期間の供給が求められる可能性がある。(Source: [[@2020__Wiley__Security Engineering 3e - Chapter 28 Assurance and Sustainability]] ch.28 §28.5.1) ## 横断的知見 - **序文が予告した「wicked problem」という抽象的な問題提起は、本章§28.5で具体的な法制度・研究プロジェクトにまで踏み込んで実装される**: 序文(印刷ページxxxviii-xxxix)は持続可能性を数段落で予告するのみで、「2033・2043・2053年にどうパッチを提供し続けるか」という問いを立てるにとどまる。これに対し本章§28.5.1はEUのSales of goods directiveという具体的な立法(2021年施行、最低2年+消費者の合理的期待、既存の10年部品供給規制との整合)を、§28.5.2はLaurent Simon・David Chisnallと著者自身が取り組んだ具体的な研究プロジェクト(OpenSSLのような暗号実装がコンパイラ最適化によって定数時間処理やメモリのゼロ化が消されてしまう問題に対し、プログラマの意図をコード注釈で表現しLLVMプラグインとして実装する試み)を示す。序文と本章は同一書籍内の独立した記述でありながら、前者が問題提起、後者が(部分的な)解決の試みという関係にあり、著者が問題提起から数年のうちに自ら研究に着手したことを裏づける。(Source: [[@2020__Wiley__Security Engineering 3e - Chapter 28 Assurance and Sustainability]] ch.28 §28.5.1, §28.5.2) - **IoT機器の持続可能性の失敗(Mirai/Xiaomi)は、電球カルテル(1924年)やApple iPhoneのバッテリー劣化に伴う速度低下(2017年)という、ソフトウェア以前から存在した「計画的陳腐化」の系譜に連なることを本章自身が示す**: 本章§28.5は、規定パスワードを持ちパッチ不能なXiaomi製監視カメラがMiraiボットネットに悪用されTwitterを機能停止に追い込んだ事件を、消費者団体や環境政党が問題視していた「スマート冷蔵庫がサーバー停止で1年後にただの霜だらけの箱になる」という一般的な陳腐化問題と同じ文脈に位置づける。1924年のGE・Osram・Philipsによる電球寿命短縮カルテル、フランスの2015年製品寿命短縮禁止法、Appleの2017年iPhoneスピード低下問題(2020年に仏で12億ユーロの罰金、米で5億ドルの集団訴訟和解)はいずれも同章内で列挙されており、セキュリティパッチの持続可能性問題が、耐久消費財全般の計画的陳腐化という百年近い歴史を持つ経済問題の最新の一事例であることを本章自身が明示している。(Source: [[@2020__Wiley__Security Engineering 3e - Chapter 28 Assurance and Sustainability]] ch.28 §28.5) - **「製品ライフサイクル規模の持続可能性」と「実務者の労働負荷規模の持続可能性」は、同じ"sustainability"という語で別々の時間軸・別々の資源を扱っている**: 本概念(Security Engineering 3e第28章)が扱う持続可能性は、耐久財に組み込まれたソフトウェアを何十年もパッチし続けられるかという、企業・規制当局が負う長期的な保守義務の問題である。これに対し『Building Secure and Reliable Systems』21章の「持続可能性の文化(Culture of Sustainability)」は、セキュリティ・信頼性を担う実務者個人のストレス・燃え尽き・士気を組織がどう管理するかという、日次〜年次の労働配分の問題を扱う。21章は「事後対応の運用作業」と「長期的な改善投資」のバランスを継続的に測定し、緊急時のみ一時的に通常業務を逸脱しつつも、その逸脱が一時的であることを明確にし、繰り返し可能で予測可能なプロセスによって英雄的対応(heroics)を回避することを要件とする。両者を並べると、「持続可能性」は資源(規制・保守コスト vs. 人的リソース・士気)も時間軸(製品の耐用年数 vs. 個人のキャリア・エンゲージメント)も異なる、少なくとも2つの独立した問題群を指す語であることが分かる——本章が扱う耐久財の問題を解決しても、実務者の燃え尽きは解決しないし、その逆も成り立たない。(Source: [[@2020__Wiley__Security Engineering 3e - Chapter 28 Assurance and Sustainability]] ch.28 §28.5, [[@2020__OReilly__Building Secure and Reliable Systems - Chapter 21 Building a Culture of Security and Reliability]] §Culture of Sustainability) - **同一書籍『Security Engineering』内の第27章が指摘する「チェックリスト的発想への逃避」に対し、『Building Secure and Reliable Systems』21章はそれを防ぐ具体的な組織設計を提示する**: 隣接concept[[セキュリティエンジニアリングチームの管理と組織的リスク]]が集約する第27章§27.5.8は、組織が不確実性への対処が苦手でチェックリスト的発想(認証取得済みプロセスが批判的思考を駆逐する)に流れがちだと指摘する。『Building Secure and Reliable Systems』21章はGoogleのSRE・セキュリティ運用チームが「フォロー・ザ・サン」シフトでストレス・燃え尽きを避け、業務時間の一部だけを運用に充て残りをインフラ改善に使う体制、および長期施策への専用開発リソースの配分を、持続可能性を支える具体的な組織設計として描く。前者(チェックリスト逃避という失敗パターンの診断)と後者(シフト設計・リソース配分という処方箋)を突き合わせると、持続可能性の欠如が具体的にどうチェックリスト思考を招くかという経路(疲弊→思考の単純化→形式的遵守)が示唆される。(Source: [[@2020__Wiley__Security Engineering 3e - Chapter 27 Secure Systems Development]] §27.5.8, [[@2020__OReilly__Building Secure and Reliable Systems - Chapter 21 Building a Culture of Security and Reliability]] §Culture of Sustainability, サイドバー "Sustainable Reliability and Security Culture at Google") ## 未解決の問い - 序文が挙げる「2023年に発売する車のナビゲーションソフトを2053年まで保守する」という具体的な時間軸に対し、本章§28.5.1のSales of goods directiveが実際に要求する保守期間の下限は「最低2年+消費者の合理的期待」という曖昧な基準にとどまり、30年規模の耐久財の要求水準を満たすかどうかは本章の時点(2021年施行前)では確定していない。 - 本章はコンパイラによる定数時間暗号処理の消去問題への対応(LLVMプラグイン)を「概念実証(proof of concept)」の段階までしか報告しておらず、実運用への展開状況は本章の範囲(2020年執筆時点)を超える。 - 自動車の事故データを学習系(learning system)としてどう設計するかという課題(§28.5.2)は、EU加盟国が車両標準の市販後監視を担うため実質ほとんど進んでいないと本章は述べるが、具体的な法整備の進捗は本章では追えない。 ## 関連 - ソース: [[@2020__Wiley__Security Engineering 3e - Chapter 28 Assurance and Sustainability]](§28.1, §28.5〜§28.5.2) / [[@2020__OReilly__Building Secure and Reliable Systems - Chapter 21 Building a Culture of Security and Reliability]](実務者の労働負荷規模の持続可能性という別軸を与えるソース) - 概念: [[セキュリティ評価制度]](静的評価から継続的保証への移行という同じ問題意識を評価制度側から扱う) / [[セキュリティにおけるインセンティブ不整合]](耐久財メーカーが長期保守のコストを負わない構造) / [[セキュリティエンジニアリングチームの管理と組織的リスク]](チェックリスト的発想への逃避という失敗パターン) / [[セキュリティと信頼性の文化]](21章の持続可能性の文化を包含する上位概念) - 実体: [[Ross Anderson]] / [[Heather Adkins]] ## 出典 - Ross Anderson, *Security Engineering: A Guide to Building Dependable Distributed Systems*, 3rd Edition, John Wiley & Sons, 2020, Chapter 28, §28.1, §28.5-§28.5.2. - Ross Anderson, *Security Engineering: A Guide to Building Dependable Distributed Systems*, 3rd Edition, John Wiley & Sons, 2020, Preface to the Third Edition, pp. xxxviii-xxxix. - Heather Adkins et al. (eds.), *Building Secure and Reliable Systems*, O'Reilly Media, 2020, Chapter 21, §Culture of Sustainability.