Hitach Incident Response Team

 今回は「米国のぜい弱性対策に関する取り組み」の第2回です。第1回は連邦情報セキュリティマネジメント法と,情報セキュリティにかかわる技術面での自動化と標準化を目指した取り組みであるISAP(Information Security Automation Program)について紹介しました。第2回はISAP実現のための技術仕様であるSCAP(Security Content Automation Protocol)[*1]について紹介します。

■ISAPを支える技術仕様SCAP

SCAP(エスキャップ)は現在6種類の仕様から構成されています。

  • Security Content Automation Protocol(SCAP)
    • Common Vulnerabilities and Exposures(CVE)
    • Common Configuration Enumeration(CCE)
    • Common Platform Enumeration(CPE)
    • Common Vulnerability Scoring System(CVSS)
    • Extensible Configuration Checklist Description Format(XCCDF)
    • Open Vulnerability and Assessment Language(OVAL)

 これらの仕様の関係は図1の通りです。図1は規格やガイドラインを順守して情報システムを利用しているかどうかを確認するための手順です。まず,規格やガイドラインを基にセキュリティ・チェックリストを作成します。XCCDFはこのセキュリティ・チェックリストを記述するための仕様です。チェックリストの項目を記述する際には,製品情報にはCPE,プログラム上のセキュリティ問題にはCVE,設定上のセキュリティ問題にはCCEという識別情報を利用します。CVSSはプログラム上のセキュリティ問題の深刻度を判定する際の参考となります。また,チェックリストの各項目を実際に調査する際には,OVALで記述されたチェック方法に従いOVALインタプリタが調査し,その結果を報告するという流れになります。それでは,6種類の仕様の概要をみていきましょう。

図1 SCAP を利用したセキュリティチェックの流れ

■ぜい弱性識別子を規定するCVE

http://cve.mitre.org/

 プログラム自身に内在する『プログラム上のセキュリティ問題』に一意の番号(ぜい弱性識別子)を付与する仕様です。例えば2003年8月に流布したネットワーク型ワーム「MS Blaster」は,WindowsのRPCインタフェースのぜい弱性 MS03-026を悪用しました。MS03-026で報告されているぜい弱性には,ぜい弱性識別子としてCVE-2003-0352 が割り当てられています。

■設定項目識別子を規定するCCE

http://cce.mitre.org/

 プログラムが稼働するための『設定上のセキュリティ問題』を解決するための仕様で,セキュリティと関連する設定項目に一意の番号(設定項目識別子)を付与します。

 セキュリティというとパスワードの話が良く取上げられます。ただパスワード設定に関連した項目にも,パスワードの有効期限,パスワードの長さ(何文字以上など),パスワードの複雑さ(英数字以外の使用など),パスワードの履歴管理(同じパスワードを使えない回数)など,いくつか項目があります。CCEでは,これら一つひとつの設定項目に一意の番号を付与して管理します。例えば,2007年6月21日にリリースされたCCE v4.0では,パスワードの最大有効期限には設定項目識別子CCE-871,パスワードの長さにはCCE-100 が割り当てられています。

■製品識別子を規定するCPE

http://cpe.mitre.org/

 情報システム,プラットフォーム,ソフトウエア・パッケージに一意の名称を付与する仕様で,ぜい弱性識別子CVE,設定項目識別子CCEと製品との関連付けを手助けします。情報システム,プラットフォーム,ソフトウエア・パッケージの照合を行なうための識別情報として利用することができます。例えば,日立のネットワーク管理製品であるJP1/Cm2/Network Node ManagerをCPE V1.0で記述すると,製品開発者名と製品名とをコロン(:)で連結したcpe:///hitachi:cm2-network_node_manager となります。

 あるぜい弱性がシステムに及ぼす影響について考える場合,「ぜい弱性の影響を受ける製品が情報システムに組み込まれているか」,「情報システムに組み込まれている製品には,該当するぜい弱性の影響はあるか」という二つのアプローチがありますが,どちらのアプローチでチェックするにしても,そのぜい弱性の影響を受ける製品の一覧と,情報システムに組み込まれている製品の一覧を照合する必要があります。

■ぜい弱性を評価するCVSS

http://www.first.org/cvss/cvss-guide.html

 以前にもこのコラムで紹介した,共通ぜい弱性評価システム[*2]です。ぜい弱性自体の特性を評価する「基本評価基準」,パッチ・プログラムの提供状況などを考慮する「現状評価基準」,ユーザー環境での影響度を考慮する「環境評価基準」を使ってぜい弱性の影響度を評価します。評価結果は0.0~10.0の値で表します。現在のCVSSは,CVEが取り扱うプログラム自身に内在する『プログラム上のセキュリティ問題』を対象とした仕様となっています。
[*2] 情報処理推進機構:共通脆弱性評価システムCVSS v2概説

■チェックリストの記述仕様XCCDF

http://nvd.nist.gov/xccdf.cfm

 セキュリティ・チェックリストやベンチマークなどの文書を記述するための仕様です。例えばプログラムが稼働するための『設定上のセキュリティ問題』について,組織としてチェックすべき設定項目を用意します。  ここでは,チェックすべき設定項目としてパスワードに関する設定項目を考えてみます。この場合,パスワードの有効期限,パスワードの長さ,パスワードの複雑さ,パスワードの履歴管理などの具体的な項目をCCE と共にリストアップし,XCCDFの仕様に沿ってチェックリストを作成します。プログラム自身に内在する『プログラム上のセキュリティ問題』についても同様で,「セキュリティ修正プログラムの適用」「MS Blaster対策」という項目をXCCDF の仕様に沿って作成し,チェックリストに追記すればよいわけです。

 次に,各項目の確認には次に示すOVAL を利用します。XCCDFでガイドラインに準拠しているかを把握できるようチェックリストを作成し,それをOVALというチェック技術で確認するという流れになります。

■ぜい弱性/設定項目のチェック技術OVAL

http://oval.mitre.org/

 プログラム自身に内在する『プログラム上のセキュリティ問題』や,プログラムが稼働するための『設定上のセキュリティ問題』などをチェックをするための仕様です。汎用的に作られた仕様で, セキュリティ修正プログラム適用状況や,稼働しているプラットフォーム/ソフトウエア・パッケージの判定にも利用できます。

 OVAL開発を担当しているMitreでは,チェック方法をXMLファイルに記述する仕様だけではなく,そのXMLファイルに従い『プログラム上のセキュリティ問題』や『設定上のセキュリティ問題』をチェックするプログラム(OVALインタプリタと呼ばれています)を参照実装として提供しています。

 次回は,ぜい弱性識別子を規定するCVE について紹介する予定です。


寺田 真敏
Hitachi Incident Response Team
チーフコーディネーションデザイナ

HIRT(Hitachi Incident Response Team)とは

HIRTは,日立グループのCSIRT連絡窓口であり,脆弱性対策,インシデント対応に関して,日立グループ内外との調整を行う専門チームです。脆弱性対策とはセキュリティに関する脆弱性を除去するための活動,インシデント対応とは発生している侵害活動を回避するための活動です。HIRTでは,日立の製品やサービスのセキュリティ向上に関する活動に力を入れており,製品の脆弱性対策情報の発信やCSIRT活動の成果を活かした技術者育成を行っています。