情報セキュリティ

  1. トップページ
  2. 情報セキュリティ
  3. ITセキュリティ評価及び認証制度（JISEC）
  4. 評価認証制度（JISEC/ジェイアイセック)について
  5. ITセキュリティ評価・認証(ISO/IEC 15408)に関するFAQ

ITセキュリティ評価・認証(ISO/IEC 15408)に関するFAQ

最終更新日：2023年12月15日

本ページでは、セキュリティ評価に関する規格や制度について、よくある質問とその回答を掲載しています。

1. 制度・規格全般

  1. Q1-1ITセキュリティ評価及び認証制度とは？

    A1-1

    IT製品の有するセキュリティ機能について、主に政府調達などにおいて調達者が求めるセキュリティの要件を満たしていること、つまり想定される脅威に対し適切な対抗となっていること、またその対抗手段が正確に実装されていることを、第三者が評価・認証を行う制度です。概要については、評価認証制度概要（JISEC）を参照してください。

    また、歴史的経緯については、ITセキュリティ評価・認証の動向 を参照してください。  

  1. Q1-2ISO/IEC 15408とは？

    A1-2

     ITセキュリティ評価及び認証制度などでセキュリティ評価を行うための共通的な評価基準を定めたものです。情報資産を保有するIT製品のセキュリティを確保する観点から、 セキュリティに関する評価・認証を受けた製品等の利用を進めるために、 ITセキュリティ評価のための国際的な共通基準として用いられています。  
    パート1：概説と一般モデル、パート2：セキュリティ機能コンポーネント、パート3:セキュリティ保証コンポーネントで構成されています。 詳細については、CC(ISO/IEC 15408）概説を参照してください。
    最新のCCは、セキュリティ評価基準（CC/CEM) で公開しております。


  1. Q1-3ISO/IEC 15408に対応するJIS規格について

    A1-3

    ISO/IEC 15408:1999 に対応する日本国内標準としてJIS X 5070 が 2000年 7月に制定されています。ただし、両規格共、現在使用することはできません。

    注：　両者の規定内容は、同一のものとなっています。JIS X 5070で は、Part 1を完全な日本語翻訳とし、 Part 2 及び Part 3 については、本体部分を原文の英語のままとした要約形式として発行されています。

  1. Q1-4ISO/IEC 15408、Common Criteria(CC)の関係は？

    A1-4

    CCを規格化しているCCRA(Q1-7参照)とISO/IEC 15408の標準化を担当する ISO/IEC JTC1/SC27/WG3とは協力関係にあり、現在CCの規格を元にISO/IEC 15408の作成が行われています。よって、CCと ISO/IEC15408のリリース時期やバージョンは厳密には一致しませんが、一般的にセキュリティ評価基準を示す用語としては、CCもISO/IEC15408も同じ意味として使用されます。

  1. Q1-5TCSEC、ITSECとの関係は？

    A1-5

    TCSEC とは、米国国防総省下の NSA(国家安全保障局)内の NCSC(米国コンピュータセキュリティセンター)により、 軍用調達のためのコンピュータ製品評価基準として1983年に作成(1985年に改定)され、欧州の ITSEC や CC の開発に影響を与えました。 レインボーシリーズの一つとして発行され、表紙の色がオレンジ色であったことから通称「オレンジブック」とも呼ばれています。

    ITSEC とは、Information Technology Security Evaluation Criteria の略で、英国、ドイツ、フランス、オランダの4ヶ国が 欧州統一評価基準として開発し、1991年6月に公開されたV1.2から運用が開始されました。

    CCでは、これらの基準からの移行や比較のための便宜として、評価保証レベル（EAL）を定義しています。CCとTCSEC及びITSECとの保証レベルの関係は以下のようになります。

    CCとTCSEC、ITSECの対応
    Common
    Criteria
    TCSEC
    ITSEC
    -
    D
    E0
    EAL1
    -
    -
    EAL2
    C1
    E1
    EAL3
    C2
    E2
    EAL4
    B1
    E3
    EAL5
    B2
    E4
    EAL6
    B3
    E5
    EAL7
    A1
    E6

    詳細については、諸外国のセキュリティ評価・認証制度の歴史 をご覧ください。

  1. Q1-6ISO/IEC 27001(JIS Q 27001、BS7799-2)に基づく情報セキュリティマネジメントシステム(ISMS)適合性評価制度との関係は？

    A1-6

    ISO/IEC 27001は、組織における情報セキュリティマネジメントシステム（ISMS）適合性評価の規格です。ISO/IEC 27001認証機関の審査員が組織におけるセキュリティ管理について規格に基づき審査を行い、認証を行います。
    ISO/IEC 15408認証製品を適切に運用することで、セキュリティリスクの低減に寄与することが可能です。
    ISO/IEC 15408は、製品のセキュリティ評価基準として定められた規格です。製品のセキュリティ評価において製品の企画・設計・製造・配付・設置・運用といった製品ライフサイクルにわたる評価が行われます。ライフサイクルにおいて、ISO/IEC 27001に適合したマネジメントシステムが安全なセキュリティ製品の提供に寄与することが可能です。

  1. Q1-7CCRA とは何ですか？

    A1-7

    CCに基づいたセキュリティ評価・認証の相互承認に関するアレンジメント。正式名称は、Arrangement on the Recognition of Common Criteria Certificates in the Field of IT Securityですが、簡略化しCommon Criteria Recognition Arrangementと呼ばれていることから、CCRA と略されています。

    認証国でCCに基づいて評価・認証された製品は、アレンジメントに合意した国同士でも相互に通用します。 加盟国には、自国に評価・認証制度を持つ認証国と、 国内に制度を持たないけれども、他の加盟国で認証されていれば、その国でも認証済みの製品として受け入れる受入国があります。CCRAでは、認証制度は基本的には国または国から委託された唯一の機関が運営・監督することとなっています。

    このアレンジメントによって、調達者は使用目的の要件を満たす製品を、国際的により多くの選択肢から共通の基準を用いて調達することができます。また、ベンダもこの国際標準に従うことにより、国や制度ごとに異なる評価基準を満たす必要がなくなります。

    CCRAでの相互承認の範囲は、以下にALC_FLRを含めたものです。

    • 1) CCRAで承認された国際的なプロテクションプロファイル（cPP）に適合するもの（評価保証レベル(EAL)4までのもの）
    • 2) 評価保証レベル(EAL)1及び2のもの

     最新情報は、国際承認アレンジメント（CCRA） を参照してください。  

  1. Q1-8セキュリティターゲット(ST)とプロテクションプロファイル(PP)について教えてください。

    A1-8

     ST(Security Target)は、IT製品のセキュリティ機能について、その目的や対抗手段、想定される運用環境などを記載したセキュリティ基本設計方針書のようなものです。製品調達の際、このSTを読むことで対象製品が自らの環境や目的に合致しているかを判断できますし、同類製品をSTにより比較することもできます。  

    PP(Protection Profile)は、特定の分野の製品について必要とされる典型的なセキュリティ要件、環境などを記述した要求仕様書であり、STをより抽象的(実装非依存）にしたものとなっています。製品調達者が、PPという標準化された要件形式を用いることで、調達者や開発者などが共通の解釈をもつことができます。

    一般的には調達者はセキュリティ要件としてPPを提示し、応札者はPPに準じたIT製品のSTを作成し、それに基づく評価を受けることとなります。
    CC(ISO/IEC 15408)のパート1の附属書にSTとPPの仕様が記述されています。 STとPPの記載内容をお知りになりたい方は、CCパート1の附属書を参照してください。

    また、PPに関しましては、「IC旅券用プロテクションプロファイル」に関する調査報告書」もご参考としてください。

  1. Q1-9cPPとはなんですか？

    A1-9

    collaborative Protection Profileの略です。これまで調達者が個別に作成していた調達要求仕様であるPPを、CCRA加盟国で共同開発した共通PPです。
    各国の政府調達において同じ製品分野で似たようなPPが複数発行されることによる、製品ベンダの重複する評価コストを軽減することを目的にしています。現在は、調達頻度の高い製品分野からcPPを開発しています。

  1. Q1-10評価と認証はどのように違うのですか？

    A1-10

    評価(機関)は対象となる製品に対し実際の評価を行い、認証(機関)は評価結果に対し認証を行います。
    評価では、IT製品のセキュリティ機能の妥当性・正確性をIT及びセキュリティの専門的な知識をもって検査します。認証ではその評価項目が評価基準に沿ってなされたか、つまり特定の側面だけが深くあるいは網羅性のみで技術的に浅い評価が行われることなく、特定された評価保証に見合ったバランスのよい評価が行われたことを確認します。

  1. Q1-11評価機関や認証機関になれますか？

    A1-11

    CCRAで有効な認証機関は一国にひとつであり、国もしくは国が委託した機関である必要があります。日本においてはIPAが認証機関となっています。
    評価機関となるには、認定機関である独立行政法人 製品評価技術基盤機構により手続、設備、教育などが試験事業者としての要件を満たしていることの認定を受ける必要があります。認定審査とともに、試行的な評価を実施し、セキュリティ評価を行える要員を組織が有していることも認証機関（IPA)により確認されます。もちろん、IT製品のセキュリティ評価・脆弱性評定が可能な特定分野でのEALに応じたITスキルの保持が前提となります。

