普通の組織で「脆弱性管理」を始めるには？　日本シーサート協議会WGが解説する4つのステップ：継続的な取り組みには文書化も不可欠

　日本シーサート協議会（NCA）の脆弱性管理WG（ワーキンググループ）は、脆弱性管理の「あるべき姿」を踏まえつつ、現実との折り合いをどのように付けていくべきか、さまざまな業種の関係者と議論し、知見を蓄積し、その成果を共有することを目的に活動してきた。会員同士の「共助」を旨とするNCAならではの取り組みといえるだろう。

　そのワーキンググループが公表したのが、「脆弱性管理の手引書 システム管理者編」だ。

　同ワーキンググループの石田悠氏（NTT西日本）は、冒頭、昨今のサイバー攻撃の動向と脆弱性の傾向から説明した。

日本シーサート協議会 脆弱性管理WG 石田悠氏

　広義の「脆弱性」には、プログラムのバグの他、設定上の問題に起因する弱点、あるいは守るべき情報資産、機能に対する意図しない経路などが含まれる。これらが悪用されれば情報漏えいやデータの改ざん、正常なサービス、機能の妨害といった被害が発生し、組織の信頼性低下につながったり、業務の中断を余儀なくされたりすることは周知の通りだ。

　一方、警察庁のレポート（PDF）によれば、こうした脆弱性を探索する不審なアクセスも非常に多いのが実情だ。しかも、ここ数年発生したランサムウェア感染のインシデントの原因を見ていくと、VPN（Virtual Private Network）装置などで放置されていた脆弱性が悪用されるケースが非常に多い。この結果、ひとたび被害に遭えば企業は復旧や対応に多くのコストと時間、労力を費やさざるを得ない。トレンドマイクロの調査によると、サイバー攻撃1件当たり1億円を超える損害が生じるとされている。

　こうしたビジネスリスクを踏まえると、脆弱性管理の重要性はあらためて分かるだろう。だが、先述したように、どのように脆弱性管理を進めていくかが課題となっている。そこでNCAは手引書で、大きく分けて以下の4つのステップで進めることを推奨している。それぞれどのような取り組みなのか見ていこう。

• 脆弱性管理対象の識別
• 脆弱性情報の内容把握
• 組織におけるリスク評価
• 対処、対策

その後のプロセスのためにも重要な、事前の「管理対象の識別」

　脆弱性管理対象の識別とは、自分たちが管理しているシステムに、脆弱性管理の観点でどのようなリソースがあるのか、ソフトウェアとそのバージョン情報、インターネットからのアクセスの可否、物理的な設置場所、管理責任者といった情報も含めて把握することだ。

　同ワーキンググループでNTTデータグループの大石眞央氏は「何がどれぐらいあるのかを事前に把握することにより、いざ脆弱性情報が公開された際に、慌てず、効率良く対応できます」と説明した。

　逆に、管理対象を識別しておかなければ、脆弱性情報が出てきても、果たして自組織の製品やITサービスが脆弱性の影響を受けるかどうか、そのリスクはどのくらいなのかが分からない。脆弱性管理における後のプロセスをより適切に実施するためにも、事前の把握が重要になるとした。

管理対象を識別するイメージ（提供：日本シーサート協議会）

　ただ、「設置場所や管理者の情報まで必要なのか」と思う人もいるかもしれない。だが「対処が必要なとき、『どこのデータセンターに行く必要があるのか？』という情報が必要になります。また、システム管理を分業していたり、外部ベンダーに委託していたりする場合もあるため、脆弱性対応を依頼する際には、誰に連絡し、誰の責任でどこまでやってもらえるのかを把握することが大切です」と、大石氏は指摘した。

　そして一連の作業を、外部からのネットワークスキャンやエージェントのインストール、手動での情報収集を組み合わせ、効率良く進めることが重要だとした。

公的な情報などを収集して「脆弱性情報の内容把握」を

　次のステップは、脆弱性情報の内容把握だ。ベンダー、あるいはJPCERT/CCやIPA（情報処理推進機構）といった組織が公開したソフトウェア製品の脆弱性情報と、事前に識別しておいた表とを照らし合わせ、「自分たちで管理するシステムがどのような脆弱性の影響を受けるのか」を確認する（※なお本来ならば、設定、設計に起因する脆弱性にも対処する必要がある。このセッションでは時間の都合上割愛された）。

