脆弱性
脆弱性とは
脆弱性とは、OS、VPNなどのネットワーク機器、資産管理ツール、セキュリティソフトなどが持つソフトウェアの欠陥（弱点）です。脆弱性を放置することで、サイバー攻撃にあう可能性が高まります。
脆弱性の概要
サイバーセキュリティを考える際、脆弱性は大きく広義、狭義2つの意味にわかれます。広義の意味で、サイバーセキュリティのリスクマネジメントを考えるうえで、脆弱性はリスクを評価する上での要素であり、サイバー攻撃による被害を受ける可能性を図る指標の一つです。組織のリスクは以下の要素に分解して考えることができます。
図1：リスクを評価する3要素
組織のリスク（ビジネス上問題になること）は、技術・プロセス・人・物の「脆弱性」、どのようなサイバー攻撃に自社が直面しているかという「脅威」、自社が保護するべき「資産」を紐解いていくことでインパクトをはかることができます。
サイバー攻撃者など悪意を持った第三者は脆弱性を悪用することで、組織のネットワークへ不正に侵入して重要な情報資産を盗み出すことや、ランサムウェアなど組織に被害をもたらすマルウェアに感染させようとしてきます。脆弱性への対応は、サイバー攻撃対策において重要であることは間違いありません。それでは、脆弱性には大きく分けるとどのようなものが存在しているのでしょうか。
脆弱性は大きく分けると4種類のカテゴリが存在します。技術・プロセス・人・物です。
技術
サイバーセキュリティ上、狭義の意味で脆弱性を語る場合、技術的な脆弱性をイメージする方が多いのではないでしょうか。技術的な脆弱性とは、OSやソフトウェア、アプリケーションなどの欠陥（弱点）を指します。「ソフトウェアに修正プログラムが適用されておらず第三者が任意のコードを実行可能」などの技術的な欠陥がこれに当たります。技術的な脆弱性が発見されると、米国政府の支援を受けた非営利団体であるMITRE社は一意の識別番号である「CVE（共通脆弱性識別子CVE(Common Vulnerabilities and Exposures)）」を採番します。これにより、各セキュリティベンダなどが発行する脆弱性対策情報が同じ脆弱性に関する話題であることの判断や、情報同士の相互参照、関連付けが容易にできるようになります。
日本で使用されているソフトウェアなどの脆弱性関連情報とその対策情報を提供し、サイバーセキュリティ対策に資することを目的とする脆弱性対策情報ポータルサイトJVN（Japan Vulnerability Notes、IPAとJPCERT/CCが共同で運営）も、MITRE社と連携してCVE採番の枠組みに参加しています。
◆Column◆
技術的な脆弱性の中でも、その存在が公表される前や開発元から修正プログラムがリリースされる前の脆弱性を「ゼロデイ脆弱性」と呼びます。また、開発元から修正プログラムが公開されている脆弱性を「Nデイ脆弱性」と呼びます。そして、ゼロデイ脆弱性を悪用した攻撃をゼロデイ攻撃、Nデイ脆弱性を悪用した攻撃をNデイ攻撃と呼びます。
注意すべきことは、ベンダから修正プログラムが提供された後にその脆弱性を悪用する攻撃は増加するということです。攻撃者はベンダから公開された修正プログラムを解析することで攻撃コードを作成できることが大きな要因です。そのため、修正プログラムが公開されたのち、可能な限り迅速に修正プログラムを適用することが求められます。
図2：ゼロデイ脆弱性とNデイ脆弱性
プロセス
プロセスの脆弱性とは、管理プロセスの不備など組織的な欠陥を指します。「顧客の個人情報の管理が適切に行われていないため、格納されているファイルフォルダへのアクセス権が全社員に付与されている」「設定の検証や承認が適切に行われなかったため、公開すべきでないサーバが外部公開されている」「送金に関する承認ルールが整備されていないため、担当者の関与のみで外部に送金を行えてしまう」など、組織がシステムを運用するうえで適切なプロセスが設定されていない、もしくは設定されているものの順守されていないといった欠陥がこれに当たります。
人
人の脆弱性とは、心理や感情、行動などの弱さや甘さ、不注意など、従業員をはじめとする人間の心理における欠陥を指します。「知らないアドレスから送信されたメールのリンクを不用意にクリックしてしまった」「SNSで所属企業の情報を投稿してしまった」など、人の不安感や焦り、弱み、セキュリティ意識の欠如などの人間の心理における欠陥が当たります。
ソーシャルエンジニアリングやフィッシングといった手法では、人の脆弱性が悪用されます。
物
物の脆弱性とは、建物などの施設やハードウェアに存在する物理的な欠陥を指します。「建物内への入退室における管理が適切に行われていない」「ワイヤーロックなど機器の盗難防止対策が行われていない」など、物理的に施設内へ侵入して、機器の破壊や情報の盗難などが行われる状態が該当します。
図3：脆弱性の４つのカテゴリ
増加する技術的な脆弱性とその脅威
サイバー攻撃者など悪意を持った第三者は、攻撃可能な脆弱性を見つけると、そこから攻撃を行い、情報窃取などの目的を達成しようと試みます。中でも技術的な脆弱性は、組織を悩ます課題となっています。新たに発見される深刻な脆弱性の数は年々増加しており、組織が技術的な脆弱性を残存させた場合に、被害が大きくなる可能性があると言えるからです。
図4：2021年上半期と2022年上半期にトレンドマイクロが運営するコミュニティ※1が公開した脆弱性情報の深刻度別（脆弱性のCVSSに基づく深刻度別）内訳
※1脆弱性発見コミュニティ「Zero Day Initiative（ゼロデイイニシアティブ）」
一方で、脆弱性が発見されると、サイバー攻撃者は非常に短期間で攻撃をしかけることがわかっています。例えば、2022年3月31日に公開された、Java向けのアプリケーションフレームワークSpring Frameworkの脆弱性Spring4Shellを悪用するサイバー攻撃は2022年4月にピークとなっています※2。また、国内の事例では、クラウドプラットフォームで利用されていたソフトウェアの脆弱性が発見されてから1週間以内にその脆弱性が悪用されたという報道もありました。
※2トレンドマイクロ「2022年上半期サイバーセキュリティレポート」
セキュリティ対策を行う上で、組織に残されている技術的な脆弱性を発見、評価し、実施内容を決定する「脆弱性管理」は、組織にとって避けては通れない課題です。
それでは、技術的な脆弱性管理や対策は、どのようなことを行えば良いのでしょうか。
脆弱性管理の基本
発見された脆弱性の根本的な対応は、ソフトウェアベンダから提供される修正プログラムを適用することです。
脆弱性が発見されてから修正プログラムを適用、評価するまでの一連の流れを、ここでは「脆弱性管理」と呼びます。適切な脆弱性管理を行うことは、組織におけるソフトウェアの欠陥による脆弱性を軽減できます。結果として、脅威となるサイバー攻撃者による悪用の機会が減り、組織の資産への侵害を未然に防ぐことに繋がります。
脆弱性管理における基本的な流れは以下になります。
システムインベントリ（資産リスト）の作成
組織で使用しているハードウェア、OS、およびソフトウェアを棚卸し、システムインベントリ（利用者名、利用開始日、コンピュータ名、OS、利用しているソフトウェアなどをリストアップしたもの）を作成します。
そして、組織が設けた指標毎に、グループ化を行い、脆弱性が発見されたときの対応の優先順位付けを行います。優先順位を行う際に用いる指標は、資産が配置されているシステム構成や、障害があったときに事業に与える影響度などから考えます。
◆Column◆
近年、システムインベントリの中でも、利用しているソフトウェアのライブラリやコンポーネントなどの依存関係も把握するSBOM（ソフトウェア部品構成表）の有効性が伝えられています。
これは多くのアプリケーションやシステムでオープンソースソフトウェア（OSS）が利用される状況下においては、自組織でその脆弱性の管理も求められるようになってきているという背景があります。ソフトウェアの構造の複雑化による脆弱性管理の課題を解決するSBOMの動向や組織が実施すべき取り組みについては、「ソフトウェア・サプライチェーンの脆弱性管理に求められるSBOMの必要性」で解説しています。
脆弱性情報の収集
セキュリティに関する情報ソースを定期的にチェックして、組織のシステムインベントリに含まれているソフトウェアに対応する脆弱性の公表、修正プログラムや修正プログラム以外による修正措置、および脅威（該当の脆弱性を悪用するマルウェアの存在有無など）がないかどうかを確認します。
脆弱性対策の優先順位付け
図5：脆弱性管理の基本的な流れ
組織のシステムインベントリ内のソフトウェアで脆弱性が発見された場合、その脆弱性が悪用された場合の組織への影響度や、PoC(Proof of Concept,脆弱性悪用のための検証用コード)や被害事例が公開されているか、修正プログラムの適用によるシステムへの影響などを考慮した上で、修正プログラムを適用する優先順位や適用の順序を設定します。
脆弱性対策の実施
修正プログラムおよび回避策（ワークアラウンド）を適用する前に、システムに想定していない影響が生じないか事前にテストを実施します。テストの結果、オペレーションに問題がないと確認できた場合に、それらを適用します。
脆弱性対策の評価
ネットワークやホスト（PCやサーバ）の脆弱性スキャン（脆弱性診断）で、脆弱性が残存していないか、残存していたとしてもリスクは想定内の許容できる範囲に収まっているか、脆弱性対応で実施した措置の検証を行います。また、実施した脆弱性対応が適切であったか、改善点はあったかを評価を行います。
深刻度の高いソフトウェア脆弱性が発生したら
日々のセキュリティに関する情報収集やセキュリティ機関からの注意喚起により、自組織のシステムインベントリ内のソフトウェアに深刻な脆弱性が存在することを確認した場合には、「観察」「方向付け」「判断」「行動」を行うOODA（ウーダ：Observe、Orient、Decide、Action）ループにより迅速に対応方針を決める必要があります。
緊急で対応を行う必要があるかの判断
脆弱性管理における基本的な流れで解説したとおり、脆弱性が発見された場合には優先順位を設定することが重要です。そのなかでも、該当の脆弱性がCVSS(共通脆弱性評価システム)により深刻度が「緊急」と判定されており、自組織の外部公開システムなど容易に攻撃が行われる可能性のある環境に存在している、また、該当の脆弱性を悪用する攻撃実証コード（PoC：Proof of Concept）が既に公開されているなどのケースでは、その他の脆弱性よりも優先度を高くして、緊急で対応を行う必要があります。
例えば、2021年12月に公開されたJava向けのログ出力ライブラリ「Apache Log4j」の脆弱性「Log4Shell」の場合、多くの企業のソフトウェアやアプリケーションで利用されており、多くの組織が緊急で対応を行いました。
攻撃の可能性を低減する一時的な代替策の検討
脆弱性の根本的な原因を排除するためには、すぐに修正プログラムを適用することが理想的です。しかし、メンテナンス時間が決められていたり、事前に検証環境でのテストが必要であったりすることから、すぐに修正プログラムを適用することが困難であるというケースが多々あります。また、ベンダからの修正プログラムのリリース前に公開されるゼロデイ脆弱性といったケースもあります。
そのような場合には、修正プログラム以外の対策によって、できる限り迅速に脆弱性が悪用される可能性を軽減する必要があります。具体的には、該当ソフトウェアにおける設定変更など開発元が案内している回避策の実施、仮想パッチ（IDS/IPS）などのセキュリティ製品による脆弱性を悪用した攻撃のブロックや検知についても併せて情報収集や実現可否を確認しておくことで、迅速な脆弱性対応の実現に繋げることができます。
修正プログラム適用後の状況の観察
修正プログラムを適用することで脆弱性を排除することはできますが、引き続きOODAループに沿って状況の観察を行うことが重要です。なぜなら、脆弱性のなかには、修正プログラムが不完全であったり、関連した新たな脆弱性が短期間の間に発見されたりするケースがあるためです。「Log4Shell」においては、開発元により該当の脆弱性の対策が施されたと案内された最初の「Apache Log4j」の新バージョンがリリース後、修正内容の見直しや新たな脆弱性の対応のために、短期間のうちにいくつものバージョンがリリースされました。
修正プログラム適用の課題
脆弱性が発見されたとしても、意図しない結果が生じないかテストを行うことや、システム稼働を止めて修正プログラムを適用するためには、ある程度の時間が必要な場合が多々あります。修正プログラムを適用する前の段階では、セキュリティソフトによる仮想パッチ（IDS/IPS）機能はとても有効な対策の一つです。
しかし、仮想パッチは大きくネットワーク型とホスト型の製品があるものの、どちらも脆弱性を悪用する攻撃パケットをネットワークレベルで防御するため、エンドポイントのローカル上で完結する攻撃への対応は難しく（ホスト型の仮想パッチもエンドポイントに侵入するネットワークレベルで攻撃を検知しています）、完璧な対策とは言えません。抜本的な脆弱性への対策は、修正プログラムを適用することにつきるのです。
トレンドマイクロが実施した組織のサイバーセキュリティリスク状況を可視化するための国際的な意識調査（Cyber Risk Index）※3では、日本は他の地域と比較して、特に「脆弱性の修正プログラムの迅速な適用」に関して課題を感じている傾向があります。
※3トレンドマイクロ「サイバーセキュリティリスク意識調査レポート（日本）」
図6：質問「自組織のITセキュリティ対策は、セキュリティパッチを迅速にテストし、適用する」に対する各地域の平均点
これはシステム開発や運用を行うITに携わる人材が自組織内部に少ない日本の特徴が、マイナスに転じている結果とも考えられます。場合によっては、脆弱性管理を誰が指揮をとって対応を行うのか、管理目標や手順が明確にされていないという可能性もあります。
修正プログラムの迅速な適用には、組織の体制や環境に沿った適切な脆弱性管理が必要不可欠です。組織内部のシステムインベントリを作成し、定期的に収集する脆弱性情報と照らし合わせたうえで、脆弱性対応の優先順位付けを行うことで、計画的な脆弱性管理を実現できます。また、脆弱性対応については、通常時と緊急時のポリシーを策定しておくことも重要になります。
◆Column◆
組織が脆弱性管理を改善し、より迅速に修正プログラムの適用を行っていくためには何をしなくてはいけないのでしょうか。参考にするガイドラインのひとつに、NIST SP800-40の文書「パッチおよび脆弱性管理プログラムの策定」があります。NIST SP800は、連邦政府機関や、連邦政府機関の業務委託先をはじめ、世界中の企業・団体に参照されているガイドラインです。本ガイドラインのポイントについては、「脆弱性管理のガイドライン「NIST SP800-40」を紐解く」で解説しています。
脆弱性情報のソース
最後に、脆弱性情報を収集するために参考となる情報ソースを掲載します。
| 名前 | 概要 |
|---|---|
| JVN（Japan Vulnerability Notes） | JPCERTコーディネーションセンターと独立行政法人情報処理推進機構(IPA)が共同で運営する日本で使用されているソフトウェアなどの脆弱性関連情報とその対策情報を提供する脆弱性対策情報ポータルサイト。 |
| JVN iPedia（脆弱性対策情報データベース） | IPAが運営する国内外問わず日々公開される脆弱性対策情報のデータベース。 |
| Common Vulnerabilities and Exposures | 米国MITRE社が管理運営を行っている、一般公表されている公知の脆弱性情報を掲載している脆弱性情報データベース。 |
| IPA：重要なセキュリティ情報 | 放置すると危険性が高いセキュリティ上の問題と対策情報を掲載。 |
| JPCERT/CC：注意喚起 | 深刻且つ影響範囲の広い脆弱性などに関する情報を告知。 |
| Zero Day Initiative（ゼロデイイニシアティブ） | トレンドマイクロが運営する脆弱性発見コミュニティ。発見された脆弱性のアドバイザリを掲載。 |
| トレンドマイクロ：脅威データベース | マルウェア、スパム、不正URL、脆弱性とすべての脅威情報を集積したデータベース。 |
脆弱性についての関連情報
脆弱性管理のガイドライン「NIST SP 800-40」を紐解く
日々発見される脆弱性に対応するため、法人組織が参考にすべき脆弱性管理のガイドラインの１つ「NIST SP 800-40」を解説します。
今後のランサムウェア攻撃で備えるべき「第三のリスクシナリオ」とは？
「暗号化による業務停止」だけでなく「暴露による情報漏えい」までも一般的になりつつあるランサムウェア攻撃。世界26ヵ国でこの脅威の被害を調査した結果、第三のリスクシナリオとして「レピュテーション」のリスクが見えてきました。