SCAP(セキュリティ設定共通化手順)とは何か――CVE、CVSS、CPEについてOpenSCAPで脆弱性対策はどう変わる?(1)(2/2 ページ)

» 2018年07月12日 05時00分 公開
[面和毅OSSセキュリティ技術の会]
前のページへ 1|2       

SCAPの構成要素

 繰り返しますがSCAPは現在、下記のような要素で構成されています。

  1. CVE(Common Vulnerabilities and Exposures:共通脆弱性識別子)
  2. CVSS(Common Vulnerability Scoring System:共通脆弱性評価システム)
  3. CPE(Common Platform Enumeration:共通プラットフォーム一覧)
  4. CWE(Common Weakness Enumeration:共通脆弱性タイプ)
  5. CCE(Common Configuration Enumeration:共通セキュリティ設定一覧)
  6. XCCDF(eXtensible Configuration Checklist Description Format:セキュリティ設定チェックリスト記述形式)
  7. OVAL(Open Vulnerability and Assessment Language: セキュリティ検査言語)

 ここからは、それぞれの構成要素について見ていきます。

CVE(Common Vulnerabilities and Exposures:共通脆弱性識別子)

 CVEは、個別の製品の脆弱性に対して、米国政府の支援を受けている非営利団体のMITREが管理しています。

 現在、新しい脆弱性情報が公開される際に、「CVE識別番号(CVE-ID)」が割り振られて一緒に公開されます。多くのセキュリティ検査ツールやパッチ管理ツールなどでは、セキュリティ情報として、このCVE-IDが利用されています。

 CVE-IDの割り当ては実際には、MITREがメインになっている「CNA(CVE Numbering Authority:CVE採番機関)」が行います。

 CNAはこちらのサイトから見ることができます。現時点で83のCNAがあり、AppleやDell、HPE、Oracle、Red HatなどもCNAとなっていて、自社製品に脆弱性が出た場合にユニークなCVE-IDを割り当てて公開しています。

 一方、OSSに関しては「Distributed Weakness Filing Project(DWF Project)」で管理されています。DWF ProjectはOSS用途でCVE-IDをリザーブしており、脆弱性報告とリクエストがあるとIDを発行します。OSSの脆弱性を発見してDWFに報告をする場合は、こちらのフォームに従って必要項目を入力してCVE-IDを採番してもらいます。

 一般的に、CVEは「CVE-XXXX(西暦年)-YYYYY(ユニークなID)」で表されます。西暦年は脆弱性が発見され報告、修正された年が割り当てられます。

CVEの例【1】

 CVEの実際の例を、MITREのサイトで見てみましょう。図8は2017年の2月に話題になった、linux kernelの脆弱性です。広範囲(約11年前のkernel 2.6.18以降全て)に及ぶ脆弱性で、Red Hat Enterprise Linux/CentOS 5.xも対象に入っていたため、問題になりました。

図8

 まず、CVE-IDとして「CVE-2017-6074」が登録されています。ここから、この脆弱性は2017年に発見、登録された、(2017年で)通算6074番目の脆弱性情報だということが分かります。リンクの「Learn more at National Vulnerability Database(NVD)」をクリックすると、NISTが管理するNVDのサイトに飛び、詳しい脆弱性の内容が分かります。

  • 「Description」に、簡単にCVEの概要が記載されている。「どういう脆弱性なのか」「何から起因しているか」などの情報が(公開されていれば)記載されている。この辺りは、ベンダーの公開情報に依存するため、一般的な(クローズドの)商用製品などではあまり詳しい情報は記載されていない
  • 「References」に、情報が公開されている参照のリンクが記載されている。これらのリンクをたどると、「どのような脆弱性なのか」「パッチは公開されているのか」などが分かる可能性がある
  • 「Date Entry Created」にCVE情報が登録された日付が記載されている。このCVE-2017-6074の場合には、2017年2月17日に登録されたことが分かる。多くの場合、ここの日付はCVE-IDの年と同じになるが、まれに例外(下記参照)がある。

CVEの例【2】

 CVEの2つ目の実例です(図9)。

