脆弱性管理とは

脆弱性管理の説明

ネットワークデバイス、サーバー、ストレージシステム、ワークステーション、レガシーアプリケーション、仮想マシン、 コンテナ、クラウドアプリケーション、 マイクロサービス、データベース、API、クラウドインフラサービス、クラウドプラットフォームサービス、セキュリティ設定など、数え上げればきりがありません。アジャイル手法やクラウドサービスの普及によりIT環境が拡大する中、脆弱性管理はますます複雑になっています。従来のIT環境と同様に、 クラウドワークロードの 脆弱性管理は、 機密データの保護、 クラウドコンプライアンスの維持、サイバー攻撃リスクの低減を確実にするために、セキュリティ脆弱性の特定、評価、優先順位付け、緩和を含む継続的かつ多面的なプロセスです。

このプロセスは、最新の資産インベントリを維持し、脆弱性スキャンを採用してクラウド・リソースに潜在する脅威を発見することから始まります。脆弱性は、その重大度と影響に基づいて評価され、修復作業の優先順位付けが可能になります。パッチと設定管理はソフトウェアの脆弱性と設定ミスに対処し、継続的な監視とインシデントレスポンスは新たな脅威の迅速な検知と封じ込めを保証します。最後に、報告および監査活動によって可視性と説明責任が提供され、脆弱性管理プログラムの有効性とコンプライアンスが確保されます。

脆弱性、脅威、リスクの理解

なぜ脆弱性が重要なのか、そして脆弱性がビジネスにどのような影響を与えるのかを理解するためには、脆弱性、脅威、リスクの関係を理解する必要があります。

脆弱性とは、IT システムの欠陥、弱点、設定ミス、見落としのことで、攻撃者がこれを悪用して、システムの制御を奪ったり、システムからデータを流出させたり、運用を妨害したり、ビジネスに損害を与えたりする可能性があります。

これが意味するのは、脆弱性がサイバー脅威を実行する機会を生み出すということです。脅威とは、ある種のサイバー攻撃を実行しようとする（そして実行できる可能性のある）あらゆる主体のことです。しかし、サイバー攻撃を実行するには、脅威が利用できる脆弱性を見つける必要があります。

脆弱性が存在し、脅威がそれを積極的に悪用しようとするとき、組織は危険にさらされます。

つまり、脆弱性は脅威が実際のリスクになることを可能にするのです。脆弱性がなければ、金銭的な利益のために組織から機密データを盗み出そうとするハッカーや、地政学的な目的のために重要なシステムを混乱させようとする国家に支援された脅威アクターなどの脅威は、依然として存在する可能性があります。しかし、実際に脅威が悪用されるリスクが存在するのは、脆弱性が存在する場合だけです。

クラウドの脆弱性管理が難しい理由

脆弱性管理はどのようなタイプのワークロードでも単純ではありませんが、クラウドワークロードを扱う場合、脆弱性の検出と緩和は特に困難です。

クラウドサービスは複雑で多様

クラウドのワークロードは千差万別です。これらのサービスには、VM、コンテナ、サーバーレス機能、 オーケストレーションサービス、またはこれらすべてが含まれます。クラウドのワークロードの種類ごとに異なるタイプの脆弱性の影響を受ける可能性があるため、ワークロードのコンテキストに基づいて異なる脅威を認識できる脆弱性管理戦略が必要です。

クラウドは常に変化しています。

一般的なオンプレミス環境よりもクラウド環境は動的です。ワークロードの大規模化・縮小、ユーザーの追加・削除、アプリケーションの更新などに伴い、構成は常に変化します。このため、脆弱性を継続的に監視する能力が最も重要です。

クラウドリスクの範囲はさまざま

すべての脆弱性が同じように作られているわけではありません。リモート・コード実行を可能にするものなど、稀なコンフィギュレーションでしか悪用できないものよりもリスクが高いものもあります。どれが重大度なのかを知っておくことで、まずそれに対処することができます。

脆弱性管理とパッチ管理の比較

ある面では、脆弱性管理プロセスは、IT 組織が数十年にわたって実践してきた他のセキュリティプロセス（パッチ管理など）に似ています。脆弱性管理と同様に、パッチ管理では、潜在的なセキュリティリスク（攻撃者が悪用する可能性のあるパッチ未適用のソフトウェア）がアクティブな問題になる前に、体系的に発見し、対応します。

しかし、脆弱性管理プロセスはパッチ管理にとどまりません。

