IT用語/CC(ISO/IEC 15408)

CC(Common Criteria)、ISO/IEC 15408 (2014-09-08)

IT 製品や情報システムに対しての、国際的なセキュリティ評価基準。

日本では、この基準に基づいて評価する「ITセキュリティ評価及び認証制度(JISEC*1)」が定められており、 独立行政法人情報処理推進機構(IPA*2)が認証機関としてこれを運用しています。

この規格で評価するのは、技術的な対策や実装、開発におけるプロセスであって、
運用面(セキュリティ教育、セキュリティ監査など)は含まれません。
また、レベル(EAL。後述)が高い=「セキュリティ強度が高い」とは一概にはいえません(例えばPPによる。後述)。

PP(Protection Profile)

利用者のセキュリティ要件を記述した要件仕様書。
代表的な例は以下

  • CAPP(Controlled Access Protection Profile)
    随意アクセス制御機能*3を実装している。
    UnixやWindowsなどの主要なOSは通常これを使用してCCの評価を取得することになる。
  • LSPP(Labeled Security Protection Profile)
    ラベルベースの強制アクセス制御機能*4を実装している。
    例えばセキュアOSの場合こちらで(或は更に堅牢なPPで)CCの評価を取得しなければならない。

※ちなみに、この2者で「セキュリティ強度が高い」のは後者になりますよね。

ST(Security Target)

対象となるIT製品、システムに実装されるセキュリティ機能の設計仕様を記述した文書。通常、製品の開発者が作成する。
IPAでは、これと、一部の開発文書をCEM(後述)に則って評価する「ST確認」という運用を行っている。

CEM(Common Evaluation Methodology。共通評価方法*5

評価結果が理解可能かつ比較可能にするために開発された評価方法。
CC 評価を行うための最低限のアクションを記述している。

EAL(Evaluation Assurance Level。評価保証レベル)

うーん。無理やり簡略化してみました。レベルが上がるほど高評価なシステムということ。

  • EAL1:機能テスト
     ガイダンスや機能仕様書がちゃんと書けていればOK
  • EAL2:構造化テスト
     設計書の検査、開発者が行ったテスト結果や脆弱性の評価がなされているか
  • EAL3:方式的テスト、及びチェック
     構成管理・開発環境の状況、開発者が行ったテストの内容範囲が適切か
  • EAL4:方式的設計、テスト、及びレビュー
     詳細設計書や一部のソースコード、部分的な実装レベルまで踏み込む
  • EAL5:準形式的設計、及びテスト
     完全な実装、評価対象 (TOE:Target Of Evaluation)設計がより詳細など
  • EAL6:準形式的検証済み設計、及びテスト
     構造化された開発プロセス、包括的で独立した脆弱性分析など
  • EAL7:形式的検証済み設計、及びテスト
     なんか、色々すごいやつ

一般的にはEAL4が最高レベルです。EAL5以上になると全ソースコードを提出する必要があり、軍事目的などに使われるようです。


*1 Japan Information Technology Security Evaluation and Certification Scheme
*2 Information-technology Promotion Agency, Japan
*3 アクセス制御については、IT用語/アクセス制御(DAC、MAC)
*4 同じく、IT用語/アクセス制御(DAC、MAC)
*5 正式名称はCommon Methodology for Information Technology Security Evaluation

  最終更新のRSS