脆弱性管理とは何か？

脆弱性管理とは、攻撃者がセキュリティ上の弱点を悪用する前に、インフラストラクチャ全体にわたる脆弱性を特定、分類、優先順位付け、および是正するための継続的なプロセスです。組織で少数のデバイスを超えて運用している場合、すでに何らかの脆弱性が存在しています。重要なのは、その存在を把握しているか、そして対処計画があるかどうかです。

ITおよびセキュリティチームにとって脆弱性管理が重要な理由

パッチが適用されていないCVE、設定ミスのあるサービス、あるいは古いOSのバージョンは、いずれも潜在的な侵入経路となります。攻撃者は、公開からわずか数時間以内に、既知の脆弱性を体系的にスキャンします。脆弱性管理とは、その攻撃の機会を封じ込める運用上の取り組みです。

その重要性は明白です。「Verizonデータ侵害調査レポート」によると、確認されたデータ侵害事例において、脆弱性の悪用は一貫して主要な初期侵入手法の一つとなっています。成熟した脆弱性管理プログラムは、インシデント発生後だけでなく、継続的に組織の攻撃対象領域を縮小します。

macOS、iOS、iPadOS、その他のプラットフォームを含む多様な環境を管理するITチームにとって、その複雑さは急速に増大します。各プラットフォームには、独自のパッチ適用サイクル、脆弱性開示プロセス、およびツール要件が存在します。

脆弱性管理プログラムの中核となる要素

脆弱性管理は、単発のプロジェクトではなく、継続的なサイクルです。その中核となる要素は以下の通りです：

1. アセットインベントリ

見えないものは管理できません。完全かつ正確な資産インベントリは、あらゆる脆弱性管理プログラムの基盤となります。これには、ハードウェア、ソフトウェア、OSのバージョン、ファームウェアが含まれます。インベントリに不備があると、セキュリティ態勢における死角に直結します。ハードウェアのインベントリ管理は、オプションの手順ではなく、必須の前提条件です。

2. 脆弱性スキャン

スキャンツールは、システム構成やソフトウェアのバージョンをNational Vulnerability Database（NVD）などの脆弱性データベースと照合することで、エンドポイント、サーバー、ネットワークデバイスに既知の脆弱性がないかを調査します。スキャンには、認証型（エージェントベースまたは認証情報を使用）と非認証型があります。 認証が必要なスキャンは、インストールされているパッケージや設定を直接検査できるため、はるかに正確な結果が得られます。

スキャンをワークフローにどのように組み込むかについてさらに詳しく知りたい場合は、『脆弱性スキャン：実務者向けガイド』を参照してください。

3. 脆弱性の評価と分類

脆弱性が特定されたら、それらを分類する必要があります。共通脆弱性評価システム（CVSS）は、0 から 10 までの標準化された深刻度スコアを提供します。しかし、優先順位付けを行うには、CVSS の生スコアだけでは不十分です。 インターネットに公開されていないソフトウェアにおける「重大（Critical）」レベルの脆弱性と、外部からアクセス可能なサービスにおける同じスコアの脆弱性では、リスクの性質が異なります。

分類にあたっては、以下の点を考慮する必要があります：

• CVSSベーススコア（脆弱性の本質的な深刻度）
• 悪用可能性：公開されたエクスプロイトコードが存在するかどうか
• 資産の重要度：影響を受けるシステムが事業運営にとってどれほど重要か
• 露出度：システムがインターネットに公開されているか、セグメント化されたネットワーク上にあるか、あるいはエアギャップが施されているか
• CISA KEVステータス：その脆弱性がCISAの「既知の悪用済み脆弱性（Known Exploited Vulnerabilities）」カタログに掲載されているか否か

4. 優先順位付け

優先順位付けは、ほとんどのプログラムが成功するか、あるいは行き詰まるかの分かれ目となる段階です。セキュリティチームは、限られた修正リソースの中で、日常的に数千件もの未修正の脆弱性に直面しています。すべてを即座に修正しようとしても、運用上現実的ではありません。リスクベースのアプローチでは、悪用される可能性が最も高く、実際の損害を引き起こす可能性が最も高い脆弱性にリソースを集中させます。

