ENISA の「協調された脆弱性開示」のポリシー報告を分析したわけですが、米国における部分は、別に取り出して、検討したいと思います。

ちなみに、ENISA報告書のアメリカ部分は、Allan Friedmanさんの寄稿によるものだそうです。Allanさんとは、西麻布の生オケにもご一緒したよね、とか、狭い世界です。

導入部分です。

米国の技術およびセキュリティコミュニティは、何十年にもわたって脆弱性の開示に関心を寄せてきました。2002 年、CVD の動作を標準化する最初の試みではありませんが、任意のインターネット標準を開発・推進する Internet Engineering Task Force（IEFT）の研究専門家が作成した IETF 標準草案は、この問題が「何年も前から分裂している話題」であると指摘しています。

セキュリティの専門家、業界のリーダー、政策立案者は、脆弱性を悪用しようとする者からユーザーを保護する必要性、セキュリティ研究者の権利と役割、誰もが使用するシステムを製造・維持する者のバランスを取ることに努めてきました。かつては対立が絶えなかったこの分野も、米国では政府の政策や法律が民間のリーダーシップをサポートすることで、コンセンサスが生まれつつあります。万能の解決策はありませんが、脆弱性情報の取り扱いにはベストプラクティスと認められた方法が存在します。

ということで、まずは、歴史に学びましょう。ちなみに、以下は、ENISA報告書の記述をベースにはしますが、高橋のいままでの調査研究の成果も踏まえて、みていくことにします。

1 脆弱性に対する政府の初期対応

1.1調整とハッキング防止法

国民を保護するための初期のアプローチは、2 つの形態で行われましたとされています。

そのひとつは、組織的な調整のための仕組みをつくっていくことで、いまひとつは、法的な枠組をつくっていくことです。

1.2 CERT／CC

まず、ソフトウェアとセキュリティのコミュニティは、ソフトウェアの脆弱性には組織的な調整が必要であることを認識しました。1988 年にインターネットの大部分をダウンさせた悪名高い Morris ワーム事件がありました。これを契機に、脆弱なシステムの危険性を実証した国防高等研究計画局（DARPA）は、コンピュータ緊急対応チーム（現在は CERT Coordination Center または CERT／CCとして知られています）を設立しました。

この組織は、当時は小規模ながら急成長していたセキュリティ研究コミュニティと、比較的少数のソフトウェアベンダーとの間のコミュニケーションを促進する「信頼できる第三者機関」として機能するなど、インターネットの安全確保に多くの役割を担っています。

1.3 コンピュータ無権限アクセス防止のための法律と著作権法

また、1980 年代の初期のコンピュータ悪用は、新しく理解されていない領域での悪質な行為者を処罰し、その活動を抑制しようとする政府を動かしました。

立法府は、米国の反ハッキング法であるコンピュータ詐欺および不正利用防止法（CFAA）において、悪質な行為を標的にしました。1986年に成立し、1994年と1996年に改正されたこの法律は、許可なくコンピュータにアクセスした者に適用され、刑事罰と民事罰が科せられます。この法律は、サイバー法学者の間で論争があり、初期の司法解釈の多くは、潜在的に有益なセキュリティ研究の多くを含む非常に広い範囲を設定しています。

とENISA報告書は触れています。

1.3.1 コンピュータ詐欺・不正利用防止法（Computer Fraud and Abuse Act; CFAA）

この規定の中でも特に代表的なものとして、1030条(a)(2)をあげることができます。

18 U.S.C.§1030 (a)(2)

権限なく、又は、権限を超えてコンピュータに故意にアクセスし、それによって、以下の情報を取得した者。

• (A) 金融機関もしくは15巻1602(n)条に定めるカード発行者の金融記録に含まれる情報、又は、公正信用報告法（15 U.S.C.1681以下）に定める消費者報告機関における消費者に関するファイルに含まれる情報、
• (B) 合衆国のいずれかの省庁からの情報、
• (C) いずれかの保護されたコンピュータからの情報

なお、1030条(a)(1)は以下の通りになります

18 U.S.C.§1030 (a)(1)

1. 無権限で又は授与されたアクセス権限を超過して，コンピュータにアクセスしたとの認識を持つこと
2. 下記のいずれかについて入手したデータの保持の目的を有すること
   1. 執行命令若しくは制定法の規定に従い合衆国政府によって国防若しくは外交関係上の理由で無権限の情報開示に対する保護すべきであると決定された情報
   2. 1954年原子力法11条y項に定義する禁止データ
3. 当該情報が合衆国の利益を侵害する目的で利用され又は外国に有利となるようにする目的で利用される可能性があると信ずべき根拠があること
4. 意欲して，上のいずれかの情報について、それを受信する権限のない者に対して，次のいずれかの行為をすること
   1. 通信し，送付し，伝送すること
   2. 通信され，送付され，伝送されるようにすること
   3. 通信，送付，伝送を試みること
   4. 通信され、送付され，伝送されるように試みること
   5. 受信権限を有する合衆国の職員若しくは従業員に対して送付されるべきものを保留し，それが送付されないようにすること

なお、米国においては、サイバー犯罪条約6条（装置の濫用）(1)(a)に対応する規定は、CFAAの1029条、1030条と電子通信プライバシー法（ECPA [Electronic Communications Privacy Act]。旧通信傍受法（Wiretap Act））の2512条である。サイバー犯罪条約第6条(1)(b)は、米国連邦法においては100％カバーされているわけではない。なお、18 U.S.C.§1029（アクセスデバイスに関連する不正および関連する行為）と、2512条（有線・口頭・電子通信傍受デバイスの製造・配布・所持・宣伝の禁止）の訳文は以下の通りになります。

18 U.S.C.§1029 (a)

以下に該当する者は、当該行為が州際取引又は外国商取引に影響する場合には、本条(c)に定める法定刑によって処罰される。