　一般には、開発元のベンダーやセキュリティ関連の団体、組織、そしてセキュリティベンダーなどから、脆弱性に一意に付けられる「CVE-ID」（CVE:Common Vulnerabilities and Exposures）をベースに情報を収集していく。その際には、脆弱性が存在するソフトウェアの他、「どのような条件で悪用されるのか」「悪用された結果、何が起こるのか」「修正するために何が必要か」といった事項も集めていく。

脆弱性情報の管理イメージ（提供：日本シーサート協議会）

日本シーサート協議会 脆弱性管理WG 大石眞央氏

　大石氏は、脆弱性情報を集める際のアプローチは2つあると説明した。一つは「注意喚起情報」を基に収集する方法、もう一つは、識別のプロセスでまとめた「自分たちが使っている製品の情報」を基に収集する方法だ。

　「注意喚起情報から始める場合、影響が深刻であると分かっている情報を迅速に把握できるため確度が高くなります。一方、利用製品の情報を基にする場合、網羅性や速報性はありますが、深刻な影響があるかどうかなどの情報は出そろいません」と大石氏は説明し、これから脆弱性管理を始める組織や、脆弱性管理のためのリソースが不十分な組織の場合は、まずは注意喚起情報の収集から始めるのがよいのではないかとした。

事前に合意と一貫した判断基準を定め、「組織ごとのリスク評価」を

　次のステップは、組織ごとのリスク評価だ。「脆弱性管理対象の識別で集めた情報と、脆弱性情報の内容把握で集めた情報の2つをそろえて、大量に出てくる脆弱性はどのぐらい危ないのか、そのうちどれに対応するのか、を考える段階です」（石田氏）

　脆弱性情報が日々大量に公表される中、その全てに対応するのは非現実的だ。そこで、組織ごとにどのような脆弱性に対応すべきか判断するための基準が必要になってくる。

　これには組織の事業特性やリソース、そしてリスク選好性も関わってくるため「これが正解だ」となるようなたった一つのやり方はない。基本的には、想定被害と発生可能性を掛け合わせた「リスク」をベースに、悪用状況や脆弱性を突かれる状況を掛け合わせ、そこにシステムの重要度を加味して見ていくことになるという。また、リスクは時間とともに変化するため、一度検討して終わりではなく、継続的なモニタリングの観点を保つことも重要だとした。

組織におけるリスク評価、判断基準のイメージ（提供：日本シーサート協議会）

　このプロセスにおいて参考になるのが、脆弱性の深刻度を測定する標準的な指標である「Common Vulnerability Scoring System（CVSS）」の他、脆弱性が悪用される確率を推定する「Exploit Prediction Scoring System（EPSS）」、CISA（米国サイバーセキュリティ・社会基盤安全保障庁）が管理する、悪用が確認された脆弱性情報のカタログである「Known Exploited Vulnerabilities catalog（KEV）」といった指標だ。

　脆弱性情報に関する報道では、CVSSの値だけがクローズアップされがちだ。しかし、CVSSの値が高い脆弱性のみ悪用されているとは限らない。CVSSが高い脆弱性だけに着目していると、CVSSの値は低くても悪用されている脆弱性を放置してしまう、ということになりかねない。そうした課題をカバーするのがEPSSとなる。本来対応すべき脆弱性を効率的に判断できるようになる指標だと石田氏は説明した。

　またKEVは、米国の連邦／行政府機関に対して一定の期間内で是正措置を執るよう義務付けられた脆弱性のリストとなる。日本でもその通りに対応すべきかどうかは検討の余地があるものの、悪用されている脆弱性の情報がまとめられており、参考になるという。

　石田氏はさらに、組織ごとのリスク評価を進めるに当たって、「関係部署との合意」と「一貫した判断の根拠を持つこと」が重要だとした。

　脆弱性に対応するには、経営層などさまざまなステークホルダーとの調整も必要になる。何か新たな脆弱性情報が出るたびに、「これはリスクが高い問題だから対処してください」と伝えても、実際に手を動かす必要のある側にしてみれば「いきなり言われても困る。なぜこれに対応しなければならないのか」と納得できないだろう。

　「事前に一貫した判断基準を定め、関係者と合意を取っておくことが望ましいでしょう。同時に、誰にどのような方法で連絡するのかといった、情報をやりとりする手順を決めておくことも大切です」（石田氏）

　同時に対応基準も、「リスクが高いものはできるだけ速やかに対処する」といったふんわりとした記述ではなく、「想定被害が大で、かつ発生可能性が高のものは3時間以内に対処する」といった具合に、具体的なアクションにつながる表現を取ることが必要だという。その際には、リスク評価や意思決定を、決定木を活用して支援する「Stakeholder-Specific Vulnerability Categorization（SSVC）」フレームワークも参考になるとした。

