NCSC.nl

1. はじめに

社会はますますデジタル化しています。今日では、携帯電話から専用ソフトウェアに至るまで、ほぼすべてのプロセスがどこかの時点でコンピュータの利用を伴います。この発展は多くの新しい機会を生み出す一方で、IT システムの脆弱性は大きな影響を及ぼしかねません。そのため、こうした脆弱性に関する知識は、効果的に扱われなければなりません。

2013年の初めに、いくつかの組織が、脆弱性の報告方法に関する方針の公表を始めました。これらの組織との協議を経て、国家サイバーセキュリティセンター（NCSC）は、その動向を「責任ある開示（Responsible Disclosure）の実践に至るためのガイドライン」（オランダ語: ‘Leidraad om te komen tot een praktijk van Responsible Disclosure’。以下「ガイドライン」）という形でまとめました。企業はこの方針を通じて、外部からの脆弱性報告を受け入れる用意があることを示し、前提条件を説明し、約束を行います。このプロセスは、報告者が刑事上の犯罪行為に直接あたることなく脆弱性を調査し報告するための、明確さと、ある程度安全な環境をもたらしました。2016年の EU サイバーセキュリティ・ハイレベル会合では、29の組織が、CIO Platform Netherlands と Rabobank が NCSC と協力して提唱した「協調的脆弱性開示マニフェスト」1に署名することで、脆弱性への対処方針の重要性を改めて確認しました。

協調的脆弱性開示（CVD）は、公的機関と民間の双方にとって非常に重要であることが証明されています。これらの主体は、日々の実務において情報システムが妨げられることなく機能することに大きく依存しています。自らのシステムにおける脆弱性の報告は、一方では脆弱性の是正を通じて、他方ではオランダ企業全般の IT セキュリティ意識への貢献を通じて、近年のシステムのセキュリティと継続性の向上に役立ってきました。

近年、報告者が、組織の定めた CVD 方針の条件の範囲内で活動する意思を持っていることが明らかになりました。報告は、報告者から組織へ直接または間接に行われます。責任ある開示の実践は、善意の報告者と脆弱な組織が協力でき、そのことでネットワークおよび情報システムのセキュリティを高める次の一歩を踏み出せたことを示しました。

今回の改訂にあたっても、私たちは、幅広く多様な報告者、民間および公的機関、さらには検察庁と国家警察と、あらためて話し合いました。これらの対話は現在の実務を裏付け、追加と改善につながりました。最も重要な新たな注目点は、脆弱性の報告者と組織との間、および脆弱性が是正された後の他の関係者とのコミュニケーションです。

以下の章では、CVD の定義、CVD 方針の構成要素、そしてコミュニケーションのプロセスについて論じます。

補足: 以前のガイドラインでは、当時この実践の一般的な用語であった「責任ある開示（responsible disclosure）」という用語を使っていました。その後、この用語は報告者の責任を過度に強調する一方で、基本原則は、報告者と脆弱性を抱えるおそれのある組織が、対話において対等なパートナーであるべきだということだと明らかになりました。この考え方は、現在一般に使われている「協調的脆弱性開示（Coordinated Vulnerability Disclosure、CVD）」という用語のほうがよく表しています。これは、このプロセスに関する ISO 29147 および 30111 規格で使われている名称でもあります。

2. 協調的脆弱性

過去30年間に、IT システムの脆弱性への認識を高めるために、さまざまな方法が用いられてきました。例を挙げます:

「フルディスクロージャー（Full Disclosure）」: 脆弱性を完全に公開すること。
「非開示（Non-disclosure）」: 脆弱性を売ったり、自分で利用したりすること。
「協調的脆弱性開示（Coordinated Vulnerability Disclosure、CVD）」: 脆弱性を協調して開示すること。

後者の実践が、明確に推奨されます。

IT コミュニティは、知識と経験を共有することに大きな意欲を示してきました。したがって、このコミュニティと協力を求めることは、システム全体のセキュリティを向上させるのに役立ちます。

協調的脆弱性開示の目的

