完全な開示ポリシーに従って公開されたセキュリティの脆弱性を特定する実用的な方法はありますか？
特定の脆弱性がどのように開示されたかに応じて、特定のベンダーが修正/パッチを発行するのにかかる時間を判断するために、さまざまな脆弱性開示ポリシーについて調査を行っています。問題は、「完全に開示された」脆弱性を特定するのに苦労していることです（ベンダーは公開前に通知されていませんでした）。セキュリティ研究者がベンダーに通知せず、脆弱性を完全に開示すると、人々はそれに夢中になるという点で、責任ある開示が今日の標準のようです（これ ツイート およびそれに続くすべての記事）。私はどちらの方針も支持していないことに注意してください。私はできるだけ客観的に調査を行っています。
完全な開示ポリシーに従って公開されたすべての脆弱性を取得できるかどうか誰かが知っていますか？たぶん、そこにいる誰かがこの明らかに退屈な仕事をして、それを共有することをいとわないでしょう:)または、私が知らないウェブサイト/ツールがそれをしているだけです。
そうでない場合は、（もちろん、特定のベンダーの）各脆弱性エントリを調べ、開示のタイムライン（存在する場合）を分析し、パッチがいつ発行されたか、脆弱性の開示とパッチのリリースが判明したかどうかを確認する必要があると思います。同じ日に->責任ある開示を行い、パッチのリリースが後日である場合->完全な開示（または、ベンダーがCERTから45日の期限を過ぎた場合など）。時間がかかる？間違いなく。現実的ですか？おそらくそうではありません。しかし、あなたの意見では結果は正確でしょうか？
ありがとう！
ベースラインを作成するために使用できる方法の1つは、次のようなサイトにアクセスすることです PacketStorm 開示された最後の50の脆弱性/エクスプロイトを見つけて、CVEが発行されているかどうかを調べます マイター 。ベースラインは、まさにそれ、ベースライン平均を提供します。考慮すべきことがいくつかあります。
- すべてのエクスプロイト/脆弱性が常に研究者やベンダーによって開示されているわけではありません
- すべての脆弱性/エクスプロイトがCVEを持つことになるわけではありません
＃1に関しては、ベンダーがパッチを適用したものの、完全な開示、bugtraq、または他の同様のサイトに送信するために脆弱性の開示を書き始める必要がないと思われる脆弱性についてCVEを発行しました。これは通常、いくつかの理由で発生します1）忙しすぎて気になりません2）修正がないため、攻撃のレベルを上げる必要はありません（他の誰かが見つけた場合はそうです）3）ベンダーは厳しい可能性があります'対処する。私はかつてネットワーク機器メーカーに脆弱性を報告しましたが、修正するのに2年かかりました。これは、私が物事を説明したり、再テストしたりするための自由な時間を与えてくれた数週間で構成されていました。
他のコメントについて：「当日パッチ」は存在しません。一日でパッチを出すことをいとわない会社は、無謀にそうするでしょう。プログラマーは、レガシーアプリケーションが引き続き機能し、パッチ/更新/修正で問題が発生しないことを確認する必要があります。これは時間のかかるプロセスであり、アプリケーション開発会社には、厳格なテスト/修正に準拠したプロセスとポリシーがあります。 「45日」の開示に関しては、これは確固たるものではありません。
Q：すべての脆弱性は45日以内に開示されますか？A：いいえ。公開スケジュールを調整する状況がしばしば発生する可能性があります。特に深刻な脅威や悪用の証拠がある脅威は、リリーススケジュールを短縮する可能性があります。 「ハード」な変更（標準の変更、コアオペレーティングシステムコンポーネントの変更）を必要とする脅威により、公開スケジュールが延長されます。報告されたすべての脆弱性を公開するとは限りません。 http://www.cert.org/vulnerability-analysis/vul-disclosure.cfm？
あなたの研究で頑張ってください、せいぜい私はあなたがベースラインを取得しているのを見ることができます。変数が多すぎるため、出力が汚染される可能性があります。例：Microsoft、Cisco、およびその他の有名ベンダーは、「優れた」または「魅力のない」ターゲットになっている可能性がありますが、それらを何と比較していますか？ myjoomlasoftware.v1、またはmyhomebackedGitHubProject2.0？オープンソース、クローズドソース、大規模ベンダー、小規模ベンダー、petprojects、githhub？これらは考慮すべき事項であり、どちらもデータを大幅に歪める可能性があります。
正直なところ、それは本当に会社次第です。企業ごとに脆弱性の扱い方が異なり、プロセスに従う一部の研究者でさえ、このように失敗します Instagramにバグを提出した男 。
バグバウンティプログラムを通じて参加した人（もしあれば）は、通常、自分のサイトで情報を公開するか、プログラムに登録している一連のユーザーに電子メールで送信します。そうでなければ、この情報を入手するために多くの企業を厳密にフォローする必要があります。
チームにメールを送信して、必要な情報のレベルに応じて、研究者としてリストが提供されるかどうかを確認することもできます。一部のチームは、それが彼らの文化にある場合にそうしますが、多くのチームはこれをソーシャルエンジニアリングと見なします。 、およびあなたの要求を拒否する場合があります。
BugCrowd も見ていきます。これは、バグ報奨金プログラムを提供している企業のリストと、適切なページへの直接リンクを提供します。
誰かがこの仕事をしたことがあれば、それは素晴らしいことですが、幸運を考えるにはたくさんの情報があります！