# 脆弱性ライフサイクルと協調的な脆弱性開示 ## 定義 脆弱性サイクル(vulnerability cycle)とは、研究者(researcher)——顧客・学者・国家情報機関の契約者・場合によっては犯罪者——がベンダーの保守するシステムに脆弱性を発見し、それが市場での売却・ベンダーへの直接開示・悪用のいずれかの経路をたどり、最終的にパッチが発行され、パッチのリバースエンジニアリングによって広く悪用可能になるまでの一連の過程である。脆弱性市場という発想は2000年にJean CampとCatherine Wolframが最初に提案し、以後バグバウンティ(数千ドルから数十万ドル)と、サイバー兵器製造業者・フォレンジック企業向けにゼロデイエクスプロイトを買い取る業者(iOS/Androidの持続的リモートエクスプロイトに数百万ドル)という2つの市場が並存するようになった。パッチが出る前に実際に悪用されるエクスプロイトは「ゼロデイ(zero day)」と呼ばれ、標的型攻撃に使われる。(Source: [[@2020__Wiley__Security Engineering 3e - Chapter 27 Secure Systems Development]] ch.27 §27.5.7) 脆弱性サイクルの各ステークホルダー——ベンダー・平均的な顧客・研究者・諜報機関・セキュリティソフト企業・大企業/政府機関——は、脆弱性の公表について相反する利害を持つ。ベンダーはパッチ費用を避けたいが対応せざるを得ない、顧客はパッチ適用の手間を避けたい、研究者は名声・報酬・自分が依存するシステムの修正を求める、諜報機関はパッチ前にゼロデイとして使いたい、セキュリティソフト企業は未パッチの脆弱性がなければ検知指標を売る商売が成り立たない、大企業・政府機関はパッチ検証・展開コストを嫌う。この利害対立を調整する仕組みとして、1990年代のbugtraqメーリングリスト(脆弱性を匿名で開示する場)を起点に「**責任ある開示(responsible disclosure)**」——研究者がCERT(computer emergency response team、EUではCSIRT)に開示し、CERTがベンダーに通知し、パッチ発行までの猶予期間を経てから脆弱性を公表する——という合意が形成された。**CVE(Common Vulnerabilities and Exposures)**システムは1999年に発足し、Mitreが管理しつつ大手ベンダーに番号割り当てを委任する。深刻度を数値化するCVSS(Common Vulnerability Scoring System)、CVEリストに基づくNISTのNVD(National Vulnerability Database)がこれを補完する。(Source: [[@2020__Wiley__Security Engineering 3e - Chapter 27 Secure Systems Development]] ch.27 §27.5.7, §27.5.7.1) サプライチェーンの複雑化に伴い、責任ある開示はさらに**協調的な脆弱性開示(coordinated disclosure)**へと発展した。単一のベンダーだけでなく、部品供給元・派生製品の開発者・複数のプラットフォームにまたがって開示を調整する必要が生じたためである。ShellshockやHeartbleedのように、多数の組み込み製品に組み込まれた基盤(Linux、OpenSSL)に脆弱性が見つかると、上流の保守者は主要ディストリビューションとは連携できても、アラーム時計からTVまでの無数の派生製品には手が届かず、協調的開示は「銀の弾丸のない、しかし対処可能な難問」として扱われる。(Source: [[@2020__Wiley__Security Engineering 3e - Chapter 27 Secure Systems Development]] ch.27 §27.5.7.2) ## 横断的知見 - **本章はch.8(Economics)の脆弱性開示経済学(§8.6.2、本wiki未取り込み)を明示的に参照するが、本章自身は「伝統派 対 実用派」の論争の帰結——過去10年以上安定してきたこと——を追加情報として与える**: 本章は「脆弱性は多数かつ無相関であり大半のエクスプロイトはパッチのリバースエンジニアリングに由来するため開示は最小限にすべき」とする伝統派と、「開示の脅しがベンダーを動かす」とする実用派の論争が経済学的に検討されてきたことをch.8への参照で示すにとどめるが、続けて「自動アップグレードの普及・脆弱性市場を作る企業の設立・バグの相関性に関する実証研究」という2000年代以降の展開を追加し、「多少の調整を経て、コンピュータ業界の現在のやり方は10年以上安定している」と結論づける。ch.8がこの安定化の経緯まで踏み込んでいるかは、ch.8をingestするまで確認できない。(Source: [[@2020__Wiley__Security Engineering 3e - Chapter 27 Secure Systems Development]] ch.27 §27.5.7.1) - **Chromeの2010年VRP発足は、本章が抽象化する「研究者からベンダーへの直接開示」経路の具体的な実装例であり、ベンダー側の対応方針が受け取ったバグの扱いを左右することを示す**: 本章はバグバウンティを「数千ドルから数十万ドルの市場」として一般的に説明するにとどまるが、『Building Secure and Reliable Systems』第19章は、ChromeのVRP発足が招いた外部からの大量の脆弱性報告に対し、当時リーンだったエンジニアリングチームに代わってセキュリティチーム自身がWebKitコードベースの専門知識を築いて直接バグを修正するという選択をしたことを記録する。これは本章が挙げる「ベンダーはパッチ費用を避けたいが対応せざるを得ない」という一般的な利害構造の中で、Chromeが費用を避けるのではなく積極的に引き受ける方向へ舵を切った具体例であり、しかもその選択がチーム全体の文化(ハイブリッドエンジニアリングチーム)を決定づけたという、本章には出てこない組織的な波及効果を示す。(Source: [[@2020__Wiley__Security Engineering 3e - Chapter 27 Secure Systems Development]] ch.27 §27.5.7; [[@2020__OReilly__Building Secure and Reliable Systems - Chapter 19 Case Study - Chrome Security Team]] ch.19 §Background and Team Evolution) - **第20章は、本章がバグバウンティを「数千ドルから数十万ドルの市場」として一般的に説明するのに対し、VRPを立ち上げる側(ベンダー)の実務手順を具体化し、Chrome(第19章)の事例が示す「積極的に引き受ける」判断の前段階にある準備作業を補う**: 本章はChromeが2010年のVRP発足後に殺到した外部報告に対しセキュリティチーム自身がバグを直接修正する道を選んだという結果を記録していたが、第20章はその手前の段階として、(1) 対象範囲・支払い水準を決める実施可否の判断、(2) 自社運用か専門業者への委託かの選択、(3) 受付・トリアージ・調査・検証・修正までのプロセス整備(重大な1件あたり約40時間の見積もり)、(4) 国をまたぐ支払いプロセスの整備、(5) 開始後の学習と反復、という5段階の準備手順を示す。また、VRPを始める前に通常のレビュー・脆弱性スキャンで発見できる問題を自組織で潰しておくべきだとも述べており、これは本章がバグバウンティ市場の存在を前提として語るのに対し、市場に参加する前に組織側が満たすべき条件を追加するものである。(Source: [[@2020__OReilly__Building Secure and Reliable Systems - Chapter 20 Understanding Roles and Responsibilities]] ch.20 §External Researchers, [[@2020__Wiley__Security Engineering 3e - Chapter 27 Secure Systems Development]] ch.27 §27.5.7, [[@2020__OReilly__Building Secure and Reliable Systems - Chapter 19 Case Study - Chrome Security Team]] ch.19 §Background and Team Evolution) - **第20章が挙げるVRP運用上の課題(報告の奔流・低品質な報告・言語の壁・開示ガイドラインの未整備)は、本章の脆弱性サイクルにおける「研究者」ステークホルダーの多様性——顧客・学者・国家情報機関の契約者・場合によっては犯罪者——が、実務上どのような負荷として現れるかを具体化する**: 本章は研究者を単一のステークホルダー類型として扱い、その動機(名声・報酬・自分が依存するシステムの修正)を列挙するにとどまるが、第20章は誤設定されたブラウザで「バグ」を誤って見つけてしまう非専門家が報告者に紛れ込むこと、報告者が必ずしもベンダーと同じ言語を使わないこと、開示のタイミング・報奨対象について業界横断の合意がないことを、VRP運用者が直面する具体的な課題として挙げる。これは、本章が抽象化する「研究者」という一枚岩のステークホルダー像に、専門家と非専門家が混在する現実の粒度を持ち込むものである。(Source: [[@2020__OReilly__Building Secure and Reliable Systems - Chapter 20 Understanding Roles and Responsibilities]] ch.20 §External Researchers, [[@2020__Wiley__Security Engineering 3e - Chapter 27 Secure Systems Development]] ch.27 §27.5.7) ## 未解決の問い - 脆弱性サイクルの6ステークホルダーモデル(ベンダー・顧客・研究者・諜報機関・セキュリティ企業・大企業/政府)は、[[セキュリティにおけるインセンティブ不整合]]concept が扱う「守る者と失う者の不一致」という定式化(第8章由来)の具体的な適用例と読めるが、両concept間の明示的な対応表はまだ作成していない。とくに「セキュリティソフト企業が未パッチの脆弱性から利益を得る」という構造は、既存conceptの「perversely motivated guards」(警察・銀行・プラットフォーム)の枠組みに新しいステークホルダーを加えるものと言えるか。 - Volkswagenの鍵システム訴訟(第4章§4.3.1、本wiki未取り込み)は、協調的開示が必要になった具体例として本章で言及されるが、第4章側の記述(訴訟の詳細な経緯)と本章の要約はどこまで一致するか、第4章ingest後に確認が必要。 - CVEを一切持たないことを目標にすべきかという「オープンな論争」(本章§27.4)に対し、本章はGoogleのような自社インフラ完全内製企業のみ現実的だとするが、この基準は[[脆弱性バジェット]]conceptが扱う既存の枠組みとどう関係するか未確認。 - 脆弱性市場(Jean Camp・Catherine Wolfram, 2000年提案)の実際の発展経緯(バグバウンティとゼロデイ買い取り業者への分岐)を、経済学的観点から[[セキュリティ経済学]]conceptと突き合わせる余地がある。 - 第20章が示すVRP立ち上げの5段階手順は、Chrome(第19章)のような既に確立したVRPの事後的な記録と比べて、どこまで一般化できる処方箋か。Chromeの事例はVRP発足後の組織的帰結(セキュリティチームが自らバグを直接修正する文化への転化)を記録するが、第20章の5段階手順が実際にChromeでどう踏まれたか(あるいは踏まれなかったか)は、第19章の記述からは確認できない。 ## 関連 - 概念: [[セキュリティ経済学]](脆弱性開示の経済学的分析) / [[セキュリティにおけるインセンティブ不整合]](脆弱性サイクルの各ステークホルダーの利害対立と同型) / [[脆弱性バジェット]] - source: [[@2020__Wiley__Security Engineering 3e - Chapter 27 Secure Systems Development]] — 脆弱性サイクル・CVE/CVSS/NVD・協調的開示を体系的に扱う一次資料 / [[@2020__OReilly__Building Secure and Reliable Systems - Chapter 19 Case Study - Chrome Security Team]] — ベンダー側がVRPをどう受け止め組織文化に転化したかを示す事例 / [[@2020__OReilly__Building Secure and Reliable Systems - Chapter 20 Understanding Roles and Responsibilities]] — VRP立ち上げの5段階手順と運用上の課題 - 実体: [[Google Chrome]] ## 出典 - Ross Anderson, *Security Engineering: A Guide to Building Dependable Distributed Systems*, 3rd Edition, John Wiley & Sons, 2020, Chapter 27, §27.5.7-§27.5.7.3. - Heather Adkins et al. (eds.), *Building Secure and Reliable Systems*, O'Reilly Media, 2020, Chapter 19 (Written by Parisa Tabriz). - Heather Adkins, Cyrus Vesuna, Hunter King, Felix Gröbert, and David Challoner, in Heather Adkins et al. (eds.), *Building Secure and Reliable Systems*, O'Reilly Media, 2020, Chapter 20.