「許せる脆弱性」と「許せない脆弱性」がある！？　その判断基準とは――

　皆さんは「許せる（forgivable）脆弱性」と「許せない（unforgivable）脆弱性」と聞いて何を思い浮かべるでしょうか？　おそらく多くの方がソフトウェアなどの利用者側の立場でパッチ適用の優先順位を決める指標の1つと考えるのではないでしょうか。つまり、「許せない脆弱性」は許容できないので速やかにパッチを適用すべきであり、「許せる脆弱性」は許容できるのでパッチ適用が多少遅れても、場合によっては未適用でも、特に問題ないと判断するといったものです。

　ところが、英国家サイバーセキュリティセンター（National Cyber Security Centre、以降NCSC）が公開した論文「A method to assess 'forgivable' vs 'unforgivable' vulnerabilities（“許せる”脆弱性と“許せない”脆弱性を評価する方法）」は観点が違うのです。

　実は、この「許せない（unforgivable）脆弱性」という表現はNCSCによる造語ではなく、MITREのSteve Christey氏の2007年の論文「Unforgivable Vulnerabilities」で使われた表現で、そこでは以下のように説明されています。

「セキュアな開発手法が組織的に無視されている兆候である。セキュリティを考慮して設計、開発、テストされたソフトウェアであれば、絶対にあってはならないものである」

　さらにChristey氏は「許せない脆弱性」のうち最も一般的なものを取り上げ、それを踏まえて、研究コミュニティがソフトウェア製品の相対的なセキュリティの指標として使用できる一連の脆弱性評価保証レベル（Vulnerability Assessment Assurance Level：VAAL）を確立することを提案しています。

　このことから分かるように、この論文における「許せない」とは「絶対にあってはならない」脆弱性を組み込んでしまった開発者に向けた表現であり、「許せない脆弱性」とはソフトウェアの利用者ではなく、脆弱性の研究者に使ってもらうことを意図した言葉なのです。

　そのうえで、NCSCはこのChristey氏の論文のアイデアを拡張し、脆弱性に対して「許せる」か「許せない」かを評価する方法を提案する目的で、今回の論文を作成・公開したのです。NCSCとしては、簡単に見つけられる脆弱性、特に何度も発生する脆弱性を大幅に削減したいと明言しており、その意図を開発者に向けて強く訴えるために「許せない」という厳しめの表現を採用したのかもしれません。確かに、同じような脆弱性が発生し続けている現実を考えると「許せない」と言いたくなる気持ちは分かります。

　ちなみに、NCSCは今回の論文の背景として過去のさまざまな論文を引用し、ソフトウェアのバグの平均数は過去20年間一定のままであること、さらにソフトウェアの平均欠陥度としてソースコード1000行（thousand lines of code：KLOC）あたりの欠陥数の統計データを紹介し、ソフトウェア製品や使用されるプログラミング言語が何であってもソフトウェアの欠陥は常に存在することを説明しています。

　ここで最初の話に戻ると、利用者側が今回のNCSCによる「許せるか否か」の評価基準をパッチ適用の優先度を決める指標の1つとして使うことは可能かもしれませんが、それは本来意図されたものではないことに注意が必要です。少なくとも今回の論文による評価基準では悪用された場合の影響度や使用環境は考慮されていないので、「許せる」脆弱性であっても必ずしも許容できるとは限らないものも当然あるでしょう。

　ところで、ここまで読まれた方はすでにお気付きかと思いますが、今回のNCSCの論文における「forgivable」と「unforgivable」を、英語の本来の意味を踏まえて、より正確に翻訳するのであれば、それぞれ「大目に見てやれる」「弁解できない」としたほうが適切なのですが、本稿では表現をシンプルにするために敢えて「許せる」「許せない」としていることをご了承ください。

　今回の論文の目的をNSCSは、セキュリティ専門家がソフトウェアの脆弱性に対して以下に定義されるように「許せる」か「許せない」かを判断できる方法を定めることであるとしています。

