CC/CEMの動向紹介 1．CC V2.2、CEM V1.2 2. CC V3.0、CEM V2.0 3. コンポジション製品の評価について 4. 認証済みTOEの保証維持について 5. システム評価 (ISO TR 19791) 注：いずれも検討中の事項であり、規格ではないことに留意願います。平成１６年８月独立行政法人情報処理推進機構セキュリティセンター情報セキュリティ認証室 1 注： CC版は作成完了 CCRAホームページで公開している http://www.commoncriteriaportal.org/ ISO版はISO/IEC 15408の改訂(CC v2.3)審議中（2005年5月IS予定） 2 CC V2.2＝ CC V2.1 + Interpretations（2003.12.1版（2002.2.15版を含む） +α） +FLR supplement +AMA削除）注：・2002.2.15版は「補足-0210 第２版」、2003.12.1版は「補足-0407」規格として採用 3 「補足0407」で追加の主要な補足概要パート２の附属書（機能クラスの操作などの説明）部分を規定扱いとする（従来は参考）。パスワードの最大連続失敗回数の範囲を指定し、管理者がその範囲内で最適な回数を決定可とする。配付手続きをTOEの部分に対しても指定可とする。ガイダンス文書の範囲を拡大（TOEの利用者、管理者、インテグレータが関与する配付、導入、構成、運用、管理や利用を記載した文書： AGD_ADM+AGD_USR+ADO+ALC_FLR) 4 FMT_MSA.3、 FMT_REV.1、 FPT_AMT.1に割付(従来は“他の特性”を選択）導入。例： FMT_MSA.3.1 The TSF shall enforce the [assignment: access control SFP, information flow control SFP] to provide [selection: restrictive, permissive, other property] default values for security attributes that are used to enforce the SFP. ↓ FMT_MSA.3.1 The TSF shall enforce the [assignment: access control SFP, information flow control SFP] to provide [selection: restrictive, permissive, [assignment: other property]] default values for security attributes that are used to enforce the SFP. “選択”の操作を明確化。明に禁止しない限り複数項目の選択を可能。例： FAU_GEN.1.1 ---------b) All auditable events for the [selection: minimum, basic, detailed, not specified] level of audit; and ↓ b) All auditable events for the [selection: choose one of :minimum, basic, detailed, not specified] level of audit; and 5 １．ASE/APE ２．ADV ３．ACM/ALC/ADO/AGD 注：CCプロジェクトでの完成は2005年6月を予定 6 １．ASE/APE（変更） STの構成 1.ST概説・ST参照・TOE参照・TOE概要・TOE記述 2.適合主張・CC適合主張・PP主張・パッケージ主張 7 ASE/APE(変更） 3.セキュリティ課題定義(Security problem definition) ・脅威・組織のセキュリティ方針・前提 4.セキュリティ対策方針・TOEのためのセキュリティ対策方針・開発環境のためのセキュリティ対策方針・運用環境のためのセキュリティ対策方針・セキュリティ対策方針根拠 8 ASE/APE(変更） 5.拡張コンポーネント定義 6.セキュリティ要件・TOEのためのセキュリティ機能要件・ TOEのためのセキュリティ保証要件・セキュリティ要件根拠 7.TOE要約仕様 9 ASE/APE(変更） PP適合について、下記の３つから選択可能・完全適合(Exact conformance) PPの記載に対して追加も修正も不可（基本的には操作の選択のみ）調達する部品のためのPPなどに採用・正確適合(Strict conformance) PPの記載に対して追加のみ可（ただし、セキュリティを弱めるものは不可、TOEに合わせて操作を完成）製品やシステムに対する最低限のセキュリティ要件をPPに記載・要求適合(Demonstrable conformance) PPの記載に対して変更は可（ただし、矛盾が無いこと、保証要件は PP規定要件を含む、選択操作はPP指定範囲内）解決すべきセキュリティ課題と解決のためのガイダンスをPPに記載 10 ASE/APE(変更）セキュリティ対策方針の策定手順組織のセキュリティ方針前提条件利用環境、物理管理、人的条件、接続／動作環境脅威識別された脅威群規則法律条件をどのように実現するか運用環境のセキュリティ対策方針開発環境どのように対抗するかのセキュリティ対策方針ＴＯＥのセキュリティ対策方針セキュリティ対策方針 11 ASE/APE(変更）セキュリティ要件の策定手順セキュリティ対策方針運用環境のセキュリティ対策方針開発環境のセキュリティ対策方針どのような信頼性を実現するかセキュリティ保証要件ＴＯＥのセキュリティ対策方針どのようなセキュリティ機能を装備するかセキュリティ機能要件 12 ASE/APE(変更）簡易ST(Low assurance Security Targets) ・記載内容 ST概説、適合主張、拡張コンポーネント定義、セキュリティ要件、TOE要約仕様・依存性を満足しない場合の根拠記述を免除 13 ２．ADV（変更）評価にかかるコストの削減を考慮した。例えば、現FSP.2(EAL4から)では全ての効果に関わる記述を要求しているが、これは評価に多大なコストをかけることになる。新ADVではsecurity enforcing interfaces に限定（EAL4で要求のFSP.4）。 LLD.1でもsecurity enforcingモジュール以外はサマリーの要求にした。下記の区別を明確に・ Security enforcing (より厳密な分析やテスト)、・ Security supporting（分析やテストを軽減）、・ Security benign（TSFから除去） 14 ADV(変更） ADV_ARC（新ファミリー）セキュリティ機能（セキュリティ機能動作のためのデータを含む）の保護セキュリティ機能のドメイン分離（他のプログラムからの非干渉）とセキュリティ機能の非バイパスに関するアーキテクチャー文書（記載の詳細レベルはHLDのenforcing subsystemの記載レベル相当（ARC.1)、セキュリティドメインの規定、ドメイン分離/ 非バイパス要求に対する正当性）を要求。評価者自らも分析。 15 ADV(変更） ADV_FTI（ Fault Isolation：新ファミリー）障害がセキュリティ機能に与える影響を最小限にする。現FPT_SEP.2, FPT_SEP.3の要件を反映。ユーザモードのfault isolation要求（特権を必要とするセキュリティ機能箇所の設定、特権ハードウェアモードでの実行禁止、など）。 ADV_CMP（新ファミリー）コンポジションへの対応 IT環境への要求（セキュリティ機能からの呼び出し）が存在する全てのインタフェースを識別。呼び出しに関して、名称、目的、パラメタと定義、利用方法を記載。 16 ADV(変更） ADV_FSP（変更）利用者へのインタフェースに関してセキュリティ機能（ Enforcing と supportingを識別）は何を行なうか（目的、利用方法、パラメタ、効果、例外、エラーメッセージ）の明確化をより鮮明に要求。・FSP.1：Incomplete specification Security enforcing インタフェースのみを識別（目的、利用方法、パラメタ）・FSP.2: Semi-complete specification(詳細度に関しては不完全、全てのインタフェースを enforcing, supporting, benignに分類) Security enforcingとsupportingを識別（目的、利用方法、パラメタとその説明）・FSP.3: 全てのTSFIを識別（目的、利用方法、パラメタとその説明） Security enforcing TSFIに対しては、効果、例外事項、エラーメッセージの説明・FSP.4: Security supportingとbenignにたいして、効果と例外事項のサマリーを要求・FSP.5: Security supportingとbenignにたいしても、効果、例外事項、エラーメッセージの説明を要求開発者の主張にたいして評価者が検証する・FSP.6: 文書はsemi-formalを要求全てのエラーメッセージを識別しその理由を説明・FSP.7: 文書はformalを要求 17 ADV(変更） EAL1 EAL2 EAL3 EAL4 EAL5 EAL6 EAL7 FSP .1 .2 .3 .4 .5 .6 .7 HLD - .1 .2 .2 .3 .4 .4 LLD - - - .1 .2 .3 .4 IMP - - - .1 .1 .2 .3 CMP - .1 .2 .2 .2 .2 .2 ARC - .1 .1 .2 .2 .2 .2 INT - - - - .1 .2 .3 FTI - - - - .1 .2 .2 RCR - .1 .1 .2 .2 .2 .2 SPM - - - .1 .2 .3 .3 Security enforcing TSFI Security enforcing subsystems -Detail security enforcing interfaces -Non-security enforcing subsystems -HLD-level SEP/ RVM -Security enforcing modules -Sample of implementation representation -LLD-level SEP/RVM Entire implementation representation -Internal structuring of TSF modules -Isolating faults of TSF -Semi-formal FSP -Semi-formal HLD -Formal FSP -Semi-formal LLD 18 3．ACM/ALC/ADO/AGDクラス（変更）重複した作業要求の削除・AGDクラスの再構成：AGD_PRE(Preparation:利用者に関わる配付とIGS関連を含める)、AGD_OPE(Operation:現在のAGD_ADM,_USRを統合) ・ADO_IGS（利用者の責任に関する事項）⇒ AGD_PREへ移す・ADO_IGS（開発者の責任に関する事項）⇒ ALC_CMCへ移す・ADO_DEL（利用者に関する事項）⇒ AGD_PREへ移す・ADO_DEL（開発者に関する事項）⇒ALC_DELへ移す・構成管理のSCPとCAPの重複箇所を削除して、scope（ALC_CMS:構成リストに含める内容）とcapability（ALC_CMC:構成管理システムへの要求事項）に関わる要求内容を明確に区別した。これに合わせて、 AUT に関わる要求を ALC_CMCに含める。ファミリー構成は以下。 AGD_PRE, AGD_OPE ALC_CMS, ALC_DEL ALC_CMC, ALC_DVS, ALC_FLR, ALC_LCD, ALC_TAT, 19 20 対象とする形態・構成する製品は同等の脅威のもとで評価済みである。・階層構造を持つ製品（例：ICカード、ハード＋OS, ション）。 OS＋アプリケー・複数の製品からなる統合製品（例：クラサバ連携製品）。 21 基本的な考え方 (1)他の製品との結合によりTSFが悪影響を受けることがないことを検証。 (2)下層のTOE評価はコンポジションを考慮したものにする。全てのプログラムインタフェースを評価。 (3)上層のTOEに関わる要求仕様は明確で完全なものにする。 ST、FSP,HLDにおけるセキュリティ要求仕様の記載を可能な限り具体化する。 IT環境に対する要求を明確かつ詳細に記載する。 (4)インテグレーションに必要な全ての情報は利用できるようにする。 AGD_OPEで配慮する。 22 (5)各TOEの評価結果は他の評価者が利用できるようにする。 NDA無しで利用できるETR, ビデンスの提供など。 NDAのもとでETR利用、NDAのもとで評価用エ (6)結合製品としての評価を行なう。・各製品の要求仕様が統合製品としての要求仕様に合致することを確認。・上位層TOEのIT環境に対する要求仕様を下位層TOEが満足することを確認。・統合製品のセキュリティ課題と構成TOEのセキュリティ課題が矛盾しないことを確認。・統合のための全ての作業を構成管理に反映。・下位層TOEが提供するインタフェースのみを上位層TOEが使用していることを確認。・統合は構成TOEのガイダンス文書のみによって可能であることを確認。・統合のためにインテグレータによって実施されたテストは確認（実施）。・統合によって引き起こされる脆弱性の分析結果は評価。・統合製品の保証パッケージ（コンポーネント）は構成TOEの保証パッケージの共通部分と考える。 23 ガイダンス文書として作成 24 概要・CC V2.1のAMAはCC V2.2からは削除・保証維持についてはガイダンス文書を作成・CCRAの保証維持の仕組みとして採用基本的な考え方・認証TOEの後続版において、最初の認証TOE の保証要件が維持されている場合、後続版の再評価は不要とする。この場合、後続版は保証維持記録簿（仮称認証書の添付資料の位置づけ）に記載し、認証製品リストの一部として公開する。変更のあったTOEは最初のSTに記載の保証要件を満足していることを意味している。脅威や脆弱性に変化があった（あると想定あれる）場合には、再評価する。保証維持記録簿に記載された後続版TOEに対しては認証書は発行しない。 25 変更がセキュリティに与える影響の大、小の判断基準開発者からの入力：ETR、ST、影響分析報告書（IAR）、（認証報告書）小：変更がTOEのセキュリティ保証に与える影響が小さいので再評価は不要例： IT環境のみが変更、評価用提供物件の変更（エディトリアルな変更はOK)は無い、ソースコードのコメントを変更、TOEには影響を与えないような開発環境の変更、TOE名称変更など大：変更がTOEのセキュリティ保証に与える影響が大きいので再評価が必要例：セキュリティ保証要件や機能要件の変更・追加、TOE範囲の変更、セキュリティメカニズムや各種手続きの変更、など注：・詳細かつ統一的な判断基準の作成は不可（実績を積んでから）⇒開発者はIARに小だと判断した根拠を記載・開発者は脆弱性分析を実施することによって、新たなアタッキングへの対応を評価する。 26 基本的な処理フロー認証TOEに対して変更を実施開発者は変更に応じて必要な評価用提供物件を修正する。開発者はIAR(Impact Analysis Report)を作成し認証機関に提出変更内容とそれが認証TOE規定のセキュリティ保証要件に与える影響を分析して記載する。認証機関が変更のセキュリティに与える影響度合いを決める大再評価を実施小変更TOEを保証維持記録簿に記載。認証製品リストとして公開保証維持報告書（保証維持記録簿から参照可）を公開 IARや過去の評価実績は最大限に利用する。変更TOEに対して新たな認証書を発行 27 影響度の分析手法：開発者の作業ステップ１：TOEの認証時に提供した評価用提供物件を識別する。ステップ２：何が変更？変更箇所（TOE自体、開発環境など）を識別する。ステップ３：影響分析・変更がTOEの評価用提供物件、保証要件に与える影響を識別する。チェックリスト：ST、TOE構成要素、設計書、セキュリティアーキテクチャ、ポリシーモデル、ガイダンス文書、テスト文書、隠れチャネル分析、脆弱性分析、配付手続き、導入/起動手続き、障害対応手続き、構成管理、ライフサイクル、開発ツール、など・影響を与える保証要件の開発者アクションエレメントの一覧表を作成する。ステップ４：変更適用開発者アクションエレメントに対して、実際の変更適用、テスト実施などを実施する。変更履歴を作成。ステップ５：変更の影響度合い（大、小）を決定し、その根拠を纏める。アウトプット：IARとアップデートされたエビデンス 28 影響分析報告書の概要（開発者が作成）１．はじめに認証TOE：名称、ST、関連ガイダンス文書、ETR、認証報告書など２．変更内容３．影響を受ける開発者エビデンスとその内容４．変更後のエビデンスエビデンスの詳細を添付する。５．影響度各変更に対して、セキュリティ保証に与える影響の大小とその理由 29 30 運用システムのセキュリティ評価 ISOで運用システム評価のための評価基準と評価方法を作成中 TR：19791 タイトル：Security assessment of operational systems スケジュール：２００６．１１に完成予定システム評価をより有効に、正確に、簡便に行うために、 CC/CEMを拡張するもの。 31 現在のISO 15408/18045で運用システムの評価は可能だが？運用システムを評価する際の主要課題 Ⅰ.異なるセキュリティポリシー（目標とする保証内容や許容リスクなど）を持つサブシステムの複合体に対する評価 Ⅱ.日々運用環境が変化するシステムに対する評価と維持 Ⅲ.非ITセキュリティ対策（手続きや規則などの規定による管理など）に対する評価 32 システム評価の位置づけライフサイクル -リスク識別開発/インテグレーション -許容リスク - 開発セキュリティ制御に関わる記録採取 - インテグレーション - 変更レビューとテストリスク評価認定運用/保守潜在リスクの許容 - 構成管理 - テスト - 組織化評価 - セキュリティ制御の規定 (ST作成)と評価 - 脆弱性分析の評価 - システム運用がST準拠を評価 -セキュリティ制御の監視 33 Ⅰ.異なるセキュリティポリシーを持つサブシステムの複合体に対する評価ドメイン: TOE = システムモデル同一のセキュリティポリシーのセット業務サーバドメイン d ドメイン a 業務プログラムドメイン b COTS 製品プリントサーバ DOMAIN c Web サーバデータベースサーバサブシステム: 独立した実行主体、サーバ/クライアントコンポネント: 識別可能な機能単位、製品クライアントクライアントクライアントドメイン e TOE 環境: 他システム, 利用者, など 34 セキュリティ制御事例技術制御機能システム TOE サーバシステムアクセス管理機能技術制御のための管理機能顧客情報利用者属性の登録運用制御のための管理機能運用制御規程利用者の役割規定利用者の役割を規定するための手続き 35 Assurance Requirements: effectiveness Life Cycle Stage Assurance Objectives Risk Counteraction Development Installation Operation Assurance component - System ST(ASE) Operational system architecture - Architecture design (ASD_SAD) - Interface functional specification (ASD_IFS) - Subsystem design (ASD_SSD) - Component design (ASD_CMP) - Implementation representation (ASD_IMP) - Security concept (ASD_COM) Strength of Security Mechanisms - Misuse (AVA_MSU) - Strength of TOE security functions (AVA_SOF) - Vulnerability analysis (AVA_VLA) Communication and awareness training - Awareness training (ASI_AWA) - Communication (ASI_CMM) Monitoring of Security Countermeasures - Verification of operational controls (ASO_VER) - Monitoring of operational controls (ASO_MON) Verification Maintenance Feedback Review - Review (ASM_ASR) - Feedback (ASM_FEB) 36 Assurance Requirements: correctness Life Cycle Stage Development Assurance Objectives Correspondence Between Security Requirements and Security Specification - Correspondence (ADV_RCR) - Identification of security measures (ALC_DVS) Configuration Management - Configuration guidance (AGD_OCD) - Baseline configuration (ACM_OBM) Correspondence with Development Works - Control testing (ATE_AST) Guidance Documents Description - Guidance documents (AGD) Compliance Installation Authorization Operation Maintenance Assurance component - Correct implementation (ASI_IMP) - Compliance (ASI_COM) - Authorization (ASI_AUT) - Site interoperability check (ADO_SIC) Monitoring of Security Countermeasures - Monitoring of operational controls (ASO_MON) Records - Record (ASM_RCD) 37 機能要件の概要技術制御のための機能要件 CCパート２＋修整運用制御のための機能要件運用システム管理(FODクラス） ITシステム運用(FOSクラス）利用者資産運用(FOAクラス）業務運用(FOBクラス）施設・機器運用(FOPクラス）第三者機関管理(FOTクラス）一般管理(FOMクラス）参照規格 -ISO 17799: Code of Practice for Information Security Management -ISO TR 13335: Guidelines for the Management of IT Security -NIST SP 800-53: Recommended Security Controls for Federal Information Systems 38 製品の集合体に対する保証の考え方サーバシステムサブシステムとしての保証要件 (Ex. ASD_SAD,ASD_IFS, ASD_SSD) 業務プログラム OS/ミドルウェア製品群製品としての保証要件構成製品として認証製品（保証パッケージを指定）を要求 39 Ⅱ.日々運用環境が変化するシステムに対する評価と維持評価プロセスセキュリティ目標は必要十分か！ ST評価評価システム開発と運用情報システムはセキュリティ目標に準拠しているか！情報システム評価 ST 設計開発エビデンス開発セキュリティ目標は維持されているか！保証維持変更分析*（定期/事象発生時）運用 *変更がセキュリティ目標に与える影響を分析 40 保証維持の考え方再評価のための入力物更新版 SST システム TOE 更新版エビデンスリスクシステム構成影響分析報告書再評価定期/ 事象発生時前回の評価報告書 41 Ⅲ.非ITセキュリティ対策に対する評価非ITセキュリティ機能要件・保証要件の追加セキュリティ対策方針 T O E のセキュリティ管理対策どのようなセキュリティ管理を実施するかセキュリティ管理要件開発環境のセキュリティ対策方針どれくらいの信頼性を実現するか O E のセキュリティ機能対策どのようなセキュリティ機能を装備するかセキュリティ保証要件拡 T セキュリティ機能要件張 42