図9

 こちらのCVE-IDは「CVE-2016-10345」となっており、2016年に発見、登録されたものであることが分かります。しかし、こちらでは「Date Entry Created」に記載されている日付が「2017/04/18」です。実際にこのCVE情報がMITREのサイトから出てきたのは2017年4月18日でした。

 過去に修正されていたがMITREやその他のCNAに届け出がされていなかった場合などに、このようなことが発生します。特に現在、OSSの脆弱性調査が本格的に進められているため、このように「過去に修正されていたが、脆弱性としては登録されていなかった」ケースが散見されるようになっています。

CVSS(Common Vulnerability Scoring System:共通脆弱性評価システム)

 CVSSにはv2とv3の2つがあります。v2は2007年にリリースされましたが、仮想化やサンドボックス化などが進んできていることから、v3ではコンポーネント単位で評価が行えるように仕様が変更されています。また機密性、完全性への影響については、v2では影響を受ける範囲を評価し、v3では重要な情報に対する影響の有無を評価するようになっています。

 v2とv3は単にバージョンが古い/新しいだけではなく、脆弱性の評価を2つの視点から行っていることになるので、現在のところ、CVE-IDの情報にはv2とv3の値が併記されています。当然、v2とv3の値は異なっていることがあります。

 具体的に、先ほどCVE-IDの例として取り上げた脆弱性(CVE-2017-6074)でのCVSSスコアを見てみましょう。NISTのサイトでのCVE-2017-6074の詳細説明には、CVSS v2/v3のスコアと詳細が載っています(図10)。

図10

 CVSSの各基準は下記のように「基本評価基準(Base Metrics)」の項目となっています(図11)。

評価項目 評価 値(IPAサイト参照)
Attack Vector Local 0.55
Attack Complexity Low 0.77
Privileges Required Low 0.62
User Interaction None 0.85
Scope Unchanged -
Confidentiality High 0.56
Integrity High 0.56
Availability High 0.56
図11(基準値はIPAの「共通脆弱性評価システムCVSS v3概説」を参照)
  • Attack Vector:攻撃元の区分。「物理」「ローカル」「隣接」「ネットワーク」と4段階ある
  • Attack Complexity:攻撃条件の複雑さ。「高」「低」の2種類
  • Privileges Required:必要な特権レベル。「高」「低」「不要」の3種類
  • User Interaction:ユーザー関与レベル。「要」「不要」の2種類
  • Scope:脆弱想定範囲。「変更なし」「変更有り」の2種類
  • Confidentiality:機密性への影響。「なし」「低」「高」の3種類
  • Integrity:完全性。「なし」「低」「高」の3種類
  • Availability:可用性。「なし」「低」「高」の3種類

 これらの項目と値からCVSS v3のベーススコアが計算されます。計算の方法は、IPAのサイトに載っていますが、複雑なものです。これらの計算式とグラフは、前述のNISTのサイトの「Vector: CVSS:3.0/....」の箇所をクリックすると確認できます(図12、図13)。

図12
図13

CPE(Common Platform Enumeration)

 CPEは、システムを構成するハードウェア/ソフトウェアなどを識別するためのユニークなIDです。以前はMITREで管理されていましたが、現在はNISTに移管されています。CPEの辞書がNISTの「Official Common Platform Enumeration(CPE)Dictionary」からダウンロードが可能になっています。

 CPEでは、ハードウェア、OS、ソフトウェアなどの識別のために構造化された名称体系を規定しています。基本構成は下記のようになっています。

cpe:/{種別}:{ベンダー名}:{製品名}:{バージョン}:{アップデート}:{エディション}:{言語}
  1. 種別
    プラットフォームの種別。「o=OS」「h=Hardware」「a=application」などとなる
  2. ベンダー名
    ベンダーのドメイン名が記載される。組織名とドメイン名が異なる場合には、ドメイン名が優先される
  3. 製品名
    製品名が記載される。スペースを挟む製品の場合には、スペースの代わりに「_」(アンダースコア)が使われる
  4. バージョン
    製品のバージョン情報が記載される
  5. アップデート
    製品のアップデートバージョンや、サービスパックの情報が記載される
  6. 言語
    製品の言語名が(特定したい場合には)記載される

