優先順位付けを理解する - パッチと脆弱性

avatar

 2016.07.28  Japanブログ編集部

Tripwire の脆弱性調査チーム、VERT の職務の 1 つに月に一度の パッチプライオリティ指標(Patch Priority Index:PPI) の公開があります。非常に重要な意味を持つ PPI は、日々これらのパッチにより解決される脆弱性に取り組んでいる VERT の研究員がリリースしています。この PPI 公開プロジェクトを開始する当初、関係者の間で非常に面白い議論が交わされました。

当初、パッチの優先順位付け方法としてスコアリングを使用することを考え、Tripwire IP360 スコアリングシステムと CVSSv2 を検討しました。どちらのシステムもパッチの優先順位付けに関するものではなく、脆弱性の深刻度を表現するために設計されたものです。

それは意味的な違いではないかと考える人もあるでしょうが、実際にはこれらのコンセプトは非常に異なるものです。脆弱性の優先順位付けについて説明するときには以下のような共通の考慮事項があります。

  • 侵入によってどのようなレベルのものにアクセスが可能となるか
  • 攻撃手法・経路は何であるか
  • その脆弱性悪用の容易さはどの程度か
  • その脆弱性は積極的に悪用されているか

これらは共通の考慮事項となり得ます。なぜならば、複数のスコアリングシステムや脆弱性の深刻度に関する議論の多くで問題とされるからです。

一方で、パッチは複数の脆弱性を解決します。つまり、優先順位付けが格段に複雑になることを意味しています。まず思いつくのは、脆弱性スコアを単純に組み合わせることです。以下のシナリオについて考えてみましょう。

A、B、C、D の 4 つの脆弱性が内在するシステムがあるとします。パッチ X は A と B を解決します。一方でパッチ Y は C と D を解決します。では、あなたはどちらのパッチを先に適用しますか?

 

CVSS スコア

脆弱性A – 10.0 (AV:N/AC:L/Au:N/C:C/I:C/A:C)

脆弱性B – 0.8 (AV:L/AC:H/Au:M/C:N/I:N/A:P)

脆弱性C – 6.0 (AV:L/AC:H/Au:S/C:C/I:C/A:C)

脆弱性D – 7.2 (AV:L/AC:L/Au:N/C:C/I:C/A:C)

 

攻撃手法や経路については考えずに、単純に CVSS を加算しています。不等式を優先順位であると勘違いしている人もいるかもしれません。

 

A+B = 10.0 + 0.8 = 10.8

C+D = 6.0 + 7.2 = 13.2

∴ パッチ Y が優先 ∵ C+D > A+B

 

まず C+D にパッチを適用すべきだという意見があるのは当然でしょう。ある ASV によるドキュメントでは、CVSS スコア 4.0 以上の脆弱性が 2 つある場合は 1 つの場合とは対照的に閾値を満たさないことを示しており、この考えを裏付けています。しかし、CVSS は、スコア 10.0 の脆弱性 1 つは、それ以下の脆弱性が 2 つある場合よりもより深刻である可能性を示唆しており、パッチの優先順位付けの際にはこれを考慮することができます。 しかし、今は脆弱性の優先順位付けとパッチの優先順位付けの違いについて考察しているだけです。

脆弱性スコアリングは科学です。脆弱性の深刻度の測定には、(マスコミによる報道や目に留まりやすい名前などによる)主観的な側面が存在するように思われるかもしれませんが、それは真実ではありません。 脆弱性の深刻度を示す 1~5 のスコアリングシステムが存続しなかったのには理由があります。

脆弱性スコアリングには客観性があります。それには再現可能なステップが存在し、脆弱性悪用の結果が盛り込まれています。これらは測定可能であることから、脆弱性スコアリングは間違いなく科学であると言うことができます。(脆弱性スコアリングに関する詳細な情報については、こちらこちら、あるいはこちらのブログ記事を参照してください。)

脆弱性スコアリングが科学なのだから、パッチの優先順位付けもまた科学であろうと、私達の多くが誤解しています。 ある 3 つの経験から、私はパッチの優先順位付けは科学ではなく、技であると感じています。最初にこれを実感したのは、先に述べたように PPI の開発のときでした。2 回目は、2015年の RSA カンファレンスのときです。

私は 2015年に脆弱性スコアリングをテーマとした P2P セッションを行いました。そこでは、さまざまなスコアリングアルゴリズムにおける数学と科学について議論を交わすことを期待していました。そのようなセッションは非常に役に立ちます。なぜなら通常のカンファレンスとは異なり、内容は大筋しか決まっておらず、参加者の反応に応じて内容が拡大するからです。このセッションは、私が全く想像していなかった方向に発展し、パッチ管理に関する素晴らしいディスカッションとなりました。

対話では、ベンダーが再起動の必要性やパッチインストールの煩雑さを考慮していないことについて質問が上がりました。「インストールの煩雑さ」のようなトピックは、脆弱性や測定システムのどちらにも通じるものがなかったため、私は驚きました。そして、「脆弱性スコアリングの科学」という話題からは逸れてしまっていることに気づきました。私はセッション中に明らかになったいくつかの新事実に興味を持ち、その後の調査で考察しようと書き留めました。

その調査がパッチ管理に関する調査です。その結果を「Patch Fatigue」(パッチが招く疲労)をテーマとしたホワイトペーパーにまとめています。 その際には、パッチの優先順位付けの際に考慮する要素についても調査することができました。それらの回答によって、パッチの優先順位付けとは「熟達した技」である、という私の考えが確信に変わりました。

いくつかの客観的データ(CVSS、エクスプロイト入手の容易さ、再起動の必要性)を取り上げた一方で、数多くの主観的データも参考にしました。これには、ポストパッチコンフィギュレーション、マルチステージのアップデート、内部ポリシー、オンラインリソース、パブリケーションが含まれます。

これらのデータのすべてが、「パッチの優先順位付けとは技である」という私の見解を後押ししています。また、私達が具現化することのできる科学が数多く存在し、客観的なデータと集約可能な主観的データも大量にあります。そのような状況下では、経験豊かな実践者が真に有能であることが求められます。だからこそ、10 年以上にわたる IT とセキュリティの経験を持つ VERT は、毎月のパッチプライオリティ指標とそれに注ぐ努力に誇りを持っているのです。

Title image courtesy of ShutterStock

元の記事はこちらからご覧いただけます。

Tripwireの脆弱性スコアリングシステム

RECOMMEND関連記事


RECENT POST「脆弱性管理」の最新記事


この記事が気に入ったらいいねしよう!