1. 情を知って（knowingly）、かつ、詐欺の意図をもって、一つ以上の偽アクセスデバイス（counterfeit access devices）を製造、使用、不正に売買をした者
2. 情を知って（knowingly）、かつ、詐欺の意図をもって、1年間において一つ以上の偽アクセスデバイスを不正に売買し、又は使用し、かつ、その行為によって、当該期間中に累計1000ドル以上の価値を得た者
3. 情を知って（knowingly）、かつ、詐欺の意図をもって、15個以上の偽アクセスデバイス又は無権限アクセスデバイス（unauthorized access devices）を所持する者
4. 情を知って（knowingly）、かつ、詐欺の意図をもって、デバイス製造装置（device-making equipment）を製造、管理、所持、不正に売買した者
5. 情を知って（knowingly）、かつ、詐欺の意図をもって、一つ以上のアクセスデバイス（access devices）を一人以上の者に発行し、1年の間に1000ドル以上の価値を取得する取引を成立させた者
6. アクセスデバイスの発行者の権限なく、情を知って（knowingly）、かつ、詐欺の意図をもって、以下を人に求めた者
   1. (A) アクセスデバイスの提供、又は、
   2. (B) アクセスデバイスに関する情報若しくはアクセスデバイスを取得するためのアプリケーションの販売
7. 情を知って（knowingly）、かつ、詐欺の意図をもって、通信サービスの無権限使用を取得するために改ざん又は変更された通信装置を使用、製造、不正に売買、所持、管理する者

（略）

18 U.S.C.§2512(1)

　　以下に該当する行為を故意に行った者は、本章で特段の規定のない限り、5年以下の有期刑又は/及び罰金刑とする。

• 電子デバイス、機械デバイス、その他のデバイスを、当該デバイスの設計が有線（電話）・口頭・電子通信の不正な傍受に主として有用であることを知って、又は知り得たにもかかわらず、電子メールで送信、又は州際取引若しくは外国取引で送付した場合
• 電子デバイス、機械デバイス、その他のデバイスを、当該デバイスの設計が有線（電話）・口頭・電子通信の不正な傍受に主として有用であり、かつ、当該デバイス又はその部品が電子メールで送信され、又は州際取引若しくは外国取引で輸出されることを知って、又は知り得たにもかかわらず、電子メールで送信、又は州際取引若しくは外国取引で送付した場合

（略）

1.3.2 デジタルミレニアム著作権法とセキュリティ

ソフトウェア・ベンダーも、米国の著作権法を利用して、セキュリティ研究を阻止することができます。

デジタルミレニアム著作権法（DMCA 1998）は、インターネット時代における著作権と情報の自由な流れのバランスをとるための画期的な試みでした。この法律の第1201条は、著作物へのアクセス制御を回避しようとする試みを、意図の如何にかかわらず犯罪として扱っています。(最近では、セキュリティ研究に対するDMCAの適用除外が設けられています)。

米国の法律では、多くのソフトウェアが著作権で保護されており、基本的な技術的保護手段が含まれていることが多いため、この法律は、ソフトウェアの脆弱性を特定したハッカーを脅し、起訴するために利用されてきました。これらの脆弱性の中には、企業や罪のないユーザーに不利益をもたらす悪意を持って利用されたものもありますが、より建設的に利用されたものもあるでしょう。

コンピュータ詐欺・乱用防止法（CFAA）とDMCAの両方がセキュリティ研究を脅かすために使用され、当局は最終的にその意味を明確にする必要がありました。

2 カオスと争い(2000年以降)

2.1 法的事件

2000年代前半、セキュリティコミュニティが徐々に成長するにつれ、米国ではセキュリティ研究者とベンダーの関係が悪化していきました。一部の情報公開はうまく調整されていましたが、多くの場合、あまり騒がれることなく、信頼が現実の問題となるほどの大きな事件が発生しました。

とあります。この当時にDMCAとセキュリティ研究者との関係で、議論になった事件に、Felton v. RIAA事件（2000年）、US v. Sklyarov事件（2001年）があります。

Felton v. RIAA事件（2000年）

EFFの資料は、こちらです。

2000年9月、SDMI（Secure　Digital　Music　Initiative）は、自らが提供するデジタル透かしを利用したDRM（デジタル著作権管理）の脆弱性の有無についてテストをさせ、脆弱性を発見したものに１万ドルを提供するという企画（Hack　SDMI　Challenge）を発表しました。これに対し、プリンストン大学のEdward　Felton教授は、研究チームとともにそのDRMの脆弱性を発見し、論文にまとめました。Hack　SDMI　Challengeは、同チームに１万ドルを提供したものの、Felton教授はこれを辞退し、発見した脆弱性情報を保持するとともに、これを公表することを選択した。

同教授の当該行為に対し、SDMIとRIAA（全米レコード協会）がDMCA（Digital Millennium Copyright Act、デジタルミレニアム著作権法）の配布禁止規定に抵触するため、思い留まるよう申し入れたところ、同教授は、DMCAにより研究を制限されたと主張し、DMCAは憲法修正第１条を侵害し、ソフトウェアの発展及び科学的研究を妨げているとしてSDMIとRIAAを相手取り訴訟を提起しました（なお、2001年11月、ニュージャージー州連邦地方裁判所は、原告主張を退ける判決を下し、同教授は控訴を断念した。）。

US v. Sklyarov事件（2001年）

EFF の資料は、こちらです。

