サイト内の現在位置

脆弱性管理におけるCVEと修正パッチについて

NECセキュリティブログ

2022年9月20日

NECサイバーセキュリティ戦略統括部セキュリティ技術センターの平田・岡です。
今回のブログでは、脆弱性情報とその修正パッチについて、RedHat Enterprise Linux(RHEL)やWindowsを例に紹介し、脆弱性管理について改めて考えてみたいと思います。

1.脆弱性情報の収集について

脆弱性は日々発見されています。それらの脆弱性の多くは「CVE(Common Vulnerabilities and Exposures)」として管理され、一意に識別可能な番号(CVE-ID)として採番されています。CVE-IDが付与された脆弱性の詳細な情報は「NVD(National Vulnerability Database)」new window[1]で公開されており、利用されている方も多いかと思います。
一般的に脆弱性情報を収集する場合には、対象の環境で使用しているソフトウェアおよびバージョン(以後、“使用ソフトウェア”)に絞り込んで情報を収集するのが効率的です。
では、”使用ソフトウェア”が更に外部のソフトウェア(ライブラリや下位ソフトウェア、モジュール等のコンポーネント)を使用するケースはどうでしょうか。このケースにおいて、外部のソフトウェアに脆弱性がある場合、上流の“使用ソフトウェア”自体にもその脆弱性が影響することは考えられます。しかし、このようなケースにおいて外部のソフトウェアの構成まで全て特定し、更にその脆弱性情報まで集めることはなかなか難しいのではないかと思われます。

ではNVDでは 脆弱性のあるソフトウェアだけではなく、そのソフトウェアの使用により影響を受けてしまう上流のソフトウェア等が、全て整理され、公開されているでしょうか?この点について、公開されているソフトウェアもありますが、すべてが公開されているわけではありません。

脆弱性の影響は上流のソフトウェアに波及する可能性がある。また”使用ソフトウェア”Cのように使用されている“外部のソフトウェア”構成がわからない場合、そもそも脆弱性の検知が困難となる場合がある。

NVDでは影響を受けるソフトウェアを全て網羅しているわけではない

NVDで公開されている詳細情報にはいろいろな項目がありますが、影響を受けるソフトウェアである 「Known Affected Software Configurations」に注目してみます。 「Known Affected Software Configurations」には脆弱性の影響を受けるソフトウェア名などがCPE(Common Platform Enumeration)フォーマットで掲載されていますが、その説明new window[2]には「分析時に脆弱性があるとされたソフトウェアまたはその組み合わせ」とあり、ある時点での情報であることが分かります。
例えば、2021年12月に発見されたCVE-2021-44228(Log4Shell)new window[3]では、「“Java版MINECRAFT"が影響を受ける」new window[4]とニュースサイト等で取り上げられるなど、一時話題となりました。しかし、2022年9月現在、NVDで公開されているCVE-2021-44228の「Known Affected Software Configurations」にMINECRAFTは記載されていません。
上記のように、現状においてすべてのソフトウェアが整理・網羅されているわけではなく、またその時に分析対象とならなかったソフトウェアの中にも脆弱性の影響を受けるソフトウェアが存在する可能性もあることから、注意が必要となります。

なお余談ですが、上記のCVE-2021-44228の影響を受けるJava版MINCRAFT Ver.1.18についてNISTによって公開されているCPE Dictionarynew window[5] では以下のように登録されています(CPEは脆弱性情報が確認されたソフトウェア等に付与されるものである為、Java版MINECRAFT Ver.1.18の脆弱性情報は認知されているものの、同じNISTのNVDには未登録ということになります)。

ベンダー公開の脆弱性情報

では、より正確に影響するソフトウェアを確認する方法はあるでしょうか?
この点については、"使用ソフトウェア"を開発・販売するベンダーが公開している脆弱性情報を確認するのがもっとも適切な方法と思います。

それでは、ベンダーが公開している脆弱性情報として、RHEL(Red Hat Enterprise Linux)と Windowsを例に、それぞれの公開された脆弱性情報とその修正パッチ等の取り扱いを紹介します。