CVEの優先順位付けと修正は、専門的な分野です。これを適切に実行するチームは、脅威インテリジェンスフィード、エクスプロイト予測スコアリングシステム（EPSS）、および資産のコンテキストを活用し、正当化可能な優先順位付けの決定を下します。

5. 修正

是正措置にはいくつかの形態があります：

• パッチ適用：ベンダーが提供する更新プログラムを適用して脆弱性を排除する
• 設定の強化：設定を変更して脆弱な状態を解消すること（例：不要なサービスの無効化）
• 代替対策：パッチ適用が直ちに不可能な場合、ネットワークのセグメンテーションや監視の強化といったリスク軽減策を追加すること
• 受容：リスクが検討され、受容されたことを、明確な検討日を明記して正式に文書化すること

効果的な是正措置には、セキュリティ部門、IT運用部門、およびアプリケーション所有者間の連携が必要です。深刻度に応じたSLA（サービスレベル契約）を設定すること（例：重大な脆弱性は24時間以内にパッチ適用、高深刻度のものは7日以内に適用）により、責任の所在が明確になります。

6. 検証と報告

是正措置の実施後、影響を受けるシステムを再スキャンして、修正が正しく適用されたことを検証します。報告は一連のプロセスを完結させます。これにより、内部SLAへの準拠が実証され、監査要件が満たされ、経営陣はプログラムの健全性を長期的に把握できるようになります。

脆弱性管理とパッチ管理

これらの用語はしばしば同義語として使われますが、同一ではありません。パッチ管理は脆弱性管理の一分野です。パッチ適用はソフトウェアの更新を適用することで脆弱性に対処しますが、多くの脆弱性はパッチだけでは解決できません。設定ミス、安全でないデフォルト設定、およびサポート終了（EOL）ソフトウェアには、パッチ適用以外の是正措置が必要です。

成熟した脆弱性管理プログラムは、パッチ管理を取り入れるだけでなく、構成管理、ソフトウェアライフサイクルのガバナンス、および代替的統制も網羅しています。

一般的なフレームワークと標準

脆弱性管理プログラムの枠組みを提供する業界標準として、以下のものがあります。

• NIST SP 800-40（「エンタープライズ・パッチ管理計画ガイド」）は、パッチ管理機能の構築と評価に関する実践的な指針を提供しています
• CIS Controls v8、コントロール7（継続的な脆弱性管理）は、自動スキャン、是正措置の追跡、リスクに基づく優先順位付けなどの具体的な保護策を定義しています
• ISO/IEC 27001、附属書A.12.6は、より広範なISMSの一部として技術的な脆弱性管理について規定している
• PCI DSS 要件 6 は、カード保有者データを保存、処理、または送信するシステムについて、脆弱性の特定とパッチ適用を義務付けています

プログラムをこれらのフレームワークのいずれかに整合させることで、正当性のある基準が得られ、監査時のコンプライアンス報告が簡素化されます。

Appleデバイスにおける脆弱性管理

Appleのエンドポイントには、特有の考慮事項があります。macOS、iOS、およびiPadOSには、それぞれ独自の脆弱性開示スケジュールとパッチ適用メカニズムがあります。Appleはセキュリティアップデートのページで各リリースのセキュリティコンテンツを公開していますが、最新の状態を維持するには、ユーザーへの通知だけでなく、MDMによる強制適用が必要です。

Apple特有の一般的な課題には、次のようなものがあります：

• OSアップデートの断片化：MDMによる強制がない場合、特にメジャーリリース後は、管理対象デバイスのOSバージョンに大きなばらつきが生じます
• サードパーティ製アプリケーションの脆弱性：ブラウザ、生産性向上ツール、開発者向けユーティリティは、Appleのパッチ提供サイクルとは独立して脆弱性を引き起こす
• BYOD（個人所有端末の業務利用）シナリオ：企業環境における個人所有端末は、可視性と是正措置の権限の両方を複雑化させる。BYODデバイスの管理には、異なる強制措置の姿勢が必要となる
• ツールのサイロ化：多くの脆弱性スキャナーはWindows中心の環境向けに構築されており、macOSでは不完全な結果しか得られない