ロシア人のプログラマーDmitry Sklyarov氏は、2001年7月16日、ラスベガスで開かれたDef Con（ハッカーの会議）で講演した後、デジタルミレニアム著作権法（Digital Millennium Copyright Act; DMCA）違反の容疑で逮捕されたという事件です。Sklyarov氏は、ロシアのElcom Soft社の従業員であったが、米Adobe Systems社が著作権保護目的で『Adobe Acrobat eBook Reader』に施していたセキュリティ暗号を解除するソフトウェア『Adobe eBook Processor』の試用版を配布したとして逮捕されました。具体的には、本等の著作権保護された著作物を配信するためのeBookファイルの暗号を解読し、すべてのPDFリーダーで読めるようにするソフトウェアを販売した行為が問題となりました。その後、プログラマーらによる抗議活動、不買運動等もあり、Adobe社がSklyarov氏を釈放するよう当局に要請し、最終的に同氏は違法性の意識を欠くことを理由に釈放されました。なお、本件に関しては、ElcomSoft社を被告人とする刑事訴訟が係属しましたが、最終的に陪審員は無罪の判断を下しています。

なお、本訴訟において、EFF（Electronic Frontier Foundation）は、ElcomSoftを擁護するamicus curiae brief(第三者による弁論趣意書。当該事件に関心を有する第三者が、原則として裁判所の許可を得て、当該事件に関する情報や意見を提出する書面をいう。米国催告裁判所規則37条参照。)を提出しています。

ENISA報告書に戻ります。

セキュリティ・コミュニティの間では、ベンダーが研究者ほど真剣にソフトウェア・セキュリティに取り組んでいないのではないかという懸念が広がっていました。一方、ベンダーは、セキュリティ研究者の動機や行動を理解しておらず、しばしば、悪意を持って自社のソフトウェアを攻撃する者と、悪意がない者とを区別することが本当に困難な状況でした。

とされています。ところで、上でも見たのですが、

2002 年、CVD の動作を標準化する最初の試みではありませんが、任意のインターネット標準を開発・推進する Internet Engineering Task Force（IEFT）の研究専門家が作成した IETF 標準草案

と紹介されています。

まさにこの時点で、責任ある開示という考え方で提起されて議論されだしたのは、この2000年前後になるのです。この当時、CERT／CCは、情報公開を促進する上で重要な役割を担っていたが、仲介役でした。

彼らは、過度に同情的で相手側に味方しているとして、双方から批判を受けた。明確な指針がないため、一部のセキュリティ研究者は、独自の大まかな方針を打ち出すことに努めた。

2.2「責任ある開示」対「完全開示」の議論(Responsible disclosure vs Full disclosure)

ハッカー集団であるNomad Mobile Research Centreは、1999年に情報公開に関する独自のポリシーを制定し、それぞれのケースの重大性に応じて、1週間または1ヶ月のウィンドウを設けました。

研究者がベンダーに通知せず、対応する機会も与えないという苦情への対応として、尊敬するハッカーRain Forest PuppyがBugTraqメーリングリストに投稿したものは、より有名です。このポリシーでは、ベンダーからの返答に2日間（後に5日間）の猶予を与え、定期的なコミュニケーションを要求していますが、脆弱性の修正に関する特定のタイムラインは設定していません。

ENISA報告書では

根本的な議論は、非公開の開示と完全な開示の間でした。前者は効果がないと批判され、後者は社会的に無責任であると非難された。この議論は、情報セキュリティの経済学に関する新進の学術研究コミュニティにも取り上げられたが、最適な対応策を見出すことはできなかった。

とされています。

まず、この理念的な対立についてみていくことにしましょう。

自由な流通が望ましいという考え方（完全開示の考え方といわれる）

根拠

• （１）悪意ある攻撃者は、脆弱性情報をすでに知っており、攻撃者のテクニックをすべての人が知りうるのがベストである
• （２）ベンダは、脆弱性情報が、ひとたび公開されてしまえば、脆弱性についてのバグを隠すことはできない
• （３）脆弱性の情報を公開することは、将来におけるよりよいシステムをつくるために必要である
• （４）そして、脆弱性情報は、発見者の自身の財産である、という積極的な意味づけ

責任ある流通の仕組みが必要であるといういわば「責任ある開示」の考え方

• （１）脆弱性の大多数は、脆弱性を解消するという目的よりも、自己の力量の顕示などの公開すること自体が目的であるという動機によって導かれて調査され、公開される
• （２）脆弱性を公開するにも効果的な他の方法が有り得る
• （３）より良いシステムを作るためといっても脆弱性情報の詳細を教えたりテストしたりする必要はない、

2.3 アメリカでの具体的な展開(2000年代)

この当時のアメリカでの脆弱性対応についてみていくと、

• (A) 重要な社会基盤を保護する目的での脆弱性報告
• (B) 業界の主導のもとでの脆弱性報告に関するガイドラインの策定、
• (C) 民間の業務サービスによる対応

をみることができます。

(A) 重要な社会基盤（critical infrastructure）を保護する目的での脆弱性報告

国土安全保障法にしたがい、2003年2月、ホワイトハウスは、国家にとって死活的な、通信技術を保護するための持続的な、多面的アプローチの概略を説明した「セキュアなサイバースペースのための国家戦略（The National Strategy to Secure Cyberspace）」という、76ページの冊子を発表しました。優先課題IIでは、国家的なサーバースペースセキュリティへの脅威と脆弱性の低減計画を確立することが取り上げられています。

「セキュアなサイバースペースのための国家戦略（The National Strategy to Secure Cyberspace）では、脅威と関連する脆弱性削減のための主要な措置とイニシアティブとして、以下の8点をあげています。

1. サイバースペース上の攻撃を防止し、犯罪者を訴追するための捜査機関の能力を高める。
2. 脅威および脆弱性の潜在的な影響をよりよく理解するために、国家的な脆弱性評価の手続を創設する。
3. プロトコルおよびルーティングの改善により、インターネットのメカニズムをセキュアにする。
4. 信頼できるデジタル制御システムおよび監視制御/データ取得システムの利用を促進する。
5. ソフトウエアの脆弱性を低減し、修正する。
6. 社会基盤の相互依存性を理解し、サイバーシステムおよび電気通信の物理的セキュリティを改善する。
7. 連邦のサイバーセキュリティ研究開発計画を優先的に取り上げる。
8. 新しく生まれるシステムを評価し、セキュアにする。