2.RHELの脆弱性情報と修正パッチの取り扱いについて

RHEL (Red Hat Enterprise Linux)の脆弱性情報は、 Red Hat カスタマーポータルnew window[6]から確認することができます。Red Hatカスタマーポータルでは、「Red Hat CVEデータベース」 と呼ばれるCVEごとに脆弱性情報を確認することができます。
他に「アドバイザリー」というRHELが提供する修正パッチごとの情報でも確認することができます。アドバイザリーの内、特にセキュリティに関するものは「RHSA(Red Hat Security Advisory)」と呼ばれており、修正されるパッケージやそのバージョンなどの情報が公開されています。

RHEL脆弱性情報の確認先

  • Red Hat CVEデータベース: CVEごとの脆弱性情報
  • アドバイザリー
  •  -
    RHSA(Red Hat Security Advisory): 修正パッチごとの情報
  •  -
    RHBA(Red Hat Bug Advisory)
  •  -
    RHEA(Red Hat Enhancement Advisory)

またこのRHSAは以下の特徴があります。

  • ひとつのパッチ情報に対して複数のCVEを含む場合がある。
     (その場合、特定のCVEだけに限定したパッチ適用はできない)
  • セキュリティ修正だけでなく、バグ修正、機能追加を含んでいることもある

ちなみに、アドバイザリーにはRHSA以外に、バグ修正と機能追加を対象とした「RHBA(Red Hat Bug Advisory)」、機能追加のみを対象とした「RHEA(Red Hat Enhancement Advisory)」があります。new window[7]

では実際に自身が管理するRHELを導入済みシステムにおいて、脆弱性対処がまだ行われていないRHSAを確認する方法を2点ご紹介いたします。

2-1. 「Red Hat カスタマーポータル」で確認

1点目はブラウザで「Red Hat カスタマーポータル」にアクセスし、サブスクリプション管理ページから未対処のアドバイザリーを確認する方法です。
サブスクリプション管理ページでは、登録されたシステムごとにインストール済のパッケージ情報を元に適用可能な(つまり未対処の)アドバイザリーを確認することができます。こちらの方法では、実際にRHELをインストールしたシステム以外の環境からでもリモートで対処状況を確認できるというメリットがあります。

2-2. RHELコマンドを使った確認

2点目はコマンドを使った未対処のアドバイザリー確認です。
例としてRHEL7, RHEL8の場合未対処のRHSAを表示するには以下のコマンドを実行します。

# yum updateinfo list sec

なお、RHBA、RHEAも含めて表示したい場合は、以下のコマンドを実行します。

# yum updateinfo list

なおこちらの方法でも事前にサブスクリプション登録が必要となります。有効なサブスクリプションが登録されていない場合、以下のようなメッセージが表示され確認することができません。

以上、紹介しました2つの方法に共通していますが、どちらもサブスクリプション登録およびインターネット接続等が前提となりますので、その点はご注意ください。

3.Windowsの脆弱性情報の取り扱いについて

Windowsの脆弱性情報はセキュリティ更新プログラムガイドnew window[8] で公開されており、CVEごとの脆弱性情報の詳細を確認することができます。

Windowsのセキュリティ更新プログラムを確認してみますと、「KB+数字の羅列(KB番号)」が表示されていることがあります。
このKB番号は、“Knowledge Base”と呼ばれるマイクロソフト社の公式のサポート技術情報を指したものです。RHELの脆弱性情報の取り扱いの際に紹介したRHSAなどのアドバイザリーに相当します。Windowsでは、修正パッチをKBの単位で公開していますが、こちらもRHSAと同じように複数の脆弱性を修正するパッチとなっており、一部の脆弱性に限定した対処はできません。

それでは、修正パッチはどのような方法で提供されているのでしょうか?

3-1. 累積パッチでの提供