• パッチが適用されていないソフトウェアは、IT環境に脆弱性が入り込む可能性のある方法の1つですが、それだけではありません。脆弱性管理は、安全でない設定など、脆弱性の他の入口にも対処します。
• パッチ管理では通常、ソフトウェア・パッチを定期的にインストールしますが、脆弱性管理は継続的なプロセスです。脆弱性のスキャンは週に1回、あるいは1日に1回でいいのではありません。その代わり、継続的なスキャンを行い、いつでもどこでもリアルタイムで脆弱性を見つけて対応できるようにすべきです。
• 脆弱性管理プロセスは、パッチを適用できる資産（アプリケーションなど）だけでなく、クラウドサービスやインフラストラクチャなど、ITチームが通常パッチを適用できないタイプのリソースにも適用されます。

一般的な脆弱性と暴露（CVE）の概要

セキュリティ研究者は、一般に使用されているソフトウェアの脆弱性を発見すると、通常、CVE（Common Vulnerabilities and Exposures）データベースに報告します。CVEデータベースは、既知の脆弱性のリストです。これらの情報には、脆弱性の原因、脆弱性の悪用方法、脆弱性の重大度、脆弱性を緩和するためのパッチやアップデートの方法などの詳細が含まれています。

ほとんどのCVEデータベースは、脆弱性とその重大度に関する詳細を共有するためのオープンなフレームワークであるCommon Vulnerability Scoring System（CVSS）を使用して、この情報を定義しています。脆弱性データにアクセスできるようにすることで、CVEとCVSSは、組織が使用するシステムやソフトウェアに影響を及ぼす脆弱性を判断するために使用できる重要なリソースを提供します。さらに、これらの脆弱性がどの程度深刻で、ビジネスで使用する特定の構成に基づいて悪用できるかどうかをチームに伝えることができます。

ナショナル・ヴァルネラビリティ・データベース（National Vulnerability Database ）と MITRE CVE データベース （MITRE CVE database）は、最もよく利用されている公開CVEデータベースのひとつです。しかし、組織は非公開または強化されたCVEデータを保持することもでき、脅威インテリジェンスの一部として他の組織に提供することもできます。

CVE の重要な限界は、通常、オープンソースのアプリケーションなど、一般に公開されているソフトウェアに影響する脅威のみをリストアップしていることです。その主な理由は、誰でも公開されているソフトウェアを検査し、その中の脆弱性を見つけることができる可能性があるからです。組織が内部使用のために確保しているソフトウェアは、第三者の研究者が調査することがより困難です。その結果、ソフトウェア内の脆弱性は必ずしもCVEデータベースで発見されたり、公開されたりしていません。

つまり、CVE データベースに既知の脆弱性の記録がないからといって、そのアプリケーションに脆弱性がない と決めつけてはならないということです。脆弱性が存在し、脅威アクターに知られているにもかかわらず、まだ報告されていないだけという可能性は常にあります。

しかし、前述のようにセキュリティの脆弱性はさまざまな形で現れます。

壊れた認証

ソフトウェア内の アクセス制御 プロセスや設定が効果的でない場合、悪意のある行為者がソフトウェアにアクセスしたり、ユーザーの権限を超えて権限を昇格させたりする可能性があります。

SQLインジェクション

SQLインジェクションの脆弱性は、攻撃者が悪意のあるクエリをデータベースに注入し、データを操作したり、データベースから情報を流出させたりすることを可能にします。SQL インジェクションの脆弱性は、通常、データベースとのインタフェースを持つアプリケーション内の適切な入力検証の欠 如によって発生します。

クロスサイト スクリプティング

クロスサイトスクリプティングの脆弱性により、攻撃者は悪意のあるスクリプトを実行することができます。この種の脆弱性は、Javascriptの記述が不十分なWebサイトに影響を与えることがほとんどです。攻撃者が脆弱なコードを見つけると、サイトを騙して好きなスクリプトを実行させることができ、ウェブサイトに接続するエンドポイントのリソースにアクセスできるようになる可能性があります。

クロスサイトリクエストフォージェリ

攻撃者は、クロスサイト・リクエスト・フォージェリの脆弱性を悪用して、ユーザが現在認証されているウェブサイトやアプリケーションに悪意のあるコードを注入させることができます。クロスサイト・スクリプティングの脆弱性と似ていますが、大きな違いは、クロスサイト・リクエスト・フォージェリの脆弱性は、安全でない Javascript を使って悪意のあるコードを実行するのではなく、認証されたユーザになりすまして悪意のあるアクションを実行する点にあります。

セキュリティの設定ミス