「セキュアなサイバースペースのための国家戦略」の結果として、国土安全保障省のナショナル・サイバー・セキュリティ・ディビジョンは、2003年9月に、インターネットのサイバー攻撃を防ぎ、これに対応するため、CERT/CCと連携する旨公表しました。

ワシントンD.C.に本拠をおく、政府から資金の援助を受けた研究開発センターであるUS-CERTが、パートナーシップをくみました。その目標は、システムへのウィルス、ワームの攻撃といった、サイバー攻撃の脅威への民間の対応と政府部門による対応を協調させることにあり、また、ソフトウエア脆弱性を報告するための新しい探知ツールと共通のプロトコルを開発するにあたり、全世界のCERTおよび民間のセキュリティ会社との間の調整を行うことでした。

当時、米国連邦政府内のコンピュータの脆弱性は、国土安全保障省の一部門である連邦コンピュータインシデント対応センター（Federal Computer Incident Response Center：FedCIRC）が調整を行っていましる。FedCIRCは、CERT/CC、営利ソフトウエア ベンダ、捜査機関、情報機関および米国連邦政府のインシデント対応チームと緊密な関係を保っていました

(B) 脆弱性報告についてのガイドライン策定に向けた業界のイニシアティブ

2001年11月、マイクロソフトおよびその他のいくつかのセキュリティ関連会社（Foundstone、@Stake、Guardent、BindViewおよびInternet Security Systemsを含む）が、ソフトウエアのセキュリティ脆弱性を報告し公開するにあたっての、限定的な国際基準のドラフトを初めて公表しました。同グループは、「Organization for Internet Safety」（OIS）として知られることとなった。

脆弱性の調整についての最初のRequest for Comment（RFC）案が2002年2月に発行された。(Responsible Vulnerability Disclosure Process
draft-christey-wysopal-vuln-disclosure-00.txt) この案には、以下の主要な規定が含まれていました。

• 発見者は、アプリケーションのメーカに脆弱性を報告すべきであり、また、仮にメーカに連絡をとれない場合には、CERT/CCのような信頼のおける第三者であるコーディネータに報告すべきである。
• すべてのソフトウエアメーカーは、セキュリティ警告と脆弱性報告を受け取るために、「secalert@companyname.com」のような電子メールアドレスを、特別に用意すべきである。
• ひとたび通知を受けた場合には、ソフトウエアメーカーは7日（自動システムを利用している場合は10日）以内に回答しなければならない。
• ソフトウエアメーカーは、その進捗状況について7日ごとに発見者に最新の情報を提供し、通知から30日以内に問題を解決することができるよう努めなければならない。問題を解決すべき確定した期日はないが、ソフトウエアメーカーは、誠実に事を進めなければならない
• 問題が解決されるまで、報告は秘匿しておくべきである。

その後、OIS  は、2003年7月28日に、「OISセキュリティ脆弱性報告および回答に関するガイドライン」の第1版（Guideline for Security Vulnerability Reporting and Response）を発表しました。

2003年9月2日には、「OISセキュリティ脆弱性報告および回答に関するガイドライン実装のためのガイド － 1.0版 」（Guide to Implementing the Security Reporting and Response Guideline – Version 1.0 記事は）が発行されました 。このOISガイドラインでは、前記RFCで提案されている基本的なアプローチと日程にしたがっています。OIS ガイドラインを採用する企業は、それら企業のセキュリティポリシーにおいて、その手続がガイドラインと異なる部分を含め、それら企業がこのガイドラインにしたがっているものであることを注記しておくべきでことになります。

企業のセキュリティポリシー内にその旨を記載したならば、ガイドラインを真剣に順守することは義務となり、FTCその他の機関による調査の対象となります。

(C) 私企業による有料サービス

営利企業の何社かは、企業がソフトウエアの脆弱性を管理できるようにするためのサービスを提供している。これらの企業では、その公開しているウェブサイト上で、いくつかの脆弱性警告を提供してはいるが、主に、秘密保持を条件として、代金を支払う用意のある会社に対して、早期の情報を提供することを業務としている。脆弱性トラッキングまたはテストサービスを提供しているベンダとして、 Security Trackerや Secuniaがありました。 

その他の企業は、システム管理者が、当該企業の既存の企業レベルでのセキュリティポリシーに、個々のワークステーションが準拠しているかをテストすることのできるツールやサービスを提供しているものもある。これら製品の中には、Configuresoft社の Enterprise Configuration Manager、そしてHarris CorporationのSTAT Scannerがある。

3 調整された開示の発展へ

2009年には、セキュリティカンファレンスCanSecWestで「No more free bugs」というプレゼンテーションが行われ、ベンダーと協力することによる法的・職業的リスクは、有料顧客に販売したり単に公開したりするメリットよりも大きいと主張されました。

2010 年代初頭までに、コミュニティの多くの人にとって、現状が持続不可能であることは明らかであった。セキュリティ研究者の数は増え続け、より安全なエコシステムを求めるようになっていました。

ベンダーは、外部の研究者の役割を評価し始めていました。企業が情報開示方針を示すことで協力関係がより明確になり、バグバウンティという考え方は、革命的な概念から新たなビジネス慣習として広まりました。アメリカ政府も、さまざまな手段で協力体制を強化するために、これに続きました。

3.1 政府における脆弱性報告受付プロセスの重視

2013年、消費者保護機関である連邦取引委員会(FTC)が、モバイル機器メーカーのHTCを「合理的なセキュリティ」を採用していないとして提訴し、同意命令がなされました。そこで、数多くの不備が指摘されましたが、5番目は、「第三者研究者からのセキュリティ脆弱性報告を受け、対処するプロセスを実施しなかった」ことでした。

この問題が一般化するにつれて、民間企業でも明確化することで利益を得られることが明らかになった。

