倫理的な方法でセキュリティの脆弱性を開示する方法は？
倫理的な方法でセキュリティの脆弱性を開示する方法は？このトピックについては、さまざまな考え方の学校があると聞いています。それぞれの長所と短所を知りたいのですが。
開発者に非公開で知らせて、修正する機会を与える必要があります。その後、脆弱性を公開する場合、開発者が問題を修正するのに十分な時間を確保し、システムにアップグレードするのに十分な時間に誰もが問題にさらされるようにする必要があります。個人的には、ほとんどの場合、開発者が自分で発表するのではなく、セキュリティ情報で発表を行うことを許可します。少なくとも、この脆弱性が修正されたことを確認するまで待ちます。時間があり、ソースコードにアクセスできる場合は、パッチを提供することもできます。
個人的に私は 責任ある開示 が倫理的な観点から行く最善の方法であるように思われ、DNSキャッシュポイズニングの脆弱性の詳細を明らかにするDan Kaminskyにとってうまく機能しました。しかし、それはすべて、あなたが扱っている会社やグループ、そしてそれが影響を与えるユーザーベースにも大きく依存します。
@VirtuosiMediaは、「責任ある開示」の概要を示す素晴らしい仕事をします。
2つのポイントを追加します。
- （可能であれば）ベンダーと協力して、ベンダーが完全に理解し、中途半端なパッチを発行しないようにします。
- ベンダーがあなたを無視したり無視したりする場合は、試してください。ただし、脆弱性ではないと主張する場合は、先に進んで公開してください。できるだけ大声で。彼らが修正することを約束したが、そうしない場合は、彼らがコミットする明確なタイムラインとともに、彼らから回答を得るようにしてください。ある時点で、もし彼らが延期し続けるなら、結局あなたはとにかく出版するつもりであることを彼らに告げたいと思うかもしれません-そして彼らに実際にそれを修正する時間を与えてください（しかし、短く制限があります）。
これは複雑なトピックの1つです。私は数年前にTLS再ネゴシエーションバグの開示に関与していたので、「責任がある」ように懸命に努力しましたが、結局のところ、私たちは主に周囲の全員を怒らせ、（おそらく）遅らせることに成功しました修正の実際のリリース。ベンダーの通知は必ずしも悪いことではありません。ただ、口笛を吹いて巻き取られて、それと同じかそれ以上の害を及ぼすのは本当に簡単なことです。
私たちのケースでは、問題を解決するためにIETF（ RFC 5746 ）のアクションを実行し、リークした日にインターネットドラフトの準備ができていたとしても、実際に議論して決定する作業は解決策はさらに3か月かかり、開示が行われるまで本格的に開始されませんでした。
とにかく、これはあなたの質問への答えではありませんが、私が知っているより興味深い開示ストーリーの1つです。その話の詳細は 2010 ShmooConのキーノート 問題を発見したMarsh Rayとやりました。
一般的にはベンダーの対応に依存します。セキュリティ研究者が脆弱性についてベンダーに通知するときは、会話中にこの脆弱性のpoc/exploitの公開の条件について話します。実際、研究者はこの脆弱性をどうするかを選択します-後で公開するかどうか。次に、ベンダーはパッチまたは新しい製品バージョンをリリースします。多分。しかし、どのように経験が示すか-すべてのベンダーがそれほど素晴らしいわけではありません。エンドユーザーや研究者に通知せずにバグを黙って修正する人もいれば、研究者を無視することを好む人もいます。他の人も訴訟を起こそうとします。そのため、未知のベンダーとの最初のコミュニケーションでは、匿名性が望ましい場合があります。
また、Google、Mozillaが提供するバグ報奨金プログラムがあることも認めておきたいと思います。その上、他は脆弱性を購入します- [〜＃〜] zdi [〜＃〜] 、 iDefense 、 SNOsoft 、今後の「エクスプロイトハブ」、およびなど。したがって、ベンダーに通知する方法は少なくとも3つあります。直接、いくつかのリストに脆弱性情報を公開することによって、またはサードパーティ企業を介してです。
公開の問題追跡システムを使用している場合は、「プライベート」または「セキュリティ」のラベルを付けてバグを報告できるかどうかを確認します。
問題トラッカーがあるかどうかに関係なく、メールsecurity@companynameと知らせます。
彼らがかなり迅速に応答しない場合（以下のシュナイアーの記事の「開示のウィンドウ」を参照）、より広くそれを開示することを考える必要があります。セキュリティアカデミック/専門家が潜んでいるメーリングリストを探し、問題のベンダーにどのように問題を報告するかを尋ねます。彼らは組織の適切な場所を紹介できるかもしれません。
それでもうまくいかない場合は、シュナイアービットを読んで、完全な開示が問題の一部なのか、解決策の一部なのかを考えてください。
ブルース・シュナイアーは、「問題の一部ではなく、解決策の一部である」という基準に基づいて、特定の状況では 完全な開示 についての議論を示しています。それは間違いなく読む価値があります。
これは古典的な「バグの秘密と完全な開示」の議論です。これについては、Crypto-Gramで以前に書いたことがあります。他の人もそれについて書いています。これは複雑な問題であり、コンピュータのセキュリティ全体に微妙な影響を及ぼします。これは、もう一度議論する価値があります。
...
説明と概念実証コードの両方を含むこの無料の情報フローは、セキュリティ調査にも不可欠です。コンピュータセキュリティの研究開発は過去10年間で開花しており、その多くは完全開示運動に起因する可能性があります。調査結果を公開する機能（良い点と悪い点の両方）は、誰にとってもより良いセキュリティにつながります。公開がなければ、セキュリティコミュニティは互いの過ちから学ぶことはできません。誰もが目隠しをつけたまま操作し、同じ間違いを何度も繰り返す必要があります。コンピュータとネットワークのセキュリティを改善し続けるためには、完全な開示が不可欠です。
...
第二に、私はベンダーに事前に通知することを信じています。 CERTはこれを極端なものにし、ベンダーに問題を修正するために何年もかかることもありました。
...
「ソリューションの一部であり、問題の一部ではない」メトリックが好きです。セキュリティの研究はソリューションの一部です。ベンダーに問題を修正するよう説得することがソリューションの一部です。恐怖の種まきは問題の一部です。問題のあるティーンエイジャーに攻撃ツールを渡すことは問題の一部です。