RFC9116 セキュリティ脆弱性開示支援のためのファイルフォーマット

RFC9116 として「セキュリティ脆弱性開示支援のためのファイルフォーマット」が公表されているので、検討したいと思います。リンクはこちらです。

この文書は、研究者が脆弱性を報告しやすくするために、組織が脆弱性の開示方法を記述するための機械解析可能なフォーマット（”security.txt”）を定義しています。

でもって、脆弱性の開示については、

私のブログ

日本における脆弱性研究委員会の一連の資料

ISO

脆弱性取扱手順については、「情報セキュリティ－セキュリティ技術　脆弱性取扱過程（ISO/IEC 30111:2019 Information technology — Security techniques — Vulnerability handling processes）」
脆弱性開示については、「情報セキュリティ－セキュリティ技術　脆弱性開示（ISO/IEC 29147:2018 Information technology — Security techniques — Vulnerability disclosure）」

が基本的な知識になります。

インターネットウォッチの記事

米連邦政府機関に策定と公表が義務付けられた脆弱性開示ポリシーとは

1. はじめに

1.1. 動機、先行研究、および範囲

多くのセキュリティ研究者が、報告経路がないこと、脆弱性開示の実践に関する情報が得られないことからセキュリティ脆弱性を組織に報告できない状況に遭遇しているとしています。

連絡の規定について

RFC2142(一般サービス・役割・機能のためのメールボックスの名前)のセクション4にあるように、セキュリティ問題に関する通信には<SECURITY@domain>という電子メールアドレスを使用するという既存の慣例があります。もっとも、この慣例は、ドメインごとに1つの電子メールベースの通信チャネルを提供するだけであり、ドメイン所有者がセキュリティ公開の実践に関する情報を公開する方法を提供するものではありません。

以下のような連絡の規定があります。

[RFC3013](ISP kセキュリティサービスおよび手続)のセクション2は、インターネットサービスプロバイダ(ISP)の
[RFC2350]のセクション3.2はコンピュータセキュリティインシデント対応チーム（CSIRT）のために
[RFC2196]のセクション5.2はサイト運用者のために定められた

また、[RFC7485]にあるように、IPアドレス、ASN（Autonomous System Numbers）、ドメイン名の所有者に対して、RIR（Regional Internet Registries）やドメインレジストリが提供する連絡先情報もあります。しかし、これらのいずれも、セキュリティ研究者が脆弱性を報告するために、どのようにして組織の連絡先や脆弱性公開の方法を見つけるかという問題には取り組んでいません。

脆弱性の連絡について

この文書は、組織がセキュリティ開示の実践と連絡方法に関する情報を伝達するための、より豊かで、機械的に解析可能で、より拡張可能な方法を定義するものです。従って、脆弱性の開示に関するその他の詳細は、このドキュメントの範囲外とされます。読者は、[ISO.29147.2018]や[CERT.CVD](The CERT Guide to Coordinated Vulnerability Disclosure)などの他のドキュメントを参照することが推奨されます。

[CERT.CVD]は、「脆弱性対応」は製品の脆弱性の報告を指し、ネットワーク侵入や侵害されたウェブサイトの報告（「インシデント対応」）とは関連するが別であることを明らかにしていて、本書で定義するメカニズムは、前者（「脆弱性対応」）のために使用することを意図しています。

「security.txt」ファイルは補完的なものであり、セキュリティ公開の実践に関して組織が維持する他の公開リソースの代替や代用になるものではないことを意図しています。

1.2. 用語の説明

本文書におけるキーワード「MUST」「MUST NOT」「REQUIRED」「SHALL」「SHALL NOT」「SHOULD」「SHOULD NOT」「RECOMMENDED」「NOT RECOMMENDED」「MAY」「OPTIONAL」は、ここに示すようにすべて大文字で現れるときだけ BCP 14 [RFC2119] [RFC8174] に記載されているように解釈することとしています。

「調査者(researcher)」という用語は、[ISO.29147.2018] および [CERT.CVD] における「発見者」および「報告者」という用語に対応します。

「組織」という用語は、[ISO.29147.2018]および[CERT.CVD]の「ベンダー」という用語に対応する。

「実装者」という用語は、脆弱性開示プロセスに関与するすべての関係者を含みます。

2. 仕様について

この文書は、特定の組織の脆弱性開示の実践に関する情報を提供する、既知の場所に配置されるテキストファイルを定義する。このファイルのフォーマットは機械で解析可能であり、セクション 4 で定義された ABNF 文法に従わなければならない(MUST)。このファイルは、セキュリティ研究者がセキュリティ脆弱性を開示する際に役立つことを意図している。

