誰もが効果的なパッチ管理を必要としている。脆弱性を排除し、製品のアップグレードを提供するこの重要かつ煩雑なプロセスは、規模を問わず組織の安全を守る。
パッチ適用には緊急性が求められる。攻撃者は、パッチが公開されると直ちにリバースエンジニアリングを始め、パッチ未適用のシステムを悪用しようとする。一方で組織は、既知の脆弱性を何年も放置することがある。Ponemon Instituteが侵害被害者を対象に実施した調査では、攻撃の60％が、パッチが存在するにもかかわらず適用されていなかった既知の脆弱性を悪用していた。
パッチ適用が依然として問題なのは、実行の詳細が組織を圧倒しかねないためだ。パッチ適用のベストプラクティスは規模を問わず組織に適用でき、適用までの時間を短縮できるが、実装方法はリソースによって大きく異なる。
パッチ管理のベストプラクティスには、次のものがある。
- 資産管理：何を保有し、現在どのような状態にあるかを把握する。
- リスク管理：システムの重要度と、障害や侵害が発生した場合に組織が負うリスクを把握する。
- 文書化：期待事項を設定し、状況を追跡し、明確に伝達する。
- 効果的なパッチ適用プロセス：適切なパッチを効果的かつ効率的に入手し、その有効性を確認した上で、業務への影響を最小限に抑えて展開する。
- ミスへの対処：計画、プロセス、テクノロジーは失敗する可能性があるため、復旧方法を把握しておく。
この記事では、各プラクティスについて、役割と最低限の期待事項を説明し、円滑なプロセスに役立つヒントを紹介する。概要を手早く確認するには、次を参照されたい。パッチ管理とは何か。
1. 資産管理
何にパッチを適用すべきかを知るには、まず組織が何を保有しているかを把握する必要がある。これは正式には「資産ディスカバリー」と呼ばれ、NIST Cybersecurity FrameworkやCIS Critical Security Controlsなどのフレームワークでは、強固なサイバーセキュリティプログラムを構築するための基盤とされている。
最低限の期待事項
自動化ツールを使う。クリップボードと紙、またはExcelによる棚卸しで対応できるのは、極めて小規模な組織だけだ。中規模の組織でさえ、自動化ツールを導入してネットワークをくまなく調べ、すべてのデバイス、エンドポイント、サーバー、オペレーティングシステム（OS）、アプリケーションを把握している。ただし、自動化ソフトウェアの中にはハードウェアしか追跡できないものもあるため、パッチ管理チームはツールの制限を理解しておく必要がある。
重要な資産を追跡する。資産の障害が業務を中断させたり、高額なデータ侵害を引き起こしたりする可能性があるなら、追跡対象にする。大半の組織は、すべてのエンドポイント端末（PC、ノートPC、タブレット、携帯電話など）、サーバー、クラウドリソース（コンテナ、リポジトリ、その他の社内管理インフラ）、重要なソフトウェア（会計ソフト、人事ソフトなど）、日常的に使用するネットワーク機器を追跡している。
次のレベルの実装
すべての資産を追跡する。コンピューターだけではない。大規模な組織は、IoT（防犯カメラ、Wi-Fi対応テレビなど）、運用技術（Wi-Fi制御ポンプ、温度センサーなど）、医療技術（特にワイヤレス機器）、POS（販売時点情報管理）システム、めったに使わない資産を無視するリスクを理解している。
アプリ資産を追跡する。資産追跡は、社内開発のアプリケーションにも適用される。これは別のDevSecOpsチームが管理する可能性が高いが、最高情報セキュリティ責任者は、ソフトウェア部品表（SBOM）と、アプリケーションコンポーネントの状況（バージョン、最終更新日時など）に関する報告も受けるべきだ。
例外を想定する。特別な管理や計画が必要になる場合がある。例えば病院では、患者記録データベースを停止できず、MRI装置を制御するWindows 95搭載機もアップグレードできない。こうした資産は、特別な対応や追加のセキュリティ管理を行うため、標準プロセスの対象外とする必要がある。
また、ユーザーにはパッチ適用を一時的に延期できる機能も必要だ。必須アップデートによる再起動で非常に重要なプレゼンテーションが中断された理由を、営業担当副社長に説明したいITチームはいない。一方でITチームには、アップデートを繰り返し先延ばしする従業員に対して、再起動を強制する機能も必要になる。
専門家のヒント
効果的な資産管理ツールは、ソフトウェアやファームウェアの現在のバージョンを特定できることが多い。これにより、資産の追跡や、パッチまたはより新しいバージョンが利用可能かどうかの判断が容易になる。
標準化された資産は、資産とその現在の状態を追跡するITチームの負担を軽減できる。多くの組織は、追跡・保守すべきハードウェアとソフトウェアの構成数を減らすため、PCをまとめて交換したり、ソフトウェアのインストールを制限したりしている。管理を集中化する組織や合併を進める組織では、ソフトウェアのカテゴリー（会計、人事など）を棚卸しし、更新を簡素化するため、すべてのユーザーを単一のソフトウェアパッケージに移行することも多い。
資産をコンテキストに置くため、さまざまなネットワークマップや図を使って、ネットワークセグメント、ネットワーク機器、ファイアウォール、各資産を保護するセキュリティ管理を特定する。このコンテキストは後に、未適用パッチの全体的なリスクを判断する際に役立つ。
未承認のパッチ未適用デバイスおよびBYODデバイスを隔離する。これらは組織のパッチ管理の制御対象外にある。ネットワークアクセス制御（NAC）ソリューションは、セキュリティパッチやアップデートが不足しているデバイスを検出・隔離し、ネットワークを保護できる。
こちらも参照：セキュリティ向けIT資産管理（ITAM）ツールのトップ製品
2. リスク管理
リスク管理では、資産（デバイス、データベース、アプリケーションなど）の価値と、その資産に含まれる、資産によって保護される、または資産を通過するデータの価値を組織が理解する必要がある。また、資産が故障したり侵害されたりした場合の組織への損害も、リスクに反映すべきだ。
最低限の期待事項
最も重要なものから始める。少なくとも、攻撃の標的になったり影響を受けたりする可能性が高い、最も価値の高い、業務上重要なインフラについては、リスク管理プロファイルを用意しておくべきだ。追跡可能な資産の数は、組織のリソースと情報を効果的に活用する能力に左右される。
攻撃の可能性を特性評価する。資産を守るセキュリティ管理および運用管理に基づいて評価する。評価は「高・中・低」のようなカテゴリー式でも、1・2・3・4のような数値式でもよく、資産へのパッチ適用の重要度を優先順位付けするために使うべきだ。例えば、価値が中程度で攻撃リスクが低いデータストレージサーバーは、価値も攻撃リスクも高い顧客向けアプリケーションサーバーより、パッチ適用の優先度が低くなる。
次のレベルの実装
を使うリスク管理ソフトウェアことで、追跡対象資産の最新のリスクプロファイルを管理・維持する。優れたソフトウェアなら、リスクを通貨（米ドル、ユーロなど）で表せるため、資産保護のためのセキュリティ支出を正当化しやすくなる。理想的には、リスク管理、資産管理、パッチ管理などの関連ソフトウェアが相互接続して情報を共有し、リアルタイム分析、自動優先順位付け、アラートを実現できることが望ましい。
資産をリスククラス別に分類することで、多数の資産を管理し、運用効率と効果的な優先順位付けを実現する。カテゴリー式の資産分類を使えば、資産へのリスクの割り当てを迅速化できる。ただし、この手法は大量の非重要資産（ワークステーション、スイッチなど）に最適だ。重要資産は個別に評価すべきである。
パッチ適用対象外の資産を分離する。すべての資産にパッチを適用できるわけではない。アップグレードが望ましい場合でも、実行できないことがあるため、デバイスを分離する必要がある。例えば、IoTデバイス（特に医療技術）内のハードコードされた認証情報が原因で、デバイスを別のネットワークセグメントに配置し、ホワイトリスト方式のデバイスリストなど、未承認のアクセスから保護するセキュリティ管理を適用しなければならない場合がある。
専門家のヒント
デフォルトでセキュリティを強化する。多くの組織は、ファイアウォールなどの管理の背後にあるネットワーク内部に埋もれていると考えられる資産について、脆弱性や開放ポートを放置している。しかし、ゼロトラストの理念では、組織はネットワークが侵害されていると仮定する必要がある。また、ランサムウェア攻撃が頻繁に成功していることから、この仮定は組織が望む以上に正確だといえる。
不要なプロトコルやポートを無効にして資産を強化すれば、潜在的な攻撃対象領域を縮小できる。強化されたインフラは組織全体のリスクも低下させ、一部のパッチ適用に伴う緊急性も軽減する。
コンテキストが重要だ。リスクスコアには、最新の脆弱性スキャンの結果、公開アクセスの可能性（インターネット接続、公共の場所で物理的にアクセス可能かどうかなど）、パッチ未適用の既知の脆弱性を組み込むべきだ。
レガシーテクノロジーをアップグレードし、廃止する。特に病院や産業用途で使われる一部のテクノロジーは、管理に必要なオペレーティングシステムよりも長い寿命を持つ。MedTechやOTでは、もはやパッチを適用できないWindows 95、Windows 7などの旧式OSを保守し続けなければならないケースがよくある。
こうしたシステムの保護コストは、実際の支出だけでなく、管理を実装するITセキュリティチームの人件費も含めて継続的に増加する。組織はこれらのコストを正確に評価し、旧式テクノロジーの置き換えに投資する必要がある。
同じ目的を達成できるアップグレードが可能な場合もあることを忘れてはならない。例えば、旧式のWindows 95搭載コンピューターは、Windows 95エミュレーターを備えた安全な仮想環境をホストできる、完全に更新済みのWindows 11マシンに置き換えられることが多い。
パッチを適用できない、またはまだ適用されていない資産への潜在的な攻撃経路を遮断することも、防御策の一つだ。これは仮想パッチと呼ばれるプロセスである。
法的リスクを考慮する。資産のリスクを算定する際は、攻撃者が制御権を得た場合に組織が負う法的責任を考慮する。資産にパッチが適用されておらず、裁判官、陪審、規制当局が組織に過失があると判断した場合、法的責任によって組織にどの程度の費用が生じるだろうか。
「最適なパッチ管理ソフトウェアとツール」を参照されたい。
3. 文書化
IT専門家の多くは、文書化を敬遠しているようだ。しかし文書化は、期待事項の設定、状況の追跡、パッチ管理チーム内および他の関係者との明確なコミュニケーションに役立つ。
最低限の期待事項
基本的なパッチ管理ポリシーを導入し、適用対象、パッチ適用プロセスの詳細、例外の管理方法、混乱への対処方法について基本要件を定める。数週間の交渉によって、部門間により恒久的な遺恨が生じるのを防げることもある。
パッチ適用と停止時間を計画することで、業務への影響と混乱を最小限に抑える。パッチ適用のために資産を無効化または再起動する必要がある場合に、承認プロセス、通知（社内、顧客など）、承認、その他必要な文書を明確にする。
レポートを作成することで、アップグレードまたはパッチ適用を行った資産、例外、発生した問題を追跡する。適切な文書化によって次回のパッチ適用サイクルが効率化され、ITチームの引き継ぎやインシデント対応時の混乱も防げる。
責任者を割り当てる。パッチ管理の責任を役員またはマネージャーに割り当て、重要業績評価指標にする。このプロセスは委任したり外部委託したりしてもよいが、指定された役員またはマネージャーが結果とプロセスを把握し続けるようにする。
次のレベルの実装
パッチ管理チームの定義と調整は、複雑さが増すため、エンタープライズレベルでは必須となる。パッチ適用は複数のパッチ管理チームが実施し、多様なIT環境を対象とし、複数のコンプライアンス基準への対応を求められる場合がある。より優れたパッチ管理ツールは、活動の調整、資産の分類、ワークフローの組み込み、包括的なレポート作成に役立つ。
変更管理のポリシーとレポートが必要になる。誰に通知する必要があるか、具体的な変更をどのように文書化するか、変更後にどのようなレポートを作成するかを定めるためだ。変更管理レポートは、重要資産に対する変更が承認済みのものか、未承認で悪意のある可能性がある変更かを確認するのに役立つ。
専門家のヒント
詳細に定める。パッチ管理チームのメンバーと責任を明確に指定する。必要な通知プロセスを詳細に定める。特定のテクノロジー（サーバー、クラウドプラットフォームなど）に異なるプロセスやチームが必要になる場合は、各チームと要件を具体的に記載した別紙を作成する。ただし、ITチームが利用可能なリソースや状況に応じて柔軟に調整できなくなるほど詳細にしないよう注意する。
パッチ適用プロセスを周知することで、定期的なパッチ適用プロセスを組織内で知られた予測可能なものにする。ユーザーは通常のプロセスに慣れ、通常のパッチ適用は一般に業務を妨げたり負担をかけたりするものではないと理解するようになる。また、緊急パッチがより重要なものに見えるようになり、その信頼性も高まる。
パッチ適用を重視する。デバイスのパッチ適用率、重要および非重要パッチの適用に要した時間、例外レポートなど、主要な指標の報告を役員レベルで義務付ける。
4. 効果的なパッチ適用プロセス
パッチ管理の主要な目標は、しばしば相反する。セキュリティの脆弱性を阻止するためにパッチを迅速に適用すると、業務に混乱が生じ、すでに割り当て済みのITリソースが必要になる可能性があるためだ。効果的なパッチ適用プロセスは、こうした相反する要素を管理し、適切なパッチを入手して有効性を確保し、業務への影響を最小限に抑えて展開する。
最低限の期待事項
アップデートを監視する、特に重要な資産については。多くのベンダーは、アップデートをチームに通知するメールなどの仕組みを提供している。例えば、ほぼすべての組織は、直接または間接的にMicrosoft Technical Security Notificationsを購読すべきだ。
検証済みのソースのみを使用する。パッチやアップデートのダウンロードには、検証済みのソースのみを使用する。悪意のあるハッキンググループの中には、マルウェアを埋め込んだセキュリティアップデートを提供するウェブサイトやフィッシング攻撃を作成する者もいる。
可能な限り自動化する。小規模なITチームは、日常業務に加えて大量のアップデートに対応しきれなくなる可能性がある。さまざまなベンダーが、特定の資産（Windowsマシン、macOS、サードパーティーソフトウェア、ネットワーク機器など）のパッチ適用を自動化するパッチ管理ツールを提供している。小規模企業向けに無料プランを提供するベンダーもある。特定のツールを導入する前に、対象となる資産を確認し、パッチ管理チームの負担を軽減するのか、逆に増やすのかを検証するためにツールをテストする。
一部の小規模企業は、OSに組み込まれたMicrosoftやAppleの自動パッチ管理に依存しているが、2つの大きな弱点を認識する必要がある。第1に、組織はエンドポイントの状態や、パッチが失敗したりユーザーによって遅延したりする可能性がある時期を把握できない。第2に、OSは重要な資産かもしれないが、定期的にアップデートが必要な唯一の資産というわけではない。OS中心のアップデートでは、Adobe、Google、Mozilla、Oracleなど多くのベンダーやアプリケーションに対する重要なアップデートが見落とされる。より正式で一元化されたパッチ管理ツールまたはサービスの方が優れた選択肢となる。
パッチに優先順位を付ける。資産のリスクと、適用対象となる脆弱性の重要度に基づいて優先順位を付ける。非重要パッチは、混乱を最小限に抑えるため、スケジュールに従ってアップデートする。
運用部門と調整する、または他の関係者と調整し、業務に混乱を引き起こすパッチについては、慎重なコミュニケーションと事前承認済みの手順に従う。
資産を監査して失敗したパッチを特定する、または適用したパッチによって混乱が生じたデバイスや資産を復旧する。
結果を報告する。パッチ管理ポリシー（前述）または基本的なKPIで定められたとおりに報告する。最新のソフトウェアやファームウェアのバージョンで資産リストを更新し、今後のパッチ適用プロセスをより効率的にする。
次のレベルの実装
脅威インテリジェンスや、NIST National Vulnerability Databaseなどの政府リソースを活用し、脆弱性やパッチの発表に関するベンダーの監視を強化する。これらのフィードは、積極的に悪用されている脆弱性に関する追加のコンテキストを提供し、実際に悪用されている、または特に重大な可能性のあるパッチの優先順位付けに役立つ。
ベンダーとの関係を活用する。デバイスを登録し、パッチ通知をできる限り早く受け取れるよう、営業担当者やサプライヤーと連絡を取り続ける。一部のベンダーは、脆弱性やパッチ適用に関する発表を一般公開する前に、顧客へ直接通知することがある。
パッチ管理を一元化することで、専門知識とレポートを集約し、冗長性（反復的なテスト、重複した展開を待つことなど）を排除する。一元化されたパッチ管理では、ローカルネットワークに配布ポイントを作成し、何千台ものマシンがベンダーのサイトにアクセスしてパッチをダウンロードすることによるネットワークおよびインターネットトラフィックも削減できる。
パッチの優先度、関連性、緊急性は、エンタープライズ環境では判断がより難しくなる可能性がある。多様なテクノロジー、オフィス間のバージョンの不一致、テックスタックの違いによって、リスクや脆弱性がどのように適用されるかの把握が複雑になる。
「多くのエンタープライズが、すべてにパッチを適用することはできないという事実を受け入れるのに苦労しています」と、Flexeraの製品管理ディレクターであるBob Kelly氏は説明する。「日々発生するセキュリティアップデートの絶え間ないバックログに対して、アップデートの特定、テスト、展開が難しいため、実際に展開されるパッチは10件に1件にすぎないこともあります」
リスク値、脅威インテリジェンス、CVSS 3.1と統合するパッチ管理ソリューションは、脆弱性のリスクプロファイルを自動化、または少なくとも迅速に把握するのに役立つ。また、未適用のパッチが後続のパッチに置き換えられる場合があることにも留意する。組織は、陳腐化したパッチをキューから削除する必要がある。
セキュリティ管理に関する前提を検証する。管理によって脆弱性を緩和し、緊急性を下げることはできるが、その管理は検証しなければならない。例えば、内部ネットワークからのみアクセスできるはずのデータベースサーバーに、重大な脆弱性への見落とされたアクセス経路がないことを確認する。誤った前提はリスクの把握を損ない、重要資産を想定以上に危険にさらす可能性がある。
パッチをテストする。テスト環境でパッチを検証し、他のソフトウェア、ハードウェア、ITアーキテクチャとの競合を確認する。リソースが限られている場合は、重要なパッチと重要なシステムに重点を置く。テストは通常、小規模な組織には手が届かず、リスクの高いパッチに重大な遅延を生じさせる可能性がある。
幸い、多くのパッチ管理ツールやサービスプロバイダーは、パッケージの一部としてパッチテストを提供しており、リリースから数時間以内にパッチをテストする場合もある。事前にテスト済みのパッチによって広範囲の混乱のリスクを排除できる可能性はあるが、各組織のアーキテクチャと資産は固有のものであり、通常とは異なる状況が発生する可能性があることに留意する。
特定のデバイスに限定してパッチを展開する。段階的な展開により、パッチ管理チームは結果を確認でき、大規模なパッチ展開に必要なネットワーク帯域幅を削減できる。限定的な展開は、パッチを適用した脆弱性から予期しない競合が生じた場合の被害も抑えられる。
「アプリケーションとコンピューターシステムは極めて複雑であり、新しいアップデートによって意図しない問題が生じる可能性は常にあります」と、ServiceNowでセキュリティ製品担当の副社長兼ゼネラルマネージャーを務めるLou Fiorello氏は注意を促す。「ネットワーク全体で信頼して使用する前に、管理された環境で新しいパッチを展開してください」
次のレベルの自動化ツールによって、パッチ管理の対象をネットワーク機器、サーバー、IoTデバイス、さまざまなサードパーティーソフトウェアにまで拡張できる。ただし、ツールによって管理機能や統合機能は異なるため、パッチ管理チームには複数のツールが必要になる場合があり、対象外であったり手動プロセスが必要であったりするため、手動でパッチを適用しなければならない資産が残ることもある。
冗長システムとフェイルオーバーシステムは、パッチ展開用の組み込みテスト環境と、より混乱の少ないパッチ展開を実現する。ウェブサーバーのフェイルオーバー用クローンにパッチを適用し、潜在的な競合を確認できる。アップデートが正常に完了したことを確認したら、フェイルオーバーサーバーをプライマリサーバーとして稼働させ、以前のプライマリサーバーをアップデートしてフェイルオーバーシステムとして稼働させる。クラウド、コンテナ、SaaSテクノロジーでは、稼働時間を最大化するためにこの手法がよく使われる。
パッチ適用をAppBoMにまで拡張する。アプリケーション開発を行う大規模な組織は、アプリケーションの部品表に含まれるオープンソースコードとライブラリを監視する必要がある。DevOpsまたはDevSecOpsチームが独立したパッチ管理プロセスを持っている場合もあるが、そのパッチ管理レポートは、個別のレポートまたは統合レポートとして役員に報告すべきである。
専門家のヒント
緊急性を持ってパッチを適用する。Mandiantの推定によると、開示された脆弱性の27％超が、パッチのリリースから1か月未満で悪用されている。リスクの低いシステムにはそれほど急いでパッチを適用しなくてもよいが、ゼロデイ攻撃や、その他の検出されていない脆弱性によって、リスクの低いシステムへの攻撃が、はるかに価値の高いシステムを危険にさらす可能性があることに留意する。
パッチ適用の優先度はリスクの大きさと同義ではない。一部の組織は、スコアが7以上の共通脆弱性評価システム（CVSS）脆弱性にのみパッチを適用しているが、攻撃者はこの傾向を利用する。「ハッカーはスコアが7以上の脆弱性の方が迅速に緩和される可能性が高いことを知っているため、スコアが5～7の脆弱性の悪用が増加しているのが分かります」と、Flexeraの製品管理ディレクターであるBob Kelly氏は警告する。
組織は、CVSSスコアをリスク評価および既知のエクスプロイトと組み合わせる必要がある。米国サイバーセキュリティ・インフラストラクチャセキュリティ庁（CISA）は、既知の悪用された脆弱性のリストを管理している。このリストに現在掲載されている脆弱性は約900件にすぎない。毎年20,000件を超える新たな脆弱性が特定されていることを考えれば、一見少ない数だが、それでも、この比較的少数のリストだけを対象にするには、適切な資産の検出と優先順位付けが必要になる。
リスク管理、CVSSスコア、積極的な悪用を組み合わせることで、例えば次のようなパッチ適用の優先順位を設定できる。
- 高いCVSSスコアと既知のエクスプロイトを持つ重大な脆弱性には、リリースから72時間以内にパッチを適用する。
- 既知のエクスプロイトを持つ脆弱性には、リリースから7暦日以内にパッチを適用する。
- CVSSスコアが高い既知の脆弱性には、リリースから10営業日以内にパッチを適用する。
- その他のアップデートには、リリースから30日以内にパッチを適用する。
専門知識を持つ人材を採用するか、外部委託する。社内リソースでパッチ管理の目標を達成できない場合は、専門知識を持つ人材を採用するか、外部委託する。パッチ管理は、マネージドITサービスプロバイダー（MSP）が最も広く外部委託される機能の一つであり、MSPは競争力のある価格で幅広いシステムやソフトウェアにパッチを適用できる。サービス契約を締結する前に、企業はMSPがパッチ展開の速度、業務の混乱の最小化、レポート作成について、パッチ管理の目標を満たすか上回ることを確認すべきである。
こちらも参照：
5. ミスへの対処
最善の計画、プロセス、テクノロジーであっても、失敗する可能性がある。組織は、幅広いシナリオでシステムを復旧できるよう、災害復旧の計画とプロセスを維持する必要がある。パッチ管理における災害復旧の要素は、システムとデータの復元を中心とする。
最低限の期待事項
バックアップは更新を効果的にロールバックまたは適用前の状態に戻せるよう、パッチ適用前に必ず実行すべきである。ローカルシステムのバックアップで対応できることが多いが、壊滅的なパッチ適用の失敗が発生した場合は、別の資産上にある独立したバックアップが必要になる。
次のレベルの実装
脆弱性スキャンは、適切にインストールされたことを確認し、開示されていない可能性のある問題をチェックするため、パッチ適用後に実施すべきである。一部のパッチは、セキュリティツールとの競合を引き起こしたり、新たな脆弱性を生じさせたりすることが知られている。
専門家のヒント
定期的な侵入テストを実施し、パッチ未適用システムを保護する管理が引き続き有効であることを検証すべきである。リスク評価では管理が機能し続けることを前提とするが、こうした前提はテストする必要がある。
こちらも参照：災害復旧ソリューションのベスト8
結論：パッチを適用するか、代償を払うか
パッチ管理を効果的に実行する組織は、セキュリティの向上、機能の改善、コストのかかるインシデント対応の回避など、多くのメリットを享受できる。効果的なパッチ適用ポリシーによって、時間外労働や資産復旧の追加コストを伴う、はるかに高コストな緊急IT対応を防げる。
さらに重要なのは、侵害がコンプライアンス違反を引き起こし、訴訟や規制当局による罰金につながる可能性もあることだ。多くの政府、例えばオーストラリアや米国では、脆弱性へのパッチ適用をITセキュリティの基本的な実践として挙げているため、パッチを適用しないことは過失とみなされ、重い罰則の対象となる可能性が高い。
パッチ管理は基本的な作業であるため、退屈に感じられるかもしれない。しかし、実行は複雑になる可能性があり、多くの侵害によって、多くの組織がプロセスを適切に管理するのに苦労していることが明らかになっている。ベストプラクティスを採用すれば、パッチ適用プロセスを効果的に実装でき、規模を問わずあらゆる組織が取り入れるべきだ。
次の記事：脆弱性管理ツールのトップ製品
この記事はもともとDrew Robbが2022年10月21日に執筆した。2023年2月24日にChad Kimeが更新した。