2015年には、米国電気通信情報局（NTIA）で米国商務省は、「セキュリティ研究者、ソフトウェアベンダー、より安全なデジタルエコシステムに関心を持つ人々を集め、共通の原則とベストプラクティスを作成する」マルチステークホルダー・プロセスを開催すると発表しました。

このプロセスでは、非常に多様な視点が集約されるとともに、万能な解決策は存在しないことが強調されています。このプロセスの参加者は、組織が CVD プロセスを容易に開始できるようにするためのテンプレート開示ポリシー を作成し、研究者やベンダーの動機や懸念を理解するための調査を行い、複数のベンダーに影響する脆弱性 を含むマルチパーティ開示の枠組みを開発しました。それによって、他の政府機関もすぐに追随しました。

2015年、FTCは、企業向けのサイバーセキュリティガイドに脆弱性開示を盛り込みました。「企業のための『セキュリティから始めよう』」ガイドラインは、こちらです。このガイドラインは、個人情報の漏洩事件等に対するFTCの対応などをまとめた趣旨のものですが、7項では、新規製品を開発する際には、健全なセキュリティ実務を適用しましょうとして

HTC America、Fandango、Credit Karmaの3社は、安全な開発手法に関するプラットフォームの明確なガイドラインに従わなかったとして、FTCは提訴しています。例えば、FandangoとCredit Karmaは、モバイルアプリのSSL証明書検証という重要なプロセスを無効にしており、消費者がこれらのアプリを通じて送信する機密情報が、中間者攻撃によって傍受される可能性がある状態になっていました。iOSおよびAndroidの開発者向けガイドラインに基づき、SSL証明書の検証を行わないようことに対して明確に警告しており、両者は、この脆弱性を防ぐことができたと思われます。

2016年末には、食品医薬品局（FDA）や米国道路交通安全局などの規制当局が、医療機器や最新の自動車に対するサイバーセキュリティのガイダンスやベストプラクティスの重要な部分としてCVDを取り上げました。特にFDAのプログラムは、医療機器メーカーが脆弱性を知らないようにするのではなく、脆弱性を知り、迅速に対処するためのインセンティブを確立するものであり、注目に値するものです。

2016年、国防総省のウェブサイトを対象としたバグバウンティプログラムに加え、国防総省はすべての公共向けシステムを対象としたCVDポリシーを発表しました。

保守的になりがちな国防総省（DoD）でさえ、CVDの群れに加わりました。

とENISA報告書ではコメントがなされています。

当時のアッシュ・カーター国防長官は、これを俗に言う「デジタル領域のための『See something, say something』ポリシー」と表現しました。CVDの慣行がアメリカ経済全体に広がるにつれ、法律もそれに追いつかなければならなかった。

3.2 法律の改正について

DMCAについて

2015年10月、米国著作権局は、投票機、電動陸上車両、埋め込み型医療機器に組み込まれているコンピュータ・システムに関する「善意のセキュリティ研究」に対して、DMCAに基づく免除を勧告しました。

これらの分類のシステムの脆弱性を探す研究者は、もはやDMCAの下で刑事罰や民事罰の対象となることはない。それ以来、投票機の脆弱性は、米国で強く注目されている。著作権局は、著作権法がサイバーセキュリティ政策の手段としては不十分である可能性があることにNTIAと同意し、著作権局に対して、セキュリティ研究のために他のカテゴリーのシステムを除外するよう求める声がさらに高まるだろうと多くの人が予想しています。

CFAAについて

ENISA報告書は、 米国のハッキング防止法（Computer Fraud and Abuse Act：CFAA）について、司法省はセキュリティ研究の役割を確保することの重要性を認めていることにふれています。

この問題について検討する前に、United States v. Aaron Schwartz事件（2011年）にふれておくことは有意義でしょう。

2011年1月6日、Schwartz氏は、論文データベースのJSTORから学術雑誌の記事をダウンロードした計画的な犯行に関与したとして、連邦当局に逮捕され、最終的には、連邦検事は、最終的に通信詐欺2件とコンピュータ詐欺・不正利用防止法（CFAA）違反11件により、Schwartz氏を起訴したという事件です。これは最長で35年の懲役刑、100万ドルの罰金と資産没収、損害賠償、保護観察となりうる罪でした。結局、彼は、2013年1月11日、自宅で自殺しました。

彼は、有名なプログラマーで、RSSなどの開発に従事し、redditの共同経営者であったこともあり、この事件は、きわめて大きな反響を呼びました。また、彼の死を契機に、コンピュータ詐欺・不正利用防止法（CFAA）を改正すべきではないか、という議論が盛んになりました。

2014年、同省は、CFAAの下での告発を考えている連邦検察官のために「コンピュータ犯罪事項の立件および起訴ポリシー（Intake and Charging Policy for Computer Crime Matters）」を明らかにしました。これはコンピュータ詐欺・不正利用防止法（CFAA）に基づいて起訴する場合のポリシーをきわめて具体的にあげており、注目されます。

そもそも、米国では、検察官マニュアル（USAM）があり、その9-27.230においては、実質的な連邦の利益を考慮にいれて起訴をなすべきとされています。同規定では、犯罪の性質と深刻さ、起訴の抑止効果、行為者の非難可能性、行為者の犯罪歴、行為者の調査又は訴追に協力する意欲、被害者の利益、有罪判決を受けた場合の量刑その他の結果、を考慮すべきとされています。

この検察官マニュアルを具体的に、CFAA法に適用する場合を論じるのが上記ポリシーです。このポリシは、A．ポリシー、B．コメント、Ｃ．諮問事項に分かれています。ポリシーにおいては、①コンピュータシステムや情報などの重要性、②損害もしくはアクセスが、国家安全・重要インフラ・公衆健康／安全・市場の完全性・国際関係・その他国家または経済利益に与えるインパクトの程度、③さらなる犯罪等につながる程度、④被害者その他に対する犯罪・起訴のインパクト、⑤犯罪が、アクセス権限を超えてなされているか、⑥捜査や起訴の抑止効果、⑦犯罪行為のもつインパクトの性質、⑧連邦が起訴しない場合に他の法域において効果的に起訴されるかどうか、を判断要素として起訴を判断するとされている。そして、これらの要素について、コメントが付されている。