セキュリティ設定の誤りや見落としがあれば、脆弱性が引き起こされる可能性があります。例えば、管理者がファイアウォールの設定ミスでうっかり機密データにインターネット経由でアクセスできるようにしてしまったり、新しいアプリケーションのデプロイメントを設定する際に多要素認証を要求し忘れたりする可能性があります。

脆弱性管理と脆弱性評価の比較

脆弱性管理とは、IT組織が脆弱性を特定し、対応するための戦略です。しかし、個々の脆弱性が発見されると、脆弱性評価と呼ばれるプロセスを用いて、脆弱性がどの程度のリスクをもたらすかを理解し、脆弱性をどのように修復するかを決定します。

脆弱性の評価が重要なのは、すべての脆弱性が同じレベルのリスクをもたらすわけではないからです。例えば、脆弱なシステムに直接物理的にアクセスできる攻撃者のみが悪用できる脆弱性は、一般的に言って、ネットワーク上で悪用できる脆弱性よりもリスクが低くなります。

さらに、特定の設定や環境下でのみ脆弱性が悪用されるケースもあります。例えば、あるアプリケーションの脆弱性は、そのアプリケーションが Windows サーバでホストされている場合 に悪用されるかもしれませんが、Linux サーバでは悪用されないかもしれません。

このような要因に基づいて脆弱性評価を行うことで、組織は各脆弱性が組織にもたらすリスクの具体的なレベルを判断することができます。そして、最も重大度の高い脆弱性から優先的に対応することで、全体的なリスクレベルを最小化することができます。

脆弱性管理フレームワークの構築

脆弱性管理プログラムは、対応する組織固有の要件に合わせて調整する必要がありますが、ガートナーは、脆弱性管理を開始するための有用な出発点となる脆弱性管理ガイダンスフレームワークを提供しています。

ガートナーのフレームワークの 主な構成要素は以下の通り：

• プログラムの範囲を定義します：企業は、どれだけのIT資産と脆弱性の種類に対処する必要があるかを決定することから、脆弱性管理戦略を開始します。
• 役割と責任の明確化誰が、いつ、何をするのかを決定することは、脆弱性管理の重要な要素です。ITエンジニアのような現場のスタッフからCISOやCTOに至るまで、誰もが脆弱性を発見、報告、管理する役割を担っています。
• 脆弱性評価ツールの選択企業は、脆弱性の発見と評価にどのツールを使用するか、また脆弱性の修復をワークフローやツールにどのように組み込むかを決定する必要があります。
• ポリシーSLAの作成と改善SLAは、組織がどの程度迅速に脆弱性に対応し、どの程度のアクティブな脆弱性を許容できるかを決定します。組織によって許容できるリスクレベルが異なるため、SLAはビジネスに合わせて調整することが特に重要なリソースです。
• アセットコンテキストソースの特定資産コンテキストソースは、システムまたはアプリケーションがビジネスで果たす役割に関するデータなど、脆弱性とその重大度を評価するために重要な補足情報を提供します。

これらの各要件に対応することで、組織は脆弱性管理プログラムを確立し、懸念されるすべてのシステムにわたって脆弱性を発見し、対応することができるようになります。

脆弱性管理の4つの主要ステップ

効果的な脆弱性管理プログラムを完全に実装すると、脆弱性管理プロセスにおける以下の各ステップを実行できるようになります。

脆弱性の特定

見えないものは直せません。脆弱性の発見には、組織内のすべてのIT資産をスキャンし、それら（またはそれらの構成要素）に脆弱性があるかどうかを判断することが含まれます。CVEデータベースはこの目的のために重要なリソースですが、やはり、すべての脆弱性が公開CVEリストに詳述されているわけではありません。

脆弱性の評価

発見後、それぞれの脆弱性を評価し、それがビジネスにどの程度のリスクをもたらすかを判断する必要があります。手作業による脆弱性評価が必要な場合もありますが、脆弱性管理ツールは、各脆弱性の重大度を自動的に判断し、その脆弱性がビジネス環境で悪用される可能性がどの程度あるかを評価することで、プロセスを加速することができます。

脆弱性の治療

脆弱性には主に3つの対処法があります：

• 修復：通常、脆弱性が存在しないように、影響を受ける資産を更新したり、パッチを適用したりすることで、脆弱性を完全に除去します。
• 緩和：脆弱性を緩和することで、組織は脆弱性が悪用されるリスクを最小限に抑えたり、脆弱性が引き起こす潜在的な被害を軽減したりすることができます。緩和策は、修復が不可能または実行可能でない場合に有効な戦略です。例えば、脆弱性のあるレガシー・アプリケーションにパッチが提供されていないために、そのアプリケーションを更新できな い場合でも、アプリケーションの設定を変更することによって、脆弱性を緩和することができるかもしれません。
• 受け入れ：場合によっては、IT 組織が、脆弱性は修復や緩和を行うほど深刻ではないと判断することもあります。その場合、彼らは脆弱性を受け入れるだけです。

