リスクベースのパッチ管理を導入することで、アクティブなエクスプロイトに優先順位付けする方法
Todd Schell
特に実行中であり効率的で有効と考えている処理についての変更には、常に抵抗があります。 セキュリティの違反もしくは事故が発生し、何が間違っていたかについて疑問に思うまでは、多くの組織がそのソフトウェア管理手順についてこう思います。
現実には、ほとんどのパッチ管理プログラムが、活発にエクスポロイとされている脆弱性についての事実ではなく、推定と推奨に基づいていると言う事です。 リスクベースのパッチ管理 がこの問題に対する答えです。
この記事でご覧下さい、
典型的な優先順位付けに従う事にどんな問題があるのか
ソフトウェア産業が始まって以来、ソフトウェア特性の更新、セキュリティー修正、バグ修正、パフォーマンスの向上、および多くのその他のタイプのソフトウェアリリースがありました。 ベンダーはしばしば、それぞれに強度評価やその他のスコアを付けて、顧客に何が重要と考えられているかを伝えます。
残念ながら、これ等の評価には紐づけられた業界の水準が無く、我々は推奨に基づいてシステムでの展開についてリリースされたものを比較し優先順位を付けなければならないのです。 この上に、その様な評価は脆弱性が変化してもアクティブな脅威の環境に対応するために更新される事が先ず無いのです。
悪用される脆弱性の見落とし
全く何も無いよりはましであっても、ベンダーの強度評価は余り良いものでもありません。 Follina脆弱性(CVE-2022-30190) 2022年5月公表について考えて下さい。 このMicrosoft Windows Support Diagnostic Tool (MSDT)の脆弱性は、リモートコード実行を許容します。
マイクロソフトが最終的に幾つかの更新により対応するまでに、Follinaは数か月間攻撃を受けました。 驚いた事に、マイクロソフトはこの脆弱性には通常の脆弱性スコアシステム（CVSS）v3にて7.8の評価と重大性を付けました。 最大深刻度に基づいてパッチをするのみの場合は、 あなたはこれを落とす事により重大な隙間を残してしまいます。
さらに悪い事に、FollinaのCVSSスコアは脆弱性が7.8のままとなり、活発にエクスポロイとされBisamwareランサムウェアの配布用に積極的に悪用され、これを見落とした組織をこれ以上のリスクに露呈するのです.。
CVSSの短所
深刻度評価は、FIRSTのCVSSスコアで「補強」されます。各CVEにはCVSS番号が割り当てられており、上の例ではCVE-2022-30190に7.8が与えられています。
実際のCVSS番号を算出する主な目的の1つは、すべてのCVEが一貫してスコア付けされ、正確に比較できるように標準化を確実にすることです。脆弱性と関連するパッチのCVSSスコアが高ければ高いほど、ほとんどの環境において、そのパッチはよりクリティカルであることを意味します。
複数のCVEに対応するソフトウェアアップデートの場合、通常は最も高いCVSS値が優先順位付けのために考慮されます。 しかしながら、この値は正確でしょうか？
最近の記事でCVSSスコアの分析の結果が発表され、CVSSスコアの20%近く(25,000)に不一致があった事が示されました。 この分析はNIST National Vulnerability Database（NVD）に報告されたスコアとベンダーが直接報告したスコアの比較に基づいています。
ベンダーの脅威度についての不一致
留意すべき重要な点の1つは、ベンダーが従来より脅威度について独自の用語を割り当てている事です（例えば、クリティカル、重要）。ベンダーの重大度スコアリングを優先順位のメカニズムとして使用することは、あるベンダーのすべてのパッチを比較する場合にはうまくいくかもしれませんが、ベンダー間のパッチを必ずしも正確に比較できるわけではありません。実際、多くのベンダーはまったく異なる用語を使用しています。
同様に、ベンダーの脅威度は必ずしも肯定的な指標とはならないのです。 ゼロデイ脆弱性の多くは、マイクロソフトによって「重要（Important）」としか評価されていませんが、これには高いCVSSの数値が付いています。重要度やCVSSを優先順位付けに使用したパッチ適用が、いかに仮定や推奨を使用しており、脆弱な環境をもたらす可能性があることが分かります。
何故その他の優先順位方法を取らずに、アクティブなエクスプロイトを優先するのでしょうか？
米国のCybersecurity and Infrastructure Security Agency (CISA)によると、積極的に悪用される脆弱性 は、「システム所有者の許可なく、システム上でアクターによって悪意のあるコードの実行が行われたという信頼できる証拠があるもの」を指します。平たく言えば、積極的に悪用されている脆弱性とは、脅威アクターがサイバー攻撃を仕掛けるために利用した脆弱性です。
したがって、組織への攻撃のリスクを最小限化する為に、その他の全てよりアクティブにエクスポロイトされている脆弱性を優先すべきなのです。 ほとんどの脆弱性はアクティブにエクスプロイトされておらず、組織へのリスクも小さいので良い知らせです。 リスクベースのパッチ管理を通じてエクスプロイトされたものは識別可能です。
リスクベースのパッチ管理とは
によると、リスクベースのパッチ管理におけるガイドブック:
「リスクベースのパッチ管理は、ベンダーの脅威度と組織に対する最も重要なリスクとなる特定の脆弱性を識別し判別する為の基本のCVSSスコアに勝ります。
このリスクベースの脆弱性管理の拡張により、組織のセキュリティ態勢にとって最も重要である悪用された既知の脆弱性の更新を取り入れることで、現実のリスク状況をパッチマネジメントプロセスに反映させることができます。
組織はどの様にリスクベースのパッチ管理を取り入れる事が出来るのでしょうか？
パッチ管理についてリスクベースのアプローチを採用可能な組織については、CISA から始めると良いでしょう、既知のエクスポロイトされた脆弱性 (KEV) カタログ。 CISAは脆弱性と優先順位付けについて手助けをする為に大きな一歩を踏み出しました、拘束力のある運用指令22–01 、と共にKEV カタログであり、先ず発行された時に、カタログには約200のアクティブにエクスプロイトされた脆弱性があります。 以降これは約900に増えました。
CISAは、含まれた脆弱性がアクティブな脅威にエクスプロイトされている知識を持ち、リストを作成しています。しかし、リストには短所も有り現在はランサムウェアに関連した131の脆弱性が除外されています。
CISA KEVカタログのみがリスクベースのパッチ管理用のリソースでしょうか？
より熟成したリスクベースのパッチ管理方法を持つ組織は、この代わりにあるいは、CVSSに追加した高度なリスク評価方法でレバレッジしています。 これ等の方法は組織環境で識別された全ての脆弱性についてスコアを与え、これ等の組織のCISA KEVを超えるリスクベースへの拡張を許容します。
リスクベースの脆弱性管理領域の多くのベンダーは、脆弱性がもたらす本当のリスクを表す独自の採点方法を開発しました。 ベンダーは、積極的にエクスプロイトされたリスクに重みを付ける事により、動的なリスク評価を出します。
例えば、Ivantiの脆弱性リスク評価 (VRR) 、はFollinaに7.8のCVSSスコアよりも脆弱性のリスクを表す10のスコアを付けています。
リスクベースのパッチ管理を採用する最適な時である理由
システム更新が遅れたり、御社の新しいシステムやアプリケーションに圧倒されたと感じたら、リスクベースのパッチ管理. を採用する丁度良いタイミングです。
脅威度のレーティングやCVSSスコアに基づいた実質的なプログラムを持ち、変化への抵抗を捨ててて事業がエクスプロイトされた脆弱性. からのデータ侵害により途方に暮れる前に、新しいプロセスを開始して下さい。
CISA KEVを使用して更新と 、割り当て、予算、リスクと脆弱性のパッチ管理ソリューションを優先して下さい。 適切なツールの使用で、迅速で最も高度なリスクシステムを識別し、パッチを行い、システムをセキュアな状態するためにリストに従って下さい。
最初の一歩を踏み出そうとしていますか？ リスクベースのパッチ管理におけるガイドブックをご覧ください。
