脆弱性の「管理単位」を
CVE ID ベースで行うと不合理な点とは？
脆弱性の管理
2020.2.23
脆弱性対策を行う「管理単位」を CVE ID ベースで行うと、その作業量は非常に多くなるという話をします。一方、SIDfm 脆弱性データベースを使うと、ソフトウェアベンダーが提供する「パッチ」に基づいた情報が「管理単位」となるため、結果的に現場SEの対策のための工数が大幅に縮減されます。
CVE ID ベースで管理する際の問題点
多くの組織では、脆弱性情報や脆弱性の対策の「管理単位」を CVE ID をベースに行っています。これは、 情報セキュリティにおける脆弱性やインシデントを認識するための公知の情報が、CVE (Common Vulnerabilities and Exposures) で発表されていることに拠るものです。また、特定の脆弱性情報を参照しようとした場合でも、CVE ベースの脆弱性情報を蓄積しデータベース化している NVD や日本の JVN iPedia から CVE ID ベースで引用する手段しかないのが現状です。
今まで、脆弱性の「情報」を管理することに主眼が置かれていたことは否定できません。これは、ニュース等で話題になった脆弱性、あるいは CVSS の高い脆弱性の「CVE情報」を拠り所にして「ピンポイント」でその対策の管理を行って良しとした背景があります。対策を行うための組織基準はあるにしても、ある程度フィルタを掛けることで対策対象が絞られ、特定の CVE 脆弱性「情報」があれば管理できたという考え方です。しかし、ピンポイント対策ではなく、対策基準となるしきい値を設定するようなことになると、CVE ID ベースの脆弱性対策の対象範囲が一気に増加します。これは、組織にどういった問題を引き起こすのでしょうか？
組織は、脆弱性の「情報」を管理することではなく、
その「対策」を管理するもの
対策作業を行うのは、「セキュリティ運用管理者」ではなく「現場SE」となります。CVE ID の情報からどのベンダーソフトウェア(OS名、distriobution 名、ミドルウェア名等）が対象となるか、その対象となるシステムを特定し、その CVE に対応するベンダー・パッチ情報を探すといった一連の重作業が待ち構えています。脆弱性対策の対象範囲が広がり対応する CVE ID が増加すると、そのパッチを探すだけでも大きな負担となり、真剣に対策を施す組織ほど、「現場SE」の疲弊が始まります。そんなに CVE の数が多いのか？とお疑いの方もいるかと思いますが、 2019 年の 1 年間に NVD に登録された CVE の数は 19,000 件もあり、非常に多いことがお分かりかと思います。
対策を行う対象は、組織のITシステムとなります。システムの位置づけや重要度に応じて対策作業レベルは異なりますが、現在は、セキュリティ脅威に対する予防的意味合い（セキュリティ・ハイジーンという衛生管理面）を重視する傾向があり、対象となる脆弱性に対して、ほとんどのシステムにパッチを適用する作業が必要となってきております。このような状況下では、「現場SE」がベンダーパッチを特定し、効率的に作業ができる情報提供環境を提供する必要があります。とは言え、かなりの数に上る CVE ID ベースで対策作業を行うことは無理があると言えましょう。脆弱性対策のための管理システム設計を行う際には、PDCAサイクルが破綻しないように注意が必要です。その管理の根源となる「情報データベース」の組成がその後の対策作業に大きく影響することは、皆さんが知っているようで知らない事実なのです。以下で述べる SIDfm 方式と較べてみてください。
SIDfm 方式で管理する場合の優位性とは
SIDfm の脆弱性データベースや管理ツールを使用すると、「現場SE」のこうした負担をなくします。SIDfm の脆弱性データは、各ソフトウェアベンダーの正式なセキュリティ・アドバザリ情報（＝パッチ情報）を「一単位」として作成されています。一般にこうしたパッチは、複数の CVE を纏めて修正する形となっております。脆弱性管理もこの単位で行い、CVE ID 単位ではありません。SIDfm RA や VM といった管理ツール製品では、この単位で「脆弱性チケット」が作成されます。従って、CVE ID ベースの管理アプローチである、修正すべき CVE が含まれている「パッチ」を探すという非合理的な作業は SIDfm では必要ありません。SIDfm は「脆弱性チケット」内から参照できる情報として「パッチ情報」がタイアップされており、チケット内から直接、パッチを参照できます。SIDfm ベースで発行される「チケット」には、当該対象となる CVE ID やパッチの在り処情報、脆弱性の評価指標などが全て纏められて閲覧できるようになっています。
以下の例を見て下さい。SIDfm の脆弱性情報単位（1チケット）の表示例です。一つのベンダーアドバイザリ（パッチ情報）が、32 個の CVE を修正するものとして提供され、その中で、最大の CVSS 値は 9.8 のものが含まれています。これら 32 個の脆弱性を修正するものとして、表示されているパッチファイルを適用するといったような情報の見え方となります。もし、一つひとつの CVE ID で管理しているならば、当該 32個の CVE 管理チケットを発行し、それぞれのパッチの在り処を調査し、多数のチケット管理を行う必要があります。これは大幅な時間を費やすことになります。
この違いにより、SIDfm の脆弱性の管理単位は、以下のようなアドバンテージがあります。
SIDfm のアドバンテージ
- SIDfm の脆弱性データは、ソフトウェアベンダーのセキュリティ・アドバザリ情報（＝パッチ情報）を「一単位」として組成されています。これは、CVE ID ベースで管理される環境に較べ、「対策作業に掛かる手間」を大幅に削減する効果があります。
- こうしたアプローチでデータを蓄積して包括的なサービスを提供している「脆弱性データベース」は、SIDfm だけとなります。
- 現在、市場に存在する他社の脆弱性管理システムは、脆弱性スキャナーによって脆弱性を検出するアプローチを取っています。このようなシステムは、自身の「脆弱性データベース」を持たないため、全て CVE ID ベースで検出されます。当然、管理チケットも当該 CVE ID ベースとなります。従って、上記で述べた CVE ID ベースで管理する際の問題点に直面することになります。
序文が長くなりましたが、以下では個別の CVE ID で管理を行う際の問題について具体的に説明します。
製品ベンダから提供される更新プログラムやパッチは、基本的に複数の CVE に対応している
製品ベンダは、脆弱性に対してパッチを提供していますが、CVE ID 毎にパッチや更新プログラムが提供されることはほとんどなく、複数の CVE をまとめて修正する形でパッチや更新プログラムを提供しています。
このことから CVE ID 毎に脆弱性の管理を行う場合、次のようなプロセスになると考えます。
- CVE ID の把握
- 使用しているソフトウェア製品に対する影響の確認
- 対処方法の検討
- 3.1 パッチ・更新プログラムの適用検討
- 3.2 パッチ・更新プログラムによって同時に修正される CVE の調査 (CVE による脆弱性の管理を行う以上、対処した脆弱性は把握しないとならない)
- パッチ・更新プログラムの適用
CVE を元にした管理の場合、(3.1) と (3.2) の作業に無駄が多いのではないかと考えます。
本当に、このような現場作業を繰り返しますか？
同じ CVE ID の CVSS スコアでも製品によって評価が違うことがある
CVE ID の危険性の評価として CVSS が標準的に利用されていますが、危険性の評価は画一的なものではないため、製品ベンダによっては自社の製品に対する CVSS 評価を独自に行っていることがあります。
例: CVE-2018-8014 Tomcat の CORS フィルタの脆弱性
| 製品ベンダ (製品) | CVSS |
|---|---|
| NVD (汎用) | 9.8 |
| Red Hat (RHEL) | 5.7 |
| Oracle (Solaris) | 4.3 |
このように製品によって、CVSS スコアによる危険性評価が違うこともあるため、CVE を元に脆弱性の管理を行っていくのは、危険性を評価していく上でも不合理であるように考えます。こうした例は、他にも数多く存在します。
CVE の数は非常に多い
CVE は、非常に多く登録されます。
SIDfm に登録されている 2019 年の CVE だけでも 4,543 件あります。これを CVE ごとにハンドリングしていくのは既に現実的ではないのではないかと考えます。(平日のみの稼働で考えると 18件/日処理する必要があります)
CVE による脆弱性の管理は、ゼロデイの脆弱性など特定の危険性の高い脆弱性には有効な部分もありますが、実際のデイリーワークとしての脆弱性管理にはあまり有効ではないと考えます。
CVE が割り当てられない脆弱性がある
脆弱性情報が公開された際に CVE が割り当てられないことがあります。2020年2月における脆弱性に対して CVE の割り当てが行われなかった代表的な製品は、次のとおりです。
WordPress
https://wordpress.org/news/2019/12/wordpress-5-3-1-security-and-maintenance-release/
脆弱性情報の公開時には CVE が割り当てられないことが多いです。
Node.js
https://nodejs.org/en/blog/vulnerability/december-2019-security-releases/
現在も割り当てられていないように見えます。そのうち割り当てられると思います。
Varnish
https://varnish-cache.org/security/VSV00005.html
https://varnish-cache.org/security/VSV00004.html
最近公開された脆弱性に CVE が割り当てられていません。
CVE を元に脆弱性をハンドリングした場合、こういった情報は存在しないこととなります。
脆弱性への対応をタイムリーに行うことができない
CVE の脆弱性情報は影響製品 (CPE) や CVSS スコアの登録まで時間がかかることがあります。
これは CVSS スコアを脆弱性の危険度判定に使用している場合に、脆弱性への対処をタイムリーに実施することができないという大きな隙を生み出します。
検出された CVE の脆弱性情報に対して、機械的に CVSS スコアを用いて対処の優先度や期日を決めている場合、CVSS スコアが登録されるまでその脆弱性は無いものと扱うしかありません。 危険度の高い脆弱性についてのこの遅れが発生したとすると、脆弱性情報が既にあるにもかかわらず、判定基準となる CVSS スコアが無いため、対処を決めそこねる可能性があります。 必要なタイミングで危険度の高い脆弱性であることを評価できなければ、脆弱性を管理する上では危険度評価としての意味がありません。
CVE の脆弱性情報につけられた CVSS スコアは、タイムリーな脆弱性の危険度評価という意味において判定基準としての役割を果たしません。
一方、SIDfm VM、RA 製品の SRI 指標を使用することにより、こうした問題を回避できます。
SIDfm の脆弱性情報には、その脆弱性コンテンツの登録時に、独自の危険度の評価値である SRI（SIDfm Risk Impact）指標も同時に登録されます。SIDfm脆弱性情報を使用する SIDfm VM 等の脆弱性チケットでは、それが発行された時点で、脆弱性の危険度が特定されます。SRI 指標については、CVSS 評価値との比較を含めて、以下のブログでも説明しています。
三菱電機㈱への不正アクセス事件から見る、SIDfm SRI 指標の有用性
脆弱性からの組織防衛のために
あなたの組織で脆弱性が対策されていることを確認できますか？ 弊社の継続的脆弱性管理ツール SIDfm VM は、管理対象のホストで使用するソフトウェアで新しく報告された脆弱性のピックアップを行い、影響判定や対策工程の把握まで、脆弱性管理をトータルでカバーいたします。
脆弱性の調査やパッチ探しは一切不要！
脆弱性対策を自動化できるので工数大幅削減！
さらに自社の脆弱性状況を全て可視化できるので
管理がグッと楽になる！
それらを全て実現するサービスがあります。
脆弱性管理ツール「SIDfm VM」について詳しくはこちらから