CVD の目的は、脆弱性に関する知識を共有することで、IT システムのセキュリティに貢献することです。CVD では、知識は、脆弱性を抱えるおそれのある1つまたは複数の組織と共有され、報告者との協力のもとで、見つかった脆弱性に対する共同の解決策に到達します。影響を受ける組織が、損失や損害を可能な限り抑えたり防いだりするために、脆弱性を是正したりシステムを保護したりするのに十分な時間を持つことが重要です。このプロセスの要は、是正後に脆弱性に関する知識を開示することです。

CVD では、脆弱性をどのように報告し、どのように扱うかについて、すべての関係者が合意事項を守ることが不可欠です。組織があらかじめ前提条件を公表していること、たとえば、どのシステムが対象範囲に含まれ、どのような調査を行ってよいかを示していることは役に立ちます。これらの前提条件に関する重要な原則は、調査と報告が設定された条件の範囲内で行われている限り、組織は原則として報告者を通報せず、その他の法的措置もとらないということです。本ガイドラインは、CVD の原則を具現化する独自の方針を組織が策定するための指針を提供します。

名称が示すとおり、CVD では、組織と報告者が互いに調整することが中心になります。この点で、脆弱性を報告する人と、問題の解決に責任を持つ組織内の担当者との間のつながりは、できるだけ少なくすべきです。

脆弱性が多くのシステムに影響する場合、複数の関係者に同時に知らせることが重要になることがあります。その場合、NCSC またはセキュリティコミュニティ内の他の関係者が、調整役としての立場から CVD プロセスを支援できます。

3. 責任の範囲

CVD 方針を追求する目的は、報告者と組織が協力して、IT システムの脆弱性を減らすことです。この方針の実施は、情報セキュリティに関する既存の対策を補完するものとみなすべきです。さまざまな主体にはそれぞれ固有の役割と責任があります。以下で詳しく説明します。

システムを所有・管理する組織

システムを所有・管理する、または提供する組織は、そのシステムのセキュリティに第一義的な責任を負います。言い換えれば、その組織は脆弱性報告への対応にも責任を負います。

組織は、本ガイドラインを用いて独自の CVD 方針を策定し、その方針を潜在的な報告者に伝えることを選択できます。CVD 方針を公表することで、組織は脆弱性に関する情報を受け入れる意思を示します。

CVD 方針を定める当事者は、方針に適用されるルールが守られている限り、警察に告訴しないという原則を約束することができます。

報告者が脆弱性を報告したら、責任は組織にあります。報告者は多くの場合、組織の外部の人であることを認識することが重要です。この当事者は、脆弱性が報告された後に開始されうる内部プロセスを直接見ることができません。そのため、報告者は、脆弱性の解決に関する進展について知らされることを喜びます。こうした継続的なコミュニケーションは、その後の対応や解決の適時性について適切な期待を生み出すためにも重要です。

脆弱性を報告する当事者

報告者は、何らかの方法で脆弱性を特定でき、その脆弱性を是正させ、場合によっては後の段階で公開することで、IT システムのセキュリティに貢献したいと考えています。報告者は、受動的な観察によって、あるいは IT システムを積極的にテストすることで、何かを発見したのかもしれません。当然ながら、この当事者は、自身の行動と、脆弱性を発見した方法に責任を負います。組織がその CVD 方針で定めた条件を把握しておくことは、報告者自身の責任です。ほとんどの政府機関や企業は、ウェブサイトに CVD 方針を公表しています。

それでも、脆弱性の発見は法律違反を伴うことがあります。CVD の文脈では、組織と報告者は、いかなる犯罪行為についても告訴しないことで合意できます。この点について、組織が公表した CVD 方針が指針となります。当事者は、民事上の措置もとらないことで合意することもできます。

