現在、技術者の経験を主とするセキュリティ設計、セキュリティ運用手法の利用により、手作業での脆弱性影響判断の確認が頻繁に行われています。そのような状況の中、米国ではSCAP（Security Content Automation Protocol）と呼ばれる、情報セキュリティの技術面での自動化と標準化を規定した技術仕様の策定が進められています。SCAPは6つの標準仕様で構成されており、その中にはソフトウェアの脆弱性情報や、脆弱性レベルなどの標準仕様が含まれています。

しかし、ネットワークシステムにおいて脆弱性の影響範囲を特定し対策の判断を行うためには、脆弱性情報だけでなく、システムの構成要素がどのように存在するか、また攻撃が対象に到達可能であるかといった情報が必要になります。そこで、モデルと脆弱性情報の対応付けを行うことで、自動的に脆弱性影響度の評価を行う手法を提案しました。

脆弱性情報(CVSS)

脆弱性による影響を数値化する代表的な手法として、SCAPの標準仕様の1つであるCVSS（Common Vulnerability Scoreing System）があげられます。CVSSは基本評価基準、現状評価基準、環境評価基準の3つの評価基準により評価を行います。基本評価基準は脆弱性そのものの特性として攻撃経路情報、認証の必要性、攻撃の複雑さ、機密性、可用性、完全性に対する影響を評価します。現状評価基準は攻撃コードの有無や脆弱性への対応状況による深刻度を、環境評価基準は実際に攻撃を受けるシステムへの影響度を評価します。各基準への影響度は「なし」「部分的」「全面的」の3段階で評価されます。3つの基準のうち、環境評価基準はユーザの環境に応じてユーザが判断するため、結果として値が定量的に定まらないものとなっています。

また、このCVSSを含む脆弱性情報がNVD（National Vulnerability Database）という脆弱性情報提供サービスによって提供されています。NVDは脆弱性情報のXML Schemaを持ち、脆弱性情報はHTMLのほかにXMLファイルでも提供されます。しかしWebブラウザでの閲覧を前提としたインタフェースであるため、システムが自動的にデータを利用するというよりも、人による利用が主となっています。

脆弱性影響度の定量化

ネットワークシステムにおける脆弱性の影響を評価するためには攻撃そのものの情報と、攻撃を受けるネットワークシステムの情報が必要であり、ネットワークシステムの構成要素と脆弱性情報の構成要素が比較可能なデータモデルとなっていることが望ましいと言えます。それを実現するため、モデルを拡張し、攻撃の到達性を考慮した上での攻撃対象ノード数の総和が全体ノード数の何割にあたるかを計算することで定量化を行いました。

脆弱性情報とモデルの関連付け

モデル上で脆弱性情報を扱うため、以下のようにシステム構成情報の各要素を通信層に分類し、モデルのノードに対してモデル拡張を行いました。

Layer attribute
5 Application Data flow
4 Application name / Version
3 OS name / Version
2 -
1 Product name / Vendor

さらに、NVDが提供している脆弱性情報のXML Schemaと拡張したモデルの構成情報を対応付けを行いました。ファイアウォールを挟んだ2台のサーバが通信を行う場合のモデルへのマッピング例は以下のようになります。

攻撃到達性の評価

ファイアウォール等によりアクセス制御が行われている場合、脆弱性が存在したとしても、攻撃が該当機器まで到達せず、脆弱性の影響を受けない可能性があります。そのため、単純に脆弱性のあるアプリケーションがネットワークシステム内部に存在するというだけでは影響を判断できず、通信の到達性を評価する必要があります。パス探索等により通信経路を調べる手法では経路探索の計算コストが高く規模の大きなシステムでは適用が困難ですが、モデルでは各通信層でアクセス可能なノードが接続されるため、到達性に関しては攻撃の起点と攻撃対象が接続されているかどうかで判断が可能です。よって、そのモデル特性をそのまま到達性の確認要件としました。

被害範囲

