本連載では、グローバルスタンダードになっている「SCAP」(セキュリティ設定共通化手順)、およびそれを基にシステム構成や脆弱性の検査を行うためのOSSツール「OpenSCAP」や、その周辺の技術、用語などを紹介する。初回は、SCAPの概要について。
OSSセキュリティ技術の会の面和毅です。皆さんは、「SCAP(Security Content Automation Protocol:セキュリティ設定共通化手順)」という言葉を聞いたことがありますでしょうか。実際に「SCAP」という言葉を知らなくても、セキュリティ、特に脆弱(ぜいじゃく)性の情報を見た際に、SCAPの情報を使っていることになっているはずです。
例えば、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の使い方を見ていきます。
米国では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シリーズ)の開発が求められました。
このようにセキュリティ対策が義務付けられたため、政府省庁などではNISTの定めた規格やガイドラインに従ってセキュリティの要求事項を洗い出し、あらゆる情報システムに対して反映する必要がありました。
その結果、政府省庁でコンプライアンスへの対応に膨大な時間がかかるようになりました(図6)。
その結果、NISTがセキュリティ対策の自動化と標準化を目指すSCAPを開発しました(図7)。
Copyright © ITmedia, Inc. All Rights Reserved.