現状、マイクロソフト社の修正パッチ(累積パッチ)は、一般的に毎月第二週の火曜日に配信されています。累積パッチでは、 その月に公開された脆弱性だけではなく、それ以前の過去の脆弱性の修正内容も含むものとなっています。
修正パッチは、Windows Updateを行うことで自動的に適用されます。修正パッチがPCに適用されているかどうかは、適宜確認することをおすすめします。

3-2. 個別の脆弱性パッチでの提供(終了予定)

前段で「一部のCVEに限定した対処はできない」と書きましたが、現在、その月に公開された脆弱性のみを対処する「セキュリティのみの更新プログラム」という修正パッチが存在します。
ただし、こちらは Windows10やWindows Sever2016以降のOSでは公開されていません。 (2022年9月現在では、Windows8.1やWindows Server 2012 R2向けの「セキュリティのみの更新プログラム」は公開されておりますが、どちらのOSも2023年内に延長サポート終了の予定となっています。) new window[9]new window[10]
また、累積パッチ適用では問題ないものの、個別の修正パッチの適用時には問題が発生するというケースnew window[11]も見られる為、運用では累積パッチでの適用を検討するのが良いかと思われます。

4.脆弱性情報の取り扱い

ここまでRHELとWindowsを例にCVEベースでの脆弱性情報の参照方法と、修正パッチの提供形態についてご紹介しましたが、ここからは脆弱性管理の観点で「脆弱性情報の取り扱い」について考えたいと思います。

4-1. CVE単位での脆弱性の取り扱い

まず脆弱性管理を「CVE単位(CVE毎に対処済みかどうか)」で行うことを考えてみます。
先ほどのRHELやWindowsのように、ベンダーから提供される修正パッチでは、ひとつの修正パッチに対して複数の脆弱性(CVE)が紐づくものが存在します。したがって、実際に適用した修正パッチと、対処済みとなるCVEの関係を正確に把握しなければ、正しく管理することが困難になります。 また正確な管理のためには調査などが煩雑になる可能性があります。
しかしながら、修正パッチの適用が困難な場合などに、どのような回避策・緩和策を実施したか?といったきめ細やかな管理がしやすいというメリットはあるかと思います。

4-2. 修正パッチ単位での脆弱性の取り扱い

一方、脆弱性管理を「修正パッチ単位(修正パッチ毎に適用済みかどうか)」で行うことを考えてみます。
この場合、修正パッチには複数の脆弱性の対処が含まれるため対応すべき件数が少なくなり、 また実際に適用したパッチのみの管理となるため、先ほどの「CVE単位」で 脆弱性管理を行うよりも利便性は高まるかと思います。

ベンダーが提供する脆弱性情報や修正パッチ、またはプロジェクトで行う脆弱性管理の要件等により、一概に「どちらがよい」とは言い切れない面がありますが、 どちらがより適切で、管理しやすいのか、を一度検討してもよいのではないかと思います。

まとめ

本ブログでは、脆弱性の影響を受けるソフトウェアを管理する時の考え方として、NVDやソフトウェアベンダーの公開する情報を活用することを述べました。そして、RHELとWindowsを例に、ソフトウェアのベンダーから発信されている脆弱性情報(CVE)と修正パッチについて紹介いたしました。 また脆弱性管理において、「CVE単位」および「修正パッチ単位」についての考察を行いました。
本ブログに考慮できていない点もあるかと思いますが、脆弱性管理について考えるきっかけとなれば幸いです。

参考:

執筆者プロフィール

平田 純(ひらた じゅん)
セキュリティ技術センター 脆弱性管理チーム

金融系SEからNECに転職し、現在はNECグループ向けの脆弱性管理業務に従事。
社内の製品・システムの脆弱性管理のため、構成管理情報の抽出やシステムへの入力支援を実施。

執筆者の他の記事を読む

執筆者プロフィール

岡 史晃(おか ふみあき)
セキュリティ技術センター 脆弱性管理チーム

グラフィックアクセラレータや画像処理開発業務、Androidフレームワーク/アプリケーション開発業務などを経て、
現在は、社内の脆弱性情報管理やその推進活動業務に従事。CISSP保持。

執筆者の他の記事を読む

アクセスランキング