許せる脆弱性

既知の緩和策を実装することが困難であると判断されるため、ソフトウェアに存在する脆弱性。これには次のような理由が考えられる：

• その脆弱性が容易には気付かないもの（subtle）である
• その脆弱性に関する知識が不足している
• その緩和策を実装するためのコストが高すぎる
• その緩和策を技術的に実装するための前提条件が多すぎる（あるいは複雑すぎる）

許せない脆弱性

緩和策を実装する難易度が無視できるほど小さいと判断されるため、ソフトウェアに存在すべきでない脆弱性。これには次のような理由が考えられる：

• その緩和策が完全に文書化されている
• 実装が安価である
• その緩和策を技術的に実装するための前提条件が多すぎない（または複雑すぎない）

注：1つの脆弱性に対して複数の原因が存在し、その原因ごとに緩和策が異なる場合がある。

悪用不可能な脆弱性

我々が「悪用不可能（Non-exploitable）」と呼んでいる第3の脆弱性クラスがある。このクラスについては本稿ではこれ以上説明しないが、間違いなく、これはセキュリティリスクではない脆弱性である。これには次のような理由が考えられる：

• その脆弱性を悪用するコードパスが存在しない、または
• その脆弱性が悪用されるのを防ぐための緩和策が実施されている、または
• 脆弱性の連鎖によって悪用される可能性が低い

　今回のNCSCの研究では「2023 CWE Top 25 Most Dangerous Software Weaknesses」を使って、脆弱性の「根本原因」（個々の脆弱性それぞれ固有の原因ではない）を特定し、さらにこれらの脆弱性を管理するために必要な11のトップレベルの緩和策を特定したうえで、その各緩和策に対して以下の基準に基づいた「実装の容易さ（ease of implementation）」のスコアを付けています。

• コスト：直接コスト（ライブラリのライセンスなど）と間接コスト（コーディングや再コード化に必要な追加時間など）を含む。
• 知識：その緩和策がどれだけ広く知られ、理解されているか。
• 技術的実現可能性：実現可能性分析では、その緩和策が成功する可能性と、その緩和策の実現がどれだけ容易であるかを評価する。これには、その緩和策の利点と欠点、技術的要件や前提条件（ハードウェアのサポートなど）の評価も含まれる。

　上記3つの基準に対し、それぞれ3点満点で、「容易／安価」なら1点を、そうでないなら3点を、どちらとも言えない中間の場合は2点を付け、3つを合計した点数を実装の容易さを示すスコア（実装スコア）とします。それが3または4なら「容易」、5または6なら「中程度」、7以上であれば「困難」とし、最終的に「容易」と評価された脆弱性は「許せない」とされます。以下の表は、11のトップレベルの緩和策の実装スコアをまとめたものです。論文ではこれらの11の緩和策それぞれについて、実装スコアの内訳と、そのように評価した理由を説明しています。

　論文の最後では今後の課題として、以下の3つの要素を考慮することで評価方法を改良できるだろうと記しています。

• 製品の役割と脆弱性の深刻度（例えば、製品がインターネットに面したサービスで、認証前に脆弱性が悪用される可能性がある場合など）
• ベンダー／開発者の脆弱性管理の成熟度を判断する方法（例えば、ベンダーが製品の想定されるライフサイクル全体に渡って脆弱性を監視しているかどうかなど）
• 脆弱性に気付かない（それが後に悪用される）ことは「許せない」ことなのか、他の要因も考慮すべきなのか（バグ／脆弱性のクラスとその典型的な緩和策を知ることを含む）

　現時点ではあくまで開発者や脆弱性の研究者向けであり、簡単に言ってしまえば「製造者責任を問う」ための指標とも言えますが、既存のものとは異なる観点の脆弱性評価基準として、今後の進化や発展には注目したいところです。