DoJのサイバーセキュリティ部門は2017年、「オンラインシステムの脆弱性開示プログラムのためのフレームワーク」を提供し、さらに前進しました。このガイダンスの目的は、CVDプログラムの開発を支援し、「認可された脆弱性開示および発見行為を明確にし、それによって、そのような記述された活動が民事または刑事上の法律違反につながる可能性を大幅に低減する」ことでした。CVDに対するさまざまな法的・政策的アプローチに共通するテーマは、組織のシステム、能力、好みによって、CVDプログラムには固有の多様性があることを認めていることです。DoJ のガイダンスでは、「組織によって異なる可能性がある」ことを明確にしています。

その内容は

---

I. ステップ 1: 脆弱性情報公開プログラムの設計

A. 組織のすべてのネットワークコンポーネントおよび/またはデータを脆弱性情報公開プログラムの対象とするか、またはそのような資産のサブセットのみを対象とするかを決定する。

1. どのネットワークコンポーネント及び／又はデータをプログラムに含めるかを決定することは、次のような影響を受ける可能性がある。

a)組織のシステムで保存されている情報の機微性

b) システム上で既に実施されているセキュリティ対策（静止データの暗号化など）

c) 組織がネットワークをセグメント化する能力、又はシステム上に保管されている機密情報を分離する能力

d) 個人健康情報など、組織が保有する保護クラスの情報の開示に対する規制、契約、その他の制限事項。

 2. 組織が、脆弱性開示プログラムに機密情報を保有するシステムを含めることを決定した場合、以下の事項を決定する必要がある。

a) 当該情報へのアクセス、コピー、転送、保管、使用、及び保持に制限を課すかどうか。これには、以下を含む

(1)機密情報を保存、保管、転送、または最初の発見後にアクセスすることを禁止すること。

(2) 機密情報を脆弱性の特定に必要な範囲でのみ閲覧し、保持しないよう指示する

(3) 組織のシステムまたはサービスとの相互作用から得られる情報の使用を、セキュリティ脆弱性の報告に直接関連する活動に限定する。

b) 機微情報に対する特別な取扱要件をプログラムに含めるかどうか。例えば、組織から偶然またはその他の方法で入手した機微情報は、速やかに組織に返却し、当該情報のコピーは保持しないよう求める。

c) 脆弱性の発見に用いることが認められている方法または技術に制約を設けるかどうか。

(1) 例えば，ソーシャルエンジニアリング攻撃やサービス妨害攻撃は，組織の通常業務に悪影響を及ぼす可能性があるため，これを禁止している組織もある。

(2) 特定の脆弱性スキャンツールや侵入テストツールが、組織のシステムに悪影響を及ぼすことが知られている場合、ポリシーでそれらを特定し、使用してはならないことを明記する。

B. 対象となる脆弱性（及びおそらくは不十分なセキュリティ対策）の種類を区別し、特定する必要があるかどうかを決定する。例えば、脆弱性開示プログラムの範囲に含まれる（または場合によっては除外される）脆弱性やセキュリティ対策には、次のようなものがあります。

1. エクスプロイトを使って特定できるソフトウェアのバグ

2. パスワードクラッキングソフトを使ってテストできるパスワード管理の不備

3. システムや情報への意図しないアクセスを可能にするシステムの設定ミス

 4. 不適切なセキュリティ教育

C 脆弱性開示プログラムの範囲内にあるネットワークコンポーネントまたはデータのいずれかが、第三者の利害に関係するかどうかを検討し、したがって、それらをプログラムから完全に除外すべきか、またはプログラムに含める前に組織が追加の承認を得ることを要求すべきかどうかを検討する。

1. 例えば、組織がクラウドストレージサービスプロバイダを使用する場合、そのデータは組織のサーバーではなく、そのプロバイダが所有するサーバーに存在することになります。また、そのサーバーには、他の個人や組織が所有するデータが共存している可能性があります。クラウドサービスプロバイダとの契約がない場合、脆弱性開示プログラムを実施する組織は、脆弱性開示プログラムの一環として、プロバイダのサーバにアクセスする権限を他者に付与することができない可能性があります。

 2. クラウドストレージプロバイダーと組織との間のサービスレベル契約は、プロバイダーのサーバーに影響を与える脆弱性開示活動に従事する権限に関する疑問を解決することができます。この問題が契約によって対処されているかどうかを判断するには、組織の法律顧問が最適な立場にあるでしょう。

D. 脆弱性情報開示プログラムを確立するためのガイダンスとして、他のリソースを検討する。

– 18F 脆弱性情報公開プレイブック https:／／handbook.18 f.gov／responding-to-public-disclosure-vulnerabilities／

– NTIA の脆弱性と開示に関するマルチステークホルダーワークは、 https:／／www.ntia.doc. gov／other-publication／2016／multistakeholder-processcybersecurity-vulnerabilities

– 国際標準化機構の脆弱性開示に関するガイダンス（ISO 29147, Vulnerability Disclosure）は http:／／standards. iso.org／ittf／PubliclyAvailableStandards／c045170_ISO_IEC_29147 _2014.zip

Ⅱ．ステップ2: 脆弱性公開プログラムの運営計画

A. 脆弱性の報告方法を決定する