慣習として、このファイルの名前は「security.txt」である。その場所と範囲は、セクション3で説明されている。

このテキストファイルは、異なる値を持つ複数のフィールドを含んでいます。

フィールドは「名前」を含み、これはフィールドの最初の部分からコロンまで(例：「Contact:」)で、[RFC5322]のセクション3.6.8で「field-name」について定義されている構文に従います。

フィールド名は大文字と小文字を区別しません(RFC5234]のセクション2.3による)。

「value」はフィールド名の後にあり(例: 「mailto:security@example.com」)、 [RFC5322]のセクション3.2.5で「unstructured」に対して定義されている構文に従います。ファイルには空白行を含んでもよい[MAY]。

フィールドは常に名前と値で構成されなければならない[MUST](例: 「Contact: mailto:security@example.com」)。「security.txt」ファイルは、無制限の数のフィールドを持つことができる。各フィールドはそれ自身の行に表示されなければならない(MUST)。フィールドの定義で特に指定されない限り、1つのフィールドに対して複数の値を連鎖させてはならない(MUST NOT)。特定のフィールドの定義に別段の定めがない限り，一つのフィールドを複数回出現させてもよい(MAY)。

実装者は、一部のフィールドがパーセントエンコーディングを使用したURIを含むかもしれないことに注意すべきである(as per Section 2.1 of [RFC3986])。

以下、コメント(2.1-#)、行の区切り文字(2.2.)、デジタル署名(2.3)、拡張性(2.4)、フィールド定義(2.5)、について触れられています。

3 security.txtファイルの場所

Webベースのサービスでは、組織は「security.txt」ファイルを「/.well-known/」のパス、たとえばドメイン名またはIPアドレスの[RFC8615]に従ってhttps://example.com/.well-known/security.txt 下に置かなければならない[MUST]。レガシー互換性のために、「security.txt」ファイルはトップレベルのパスに置かれるか、(［RFC7231］のセクション6.4に従って)「/.well-known/」パスの下にある「security.txt」ファイルにリダイレクトされるのも可能である。security.txt」ファイルが両方の場所に存在する場合、「/.well-known/」パスのものが使用されなければならない[MUST]。

このファイルは、HTTP1.0またはそれ以上のバージョンでアクセスされなければならず、ファイルアクセスには「https」スキームを使用しなければならない（[RFC7230]のセクション2.7.2に準ずる）。また、Content-Typeは「text/plain」で、デフォルトのcharsetパラメータは「utf-8」でなければならない(MUST)(【RFC2046】のセクション4.1.3による)。

「security.txt」ファイルおよびそのファイル内に示されたリソースを検索すると、リダイレクトが発生する場合があります（[RFC7231]のセクション6.4による）。研究者は、これらのリダイレクトが悪意のあるものでないこと、または攻撃者が管理するリソースを指していないことを確認するために、（セクション5.2に従って）追加の分析を実行する必要がある。

どのサイトに適用がされるのか、について触れることが必要になることが、範囲(3.1)において述べられています。

4. ファイル形式の説明とABNF文法

「security.txt」ファイルのファイル形式は、[RFC2046]のセクション4.1.3で定義されているようにプレーンテキスト(MIMEタイプ「text/plain」)としなければならず、 Net-Unicode 形式で UTF-8 [RFC3629] を使用してエンコードされなければなりません[MUST][RFC5198]。

このファイルの形式は、以下のABNF定義に従わなければなりません(MUST)([RFC5234]のコアABNFルールを取り入れ、[RFC7405]のケースセンシティブ文字列サポートを使用しています)。

ここでは、具体的に、ボディ、署名の有無、クリアテキストヘッダ、ハッシュヘッダ、クリアテキスト、ラインダッシュ、..などの項目の記載の方法が示されています。

5. セキュリティの考慮事項

URIとよく知られたリソースを使用するため、以下に概説する考察に加えて、 [RFC3986]と[RFC8615]のセキュリティ考察がここでも適用されるとされます。

具体的な考慮事項としては、汚染さたファイルと対応(5.1)、リダイレクト(5.2)、不正確な情報または古い情報(5.3)、意図的に誤った様式のファイル、資源、報告(5.4)、試験の許可の意図がない場合(5.5)、マルチユーザ環境(5.6)、送信中のデータの保護(5.7)、スパムおよび不正なレポート(5.8)が論じられています。