パッチマネジメントを自動化する際に考えておきたい脆弱性管理の課題とは：こっそり始めるパッチマネジメント自動化入門（終）

パッチ適用の時間を短縮する「自動化」について解説する連載。最終回は、パッチマネジメントサイクルについて振り返り、脆弱性管理の課題や最新動向などについて解説します。

[大久保次郎，NTTデータ先端技術株式会社]

パッチマネジメントサイクルにおける脆弱性管理

　パッチ適用の時間を短縮する「自動化」について解説する本連載「こっそり始めるパッチマネジメント自動化入門」。第1回で説明したパッチマネジメントサイクルについて覚えているでしょうか？

パッチマネジメントサイクル（再掲）

　パッチマネジメントとは、セキュリティリスクを低減してシステムを健全に運用することを目的とし、システムを構成するサーバのOS、ミドルウェアおよびネットワーク機器の脆弱（ぜいじゃく）性を特定し、それらのセキュリティパッチを適用することで脆弱性を修正し、セキュリティリスクを低減する一連の作業を管理することです。

　脆弱性管理はこのパッチマネジメントサイクルの中で「脆弱性の調査」と「パッチの特定」の部分に対応します。「脆弱性の調査」では脆弱性スキャナーを使ったスキャン検査やセキュリティ専門会社によるセキュリティ診断で対象サーバの脆弱性を洗い出します。次に、洗い出した脆弱性に対して脆弱性の深刻度と対象サーバの情報資産としての価値的重要性を掛け合わせ、パッチ適用の優先順位を決定します。これが「パッチの特定」です。

脆弱性の調査

　脆弱性スキャナーで検査すると製品によって若干の違いがありますが、おおむね下記表のような項目の情報がレポートとして出力されます。

　共通脆弱性識別子CVE（Common Vulnerabilities and Exposures）は、個別製品中の脆弱性を対象として、米国企業のMITREが採番している識別子です。日本でも情報処理推進機構（IPA）とJPCERT/CC（Japan Computer Emergency Response Team / Coordination Center）が共同で管理、運用しているJVN（Japan Vulnerability Notes）という脆弱性データベースがありますが、日本国内でも脆弱性の管理にはCVE番号を使うのが一般的です。

　なお、MITREについては記事「MITRE ATT&CK（マイターアタック）とは？　「今のサイバー攻撃って何してくるの？」が分かる6つの利用方法：MITRE ATT&CKで始める脅威ベースのセキュリティ対策入門（1） - ＠IT」に詳しく書かれているのでご参照ください。

　共通脆弱性評価システムCVSS（Common Vulnerability Scoring System）は脆弱性の深刻度を表す指標の一つです。ベンダーに依存せず、オープンで包括的、汎用（はんよう）的な評価方法として作られており、バージョンは国際フォーラム「Forum of Incident Response and Security Teams」（FIRST）が管理しています。現状v2とv3の2つのバージョンがあります。

　脆弱性の調査は検査対象ノードごとに、脆弱性の存在とその深刻度をまとめる作業です。

　CVSS値は0〜10.0の少数点1位の数値で表され、v2では「High」「Medium」「Low」の3段階、v3で「Critical」「High」「Medium」「Low」「None」の5段階で深刻度をカテゴリー分けしています。

パッチの特定

　パッチの特定では脆弱性の深刻度とサーバの情報資産としての価値的重要度を掛け合わせてパッチ適用の優先順位を決定します。つまり、脆弱性の深刻度（危険度ともいえるでしょう）が高く、サーバの存在が重要で保持している情報資産の価値が高い場合は、最優先でパッチ適用が必要ということです。

脆弱性管理の課題

　セキュリティ専門家でない情報システム部門のメンバーが脆弱性を適正に管理するのは簡単なことではありません。企業の情報システム部門で脆弱性を管理する際には以下のような点が課題となることが多いのではないかと考えます。

脆弱性スキャン検査は工数がかかる

　脆弱性スキャン検査を実施する際には、検査前に対象サーバを管理する現場と入念な調整が必要です。脆弱性スキャン検査は対象サーバのパフォーマンスに影響を与えることがあり、加えてスキャンに長時間かかることがあります。ですので、本来業務の影響をできる限り最小化するために、スキャン検査を実施する時間帯の調整は重要です。

　また、脆弱性スキャン検査には、現地に情報システム部門のスタッフが赴いてスキャナーを操作する必要があります。

　このように、事前調整およびスキャン検査には工数がそれなりにかかり、それが幾つものシステムで実施されるので、情報システム部門には多くの工数が必要です。

緊急点検時の機動性がない

　脆弱性管理は定期的なパッチマネジメントのためだけにあるものではありません。世間を騒がす重大なサイバー攻撃が発生した場合、攻撃対象となる脆弱性の有無を一斉に緊急点検することがしばしばあります。

　このような緊急を要するケースでは、現場と調整しながら実施するやり方では機動性がなく、重大な脆弱性リスクを長期間放置する結果になりかねません。

