私は、2013年9月に、The State of Securityに脆弱性評価について考察する記事（英語版）を書きました。制限のない脆弱性評価システム - 即ち、如何なる明確な制限のない評価システム – は、ビジネス過程の適切なレベルで重要となることについて議論し、また、順位付け、分類、より洗練された計測方法がこの種のシステムの恩恵を受けると結論付けました。
この記事の出版から3年が経ちますが、企業がどのように脆弱性リスクを優先順位付けできるかについて取り上げた点は、今日でも変わりません。
そこで今回は、安全評価ソリューションの新分野を専門とするITセキュリティ企業Kennaのマイケル・ロイトマン氏と脆弱性評価について会話した内容をご紹介します。
マイケル・ロイトマン: 2013年のあなたの記事の考え方に全く同意します。あなたが言う通り、我々は優先順位を付けすぎる傾向があります。実際に、閾値を定義する方法や、歴史的評価によって何が重要であるかが曖昧になったことも問題なのです。しかし、制限されたスコアに関するこれらの問題を指摘することは非常に簡単だと思います。
何故制限されたスコアが問題なのか説明させてください。一般的に、計測方法を制限すると、特定の状況がその他の状況に比べて「どれだけ悪いか」を主張できるようになります。制限しなければ、12,000点のスコアが実際には6,000点のスコアより2倍悪いスコアであると言うことはできません。その理由は、脆弱性 (または一連の脆弱性) が企業に与えるリスクを実際に計算しているからです。そうすることにより、我々は、脆弱性が発生する確率を計測できることを本質的に推測するのです。お互いに分かっているように、一連の知り得る出来事以外で起こるかも知れない出来事について主張できるように、確率空間は定義によって制限されます。この件に関する詳細は、ここをクリックしてください。
ティム・アーリン: マイケル、あなたの理由付けはしっかりしています。制限されたスコアが2種類の脆弱性を見分ける能力があることは確かです。あなたの分析を考慮して、「制限されない」から「動的制限」の様な言葉に変更するようにします。少し難解になって来たので、段取りの一つとして、用語の定義を上げておきましょう。
- 制限されたスコア: 上下の制限値が固定された評価システム
- 制限されないスコア: 上下何れかの制限値が固定されていない評価システム
- 動的に制限されたスコア: ある条件によって上下の制限値が変わる評価システム
では、あなたの意見に戻りましょう。「一連の知り得る出来事以外で起こるかも知れない出来事について主張する」ことができるようになりますが、制限されたスコアの問題点は、確率の変化に対して調整できないことです – それは、評価をそのまま取り入れることです。今日は確率(x)であった脅威が、実際に明日には確率(y)となることもあるのです。
功績の確率を変化させる一連の条件を認知して調整することができると推測するなら、それらを評価システムに組み込んで、そのシステムの制限を調整できるようにするべきです。スコアはいつでも制限されます。よく聞いてください。しかし、その制限は確率の変化によって変わるのです。
マイケル・ロイトマン: あなたが今説明したシステムがより良いものであるとは思えません。制限されたスコアは確率に関する欠点がありますが、それに関わらず、固定された制限は、脆弱性の順位付けを伝えることができるため重要です – それは、脆弱性を修正すべき順序です – なぜなら、私たちが話していること全ての目標には二つの要素があるからです。
- 人が取る行為の重要度順のリストを作成する
- システムの現在、過去、未来の状況を報告できる
あなたの記事は、これらの二つの目標が重要であることを大変上手に指摘しています。しかし、順位付けなしでは同じ問題が発生します:.
脆弱性の多くが重要であることは分かっていますが、どれが一番重要であるかは決められないことも分かっています (だから先に行動する)。そうでなければ、制限されない計測方法は総体として、最終状況を曖昧にするため、システムの状況を報告することができなくなります。
あなたの記事の中で同意できない箇所だけを一行ずつ批評することにより、私の理由付けを説明してみます。
「脆弱性評価で最も共通して使用されるケースは、どの脆弱性を修正することに焦点を置くかを決めることです。このケースでは、最終的に高い順位ばかりが集まってしまうという問題が発生する順位付けシステムの制限と、それに対して何もできないことが既に分かっています。」
高い順位が集まるのは、CVSSスコアの配布は、現在私たちが使用できるデータを使用せずに作成されたからです。と言うのは、2002件のデータセット (CVSS 2) を正常として作成された配布ですが、実際には、もっと多くのパラメーター (利用速度、考えられる利用の種類、脆弱性のIDS警告等) 付きのデータによって、もっと精度の高い評価システム (もっと多くの順位、もっと可能性のあるスコア) を作成することと、CVSSで見られる高度なレベルでの人工的な集結を区別することの両方が可能になることを説明しているからです。忘れないでください。CVSSには16種類位の可能な「順位」やスコアしかなく、それらの全てが上位の順位やスコアになりがちなのは、この方法がスコアを高く維持するのは情報の欠如によるからです。(利用が確認できませんか? 同じスコアを維持してください。概念実証を使用しますか? スコアを下げたら利用が確認できましたか? スコアを高いままにしてください。)
「しかし、順位付けは小規模であれば役に立つこともあります。数百個のデバイスがあって、進捗状況を報告する必要がないなら、脆弱性を順位付けることができます。しかし、大抵の場合、制限されないスコアは精密な優先順位付けに最高の機能を提供します。」
再度、これは適切なモデル選択に関する質問です。高度なレベル (FICOスコアを想像してください) で作動し、制限範囲内の二つのシステム状況 (人) を区別するか、比較することができる方法を作成することができます。
もっと多くのデータをモデルに組み込んで、その精度にする必要があるだけです。
「制限されないスコアのもう一つの利点は、ホストレベルまたはその他如何なる任意のグループ分けに総計できることです。例えば、あなたの環境の中でどの脆弱性を今日修正する必要があるかを実際に知る必要がないのです。」
この点は同意できません。目標は環境の中で一番脆弱性の強いものを見つけて、修正して、次に移ることだと思います。チームがそれをしていないと、リスクが最も高い脆弱性を修正していないことになります。制限されないスコアを使用したためにこれができなくなると、不完全な計測方法を使用することになり、特定の大量のデータ条件を使用した時だけ、上位のスコアが得られるような方法でモデルが作成される時に、ホスト上で最悪の脆弱性を見つけることにもなります。
ティム・アーリン: その点は同意できません。この『最もリスクの高い脆弱性を優先し、修正し、次の脆弱性に移動する』戦略は理想的な過程を形成するかも知れませんが、現実的ではありません。実在企業の中で効果的なリスク削減をしたい場合、企業に合わせて過程を調整する方が、企業に理想的な過程を押しつけるよりもっと効果的です。脆弱性のパンチリストを使用した方が良い企業もありますが、他の企業は部署別目標、反省会、修正委員会を使用した方が上手く行きます。何故評価モデルの柔軟性が重要であるかの答えの一つです。同じ企業内でも、複数のモデルに対する使用ケースがあります。脆弱性分析者は、悪用可能性に関する技術的な詳細を気にしますが、経営陣は目的に対する進捗状況を知りたいだけかも知れません。異なる戦略をどのように使用するかに対する一つの意見については下記を参照してください。
https://www.tripwire.com/state-of-security/vulnerability-management/six-strategies-for-reducing-vulnerability-risk/
マイケル・ロイトマン: これが企業哲学における相違点のようです。あなたの記事の中で私が同意できない次の項目に行かせてください。
「実際に、大きな環境内でのもっと実用的な使用ケースは、あなたのウィンドウズ管理者が今週焦点を置くべき脆弱性は何であるか尋ねることです。このケースでは、フィルターされたグループ全体の脆弱性に関する事故の総合スコアが最も役に立ちました (例、あなたの環境内でのウィンドウズの脆弱性に関する全ての事故の最高合計スコア)。
私が提案する代替案では、技術、ビジネス過程、ホストを基に集めることができます – 単に、一連の条件に従ってその最悪の脆弱性を見つけることができるか、または、もっと特別なフィルターに変えることができるかです。
さあ、私の意見のせいで重要なことが曖昧にならないようにしましょう。私たちはお互いに、脆弱性評価がもっと役に立ち、もっと精度が高くなり、侵害を予測できるようになる方法を探しています。CVSSの主な問題は、スコアの種類ではなく、どの様なデータが含まれており、どれほど良いモデルであるかということを明らかにしたいのです。実際に、瞬間的な評価のために制限されないスコアを、経時計測に私のモデルを使用するのも良いでしょうが、どちらにしても現状よりは良いでしょう。
ティム・アーリン: 先程言われたように、あなたはこの点では実際に正しいです。寛大に共有の目的を認めて頂いたのに、細かいことで文句を言いたくありません。私たちの目的は同じことであると思うからです。しかし、評価の正確性ではなく、実務をこなす評価システムの効果に焦点を置きたいのです。これは、精密度と正確性の相違点に触れると同時に、恐らく、もっと重要なことに、精密度の増加の収穫逓減にも触れます。ここに精密度と正確性の違いの描写記載します。
これらの条件を使用して、脆弱性のスキャン結果がどれほど間違っている可能性があるかを説明することができます。ここで見て頂きたいのは、左下の「一般的に右」とラベル付けされた標的です。企業がどのような態度を示すかにより、正確性が維持されれば、増加した精密度の価値は増加するかも知れませんし、しないかも知れません。例として、私の企業が個人的な脆弱性よりも、財産グループに対してもっと効果的な態度を示した場合、集合体のために評価の精密度が価値を失う時があります。私は、ネットワーク基盤チームよりも、Windows管理者たちをもっと奨励しなければなりません。
もっと良い見本は、非合理的な態度を示し、もっと正確なリスク評価ではなく、業界基準計測方法に焦点を置く企業でしょう。このケースでは、CVSSの様なシステムは、大変正確ですが、独特な脆弱性スコアよりも企業内でもっと多くの力を持っています。