2. 評価・認証の実際

  1. Q2-1評価・認証を受ける手順を教えてください。

    A2-1

    おおまかなイメージとしては、下記のようなステップになります。

    ステップ(1)

    作業者

    申請者

    作業内容
    • セキュリティターゲット（ST）や評価用資料の準備

    ステップ(2)

    作業者

    申請者

    作業内容
    • 評価機関の選択と評価依頼

    ステップ(3)

    作業者

    評価機関

    作業内容
    • 「評価作業実施計画書」を作成し、申請者の承認を得る。

    ステップ(4)

    作業者

    申請者

    作業内容

    ステップ(5)

    作業者

    認証機関

    作業内容
    • 申請書類のチェック、「認証申請」の受付
    • 担当をアサインし、「評価作業確認通知」を申請者・評価機関へ送付

    ステップ(6)

    作業者
    • 申請者
    • 評価機関
    • 認証機関
    作業内容
    • 3者によるキックオフミーティングの実施
      （評価作業の実施に関する確認を行う。）

    ステップ(7)

    作業者
    • 評価機関
    • 申請者
    作業内容
    • 評価実施　（問題事項の指摘など）
    • 申請者及び認証機関への進捗状況の報告
    • 評価作業対応、指摘事項への対応

    ステップ(8)

    作業者

    評価機関

    作業内容
    • 「評価報告書」の作成、認証機関への提出

    ステップ(9)

    作業者

    認証機関

    作業内容
    • 「評価報告書」を検証
    • 適正であれば「認証書」及び「認証報告書」を発行

  1. Q2-2評価・認証にかかる期間、費用を教えてください。

    A2-2

     期間は、評価対象の規模や評価保証レベル(EAL)によって異なるため一概には言えませんが、例えば、EAL2 の場合で最短でも 4～6ヶ月はかかっています。 EAL4の場合、12ヶ月以上かかることもあります。認証が調達の要件等になっている場合などは、予め期日にむけたスケジュールを評価開始時に調整する必要があります。  
    特に評価する製品の技術分野について専門的な知識を持つ評価機関を選択することは、評価の期間に大きくかかわってきます。評価機関の選択に当たっては、対象となる技術分野の専門家を伴い評価機関を訪問し、人材や設備の確認をすべきです。

    費用は、評価機関に支払う評価費用、認証機関に支払う認証申請手数料のほか、ST作成や（もし、現開発プロセスにおいて作成される資料で不十分な場合は） CCで定められた各種証拠資料の準備、評価中に生じる不具合等への対応、テスト環境の準備などの内部工数あるいは、コンサルタント（使用した場合）にかかる費用が発生します。 評価費用は、評価対象の規模や現開発プロセスの状況などに応じて、また評価機関のサービス内容によって異なります。評価費用とそのサービス内容については、各評価機関にお問い合わせください。認証申請手数料は、「申請手数料支払いについて」を参照してください。


  1. Q2-3評価機関からコンサルティングサービスを受けた場合、その評価機関で評価を受けることは可能ですか？

    A2-3

    評価機関がコンサルティングサービスを提供することは、禁止されています。評価機関及び評価者は、評価に際し独立性及び公平性を維持することが義務付けられています。 評価機関の所属する法人でも、独立した別部門が評価にまったく影響を与えない形でコンサルティングを実施する場合がありますが、この場合でも評価機関の独立性は独立行政法人 製品評価技術基盤機構等の認定機関により厳しく審査されています。

  1. Q2-4どのようなものが評価・認証の対象になりますか？

    A2-4

     セキュリティ機能を持ったIT製品のソフトウェア、ハードウェア、ファームウェア等が対象になります。 ISO/IEC 15408は、IT製品に実装されたセキュリティ機能が、脅威に対し確実に対抗できるかを客観的に評価するための基準です。 したがって、評価の対象となるものは、「保護するべき資産(情報)」、「対抗すべき脅威(攻撃)」、 「適用すべき環境」が具体化できるものでなければなりません。 日本における政府調達の対象分野は、経済産業省の 「IT製品の調達におけるセキュリティ要件リスト」を参照してください。

    評価・認証済みの IT 製品としては、OS、DBMS、ファイアウォール、ルータ、IC カード、MFPなどがあります。具体的な製品については、JISECにおける認証製品リストやCCRAのCertified product list などを参照してください。

    実際に認証申請をする場合には、評価機関が申請する評価対象分野を評価できる必要がありますので、事前に評価可能かを各評価機関にご相談ください。

  1. Q2-5評価にはどのようなものが必要になりますか？

    A2-5

    CCのセキュリティ評価では、機能テストは一部の側面でしかありません。IT 製品だけではなく、その開発で使用した設計文書やテスト関連の文書、利用者や管理者ガイダンス、実際の開発現場におけるセキュリティ維持のための手順書や実施証拠資料（各種ログや承認書など）も評価の対象となります。また、EALによって評価の範囲や深さが異なりますので、これらの必要な資料類も異なります。

    いずれもセキュリティを確保するために必要な資料であり、評価のために別途作成されるものではありません。該当する資料へのインデックスを評価者に示していただければいいものです。もし評価に必要な資料がないとすれば、それは必要とされるべき手順や記録が欠落していたことを意味します。

  1. Q2-6STを作成したいのですが、どのようにすればよいでしょう？

    A2-6

     CCパート1の附属書を参考に作成できます。また、現在、JISECの各種講座や評価機関において、 ST作成に関する教育が行われています。 詳細につきましては、各機関にお問い合わせください。

  1. Q2-7評価保証レベル(EAL) は、調達者・顧客、開発者のどちらが決めるべきものなのでしょう？

    A2-7

     調達などでは要件に見合ったEALを調達者・顧客が指定しますが、パッケージ製品では製品の特性や市場の動向から開発者が決定する場合もあります。 いずれにしても適切なEALの選択が、スムーズな評価・認証につながります。EALの決定については、「セキュリティ機能と保証レベル」も参照してください。  