報告者が法律に違反したという疑いがある場合、CVD 方針は、まず、報告者が当局に通報されるのを防ぐのに役立ちます。この手続は、組織が報告者に遵守を求める方針の前提条件と、その遵守が達成されたかどうかに全面的に依存し、場合によっては、当事者が方針の条件の範囲内で行動している限り刑事告訴をしないという対応する約束を伴います。警察に通報された場合、CVD 方針の存在とその遵守は、オランダでは関連する事情であり、検察官は刑事捜査を開始するか、または起訴するかを決定する際にこれを考慮します。原則として、報告者が当該組織の CVD 方針のルールを明らかに遵守していた場合、警察と検察庁（OM）は刑事捜査を開始しません。しかし、報告者が意図的にまたは無意識のうちに行動の度を超した、または CVD 方針を遵守しなかったことを示す兆候がある場合は、検察庁と警察は事件をさらに捜査することができます。この捜査に基づいて、検察庁は起訴するかどうかを決定できます。

検察庁は、捜査や起訴の決定に至るうえで重要な側面を、より具体的に扱った方針書簡を公表しています。たとえば、報告者の行動が重要な公共の利益に資していたか、当事者が不均衡な行動をとったか、当事者が別の、より穏当な方法で行動できたのではないか、といった点です。当該の方針書簡は、これらの側面をさらに詳しく説明しています。2 2013年以降の関連する判例3は、組織が CVD 方針を持たない場合でも、これらの側面が裁判で考慮されることを示しています。

4. 協調的脆弱性開示プロセスの構成要素

組織、報告者、NCSC のための CVD プロセスを形づくる構成要素を、以下に示します。

組織

CVD の推進は、IT システムを所有する、または IT 製品・システムを提供する組織から始まります。結局のところ、この組織がこれらの IT システムの情報セキュリティに第一義的な責任を負うからです。脆弱性を解決するためにさまざまな関係者と効果的に協力するため、組織は CVD 方針を策定し公表することを決定できます。独自の CVD 方針を策定することで、組織は脆弱性報告にどう対処するかを示すことができます。こうして組織は、通知をどのように受け取りたいかを具体化することもできます。このようなプロセスは、次のように組織できます:

組織は CVD 方針を策定し、公表する。
この方針のなかで、組織は、報告者が行える調査について、どの手法が許可されるか、どのシステムが対象範囲の内か外かなど、明確なルールを示す。
組織は、報告者が報告しやすいようにする。選択肢の1つは、特定のメールアドレスやオンラインフォームなど、標準化された報告方法を使用することである。さらに、組織は匿名の報告を受け付けるかどうかを決めることができる。
組織は、報告に適切に対応するために、内部の対応能力を確保し、プロセスを整備する。見つかった脆弱性を適切に是正できるプロセスを整備することが望ましい。この点で、報告の出所は関係ない。脆弱性は、たとえば社内の従業員やテストの際に特定されたものである場合もある。
実務上の経験から、CVD 方針が最初に公表された後は、組織への脆弱性報告への関心が高まることが分かっている。組織は、（追加の）対応能力を計画する際にこれを考慮すべきである。
組織が脆弱性報告を受け取ったら、その報告を評価し対処するのに最も適した部署に、できるだけ早く報告が届くようにする。
組織は、報告者に受領確認を送る。優先度を強調するため、できれば電子署名を付ける。
その後、組織は報告者と協議し、公表が行われる期間を決定する。この期間は、脆弱性の性質とシステムの種類によって大きく異なる。
目安として、ソフトウェアの脆弱性にはおよそ60日の期間がよく用いられる。ハードウェアの脆弱性の是正はより難しく、6か月を目安にすることができる。
脆弱性が報告されたシステムに依存する IT システムの数の多少や、脆弱性の解決の難易度に応じて、双方の合意によりこの期間を延長または短縮することが望ましい場合がある。
脆弱性の解決が難しい、あるいは不可能であることが判明する場合や、解決に高額な費用がかかる場合がある。そのような場合、組織は、場合によっては報告者と協議のうえ、その脆弱性を許容されるリスクとみなし、是正しないことに同意することができる。
組織は、プロセスの進展について報告者に知らせ続ける。
さらに、組織は、脆弱性を公表したことについて、報告者を公に称えることを申し出ることができる。外部への共同開示を選択することもできる。
報告者が CVD 方針のルールを遵守した場合、システムの脆弱性を報告したことに対して報告者に報いることが望ましい。報奨の額は、報告の質によって決まることがある。報告者に報いることで、その当事者と組織との間により良い関係を築くことができ、CVD 方針に従って新たな報告を行う人々の意欲も高まる。
報告者との協議のうえ、その脆弱性が他の場所にも存在する可能性が高い場合は、組織は、より広い IT コミュニティに脆弱性について知らせることに同意することができる。
CVD 方針において、組織は、報告者が方針に示されたルールを遵守した場合は警察に告訴しないという原則を約束することができる。

