2025年4月18日

NECサイバーセキュリティ技術統括部 セキュリティ技術センターの山本です。
本ブログでは、セキュリティの運用・保守の業務において日々実施する必要のある脆弱性管理の中でも、特にパッチの適用というフェーズについて、業務改善に関係する指標の情報を取り上げます。

目次

はじめに

ソフトウェアを用いた製品・サービスにおける脆弱性に対して、脆弱性を把握し対処を行う一連の業務は「脆弱性管理」などと呼ばれます。以前のNEC セキュリティブログ「簡単！Excelからはじめる脆弱性管理　～トリアージ～」[1]の中でも、収集した脆弱性情報やそれぞれの脆弱性情報に対する対処状況をエクセルに記載し、優先度を付けて対応していく方法を紹介しました。

一般に業務活動、特に繰り返し実施される業務を改善していくためには、対象とする業務活動から計測される指標の管理が重要です。脆弱性管理に関しても同じで、NIST SP800-40 Rev.4[2] 「3.6 Choose Actionable Enterprise-Level Patching Metrics」の中でも、継続的な改善のために有用な指標を特定することや、指標の測定値を頻繁にかつできる限り正確にモニタリングしていくことの重要性が述べられています。

より効果的な脆弱性管理を行っていくように改善するための指標の種類については、大きく分けて以下の2種類があります。

1.については、前回のブログ[1]の中でも、CVSSやSSVC、EPSSなど、いくつかの情報を共有しました。脆弱性情報とは異なりますが対象とする資産の重要性などもこちらに該当します。今回のブログでは、2.について共有します。

改善のための指標活用

繰り返し実施する業務活動において、対応品質の向上やコスト削減などのためには、適宜プロセスを見直して改善していくことが必要です。しかしながら、改善したいことに適切にフォーカスできていないと、あまり改善には繋がらなかったり、意図した改善が行えなかったりすることがあります。

改善のためのフレームワークとしては、PDCAサイクルやOODAループ[3]など、複数のフレームワークが多くの業務改善において活用されています。それぞれのフレームワークでは、フェーズの順番や表現は異なりますが、共通的に含まれている要素としては、PDCAではC(Check)、OODAではO(Observe)、つまり状況を確認・観察した上で、後々のA(Act)として次の行動が取られるという点になります。A(Act)が最初に来るフレームワークも存在しますが、最終的にはループの中で確認・観察・検査の要素が必ず含まれます。

脆弱性管理は日々繰り返し行われるものですから、脆弱性管理に関係のある指標に注目し、一連の業務の中にそれらの値をCheck/Observeすることをプロセスとして含めることで、どの部分が改善できるのか、その確認をすることができます。

指標の紹介

本章では、脆弱性管理の改善に役立つ指標を紹介します。

パッチ適用率

パッチ適用率とは、自らが所属するグループや組織において、ある範囲の脆弱性管理の対象とする端末・ソフトウェアの全数を把握した上で、パッチが適用されている比率を表現したものです。この値が100%であるとは、公開されているすべてのパッチが適用されている状態を指しており、パッチが適用されていないことによる侵害・問題は発生しないということになります。

この指標は、どの切り口、見方で適用率を測定するかで、現状認識、改善の効果が変わってきます。一般的に、広範囲の状態を測定するほうが高コストとなります。理想的には公開されているすべてのパッチに対する適用率を向上させたいところではありますが、トリアージガイドライン[4]などを参考に、効果の高い範囲から優先的に確認するのが望ましいです。

確認する範囲の実践例
実践例1：各組織で扱っているソフトウェアとそれに対するパッチをリスト化した上で、パッチ適用率を測定する
実践例2：CVEの緊急度が特定のレベル以上（high以上など）かつ悪用実績のあるパッチのみをリスト化した上で、パッチ適用率を測定する。
実践例3：特定のソフトウェア(Windows、Linux、OpenSSH、Log4j・・・)を限定して、自組織内でのパッチ適用率を測定する

また、パッチの適用率について、単にパッチが適用されている割合を見ることもできますし、パッチごとの適用の期限を設定し、期限までの適用が遵守されているパッチの適用率を見ることもできます。[2]

MTTP(平均パッチ適用時間)

ベンダーなど、ソフトウェアのリリース元からパッチが公開され、それを適用するまでの時間の平均がMTTP(平均パッチ適用時間)[5]となります。

この値が大きくなると、パッチ適用に要する時間のサイクルが長いことを意味しており、該当する脆弱性を悪用した攻撃を許してしまう時間的なリスクが高まることを指します。