3. 申請・契約関連

  1. Q3-1秘密保持契約の内容を変更したいのですが可能ですか？

    A3-1

    基本的には、雛形の秘密保持契約書の内容とします。ただし、政府調達の目的に有用あるいは合致している範囲内であれば内容を検討の上、覚書にて対応いたします。検討のためお時間を要しますので、余裕を持ってご相談ください。なお、申請受付は覚書事項等の合意がとれてからとなります。

  1. Q3-2評価・認証の際に提供した情報は保護されますか？

    A3-2

    はい、認証申請に際して、案件ごとに申請者と認証機関の間で、秘密保持契約を締結します。認証機関における秘密情報の取り扱いは、「ITセキュリティ認証業務取扱手順」（CCM-01-A）に従い、保護されます。
    評価機関における秘密情報の保護については、別途申請者と評価機関の間で、秘密保持契約の締結が必要となります。評価機関の運営管理につきましては独立行政法人製品評価技術基盤機構等の認定機関により情報の管理について厳しい審査を受けています

  1. Q3-3秘密保持契約期間終了後の秘密保持の扱いについて教えてください。

    A3-3

    申請者と認証機関との間の秘密保持契約の有効期間が終了した後、「ITセキュリティ認証業務取扱手順」（CCM-01-A）に記載の方法で、返却又は消去を行います。紙媒体の場合はシュレッダにより消去し、電子データの場合は内容を消去します。

  1. Q3-4認証取得後に、5年の秘密保持契約期間を待たずに秘密文書を破棄してもらうことは可能ですか？

    A3-4

    はい、可能です。
    秘密情報には特に秘匿性の高い情報もありますので、その場合情報開示時に「禁複写」等の表示、又は特別な取扱いに関する指示書（不要になった時点で返却又は消去）を添付頂ければ、「ITセキュリティ認証業務取扱手順」（CCM-01-A）に基づいて、適切に処理します。

  1. Q3-5申請責任者にはどのような役職が必要ですか？

    A3-5

    認証申請書における申請責任者は、その製品のセキュリティ評価及び認証を行う上で必要となる評価対象、評価用提供物件（製品ライフサイクルにおける証拠資料）等を提供するにあたり、権限のある方となります。通常は、事業責任者等の役職の方が権限と責任を負うことになります。

  1. Q3-6日本語以外の申請は可能ですか？

    A3-6

    認証申請手続、及び認証機関との連絡に使用する言語は、日本語又は英語になります。ST、評価報告書、証拠資料についても使用する言語は、日本語又は英語となります。
    法人格を証明する書類等の原文が日本語又は英語のいずれでもない場合は、原文に加えて、日本語訳又は英語訳を提出してください。

  1. Q3-7保証継続により、認証製品リストの掲載期間は延長されますか？

    A3-7

    保証継続における再評定の仕組みを用いて、認証有効期限及び認証製品リストの掲載期限を延長することができます。

  1. Q3-8プロテクションプロファイル準拠の申請をしたいのですが、評価保証レベルが既定されていません。申請手数料はどうなりますか？

    A3-8

     認証手数料は、対象プロテクションプロファイルで求められる保証コンポーネントに相当する保証レベルに準じます。認証プロテクションプロファイルリストの「要求する保証要件」を確認願います。  

