SCAPの構成要素、CWE(共通脆弱性タイプ)、CCE(共通セキュリティ設定一覧)とは:OpenSCAPで脆弱性対策はどう変わる?(2)(2/2 ページ)
本連載では、グローバルスタンダードになっている「SCAP」(セキュリティ設定共通化手順)、およびそれを基にシステム構成や脆弱性の検査を行うためのOSSツール「OpenSCAP」や、その周辺の技術、用語などを紹介する。今回は、CWE(共通脆弱性タイプ)、CCE(共通セキュリティ設定一覧)について。
CCE(Common Configuration Enumeration:共通セキュリティ設定一覧)
CCEは、コンピュータのセキュリティ設定項目にユニークなIDを割り振るための仕様です。「設定上のセキュリティの問題」を確認、解決するために定められました。
CCEは、米国政府の支援を受けている非営利団体のMITREが中心となって作成した「CCE Working Group」が、OSベンダーと協力しながら作成しました。以前はMITREが管理していましたが、現在はNIST(米国国立標準技術研究所)が管理しています。
なお、CCE IDの番号の割り振りについては、CCEのFAQによると、下記形式で登録されます。この際、{チェック番号}は「Luhnチェックアルゴリズム」によって割り振られます。
CCE-{識別子}-{チェック番号}
CCEの最新バージョンは、現在NISTのサイトで公開されているものですと、2013年2月に公開されたCCEv5(5.20130214)になります。RHEL 6、7などのCCEも開発されていますが、公開が遅れています(理由は後述します)。
CCEv5の中身
CCEのサンプルファイルは、前述のようにNISTのサイトからダウンロードできます。CCEv5をダウンロードして中身を見てみましょう。
CCEは通常XML形式で記載されています。今回は、分かりやすいExcel形式の「CCE v5 - Red Hat Enterprise Linux 5」をダウンロードして、代表的な例をピックアップしました。
図6を見てください。
まず、各項目を説明します。
- CCE ID:前述のCCE IDが入る
- CCE Description:CCEの説明
- CCE Parameters:CCEでの設定値のパラメーターが記載される
- CCE Technical Mechanism:「実際に、どのファイルを編集したり、コマンドを実行したりして設定を行うのか」が記載される。これはSCAPなどのような自動化を行う際にも参照される
- NSA "Guide to the Secure Configuration of Red Hat Enterprise Linux 5":NSAの該当文書の項目では「どのように設定されているか」が記載される
- NSA "Guide to the Secure Configuration of Red Hat Enterprise Linux 5" - Revision 4, September 14, 2010:NSAの該当文書の項目と、「どのような値にすべきか」が明記されている場合には、設定値が記載される
- Old "Unix-CCE-DRAFT-2" ID: 古いバージョンのUnix-CCE-DRAFT-2の項目で、対応するIDがあった場合、ここに記載される
次に、設定の例を幾つか紹介します。
図6の「項目」1は、「rootアカウントでSSHDログインを許可するか否か」の設定です。CCE IDは「CCE-4387-7」。CCEのパラメーターは「enabled/disabled」(有効/無効)です。これは、CCE Technical Mechanismにある通り、「/etc/ssh/sshd_config」中で「Permit Root Login:yes (or no)」で設定します。この設定は、NSAのガイドラインではSection 3.5.2.6に記載があり、設定値は「disabled」とされています。
図6の「項目」2はパスワードのポリシーで「特殊文字を幾つパスワードに入れなくてはいけないか」の設定です。CCE IDは「CCE-14122-6」。CCEのパラメーターは「特殊文字の数」です。これは、CCE Technical Mechanismにある通り、pam_cracklibモジュールやpam_passwdqcモジュールで操作します。この設定は、NSAのガイドライン(Revision 4)ではSection: 2.3.3.1.1に記載されています。
図6の「項目」3は「/etc/passwd」のファイルパーミッションの値における設定です。CCE IDは「CCE-3566-7」。CCEのパラメーターでは「permissions」と記載されており、CCE Technical Mechanismにある通りchmodコマンドで変更します。これはNSAのガイドラインではSection: 2.2.3.1に記載があり、設定値は「644」とされています。
これらの値がRHEL 5では約400あります。
CCEがRHEL 6以降で更新されていない理由
このCCEが2013年以降(つまり、RHEL 6以降)で更新されていない理由を筆者がSCAP-ML上で質問したところ、以下のような答えがNISTに近い方から返ってきました。
上述の例で分かる通り、CCEのパラメーターは単純なEnabled/Disabledのboolean値ではなく、さまざまな設定の値を入れていくことになります。また、「それらのEnabled/Disabledをどのようにチェックしていくか」も、あるルールではsysctlでservice_XX_enabledをチェックすればよかったり、あるルールでは設定値を見なくてはならなくなったり、さまざまなケースがあります。さらに、その値のチェックの方法(CCE Technical Mechanism)も、その時々で変わります。
これらの事情により、CCEのアップデートと一般への公開が遅れているということです。
ちなみに、現在はSSG(SCAP-Security-Guide)がCCEをSCAPの設定値チェックの中で使用するために、最新のRHEL 6、7対応のものを提供しています。これらはRHELのscap-security-guide-docsで参照できます。アンオフィシャルなものとしては、Shawn Wells氏が下記に公開しています。
次回は、XCCDF、OVALについて
次回は、その他のSCAPの構成要素XCCDF、OVALについて見ていきます。
筆者紹介
面和毅
略歴: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」では、「脆弱性情報と賢く付き合う〜発見から対策までの最前線〜」と題したプログラムが開催された。