脆弱性の報告

脆弱性報告とは、外部のステークホルダーに脆弱性を開示するプロセスです。多くの場合、公開されているCVEデータベースに脆弱性レポートを提出することになりますが、コンプライアンス上の義務や契約上の合意によって、組織が規制当局や顧客、パートナーに脆弱性を直接報告することを求められる場合もあります。いずれにせよ、報告の目的は、どのような脆弱性が存在し、何がその原因となっているのか、そしてどのように修正すればよいのかという情報を共有し、脆弱性が悪用される前に他の人が対応できるようにすることです。

脆弱性管理プログラムの改善

脆弱性管理プログラムを導入したからといって、脆弱性の心配をやめて他の心配事に移れるわけではありません。その代わりに、脆弱性管理は継続的な改善戦略、つまりIT組織が脆弱性管理戦略を改善する方法を継続的に模索することによって利益を得るべきです。

脆弱性管理プログラムの一般的な改善例には、以下のようなものがあります：

• 脆弱性管理の効率性と一貫性を高めるため、自動化をより広範に活用します。
• 脆弱性管理の対象範囲にシステムやアプリケーションを追加し、対象範囲の包括性を高めること。
• 脆弱性を評価する際に利用可能なデータを増やすために、脆弱性データベースおよび/または資産のコンテキストソースを追加活用。
• 従来のシステムでは対応できなかった種類の脆弱性を検出するための、新しい、または強化された脆弱性管理ツールのデプロイメント。

このようなステップを踏むことで、組織は脆弱性管理をより効果的かつ効率的に行うことができ、脆弱性の内容や存在場所を問わず、すべての脆弱性をリアルタイムで確実に検出し、修復するという目標に近づくことができます。

クラウドワークロードの脆弱性管理のベストプラクティス

クラウドの脆弱性が致命的な脅威になる前に、すべてを確実にキャッチして修復するための簡単なコツはありません。しかし、以下のような戦略によって、クラウド関連の深刻なサイバー攻撃のリスクを軽減することができます。

CIプロセスへの脆弱性スキャニングの統合

開発ライフサイクルの早い段階で脆弱性を発見すればするほど、それが本番環境での侵害につながるリスクは低くなります。

そのため、脆弱性スキャンはCIプロセスに組み込む必要があります。ワークロードが本番環境に入るまで待ってスキャンするのではなく、開発環境やステージング環境でホスト、コンテナ、サーバーレス機能、その他のリソースをスキャンします。開発環境と本番環境で構成が変わったとしても、事前に脆弱性を監視することで、本番環境に脆弱性が入り込むのを防ぐことができます。

スキャニングの継続

もちろん、ワークロードが本番環境にデプロイされた後も、継続的な脆弱性監視を実施する必要があります。事前にいくらスキャンしても、本番ワークロードのリスクをチェックすることには代えられません。

クラウド環境の全レイヤーをスキャン

典型的なクラウドのワークロードには、複数のレイヤーの構成が含まれます。それぞれに脆弱性が存在する可能性があります。

例えば、コンテナをデプロイした場合、コンテナイメージに脆弱性がある可能性があります。脆弱性は、コンテナ・オーケストレーターで設定するRBACポリシーにも潜んでいる可能性があります。その上、クラウドプロバイダーのIAMフレームワークを使って設定したポリシーが、コンテナ化されたワークロードにリスクをもたらす可能性もあります。

そのため、クラウドワークロードのすべてのレイヤーをスキャンすることが重要です。データが存在する場所には必ず脆弱性も存在します。

脆弱性のコンテキストを得るためにCVEを使用

上述したように、一部の脆弱性は他の脆弱性よりも重大です。しかし、どれが早急な注意を要するかは必ずしも明らかではありません。

とはいえ、脆弱性アラートをできるだけ実用的なものにするためには、それぞれの重大度レベルを知る必要があります。CVE（Common Vulnerabilities and Exposures）データベースは、既知の脆弱性をリストアップし、そのリスクの大きさに応じて「スコア化」したものです。

脆弱性検出をCVEデータと組み合わせることで、クラウドワークロードのリスクについて、文脈に応じた実用的な洞察を得ることができます。

脆弱性管理に関するFAQ