脆弱性スキャン結果の取りまとめに労力がかかる

　脆弱性スキャナーから出力される検査結果はシステムごとに手動で集計される必要があります。また、それらを分析して脆弱性リスクを評価し、経営陣に報告するための資料を作成することにも大変な労力がかかることでしょう。

脆弱性管理製品

　脆弱性製品は定期的に脆弱性スキャン検査を実施し、脆弱性リスクを定点観測します。主に脆弱性スキャナーとそれらを管理するサーバとで構成されます。管理サーバを企業内に設置するものの他、管理サーバをクラウドで提供するSaaS型ソリューションもあります。

　脆弱性管理製品の大まかな流れは下記の通りです。

1）脆弱性スキャンのスケジューリング

　脆弱性スキャナーがスキャンするに当たって必要な情報を、スキャナーに設定し、スキャンする日時をスケジューリングします。

2）脆弱性スキャンの実行と結果通知

　スケジューリングされた日時に自動的に脆弱性スキャンを実行し、その結果を管理サーバに送ります。

　一斉緊急検査の場合は、管理サーバを操作し、スキャナーに対して調べたい脆弱性にフォーカスしてリアルタイムにスキャンするように指示します。

3）スキャン結果の集計および見える化

　スキャン結果は集計されて自動的にスキャンレポートとして成形されます。また、ダッシュボード表示によって企業全体の脆弱性リスクの状況を可視化します。

優先順位付けの自動化はどうするのか

　パッチの特定工程では、脆弱性の深刻度と情報資産の重要性を掛け合わせてパッチ適用の優先順位を決めます。この工程を自動化するにはSOAR（Security Orchestration, Automation and Response）の導入が最適です。

　SOARは、企業が導入しているセキュリティ製品が出力する情報（ログ、イベントなど）やSIEM（Security Information and Event Management）が発するインシデント情報、脆弱性管理製品のスキャン結果、外部のインテリジェンスサービスの情報などをインプットとして集約し、それらのリアクション（アウトプット）を自動化するプラットフォームです。

　パッチ適用の優先順位付けを自動化するには、情報資産の構成管理データベースにあるサーバ情報と、脆弱性スキャンの結果を掛け合わせて、優先順位を自動化するSOARの機能を使います。

最近の動向

　DevOpsやCI/CD（継続的インテグレーション／継続的デリバリー）などの新しい開発手法がシステム開発現場に浸透するにつれて、脆弱性検査および脆弱性管理にも新しい技術が必要となってきました。ここでは、2つのキーワードを挙げておきます。

1）コンテナイメージの脆弱性検査

　CI/CDのためにコンテナ環境の利用が普及してきました。コンテナイメージに存在する脆弱性を検出するには、今まで説明してきたインフラ部分（OS、ミドルウェアのレイヤー）を検査する脆弱性スキャナーではできないので、コンテナイメージの脆弱性検査専用のスキャナーが必要です。多くのメーカーでは、コンテナイメージ専用の脆弱性スキャナーを準備しています。

2）アプリケーションに埋め込まれたOSSの脆弱性

　2021年12月に判明した「Apache Log4j」の脆弱性はCVSS値が最高レベルの「10」と評価され、皆さんの現場でもLog4jの対策で多大な苦労があったと推察します。Log4jの対策の難しさは「どこでLog4jが使われているのかが分からない」ということが一番ではないでしょうか。

　OSやミドルウェアなら意図してそれを使っているので、脆弱性情報にある影響範囲から脆弱性の有無をだいたい特定できます。一方、Log4jのようなオープンソースソフトウェア（OSS）は、ユーザーアプリケーションや商用パッケージに意図せず混入している可能性があり、システム管理者は脆弱性の有無を判断できません。

　このようなOSSに関する状況を解決する手段の一つとしてSBOM（Software Bill of Materials）という概念があります。

　SBOMは製造業ではおなじみのBOM（部品表）の概念をソフトウェアに応用したもので、「ソフトウェア部品表」と訳されます。つまり、アプリケーションが利用しているソフトウェアやライブラリを一覧にしたもので、決められたフォーマットで出力されます（標準的なフォーマットは3種類程度あります）。

　アプリケーションを解析してSBOMのフォーマットで出力する製品は幾つかありますが、SBOMを使って体系的に脆弱性を管理している事例は日本国内ではまだ希少です。しかし、ソフトウェアサプライチェーンのセキュリティ管理ではトレンドとなるはずなので、SBOMの動向から目が離せません。

終わりに

　これまで3回にわたって連載したパッチマネジメント自動化の解説は今回で最後です。本連載が皆さまのセキュリティレベル向上の一助となれば幸いです。

筆者紹介

大久保 次郎

NTTデータ先端技術株式会社

経営企画部テクノロジーパートナーアライアンス推進室

情報処理安全確保支援士　CISSP　CISA