ENISAの「「国家脆弱性プログラム」を開発する(Developing National Vulnerability Programms)」という報告書が公表され、「ENISA 協調的な脆弱性情報開示：EU共通のアプローチ」というプレスリリースとともに公表されています(2023年2月16日)。リンクこちらです。 いろいろと、調査等で書きかけていたのが、そのままになってしまっていたのですが、さいごまで確認してまとめたいと思います。
表紙は、こんな感じです。
丸山さんのメモは、こちら。 全文の翻訳(仮)もあります。
私のブログでは、この問題についてのENISAの報告書としては
を取り上げており、Codeblue2022でもアメリカともあわせて共同セッションをコーディネイトしました。
協調された脆弱性情報開示の一般論について
などがあります。また、
なども参考になると思います。丸山さんの全文訳をもとに、要点と法律的な分析のところを見ていきます。
1 はじめに
ここでは、背景と目的、対象者、報告書の構成、方法論的アプローチ がふれられています。興味深いのは、方法論的アプローチで、文献調査・質疑応答等(Target consultation)・事実分析のプロセスで行われていることが明らかにされています。
2 国の CVD 政策の実施 – 産業界の視点
これは、内容の案内、国の政策に対する評価、国家的に協調した脆弱性開示方針を策定・実施する際のグッドプラクティス 、国家的に協調した脆弱性開示方針の策定と実施に際して直面した課題 にわけて論じられています。
2.2 国の政策に対する評価
国の政策に対する評価においては、
- 国内CVD政策が完全に確立されているEU加盟国は、ベルギー、フランス、リトアニア、オランダの4カ国だけ(これらの状況は、去年のENISA報告書でもでていました)
- NIS2 指令 とサイバーレジリエンス法 が脆弱性への配慮の重要性を指摘していること
- 業界のプレーヤー（民間企業）がすでに企業レベルでCVDの取り組みを開始していること
が述べられています。
2.3 策定・実施する際のグッドプラクティス
2.3 策定・実施する際のグッドプラクティスにおいては、
- 内容と形式(ポリシーの内容は明確で、その国の言語と英語（海外のセキュリティ研究者向け）の両方で書かれている必要があること)
- CVD政策の透明性(政策の目的、範囲、ITツール、開示プロセスなどを提示する必要がある)
- 各国のCVD政策の一貫性(EU、国、組織レベル（民間企業）で策定される CVD 政策は、主に業界に存在する既存のイニシアティブと首尾一貫していなければならない)
とされています。
ここで、個人的に興味深いのは、「政府の脆弱性開示」（GVD）についての言及がなされていることです。これは、わが国では特に論じられていない事項になると思います。
「政府の脆弱性開示」というのは、
政府が、これまで確認されていないサイバーセキュリティの脆弱性に関する知識を直ちに公開することと、慎重に検討し、期限を切って正当化した上でその知識を保持することの潜在的コストと利益を適切に評価・検討するために実施すべき内部政策決定構造
をいいます。これについては、CENTER FOR CYBERSECURITY POLICY AND LAWの”MORE SUNLIGHT, FEWER SHADOWS Guidelines For Establishing & Strengthening Government Vulnerability Disclosure Policies”という報告書を公表しています。
また、脆弱性エクイティ(Equity)プロセスについての論及もなされています。VEPとは
米国政府が、脆弱性情報を取得した場合に、それを法執行、諜報その他の「攻撃的」に利用するかどうかを定めるためのプロセスをいいます
これについては、米国における「脆弱性の協調された開示」(CVD) の歴史と現在 で検討しました。なお、英国では、エクイティプロセスという手続が行われています。
これらの提起する論点については、別の機会にまとめてみたいと思います。
「国家脆弱性プログラム」開発報告書では、
エネルギー管理・供給や重要な公共インフラの基礎となるような特定のセクターは、脆弱性管理に取り組む際に特別な扱いを受ける必要があるかもしれない。規制の枠組みや行動計画の策定が義務付けられるかもしれない
という議論がなされており、この点も興味深いものといえるでしょう。
「政策立案者、産業界の関係者、学界、研究者間の協力的なアプローチ」が強調されており、そこでは、 「国土安全保障省 拘束力のある運用指令22-01 悪用された既知の脆弱性についての重大なリスクの低減」が、紹介されています(日本語の紹介記事は、こちら、本文はこちら)。
この一連の流れのなかで、
脆弱性管理の政府関係者間の役割分担に加え、攻撃的機能（例えば、軍事、サイバー防衛）をデジタルセキュリティ機関やENISAから分離し、政府が脆弱性情報をどのように取り扱うかに関する透明なプロセスを確立する
という点が論じられているのは、興味深かったです。
「紫のライトセーバー」として、政府の攻撃的役割、そのための脆弱性の役割を何度が論じてきました。
などがその代表的なものです。このために
CVDに対処する際、制度レベルで政府の防御的機能と攻撃的機能の分離を透明性をもって知らせることであろう
という示唆がなされています。
2.4 国家的に協調した脆弱性開示方針の策定と実施
国家的に協調した脆弱性開示方針の策定と実施 においては、課題について
- 法的枠組みの欠如
- 財源不足
- 人的資本の不足と専門知識の不足
- 不適切なIT インフラ
- EU、国家組織、産業界との不明確なガバナンス
があげられています。
3 セキュリティ研究者のための法的課題への対応
3.1背景
これについては、
1. セキュリティ研究者が合法的に脆弱性を報告するためのインセンティブを提供する。
2. セキュリティ研究者が合法的に脆弱性を報告することの阻害要因。
3. セキュリティ研究者の法的保護の欠如に対処するための取り組み。
として論じられています。
3.2 セキュリティ研究者が合法的に脆弱性を報告するためのインセンティブ
ここでは、
- 悪評(notoriety)
- 法的保護
があげられています。また、金銭的なインセンティブについてもふれられています。
3.3 脆弱性の合法的な報告を阻む阻害要因
ここでは、6つの潜在的な阻害要因としては、
- 不十分な法的保護と訴訟への潜在的な露出
- 法的枠組みが明確でないため
- 研究者の認識不足
- フォローアップやモニタリングの非効率さ・欠如
- 利害関係者におけるコミュニケーションの不十分さ
- 管理の負担
があげられています。
3.4 法的保護の欠如に対処するイニシアチブ
これについて、対応策としては、具体的な法的措置(ガイドトライン等)と啓発的措置(キャンペーンやプロジェクト)の2種類の取り組みがあげられています。
ここでは、司法省のガイドライン(「善意のハッキングを行うセキュリティ研究では訴えられない新方針を司法省が発表」参照)が紹介されています。また、グッドプラクティスとしてIoT セキュリティ財団の「脆弱性開示 リリース2.0-ベストプラクティスガイドライン」(2021年9月) が紹介されています。
4.コラボレーションの課題への取り組み：オープンソースソフトウェアとバグバウンティプログラムの活用
4.1 オープンソースソフトウェア – OSS
4.1.1 コンテクスト
脆弱性の発見と開示に関しては、ステークホルダーと影響を受ける当事者との効果的な連携が不可欠である。しかし、特に責任の所在が曖昧になりがちなOSSの場合、これが困難な場合も少なくない。
という指摘がなされています。
これは、オープンソースコンポーネントの構成比率があがってきていること、それによるサプライチェーンの複雑性、最終ユーザーの認識の困難さ、などが要因としてあげられていて、SBOMが対応策としてあげられています。
4.1.2 OSSにおける脆弱性の影響、管理、処置
- オープンソースコンポーネントで構成されており、当該コンポーネントは、5年前と比較して倍増していること
- ソフトウェア部品表（SBOM） および／またはソフ トウェア構成分析（SCA）が回避策として認識されていること
- 脆弱性の扱いに関して言えば、OSSのコードはすべての商用ソフトウェアに存在する傾向がある
- OSSとプロプライエタリ・ソフトウェアの区別は、ガバナンスと、主に脆弱性に対する説明責任と責任に関しては、意味を持ちうる
- OSSの場合、誰もが自由にコードを公開、使用、編集できるため、コードの所有者や脆弱性を管理するための「適切な連絡先」を特定することは、より複雑になる。
- OSS と商用 の両方の脆弱性を扱うプロジェクトとしてアルファオメガ（Alpha Omega）が紹介されています。
- OECDが「調整の複雑さを克服する」方法について助言している(OECD、Encouraging Vulnerability Treatment:政策立案者のための概要、OECDデジタル・エコノミー・ペーパー、2021年2月)
- OSSが世界中で生産され使用されているソフトウェアに存在することから、脆弱性の管理について国際的な（または少なくともEUの）調整努力が必要である
4.1.3 OSS の文脈における「ソフトウェア部品表(SBOM)」の使用
SBOMについては、幾度となくふれていますが、この報告書でも注目がなされています。
- 公共組織や民間組織で使用されるソフトウェアの攻撃によるリスクは、リスクに基づくベンダ ー／パートナーのセグメンテーションやスコアリング以上の新たな緩和策を検討するのに十分なほど重大なも のになりつつある。
- SBOMは、ソフトウエアセキュリティとソフトウエアサプライチェーンのリスク管理における重要な構成要素として浮上してきた
- ドイツ連邦情報セキュリティ局が、国家ガイドラインの一部にSBOMを採用することを推奨していること
- ホワイトハウスは「国家のサイバーセキュリティの改善に関する大統領令」（2021年5月）を発表し、オープンソース・コードを使用する際の透明性とトレーサビリティの重要性を強調し、SBOMの使用も推進していること
- オープン財団が作成した「オープンソースソフトウェアセキュリティ動員プラン」と題する報告書は、自動化の取り組み、設計によるセキュリティ、SBOMの活用を含む10の具体的な推奨事項を提示している(日本語訳)
4.1.4 OSS の観点でのガバナンス
業界の専門家は、対応責任(Responsibility)、説明責任(Accountability)、結果責任(Liability )の概念を定義し、政府や民間組織が方針を策定する際の指針とするため、明確で標準化されたガイドラインを作成する必要があることを確認した
とされています。
それぞれの定義ですが、
-
対応責任(responsibility)とは、業務を遂行する義務やルールを遵守する義務を指す。
-
説明責任(Accountability)とは、タスクやプロセスの結果に対する回答責任を意味する。
-
結果責任(Liability)とは、何かに対して法的に責任がある状態のことである。
とそれぞれされています。
対応責任、結果責任の違いは、私のブログでもいろいろな局面でふれています。
- 投資詐欺広告へのイギリスの対応-インターネット媒介者の結果責任と対応責任
- 責任分界点
- ソフトウエア提供者の結果責任に関する判決群－In-Law「ユーザ・ベン ダの責任分界と損害の範囲 」セッション
- インターネット媒介者の役割と「通信の秘密」の外延(検索エンジン・CDN)-EU「プロバイダーの注意義務と責任」報告書の示唆
などです。この三つの区別は、まさに、「翻訳で失われたもの(Lost in Translation)」になるかと思います。残念ながら、私のこのキャンペーンにもかかわらず、この用語の区別をする人があまり増えないのは、残念なことです。
4.1.5 公共および民間組織における OSS の脆弱性の事例
イタリアでは、デジタル・イタリア庁（Agency for Digital Italy）とデジタル変革局（Digital Transformation Department）によって、公共行政で使用されている OSS のカタログが作成されたこと、が紹介されています。
また、イタリアデジタル庁とTeam Digitalが発表したOSSの取得と再利用に関するガイドラインが公表されています。
4.2 バグ報奨金制度によるセキュリティの外部委託に関する考察
4.2.1 コンテキスト
バグ報奨金制度（BBP）は、セキュリティ研究者や専門家が、発見した脆弱性を報酬と引き換えに提出できる専用のプログラムである。
4.2.2 バグ報奨金プログラムの構造
そこで、基本となるパラメータがあげられています。
- 目標。組織体はどのような目標を想定しているのか（脆弱性調査の外部委託、企業のセキュリティ態勢の強化、透明性の向上など）。
- 範囲。IT インフラストラクチャのどの部分が BBP の対象となるか（定性的な範囲の定義）。
- IT資産の数。BBPの開始時に対象となる資産の数と、後の段階で追加される可能性のある資産の数（量的範囲の定義）。
- 参加者。誰がBPPに参加するのか（組織体の外部の利害関係者か、会社のセキュリティチームの内部の専門家か、あるいは、この2種類の関係者の組み合わせか）。
- 期間。BBPの期間は？
- 報酬。セキュリティ研究者がその研究成果の対価として受け取る報酬の性質と価値は何か（通常は金銭的なものであるが、必ずしもそうである必要はない）。
- コミュニケーション・チャネル。研究者、組織体、仲介者はどのようにコミュニケーションをとるのか。
このプログラムの効果・体制の整備の説明がなされており、そのうえで、モデルについてふれられています。
- クローズド BBP は招待制のプログラムであり、主催主体によって限定された数の研究者が選ばれ、招待される。
- ハイブリッド型 BBP は登録制のプログラムで、関心のある研究者が自由に登録し、参加前に主催主体による審査が行われる。
- オープンBBPは、関心のある研究者であれば誰でも参加できる公開プログラムである。
4.2.3 セキュリティ・バイ・デザイン
ここでは、
BBPとセキュリティ・バイ・デザインは、最終的にはITエコシステムのセキュリティを向上させる補完的な概念と見なすべきであるという事実については、一般的なコンセンサスが得られている
とされています。
一方で、「セキュリティ・バイ・デザイン」アプローチの採用が 課題をもたらすことにも留意すべきであるとして
- 例えば、ソフトウエア開発のアプローチや考え方が異なり、開発手法を適応させる必要があるため、追加コストが発生する可能性がある（実装、トレーニング、人的資源、コンサルティングサービスなど）。
- セキュリティプログラムの初期段階では、安全なソフトウエア開発ライフサイクル （SSDL）を実施することを最優先とし、その後、製品のセキュリティを確保するための BBP の利点をさらに評価すべきである。
ともされています。
4.2.4 行政機関におけるバグ報奨金プログラム
既存の制約や躊躇にもかかわらず、公的機関でもBBPが可能であることを示しているとして
- Hack the Pentagon
- Hack U.S.
- 2022 年初めに開始された欧州委員会のプログラム
脆弱性開示プロセスの確立の要求があったことから、
行政内部で観察された傾向や利害関係者のフィードバックに沿えば、世界中の行政機関でBBPの採用が継続的に拡大すると予想するのが妥当である
とされています。
4.2.5 バグ・バウンティ・プログラムの課題
この課題としては
- IT資産の所有者の特定が困難であり、脆弱性の修正の責任者をどのように定義するかに関するガイドラインが不明確であること
- 脆弱性を報告する研究者、組織の開発者、組織のセキュリティチーム間のコミュニケーションが不十分であること
- 開発や研究とは対照的に、セキュリティチームに割り当てられるリソースが限られていること
があげられています。
5 技術的課題への取り組み
技術的課題に対処し、効率性と有効性を高める自動化の利用でが、脆弱性改善のために重要であるとされています。
そこでは、1. 脆弱性管理における自動化プロセスの使用に関する考察。2. 脆弱性の優先順位付けと処理における自動化ワークフローの使用を促進する CVD ツール、について検討されています。