報告者

報告者は、CVD プロセスを成功させる鍵です。この当事者は、何らかの方法で脆弱性を特定でき、その脆弱性を組織に是正させて公表することで、IT システムのセキュリティに貢献したいと考えています。そうすることで、報告者は、脆弱性を協調的な方法で明らかにすることにより、社会に重要な貢献ができることを認識しています。CVD プロセスを成功させるために、報告者にとって次の構成要素が重要です:

報告者は自身の行動に責任を負い、脆弱性を調査し報告する際には、比例性の原則と補完性の原則の両方を守らなければならない。言い換えれば、報告者は、脆弱性を実証するために必要な範囲を超えて行動すべきではなく、常に、まずシステム／情報の所有者に脆弱性を報告すべきである。
悪意のある者が脆弱性を発見し、それを悪用することを防ぐため、報告者はできるだけ早く問題を報告しなければならない。
他の者がこの情報にアクセスすることを防ぐため、報告者は、組織への報告を機密の方法で行わなければならない。
報告者は、報告の提出や追加情報の提供を、報酬に左右されてはならない。報告があった場合に報酬を与えるかどうかの主導権は、受け取る組織にあり、組織はその公表された方針において前提条件を示すことができる。
報告者と組織は、脆弱性の開示について明確な合意をする。複数の組織が関わっている場合は、すべての組織がその事実に同意した場合にのみ脆弱性を公表できる、というのが基本原則である。これらの合意は、早い段階でしておくことが望ましい。
報告者と関係する組織は、より広い IT コミュニティへの周知について合意することができる。たとえば、この状況は、複数の場所に存在することが知られている脆弱性（すでに知られているかどうかを問わない）に当てはまる。国家サイバーセキュリティセンター（NCSC）は、中央政府や重要インフラの対象グループを支援するため、または多くのシステムに影響する脆弱性が生じた場合に複数の関係者に知らせるために、このプロセスに関与することができる。

NCSC

CVD プロセスは、第一に組織と報告者の問題です。それでも、NCSC は CVD プロセスの利用を奨励します。報告者および組織との協議のうえ、NCSC は、その脆弱性から生じるさらなるセキュリティリスクを抑えるため、その対象コミュニティ（constituency）と脆弱性に関する情報を共有することにも関与できます。

脆弱性の報告が報告者の期待どおりに進まない場合、または脆弱性を組織に直接報告したくない場合、報告者は NCSC に連絡できます。4 この場合、NCSC は必要に応じて仲介役を務めることができます。

IT システムの所有者は、常にそのシステムのセキュリティに責任を負います。NCSC は、システムの所有者に脆弱性の是正を強制することも、所有者が報告者に対して法的措置をとらないことを保証することもできません。その結果、報告者は、脆弱性を探し報告する際に、組織と報告者に関する前述の構成要素を考慮しなければなりません。報告者は、NCSC が脆弱性の是正のために最善を尽くし、報告を機密として扱うことを期待できます。NCSC は、法的に義務づけられている場合を除き、個人データを共有しません。

可能であれば、NCSC は、組織および報告者との協議のうえ、脆弱性について得た情報を、IT コミュニティとの知識のさらなる共有に使用します。たとえば、情報の一部を公表する、ファクトシートやホワイトペーパーを作成または更新する、あるいは特定の組織に知らせることによって行います。