4. 主なCC用語解説

  1. Q4-1STやPPで良く見るCC特有の用語の意味は？

    A4-1

    EAL
    （評価保証レベル）

    Evaluation Assurance Levelの略。
    製品のセキュリティ評価において、そのセキュティ機能が確実に動作することの保証の度合いを表すものです。
    セキュリティ機能が確実に動作するために、要求される機能設計、開発環境、ガイダンス文書、脆弱性評定などの側面における要件（セキュリティ保証要件と呼ぶ）について、評価においてどの範囲でどの程度の厳密さを求めるかにより、EAL1からEAL7までのレベルのセキュリティ保証要件が用意されています。
    評価を申請する開発者やスポンサーは、目的に応じた保証レベルを選択することで費用対効果に見合った評価を行うことができます。
    詳しくは「セキュリティ機能と保証レベル」を参照してください。

    OSP
    （組織のセキュリティ方針）

    Organisational Security Policyの略。
    TOEに対し、脅威からは直接導かれないセキュリティ機能を要求することがある場合、たとえば、製品により法律において要求される機能や、調達側組織のセキュリティ方針として満たすべき機能上の要件がある場合には、TOEを利用する組織のセキュリティ方針として、STに記述します。汎用製品のように不特定の利用者を想定するものは、ほとんどの場合組織のセキュリティ方針は存在しません。

    SAR
    （セキュリティ保証要件）

    Security Assurance Requirementの略。
    保証要件は、設計から製品化に至る過程で、セキュリティ機能が確実に実現され、動作することを確信するための「保証」の指針となるあらゆる要件です。
    CCでは、保証要件を「開発」、「ガイダンス文書」、「ライフサイクルサポート」、「セキュリティターゲット評価」、「テスト」、「脆弱性評定」の6つのクラス(「保証クラス」と呼びます)に分類し規定しています。 保証要件の詳細については、CC パート3を参照してください。
    保護される資産の価値とその資産がさらされている危険度合い、技術上の実現可能性、開発と評価コスト・必要な期間の見込み、明確になっている市場要件などのバランスをとってセキュリティ保証要件決めます。

    SFP
    （セキュリティ機能方針）

    Security Functional Policyの略。
    TOEセキュリティ機能によって実施され、セキュリティ機能要件のセットとして表現できる特定のセキュリティのふるまいを記述する規則のセットを言います。たとえば、サブジェクトがオブジェクトへアクセスする際、それぞれの属性に従い操作が定義されているようなアクセス制御方針が該当します。

    SFR
    （セキュリティ機能要件）

    Security Functional Requirementの略。
    セキュリティ機能要件は、IT製品が備えるべき情報セキュリティに必要な機能の要件を、共通的な表現で表したものです。セキュリティ仕様作成の際、機能要件を用いることで、要件に対する共通の理解が容易になります。
    CCでは、機能要件を大きく11種類に分類し(「機能クラス」と呼びます)、規定しています。 機能要件の詳細については、CC パート2を参照してください。

    TOE
    （評価対象）

    Target Of Evaluationの略。
    TOEは、評価の対象となるソフトウェアやハードウェアなどの製品です。これらは、それに関連する管理者及び使用者の手引書(利用者マニュアル、ガイダンス、インストール手順書など)を含むことがあります。

    TSF
    （TOEセキュリティ機能）

    TOE Security Functionalityの略。
    TOEの中でセキュリティ機能要件（SFR）を正しく実施する機能性の総称。直接あるいは間接にセキュリティの実施の役割を果たすTOEのソフトウェア、ハードウェアあるいはファームウェアで構成されます。

    オブジェクト

    情報を格納または受信し、サブジェクトによる操作の実行対象となるTOE内の受動的なエンティティのこと。

    サブジェクト

    オブジェクトに対して操作を実行するTOEの能動的なエンティティのこと。

更新履歴

  • 2023年12月15日

    「再評定」の導入に伴い、一部の記載を更新しました。

  • 2023年11月1日

    CC/CEM:2022へのバージョンアップに伴い、一部の記載を更新しました。