Help Net Securityのインタビューに応じたのは、QualysのシニアVP兼ゼネラルマネージャーであるKunal Modasiya氏です。同氏は、パッチ適用が今なお難しい理由を語りました。事業部門からのプレッシャー、収益に直結するシステム、不具合を引き起こすパッチなどが、修正プログラムの展開を妨げているといいます。Modasiya氏は、速度だけでは限界があると指摘し、チームは修復ワークフロー全体に目を向けるべきだと主張しています。
同氏はさらに、先進的なチームがどのようにリスクを判断しているのか、MTTR（平均修復時間）よりも「露出期間」と「武器化までの期間」の差が重要である理由、本番ネットワークで自動パッチ適用が妥当となる場面についても説明しました。
パッチ適用はセキュリティ分野でも最も歴史の長い取り組みの一つであり、各チームは長年にわたり予算とツールを投じてきました。それでもなお、これほど難しいのはなぜでしょうか。
パッチ適用の第一の問題は、「1つの問題に1つのパッチ」という単純な話ではないことです。1つの問題を完全に解消するために複数のパッチが必要になる場合もあれば、脆弱性に完全に対処するために設定変更が必要になる場合もあります。そのため、「単にパッチを当てる」ことは、特に大規模環境では見かけ以上に困難です。
第二の問題は、そもそもパッチを展開できない場合があることです。多くのセキュリティチームが経験していることですが、問題の存在を把握し、更新プログラムも用意できているのに、事業部門が適用を認めないのです。なぜでしょうか。こうしたアプリケーションはミッションクリティカルで、収益創出に直結していることが多いからです。アプリケーションを止めることは収益を止めることを意味し、その判断への支持を得るのは容易ではありません。
IT部門にとって、パッチの展開が予期せぬ結果や、事前には見えなかった追加の影響を招き、想定以上にシステムが停止した経験も身近なものでしょう。重要な更新プログラムには経営陣や取締役会の支持が必要で、その承認を得るには、セキュリティ上の問題だけでは足りず、より説得力のある根拠が求められることもあります。財務面への影響を見極め、事業部門が理解し、賛同できる言葉で主張しなければなりません。
「より速くパッチを当てよ」は、10年にわたって業界が唱えてきた助言です。速度だけでは、もはや効果の限界に達したのでしょうか。
パッチ適用の速度は、かつては、チームがタスクのためのスクリプトやその他の自動化をどれだけ速く構築できるかで測られていました。しかし、パッチをどれだけ速く展開できるかについては、依然としてチームが責任を負っていました。自動化を使っても、ワークフロー全体が人の作業に依存していたため、大規模に展開する速度には限界がありました。AIは、展開前のパッチのテストや問題の確認を容易にして、この点で役立ちます。ただ、ワークフロー全体を見渡したときに、より大きな効果を発揮します。
たとえば、一部のパッチは自動的に適用したいと考えるかもしれません。まず環境の一部で試験的に適用したいパッチもあれば、一斉にあらゆる環境へ適用したいパッチもあるでしょう。それは、パッチがどれだけリスクを低減するか、万一問題が起きた場合の潜在的な影響と比べてどうか、という観点で決めるべき判断です。このプロセスをAIの支援を受けながら進めれば、より速く、効率的にパッチを届けることができます。展開の速度は方程式の一部にすぎず、プロセス全体を見直すことで効率を高められます。
ITセキュリティチームにとって、こうした情報を提供することは、社内での価値を高めることにつながります。問題がどこにあり、どれほど深刻かを指摘するだけでなく、どのように変更を加え、どのような手順を踏むべきかを直接提案できるからです。このチームは、別のチームに引き継ぐことなく、リスクの修復と排除まで自ら担うこともできます。
一部の組織は、脆弱性が公式の「必須パッチ」リストに載る前に対応に動きますが、大半は確認を待ちます。この先手を打つ少数派は、他の組織が理解していない何を理解しているのでしょうか。
先を行くチームは、CVSSが示す標準的な定義ではなく、自社の事業に対するリスクに目を向けています。脅威インテリジェンス、資産インベントリ、想定される事業への影響を組み合わせて評価し、事業運営に大きな影響を及ぼしかねない問題が自社環境に見つかれば、迅速に動く意思と能力を備えています。こうしたリスク運用への先手を打つ姿勢によって、攻撃者によるキャンペーンが始まる前に先回りできるのです。
この段階に到達するには、リスクが事業にとって本当に何を意味し、どこに存在するのかを見極める必要があります。重大な問題があるというだけでは不十分です。その問題はどこにあるのか。インターネットに公開されているのか。エクスプロイトは存在するのか、攻撃者は自らのキャンペーンで容易に悪用できるのか。設定変更で潜在的なリスクを素早く緩和し、その後にパッチを適用して問題を取り除けないか。こうした点を確認します。
先進的なセキュリティチームは、このプロセスを経て運用に組み込んでおり、あらゆる問題に対していつでも同じ手法を適用できます。また、この仕組みは状況の変化にも対応できます。たとえば、ほとんど無害だった脆弱性が、突如として広範な攻撃チェーンの一部となり、修復の優先順位が上がるような場合です。機敏さを保ち、すばやく対応できる能力は欠かせません。
すべてのセキュリティ責任者に、現在は見過ごされている修復に関する指標を1つだけ追跡してもらうとしたら、何を選びますか。
チームが追跡する典型的な指標は、平均修復時間（MTTR）です。最初の問題が公開されてから、チームがパッチを展開するまでにかかる時間を指します。MTTRは今でも有用かもしれませんが、私が今おすすめしたい指標ではありません。代わりに、修復効率に注目することを提案します。
パッチが最初に公開された時点を見ることは有益ですが、最も重要なポイントではありません。チームが考慮すべきは、平均露出期間（AWE：Average Window of Exposure）です。これは、エクスプロイトが公開されてから、組織が潜在的な悪用にさらされ続ける期間を示します。ゼロデイ脆弱性の場合や、パッチ公開のはるか前に攻撃者がエクスプロイトを悪用する場合、組織は発見や公表の何日も前から脆弱な状態に置かれている可能性があります。あわせて、チームは武器化期間（WOW：Window of Weaponization）も追跡すべきです。これは、攻撃者が潜在的な脆弱性を実際に機能するエクスプロイトに仕立て上げるまでの速さを表します。AWEとWOWの差は、防御側にとって最も重要な要素です。自組織がどれだけの期間、脅威にさらされていた可能性があるかを示すからです。この「修復効率ギャップ」が重要なのは、攻撃者が優位に立つ、まさにその期間を示しているためです。
人間を介在させず、システムが自律的に修復する可能性が盛んに語られるようになっています。運用責任者が本番ネットワークでそれを信頼するには、何が前提となるでしょうか。
自動修復は可能ですが、多くのチームはAIに全面的な制御を委ねることを望んでいません。セキュリティのあらゆる事柄と同様に、これは二者択一の話ではありません。むしろチームは、問題の深刻度、エクスプロイトが公開された場合の事業への影響、そして万一問題が起きた場合に展開が及ぼす影響の大きさに応じて、課題に優先順位を付けるべきです。
ここでの考え方は、収益を生むアプリケーションの重大な問題には、セキュリティチームが直接、最も注意を払うべきだというものです。一方、パッチの信頼性が非常に高く、問題が起きてもユーザーへのリスクが小さい低リスクのアプリケーションは、自動で展開できます。Google Chromeのパッチがその好例です。判断が明確に分かれない場合は、自社のリスクに対する姿勢や、パッチを展開できる速さに応じて、リリースを段階分けできます。
こうしたプロセスを実現するには、複数のチームをまたぐ作業が必要です。ITセキュリティはIT運用部門に知見や提言を提供でき、そのデータは時間とともに進化させて、新たに生じる問題や変化する問題に対応していけます。
将来的には、現実のSecOpsや修復のユースケースをエージェント型AIがより多く担うことを期待しています。そうすれば、より迅速かつ賢明にリスクを低減できるからです。毎月、Microsoftがセキュリティ更新プログラムを公開するパッチチューズデーを考えてみましょう。優先すべきパッチを見極めるため、多くのチームはリリースに含まれる公式情報を確認し、「緊急」や「重要」と評価されたものに集中します。しかし、公式の評価が自社の環境に適しているとは限りません。すでに他の緩和策や更新によって対処済みのケースもあれば、自社環境にとってはるかに差し迫った別の問題があるかもしれません。
エージェント型AIは、チームが注力すべき対象を提案できるようになり、そのうえで現実のリスクが存在する箇所に集中できます。脆弱性の優先順位を付けたら、その情報を共有し、自動でパッチを適用できるものや、人事、財務、マーケティングといった事業部門が所有するものについて検討を進められます。物事を実際に進めるうえでは、この所有者の側面のほうが重要であり、エージェント型AIはそのプロセスをはるかに容易かつ効率的にしてくれます。
翻訳元: https://www.helpnetsecurity.com/2026/10/14/kunal-modasiya-qualys-vulnerability-remediation/
