パッチ管理は、IT資産に新しいパッチを適用するための一元管理されるプロセスを作成します。 これらのパッチにより、セキュリティーが強化され、パフォーマンスや生産性が向上します。

セキュリティー・プログラムの更新

セキュリティー・パッチは多くの場合、特定の脆弱性を修正することによって、特定のセキュリティー・リスクに対処します。

ハッカーはパッチが適用されていない資産をターゲットにすることが多いため、セキュリティー更新プログラムを適用しないことにより、セキュリティー侵害にさらされる可能性があります。 例えば、2017年のWannaCryランサムウェアは、パッチが発行されていたMicrosoft Windowsの脆弱性を悪用して拡散しました。サイバー犯罪者は、管理者がパッチの適用を怠ったネットワークを攻撃し、150カ国で実に2万台以上のコンピューターに感染しました。

機能の更新

アプリケーションやデバイスに新機能をもたらすパッチもあります。 これらの更新プログラムにより、資産のパフォーマンスとユーザーの生産性が向上します。

バグの修正

バグの修正は、ハードウェアやソフトウェアの小さな問題に対処するものです。 通常、これらの問題はセキュリティー上に大きな問題を引き起こすことはありませんが、資産のパフォーマンスに影響を与えます。

ダウンタイムの最小化

ほとんどの企業では、パッチ・プログラムがリリースされた時点で、その都度ダウンロードし、すべての資産に適用していくことは非現実的です。 これは、パッチ適用時にシステムにダウンタイムが発生するためです。 パッチを適用するには、ユーザーは作業を停止し、ログアウトし、主要なシステムを再起動する必要があります。

文書化されたパッチ管理プロセスにより、組織は重要なアップデートに優先順位を付けることができます。 企業は、従業員のワークフローへの中断を最小限に抑えながら、これらのパッチ適用からメリットを得ることができます。

法規制への準拠

一般データ保護規則（GDPR）、医療保険の相互運用性と説明責任に関する法律（HIPAA法）、カード情報セキュリティの国際統一基準であるPCI-DSSなどの規制の下、企業は特定のサイバーセキュリティー慣行に従う必要があります。パッチ管理を行うことは、組織が重要なシステムをこれらの要件に準拠させるのに役立ちます。

ほとんどの企業は、パッチ管理を継続的なライフサイクルとみなしています。 これは、ベンダーが新しいパッチを定期的にリリースしているためです。 さらに、IT環境の変化に伴い、企業のパッチ適用ニーズが今後変化する可能性もあります。

管理者とエンドユーザーがライフサイクルを通じて従うべきパッチ管理のベスト・プラクティスを概説するため、企業は文書化されたパッチ管理ポリシーを作成しています。

パッチ管理ライフサイクルは次の段階を経ます。

1. 資産管理

ITリソースをモニタリングするために、ITチームとセキュリティー・チームは、外部のアプリケーション、オペレーティング・システム、モバイル・デバイス、リモートおよびオンプレミスのエンドポイントなどのネットワーク資産のインベントリーを作成します。

ITチームは、従業員が使用できるハードウェアとソフトウェアのバージョンを指定することもできます。 このように資産を標準化することにより、ネットワーク上で管理すべき資産のタイプが統一化され、パッチ適用プロセスが簡素化されます。 また、従業員が安全でない、または老朽化した、あるいは互換性のないアプリケーションやデバイスを使用することを防ぐこともできます。

2. パッチ・モニタリング

ITチームとセキュリティー・チームが網羅的な資産インベントリーを入手することで、利用可能なパッチをモニタリングし、資産のパッチ・ステータスを追跡し、パッチが欠落している資産を特定することができます。

3. パッチの優先順位付け

特にセキュリティー・パッチに関しては、他のパッチよりも重要なパッチがあります。 米調査会社のGartner社によると、2021年には19,093件の新しい脆弱性が報告されましたが、サイバー犯罪者が悪用したのはそのうち1,554件にすぎません（ibm.com外部へのリンク）。

ITチームとセキュリティー・チームは、脅威インテリジェンスのフィードなどのリソースを使用して、システム内で最も重大な脆弱性を正確に特定できます。 これらの脆弱性に対するパッチは、それほど重要でないアップデートよりも優先されます。