誰が、どのくらい迅速に実行するかを擦り合わせた上で「対処、対応」を

　最後は脆弱性への対処、対応のフェーズだ。ここまで収集してきた情報をマッピングし、リスクを許容できる範囲内に抑えるべく手を動かすことになる。

　同ワーキンググループの柴田はるな氏（NTT西日本）はまず、対応には、パッチを適用して根本的に脆弱性を解消する方法と、機能停止や通信の制限など他の手を打つことで脆弱性そのものに到達する可能性を下げる方法の2種類があると説明した。

　これらは、どちらかを選択して実施するという類いのものではない。パッチを適用したくても検証に時間がかかりそうならば、まず暫定対処で発生可能性を下げておき、その間に検証を済ませ、あらためて本格的な対処に入るといった流れが考えられるという。

脆弱性対応のモニタリングイメージ（提供：日本シーサート協議会）

日本シーサート協議会 脆弱性管理WG 柴田はるな氏

　ただいずれの対応を取るにせよ、対処した際の「効果」と「影響」――つまり、再起動などでシステムを停止したり、通信の制限によって一部の正常な通信もブロックされてしまったりする可能性と、その作業を「誰が」担当するのかを考慮しておくべきだという。

　「脆弱性が公表された際に、システムの開発や運用を依頼しているベンダーに『パッチ適用をお願いします』と連絡しても『その作業は契約外だ』と返されてしまうケースもあります。事前の契約合意をしっかり取ることが重要です」（柴田氏）

　もし、業務委託契約を締結している取引先企業に脆弱性対策を依頼してしまうと「偽装請負」になってしまう恐れもあるため、必要に応じて契約内容を見直すべきだとした。

　そして、組織におけるリスク評価で説明された各種指標を基に、どのような作業をどのぐらいの期間やスピードで進めるかについて、事前に意識をすり合わせておくべきだとも述べた。ただ、そうはいっても、数多くの脆弱性に対処が求められる中、いちいちルールを覚えていられない、というのも正直なところだろう。

　そこで柴田氏は、「システムそれぞれに合わせた、対処のモニタリングが必要です。脆弱性への対処がいつ完了したのか、予定通り行われているのか、それとも変更されているかを確認します。もし対処の前提となるリスク評価に変動があり、急ぎの対応が必要になれば、それも見ていく必要があります」とアドバイスした。

　中には諸般の理由で対処に遅れが生じることもあるだろう。それ自体はやむを得ないとしても、「対処の期限を超過してしまう場合は、リスクを受容、保有するという意思決定が必要になってきます。脆弱性を放置してしまったと社会から評価されると、ビジネスリスクにつながってくるため、現場ではなく、経営判断が必要になります」とした。

脆弱性管理は文書化も重要

　こうして4つのステップで脆弱性管理を進めていくには、システム管理担当者だけでなく、CISO（最高情報セキュリティ責任者）や経営層、インシデント対応のメンバーも含め、さまざまな関係者の協力が不可欠となる。従って、「もし、『広範囲に影響する深刻な脆弱性がある』となった場合の体制についても、あらかじめ整理しておくことが大切です」と柴田氏は述べ、どのような場合に誰を呼び出すかを検討、整理しておくべきだとした。

　「脆弱性管理は一過性の取り組みではなく、継続的に取り組んでいく必要があります。継続的に進めるためには、文書化しておくこともポイントです」（柴田氏）

　具体的には、対象の識別手順や脆弱性情報の内容把握、リスク評価、対処というそれぞれのステップに関して、どのツールを用いてどのような情報を収集し、どう管理するのか。そして、集まった情報は何を指標にしてどのような基準で判断するのかといった事柄に加え、対応体制についても文書化しておくことで、いざというときにも関係部署との間で「言った、言わない」にならず、スムーズに対応できるだろうとした。

　そして最後に「脆弱性管理はやはり難しい業務です。日々、大量な脆弱性情報が大量に出て、その脆弱性のどれが組織にとってクリティカルなのか、そうではないのかという中で、どこまで対処するかを考え、対策しなければならない状況です」（柴田氏）と、その困難さに言及しつつ、日々リスクが変動する中でも、手引書などを参考に自社なりの基準を定め、体制を整備し、長期戦で疲弊しないような適切な脆弱性管理につなげてほしいとした。