そのため、一般的には値としては小さいほうが望ましいですが、業務特性によって、パッチの適用が簡単なもの（オンラインアップデート）や即座のパッチの適用が難しいもの（インターネットから切り離された端末や制御システム、NW機器のファームウェアなど）など違いがあると思います。適用時間が長いものに対しても、現実として適用時間が長くなってしまっているという現状を認識し、中長期的にパッチ適用時間を減らすような抜本的な取り組みが打てているか、あるいはその検討や、長い間パッチが当てられていないことに対するリスクを抑えるための処置が行われているかなどを確認する材料となります。

パッチ適用にかかるコスト(時間、費用など)

組織としてどの程度安全かを測る指標に加えて、パッチ適用のコストをいかに抑えるかという点も改善の重要な要素となります。パッチを迅速に適用できるプロセス作りができれば、より多くの脆弱性に対処できるためです。

パッチが公開されると、一般的には以下の対応が必要となります。

それぞれのフェーズで、パッチの適用に費やす時間や人員数などを記録し、繰り返しのパッチ適用の中で観測していく方法です。ソフトウェアによっては適用の難しさが異なることもありますが、定常的に実施する作業時間の変化の確認、逆にイレギュラーな対応を行ったものを抽出して確認などすると、改善のポイントが見えてきます。

コスト改善については、脆弱性管理に限らず、多くの開発・製造・保守業務におけるプロセスの改善と類似点が多いことから、カイゼンやフィッシュボーンなどそれらの応用的なものも含め、既存の多くのフレームワークが適用可能な部分が多くあります。

実践イメージ

ここまで紹介した指標を用いて、実際にどのようにして改善を行っていくのかを紹介します。

測定値の継続監視

取り組みやすい方法としては、ある特定の指標に着目して指標を測定して、継続監視をするという方法が挙げられます。

例えば、自分のシステムの中で扱っているソフトウェアが「Apache HTTP Server」、「MySQL」の2点あるとします。

2つのソフトウェアに対して、新しいパッチが公開される度に「パッチ公開からパッチ適用完了」までの時間を記録していくために、既存のパッチ適用のプロセスの中に、「時間の記録」という作業を組み込みます。

そして1年間経過した段階での「MTTP：平均パッチ適用時間」を計測すれば、今年の自システムにおけるパッチ適用に関する実力(上記だと10.4 days/patch)が測定できます。あとは翌年、翌々年と同様の計測をして、改善を目指す施策を打っていく、あるいは集計対象に別システム、別ソフトウェアを含めるなど、対象を広げていくという形になります。対象が増えて来ると、組織/システム別に差異を分析していくということも可能になります。

目標・スコープの見直し

図5において、「2024年度のパッチ適用率が43%だったから2025年度がパッチ適用率60%を目指すというのは、目標の根拠としては乏しいのでは？」と思われる方もいるかもしれません。まさにその通りで、単一な指標を継続的に監視するのみでは、改善の目標設定に対する情報の不足や、誤った判断を下してしまうことがあります。

例えば過剰な改善をしてしまうケースで、他に優先すべきソフトウェアの脆弱性に対処する必要があるのに、優先度の低いパッチのパッチ適用率を重視してしまい、影響の大きい脆弱性にフタをすることが出来ず、インシデントに繋がってしまうような場合です。

これを防ぐには、以下が必要となります。

スコープ設定という意味では、例えば前述の例では、「組織全体」に対するパッチ適用の改善としておりましたが、社内や社外で発生しているセキュリティインシデントなどを確認した上で、「〇〇というネットワーク機器での事故が頻発しているから、それに関連するソフトウェア・システムを重点的に測定にしよう」などとして、本当に改善を試みたい部分を特定するといった方法と併用するなどが考えられます。

多視点での確認という意味では、例えば[2] においては、「資産の重要性」および「脆弱性の重要性」のマトリクスを作成した上で、それぞれにパッチ適用率、平均パッチ適用時間を管理するという形が提示されていました。こうすることで「資産の重要性：高」かつ「脆弱性の重要性：致命的」のエリアに、正しくフォーカスできているかということが判断できます。

このように、より複数の要素を組み合わせていくことで、より組織の目標にあった改善の施策を導き出すことができるでしょう。

まとめ

本ブログでは、脆弱性管理という業務に対して、指標を計測して改善していくために、いくつかの指標を共有しました。脅威分析やリスクアセスメントを行い、どういったポイントに絞って脆弱性管理を行うのが望ましいかを判断を行うという大局的なアプローチも、最初に開発・構築を行ったタイミングや要所要所では必要ですが、このように指標を追いかけて改善を目指すということも実際の業務においては必要になってきます。実運用の中で改善を行っていくためのアイデアとして、本ブログの情報がお役立てると幸いです。

参考文献

執筆者の他の記事を読む