パッチの狂気: ベンダー バグ アドバイザリが破られたため、PlatoBlockchain データ インテリジェンスが壊れました。 垂直検索。 あい。

パッチの狂気: ベンダー バグ アドバイザリは壊れている、壊れている

BLACK HAT USA – ラスベガス – セキュリティ脆弱性のパッチ適用に遅れずについていくことは、せいぜい困難ですが、どのバグに焦点を当てるかの優先順位付けは、コンテキストが不足している CVSS スコア、曖昧なベンダー アドバイザリ、および不完全な修正のおかげで、これまで以上に困難になっています。管理者に誤った安心感を与える。

これは、トレンド マイクロのゼロデイ イニシアチブ (ZDI) のブライアン ゴレンクとダスティン チャイルズが、セッション中にブラック ハット USA のステージから行った議論です。あいまいな時代のリスク計算: セキュリティ アドバイザリの行間を読むに設立された地域オフィスに加えて、さらにローカルカスタマーサポートを提供できるようになります。」

ZDI は 10,000 年以来、業界全体で 2005 件を超える脆弱性をベンダーに開示してきました。その間、ZDI のコミュニケーション マネージャーであるチャイルズ氏は、パッチの品質が低下し、セキュリティ アップデートに関連するコミュニケーションが減少しているという不穏な傾向に気付いたと述べています。

「本当の問題は、ベンダーが欠陥のあるパッチをリリースしたり、それらのパッチに関する不正確で不完全な情報をリリースしたりすると、企業がリスクを誤って計算する可能性がある場合に発生します」と彼は指摘しました。 「『n-days』はゼロデイズよりもはるかに使いやすいため、不完全なパッチはライターを悪用するための恩恵にもなります。」

CVSS スコアとパッチ適用の優先度に関する問題

ほとんどのサイバーセキュリティ チームは人手不足でプレッシャーにさらされており、「すべてのソフトウェア バージョンを常に最新の状態に保つ」というマントラは、ウォーターフロントをカバーするリソースを単に持っていない部門にとって常に意味があるとは限りません。 そのため、Common Vulnerability Severity Scale (CVSS) での重大度評価に従って適用するパッチに優先順位を付けることが、多くの管理者にとってフォールバックになっています。

ただし、Childs 氏は、このアプローチには深刻な欠陥があり、悪用される可能性が低いバグにリソースが費やされる可能性があると述べています。 これは、CVSS スコアが提供しない重要な情報が多数あるためです。

「多くの企業は、パッチ適用の優先度を決定するために CVSS ベース コア以外に目を向けません」と彼は言いました。 「しかし、CVSS は実際には悪用可能性や、脆弱性が実際に使用される可能性があるかどうかを調べていません。 CVSS は、バグが 15 のシステムに存在するのか、15 万のシステムに存在するのかを教えてくれません。 また、公開されているサーバーにあるかどうかについても言及されていません。」

「そして最も重要なことは、特定の企業にとって重要なシステムにバグが存在するかどうかを示していないことです。」

したがって、バグが CVSS スケールで 10 点満点中 10 点の重要度を持っている場合でも、その実際の影響は重要度ラベルが示すよりもはるかに重要ではない可能性があります。

「Microsoft Exchange のような電子メール サーバーの認証されていないリモート コード実行 (RCE) バグは、エクスプロイト作成者から多くの関心を集めるでしょう」と彼は言いました。 「Squirrel Mail のような電子メール サーバーの認証されていない RCE バグは、おそらくそれほど注目を集めることはないでしょう。」

コンテキスト上のギャップを埋めるために、セキュリティ チームはベンダー アドバイザリに頼ることがよくありますが、チャイルズ氏によると、これには明らかな問題があります。

Microsoft Patch Tuesday アドバイザリには詳細がありません

2021年、マイクロソフトは決定を下しました エグゼクティブサマリーを削除するには
代わりに、セキュリティ更新ガイドから、優先順位付けには CVSS スコアで十分であることをユーザーに通知します。これは Childs が爆破した変更です。

「この変更により、リスクを判断するために必要なコンテキストが削除されます」と彼は言いました。 「たとえば、情報漏えいバグはランダム メモリまたは PII をダンプしますか? または、セキュリティ機能のバイパスの場合、何がバイパスされているのでしょうか? 変更に対するほぼ普遍的な批判にもかかわらず、これらの記事の情報には一貫性がなく、質もさまざまです。」

マイクロソフトが「以前は明確なガイダンスを作成していた更新プログラムの情報を削除または不明瞭にする」ことに加えて、毎月パッチが適用されるバグの数など、基本的なパッチ チューズデー情報を判断することも難しくなっています。

「今、あなたは自分自身を数えなければなりません、そしてそれは実際に私がする最も難しいことのXNUMXつです」とChildsは指摘しました.

また、アクティブな攻撃を受けている、または公に知られている脆弱性の数に関する情報は引き続き入手できますが、現在は速報に埋もれています。

「例として、 今月は 121 件の CVE にパッチが適用されます、それらすべてを掘り下げて、どれがアクティブな攻撃を受けているかを見つけるのはちょっと難しいです」とチャイルズは言いました. 「代わりに、人々は現在、リスクを判断するのに役立つベンダーからの信頼できる情報ではなく、ブログやプレス記事などの他の情報源に依存しています。」

