SCAP(セキュリティ設定共通化手順)とは何か――CVE、CVSS、CPEについて:OpenSCAPで脆弱性対策はどう変わる?(1)(2/2 ページ)
本連載では、グローバルスタンダードになっている「SCAP」(セキュリティ設定共通化手順)、およびそれを基にシステム構成や脆弱性の検査を行うためのOSSツール「OpenSCAP」や、その周辺の技術、用語などを紹介する。初回は、SCAPの概要について。
SCAPの構成要素
繰り返しますがSCAPは現在、下記のような要素で構成されています。
- CVE(Common Vulnerabilities and Exposures:共通脆弱性識別子)
- CVSS(Common Vulnerability Scoring System:共通脆弱性評価システム)
- CPE(Common Platform Enumeration:共通プラットフォーム一覧)
- CWE(Common Weakness Enumeration:共通脆弱性タイプ)
- CCE(Common Configuration Enumeration:共通セキュリティ設定一覧)
- XCCDF(eXtensible Configuration Checklist Description Format:セキュリティ設定チェックリスト記述形式)
- 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も対象に入っていたため、問題になりました。
まず、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)。
こちらの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)。
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)。
CPE(Common Platform Enumeration)
CPEは、システムを構成するハードウェア/ソフトウェアなどを識別するためのユニークなIDです。以前はMITREで管理されていましたが、現在はNISTに移管されています。CPEの辞書がNISTの「Official Common Platform Enumeration(CPE)Dictionary」からダウンロードが可能になっています。
CPEでは、ハードウェア、OS、ソフトウェアなどの識別のために構造化された名称体系を規定しています。基本構成は下記のようになっています。
cpe:/{種別}:{ベンダー名}:{製品名}:{バージョン}:{アップデート}:{エディション}:{言語}
- 種別
プラットフォームの種別。「o=OS」「h=Hardware」「a=application」などとなる - ベンダー名
ベンダーのドメイン名が記載される。組織名とドメイン名が異なる場合には、ドメイン名が優先される - 製品名
製品名が記載される。スペースを挟む製品の場合には、スペースの代わりに「_」(アンダースコア)が使われる - バージョン
製品のバージョン情報が記載される - アップデート
製品のアップデートバージョンや、サービスパックの情報が記載される - 言語
製品の言語名が(特定したい場合には)記載される
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>
「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>
この製品は、「/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"
次回は、CWE、CCEについて
次回は、SCAPの構成要素の続きとして、CWE、CCEについて見ていきます。
筆者紹介
面和毅
略歴:OSSのセキュリティ専門家として20年近くの経験があり、主にOS系のセキュリティに関しての執筆や講演を行う。大手ベンダーや外資系、ユーザー企業などでさまざまな立場を経験。2015年からサイオステクノロジーのOSS/セキュリティエバンジェリストとして活躍し、同社でSIOSセキュリティブログを連載中。
CISSP:#366942
近著:『Linuxセキュリティ標準教科書』(LPI-Japan)」
Copyright © ITmedia, Inc. All Rights Reserved.
関連記事
- 2017年の脆弱性報告件数は過去最高の約1万4700件、まだ隠れた脆弱性がある可能性も:ESET
ESETによると、2017年は脆弱性の報告件数が前年比で2倍以上に増えて過去最高となり、中でも重大な脆弱性が近年の傾向に沿って急激に増加した。 - 外注したシステムの脆弱性は誰のせい? 連日の「深刻な脆弱性」にどう向き合い、どう対応するか?
連日のように公開される脆弱性情報の中から自分たちに関係するものを見つけ、適切な優先順位で対応するのは容易ではない。この状況に、企業はどう向き合えばよいのだろうか? @ITは、2017年8月30日にセミナー『連日の「深刻な脆弱性」どう向き合い、どう対応するか』を東京で開催した。多数の専門家やセキュリティベンダーが登壇した同セミナーの模様をお届けしよう。 - 「脆弱性情報」をどう扱うか――見つける人、流通させる人、対処する人、それぞれの視点
連日公表されるソフトウェアなどの脆弱(ぜいじゃく)性情報。2016年12月1日に行われた「Internet Week 2016」では、「脆弱性情報と賢く付き合う〜発見から対策までの最前線〜」と題したプログラムが開催された。