SCAP(セキュリティ設定共通化手順)とは何か――CVE、CVSS、CPEについて:OpenSCAPで脆弱性対策はどう変わる?(1)(1/2 ページ)
本連載では、グローバルスタンダードになっている「SCAP」(セキュリティ設定共通化手順)、およびそれを基にシステム構成や脆弱性の検査を行うためのOSSツール「OpenSCAP」や、その周辺の技術、用語などを紹介する。初回は、SCAPの概要について。
企業の脆弱性対策に役立つ、SCAP(セキュリティ設定共通化手順)とは
OSSセキュリティ技術の会の面和毅です。皆さんは、「SCAP(Security Content Automation Protocol:セキュリティ設定共通化手順)」という言葉を聞いたことがありますでしょうか。実際に「SCAP」という言葉を知らなくても、セキュリティ、特に脆弱(ぜいじゃく)性の情報を見た際に、SCAPの情報を使っていることになっているはずです。
セキュリティの情報共有やOSの設定などで使われている
例えば、IPA(情報処理推進機構)のサイトでStruts2の脆弱性情報を見たとき「CVE-{年}-{番号}」という記述を見たことがあると思います(図1)。
また、ソフトウェアやディストリビューションから提供される「セキュリティアドバイザリー」などにも「CVE-{年}-{番号}」「CWE-{番号}」「CVSS」などという記述があるのを見たことがあると思います(図2、図3)。
これら「CVE(Common Vulnerabilities and Exposures)」「CWE(Common Weakness Enumeration)」「CVSS(Common Vulnerability Scoring System)」などは、「SCAP」というプロトコルに含まれる、各脆弱性に対してユニークな番号を与えたり、カテゴライズしたり、影響範囲を記述したりするための要素になります。
さらに、これらは単にディストリビュータから提供される情報だけではありません。皆さんのOSの中にも、「CPE(Common Platform Enumeration)」というユニークな番号が記述されています(図4)。
また、Red Hat Enterprise LinuxやCentOSなどのインストールを行うときに「SECURITY POLICY」を強制できる項目が付いていますが、こちらにもSCAPの要素が使われています(図5)。
このように「SCAP」は、あまりなじみがない言葉かもしれませんが、実際にはセキュリティの情報共有やOSの設定などで使われています。
本連載について
本連載では、このように実質的にグローバルスタンダードになっている「SCAP」、およびそれを基にシステム構成や脆弱性の検査を行うためのオープンソースソフトウェア(OSS)ツール「OpenSCAP」や、その周辺の技術、用語などを紹介していきます。これらは企業の脆弱性対策に役立つものになります。
今回から数回にかけて、SCAPの歴史的背景と、下記のようなSCAPの構成要素について説明していき、その後、OpenSCAPの使い方を見ていきます。
- 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: セキュリティ検査言語)
SCAPの背景
FISMA(連邦情報セキュリティ管理法)
米国では2001年9月11日のテロ発生以降、政府としてのセキュリティ対策が大きく変わりました。特に大きなものが、2002年12月に成立した「FISMA(Federal Information Security Management Act:連邦情報セキュリティ管理法)」と呼ばれるものです。
このFISMAでは、連邦政府機関や連邦政府機関から業務委託を受けている民間の外部委託先が、情報セキュリティを強化することが義務付けられています。さらに、最低でも年に一度情報セキュリティの有効性についてのレビューを行い、OMB(Office of Management and Budget:米国合衆国行政管理予算局)に報告書を提出することも義務付けられています。その他、各省庁では昨今耳にするようになったCSO(Chief Security Officer:情報セキュリティ責任者)の設置なども求められています。
そして、NIST(National Institute of Standards and Technology:米国国立標準技術研究所)には、そのための規格としてのFIPS(Federal Information Processing Standards:連邦情報処理標準)やガイドライン(SP8000シリーズ)の開発が求められました。
SCAPの登場
このようにセキュリティ対策が義務付けられたため、政府省庁などではNISTの定めた規格やガイドラインに従ってセキュリティの要求事項を洗い出し、あらゆる情報システムに対して反映する必要がありました。
その結果、政府省庁でコンプライアンスへの対応に膨大な時間がかかるようになりました(図6)。
その結果、NISTがセキュリティ対策の自動化と標準化を目指すSCAPを開発しました(図7)。
Copyright © ITmedia, Inc. All Rights Reserved.
関連記事
- 2017年の脆弱性報告件数は過去最高の約1万4700件、まだ隠れた脆弱性がある可能性も:ESET
ESETによると、2017年は脆弱性の報告件数が前年比で2倍以上に増えて過去最高となり、中でも重大な脆弱性が近年の傾向に沿って急激に増加した。 - 外注したシステムの脆弱性は誰のせい? 連日の「深刻な脆弱性」にどう向き合い、どう対応するか?
連日のように公開される脆弱性情報の中から自分たちに関係するものを見つけ、適切な優先順位で対応するのは容易ではない。この状況に、企業はどう向き合えばよいのだろうか? @ITは、2017年8月30日にセミナー『連日の「深刻な脆弱性」どう向き合い、どう対応するか』を東京で開催した。多数の専門家やセキュリティベンダーが登壇した同セミナーの模様をお届けしよう。 - 「脆弱性情報」をどう扱うか――見つける人、流通させる人、対処する人、それぞれの視点
連日公表されるソフトウェアなどの脆弱(ぜいじゃく)性情報。2016年12月1日に行われた「Internet Week 2016」では、「脆弱性情報と賢く付き合う〜発見から対策までの最前線〜」と題したプログラムが開催された。