ネットワークシステムが何らかの攻撃を受けた場合、攻撃の対象となったノードが直接的な被害を受ける以外に、ネッワークシステム内部の他のノードに二次的な被害が発生する可能性があります。機密性、完全性に関する攻撃の二次被害と可用性に関する攻撃の二次被害とでは被害範囲が異なることが考えられたため、セキュリティ項目毎の脆弱性影響の特徴や傾向を、NVDを用いて調査しました。調査の結果、脆弱性影響拡大のパターンを2つに大別しました。1つは、リソースの枯渇などによる可用性への影響から、通信経路を通して他の機器（モジュール）への影響を誘発しうるものです。もう1つは、攻撃対象となったOSやソフトウェアに依存する上位のアプリケーションやサービスへの影響が考えられる一方で、他の機器への影響は考えにくいものです。以上の事を踏まえ、脆弱性の影響範囲を以下のように定義しました。

次に、上記定義の適用例を紹介します。

まず、可用性への影響があり、他の機器への影響を考慮するものについて説明します。右図のネットワークシステムは、左がWAN（インターネット）、右がLANを示しており、中央付近のL4Rに属するL4ノードが可用性影響を含む脆弱性による攻撃を受けたと仮定します。

すると、攻撃によりリソースが枯渇するため、L4Rの機器としての機能が失われ、影響はモジュール全体に拡大します。ここで、L4Rの冗長性を見ると、WANからLANに通信する際にはこのL4Rを介することが必須であることが分かります。すなわち、このL4Rの中継機能が失われることで、WANからLANへのアクセスが不可能になり、WAN側から見るとその奥にあるサービスの可用性も失われていると言えます。

以上の理由から、最終的な影響範囲は右図のようになります。可用性に対する脆弱性は非常に大きな影響へと発展し易いことが見て取れますが、特に多くの機器と接続している中継機器はその傾向が強いと考えられます。

続いて、同様の脆弱性が冗長化されたモジュールに存在した場合を仮定します。左図のように、あるサービス（L5ノード）を提供しているサービスモジュールのL4ノードが可用性影響を含む脆弱性による攻撃を受けたとします。すると先程と同様に、リソースの枯渇によりモジュール全体に影響が拡大します。ただし、この時点ではL5ノードは影響範囲に含みません。

ここでサービスモジュールの冗長性を確認します。L5ノードから出ている依存関係リンクは、攻撃対象となっているモジュールとは異なるサービスモジュールにも接続しているため、このサービスは2台のサーバによる冗長構成が取られてることが分かります。すなわち、いずれか片方のサーバがダウンしたとしても、もう片方によるサービスの継続が可能であり、影響がこれ以上拡大することはありません。

最後に、可用性への影響が認められない、その他の脆弱性についての影響範囲を示します。ここでは、先程と同様のサービスモジュールに属するL3ノードに脆弱性が存在すると仮定します。脆弱性はそのOSまたはアプリケーションに存在するため、同一モジュールにおける同一レイヤのノードも同じ脆弱性を持つと考えることができ、まずそれらを影響範囲に含みます。

そして、その影響は依存関係リンクを逆に辿った先の全てのノードに及びます。すなわち、L3ノードに脆弱性があった場合はL3, L4, L5ノードが、L4ノードに脆弱性があった場合はL4, L5ノードが影響範囲となります。なお、可用性に対する脆弱性と異なり、冗長化によりL5ノードの影響が防がれることはありません。何故なら、サービスとしては稼働状態にあるため、脆弱なサービスへのアクセスが可能な状態にあるためです。

最終的な影響範囲は以下のようになります。可用性への影響と異なり、単体での影響範囲は小さなものとなりますが、サービスへの影響が現れやすく、特にデータベース等への影響は非常に深刻なものになると考えられます。ただし、そうしたモジュールや扱う情報に対するセキュリティ要求などの定量化に関しては今後の課題としています。

CVSSへの適用

CVSSの定義と照らし合わせ、被害対象をTarget Distribution（TD）として関連付けを行いました。TDは4段階に分類されていますが、粒度が非常に粗く、また判断基準も明確でないため、再現性の低いものとなっています。

そこで、先程の影響範囲の定義において、脆弱性影響ノード数をNA、インターネットを除くすべてのノード数をN、影響対象となるノード数が全体ノード数に占める割合 （NA/N）を被害対象TDとして対応付けを行いました。これにより、より精密な値を一意に決定することができるようになります。