「パッチマネジメントの自動化によるモダナイゼーション」というテーマで過去二回お話させていただきました。

第一話ではパッチマネジメントの概要と重要性、第二話では基盤システム構築とパッチ適用の自動化についてご説明しました。
第三話である今回は脆弱性管理の自動化について解説いたします。

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

第一話でご説明したパッチマネジメントサイクルについて覚えていらっしゃいますか。 パッチマネジメントとは、セキュリティリスクを低減しシステムを健全に運用することを目的とし、システムを構成するサーバーのＯＳ、ミドルウェアおよびネットワーク機器の脆弱性を特定し、それらのセキュリティパッチを適用することで脆弱性を修正し、セキュリティリスクを低減する一連の作業を管理することです。

次に洗い出した脆弱性に対して、脆弱性の深刻度と対象サーバーの情報資産としての価値的重要性を掛け合わせてパッチ適用の優先順位を決定します。これが「パッチの特定」です。

脆弱性の調査

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

共通脆弱性識別子CVE(Common Vulnerabilities and Exposures）は、個別製品中の脆弱性を対象として、アメリカのMITRE社が採番している識別子です。

日本でもIPAとJPCERT/CCが共同で管理・運用しているJNV(Japan Vulnerability Notes）という脆弱性データベースがありますが、日本国内でも脆弱性の管理にはCVE番号を使うのが一般的です。

なお、MITRE社については弊社のセキュリティコラム「MITRE ATT&CK その1 ～概要～」に詳しく書かれていますのでご参照ください。

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

脆弱性の調査は検査対象ノードごとに、脆弱性の存在とその深刻度をまとめる作業です。 CVSS値は0～10.0の少数点一位の数値で表され、v2では「High/Medium/Low」の三段階、v3で「Critical/High/Medium/Low/None」の５段階で深刻度をカテゴリ分けしています。

CVSS値のバージョンによるカテゴリの違い

パッチの特定

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

脆弱性管理の課題

脆弱性管理の構成要素である脆弱性の調査とパッチの特定について説明してきましたが、 セキュリティ専門家でない情報システム部門のメンバーが脆弱性管理を適正に実施することは簡単なことではありません。 企業の情報システム部門で脆弱性管理を実施する際には以下のような点が課題となることが多いのではないかと考えます。

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

脆弱性スキャン検査を実施する際には、検査前に対象サーバーを管理する現場と入念な調整が必要です。脆弱性スキャン検査は対象サーバーのパフォーマンスに影響を与えることがあり、加えてスキャンに長時間かかることがあります。ですので、本来業務の影響をできる限り最小化するために、スキャン検査を実施する時間帯の調整は重要です。 また、脆弱性スキャン検査を実施する場合は、現地に情報システム部門のスタッフが赴きスキャナを操作する必要があります。 このように事前調整およびスキャン検査実施には工数がそれなりにかかり、それがいくつものシステムで実施されるため、情報システム部門には多くの工数が必要となる理由です。

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

脆弱性管理は定期的なパッチマネジメントのためにだけあるものではありません。世間を騒がす重大な攻撃が発生した場合、攻撃対象となる脆弱性の有無を一斉緊急点検することがしばしばあります。 このような緊急を要するケースでは、現場と調整をしながら実施するやり方では機動性がなく、重大な脆弱性リスクを長期間放置する結果になりかねません。

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

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

脆弱性管理ソリューション

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

脆弱性管理ソリューションの大まかな流れは下記のとおりです。

①脆弱性スキャンのスケジューリング
脆弱性スキャナがスキャンを実行するにあたり必要な情報をスキャナに設定し、スキャンする日時をスケジューリングします。

②脆弱性スキャンの実行と結果通知
スケジューリングされた日時に自動的に脆弱性スキャンを実施し、その結果を管理サーバーに送ります。 また、緊急一斉検査の場合は、管理サーバーを操作しスキャナに対して調べたい脆弱性にフォーカスしてリアルタイムにスキャンするよう指示を出します。

③スキャン結果の集計および見える化
スキャン結果は集計され自動的にスキャンレポートとして成形されます。 また、ダッシュボード表示により企業全体の脆弱性リスクの状況を見える化します。 脆弱性管理ソリューションは海外製品を中心にさまざまございますが、当社で取り扱っているものは下記の２製品でございます。

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

以上のように脆弱性管理ソリューションを導入することにより、パッチマネジメントサイクルのうち、脆弱性の調査を自動化し、効率的効果的な脆弱性管理を実現することをご説明しました。

それではパッチの特定工程での自動化はどのように行うのでしょうか。

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

SOARの概念

SOARとは企業が導入しているさまざまなセキュリティソリューションが出力する情報（ログ、イベント等）、SIEM(Security Information and Event Management)が発するインシデント情報、脆弱性管理ソリューションの脆弱性スキャン結果や外部のインテリジェンスサービスの多種多様な情報をインプットとして集約し、それらのリアクション（アプトプット）を自動的に行うためのプラットフォームです。 パッチ適用の優先順位付けを自動化するためには、情報資産の構成管理データベースにあるサーバー情報と、脆弱性スキャンの結果を掛け合わせて優先順位の自動化処理を行うSOARの機能を使って実現します。

なお、SOARを導入するにはソリューションの組み合わせに関する知見、セキュリティ運用業務の知見などを総合的に設計に反映する必要がありますので、サービス開始までかなり時間がかかることを付け加えさせていただきます。

終わりに

さて、脆弱性管理の自動化についてご参考になったでしょうか。

皆様の関係している情報システムの脆弱性リスクが軽減され、本来業務が滞りなく遂行するための一助となれば幸いです。 これで三回にわたりお話してまいりましたパッチマネジメントの自動化について筆を置きたいと思います。 コラムをお読みいただきありがとうございました。