関係する組織と確認された脆弱性の性質に応じて、NCSC は、その脆弱性を当該組織の注意に留めるよう努める。ただし、当該 IT システムの所有者がそのシステムに対して引き続き責任を負う。
可能で必要な場合、NCSC は、脆弱性の是正方法について、関係する組織に助言を提供する。
NCSC は報告を機密として扱い、法定の義務に基づく場合を除き、同意なしに報告者または受け取る組織の個人データを共有しない。
可能な限り、NCSC は、組織との連絡の進展と脆弱性の是正について、報告者に知らせ続ける。
NCSC に報告があった場合、NCSC は、報告者または潜在的な報告者と組織を引き合わせるよう努める。

たとえば、報告者がソフトウェア製品の脆弱性や、多くの異なるシステムに影響する脆弱性を見つけた場合、報告者は、NCSC に脆弱性の是正と開示の調整を依頼できます。

NCSC は、報告者、パートナー、開発者やソフトウェア開発者、その他のセキュリティチームとともに、脆弱性を分析し、是正または是正させ、調整し、管理された方法で開示するのを支援します。このプロセスはすべて、脆弱性を見つけた報告者との緊密な協議のもとで行われます。

CVD 方針は、措置を講じられるよう脆弱性をできるだけ早く開示することの重要性と、開発者や供給者が脆弱性を是正するのに十分な時間を持つことの重要性とのバランスをとろうとします。このプロセスにおいて、NCSC は、報告から公開までを60日とする標準期間を使用します。ただし、この期間を延長または短縮することが決定される状況もありえます。

NCSC は、報告者との協議後にのみ、脆弱性に関する情報を第三者と共有します。この文脈では、NCSC が協力し、脆弱性を協調して開示するために関係者と脆弱性に関する情報を共有することが不可欠です。NCSC は、その際、適切な関係者が脆弱性の是正に取り組めるようにし、損失や損害の抑制に役立ち、見つかった脆弱性への注意喚起に役立つようにします。

5. コミュニケーションと開示プロセス

5年間の実践から、明確なコミュニケーションが CVD プロセス成功の要であることが分かっています。CVD プロセスの前、最中、後に、それぞれ注意すべき点があります。

開示プロセスに関するコミュニケーション

CVD 方針の公表は、プロセスについてのコミュニケーションの第一歩です。方針を公に公表することで、報告者は、見つけた脆弱性を組織に通知するよう促されます。

一方で、組織は、脆弱性を発見するために行われる調査の条件と、連絡の取り方に関する条件を定めることができます。他方で、組織は、方針のルールが守られている限り警察に告訴しないという原則を約束できます。この方法は、報告者の立場を守ります。

CVD 方針は、後日変更または更新されることがあります。この点で、変更について明確にしておくことが重要です。報告者は、何がいつ変更されたかを知ることに関心があります。たとえば、CVD 方針の冒頭に公表日を記載する、CVD 方針の下に変更点の概要を記述する、または CVD 方針の旧版のアーカイブを保管することで、変更を明確にできます。

CVD 方針には、プロセス中のコミュニケーションの方法に関するガイドラインを定めることができます。たとえば、メールやウェブポータルによる定期的な更新を示すことです。さらに、CVD 方針には、更新時の言及、殿堂入り（hall of fame）、その他の形の報酬によって、報告者をどのように称えるかを記載することができます。

開示プロセス中のコミュニケーション

報告者は、組織にメッセージを送ることで CVD プロセスを開始します。このメッセージのなかで、報告者は発見した脆弱性を明確に説明します。重要な要素は、影響を受けるシステムの IP アドレスまたは URL と、脆弱性を再現するために必要な手順です。

組織が報告者に明確に伝え、プロセスに関する期待が明確になるようにすることが重要です。

これは、最初のまたはその後の実質的な返答が送られる期間の目安を含む、（自動かどうかを問わない）受領確認を送ることで、すでに実現できます。

この期間を決めずにおき、報告の内容を評価した後に期間の最初の目安を示すこともできます。解決策が実現できる期間について、できるだけ早く明確にすることが望ましいです。こうすることで、報告者は結果がいつ得られるか分かります。