CPE-IDの例【1】

 NISTのサイトから、CPE Dictionaryをダウンロードして、実際にCPEの例を見てみましょう。CPE DictionaryはXMLで記載されており、製品の詳細情報も載っています。

 図14は、Red Hat Enterprise Linux 7.3のCPEです。

  <cpe-item name="cpe:/o:redhat:enterprise_linux:7.3">
    <title xml:lang="en-US">Red Hat Enterprise Linux 7.3</title>
    <references>
      <reference href="https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/
       7/html/7.3_Release_Notes/">Change Log</reference>
    </references>
    <cpe-23:cpe23-item name="cpe:2.3:o:redhat:enterprise_linux:7.3:*:*:*:*:*:*:*"/>
  </cpe-item>
図14

 「cpe-item」で始まる箇所がCPE-IDです。前章に従って確認すると、この製品は「/o」なのでOSで、ベンダーが「redhat」で、製品名は「enterprise linux」、バージョンは「7.3」を表していることが分かります。細かい製品情報は「references」句に記載されています。

 また、図15はMySQL 5.7.16のCPEです。

  <cpe-item name="cpe:/a:oracle:mysql:5.7.16">
    <title xml:lang="en-US">Oracle MySQL 5.7.16</title>
    <references>
      <reference href="http://www.oracle.com/technetwork/security-advisory/cpujan2017-2881727.html">
        Advisory</reference>
      <reference href="https://www.oracle.com/mysql/index.html">Product</reference>
    </references>
    <cpe-23:cpe23-item name="cpe:2.3:a:oracle:mysql:5.7.16:*:*:*:*:*:*:*"/>
  </cpe-item>
図15

 この製品は、「/a」なのでアプリケーションであり、ベンダーが「oracle」で、製品名は「mysql」、バージョンは「5.7.16」であることが分かります。細かい情報は、「references」句に記載されています。

CPE-IDの例【2】

 一部のOSなどは、既に製品にCPE-IDが入っているものがあります。

 図16は、Red Hat Enterprise Linux 7.4の/etc/os-releaseです。CPEが「cpe:/o:redhat:enterprise_linux:7.4:GA:server」と記載されていることが分かります。

NAME="Red Hat Enterprise Linux Server"
VERSION="7.4 (Maipo)"
ID="rhel"
ID_LIKE="fedora"
VARIANT="Server"
VARIANT_ID="server"
VERSION_ID="7.4"
PRETTY_NAME="Red Hat Enterprise Linux"
ANSI_COLOR="0;31"
CPE_NAME="cpe:/o:redhat:enterprise_linux:7.4:GA:server"
HOME_URL="https://www.redhat.com/"
BUG_REPORT_URL="https://bugzilla.redhat.com/"
 
REDHAT_BUGZILLA_PRODUCT="Red Hat Enterprise Linux 7"
REDHAT_BUGZILLA_PRODUCT_VERSION=7.4
REDHAT_SUPPORT_PRODUCT="Red Hat Enterprise Linux"
REDHAT_SUPPORT_PRODUCT_VERSION="7.4"
図16

次回は、CWE、CCEについて

 次回は、SCAPの構成要素の続きとして、CWE、CCEについて見ていきます。

筆者紹介

面和毅

略歴:OSSのセキュリティ専門家として20年近くの経験があり、主にOS系のセキュリティに関しての執筆や講演を行う。大手ベンダーや外資系、ユーザー企業などでさまざまな立場を経験。2015年からサイオステクノロジーのOSS/セキュリティエバンジェリストとして活躍し、同社でSIOSセキュリティブログを連載中。

CISSP:#366942

近著:『Linuxセキュリティ標準教科書』(LPI-Japan)」


前のページへ 1|2       

Copyright © ITmedia, Inc. All Rights Reserved.

スポンサーからのお知らせPR

注目のテーマ

AI for エンジニアリング
「サプライチェーン攻撃」対策
1P情シスのための脆弱性管理/対策の現実解
OSSのサプライチェーン管理、取るべきアクションとは
Microsoft & Windows最前線2024
システム開発ノウハウ 【発注ナビ】PR
あなたにおすすめの記事PR

RSSについて

アイティメディアIDについて

メールマガジン登録

@ITのメールマガジンは、 もちろん、すべて無料です。ぜひメールマガジンをご購読ください。