ベンダーがパッチを公開すると、攻撃者は、そのパッチで修正される脆弱性に関する手がかりを得てしまう可能性があります。 パッチのリリースから、各エンドポイントでのインストールが確認されるまでの間に生じるそのギャップこそが、リスクが蓄積される場所なのです。
このガイドでは、パッチの技術的な仕組み、実際に遭遇するさまざまな種類のパッチ、そして検証が展開と同じくらい重要である理由について解説します。
ソフトウェアのパッチが実際に何を行うのか
ソフトウェアパッチとは、既存のプログラムやオペレーティングシステムを変更するための小さなコードのことです。 パッチは、バグの修正、セキュリティ上の脆弱性への対応、あるいはパフォーマンスの向上を行うものです。 ソフトウェアの全面的な更新や新バージョンのリリースとは異なり、パッチはアプリケーション全体を置き換えることなく、特定の問題に対処するものです。
ベンダーが不具合を発見した場合、それがクラッシュを引き起こすコーディングミスであれ、攻撃者が悪用しうる既知の脆弱性の1つであれ、修正するためのパッチを開発します。 このパッチは、対象システム上の特定のファイル、レジストリエントリ、または構成設定を上書きまたは変更します。 まるで、エンジン全体を取り替えるのではなく、機械の中の故障した部品を1つだけ交換するようなものだと考えてみてください。
パッチは、ベンダーのウェブサイト、Windows Updateなどの自動更新、アプリストア、あるいは企業のパッチ管理ツールを通じて配布されます。 パッチを適用すると、問題の原因となっていた基盤となるコードを変更することで、ソフトウェアの動作が変更されます。
パッチが他の更新タイプと異なる点は、以下の通りです：
- 適用範囲： のパッチは、機能に広範な変更を加えるのではなく、特定の限定的な問題に対処するものです
- サイズ： 通常は小さく、多くの場合、わずか数メガバイト程度です
- 緊急度： 特にセキュリティパッチは、攻撃者がすでに把握している可能性のある脆弱性を修正するものであるため、時間的制約が厳しいものです
ベンダーがパッチを公開すると、まだそのパッチを適用していない組織にとっては、脆弱性にさらされる期間が始まります。 ハッカーや、組織的なサイバー犯罪者を含むその他の攻撃者は、パッチのリリースを頻繁に監視しています。なぜなら、パッチのリリースからは、脆弱性がどこにあるかについて重要な手がかりが得られるからです。 だからこそ、パッチの公開から正常なインストールが確認されるまでの時間が、これほど重要になるのです。
[四半期ごとのスキャンと手動でのパッチ適用サイクルで運用されていますか？ 【継続的な露出管理が実際にどのように行われるかをご紹介します】
基本について理解できたところで、次の疑問は、「どのような種類のパッチがあり、それらはどのように異なるのか」ということです。
ソフトウェアパッチの種類に関する詳細な分類
すべてのソフトウェアパッチが、同じ緊急性やリスクプロファイルを持つわけではありません。 これらの違いを理解しておけば、導入の順序を、到着順ではなく、実際の影響度に基づいて決定することができます。
| パッチの種類 | 目的 | 典型的な緊急性 | ロールバックの複雑さ |
|---|---|---|---|
| セキュリティパッチ | 特定の脆弱性を修正します | 「高」から「重大」 | たいていは単純明快です |
| ホットフィックス | 通常のリリースサイクル外で発生した緊急の不具合に対処します | 高い | 範囲によって異なります |
| 不具合の修正 | パフォーマンスに影響を及ぼす機能上の不具合を修正しました | ミディアム | たいていは単純明快です |
| 累積更新プログラム | 複数のパッチを1つのパッケージにまとめます | ミディアム | より複雑です |
| サービスパック | パッチ、バグ修正、機能強化をまとめています | 下へ | 複合体 |
| 機能の更新 | 新機能や新たな機能性が追加されました | 下へ | 場合によります |
セキュリティパッチ（）は、セキュリティアップデートとも呼ばれることがありますが、不正アクセス、データの盗難、またはシステムの侵害につながる可能性のある脆弱性を修正するものです。 共通脆弱性評価システム（CVSS）では、深刻度を 0 から10までの尺度で評価します。 CVSSスコアが 9.0 以上の場合、一般的には重大な脆弱性を示しており、早急に優先的に対処する必要があります。
のホットフィックスは、通常の更新スケジュールとは別にリリースされる、迅速な対応を目的としたパッチです。 ベンダーは、次回の予定されたリリースを待つことでシステムが現在進行中の脅威や重大なバグにさらされる恐れがある場合に、ホットフィックスをリリースします。
の累積更新プログラムは、複数のパッチを1つのパッケージにまとめています。 マイクロソフトが毎月「パッチ・チューズデー」として公開する更新プログラムは、往々にしてこのような形式をとります。 累積更新プログラムは便利ですが、多くの変更がまとめて含まれているため、ロールバックが難しくなる場合があります。
実務上の意味： セキュリティパッチ および ホットフィックス は、現在悪用されている脆弱性の窓を塞ぐものであるため、最速の対応が求められます。 累積更新プログラム および 、サービスパック には、複数の修正プログラムや機能強化がまとめられているため、これらをきれいにロールバックすることが難しくなっています。 広く展開する前に、代表的なアプリケーション環境でテストを行ってください。
における新機能を導入する機能アップデートは、緊急度は最も低いものの、互換性の範囲が最も予測しづらいものです。
パッチの種類が明確になったところで、ベンダーによるリリースからエンドポイントへのインストールに至るまでのパッチの経路をたどってみましょう。
ベンダーによるリリースからエンドポイントへのインストールに至るまでのソフトウェアパッチのライフサイクル
ベンダーがソフトウェアパッチを出荷してから、エンドポイント上でそのパッチが検証されるまでの間に、さまざまな問題が発生する可能性があります。 ライフサイクルの各段階は、遅延が生じる可能性があり、遅延が生じるたびに、攻撃者が行動できる期間が長くなります。
1. 発見： ベンダーは、内部テスト、セキュリティ研究者、または顧客からの報告を通じて、セキュリティ上の脆弱性を特定します。 セキュリティ上の問題に関しては、一般に公表する前に、CISAや 、NIST（ ）といった組織と連携することがよくあります。
2。 開発： のエンジニアが修正プログラムを作成し、さまざまな構成環境でテストを行った後、配布用にパッケージ化します。 この段階は、その複雑さによっては数日あるいは数週間かかる場合があります。
3。 リリース： ベンダーは公式ルートを通じてパッチを公開しています。 広く利用されているソフトウェアの場合、この発表によって、攻撃者にその脆弱性の存在が知れ渡ってしまう可能性があります。
4。 検出： 貴組織は、自社ソフトウェアおよび のサードパーティ製アプリケーションの両方について、新しいパッチが存在することを把握します。。 これは、ベンダーからのアドバイザリ、パッチ管理プラットフォームからの自動通知、CISAの「既知の悪用されている脆弱性（KEV）」カタログ、全米脆弱性データベース（NVD）、あるいは自動スキャンツールを通じて行われます。
5。 優先順位の決定： の脆弱性の深刻度、資産の重要度、およびビジネス上の状況を踏まえ、どのエンドポイントが影響を受けているか、またパッチの適用がどれほど緊急を要するかを評価します。
6。 テスト： 大規模な展開を行う前に、エンドポイントの代表的なサンプルでパッチをテストし、互換性の問題や予期せぬ動作を検出します。
7。 展開： パッチは、お客様の展開インフラストラクチャを通じて、対象のエンドポイントに配布されます。 これは段階的に行われる可能性があり、重要度の低いシステムから始め、その後本番環境へと移行することになります。
8。 検証： 対象のエンドポイントにソフトウェアパッチが正常にインストールされたことを確認し、単に展開コマンドが実行されただけでなく、脆弱性のあるアプリケーションコードやライブラリが置き換えられていることを検証します。
[パッチ管理のベストプラクティスは、これまで以上に重要になっています。ここでは、予防的なリスク管理と事後対応的なインシデント対応をどのように区別すべきかをご紹介します]
ステップ 3 （リリース）とステップ8 （検証）の間のギャップこそが、リスクが蓄積される場所です。 のパッチが適用されていないエンドポイント が存在するまま日が経つごとに、攻撃者にとっての攻撃の好機が広がる可能性があります。
ヒント： 現在の のパッチ適用プロセスのワークフロー を、これらの段階に照らし合わせて整理してください。 通常、どこで遅延が発生するのでしょうか？ そこが、改善の取り組みに注力すべき点です。
エクスポージャー・ウィンドウとそれに伴うリスク
「エクスポージャー・ウィンドウ」とは、ベンダーがパッチをリリースしてから、影響を受けるすべてのエンドポイントにそのパッチがインストールされていることを確認するまでの期間を指します。 これは抽象的な概念ではありません。 それは測定可能なリスクです。
攻撃者は待ってはいません。 パッチがリリースされる際、そのパッチがどの脆弱性を修正したものかについての詳細が記載されていることがよくあります。 セキュリティ研究者も脅威アクターも、パッチをリバースエンジニアリングすることで、パッチが適用されていないシステムをどのように悪用すればよいかを正確に把握することができます。 多くの場合、彼らはその知識を即座に悪用し、組織が対応する間もなく、新たに明らかになった脆弱性を標的としたマルウェアを展開します。
その脆弱性が公開されている期間中の毎日が、攻撃者が、パッチが公開された際に御社のベンダーから提供された情報を基に攻撃を仕掛けることができる日となります。 一般的な被ばく期間中に何が起こるのか、考えてみましょう：
- 0日目： のベンダーがパッチとアドバイザリを公開しました
- 1–3日目： 攻撃者らがパッチの詳細に基づいてエクスプロイトの開発を開始
- 7日目： のエクスプロイトコードが、アンダーグラウンドのフォーラムで出回っている可能性があります
- 14日目： このエクスプロイトを組み込んだ自動攻撃ツールが出回っています
- 30日目以降： 組織での導入がようやく完了しました
その期間中、 のパッチが適用されていないエンドポイント は、引き続き脆弱な状態のままとなる可能性があります。 ウィンドウが開いたままの状態が長引けば長引くほど、侵害される可能性が高くなります。 パッチが適用されていないアプリケーションの脆弱性は、攻撃者にとっての侵入経路としてますます活発化しており、規制上の問題、金銭的損失、評判の低下といった影響を伴うデータ漏洩のリスクを高めています。
とはいえ、露出ウィンドウは単にシャッタースピードだけの問題ではありません。 また、完全性についても重要な点です。 影響を受けるエンドポイントの 95 パーセントには迅速にパッチを適用できたとしても、5 パーセントを見落としてしまうと、その見落とされたシステムはいつまでも脆弱なままとなります。
大企業において、 5 パーセントというのは、何千もの脆弱なエンドポイントを意味する可能性があります。
この脆弱性のリスクを解消するには、2つのことが必要です。すなわち、ソフトウェアのパッチを迅速に適用すること、そして、影響を受けるすべてのエンドポイントにパッチが実際にインストールされたことを確認することです。 ほとんどの組織は、最初の部分についてはそこそこうまくやっています。 2つ目は、プログラムが気づかれないうちに動作しなくなる場合です。
大規模なソフトウェアパッチの展開がしばしば失敗する理由
何千ものエンドポイントにソフトウェアのパッチを適用するのは、機械的な作業のように思えます。 実際には、そこではセキュリティの死角が知らぬ間に生じ、セキュリティ侵害が発生し、パッチが適用されていないアプリケーションの脆弱性が最も長く残ってしまうのです。
エンドポイントに常にアクセスできるとは限りません。 ノートパソコンは持ち運びに便利です。 リモートワーカーの接続は断続的です。 隔離されたネットワークセグメントにあるサーバーは、デプロイメントコマンドを受信できない場合があります。 パッチが配信された時点で、エンドポイントがオンライン状態でなく、接続されていない場合、そのエンドポイントにはパッチが適用されません。
[サーバーのパッチ管理戦略を検討し、稼働時間、依存関係、監査対応体制を確保しつつ、悪用されるリスクを低減しましょう]
依存関係は競合を引き起こします。 あるアプリケーション向けのソフトウェアパッチが、特定のバージョンや共有ライブラリに依存している別のアプリケーションの動作を妨げる可能性があります。 何がインストールされているか、またアプリケーション同士がどのように連携しているかについて把握できていなければ、何かが動作しなくなるまで、問題があることに気づくことはできません。
異種混在環境は、複雑さを増大させます。 企業では、複数のアプリケーションバージョン、依存関係スタック、およびOS構成を同時に運用しています。 あるアプリケーションのバージョンに対して検証されたソフトウェアパッチでも、別のバージョンでは異なる動作をする場合があります。 実際に何がインストールされているのかが把握できていないと、手探りの状態で展開することになります。
自己申告は信頼できません。 多くのパッチ適用ツールは、パッチが実際に正しくインストールされたかどうかではなく、展開コマンドが実行されたかどうかに基づいて、成功したと報告します。 エンドポイントでは「パッチが適用済み」と報告されていても、その根本的な脆弱性が残っている場合があります。
[毎日 130 件以上の新たな脆弱性が公表されている中、現代の脆弱性管理が、先手を打つか後手に回るかの分かれ目となる理由をご説明します]
メンテナンスの実施期間は限られています。 ダウンタイムが発生する可能性があるため、営業時間中に再起動できないアプリケーションがあると、パッチ適用可能な時間が限られてしまいます。 デプロイが完了する前にそれらのウィンドウが閉じられると、ソフトウェアのパッチは適用されるのではなく、キューに蓄積されてしまいます。 未処理の課題は時間の経過とともに積み重なり、適用されなかった各パッチの脆弱性が露呈する期間が長引くだけでなく、ITサポートチームを、先を見越した展開ではなく、事後対応的な対応に追いやることになります。
パッチが実際に適用されたことを確認する
導入はゴールではありません。 検証とは、
インストールが検証されないまま展開されたソフトウェアのパッチは、未解決の問題であり、修正済みの脆弱性ではありません。 「適用しました」と「確認しました」との間のギャップこそが、組織が実際のパッチ適用率を常に過大評価してしまう原因となっています。
検証では、次の3つの疑問に答えます：
- パッチはエンドポイントに適用されましたか？ ネットワークの問題、オフラインのデバイス、または展開のエラーにより、配信が行えない場合があります。
- エンドポイントへのパッチのインストールは正常に完了しましたか？ ディスク容量不足、権限エラー、または競合により、パッチが配信された場合でもインストールに失敗することがあります。
- その脆弱性は実際に修正されたのでしょうか？ 場合によっては、パッチがインストールされても、設定要件や再起動が必要なため、問題が完全に解決されないことがあります。
多くの組織は、パッチ適用ツールの成功レポートを頼りにしています。 しかし、そうした報告は、多くの場合、配備の試みを反映しているだけで、実証された結果ではないのです。 ツールによると、パッチが適用されたとのことです。 これは、エンドポイントが実際にパッチを正しく受信・インストールしたかどうか、あるいは根本的な脆弱性が解消されたかどうかを保証するものではありません。
効果的な検証を行うには、エンドポイントに直接クエリを送信し、その現在の状態を確認する必要があります。 どのバージョンのアプリケーションがインストールされていますか？ 脆弱性のあるライブラリやファイルは、まだ存在していますか？ パッチが適用されたコードを有効にするために、アプリケーションを再起動しましたか？
ここで、 のリアルタイムエンドポイント可視化機能 が極めて重要となります。 特定時点でのスキャンでは、スキャン中にオフラインだったエンドポイントが検出されません。
また、スキャン完了後に発生した変更も見逃してしまいます。 継続的な可視化により、環境全体にわたるパッチの状態について、最新かつ正確な状況を把握することができます。
ヒント： 重要なパッチの適用後は、影響を受けるエンドポイントに直接クエリを実行し、脆弱性のあるコンポーネントがもはや存在しないことを確認してください。 デプロイログだけに頼らないでください。
検証により、個々のソフトウェアパッチに関する一連のプロセスが完了します。 しかし、パッチは単独で提供されることはなく、ベンダーのリリースから検証済みのエンドポイント状態へとパッチを適用するプログラムこそが、大規模な環境においても適用範囲が維持されるかどうかを決定づけるのです。
パッチ管理におけるソフトウェアパッチの位置づけ
ソフトウェアパッチとは何か、またそれがどのように機能するかを理解することは、基本となります。 しかし、企業環境においては、個々のパッチは自動的に展開されるわけではありません。 これらは、「検出」「優先順位付け」「テスト」「展開」「検証」という一連のプロセスに沿って進められます。
そのプログラムとはパッチ管理のことであり、その機能の良し悪しによって、ソフトウェアのパッチがリリースされた後、組織がどのくらいの速さで脆弱性の発生期間を解消できるかが決まります。 パッチ管理プログラムの構成や評価方法についてさらに詳しく知りたい場合は、 のパッチ管理ガイド（）をご覧ください。
ソフトウェアパッチこそが成果物です。 パッチ管理とは、ベンダーによるリリースから、場合によっては数十万台にも及ぶエンドポイント全体での検証済みインストールに至るまで、そのアーティファクトを管理するシステムのことです。
この区別が重要なのは、パッチ適用に失敗する多くのケースが、パッチそのものに起因するものではないからです。 これらは、そのプログラムに関するものです：
- 検出のギャップ： パッチの存在や、どのエンドポイントにそのパッチが必要なのかが分からない
- 優先順位の不備： 重要なパッチが、定期的な更新の後ろに並んで待機している
- テストのボトルネック： のデプロイが、チームによる手動での互換性検証のために遅延しています
- 展開に関する制限事項： パッチは、影響を受けるすべてのエンドポイントに適用されません
- 検証上の不備： パッチが実際にインストールされたかどうかが不明です
これらはそれぞれ、パッチレベルの問題ではなく、プログラムレベルの課題です。
適切なパッチ管理ソフトウェアの選定は、こうした課題を体系的に解決するための第一歩となることが多く、チームが大規模な運用を行うために必要な可視性、自動化、およびレポート機能を提供します。
大規模かつ分散したエンドポイント環境を管理する組織にとって、プログラムレベルでの課題は、個々のパッチの技術的な複雑さをはるかに上回る場合が少なくありません。
リアルタイムの可視性、検証済みの導入状況、明確な パッチ適用ポリシー、および自動化されたパッチ管理ワークフローは、もはや「あれば便利なもの」ではなく、運用上の必須要件となっています。特に、数千ものエンドポイントにわたってパッチの状態を手作業で追跡しなければならない場合、その重要性は一層高まります。
Taniumが企業のソフトウェアパッチ管理をどのように支援するか
前述の課題、すなわち、情報が古くなっていること、デプロイの失敗、および検証されていない修正措置などは、個々のパッチでは解決できないプログラムレベルの問題です。
Taniumの自律型ITプラットフォーム「 」は、これらの課題を根本から解決します。具体的には、エンドポイントに直接クエリを送信してリアルタイムのパッチ適用状況を把握し、の信頼度スコア（ ）や脆弱性データに基づいて実際のリスクに応じて展開の優先順位を決定し、展開ログのみに頼るのではなく、インストールが正常に完了したことを確認します。
大規模かつ分散したエンドポイント環境を管理する組織にとって、この組み合わせは、二次的なインフラを必要とすることなく、スキャンベースのアプローチでは通常実現できないほど迅速に、パッチのリリースと検証済みの修正措置との間のギャップを埋めることを目的としています。
基盤となるリアルタイムの可視性
パッチ適用プログラムが大規模な導入において失敗する最も一般的な理由は、努力不足ではありません。 正確で最新のデータが不足しているのです。 Taniumの自律型ITプラットフォームは、Windows 、Linux、macOSの各デバイスにおけるエンドポイントのパッチ適用状況をリアルタイムで可視化することで、この課題に直接取り組んでいます。
[Linux環境がますます複雑化する中、定期的なパッチ適用と継続的な脆弱性管理との間のギャップが、かつてないほど大きなコスト要因となっている理由をご説明します]
数時間あるいは数日前のスキャンデータに頼るのではなく、Taniumを利用している組織は、エンドポイントに直接クエリを実行して、その現在の状態を把握することができます。 重要なパッチがリリースされた際、ITチームは、定期的なスキャンサイクルの完了を待つことなく、どのエンドポイントが影響を受ける可能性が高いか、どのエンドポイントがすでにパッチが適用されているか、そしてどのエンドポイントの対応を延期すべきかを迅速に特定することができます。
Taniumの自律型ITプラットフォームは、支店、遠隔地、地理的に分散した拠点にあるエンドポイントを含む分散環境全体にわたる可視性を維持するように設計されており、これらすべてを単一のTaniumインスタンスから管理できるようになっています。これにより、二次中継サーバー、データベース、または配布サーバーへの依存を軽減することを目的としています。
このプラットフォームのアーキテクチャは、数十万のエンドポイントを含む導入環境など、大規模な環境に対応できるよう設計されています。 この規模が重要となるのは、パッチの適用漏れが均一であることはめったにないからです。到達するのが最も困難なエンドポイントほど、パッチが適用されないままになる可能性が高くなります。
導入前のリスクに基づく優先順位付け
すべてのソフトウェアパッチが、同じ程度の緊急性を要するわけではありません。 優先順位付けを行わずにデプロイを行うと、チームは、アクティブな脆弱性の修正期間を締め切るのと同じくらい、リスクの低いアプリケーションの更新に追われることになりかねません。
Taniumの自律型ITプラットフォームにより、組織は脆弱性データとエンドポイントの重要度および信頼性スコアを組み合わせて、パッチ適用の優先順位を決定し、まず高リスクの脆弱性に注力することができます。
信頼性スコアは、インストール成功率、クラッシュの発生頻度、パフォーマンスへの影響などの傾向を、クラウドインテリジェンスによるリアルタイム分析を通じて算出されます。これにより、チームはパッチを広く展開する前に、展開順序を決定するための実用的なデータを得ることができます。
また、このプラットフォームにより、チームはリスクシグナルやビジネス上の状況を踏まえて、リスクを最も効果的に低減できるパッチを優先的に適用することが可能になります。 このアプローチでは、パッチ管理を孤立したIT運用タスクとして扱うのではなく、より広範な のエクスポージャー管理 ワークフローに直接連携させます。
各チームは、パッチ適用可能な脆弱性や、優先度の高い予定外のパッチを特定することができます。これにより、セキュリティチームと運用チーム間の連携が円滑になり、パッチの優先順位付けと効果的な適用が確保されます。
リングベースの展開による管理された導入
Taniumの「Autonomous IT Platform」において、運用面で特に重要な機能の一つは、段階的な リング方式による展開への対応です。 すべてのエンドポイントに同時にパッチを適用するのではなく、組織はまず少数のエンドポイントから始め、その結果を検証し、Taniumのカスタマーコミュニティから得た知見を活用することで、各段階が成功基準を満たすたびに、自信を持って展開を拡大していくことができます。
このアプローチは、 のゼロデイ脆弱性（）において特に重要となります。このケースでは、迅速な対応が不可欠である一方で、問題のあるパッチによって広範囲にわたる混乱が生じるリスクも高まっているからです。
パッチの適用は、承認ワークフローを経由させたり、メンテナンス時間帯に実施したりすることで、業務への影響を最小限に抑えることができます。 各チームは、組織の既存の運用体制に合わせてパッチのスケジュールやワークフローを設定し、どのエンドポイントにどの順序でパッチを適用するか、またどのような条件下で展開が次のリングに進むかを管理することができます。
Tanium Automate を活用して構築された「 」の自動化プレイブックは、大規模なエンドポイント環境全体におけるソフトウェアパッチのワークフローをリアルタイムで管理し、検出、展開順序の決定、検証といった各ステップを、ツール間での一連の手動による引き継ぎではなく、単一の反復可能なプロセスとして処理します。
検証と閉ループによる是正措置
導入と是正措置は同じものではありません。 Taniumの自律型ITプラットフォームは、パッチ適用状況、例外、およびパフォーマンス指標をリアルタイムで追跡し、対象選定、タイミング、および順序付けに関する今後のプロセス改善を支援するための詳細なレポートを提供します。
展開後、組織はパッチの適用状況を確認し、更新に失敗したシステムを特定することができます。その際、パッチが配信されたもののインストールされなかったエンドポイントと、展開期間中に単に接続できなかったエンドポイントとを区別することができます。
Tanium Comply は、パッチの適用が完了したかどうかだけでなく、ソフトウェアの脆弱性が実際に修正されたかどうかを評価することで、この機能をさらに拡張しています。 チームは、同じプラットフォーム上で、パッチが適用されていないソフトウェアの脆弱性を特定した直後から、是正措置の開始や進捗管理へと直接移行することができ、ツールを切り替えたり、別々のシステムからのデータを照合したりする必要はありません。
この「特定→修正→検証」というサイクルは、パッチ管理が展開で終わるのではなく、脆弱性が修正されたことが確認された時点で完了することを意味します。
コンプライアンス報告および監査への備え
ソフトウェアのパッチが適用され、かつ正しく適用されていることを実証することは、 の規制監査プログラムにおいて、HIPAAやPCIなどのフレームワークに関連するものを含め、ますます重要になってきています。 Taniumは、こうしたドキュメント作成のニーズに対応できるよう設計されています。
Tanium Patch では、あらゆるソフトウェアパッチの展開状況をまとめて表示し、成功や、是正措置が必要な失敗について即座にフィードバックを提供します。 監査担当者が「どのソフトウェアパッチがいつ適用されたか」と尋ねた際、Taniumは、その質問に対して推測ではなくデータに基づいて回答するために必要な、展開履歴、再起動状況、および修正の確認情報をチームに提供します。
コンプライアンスのギャップからパッチ適用率 90％へ：ハネウェル
ハネウェル（ ）では、パッチ適用率が低かったため、ランサムウェアやその他のサイバー攻撃のリスクにさらされていました。 Taniumの導入後、ハネウェルは3ヶ月連続でパッチ適用率 90 ％を達成しました。これは、同社がこれまで達成できなかった水準です。
また、Taniumの導入により、ハネウェルは他のパッチ適用ツールを統合し、場合によってはそれらを廃止することが可能となり、経営陣および運用部門向けのコンプライアンス報告を一元的に管理できる環境が整いました。
「Taniumを導入する前は、当社のパッチ適用率は低かったのです。 Taniumの導入により、パッチ適用率 90％という水準を3ヶ月連続で達成しました。 それは重要な点ですね。”ハネウェル社のITディレクター、マニッシュ・チョプラ氏
ソフトウェアパッチの仕組みは単純です。 数千ものエンドポイントにこれを展開するという運用上の現実は、そうではありません。 以下に、よく寄せられる質問への回答を掲載します。
ソフトウェアパッチに関するよくある質問
ソフトウェアのパッチとアップデートの違いは何ですか？
パッチとは、特定の問題、通常はソフトウェアのバグやセキュリティ上の脆弱性に対して、的を絞って修正を行うものです。 「アップデート」とは、パッチ、機能の追加、パフォーマンスの向上、その他の変更などを含む、より広義の用語です。 すべてのパッチはアップデートですが、すべてのアップデートがパッチであるとは限りません。
ソフトウェアのパッチがリリースされた後、攻撃者はどれくらいの速さで行動を起こすのでしょうか？
多くの組織が導入できるよりも迅速です。 ベンダーがソフトウェアのパッチを公開すると、そのパッチ自体によって根本的な脆弱性の詳細が明らかになり、攻撃者に対して、パッチが適用されていないシステムを悪用するための手掛かりを与えてしまう可能性があります。 注目度の高いソフトウェアの脆弱性については、パッチの公開から数時間以内にエクスプロイトコードが出現することがあります。
広く利用されているJavaロギングライブラリの脆弱性である「 2021 Log4j 」については、公開から24 時間以内に200,000 件以上の攻撃試行が確認されました。Check Point Research（）の報告によると。 だからこそ、ソフトウェアパッチのリリースから検証済みのインストールまでの間に生じるギャップは、単なる運用上の不便さではなく、測定可能なリスクとなるのです。
万が一問題が発生した場合、ソフトウェアのパッチを元に戻すことは可能でしょうか？
それは、パッチがどのようにパッケージ化されたかによって異なります。 ほとんどのスタンドアロン型ソフトウェアのパッチは、アプリケーションまたはパッチ管理ツールを通じてアンインストールすることができ、以前のバージョンに戻すことができます。 累積更新は、1つの変更を元に戻すには複数の変更を元に戻す必要があるため、きれいに元に戻すのが難しくなります。
ソフトウェアパッチを広く展開する前に、エンドポイントの代表的なサンプルを用いてテストを行い、パッチによって互換性の問題や予期せぬアプリケーションの動作が生じた場合に備えて、ロールバックの手順が確立されていることを確認してください。
なぜ一部のソフトウェアのパッチでは再起動が必要になるのでしょうか？
現在使用中のアプリケーションファイルや共有ライブラリを変更するソフトウェアパッチは、それらのファイルがアクティブな状態ではインストールを完了できません。 再起動、あるいは場合によってはアプリケーションの再起動を行うと、それらのロックが解除され、パッチが適用されたファイルが有効になります。 再起動が必要かどうかは、ソフトウェアパッチによって何が変更されるか、および影響を受けるアプリケーションがシステム全体の再起動を行わずに安全に再起動できるかどうかに依存します。
エンドポイントがソフトウェアパッチの展開を受けられなかった場合、どうなるのでしょうか？
そのエンドポイントは、そのパッチで修正されるはずだったソフトウェアの脆弱性に依然としてさらされたままとなっています。 デプロイの失敗は、些細な問題ではありません。 つまり、根本的なコードの欠陥は依然として存在しており、悪用される可能性があるということです。 見落とされたエンドポイントを特定するには、現在のソフトウェアのバージョンやパッチの状態をエンドポイントに直接照会する必要があります。パッチが配信されたことのみを確認するデプロイメントログに頼るのではなく、正しくインストールされたかどうかを確認する必要があります。
多くの最新のパッチ管理ソリューションは、適用漏れを追跡し、自動的に再試行を行い、不備を可視化するように設計されており、これにより、長期間にわたりパッチが適用されていないエンドポイントが少なくなるようになっています。
効果的なソフトウェアパッチ管理は、何を、なぜ展開するのかを理解することから始まります。具体的には、パッチによって行われる具体的なコードの変更内容や、正しくインストールされなかった場合に何が起こるのかといった点まで把握することが重要です。 その後は、脆弱性の露出期間をできるだけ迅速かつ完全に解消し、実際に成功したかどうかを確認することが重要です。
Taniumは、分散したエンドポイント環境全体におけるソフトウェアパッチの状態をリアルタイムで可視化し、チームがギャップを特定し、確信を持って展開を行い、是正措置を「推測」するのではなく「確認」できるようにします。 からデモをご予約いただき、エンタープライズ規模での運用状況をご確認ください。
