OSがCentOS 7かどうかを判定するサンプルで、SCAPの構成要素XCCDFとOVALの構造を理解する:OpenSCAPで脆弱性対策はどう変わる?(5)(1/2 ページ)
本連載では、グローバルスタンダードになっている「SCAP」(セキュリティ設定共通化手順)、およびそれを基にシステム構成や脆弱性の検査を行うためのOSSツール「OpenSCAP」や、その周辺の技術、用語などを紹介する。今回は、OSがCentOS 7かどうかを判定するサンプルで、SCAPの構成要素XCCDFとOVALの構造を理解する。
OSSセキュリティ技術の会の面和毅です。本連載「OpenSCAPで脆弱性対策はどう変わる?」では、実質的にグローバルスタンダードの「SCAP(Security Content Automation Protocol:セキュリティ設定共通化手順)」、およびそれを基にシステム構成や脆弱(ぜいじゃく)性の検査を行うためのOSS(オープンソースソフトウェア)ツール「OpenSCAP」や、その周辺の技術、用語などを紹介しています。
前回から時間が空いてしまいましたが、今回は前回の続きで、XCCDF(eXtensible Configuration Checklist Description Format:セキュリティ設定チェックリスト記述形式)ファイルやOVAL(Open Vulnerability and Assessment Language:セキュリティ検査言語)ファイルについて、OSがCentOS 7かどうかを判定するサンプル(図1)を見ながら、より深く説明していきます。
今回の説明から数回は、MITREの「About the OVAL Language」をベースにしています。今後の連載でも時々引用することになるので、SCAPに興味のある方は時間のあるときに目を通すと面白いと思います。
XCCDFとOVALの関係
XCCDFとOVALの関係に関しては、MITREが分かりやすい図にして表しています(図2)。
XCCDFでPCI DSSなどのコンプライアンスに準拠しているかどうかの監査用のファイルを記述します。XCCDFが、システムの設定や、パッチが当たっているかどうかなどを調べるときに、内部でOVALを使用(呼び出し)しています。
その意味で、まずはOVALについて説明しておきます。
OVALの構造
連載第3回でも説明しましたが、OVALはセキュリティの検査を行う言語です。OVAL言語の構成は、連載第3回に概略で説明しましたが下記の要素から成り立っています。
- スキーマ(Schema)
- ジェネレータ(Generator)
- 定義(Definitions)
- テスト(Tests)
- オブジェクト(Objects)
- ステート(States)
それぞれの関係性は図3のようになっています。
まず、Schema/Generatorがヘッダのように付いており、その後にシステム情報を取り出す定義(Definitions)を記載するようになっています。Definitionsはおのおのの情報ごとに作られており、Definitionsの中では幾つかのTestsを呼び出してそのTestsの結果を「AND」「OR」で評価して判定するようになっています。TestsはObjects/Statesから構成されています。
以降、図1のサンプルコードを見ながら、それぞれの要素を説明します。
なお、OVALにはバージョンがあり、「5.11.2」が最新(といっても3年前ですが)になっています。「oscap(openscap)」コマンドなど、SCAPを扱うツールが対応しているOVALバージョンが異なると、定義されているスキーマが正しく認識されません。
また、oscapコマンドでサポートされているOVALバージョンは、「oscap -V」コマンドの出力で分かります。CentOS 7.6では、「OVAL Version:5.11.1」と出力されるため、5.11.1以下のバージョンはサポートされます(図4)。
スキーマ(Schema)
XMLのスキーマ部分です。「xmlns="{URL}"」で、そのURLで指定されているネームスペースを使用することになります。例えば「xmlns="http://oval.mitre.org/XMLSchema/oval-definitions-5"」は、該当のURLのネームスペースを参照します。それぞれ下記のようになっています。
- OVAL Common スキーマ(xmlns:oval)
- http://oval.mitre.org/XMLSchema/oval-common-5
- OVAL Definitionスキーマ(xmlns:red-def, xmlns:unix-def)
- http://oval.mitre.org/XMLSchema/oval-definitions-5#linux
- http://oval.mitre.org/XMLSchema/oval-definitions-5#unix
- XMLスキーマインスタンス(xmlns:xsi)
- http://www.w3.org/2001/XMLSchema-instance
- スキーマロケーション(XMLスキーマ定義ファイル)(xsi:schemaLocation)
- http://oval.mitre.org/XMLSchema/oval-common-5 oval-common-schema.xsd
- http://oval.mitre.org/XMLSchema/oval-definitions-5 oval-definitions-schema.xsd
- http://oval.mitre.org/XMLSchema/oval-definitions-5#unix unix-definitions-schema.xsd
- http://oval.mitre.org/XMLSchema/oval-definitions-5#linux linux-definitions-schema.xsd
XMLスキーマ定義ファイルは、それぞれ下記のようなものになっています。
- oval-common-schema.xsd
OVAL内のさまざまなスキーマ間で共有される一般的なタイプ - oval-definitions-schema.xsd
OVAL定義をエンコードするためのコアスキーマを構成する要素、タイプ、および属性の説明 - unix-definitions-schema.xsd
OVALにある一般的なUNIXテストを構成する要素、タイプ、および属性の説明 - linux-definitions-schema.xsd
OVALにあるLinux固有のテストを構成する要素、タイプ、および属性の説明
これらのXSDファイルは、「https://github.com/CISecurity/OVALRepo/tree/master/oval_schemas/{OVALバージョン}」からダウンロードできるので、OVALに関わる開発を行う場合には一度目を通しておいた方がいいでしょう。
ジェネレータ(Generator)
このOVALドキュメント(xmlファイル:例えば図1のサンプル)が、どのように作られたかが記載されている箇所になります。下記などがあります。
- product name
- product version
- schema version
- timestamp
図1のサンプルでは、product nameは「Test OVAL」に、product versionは「0.1beta」に、schema versionは「5.11.1」に、timestampは「2019-09-20T00:11:22」になっています。
定義(Definitions)
こちらが個々のOVALファイルの定義が書かれたセクションになっています。それぞれのDefinitionsでclassを指定します。classには下記があります。
- vulnerability:システム上の脆弱性の存在を判断するテスト
- compliance:システムの構成設定がセキュリティポリシーを満たしているかどうかを判断するテスト
- patch:特定のパッチがシステムに適しているかどうかを判断するテスト
- inventory:特定のソフトウェアがシステムにインストールされているかどうかをテスト
また、それぞれのdefinitionsには「metadata」「criteria」が含まれています。それぞれ説明します。
metadata
metadataはDefinitionsを分類するために使用されます。ツールによって参照はされますが、スキャン部分には影響を与えないデータ(タイトルや、Definitionsの説明など)で構成されています。
図1のサンプルでは下記のように、タイトルや詳細をメタデータとして与えています。
<metadata> <title>For atmarkIT test: Test Scan (Important)</title> <description>RHSA test.</description> </metadata>
criteria
criteriaは、実行するテストをAND/ORなどの条件で結んだものです。下記でANDやORなどの条件を選び、
<criteria operator="AND"または"OR" />
下記で実行するテストのIDを参照して実行しています。
<criterion comment="{コメント}" test_ref="{テストのID}" />
図1のサンプルでは下記のように、test_refの箇所「:oval:com.redhat.rhsa:tst:20140675001」をテストとして実行しています。
<criteria operator="AND"> <criterion comment="CentOS 7 is installed" test_ref="oval:com.redhat.rhsa:tst:20140675001"/> </criteria>
Copyright © ITmedia, Inc. All Rights Reserved.
関連記事
- 2017年の脆弱性報告件数は過去最高の約1万4700件、まだ隠れた脆弱性がある可能性も:ESET
ESETによると、2017年は脆弱性の報告件数が前年比で2倍以上に増えて過去最高となり、中でも重大な脆弱性が近年の傾向に沿って急激に増加した。 - 外注したシステムの脆弱性は誰のせい? 連日の「深刻な脆弱性」にどう向き合い、どう対応するか?
連日のように公開される脆弱性情報の中から自分たちに関係するものを見つけ、適切な優先順位で対応するのは容易ではない。この状況に、企業はどう向き合えばよいのだろうか? @ITは、2017年8月30日にセミナー『連日の「深刻な脆弱性」どう向き合い、どう対応するか』を東京で開催した。多数の専門家やセキュリティベンダーが登壇した同セミナーの模様をお届けしよう。 - 「脆弱性情報」をどう扱うか――見つける人、流通させる人、対処する人、それぞれの視点
連日公表されるソフトウェアなどの脆弱(ぜいじゃく)性情報。2016年12月1日に行われた「Internet Week 2016」では、「脆弱性情報と賢く付き合う〜発見から対策までの最前線〜」と題したプログラムが開催された。