場合によっては、たとえばカンファレンスでの発表があるから、あるいは報告者が独自の期限を決めているから、公表日が報告者にとってすでに明確であることがあります。この場合でも、報告者がこのスケジュールを明確に伝え、できるだけ早い段階で示し、この日付を延期できるか否かについて明確にしておくことが重要です。

報告者は多くの場合、組織の外部の人であり、報告によって開始されうる内部プロセスを知る手立てがありません。組織は、定期的な更新を通じて、プロセスの進展を報告者に知らせ続けることができます。この方法により、解決策に取り組んでいることが報告者に伝わります。必要に応じて、組織は、プロセス中に説明を求めたり、解決策のテストを依頼したりすることができます。

組織が当初の解決期限に間に合わない場合、報告者と協議して延期することができます。定期的なコミュニケーションにより、この状況をより早い段階で報告者に明らかにできます。

CVD の主な意図は脆弱性を緩和することですが、プロセスに時間がかかりすぎると報告者が感じる場合、脆弱性の「フルディスクロージャー」は常に報告者にとっての選択肢です。この手段は、報告者が使える、いわゆる「大きな棒」です。当然ながら、この状況はできるだけ防がなければなりません。

開示プロセス後のコミュニケーション

報告者が脆弱性を探し、CVD プロセスを通じて組織に報告する理由は、数多く考えられます。多くの報告者にとって、（公の）評価は重要な動機です。

報告者は、更新時の謝辞や殿堂入りを通じて、公に評価されます。ただし、公の評価の必要性はすべての報告者に当てはまるわけではありません。実際、公に知られたくない報告者もいます。したがって、組織が発信する場合は、報告者の名前を挙げることについて、報告者の同意を得ることが望ましいです。

さらに、報告者は、CVD プロセスの完了後に報告についてコミュニケーションをとることを決めることもできます。たとえば、報告者は発見のプロセスを説明したり、他の人々に脆弱性について警告したりすることができます。報告者は、情報提供の目的で、その公表物を組織に提出することにしてもよいでしょう。CVD プロセスは、脆弱性の除去をもって原則として完了するため、方針の中やプロセスの途中で追加の合意がなされていない限り、報告者はその後、自由にそれについてコミュニケーションをとれます。

一覧

開示プロセスに関するコミュニケーション

ウェブサイトでの CVD 方針の公表
制限について明確にする（さまざまなアプローチは第6章を参照）
調査方法の制限
コミュニケーションに関するガイドライン
想定される報酬に関するガイドライン: 殿堂入り、金銭的報酬、T シャツなど
CVD 方針の更新について、変更日を含めて明確にする

開示プロセス中のコミュニケーション

報告者が、発見した脆弱性について組織に連絡する。
組織が、最初の技術的な返答までの時間など、期待値を管理する。
組織と報告者が、想定される解決期間について互いに明確にする。
組織が、（プロセスの）更新を頻繁に提供する。
必要に応じて、報告者と組織が、関連する他の組織への連絡について話し合う。

開示プロセス後のコミュニケーション

報告者への（公の）評価と報酬について話し合う。
脆弱性に関する情報をどのように公表するか、たとえば調査段階や他の組織への周知などを取り決める。

6. 協調的脆弱性開示方針の例

協調的脆弱性開示に関する方針の文面には、さまざまな形式があります。公表された CVD 方針は、潜在的な報告者への道しるべとして機能するため、この方針の形式が組織の方針と戦略に沿ったものになるようにしてください。

CVD 方針では、次の要素が重要です:

安全なコミュニケーションのための連絡方法
報告者の前提条件
報告の取り扱いに関する明確な期待
報告への報奨の方法
バージョン番号と最終改訂日

以下に3つの例を示します。オランダの多くの組織は、ResponsibleDisclosure.nl の基本的な例を参考にしています。他の組織は追加の前提条件を含めています。Fox IT の方針を参照してください。さらに他の組織は、対象とする読者に合わせてより自由な形式を採用しています。Bits of Freedom の方針を参照してください。

Acme Corporation では、システムのセキュリティを最優先事項と考えています。しかし、システムセキュリティにどれだけ努力を注いでも、脆弱性が存在する可能性は残ります。

