あらゆるIT環境とサイバーセキュリティ戦略には脆弱性が存在します。被害や損失を避けるには、攻撃者に悪用される前に、組織が脆弱性を見つけて排除する必要があります。
脆弱性の一部はベンダーが発見して修正し、自社製品向けのパッチやアップデートを提供します。
一方、パッチを適用できない脆弱性には、IT部門、サイバーセキュリティ部門、アプリ開発者の連携が必要です。こうした連携により、追加のリソースで、悪用のリスクを軽減または低減し、露出した脆弱性を保護します。
次の脆弱性およびパッチ管理の各段階を定期的かつ効率的に実施することで、あらゆる規模の組織を強力に保護できます：
自分で対応したくない場合はこちらもご覧ください：
脆弱性を見つける方法
脆弱性の中には公表されるものもありますが、テストを通じて見つけなければならないものもあります。ただし、すべてのIT・サイバーセキュリティチームは、脆弱性の検出と管理に専念する担当者とプロセスを明確に定めるべきです。
まず優先すべきは、公表された脆弱性を収集することです。ベンダーはエクスプロイトを公表すると同時に、通常はその脆弱性に対処するパッチや緩和策も提供します。
攻撃者は迅速に行動するため、脆弱性検出チームはニュースフィードやベンダーのWebサイトを監視し、速やかに対応する必要があります。Mandiantの調査では、次のことが明らかになっています。
- パッチ発行後にエクスプロイトが発生した割合は42%だった
- パッチの提供開始日から1週間以内にエクスプロイトが発生した割合は12%だった
- パッチ提供開始後1カ月以内、ただし最初の1週間を過ぎてからエクスプロイトが発生した割合は15%だった
もちろん、IT環境に存在する脆弱性はこれだけではありません。古いソフトウェアやパッチ未適用のソフトウェアは、Crowdstrikeが指摘する脆弱性の主な7種類の1つにすぎません。その他は次のとおりです。
- 設定ミス – 不適切なセキュリティ設定により、データやシステムが露出する
- 保護されていないアプリケーションプログラミングインターフェース（API）– 攻撃者は保護されていないAPIを利用してデータを取得したり、コードを投入したり、その他の攻撃を実行したりできる
- ゼロデイ脆弱性 – 検出が極めて難しく、通常は研究者によって発見される
- 脆弱または窃取されたユーザー認証情報 – ユーザーがフィッシング攻撃、再利用された認証情報、あるいはデータ侵害によって侵害されると、攻撃者は正規ユーザーの身元を装ってアクセスできる
- 過度に広範なアクセス制御 – ユーザーに、業務に必要な範囲を超えたリソースへのアクセス権が付与されることが多い
- クラウドコンピューティングの共有責任モデルに対する誤解 – 誤解によってセキュリティスタックに攻撃者が悪用できる隙間が生じる
脆弱性スキャンツールを使用したり、脆弱性管理ベンダーに業務を委託したりすることは、組織内の大半の脆弱性を特定するための有効な出発点になります。ただし、脆弱性管理チームは、保有資産と、利用している脆弱性管理・検出ソリューションの限界を明確に把握する必要があります。
例えば、広く利用されているHeimdal Securityは、MicrosoftおよびLinuxシステム向けに、120種類を超えるサードパーティーアプリケーションと、サイレントインストールコマンドに対応するあらゆるアプリケーションのパッチ管理と資産管理を提供します。多くの煩雑な作業を解消できる一方で、設定ミスのスキャンには対応しておらず、ITインフラ（ルーター、ファイアウォールなど）、ファームウェア（ハードドライブ、ドライバーなど）、IoT（モノのインターネット）デバイス（防犯カメラ、心拍モニターなど）、Kubernetesインスタンス、Webサイト、アプリケーションなど、その他の重要なアップデートには対応できない場合があります。
資産や接続をくまなくスキャンして脆弱性を見つけるには、追加のベンダー、コンサルタント、またはITリソースが必要になる場合があります。ペネトレーションテストや侵害・攻撃シミュレーションを利用して、脆弱性を能動的に特定することもできます。
パッチを見つける方法
ベンダーは脆弱性に対処するパッチやアップデートを公開するため、脆弱性を最初に公表することが多くあります。ただし、ニュースサイト、コミュニティーフォーラム、メールアラートも、パッチに関する情報を入手し、見つけるための有効な情報源です。
ただし、脆弱性管理チームは、パッチやアップデートが正規のものであることを確認する必要があります。攻撃者は常に、マルウェアが仕込まれたソフトウェアアップデートを含むフィッシングメールを送り付けたり、偽のWebサイトを公開したり、偽のブラウザーアラートを表示したりしています。
脆弱性とパッチの優先順位付け
複数のパッチが同時に利用可能になったり、組織が緩和すべき複数の脆弱性を発見したりすることがあります。限られたリソースで、組織は修正の優先順位をどのように決めるべきでしょうか。
共通脆弱性評価システム（CVSS）によるパッチ適用対象の脆弱性のスコアは、その脆弱性がもたらす潜在的な危険性を判断するために広く使われている基準です。CVSSは脆弱性に1から10までのスコアを割り当てます。CVSSバージョン3.0の評価は次のように対応します。
- 9.0～10.0 = 重大
- 7.0～8.9 = 高
- 4.0～6.9 = 中
- 0.1～3.9 = 低
- 0.0 = なし（情報提供）
これらのスコアは、攻撃者がシステムに及ぼし得る影響の大きさや、脆弱性の悪用に必要な攻撃者側の労力の少なさを示すものです。
こうしたスコアは緊急性の目安にはなりますが、悪用される可能性や組織にとっての価値は反映しません。真の優先順位を決めるには、組織は次の要素も考慮する必要があります。
- 組織にとっての資産の価値。これは多くの場合、リスク登録簿またはリスク管理プログラムを通じて測定・追跡されます。
- 組織の状況における悪用の可能性
パッチ適用の優先順位付け例
次のような設備を持つ病院を考えてみましょう。
- 次のルーターがあります。
- リモートコード実行の脆弱性があり、評価は9.4
- 画像診断部門と機器を内部ネットワーク（高価値システム）に接続している
- 内部ネットワークは独自のネットワークセグメントに分離され、インターネット接続は許可されていない。これは、ローカルファイアウォールのポート設定と、ネットワークセグメント内のデバイスにインストールするソフトウェアの厳格な管理によって実施されている
- 一般的なPCモデルがあります。
- 認証バイパスのバグがファームウェアに存在し、評価は7.2。マシンへの物理アクセスが必要なため（ただしサインオンパスワードは回避できる）
- すべての役員用PCと看護端末に存在する（中価値の資産）
- 特別なITアーキテクチャやセキュリティ対策は導入されていない
- Wi-Fi機能を備えたルーターがあります。
- Wi-Fiが有効になっており、Wired Equivalent Privacy（WEP）プロトコルの暗号化を受け入れる
- これは最も脆弱なWi-Fi暗号化プロトコルであり、有効にすべきではない
- これは設定の脆弱性であるため、CVSS評価はない
- 集中治療室に設置され、遠隔監視が必要になる可能性のある各種心拍モニター、呼吸装置、その他の機器をネットワークに接続するために使用されている
- 病棟内の機器はWi-Fi接続を使用しておらず、すべて有線接続である
これらの脆弱性をCVSSの数値だけで厳密に評価すると、画像診断センターのルーターを最初に対処すべきことになります。しかし、ネットワークが分離されているため、ルーターの欠陥が悪用される可能性は、次のケースと比べて非常に低いと考えられます。
- PCの台数が多く、一部の機器が半公共的な場所で使われる可能性もあるため、物理的に簡単にアクセスできる大量のPC
- スキルや労力をほとんど必要とせず、電波の届く範囲にいる誰もがアクセスできるWi-Fi接続
次に、組織にとっての価値を考慮する必要があります。多数のPCがさまざまな形で影響を受ける可能性がある一方、物理アクセスには発覚のリスクがあり、初期被害は金銭的利益をすぐに得るためのデータ侵害にとどまる可能性があります。
一方、病院の中核的な役割は患者の健康を守ることです。そのため、重篤な状態にある患者にアクセスできる潜在的な脅威は、深刻な合併症や死亡につながる可能性があります。最も高い価値と最大のリスクが組み合わさるのは、CVSS評価がまったくない脆弱性です。
脆弱性にパッチを適用する方法
多くの組織は、パッチ管理ソフトウェアとツールやマネージドITサービスプロバイダー（MSP）を利用してパッチ管理を自動化しています。一部のソフトウェアベンダー（Microsoft、Firefoxなど）も、自動パッチ適用と自動アップデートに対応しています。
ITチームの負担を軽減し、パッチや脆弱性への対処にかかる時間を短縮できる場合は、常に自動パッチ適用が推奨されます。ただし、インフラ、ファームウェア、またはあまり一般的でないソフトウェア向けのパッチなどは、自動化できないことがあります。
さらに、一部の重要な業務は影響を受けずに中断できないため、計画停止時間を設定する必要があります。手動でパッチを適用する組織では、基本的な手順は自動化されたプロセスに倣いますが、各段階でより正式な確認を行います。手動でパッチを適用するためのパッチ管理のベストプラクティスには、次のものがあります。
- パッチのテスト：大規模な組織ではデジタルツインを利用して、パッチやアップデートが他の業務システムに影響しないことを検証できます。
- パッチの展開：ほとんどのソフトウェア、ファームウェア、アプライアンスはパッチ更新の自動化に対応していますが、業務への影響を最小限に抑えるため、再起動やダウンタイムの調整が必要になる場合があります。
- インストールの検証：レポート、ログ、追加の脆弱性テストによって、パッチが公開された脆弱性のセキュリティ上の脅威を効果的に取り除いたことを確認できます。
サービスプロバイダーに外部委託する場合やパッチ適用ツールを使用する場合、一部のパッチ適用は自動的に実行されるため、それらのデバイスについてはパッチ適用の優先順位付けが必要ないことがあります。パッチ適用の優先順位は、次のようなアップデートやパッチの優先順位を決めるために使用します。
- メンテナンスのためにリソースの停止が必要なもの
- リソースに対する他のパッチやアップデートと競合するもの、または技術的に競合するもの
- 他のシステムや業務プロセスに問題を引き起こすもの
実行されていないパッチ、アップデート、脆弱性の緩和策は、優先順位に基づいて追跡・修正する必要があります。このパッチ適用待ち行列には、古く緊急性の低いパッチが含まれている場合があります。そのため、同じ資産向けに新しいパッチがリリースされたら、キュー内の古いパッチと置き換える必要があります。置き換え後のパッチには古いパッチと同じ優先順位を設定することも、IT部門の判断で優先順位を付け直すこともできます。
パッチを適用できない脆弱性の緩和方法
パッチを適用できない脆弱性は、緩和策の対象として検討する必要があります。緩和策の候補は、すでに数の多い脆弱性の種類を上回るほど存在しますが、脆弱性の分類に基づいて緩和策の種類を検討できます。
例えば、具体的な分類と緩和策または修正方法を考えてみましょう。
- 設定ミス – 検出後、設定ミスはデバイスの設定を変更するだけで簡単に修正できることがよくあります。
- 保護されていないAPI – 検出後、APIはツールやセキュリティ設定の調整、Webアプリケーションファイアウォールなどによって保護できます。
- ゼロデイ脆弱性 – ゼロデイ脆弱性は通常、一般的な組織では検出されないため、具体的な緩和策の対象にもなりません。その代わりに、組織はセキュリティを多層化し、いずれか1つの層にある未検出のゼロデイ脆弱性が及ぼす影響を限定する必要があります。
- 脆弱な、または盗まれたユーザー認証情報 – 組織は通常、次の方法で脆弱な、または盗まれたユーザー認証情報から保護します。
- 必要なパスワードの複雑さを高める
- 多要素認証（MFA）を有効にする
- パスワードクラッキングを内部で実施し、変更が必要なパスワードを特定する
- パスワードマネージャーを使用して、ユーザーが複雑で固有のパスワードを維持できるよう支援する
- 過度に広範なアクセス制御 – 組織は次の方法でアクセス制御と最小権限アクセスの原則を改善します。
- クラウドコンピューティングの共有責任モデルに対する誤解 – 組織は設定を調整し、クラウドセキュリティツールを追加するか、サービスプロバイダーに依頼してセキュリティ上のギャップを解消します。
- 古い資産やサポート終了の資産、および業務を過度に中断させるパッチ：これらのデバイスは修正できないため、組織は次の対応を行います。
- 資産をサポート対象の同等品に置き換える
- 次のような追加のセキュリティ対策を講じて資産を保護する
- パッチを適用できないWebアプリケーションにWebアプリケーションファイアウォール（WAF）を追加する
- マイクロセグメンテーションを使用して、古いオペレーティングシステムを実行しているPC（通常は運用技術（OT）の管理に使用）を分離する
- ポートノッキング、またはホワイトリスト登録済みIPアドレスを、古いファイル転送プロトコル（FTP）サービスをホストするサーバーに追加する
結論
ITシステムやサイバーセキュリティ戦略に、絶対に安全なものはありません。組織のリソースを踏まえて合理的なセキュリティを導入し、サイバーセキュリティリスクを許容可能なレベルに抑えることが目標となります。
幸い、自動化、ツール、外部委託を組み合わせることで、多数の脆弱性であっても妥当なリソースで対処できます。組織の資産を保護するには攻撃者の先手を取ることが重要であるため、各組織は自社に適した脆弱性管理システムを見つける必要があります。
より詳しい情報については、次もご覧ください。