トリアージ値の定量化はいかにして行われたか

前回に引き続き、今回は「脆弱性定量化に向けての検討報告書」で定義される「トリアージ値」について、具体的な定量化の考え方を見ていくことにしよう。

まず「トリアージ値」の定義からおさらいしておこう。前回はトリアージ値を「病気になったサーバの処置の優先度を表す指標」であると述べたが、報告書では「意思決定者がフィックス行為を実施するにあたって、その実行可否と実行タイミングを判断するために利用できる指標として使える数値」と定義している。ここで特に重要なの点は、「判断するために利用できる」と明確に宣言していることだ。漠然とした概念的な値ではなく、きちんと現場で利用可能な指標として定義するためには、まず複雑な相互関係が絡み合って発生する「リスク」を正しくモデル化する必要がある。そこで、モデル化に必要な要素として挙げられたのが、前回に述べた12のオブジェクトである。

さて、各要素はそれぞれ、管理者にとって「好ましい」ものと「好ましくない」ものに分けられる。例えば「ホワイトハット」は好ましいが、「ブラックハット」は好ましくないものだ。さらに、各要素は相互に「好ましい影響」「好ましくない影響」を与えあう。「『バグフィックス』が『攻撃主体』の動機を奪う」のは好ましい影響、「『ブラックハット』が『攻撃主体』に手段を与える」のは好ましくない影響、といった具合だ。さらに、これらの関係性には、時間軸にそった3つの段階があると考えられる。すなわち、「脆弱性の発生(1st)」「世の中の動き(2nd)」「資産に影響(3rd)」の3つのステージである。図1は、この時間上の分類を反映した、最終的なセキュリティリスクのモデル図である。

好ましいオブジェクトと関係、好ましくないオブジェクトと関係が、最終的に「資産」に対して影響を及ぼすまでの流れとして、きれいにモデル化されていることが図1からわかるだろう。なお、図中で「TV」として表されるのがトリアージ値で、管理者にとって「TV+」がネガティブな値、「TV-」がポジティブな値である。

ここまでで、トリアージ値の定量化に向けた流れは理解できただろう。次に、実際にTV+やTV-をどのような基準で算定するかについて、見ていこう。報告書では「フィックス」のオブジェクトを例に算定の手順や数式が説明されているが、簡単に言えば、オブジェクトの持つ属性やオブジェクトに対するインとアウトの影響それぞれに値を設定し、その総和を求めていく形を採っている。そこで、オブジェクト属性や影響に設定される「パラメータ値」そのものが極めて重要になるわけだが、この値については、ワーキンググループでの議論によって決定され、さらに実際の事例に基づいて修正を繰り返した値が採用されているという。図1にパラメータを反映したものを図2に示す。

何かリスクが発生した場合に、この図に沿って計算していけば、そのリスクに関するトリアージ値が算出できる。管理者はトリアージ値を見て、自分のシステムに「すぐにパッチを適用すべきか」を判断できる。さらに、上司に対して「トリアージ値がこれこれだったからパッチをあてました」とか、「パッチは急がなくていいので何月何日にあてます」といった説明責任も果たせるようになるわけだ。

ところで、読者の皆さんの中には、「定量化って言っても、結局パラメータ値は恣意的に決まってしまうのか?」という疑問を持つ方もいらっしゃるかもしれない。確かに、「議論」に基づいて決定されたパラメータ値は、ワーキンググループに参加しているメンバの知識や経験や思想に基づくものであって、人が変われば変動するものかもしれない。しかし、大切なのは成果として定義された「トリアージ値」が、現場で「使える指標かどうか」である。

ワーキンググループでは、これを検証するためにサーバ管理者を対象としたアンケートを実施し、トリアージ値とアンケート結果の比較分析を行っている。この分析の結果を見ると、脆弱性に対するサーバ管理者の意識と算出されたトリアージ値にはある程度の相関関係が見られ、元になるセキュリティモデルや、各パラメータの値が大筋で見当違いなものでないことがわかる。そして何より、複雑に絡み合ったリスクの関係性を整理し、モデル化を試みたワーキンググループの努力には、率直に拍手を贈るべきだろう。