ソフトウェアを開発する過程において、脆弱性（サイバー攻撃につながるバグ、セキュリティホール）はつきものです。それを悪意ある人間に利用され、システムに不正アクセスを試みるサイバー攻撃が相次いでいることは周知の事実と言えるでしょう。
これらの脆弱性対応に追われている企業の担当者は少なくないのではないでしょうか。
本記事では脆弱性管理で抑えておくべき、パッチマネジメントのポイントを基本に立ち返り解説します。
パッチマネジメントはなぜ必要なのか？
パッチマネジメントとは？
パッチマネジメントとは、システム構成を把握したうえで、構成要素ごとに関連する脆弱性情報をいち早く「検知」し、影響範囲の特定とリスクの分析によって適用の緊急性と対応要否を「判断」し、判断結果をもとに迅速に「対応」する、という一連の流れのことです（図1）。
| ① | 検知 |
| ベンダ、有識者、業界団体などの情報源から発信される脆弱性情報を収集し、自社のシステム構成要素に対する影響を評価する。 | |
| ② | 判断 |
| 脆弱性に起因するリスクの大きさ（業務影響）と攻撃手法の容易性を分析し、対応の緊急度と対応要否を決定する。 | |
| ③ | 対応 |
| 具体的な対策方法と実施時期を設定し、システムが脆弱性を突いた攻撃を受ける前に、脆弱性によるリスクを許容レベルまで極小化する。 |
図1 パッチマネジメントのプロセス
対処すべき脆弱性を迅速に特定・判断するため
脆弱性を突いたサイバー攻撃が起こると、企業の重要な情報が外部に漏洩する、またはECサイトが停止してしまい売上損失につながる、などの被害を受けます。ただし、たいていの攻撃は脆弱性発覚後にその脆弱性の内容をもとに悪意ある人間が攻撃プログラムを作成するため、攻撃が発生するまでには一定の期間を要します。この間に脆弱性に対処することで、攻撃は未然に防ぐことができます。
2017年は前年に比べて2倍以上となる約15,000もの脆弱性が公開されましたが、最新の統計データでは、そのうち「実際に攻撃まで繋がる脆弱性は2%に過ぎない」ということが判明しました*。また、「実際に攻撃プログラムが公開されるまでの日数は”2週間以内”が50%を占めている」ことがわかっています*。これらのデータから、全ての脆弱性に対処するのは非効率的であり、とくに深刻な脆弱性を見極めて必要な脆弱性のみに対応することが重要となります。
* https://www.kennasecurity.com/prioritization-to-prediction-report/ https://www.kennasecurity.com/prioritization-to-prediction-report/
※本ブログ公開当時の統計データを元に掲載しております。
そこでパッチマネジメントの出番です。パッチマネジメントにおいては上記プロセス（図1）のいずれかが欠けると、脆弱性を野放しにしてしまい企業に甚大な被害を与えかねません。しかし、パッチマネジメントは完璧！と言える企業は決して多くはないはずです。
筆者が日々企業に対してコンサルテーションをする中で、パッチマネジメントに関する以下のようなお悩みが寄せられます。
■お悩み１．どこから脆弱性情報を集めればよいのかわからない
■お悩み２．緊急性をどのように判定すればよいのかわからない
■お悩み３．脆弱性に対応できているかどうか把握できない
今回はシステムのインフラ（OS,ミドルウェア）と開発フレームワークに絞り、上記ようなお悩みにお答えしながら、組織としてのパッチマネジメントに関する基本的なノウハウをご紹介していきたいと思います。
パッチマネジメントにおける3つのポイント
どこから脆弱性情報を集めればよいか
製品ベンダのHP、有識者のブログ投稿、Twitterでのつぶやき、JPCERT/CCといった団体からの注意喚起などが、脆弱性情報を収集する際の主な情報源として活用できます（図2）。高度なCSIRT組織の早期警戒グループ（ゼロデイ攻撃を含むサイバー攻撃の予兆を早期に発見し対処を検討・実行するグループ）では、上記のような情報源から日次もしくは日に2回程度の短い間隔で脆弱性情報を調査します。
図2 脆弱性情報の主な情報源
これらの情報を整理してメール配信してくれる脆弱性情報提供サービスも存在します。脆弱性情報が当該サービスに登録される度に当該情報がユーザへメール通知され、Web上での閲覧も可能となっており、情報の質・量、スピード、コスト（有償か無償）、使い勝手によって様々な種類があります。
有償のものであれば、予め自社のシステム構成に合わせて製品情報（メーカ、型番、バージョンなど）を登録しておくことで、必要な情報のみを配信させるようにカスタマイズすることも可能です。とくに、日々システムの運用に追われている現場担当者の方々にとっては少ない運用工数で効率的に脆弱性情報を取得することができます。
以下に、無償公開されている一般的な脆弱性情報提供サイトを紹介します。
| ● | JVN iPedia |
| IPA（情報処理推進機構）による提供。データベース登録された脆弱性情報をWebから検索可能。無償であること、海外で発覚した脆弱性については翻訳作業が必要となるので要注意。 | |
| ● | NVD |
| 米国NIST(National Institute of Standards and Technology)による提供。JVN iPediaの収集情報源のひとつともなっている。データベース登録された脆弱性情報をWebから検索可能。英語のみの情報提供。 |
上記のような最新の情報が集約されている脆弱性情報提供サイトやサービスを利用することで、散在する情報を効率的に収集することが可能になります。
緊急性をどのように判定すればよいか
脆弱性の緊急性判断にはCVSSを用いた考えが一般的です。CVSSとは情報システムの脆弱性に対するオープンで汎用的な評価手法、及び指標を指します。提供ベンダによって様々な脆弱性および緊急性の表現が標準化され、評価指標が設けられています。
CVSSは0.0-10.0の数値指標となっており、しばしば7.0以上が緊急度：Highとされます。緊急度：Highかつ当該脆弱性を突いた攻撃プログラム(いわゆるPoCやExploit)が世に出回っている状況、もしくはすでに他社において被害が発生しているような状況は読者のみなさんも攻撃される可能性が非常に高い状態であるため、即座に対応が必要です（図3）。
図3 CVSSによる脆弱性の緊急度判定ロジック例
また、会社規模や事業内容によってレピュテーションリスクを緊急度判断の際のリスク評価指標の一つとするケースもあります。大々的に報道される脆弱性の悪用は、直接的被害に留まらず風評被害などの二次的な被害にもつながりやすいためです。
自社の状況を鑑みて、事前に上記のような脆弱性レベル毎の対応方針を定めておくことで、いざというときに迅速な対応が可能になります。
脆弱性に対応できているかどうか把握するにはどうすればよいか
脆弱性への代表的な対策方法としてパッチ適用、ワークアラウンド（設定変更やWAFによる通信遮断）、一時的なサービス停止などがあります。これらを比較・検討し企業にとって最良なものを選択し、現場担当者に対応を促します。主管部が資産管理台帳を俯瞰して脆弱性対応の指示を現場の責任者または担当者に伝え、対応結果を報告いただきます。作業の申請・承認プロセスと連動させることで、対応漏れや報告遅れを防ぎ、常にシステムの最新の構成情報および脆弱性対応状況が把握できます。また、これらをシステム化すれば対応結果の追跡や、対策の横展開も容易に行うことができるでしょう。
システム化については個社毎に基盤構築するのではなく、共通サービスを利用した対応を推奨します。脆弱性情報収集～対応進捗管理まで、つまり検知～判断～対応を包括的に管理できるクラウドサービスも登場しており、とくにグローバル展開している企業のグループ全体を統制する場合に効果的です。
システムの脆弱性対策状況の把握は情報集約度、情報鮮度、検索容易性の観点からその管理・統制パターンが分類されます（図4）。
| ● | 情報集約度 |
| システムの構成情報が集中管理されているか | |
| ● | 情報鮮度 |
| 構成情報が常に最新の状態が保たれているか | |
| ● | 検索容易性 |
| 脆弱性を検知後、迅速に対象となるシステムを一覧化できるか |
図4 脆弱性対応の管理・統制パターン例
自社において現状どのパターンで管理・統制が可能なのか、レベルアップするためにはどの観点を高度化すればよいのか、整理するのにお役立ていただきたいです。
「脆弱性管理・パッチマネジメントのプロセス整備」の実施状況を確認
いかがでしたでしょうか、この記事では組織としてパッチマネジメントを推進する上で基本的なノウハウをご紹介しました。
冒頭にも述べたように、現状においても実践できていない、もしくは実践していても時間やコストが多く掛かっており効率化できていない企業が存在します。体制・フロー整備について、改めて基本に立ち戻ってご確認いただきたいと思います。
「脆弱性管理・パッチマネジメントのプロセス整備」をどのくらいの企業が実施できているのか？
Secure SketCHに登録すればいつでも登録企業の各対策の平均実施率が把握できます。
是非この機会にSecure SketCHに登録して、実施率を確認してみてはいかがでしょうか？