主にApple製ハードウェアを運用する組織にとって、ここがAppleデバイスの管理と脆弱性管理が直接交差するポイントです。

Iruの脆弱性管理へのアプローチ

IruはAppleデバイス群向けに特別に構築されており、つまり、その脆弱性管理機能は、Windows優先のアーキテクチャから流用されたものではなく、Appleデバイスの実際の動作に基づいて設計されています。

具体的には、次のような形になります：

• 継続的なOSおよびソフトウェアのインベントリ管理：Iruは、手動での照会を必要とせずに、各デバイスのOSバージョン、インストール済みアプリケーション、パッチ適用状況をリアルタイムで把握します。この情報は、脆弱性評価ワークフローに直接反映されます。
• 自動化された是正ワークフロー：Appleがセキュリティアップデートをリリースすると、IruはMDMネイティブなメカニズムを通じて、設定可能な延期期間やエンドユーザーへの期限設定を適用し、全デバイスにそのアップデートを強制適用できます。
• カスタムスクリプトと設定の強制適用：パッチではなく設定変更を必要とする脆弱性（安全でないプロトコルの無効化、FileVaultの強制適用、SIPステータスの管理など）に対して、Iruの事前構築済みスクリプトおよびコンプライアンスパラメータのライブラリを活用することで、カスタムツールを必要とせずに是正を迅速化します。
• エンドポイント検出および対応（EDR）との統合：Iruは主要なEDRソリューションと統合されており、脆弱性のコンテキストがアクティブな脅威監視に情報を提供し、その逆も同様に行われます。
• コンプライアンスレポート：Iruのコンプライアンスビューは、デバイスの状態をCISベンチマークやNISTコントロールなどのフレームワークにマッピングし、セキュリティチームに手作業によるスプレッドシート作成を必要としない、監査対応済みのドキュメントを提供します。

ここで重要なのが、統合プラットフォームモデルです。MDMとセキュリティツールが同じデバイスデータを共有することで、あるツールではパッチが「展開済み」と表示されているのに、別のツールでは「未検証」と表示されるといった、データ整合性の不一致を解消できます。

拡張性のある脆弱性管理プログラムの構築

脆弱性管理は、一度導入すれば放置できるようなツールではありません。一貫したスキャン範囲の確保、是正措置の責任の明確化、定期的なプログラムの見直しといった、運用上の規律が求められます。

プログラムを開始する場合、または既存のプログラムを改善する場合は、以下の手順に従ってください：

1.まず資産の網羅性から着手します。インベントリが不完全な場合は、それを最初に修正してください。資産の80％しかカバーしていないスキャナーでは、カバー率について誤った認識を抱くことになります。

2.深刻度ごとのSLAを明確に定義します。「重大」、「高」、「中」、「低」の各発見項目について、想定される是正期間を文書化してください。経営陣の承認を得てください。

3.変更管理プロセスと統合します。システムの再起動や設定変更を必要とするパッチについては、予期せぬダウンタイムを回避するために運用チームとの調整が必要です。

4.可能な限り自動化しましょう。大規模な手動パッチ適用は持続可能ではありません。MDMによるOS更新の強制やアプリケーションの自動展開により、遅延の原因となる要因を根本から排除できます。

5.単一時点のスナップショットだけでなく、傾向を報告してください。時間の経過とともに脆弱性の数が減少し、SLAの遵守率が向上している状況は、単発の監査レポートよりもはるかに説得力があります。

IruがAppleデバイス群全体で脆弱性管理をどのように行っているかをご覧になりたい場合は、デモをご依頼ください。お客様の具体的な環境に合わせて、ワークフローをご案内いたします。