脆弱性を発見された場合は、できるだけ早く対処するための手立てを講じられるよう、お知らせください。

お客様と当社のシステムをより良く守るために、ご協力をお願いします。

次のことをお願いします:

発見した内容を cert@example.com にメールで送ってください。この重要な情報が悪意ある第三者の手に渡らないよう、当社の PGP キーで発見内容を暗号化してください。
発見した脆弱性や問題を悪用しないでください。たとえば、脆弱性を実証するのに必要な量を超えるデータをダウンロードしたり、他の人のデータを削除または変更したりしないでください。
問題が解決されるまで、他の人に問題を明かさないでください。
物理的セキュリティへの攻撃、ソーシャルエンジニアリング、分散型サービス拒否、スパム、第三者のアプリケーションを使用しないでください。
問題をできるだけ早く解決できるよう、問題を再現するための十分な情報を提供してください。通常は、影響を受けるシステムの IP アドレスまたは URL と脆弱性の説明で十分ですが、複雑な脆弱性ではさらなる説明が必要になることがあります。

当社の約束:

報告から3営業日以内に、報告の評価と解決の予定日をお知らせします。
上記の指示に従っていただいた場合、報告に関して、お客様に対する法的措置はとりません。
報告は厳重に機密として扱い、お客様の許可なく個人情報を第三者に渡しません。
問題の解決に向けた進捗をお知らせします。
報告された問題に関する公開情報では、（別段の希望がない限り）問題の発見者としてお客様のお名前を記載します。
ご協力への感謝のしるしとして、当社がまだ把握していなかったセキュリティ上の問題の報告ごとに、報奨を提供します。報奨の金額は、漏えいの深刻度と報告の質に基づいて決定されます。最低報奨額は50ユーロのギフト券です。

当社は、すべての問題をできるだけ早く解決するよう努めており、問題が解決された後の最終的な公表に、積極的な役割を果たしたいと考えています。

例: Fox-IT

Fox-IT では、当社のシステム、ネットワーク、製品のセキュリティを最も重要なものと考えています。セキュリティに細心の注意を払っていても、弱点が残ることがあります。そのような弱点を見つけられた場合は、できるだけ早く適切な対策を講じられるよう、できるだけ早くお知らせください。

弱点の発見には2つの方法があります。デジタル環境を通常どおり利用している間にたまたま何かに行き当たる場合と、明確に弱点を見つけようと努力する場合です。

当社の責任ある開示ポリシーは、弱点を発見するために当社の業務ネットワークを積極的にスキャンすることを促すものではありません。当社は自ら業務ネットワークを監視しています。つまり、スキャンが検知される可能性が高く、当社のセキュリティオペレーションセンター（SOC）が調査を行うことになり、不要なコストが発生しかねません。ただし、オフラインの非本番環境で当社の製品の脆弱性を積極的に探し、その結果を当社に報告していただくことは歓迎します。お客様に対する当社の責任として、お客様のインフラへのハッキングの試みを奨励する意図はありません。しかし、脆弱性が見つかった場合は、適切に解決できるよう、できるだけ早くお知らせいただきたいと考えています。

お客様と当社のシステムをより良く守れるよう、皆様と協力したいと考えています。

次のことをお願いします:

発見した内容を、できるだけ早く security-alert@fox-it.com にメールで送ってください。
脆弱性を悪用しないでください。たとえば、データのダウンロード、編集、削除をしないでください。当社は常に報告を真剣に受け止め、証拠がなくても、脆弱性の疑いがあれば調査します。
問題が解決されるまで、他の人に問題を共有しないでください。
物理的セキュリティへの攻撃、ソーシャルエンジニアリング、脆弱性スキャナーのようなハッキングツールを使用しないでください。
問題を再現できるだけの十分な情報を提供してください。そうすれば、できるだけ早く解決できます。通常は、影響を受けるシステムの IP アドレスまたは URL と脆弱性の説明で足りますが、より複雑な脆弱性ではさらなる情報が必要になることがあります。

当社の約束:

報告から3営業日以内に、報告の評価と解決の予定日をお知らせします。
報告は機密として扱い、お客様の許可なく個人情報を第三者と共有しません。ただし、訴追の場合や情報が要求された場合の警察および司法当局は例外です。
問題の解決の進捗をお知らせします。
報告された問題についての連絡では、ご希望であれば、問題の発見者としてお客様のお名前を記載します。
残念ながら、お客様に対して法的措置がとられないことを事前に保証することはできません。各状況を個別に検討したいと考えています。弱点やデータが悪用されている、またはお客様が弱点の知識を他者と共有したと疑われる場合は、お客様を通報することが道義的に求められていると考えています。当社のオンライン環境での偶然の発見が、訴追につながることはないとご安心ください。
ご協力への感謝として、当社が把握していないセキュリティ上の問題の報告ごとに、報奨を提供します。報奨の額は、侵害の深刻度と報告の質に基づいて決定します。

当社は、すべての問題をできるだけ早く解決し、関係者全員に情報をお伝えするよう努めており、問題が解決された後の公表にも関わりたいと考えています。

例: Bits of Freedom

私たちのデジタルインフラへの依存は、ますます高まっています。これは社会全体に当てはまりますが、私たち自身にも当てはまります。したがって、政府や組織（私たちの組織を含む）は、デジタルインフラの保護に強く取り組むべきだと私たちは考えます。最善の意図と最大限の注意を払っても、私たちのシステムに脆弱性が存在しうることを、私たちは認識しています。こうした弱点を見つけた場合は、問題を解決できるよう、ぜひご連絡ください。

私たちがお願いすること

私たちのシステムを調査するときは、攻撃の比例性を念頭に置いてください。当社のウェブサイトにインターネット史上最大の DDoS 攻撃を加えれば、サイトが到達不能になりうることを実証する必要はありません。それは分かっています。また、オフィスにブルドーザーで突っ込めば、おそらくノートパソコンを1台奪えることも理解しています。
この比例性の原則は、脆弱性そのものを実証するときにも当てはまります。発見内容の正しさを確認するために厳密に必要な量を超えて、データを調べたり変更したりしてはいけません。たとえば、ホームページを変更できる場合は、ページ全体を乗っ取るのではなく、物議を醸さない単語を1つだけ追加してください。データベースにアクセスできる場合は、そこにあるテーブルの一覧を、あるいはそれらのテーブルのうちの1つの最初のレコードを示せば十分です。
私たちのシステムの脆弱性は、security@bof.nl にメールを送って、できるだけ早く報告してください。できれば OpenPGP でメッセージを暗号化してください。私たちが問題を再現し調査できるよう、十分な情報を提供してください。
security@bof.nl の OpenPGP 公開鍵
私たちが問題に対処していない間、そしてあなたが問題を報告してから妥当な期間内にある間は、脆弱性についての知識を他の関係者と共有しないでください。
私たちが脆弱性を解決したら、調査の過程で入手した機密情報をすべて削除してください。

私たちにできること

報告から3日以内に、詳細な返信をします。問題への対処に必要な見込み時間も添えます。もちろん、進捗は定期的にお知らせします。
脆弱性はできるだけ早く解決します。ここでも比例性が重要です。脆弱性の修正に必要な時間は、問題の深刻度や複雑さなど、いくつかの要因によって決まります。
ここに示したガイドラインに従っていただいた場合、報告に関して、あなたに対する法的措置はとりません。
ご希望であれば、あなたの功績を認めることは私たちにとって重要です。脆弱性に関する公表にあなたのお名前を記載するのは、あなたが同意した場合に限ります。
私たちのシステムをより良く守る手助けをしてくださったことへの感謝として、当時私たちが把握していなかった脆弱性の報告ごとに、報奨を差し上げたいと考えています。報奨は、脆弱性の深刻度と報告の質によって決まります。
私たちが使用している第三者のソフトウェアに脆弱性を見つけ、その脆弱性がバグ報奨金プログラムの対象である場合、私たちはその報奨金を請求しようとはしません。あなたが請求すべきです。