1  「ソーシャルエンジニアリング」によって明らかにされる可能性のある脆弱性については、報告先のメールアカウントや情報保護に使用する公開暗号鍵を特定するなど、発見した脆弱性を容易に報告できる手段を用意する。一部の脆弱性については、その価値と悪用の可能性を考慮し、脆弱性報告を暗号化することが望ましい。

 2. 可能であれば、個人のメールアカウントを脆弱性報告用に使用することは避けてください。その代わりに、脆弱性の公開を取り扱うすべての担当者がアクセスできる脆弱性報告専用のアカウントを作成してください。このようなアカウントの一般的な命名規則は、「security@[organization]」です。

 3. 発見された脆弱性の証明を組織にどのように提供すべきかを記述する。

例えば、

a) 脆弱性の証明を提出する際の書式を記述する。

(1) 脆弱性レポートが真の脆弱性に関係しているかどうかを評価するために必要なデータの種類は、レポートされた脆弱性の性質によって異なる場合があります。報告書は、単に脆弱性の説明で構成されている場合もあれば、実際のコードの提出を要求する場合もあります。また、証明の形式によって、組織が提出された報告書をどのように受け入れるかが決まる場合もあります。たとえば、マルウェアの実行形式を受け入れることに慎重な組織もあるかもしれません。

(2) 脆弱性の開示方針において、最初の発見後にデータを保存、保管、転送し、さらにアクセスすることを禁止している場合、脆弱性の説明文書または脆弱性の存在を示すスクリーンショットを許容可能な証明形式とする必要があるかもしれない。

b) 発見された脆弱性を報告すべき時間枠を示すことを検討する。例えば、発見時、実行可能な限り早期、検証後など。

B. 脆弱性の開示報告を受けるために、組織内ですぐに利用できる窓口を割り当てる。これは、コンピュータセキュリティインシデントレスポンスサービス、セキュリティオペレーションセンター、または、組織のチーフインフラストラクチャが管理する他のコンポーネントであってもよい。組織の脆弱性開示プログラムが許可する行為と許可しない行為に関する質問に、権威を持って答えることができる人員を特定する。

C 組織の脆弱性開示プログラムが許可する行為と許可しない行為に関する質問に、権威を持って答えることができる人員を特定する。

 1. タイムリーな回答を提供するよう努め、照会に対する回答が策定されている間、許容される行動がある場合には、その内容を明確に説明する。

 2. 予期せぬ質問に回答する前に、法律顧問に相談することを検討する。これらの質問は、これまで考慮されていなかった法的問題を提起する可能性があります。

D. 組織は、脆弱性開示プログラムを開始する前に、脆弱性開示方針に対する偶発的で善意の違反と、意図的で悪意のある違反とをどのように取り扱うかを決定しておく必要があります。

III. ステップ 3: 組織の意図を正確かつ明確に捉えた脆弱性開示方針の草案

A. 許可された行為と許可されない行為を、分かりやすい言葉で記述する。

 1. 脆弱性情報公開プログラムのもとで、組織が使用を許可しない技術や戦術を特定する。

 2. 脆弱性情報公開活動に関連する組織のデータへのアクセス、コピー、使用、保持に関する制限を明確に説明する。

3. ユーザが作成したデータを削除または変更する、システムを損傷、中断または無効にする、あるいはデータにアクセスできなくするような意図的な行為に対する一般的な禁止事項を含めるかどうかを検討する。

 4. 許容できる行為とできない行為など、ポリシーの重要な側面を説明するために、曖昧な専門用語や曖昧な技術的言語を使用しないようにする。

B. 組織のシステムまたはデータのサブセットが脆弱性開示プログラムの対象となる場合、ポリシーにおいて、プログラムの範囲に含まれるネットワークコンポーネントまたはデータをできるだけ具体的に特定する。例えば、脆弱性開示プログラムの対象として、

1.ドメイン名などの容易に識別できる特性によって記述された特定のシステムのみ（ホワイトリスト）

2.特に除外され、容易に識別できる特性によって記述されたシステム以外のすべてのシステム（ブラックリスト）

3.一般公開されているシステムのみ

4.一般にアクセスできるすべてのシステム、

とポリシーには記述することができます。

---

3.3 CERT/CCとCVD

CERT／CCは現在も調整役としての役割を担っていますが、一人の中立的な立場として行動することは、デジタル世界の発展とともに規模が拡大せず、現在は他の人々の努力を支援しながら専門知識を提供しています。

CERT／CCは、セキュリティ専門家グループに参加し、米国経済の重要なセキュリティ戦略・標準文書であるNIST Cybersecurity FrameworkにCVDが含まれることを提唱しました。

サイバーセキュリティフレームワークVer.1.1の2017年第2草案でも認められており、「内部および外部ソース（内部テスト、セキュリティ公報、セキュリティ研究者など）から組織に開示された脆弱性を受け取り、分析し、対応するために確立した…プロセス」の重要性が指摘されています。

3.4 脆弱性開示方針（VDP）プラットフォーム

2020年秋、サイバーセキュリティとインフラセキュリティ庁（CISA）は、ソフトウェア脆弱性のより良い管理と解決を支援するため、拘束力のある運用指令（BOD 20-01）を発表した。その目的は、連邦機関のサイバーセキュリティを強化するため、外部研究者が脆弱性を報告できるようなポリシーの策定を義務付けることであった。

この指令は、背景、求められる行為、実装ガイド、テンプレート、FAQなどからなりっています。詳細は、また、別の機会にしましょう。

2021年7月30日、この目的を集約するため、CISAは脆弱性開示のための新しいサービス「脆弱性開示ポリシー（VDP）プラットフォーム」をリリースしました。このサービスは、セキュリティ研究者と民間人の両方から脆弱性の報告を受けるのに適したウェブサイトを提供するものです。このプラットフォームは、CISAのCyber Quality Services Management Office（QSMO）が提供し、BugCrowdとEnDynaが提供します。このため、連邦政府民間機関はQSMO共有サービスの恩恵を受けることができ、その結果、独立したシステムの開発費用を削減することができます。CISAは、政府全体で1,000万ドル以上のコスト削減を見込んでいます。

このプラットフォームの図は、このような感じです。