注目すべきは、マイクロソフト 変更を倍増しました. Black Hat USA の Dark Reading との会話の中で、Microsoft のセキュリティ レスポンス センターのコーポレート バイス プレジデントである Aanchal Gupta 氏は、ユーザーを保護するために、最初に CVE で提供する情報を意識的に制限することにしたと述べました。 Microsoft の CVE は、バグの深刻度と悪用される可能性 (および実際に悪用されているかどうか) に関する情報を提供しますが、同社は脆弱性悪用情報をどのように公開するかについて慎重になると彼女は言いました。

目標は、セキュリティ管理者を危険にさらすことなく、パッチを適用するのに十分な時間を与えることだと Gupta 氏は述べています。 「私たちの CVE で、脆弱性が悪用される方法のすべての詳細を提供した場合、私たちは顧客をゼロデイ攻撃することになります」と彼女は言いました。

他のベンダーはあいまいさを実践しています

バグ開示で詳細をほとんど提供していないのは Microsoft だけではありません。 Childs 氏によると、多くのベンダーはアップデートをリリースする際に CVE をまったく提供していません。

「彼らは、アップデートがいくつかのセキュリティ問題を修正すると言っているだけです」と彼は説明した. "幾つか? 重症度は? 悪用可能性は何ですか? 最近、ベンダーから具体的に言われたことがあります。 それは大胆な行動です。」

さらに、一部のベンダーは、推奨事項をペイウォールやサポート契約の背後に置き、リスクをさらに曖昧にしています。 または、CVE は単一の固有の脆弱性を表すという一般的な認識にもかかわらず、複数のバグ レポートを単一の CVE に結合します。

「これは、リスク計算を歪めることにつながる可能性があります」と彼は言いました。 「たとえば、製品の購入を検討していて、一定期間内に 10 個の CVE にパッチが適用されていることがわかった場合、この新製品のリスクについて 10 つの結論を導き出すことができます。 ただし、これらの 100 個の CVE が XNUMX 件以上のバグ レポートに基づいていることがわかっている場合は、別の結論に達する可能性があります。」

プラセボ パッチ ペストの優先順位付け

開示の問題以外にも、セキュリティ チームはパッチ自体の問題にも直面しています。 チャイルズ氏によると、実際には効果的なコード変更を行わない「修正」である「プラシーボ パッチ」は珍しくありません。

「つまり、そのバグはまだ存在しており、脅威アクターに悪用される可能性があります。ただし、彼らはそれについて知らされています」と彼は言いました。 「これが起こる理由はたくさんありますが、 しかし、それは起こります – バグがとてもいいので、XNUMX 回パッチを当てます。」

不完全なパッチもよくあります。 実際、ZDI プログラムでは、研究者が分析するバグの 10% から 20% が、不完全または不完全なパッチの直接の結果です。

Childs は、Adobe Reader の整数オーバーフローの問題を例に挙げ、ヒープ割り当てのサイズ不足につながり、大量のデータが書き込まれるとバッファー オーバーフローが発生します。

「私たちは、アドビが特定のポイントを超える値を悪いものとして設定することで修正を行うことを期待していました. 「しかし、それは私たちが見たものではなく、ロールアウトから 60 分以内にパッチのバイパスが発生し、再度パッチを適用する必要がありました。 再放送はテレビ番組だけのものではありません。」

パッチの優先順位付けの問題に対処する方法

最終的に、パッチの優先順位付けに関しては、効果的なパッチ管理とリスク計算は、組織内の価値の高いソフトウェア ターゲットを特定し、サード パーティのソースを使用して特定の環境にとって最も重要なパッチを絞り込むことに要約されます。研究者は指摘した。

ただし、情報開示後の機敏性の問題は、組織が注目すべきもう XNUMX つの重要な領域です。

ZDI のシニア ディレクタである Gorenc 氏によると、サイバー犯罪者は、企業がパッチを適用する前に、新たに公開された欠陥を兵器化しようとして、大規模な攻撃対象領域を持つ脆弱性をランサムウェア ツール セットまたはエクスプロイト キットに統合することに時間を費やしています。 これらのいわゆる n-day バグは、平均してわずか 48 時間でバグをリバース エンジニアリングできる攻撃者にとって厄介な存在です。

「ほとんどの場合、攻撃コミュニティは公開パッチが利用可能なn-day脆弱性を使用しています」とGorenc氏は述べています。 「バグが実際に兵器化されるかどうかを開示時に理解することは重要ですが、ほとんどのベンダーは悪用可能性に関する情報を提供していません。」

したがって、企業のリスク評価は、開示後に変更できるほど動的である必要があり、セキュリティ チームは脅威インテリジェンス ソースを監視して、バグがいつエクスプロイト キットまたはランサムウェアに組み込まれたか、またはエクスプロイトがオンラインでリリースされたかを理解する必要があります。

それに付随して、企業が考慮すべき重要なタイムラインは、実際に組織全体にパッチを展開するのにかかる時間と、必要に応じて提供できる緊急リソースがあるかどうかです。

「脅威の状況に変化が生じた場合 (パッチのリビジョン、概念実証の公開、エクスプロイトのリリース)、企業は必要に応じてリソースをシフトし、最新のリスクに対処する必要があります」と Gorenc 氏は説明します。 「最近公開され、名前が付けられた脆弱性だけではありません。 脅威の状況で何が起こっているかを観察し、リソースを方向付け、いつ行動するかを決定してください。」

タイムスタンプ:

より多くの 暗い読書