Common Criteria
(株)NTTデータ 技術開発本部 セキュアサービスプラットフォームグループ 市原尚久(いちはら なおひさ)
はじめに
近年、パソコンやインターネットをはじめとしたIT製品の普及と共に、これらを悪用した不正アクセスや情報漏洩、ウイルス等の不正・犯罪事件が増加しており、社会全体に対する脅威となっている。
このような脅威に対するセキュリティ対策として、セキュリティ運用・管理の実施基準であるBS7779、ISO/IEC17799、IT製品のセキュリティに関する国際評価基準であるCommon Criteria(以降、CC)が注目されている。国内では、ISO/IEC 17799をベースに情報セキュリティマネジメントシステム制度(以降、ISMS)が、ISO/IEC 15408(CC ver2.1 と同一)をベースにJIS X5070が制定されている。
なお、内容においては、CC ver2.1、ISO/IEC 15408、JIS X5070はすべて同一であるため、ここでは全てCCと呼ぶことにする。
CCの概要
CCは、IT製品・システムのセキュリティを、セキュリティ基本設計書(セキュリティターゲット、以降ST)をベースにして、設計書、ソースコード、試験結果、マニュアル等の検査、脆弱性分析、裏チャネル解析、さらには開発環境や管理体制などの評価検査などを通じて評価が行われ、これに合格することで「認証」を取得できる。また、CCでは「保証レベル」(Evaluation Assurance Level、以降EAL)を1〜7に設定し、このレベルによって評価内容も異なる(大きいほど厳しい)。但し、EALはセキュリティ強度を示すものではない。
CC認証を受ける際に、製品開発ベンダは、製品に対応したSTを作成して評価機関に提出する事になるが、STに対する要件が提供されたプロテクションプロファイル(Protection Profile、以降PP)に基づいて(準拠して)作成してもよい。
CCの構成
CCは、以下のPart1〜3の3部で構成されている。
Part1: Introduction and general model (総則及び一般モデル)
Part1では、ITセキュリティ評価の概念や方針、一般モデルを規定し、評価対象(Target of evaluation、以降TOE)にセキュリティを確保するための枠組みが提供されている。具体的には、TOEのST記述、脆弱性分析、セキュリティ対策方針の策定、セキュリティ機能要件、セキュリティ保障要件等の記述が規定されている。
Part 2:Security functional require ments(セキュリティ機能要件)
Par2では、セキュリティ機能要件が以下の11クラスで提供されている。
・FAU: Security Audit(セキュリティ監査)
・FCO: Communication(通信)
・FCS: Cryptographic support(暗号サポート)・FDP: User data protection(利用者データ保護)
・FIA: Identification and authentication(識別・認証)
・FMT: Security management(セキュリティ管理)
・FPR: Privacy(プライバシー)
・FPT: Protection of the TSF(TSFの保護)
・FRU: Resource utilization(資源利用)
・FTA: TOE access(TOEアクセス)
・FTP: Trusted path/channels(高信頼パス/チャネル)
各クラスはさらにファミリ、コンポーネント、エレメントという階層構造で定義されている。例えば、FIA(クラス)配下のFIA_AFL(ファミリ)には、FIA_AFL.1(コンポーネント)が、以下の2つのエレメントを定義している。
■FIA_AFL.1 認証失敗時の取り扱い■
FIA_AFL.1.1 TSF は、[割付: 認証事
象のリスト]に関して、[割付: 回数]
回の不成功認証試行が生じたときを検
出しなければならない。
FIA_AFL.1.2 不成功の認証試行が定
義した回数に達するか上回ったとき、
TSF は、[割付: アクションのリスト]
をしなければならない。(IPAによる
日本語訳)
|
STを作成する際には、セキュリティ要件の中から必要な要件を「コンポーネント単位」で任意に選択し、斜体文字を以下のように具体化(refinement)する必要がある。
■FIA_AFL.1 認証失敗時の取り扱い■
FIA_AFL.1.1 TSF は、ユーザーのパ
スワード認証に関して、3回の不成功
認証試行が生じたときを検出しなけれ
ばならない。
FIA_AFL.1.2 不成功の認証試行が定
義した回数に達するか上回ったとき、
TSF は、パスワードのロックをしなけ
ればならない。
|
Part3:(セキュリティ保証要件)
Par3では、以下のセキュリティ保証要件が提供されている。
・ASE: Security Target Evaluation(セキュリティターゲット評価)
・ACM: Configuration management(構成管理)
・ADO: Delivery and operation(配付と運用)
・ADV: Development(開発)
・AGD: Guidance documents(ガイダンス文書)
・ALC: Life cycle Support(ライフサイクルサポート)
・ATE: Tests (テスト)
・AVA: Vulnerability assessment(脆弱性評定)
・APE: Protection Profile Evaluation(プロテクションプロファイル評価)
・AMA: Maintenance of assurance(保証維持)
EALのレベルによって、評価に用いられるセキュリティ保証要件のコンポーネントのメニューが一意に決定する。
図1 Common Criteria の概要
CCの認証スキーム
CCの認証スキームでは、国ごとに認定機関・認証機関が設立される。認定機関は、あらかじめ認定プログラムに基づいて民間評価機関を認定する。
製品ベンダは、認定済みの評価機関に評価依頼し、認証機関に認証の申請を提出する。STをはじめとする製品ベンダの提出物に基づいて評価機関が評価を行うが、評価機関は定期的に評価レポートを認証機関に提出する。最終評価レポートが認証機関に提出され、評価が合格すると、認証機関から認証書と認証レポートがIT 製品ベンダに授与される。
日本の認証プログラムに関しては、下記のホームページを参照されたい。
日本の認定・認証機関*
独立行政法人製品評価技術基盤機構(NITE)National Institute of Technology and Evaluation http://www.nite.go.jp/asse/its/jisecindex.html
*2004年4月1日より認証機関はNITEから独立行政法人情報処理推進機構(IPA)に移管される。 http://www.ipa.go.jp/about/jigyoshokai/security.html
日本の評価機関
JEITA: 社団法人電子情報技術産業協会 ITセキュリティセンターECSEC: 電子商取引安全技術研究組合研究所
おわりに
CC評価は、費用面や評価期間の面での課題は依存として残っている。特に日本の場合は認証プログラムの開始からわずか2年。認証事例の数(3)、評価期間の長さ(1〜2年)、さらに(ハードウェア製品用の)評価施設などに関しても、まだまだ欧州のレベルに追いついていない。さらに、欧州のICカード評価で標準的に利用されているJIL Document(CCの公式サポート文書。
ICカード評価の為の統一的解釈が規定されている)に対してNITEが否定的見解を示している現状では、当面は海外で認証取得をせざるを得ないのではという見解さえベンダの中にはある。
それでも、2003年10月末にはNITEがCCRA(Common Criteria Recognition Agreement)に正式加盟したことが発表され、日本とCCRA加盟国間での認証の相互承認が可能になった。また、同年12月にはJEITAが日本初のEAL4評価機関に認定されるなど、明るいニュースも続いた。安全で信頼できる日本のIT社会を築き上げるためにも、ITセキュリティ評価の制度と基盤の発展に期待したい。
お問い合わせ先
E-mail:ichiharan@nttdata.co.jp
|
|