プラットフォームは、報告者が参加機関のインターネットアクセス可能なシステム上の問題を警告するための主要なエントリポイントとして機能するSaaS型アプリケーションになると予想されます。連邦政府の情報システムで特定された脆弱性の修正は、CISAやVDPプラットフォームのサービスプロバイダではなく、影響を受けるシステムを運用する機関の責任として残ります。

•  脆弱性報告者：参加機関の連邦システムの脆弱性を報告するための中心的な場所として、このプラットフォームを活用します。
•  プラットフォームサービスプロバイダ：提出された脆弱性のスクリーニングと初期トリアージを行い、正当と思われる脆弱性の検証を行います。
•  CISA：開示活動に対する洞察を維持しますが、各開示の是正プロセスには積極的に参加しません。CISA は、統計データおよびレポートの集計を表示するために、すべての機関レポートへの読み取り専用アクセス権を有します。
• 政府機関：プラットフォームで個別のプロファイルを維持します。プラットフォームのインターフェイスにログインすると、代理店ユーザーは、提出物のリストと一般的な統計情報を含む代理店ダッシュボードを見ることができます。

さらに、このプラットフォームのおかげで、政府機関は、サイバーセキュリティの維持に役立つ可能性のある脆弱性についての情報をより多く得ることができます。サービスプロバイダーであるBugCrowdとEnDynaは、受け取った報告の初期見積もりを担当します。その後、各機関は、実際に影響を与える可能性のある脆弱性に時間を割くことができます。

CISAはこのプロジェクトで、連邦政府民間行政機関（FCEB）の機関が情報システムの脆弱性を管理するのを支援したいと考えています。

VDPプラットフォームにより、FCEBは報告者との調整を容易にし、安全な情報交換を支援し、官民の協力関係を強化します。VDPに至る過程では、草案に対するコメント期間が設けられました。テーマの関連性を考慮し、CISAは初めて、拘束力のある運用指令が発行される前にパブリックコメントの対象となることを認めました。その結果、2019年11月以降、CISAには、研究者の保護に関する法的パラメータの導入や、脆弱性の是正に関する義務的なタイムラインの定義など、改善に関する多くの提案が寄せられています。

現在、CISAの協調的な脆弱性開示プロセスは、5つのステップで構成されています。

収集

CISAは、報告を受けると、脆弱性の存在と、それがまだ報告されていないことを確認するために最初のスクリーニングを行うというタスクを持ちます。最初のチェックの後、CISAはすべての関連情報を含む報告書を収集することができます。脆弱性報告は、CISAの脆弱性分析、ソフトウェアの脆弱性に関する公開情報の確認、または研究者からの提出によって収集されます。

解析

CISAがベンダーと協力して、脆弱性の技術的な問題点とリスクの両方を調査します。

対策調整

CISAは、ベンダーと緊密に連携しながら、緩和策（例えばパッチやアップデート）を開発し、問題を解決する方法を探ります。

緩和策の適用

影響を受けるエンドユーザーは、一般公開前に緩和策をテストし、適用する必要があります。これはこの段階で行われます。

公開

最後のステップとして、CISAは、影響を受けるユーザーに対して、そのチャネルを通じて脆弱性を通知します。この段階は、CISA、影響を受けるベンダー、および脆弱性の報告元との間の調整によって特徴付けられることを強調することが重要です。CISAが実施しようとする行動を検討した後、ベンダーが対応しないか、緩和のための合理的なスケジュールを確立しない場合を想定することが必要です。

このシナリオでは、CISAは、緩和策の有無にかかわらず、ベンダーへの最初の接触試みから45日後に脆弱性を開示することができる。サイバー脅威の継続的な増加と進化に伴い、ベンダーは自らの役割とセキュリティ研究者が提供できる支援について認識することが必要となっています。CISAは、このプロセスにおけるベストプラクティスの特定と実施を支援するために最前線にいます。

3.5 IoT機器の脆弱性対応について

米国においては、連邦取引委員会（In the US, the US Federal Trade Commission (FTC)）が情報通信産業において監督を行っている。

2015年には、機器の保護に関するガイドラインを公表している 。また、TRENDnet 、Asus 、D-Link に対して、積極的な法的な手段をとっている。その後、2017年には、「新規および将来の技術の潜在的なハザード」という米国連邦消費者製品安全委員会スタッフレポート が公表され、また、議会での公聴会が開かれた。また、NISTは、種々のドキュメントを公表している 。
これらの動向のなか、2020年12月には、「2020年IoTサイバーセキュリティ改善法（IoT Cybersecurity Improvement Act of 2020）」が成立しました 。

同法は、NISTによるセキュリティ標準の設定（4条）、IoT機器を含むセキュリティ脆弱性の開示ガイドラインについてのガイドライン（5条）、連邦機関の情報システム（IoTを含む）に関する脆弱性についての協調された開示の実施（6条）、連邦機関のIoTデバイスについて契約先が協調された脆弱性開示を遵守すること（7条）などを定めている。

4 脆弱性エクイティプロセス(Vulnerabilities Equities Process)

法執行の新たな手法

米国においては、法執行機関等が脆弱性を知得した場合に、公表を含めてどのように扱うか、という問題について、脆弱性エクイティ・プロセス（Vulnerability Equities Process (VEP)）が行われています。

脆弱性エクイティ・プロセスというのは、米国政府が、脆弱性情報を取得した場合に、それを法執行、諜報その他の「攻撃的」に利用するかどうかを定めるためのプロセスをいいます。上記の脆弱性エクイティ・プロセスの内容と脆弱性を法執行機関が利用することの重要性については、議会調査サービスによる「法執行機関による技術的脆弱性の利用および公表」（Law Enforcement Using and Disclosing　Technology Vulnerabilities）という報告書が公表されています。

このプロセス自体は、EFFのNSA等を相手にする情報の自由法に基づく裁判によって、明らかになっています。