ダウンタイムを削減するためのパッチ管理ポリシーでは、優先順位付けが重要になります。重要なパッチからリリースすることで、ITチームとセキュリティー・チームは ネットワークを保護しながら、リソースがパッチ適用のためにオフラインとなる時間を短縮できます。

4. パッチ・テスト

新しいパッチは問題を引き起こし、統合を解除し、修正したかった脆弱性に対処できないことがあります。しかも、例外的とはいえ、ハッカーがパッチを乗っ取ることすらあります。例えば、サイバー犯罪者は、Kaseya社のVSAプラットフォーム（ibm.com外部へのリンク）の脆弱性を悪用し 、正規のソフトウェア・アップデートを装ったランサムウェアを拡散しました。

パッチをインストールする前にテストすることで、ITチームとセキュリティー・チームは、ネットワーク全体に影響が及ぶ前にこれらの問題を検知して修正しようとしています。

5. パッチのデプロイメント

「パッチのデプロイメント」とは、パッチをいつ、どのようにデプロイするかということです。

パッチの適用プロセスは通常、従業員がほとんどまたはまったく働いていない時間に計画されます。 ベンダーのパッチ・リリースもパッチ適用スケジュールに影響を与える可能性があります。 例えば、マイクロソフトは通常、火曜日にパッチをリリースします。この日は、一部のITプロフェッショナルの間では「パッチ・チューズデー（パッチがリリースされる火曜日）」と呼ばれています。

ITチームとセキュリティー・チームは、ネットワーク全体に一度にパッチを適用するのではなく、資産ごとにパッチを適用する場合があります。 そうすることで、一部の従業員が作業を続けながら、他の従業員がパッチ適用のためにログオフすることができます。 グループごとにパッチを適用することは、問題がネットワーク全体に及ぶ前に問題を検知する最後のチャンスにもなります。

パッチのデプロイメントには、パッチ適用後に資産を監視し、予期しない問題を引き起こす変更を変更前の状態に戻す計画も含まれる場合があります。

6. パッチのドキュメント

パッチのコンプライアンスを確保するために、ITチームとセキュリティー・チームは、テスト結果、デプロイメントの結果、まだパッチが必要な資産など、パッチ適用プロセスを文書化する必要があります。 こうした記録により資産インベントリーが常に最新の状態に保たれ、監査の際にサイバーセキュリティー規制への準拠を証明できます。

パッチ管理は複雑なライフサイクルであるため、組織はパッチ適用を合理化する方法を模索することがよくあります。プロセスを完全にマネージド・サービス・プロバイダー（MSP）に委託する企業もあります。社内でパッチ適用を扱う企業は、パッチ管理ソフトウェアを使用してプロセスの多くを自動化しています。

ほとんどのパッチ管理ソフトウェアは、Windows、Mac、Linuxなどの一般的なOSに対応しています。こうしたソフトウェアは、資産に欠落しているパッチや利用可能なパッチがないかをモニタリングします。 パッチが利用可能な場合、パッチ管理ソリューションはそれらをリアルタイムまたは設定されたスケジュールで自動的に適用します。 多くのソリューションは処理すべき工程数を少なくするため、パッチを一元管理サーバーにダウンロードし、そこからネットワーク資産に配布します。 一部のパッチ管理ソフトウェアでは、テスト、文書化、パッチが誤動作した場合、システムを適用前の状態に戻す「ロールバック」を自動化できます。

パッチ管理ツールは単独のソフトウェアを購入することもできますが、多くの場合、大規模なサイバーセキュリティー・ソリューションの一部として提供されます。 多くの脆弱性管理および攻撃対象領域管理ソリューションは、資産インベントリーや自動パッチ・デプロイメントなどのパッチ管理機能を提供します。 多くのEDR（エンドポイントの検知と対応）ソリューションでは、パッチを自動的にインストールすることもできます。 一部の組織では、統合エンドポイント管理（UEM）プラットフォームを使用して、オンプレミスおよびリモート・デバイスにパッチを適用しています。

自動パッチ管理ソリューションにより、組織はすべてのパッチを手動でモニタリング、承認、適用する必要がなくなりました。 これにより、ユーザーがパッチをインストールする都合の良い時間を見つけられずに適用されないままになる重要なパッチの数を減らすことができます。