X 5070-1：2011 (ISO/IEC 15408-1：2009)
（1）
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
目 次
ページ
序文 ··································································································································· 1
1 適用範囲························································································································· 2
2 引用規格························································································································· 3
3 用語及び定義 ··················································································································· 3
3.1 この規格類で共通の用語及び定義······················································································ 3
3.2 ADVクラスに関連する用語及び定義 ················································································ 11
3.3 AGDクラスに関連する用語及び定義 ················································································ 16
3.4 ALCクラスに関連する用語及び定義 ················································································ 16
3.5 AVAクラスに関連する用語及び定義 ················································································· 20
3.6 ACOクラスに関連する用語及び定義 ················································································ 21
4 略語······························································································································ 21
5 概要······························································································································ 22
5.1 一般 ··························································································································· 22
5.2 TOE ··························································································································· 22
5.3 この規格類の対象読者 ··································································································· 23
5.4 この規格類の各部 ········································································································· 24
5.5 評価の枠組み ··············································································································· 25
6 一般モデル ····················································································································· 25
6.1 序説及び一般モデル ······································································································ 25
6.2 資産及び対抗策 ············································································································ 26
6.3 評価 ··························································································································· 30
7 セキュリティ要件の調整（tailoring） ·················································································· 30
7.1 操作（Operations） ······································································································· 30
7.2 コンポーネント間の依存性 ····························································································· 33
7.3 拡張コンポーネント ······································································································ 33
8 プロテクションプロファイル及びパッケージ ········································································ 34
8.1 序説 ··························································································································· 34
8.2 パッケージ ·················································································································· 34
8.3 プロテクションプロファイル ·························································································· 34
8.4 PP及びパッケージの使用 ······························································································· 37
8.5 複数のプロテクションプロファイルの使用 ········································································· 37
9 評価結果························································································································ 37
9.1 序説 ··························································································································· 37
9.2 PP評価の結果 ·············································································································· 38
9.3 ST評価を含むTOE評価の結果 ······················································································· 38
X 5070-1：2011 (ISO/IEC 15408-1：2009) 目次
（2）
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
ページ
9.4 適合主張 ····················································································································· 38
9.5 ST評価を含むTOE評価の結果の利用 ·············································································· 39
附属書A（参考）セキュリティターゲットの仕様 ······································································ 41
附属書B（参考）プロテクションプロファイルの仕様 ································································· 57
附属書C（参考）操作の指針 ································································································· 62
附属書D（参考）PP適合 ······································································································ 65
附属書JA（参考）ISO/IEC 15408-2 Part 2: Security functional components第2部：セキュリティ機能コ
ンポーネント ······································································································· 66
附属書JB（参考）ISO/IEC 15408-3 Part 3: Security assurance components第3部：セキュリティ保証コ
ンポーネント ······································································································· 69
参考文献 ···························································································································· 71
X 5070-1：2011 (ISO/IEC 15408-1：2009)
（3）
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
まえがき
この規格は，工業標準化法に基づき，日本工業標準調査会の審議を経て，経済産業大臣が改正した日本
工業規格である。
これによって，JIS X 5070-1:2000は改正され，この規格に置き換えられ，JIS X 5070-2:2000及びJIS X
5070-3:2000は廃止された。
この規格は，著作権法で保護対象となっている著作物である。
この規格の一部が，特許権，出願公開後の特許出願又は実用新案権に抵触する可能性があることに注意
を喚起する。経済産業大臣及び日本工業標準調査会は，このような特許権，出願公開後の特許出願及び実
用新案権に関わる確認について，責任はもたない。
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
日本工業規格 JIS
X 5070-1：2011
(ISO/IEC 15408-1：2009)
セキュリティ技術−
情報技術セキュリティの評価基準−
第1部：総則及び一般モデル
Information technology-
Security techniques-Evaluation criteria for IT security-
Part 1: Introduction and general model
序文
この規格は，2009年に第3版として発行されたISO/IEC 15408-1を基に，技術的内容を変更することな
く作成した日本工業規格である。ただし，附属書JA及び附属書JBは，対応国際規格にはない参考事項で
ある。
なお，この規格で点線の下線を施してある参考事項は，対応国際規格にはない事項である。
この規格を含むJIS X 5070規格類（JIS X 5070-1:2011，ISO/IEC 15408-2:2008及びISO/IEC 15408-3:2008）
は，評価機関の行った，異なるセキュリティ評価の結果を比較可能にする。この規格類は，セキュリティ
評価のときにIT製品のセキュリティ機能及びそのIT製品に適応される保証手段に対する共通の要件群を
提供することによって，この比較を可能にする。IT製品はハードウェア，ファームウェア，又はソフトウ
ェアのいずれで実装されてもよい。
注記1 日本工業規格では部で構成する規格がある場合，この部編成の規格全体を総称して，“規格
群”という。この規格では，日本工業規格になっていない国際規格を含めて，規格群をいう
場合は，“規格類”と呼ぶ。また，この規格では，日本工業規格になっていない国際規格を，
ISO/IEC 15408-2:2008を第2部及びISO/IEC 15408-3:2008を第3部という。
注記2 附属書JAに，第2部の目次を示し，附属書JBに，第3部の目次を示している。
評価過程は，IT製品のセキュリティ機能とIT製品に適用される保証手段とがこれらの要件を満たすと
いうレベルの信頼を確立する。評価結果は，そのIT製品が利用者のセキュリティ要求を満たすか否かを利
用者が判断する際の手助けになるであろう。
この規格類は，セキュリティ機能をもつIT製品の開発，評価，及び／又は購入のための指針として役立
つものである。
この規格類は，多種多様なIT製品の様々なセキュリティ特性に対して，多様な評価方法を適用できるよ
うに，意図的に柔軟性をもたせてある。したがって，この柔軟性が誤用されないように，注意を払うのが
望ましい。例えば，この規格類を使用する場合，不適切な評価方法，不適切なセキュリティ特性，又は不
適切なIT製品に対しては，無意味な評価結果を生じるかもしれない。
このため，IT製品が評価を受けたという事実は，評価対象のセキュリティ特性と使用された評価方法と
の枠組みにおいてだけ意味をもつ。認証機関は，製品，特性及び方法を慎重に点検して，評価によって有
2
X 5070-1：2011 (ISO/IEC 15408-1：2009)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
意な結果が提供されることを確認するのが望ましい。また，評価対象の製品の購入者は，評価対象の製品
が購入者の固有な状況及び要求にとって有用であり，適用可能であるかどうかを判断するために，この枠
組みを慎重に検討するのが望ましい。
この規格類は，漏えい（洩），改ざん，又はサービス停止から資産を守る方法に関するものである。この
3種類のセキュリティ確保の失敗に関する保護の分類は，一般にそれぞれ，機密性，完全性及び可用性と
呼ばれている。この規格類はこの3種類以外のITセキュリティの観点にも適用してもよい。この規格類は，
（悪意のある，又は悪意はない）人間の活動から生じるリスク及び人間以外の活動から生じるリスクに適
用可能である。ITセキュリティから離れて，この規格類はITの他の領域に適用してもよいが，この領域
への適用性については何も主張していない。
幾つかの項目には，専門的な技法が必要であったり，ITセキュリティにとってあまり重要でなかったり
することから，この規格類の範囲外とみなされるものがある。これらの項目の一部を次に示す。
a) この規格類は，ITセキュリティ機能に直接関係しない管理上のセキュリティ手段に関するセキュリテ
ィ評価基準を含まない。しかし，多くの場合，セキュリティのかなりの部分が組織管理，人事管理，
物理管理，手順管理などの管理手段によって実現可能なこと又は支援可能なことがある。
b) 電磁波放射制御など，ITセキュリティの技術的な物理的側面の評価は特に対象としていないが，この
規格類で扱われる概念の多くはその領域に適用することができる。
c) この規格類は，基準を適用するときに使用すべき評価方法については扱わない。この方法は，ISO/IEC
18045による。
d) この規格類は，機関が基準を適用する上での管理上及び法律上の枠組みについては扱わない。しかし，
こうした枠組みの状況の下で評価を行う場合にこの規格類を用いることができる。
e) 認定（accreditation）に評価結果を用いるための手続は，この規格類で扱わない。認定は，非IT部分
全てを含む，運用環境全体におけるIT製品（又はその集合体）の運用を，機関が承諾するための管理
行為をいう。評価プロセスの結果は，認定プロセスへの入力となる。しかし，非IT関連の特性の評定，
及びITセキュリティ部分と非IT関連との関係の評定のためには，他の手法の方がより適しているた
め，認定機関（accreditor）はこれらの側面に対して別の手法を利用するのがよい。
f)
暗号化アルゴリズム固有の品質評定のための基準は，この規格類の適用対象外とする。暗号の数学的
特性に対して別途評定が必要な場合，この規格類が適用される評価制度は，そのような評定について
規定しなければならない。
1
適用範囲
この規格は，ITセキュリティ評価の一般的な概念及び原理を定め，IT製品のセキュリティ特性を評価す
る基盤として用いることを意図した規格の様々な部分によって与えられる評価の一般モデルについて規定
する。
この規格は，この規格類の全ての規格の概観を示す。この規格はこの規格類の様々な規格を記述し，こ
の規格類の全ての規格で使用される用語及び略語を定義し，評価対象（TOE）の基本的な概念を定め，評
価の枠組みを定め，評価基準が対象とする利用者を規定する。この規格はIT製品の評価に必要な基本的な
セキュリティの概念を紹介する。
この規格は，様々な操作を定義する。それらの操作によって，この規格類の第2部及び第3部に記述さ
れている機能コンポーネント及び保証コンポーネントを調整できる。
この規格は，プロテクションプロファイル（PP）の主要な概念，セキュリティ要件のパッケージ及び適
3
X 5070-1：2011 (ISO/IEC 15408-1：2009)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
合の主題を規定しており，評価結果についても規定している。この規格はセキュリティターゲット（ST）
の書き方について規定し，モデルを通してコンポーネントの組立て方について規定している。評価方法に
関する一般的な情報及び評価方法の適用範囲は，別の規格であるISO/IEC 18045で規定している。
注記 この規格の対応国際規格及びその対応の程度を表す記号を，次に示す。
ISO/IEC 15408-1:2009，Information technology−Security techniques−Evaluation criteria for IT
security−Part 1: Introduction and general model（IDT）
なお，対応の程度を表す記号“IDT”は，ISO/IEC Guide 21-1に基づき，“一致している”こ
とを示す。
2
引用規格
次に掲げる規格は，この規格に引用されることによって，この規格の規定の一部を構成する。これらの
引用規格は，記載の年の版を適用し，その後の改正版（追補を含む。）は適用しない。
ISO/IEC 15408-2:2008，Information technology−Security techniques−Evaluation criteria for IT security−
Part 2: Security functional components
ISO/IEC 15408-3:2008，Information technology−Security techniques−Evaluation criteria for IT security−
Part 3: Security assurance components
ISO/IEC 18045:2008，Information technology−Security techniques−Methodology for IT security evaluation
3
用語及び定義
この規格類で用いる主な用語及び定義は，次による。
注記 箇条3では，この規格類において特別な意味で用いられる用語だけを示す。この規格類に用い
られる用語の組合せのうち，箇条3に含まれていない用語は，誤解が生じないように出現する
文脈において説明する。
3.1
この規格類で共通の用語及び定義
3.1.1
敵対的な動作（adverse actions）
脅威エージェントが資産に行う動作。
3.1.2
資産（assets）
TOEの所有者が一般に価値を認めるもの。
3.1.3
割付け（assignment）
この規格におけるコンポーネント内又は要件内の識別されたパラメタを規定すること。
3.1.4
保証（assurance）
TOEがSFRを満たしていることへの信頼の基盤。
3.1.5
攻撃能力（attack potential）
TOEへの攻撃に攻撃者が費やすことができる労力の尺度であって，攻撃者の技能，資源及び動機の観点
から表現されるもの。
4
X 5070-1：2011 (ISO/IEC 15408-1：2009)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
3.1.6
要件追加（augmentation）
パッケージへの一つ以上の要件の追加。
3.1.7
認証データ（authentication data）
利用者の認証に用いられる情報。
3.1.8
正当な利用者（authorised user）
SFRに従って，操作を実行することができるTOE利用者。
3.1.9
クラス（class）
共通の目的をもつファミリの集合。
3.1.10
理路整然とした（coherent）
論理的順序で並べられ，識別できる意味をもつ（連体修飾）。
注記 証拠資料の場合は，文書内容及び文書構造の両方が，対象読者にとって理解できるものである
ことを意味する。
3.1.11
完全な（complete）
エンティティの全ての必要な部分が提供されている（連体修飾）。
注記 証拠資料の場合は，抽象化のレベルにおいてこれ以上の説明が必要ない詳細レベルで，全ての
関連する情報が証拠資料において扱われていることを意味する。
3.1.12
コンポーネント（component）
要件を構成する最小の選択可能なエレメントのセット。
3.1.13
統合保証パッケージ（composed assurance package）
この規格類第3部（主にACOクラス）から抽出された要件からなる，定義済み統合保証尺度での程度
を表す保証パッケージ。
3.1.14
確認する（confirm）
詳細にレビューし，充足性を第三者として示す。
注記 必要とされる厳格性のレベルは，内容によって異なる。この用語は，評価者アクションだけに
適用される。
3.1.15
接続性（connectivity）
TOEと外部のITエンティティとの対話を可能にするTOEの特性。
注記 接続性には，任意の環境又は構成において任意の距離を介して，有線手段又は無線手段によっ
て行われるデータ交換が含まれる。
5
X 5070-1：2011 (ISO/IEC 15408-1：2009)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
3.1.16
一貫した（consistent）
複数のエンティティ間に明らかな矛盾が存在しない（連体修飾）。
3.1.17
対抗する（counter）
特定の脅威の影響を緩和する。脅威の影響を完全になくす必要はない。
3.1.18
例証適合（demonstrable conformance）
PPにおける一般的なセキュリティ課題の解決方法をSTが提供するというSTとPPとの関係。
注記 PP及びSTは，異なるエンティティについて全く異なる記述を含み，異なる概念などを使用す
ることができる。例証適合は，複数の同様のPPが既に存在するTOEの種別にも適している。
これによって，ST作成者はこれらのPPに対する適合を同時に主張し，作業量を減らすことが
できる。
3.1.19
例証する（demonstrate）
分析によって得られる結果を提供する。この結果は“証明（proof）”ほど厳格ではない。
3.1.20
依存性（dependency）
依存するコンポーネントに基づく要件がPP，ST又はパッケージに含まれる場合，一般に，依存される
コンポーネントに基づく要件もそのPP，ST又はパッケージに含まれなければならない，というコンポー
ネント間の関係。
3.1.21
記述する（describe）
エンティティの一定の詳細を提供する。
3.1.22
決定する（determine）
独立に分析し，一定の結論に到達する。
注記 この用語は，通常，これまでの分析を考慮しない，真に独立した分析を意味する。レビューす
る必要のある分析が既に行われていることを意味する用語である“確認する（confirm）”又は
“検証する（verify）”と対比される。
3.1.23
開発環境（development environment）
TOEが開発される環境。
3.1.24
エレメント（element）
セキュリティ上必要な事項の，最小単位の記述。
3.1.25
確実にする（ensure）
アクション（開発者アクション及び評価者アクション）が結果をもたらすことを保証する。
注記 この用語が“助ける（help）”などとともに用いられる場合は，結果が，そのアクションだけで
6
X 5070-1：2011 (ISO/IEC 15408-1：2009)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
は完全には確実でないことを示す。
3.1.26
評価（evaluation）
定義された基準に基づき，PP，ST又はTOEを評定すること。
3.1.27
評価保証レベル（evaluation assurance level）
この規格類第3部から抽出された保証要件の集合で，定義済み保証尺度での程度を表し，保証パッケー
ジを構成するもの。
3.1.28
評価機関（evaluation authority）
特定のコミュニティにおいて，評価制度に基づきこの規格類を適用し，標準を定め，評価の品質を監視
する機関。
3.1.29
評価制度（evaluation scheme）
評価機関が特定のコミュニティにおいて，この規格類を適用するときの管理及び規制の枠組み。
注記 我が国における評価制度の名称は，“ITセキュリティ評価及び認証制度”である。
3.1.30
徹底的な（exhaustive）
曖昧さを排除した計画に従って分析又は他の活動を行う，方法論的に整備されたアプローチ（連体修飾）。
注記 この用語は，分析などの活動を実施するときに用い，“系統的な”よりもかなり強い意味で用い
る。明快な計画に従って分析又は他の活動を行うときに系統的なアプローチを選択したことだ
けでなく，活動に使われる計画そのものが全ての可能性を尽くすことを保証するのに十分であ
る。
3.1.31
説明する（explain）
行った活動の理由を示す。
注記 問われた場合，“行った活動が必然的に最適であった”という議論を試みることをせずに，“な
ぜ？”という問いへの答えを意図している。この用語は，“記述する（describe）”及び“例証す
る（demonstrate）”とは異なる。
3.1.32
拡張（extension）
この規格類第2部に含まれていない機能要件及び／又はこの規格類第3部に含まれていない保証要件を
ST又はPPに追加すること。
3.1.33
外部エンティティ（external entity）
TOE境界の外からTOEと交信する可能性がある人エンティティ又はITエンティティ。
3.1.34
ファミリ（family）
類似する目標をもつが，着眼点又は厳密さが異なるコンポーネントの集合。
7
X 5070-1：2011 (ISO/IEC 15408-1：2009)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
3.1.35
形式的（な）（formal）
確立した数学上の概念に基づいて，意味が定義された制限付き構文言語で表現されている（連体修飾）。
3.1.36
ガイダンス文書（guidance documentation）
TOEの配付，立上げ，操作，管理及び／又は使用法について記述した文書。
3.1.37
識別情報（identity）
TOEの文脈内のエンティティ（利用者，プロセス，ディスクなど）を一意に識別する表現。
注記 このような表現の例は文字列である。利用者が人間の場合，表現は利用者の氏名若しくは略称，
又は（一意に識別化の可能な）擬似名であってもよい。
3.1.38
非形式的（な）（informal）
自然言語で表現されている（連体修飾）。
3.1.39
TSF間転送（inter TSF transfers）
TOEと他の信頼できるIT製品のセキュリティ機能との間でデータを通信すること。
3.1.40
内部通信チャネル（internal communication channel）
TOE内部の別々の部分間のチャネル。
3.1.41
TOE内転送（internal TOE transfer）
TOE内部の別々の部分間でデータを通信すること。
3.1.42
内部的に一貫した（internally consistent）
エンティティのどの側面の間にも明らかな矛盾がない（連体修飾）。
注記 証拠資料のどの2か所をつき合わせても矛盾していると解釈できる部分がないことを意味す
る。
3.1.43
繰返し（iteration）
二つ以上の異なる要件を表現するのに同一コンポーネントを使用すること。
3.1.44
正当化（justification）
決定を導く分析。
注記 正当な例証より厳密である。この語は注意深く徹底的に論理的に一つ一つ確認していくという
意味で格段の厳密性を要する。
3.1.45
オブジェクト（object）
情報を保持したり受け取ったりするTOE内の受動的なもので，サブジェクトが行う操作の対象となるエ
ンティティ。
8
X 5070-1：2011 (ISO/IEC 15408-1：2009)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
3.1.46
操作（JIS X 5070のコンポーネントに対する）［operation (on a component of JIS X 5070)］
コンポーネントを修正したり繰り返したりすること。
注記 コンポーネントに許される操作は，割付け，繰返し，詳細化及び選択である。
3.1.47
操作（オブジェクトに対する）［operation (on an object)］
オブジェクトに対してサブジェクトが行える，特定の種類のアクション。
3.1.48
運用環境（operational environment）
TOEを運用する環境。
3.1.49
組織のセキュリティ方針（organizational security policy）
組織のためのセキュリティ規則，手順又は指針の集まり。
注記 セキュリティ方針は，特定の運用環境だけに対応することもある。
3.1.50
パッケージ（package）
名前の付いた機能要件又は保証要件の集合。
注記 パッケージの例に“EAL 3”がある。
3.1.51
PP評価（PP evaluation）
定義済みの評価基準を用いてPPを評定すること。
3.1.52
プロテクションプロファイル，セキュリティ要求仕様書（Protection Profile）
ある種別のTOEに対するセキュリティの要求を実装に依存しないように記述した文書。
3.1.53
証明する（prove）
数学的な意味での形式的分析による対応関係を示す。
注記 この分析では，あらゆる面で完全な厳密性が要求される。通常，二つのTSF表現の対応関係を
高いレベルの厳密性で示す必要がある場合に，“証明する”を使用する。
3.1.54
詳細化（refinement）
コンポーネントに詳細な内容を追加すること。
3.1.55
役割（role）
利用者とTOEとの間で許されている交信を規定する定義済みの規則の集まり。
3.1.56
秘密（secret）
特定のSFPを実施するために，正当な利用者及び／又はTSFにしか知らせてはならない情報。
3.1.57
セキュアな状態，セキュリティの確保された状態（secure state）
9
X 5070-1：2011 (ISO/IEC 15408-1：2009)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
TSFデータが一貫しており，TSFがSFRの正確な実施を継続している状態。
3.1.58
セキュリティ属性（security attribute）
サブジェクト，利用者（TOE範囲外のIT製品を含む。），オブジェクト，情報，セッション及び／又は
資源の特性のうち，SFRを定義する場合に使用し，SFRを実施する場合にその値を使用するもの。
3.1.59
セキュリティ機能方針（security function policy）
TSFによって実施され，SFRの集まりとして表現できる特定のセキュリティの振る舞いを記述する規則
の集まり。
3.1.60
セキュリティ対策方針（security objective）
識別された脅威へ対抗することを意図した記述，並びに／又は識別された組織のセキュリティ方針及び
／若しくは前提条件を満たすことを意図した記述。
3.1.61
セキュリティ課題（security problem）
TOEが対処するよう意図されたセキュリティの本質及び範囲を規定する，一定の形式に従った記述。
注記 この記述は次の組合せから構成される。
・TOEが対抗すべき脅威。
・TOEが実施すべきOSP。
・TOEとその運用環境とが満たすべき前提条件。
3.1.62
セキュリティ要件（security requirement）
TOEのセキュリティ対策方針の達成に寄与するように定められている，標準的な言い回しで記述された
要件。
3.1.63
セキュリティターゲット，セキュリティ設計仕様書（Security Target, ST）
特定の識別されたTOEに対するセキュリティの要求を，実装に依存するように記述した文書。
3.1.64
選択（selection）
コンポーネント内のリストから一つ以上の項目を指定すること。
3.1.65
準形式的（な）（semiformal）
意味が定義された制限付き構文言語で表現されている（連体修飾）。
3.1.66
規定する（specify）
あるエンティティの固有の詳細を，厳密かつ正確に提供する。
3.1.67
正確適合（strict conformance）
PPにおける全ての要件がSTにもまた存在する，STとPPとの階層的な関係。
10
X 5070-1：2011 (ISO/IEC 15408-1：2009)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
注記 この関係は，“STには，PPの全ての項目を含めなければならないか，それ以上の項目を加える
ことができる”（包含関係）として大まかに定義することができる。正確適合は，指定された方
法に厳格に従う要件である。
3.1.68
ST評価（ST evaluation）
定義済みの評価基準に用いてSTを評定すること。
3.1.69
サブジェクト（subject）
オブジェクトに対して操作を実行するTOE内の能動的なエンティティ。
3.1.70
評価対象 TOE（target of evaluation）
ガイダンス文書が添付されることもある，ひとまとまりのソフトウェア，ファームウェア及び／又はハ
ードウェア。
3.1.71
脅威エージェント（threat agent）
資産に対して敵対的な動作を行うエンティティ。
3.1.72
TOE評価（TOE evaluation）
定義済みの評価基準を用いてTOEを評定すること。
3.1.73
TOE資源（TOE resource）
TOE内で使用可能な又は消費可能なもの。
3.1.74
TOEセキュリティ機能（TOE security functionality）
SFRを正確に実現するために必要なTOEのハードウェア機能，ソフトウェア機能及び／又はファームウ
ェア機能の組合せ。
3.1.75
たどる，追跡する（trace）
最小限の厳密性で，二つのエンティティ間の対応関係の非形式的分析を実施する。
注記 例えば，セキュリティ機能要件からその元となるセキュリティ対策方針まで遡って確認できる
こと。
3.1.76
TOE範囲外への転送（transfers outside of the TOE）
TSFの制御下にないエンティティに対して，TSFが仲介して行われるデータ通信。
3.1.77
変換（translation）
標準的な言い回しでセキュリティ要件を記述する処理。
注記 この意味で変換という用語を使用することはこの用語の文字どおりの意味ではなく，また，標
準的な言い回しで表現される全てのSFRをセキュリティ対策方針に逆変換できることを意味す
るものでもない。
11
X 5070-1：2011 (ISO/IEC 15408-1：2009)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
3.1.78
高信頼チャネル（trusted channel）
TSFと別の信頼できるIT製品とが，必要な信頼をもって通信することができる手段。
3.1.79
高信頼IT製品（trusted IT product）
TOEと運用上，整合されたセキュリティ機能要件をもち，そのセキュリティ機能要件を正しく実現する
とみなされるTOE以外のIT製品。
注記 高信頼IT製品の一例として，別個に評価されたものがある。
3.1.80
高信頼パス（trusted path）
利用者とTSFとが，必要な信頼をもって通信することができる手段。
3.1.81
TSFデータ（TSF data）
SFRの実施に影響する，TOEの動作に必要なデータ。
3.1.82
TSFインタフェース（TSF interface）
外部エンティティ（又はTSF外にあるTOE内のサブジェクト）が，TSFへデータを提供し，TSFから
データを受信し，TSFからサービスを呼び出す手段。
3.1.83
利用者データ（user data）
TSFの動作に影響を与えない，利用者のためのデータ。
3.1.84
検証する（verify）
充足性について独自の判断ができる程度に厳密に，第三者として確かめる。
注記 “3.1.14確認する（confirm）”も参照する。この“検証する（verify）”という用語は，“確認す
る（confirm）”よりも厳格な意味合いをもつ。評価者に独自の調査・分析作業を要求する場合，
この用語は評価者アクションの中で使用される。
3.2
ADVクラスに関連する用語及び定義
注記1 次の用語は，ソフトウェアの内部構造に対する要件で使用する。これらの用語の幾つかは，
“the IEEE Std 610.12-1990，Institute of Electrical and Electronics Engineers, Standard Glossary of
Software Engineering Terminology”による。
注記2 3.2から3.6までに示す，ADVクラス，AGDクラス，ALCクラス，AVAクラス及びACOク
ラスは，この規格類第3部に定義されたクラスである。
3.2.1
管理者（administrator）
TSFが実装する全ての方針に関して，あるレベルの信頼を得ているエンティティ。
注記 全てのPP又はSTが管理者に対して同一のレベルを仮定しているわけではない。一般的に管理
者は，TOEのST中の方針に従うものと仮定されている。これらの方針のうち幾つかは，TOE
の機能要件に関係し，その他のものは，運用環境に関係している。
12
X 5070-1：2011 (ISO/IEC 15408-1：2009)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
3.2.2
呼出し木，コールツリー（call tree）
モジュールが相互に呼び出し合っている関係を表す図中で，システム内のモジュールを示す図の形態。
注記 IEEE Std 610.12-1990による。
3.2.3
凝集，凝集度，モジュール強度（cohesion）
単一のソフトウェアモジュールによって実行されるタスクが，相互に関連付けられる方法及びその度合
い。
[IEEE Std 610.12-1990]
注記 凝集の種類には，偶発的凝集，通信的凝集，機能的凝集，論理的凝集，逐次的凝集及び時間的
凝集がある。これらの凝集の種類については，対応する用語の項に定義している。
3.2.4
偶発的凝集（coincidental cohesion）
モジュール関連が全くない，又はほとんどないアクティビティを実行するような特性をもつ凝集。
[IEEE Std 610.12-1990]
注記 “凝集”（3.2.3）も参照。
3.2.5
通信的凝集（communicational cohesion）
モジュール内の他の機能に対する出力を生成する機能，又はモジュール内の他の機能からの出力を使用
する機能をもつ凝集。
[IEEE Std 610.12-1990]
注記1 “凝集”（3.2.3）も参照。
注記2 通信的に凝集するモジュールの例には，強制アクセスの検査，任意アクセスの検査及びアク
セス権限の検査を含む，アクセスチェックモジュールがある。
3.2.6
複雑性（complexity）
ソフトウェアの理解（分析，試験及び保守）のしづらさ。
[IEEE Std 610.12-1990]
注記 複雑性の軽減は，モジュールの分解，階層化及び最小化を用いる際の最終目標である。結合度
及び凝集度の管理は，この目標に大きく寄与する。
ソフトウェア工学分野では，ソースコードの複雑性を測定するための尺度を開発するための
試みに，多大な労力が費やされてきた。これらの尺度の多くは，演算子及びオペランドの数，
制御フロー図の複雑性（循環的複雑性），ソースコードの行数，実行可能コードに対するコメン
トの比率，その他類似する指標などの，簡単に算定できるソースコードの特性を使用している。
より簡単に理解できるコードを生成する上で，コーディング標準は，有効な手段であることが
分かってきた。
このTSF内部構造（ADV̲INT）ファミリは，全てのコンポーネントで複雑性分析を要求する。
開発者は，複雑性が十分に軽減されたことを主張するために，その裏付けを提供することが求
められる。この裏付けとしては，開発者が使用したプログラミング標準，及び全てのモジュー
ルが標準に適合していること（適合しない場合には，ソフトウェア工学の論証によって例外が
13
X 5070-1：2011 (ISO/IEC 15408-1：2009)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
正当化されていること）の明示，ソースコードの特性の幾つかを測定するために使用したツー
ルの結果，開発者が適切とみなすその他の裏付けなどがある。
3.2.7
結合（coupling）
ソフトウェアモジュール間の相互依存の方法及びその度合い。
[IEEE Std 610.12-1990]
注記 結合の種類には，呼出し結合，共通結合及び内容結合がある。これらについては3.2.8から3.2.13
までで定義する。
3.2.8
呼出し結合（call coupling）
設計資料に記載された関数呼出し手続に厳密に従って，通信する場合の二つのモジュール間の関係。
注記 呼出し結合の例には，データ結合，スタンプ結合及び制御結合がある。3.2.9から3.2.11までで
定義する。
3.2.9
データ形呼出し結合［call coupling (data)］
設計資料に記載された関数呼出し手続に厳密に従い，かつ，厳密に単一データ項目の呼出しパラメタを
使用して通信する場合の二つのモジュール間の関係。
注記 “呼出し結合”（3.2.8）も参照。
3.2.10
スタンプ形呼出し結合［call coupling (stamp)］
複数のフィールドからなる呼出しパラメタ，又は意味のある内部構造をもつ呼出しパラメタを使用して
通信する場合の，二つのモジュール間の関係。
注記 “呼出し結合”（3.2.8）も参照。
3.2.11
制御形呼出し結合［call coupling (control)］
その一方が他方の内部ロジックに影響するように意図された情報を渡す場合の，二つのモジュール間の
関係。
注記 “呼出し結合”（3.2.8）も参照。
3.2.12
共通結合（common coupling）
共通データ領域又は共通システム資源を共有する場合の，二つのモジュール間の関係。
注記 グローバル変数は，その変数を使用するモジュールが共通結合されていることを示す。グロー
バル変数による共通結合は，一般に許可されているが，その結合度は制限される。
例えば，グローバル領域に配置されているが，単一のモジュールだけが使用する変数は，グ
ローバル領域への配置が不適切であり，その領域から削除するのが望ましい。グローバル変数
の適切性を評定するときに検討する必要がある，その他の要因には，次のものがある。
1) グローバル変数を変更するモジュールの数： 一般に，グローバル変数の内容の制御に関す
る責任は，一つのモジュールだけに割り当てるのが望ましいが，その責任を別のモジュー
ルと共有する状況が発生するかもしれない。このような場合には，十分な正当性を提示す
る必要がある。この責任を三つ以上のモジュールが共有することは容認できない（この評
14
X 5070-1：2011 (ISO/IEC 15408-1：2009)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
定を行う場合において注意することは，変数の内容に関して実際に責任を負う一つのモジ
ュールを決定することである。例えば，変数を変更するために一つのルーチンが使用され
るとして，そのルーチンが単にその呼出し側から要求された変更を実行する場合，その責
任を負うのは呼出し側のモジュールであり，そのようなモジュールが複数存在する可能性
がある。）。さらに，複雑性の決定手続の一つとして，二つのモジュールがグローバル変数
の内容に関して責任を負う場合，その変更が，それらのモジュール間でどのように調整さ
れるかを明確に示すことが望ましい。
2) グローバル変数を参照するモジュールの数：一般に，グローバル変数を参照するモジュー
ルの数に制限はないが，多数のモジュールが参照する場合には，有効性及び必要性を検査
するのが望ましい。
3.2.13
内容結合（content coupling）
その一方が他方の内部を直接参照することができる場合の，二つのモジュール間の関係。
注記 例えば，他方のモジュールのコードを変更する場合，又は他方のモジュールの内部ラベルを参
照する場合を含む。内容結合の結果，一方のモジュールの内容の一部又は全部が，他方のモジ
ュールに実質的に包含される。内容結合は，公表されていないモジュールインタフェースを使
用しているとみなすことができる。これは，公表されているモジュールインタフェースだけを
使用する呼出し結合とは対照的である。
3.2.14
ドメイン分離（domain separation）
TSFが，各々の利用者とそのTSFとに対して別々のセキュリティドメインを定義し，別の利用者のセキ
ュリティドメイン又はTSFの内容に影響を与えることができる利用者プロセスが存在しないことを保証す
るセキュリティアーキテクチャ特性。
3.2.15
機能的凝集（functional cohesion）
単一の目的に関連するアクティビティを実行するようなモジュールの機能的特性。
[IEEE Std 610.12-1990]
注記 機能的に凝集するモジュールの例には，単一タイプの入力を単一タイプの出力に変換する，ス
タックマネージャ，キューマネージャなどがある。“凝集”（3.2.3）も参照。
3.2.16
交信（interaction）
エンティティ間の一般的な通信に基づくアクティビティ。
3.2.17
インタフェース（interface）
コンポーネント又はモジュールと交信するための手段。
3.2.18
階層化（layering）
ある層がサービスに関して階層内でそれより下の層だけに依存し，更に，そのサービスをそれより上の
層だけに提供するように，モジュールの独立したグループが，個々の責任をもつよう階層的に体系化され
たソフトウェアの設計技法。
15
X 5070-1：2011 (ISO/IEC 15408-1：2009)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
注記 各層がその直下の層からだけサービスを受け，その直上の層にだけサービスを提供するように
制約を強化したものを，厳密な階層化と呼ぶ。
3.2.19
論理的凝集，手続的凝集（logical cohesion, procedural cohesion）
類似するアクティビティを異なるデータ構造で実行するような特性をもつ凝集。
注記 モジュールの機能が，異なった入力に対して，異なっていても関連した操作を行う場合，論理
的凝集のモジュールである。“凝集”（3.2.3）も参照。
3.2.20
モジュール分解（modular decomposition）
設計，開発及び評価を容易にするためにシステムをコンポーネントに分割するプロセス。
[IEEE Std 610.12-1990]
3.2.21
非バイパス性（TSFの）［non-bypassability (of the TSF)］
全てのSFR関連アクションがTSFによって仲介される，セキュリティアーキテクチャ特性。
3.2.22
セキュリティドメイン（security domain）
能動的なエンティティがアクセスすることができる資源の集まり。
3.2.23
逐次的凝集（sequential cohesion）
各機能の出力がその次の機能の入力となる特性をもつモジュール。
[IEEE Std 610.12-1990]
注記 逐次的に凝集するモジュールの例には，監査レコードを書き出す機能及び特定タイプの監査違
反の累積数をカウントし続ける機能を含むモジュールがある。
3.2.24
ソフトウェア工学（software engineering）
ソフトウェアの開発，運用及び保守に対する，系統的かつ規則的で定量化可能な手法の適用（すなわち，
ソフトウェアに工学技術を適用すること。）。
[IEEE Std 610.12-1990]
注記 一般的に工学技術を実践するのと同様に，工学技術の原則を適用するときに，ある程度の見識
をもたなければならない。数多くの要因が，モジュール分解，階層化，最小化，その他の手段
の選択に影響する。例えば，開発者は，当初は実装されないが将来使用するアプリケーション
を念頭に置いてシステムを設計することがある。この場合，開発者は，将来使用するアプリケ
ーションを処理するロジックを，それらのアプリケーションを完全に実装する前に組み込むこ
とを選択するかもしれない。さらに，まだ実装されていないモジュールに対するコールを幾つ
か組み込んで，コールスタブ（call stub）をそのまま残すかもしれない。適切に構造化されたプ
ログラムからのこのような逸脱に対して開発者の正当性は，優れたソフトウェア工学の規則を
適用するとともに見識をもって評定する必要がある。
3.2.25
時間的凝集（temporal cohesion）
機能を同時に実行する必要がある特性をもつモジュール。
16
X 5070-1：2011 (ISO/IEC 15408-1：2009)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
注記1 ［IEEE Std 610.12-1990］による。
注記2 時間的に凝集するモジュールの例には，初期化，回復，シャットダウンなどのモジュールが
ある。
3.2.26
TSF自己保護（TSF self-protection）
TSF以外のコード又はエンティティによって，TSFが破損されることのないセキュリティアーキテクチ
ャ特性。
3.3
AGDクラスに関連する用語及び定義
3.3.1
設置（installation）
TOE運用環境への組込み，運用状態にするために人間が行う手続。
注記 この作業はTOEを受領して受け入れた後に，通常は，1回だけ実行される。TOEは，STで許
されたように，構成されるように求められる。TOEをセキュアな設定にするために，開発者が
実行しなければならない同様のプロセスの場合，ライフサイクルサポート（ALC）全体を通じ
て，それらのプロセスを“生成”という。TOEに，定期的に繰り返す必要のない初期立上げが
必要である場合，このプロセスを設置と分類する。
3.3.2
運用（operation）
TOEの配布，準備後の“通常使用”，管理及び保守を含むTOEの使用フェーズ。
3.3.3
準備（preparation）
配付されたTOEの利用者による受入れと，起動，初期化，立上げ，運用可能な状態へのTOEの遷移な
どを含む設置とで構成される，製品ライフサイクルの1フェーズにおけるアクティビティ。
3.4
ALCクラスに関連する用語及び定義
3.4.1
受入れ基準（acceptance criteria）
受入れ手順（例えば，文書のレビュー，ソフトウェア，ファームウェア又はハードウェアの試験）を実
施する場合に用いる基準。
3.4.2
受入れ手順（acceptance procedures）
作成又は修正した構成要素を，TOEの一部として受け入れるため，又はライフサイクルの次の段階へ移
行するために従う手順。
注記 この手順は，受入れ及び受入れの決定に用いる基準について責任をもつ役割又は個人を明確に
する。受入れ状況には次に示す複数の種類があり，その幾つかの状況は重複してもよい。
a) 構成要素を最初に構成管理（configuration management）システムへ受け入れる場合。
特に，他の製造業者のソフトウェア，ファームウェア及びハードウェアの構成要素をTOE
へ追加する場合（“統合”）。
b) TOEを構築する各工程（例えば，モジュール，サブシステム，完成したTOEの品質管理）
において，構成要素を次のライフサイクルのフェーズへ移行するために受け入れる場合。
17
X 5070-1：2011 (ISO/IEC 15408-1：2009)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
c) 異なる開発サイト間で，構成要素（例えば，TOE又は暫定製品の一部）を搬送後に受け入
れる場合。
d) 利用者へのTOEの配付後に受け入れる場合。
3.4.3
構成管理，CM（configuration management, CM）
技術的及び管理的な指示及び監視の適用であって，構成要素の機能的特性及び物理的特性を識別し文書
化すること，それらの特性の変更処理及び実装状態を記録し報告すること，並びに指定された要件へのコ
ンプライアンスについての検証を行うこと。
注記 ［IEEE Std 610.12-1990］による。
3.4.4
CM 文書（CM documentation, documentation of the CM system）
CM出力，CMリスト（構成リスト），CMシステム記録，CM計画及びCM使用法文書を含む，全ての
CM文書。
3.4.5
構成管理証拠（configuration management evidence）
CMシステムの正しい運用を確証するのに使われても差し支えのない全てのもの。
注記 例えば，CM出力，開発者が提供する理論的根拠，サイト訪問中に評価者が行う観察，実験，
インタビュー。
3.4.6
構成要素（configuration item）
TOE開発中に，CMシステムが管理するオブジェクト。
注記 CM要素は，TOEの一部又は評価文書若しくは開発ツールのようなTOEの開発関連のオブジェ
クトでもよい。CM要素は，（ファイルなどのように）直接，又は（ハードウェア部品などのよ
うに）バージョンを含む参照情報をCMシステムに格納してもよい。
3.4.7
構成リスト（configuration list）
特定の製品に関する全ての構成要素をリスト化した構成管理出力文書であって，完成した製品の特定の
バージョンと関連する，個々の構成管理要素の正確なバージョンを伴っているもの。
注記 構成管理リストによって，製品の評価バージョンに属している構成要素を，製品の他バージョ
ンに属している異なるバージョンの同一構成要素から，区別することができる。最終構成管理
リストは，特定の製品の特定のバージョンのための特定の文書である。構成管理リストは構成
管理ツール内の電子文書とすることができる。その場合には，システムからの印刷出力ではな
く，システム全体又はシステムの一部を指定した方法で見ることができる。しかし，実際の評
価では，構成リストは評価文書の一部として印刷して配付されるであろう。構成リストは，
ALC̲CMCの構成管理要件の下にある構成要素を特定する。
3.4.8
構成管理出力（configuration management output）
構成管理システムが作成又は実施し，構成管理に関連する結果。
18
X 5070-1：2011 (ISO/IEC 15408-1：2009)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
注記 構成管理関連の成果は，行為（構成管理の指示を実現するための手動による処置など）と同様
に，文書（記入された定型用紙，構成管理システムの記録，ログデータ，ハードコピー，電子
出力データなど）として生じる。このような管理構成出力の例には，構成リスト，構成管理計
画及び／又は製品のライフサイクル中の振る舞いがある。
3.4.9
構成管理計画（configuration management plan）
TOEに対して構成管理システムをどのように使用するかの記述。
注記 構成管理計画を発行する目的は，担当者が何をしなければならないのかを明確にすることであ
る。構成管理システム全体からは，（構成管理システムを適用する過程で作られてもよいため）
構成管理計画は構成管理システムの出力文書の一つと見ることができる。プロジェクトチーム
の担当者が，プロジェクトで行わなければならない各作業を理解するために使うため，具体的
なプロジェクトからは，構成管理計画は使用法文書に見える。構成管理計画は，特定の製品に
対する構成管理システムの使用方法を規定する。同一の構成管理システムを，他の製品の異な
る範囲で使用してもよい。すなわち，構成管理計画は，TOE開発の期間中使用する，組織の構
成管理システムが出力するものを規定し，記述する。
3.4.10
構成管理システム（configuration management system）
開発者が，製品ライフサイクルの開発及び保守で使用する，手順及びツール（それらの説明文書を含む。）
全体の総称。
注記 構成管理システムは，異なれば，厳密さ及び機能の程度も異なってくる。評価保証の高いレベ
ル（のEAL）では，構成管理システムの，欠陥修正，変更管理及び他の追跡機構を自動化する
かもしれない。
3.4.11
構成管理システム記録（configuration management system records）
構成管理システムの運用中に生成される出力であって，重要な構成管理活動を文書化するもの。
注記 構成管理システム記録の例には，構成管理要素の変更管理記録，アクセス承認記録などがある。
3.4.12
構成管理ツール（configuration management tools）
構成管理システムを実現又は支援するツール（TOEの部品のバージョン管理のためのツールなど）。ツ
ールは，人手による運用でも自動化された運用でもよい。
3.4.13
構成管理使用法文書（configuration management usage documentation）
ツール及び手順のハンドブック，規則，文書などを用いて，構成管理システムを規定し，適用するよう
に記述した，構成管理システムの一部。
3.4.14
配付（delivery）
完成したTOEを，製造環境から利用者の手元まで送り届けること（電子的手段を含む。）。
注記 このライフサイクルフェーズには，開発サイトにおけるパッケージ化及び格納を含んでもよい
が，未完成のTOE又はTOEの一部を，異なる開発者又は異なる開発サイトの間で搬送するこ
とは含まない。
19
X 5070-1：2011 (ISO/IEC 15408-1：2009)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
3.4.15
開発者（developer）
TOEの開発に責任をもつ組織。
3.4.16
開発（development）
TOEの実装表現の生成に関連する製品ライフサイクルのフェーズ。
注記 ALC要件全般では，開発及び関連用語（開発者，開発する）が，より一般的な意味で開発及び
製造を含むように意図されている。
3.4.17
開発ツール（development tools）
TOEの開発製造を支援するツール（該当する場合はテストソフトウェアも含む。）。
注記 ソフトウェアTOEの場合は，一般に，プログラム言語，コンパイラ，リンカ及び生成ツールが
開発ツールである。
3.4.18
実装表現（implementation representation）
最も抽象度の低いTSFの表現。具体的には，それ以上の設計の詳細化をすることなく，それ自体でTSF
を作成するのに使用される表現。
注記 すぐにコンパイルされる状態にあるソースコード，又は実際のハードウェアの製造に用いられ
るハードウェア図面は，実装表現の一部の例である。
3.4.19
ライフサイクル（life-cycle）
オブジェクト（例えば，製品，システムなど）が存在する期間における一連の段階。
3.4.20
ライフサイクル定義（life-cycle definition）
ライフサイクルモデルの定義。
3.4.21
ライフサイクルモデル（life-cycle model）
ある特定のオブジェクトのライフサイクルの管理で使用される各段階及びそれらの関係の記述であって，
各段階のつながり具合，各段階の上位レベル特性（概念的特性）などを記述するもの。
注記 図1参照。
3.4.22
製造（production）
製造ライフサイクルのフェーズは，開発フェーズに続き，実装表現からTOEの実装への変換，つまり利
用者に配付できる状態への変換で構成される。
注記1 このフェーズは，TOEの製作，統合，生成，内部転送，保管及びラベル付けで構成すること
ができる。
注記2 図1参照。
20
X 5070-1：2011 (ISO/IEC 15408-1：2009)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
図1−CM及び製品ライフサイクルの用語
3.5
AVAクラスに関連する用語及び定義
3.5.1
隠れチャネル（covert channel）
利用者にマルチレベル分離方針及びTOEの観察不能性要件に秘密裏に違反させてしまう不正信号チャ
ネル。
3.5.2
検出した潜在するぜい弱性（encountered potential vulnerabilities）
評価者が評価中に検出した，SFRの侵害に使用される可能性のあるTOEに潜在するぜい弱性。
3.5.3
悪用可能なぜい弱性（exploitable vulnerability）
TOEの運用環境でSFRを侵害するために使用可能なTOEの弱点。
3.5.4
監視攻撃（monitoring attacks）
ガイダンス文書に対応した方法でTOEを運用することによって，TOEの内部機密データの暴露を目的
とする受動的な解析技術を含む攻撃方法の包括的なカテゴリ。
3.5.5
潜在するぜい弱性（potential vulnerability）
存在が懸念されるが確認されていない弱点。
注記 存在が懸念されるとは，SFRを侵害する攻撃経路が想定されることである。
3.5.6
残存するぜい弱性（residual vulnerability）
TOEの運用環境では悪用できないが，TOEの運用環境において想定を超える攻撃力をもつ攻撃者が，SFR
21
X 5070-1：2011 (ISO/IEC 15408-1：2009)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
を侵害するために使用可能な弱点。
3.5.7
ぜい弱性（vulnerability）
ある環境のSFRを侵害するために使用可能なTOEの弱点。
3.6
ACOクラスに関連する用語及び定義
3.6.1
基本コンポーネント（base component）
自身が評価の対象であり，従属コンポーネントにサービス及び資源を提供する，統合TOE内のエンティ
ティ。
3.6.2
互換性のあるコンポーネント［compatible (components)］
同様の運用環境で，各コンポーネントの対応するインタフェースを通じて，他のコンポーネントが要求
するサービスを提供可能なコンポーネントの特性。
3.6.3
コンポーネントTOE （component TOE）
評価に合格したTOEであって，他の統合TOEの部品となるもの。
3.6.4
統合TOE （composed TOE）
評価に合格した二つ以上のコンポーネントだけで構成されるTOE。
3.6.5
従属コンポーネント（dependent component）
自身が評価の対象であり，基本コンポーネントからのサービスの提供を受ける，統合TOE内のエンティ
ティ。
3.6.6
機能インタフェース（functional interface）
セキュリティ機能要件の実施に直接関連しないTOE機能へのアクセスを利用者に提供する外部インタ
フェース。
注記 統合TOEでは，統合TOEの運用を支援するために従属コンポーネントによって要求され，基
本コンポーネントによって提供されるインタフェースである。
4
略語
次の略語は，この規格類の一つ以上の部で用いる。
API
アプリケーションプログラミングインタフェース（Application Programming Interface）
CAP
統合保証パッケージ（Composed Assurance Package）
CM
構成管理（Configuration Management）
DAC
任意アクセス制御（Discretionary Access Control）
EAL
評価保証レベル（Evaluation Assurance Level）
GHz
ギガヘルツ（Gigahertz）
GUI
グラフィカルユーザインタフェース（Graphical User Interface）
IC
集積回路（Integrated Circuit）
22
X 5070-1：2011 (ISO/IEC 15408-1：2009)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
IOCTL 入出力制御（Input Output Control）
IP
インターネットプロトコル（Internet Protocol）
IT
情報技術（Information Technology）
MB
メガバイト（Mega Byte）
OS
オペレーティングシステム（Operating System）
OSP
組織のセキュリティ方針（Organizational Security Policy）
PC
パーソナルコンピュータ（Personal Computer）
PCI
周辺コンポーネント相互接続（Peripheral Component Interconnect）
PKI
公開鍵基盤（Public Key Infrastructure）
PP
プロテクションプロファイル，セキュリティ要求仕様書（Protection Profile）
RAM
ランダムアクセスメモリ（Random Access Memory）
RPC
リモートプロシージャコール（Remote Procedure Call）
SAR
セキュリティ保証要件（Security Assurance Requirement）
SFR
セキュリティ機能要件（Security Functional Requirement）
SFP
セキュリティ機能方針（Security Function Policy）
SPD
セキュリティ課題定義（Security Problem Definition）
ST
セキュリティターゲット，セキュリティ設計仕様書（Security Target）
TCP
伝送制御プロトコル（Transmission Control Protocol）
TOE
評価対象（Target of Evaluation）
TSF
TOEセキュリティ機能の実現主体（TOE Security Functionality）
TSFI
TSFインタフェース（TSF Interface）
VPN
仮想プライベートネットワーク（Virtual Private Network）
5
概要
5.1
一般
箇条5では，この規格類の主な概念について示す。すなわち，“TOE”の概念，この規格類の対象読者及
びこの規格類の他の部分での内容記述のためのアプローチを明らかにする。
5.2
TOE
この規格類は，評価するものに関して柔軟に対応できるため，広く理解されているIT製品の境界に拘束
されていない。したがって，評価の文脈において，この規格類では“TOE”（Target of Evaluation，評価対
象）という用語を使用する。
TOEは，ガイダンス文書を伴うことがある，ソフトウェア，ファームウェア及び／又はハードウェアの
集合として定義される。
TOEは一つのIT製品の場合もあるが，そうである必要はない。TOEは，一つのIT製品，IT製品の一部，
IT製品の集合，製品にならない固有な技術又はこれらの組合せのいずれでもよい。
この規格類に関する限り，TOEとIT製品との間の正確な関係は，一つの側面に限って重要となる。つ
まり，IT製品の一部だけからなるTOEの評価を，IT製品全体の評価と誤解させてはならない。
TOEの例を次に示す。
・ ソフトウェアアプリケーション。
・ オペレーティングシステム。
23
X 5070-1：2011 (ISO/IEC 15408-1：2009)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
・ オペレーティングシステムと組み合わせたソフトウェアアプリケーション。
・ オペレーティングシステム及びワークステーションと組み合わせたソフトウェアアプリケーション。
・ ワークステーションと組み合わせたオペレーティングシステム。
・ スマートカード向け集積回路。
・ スマートカード向け集積回路の暗号化コプロセッサ。
・ 端末，サーバ，ネットワーク機器及びソフトウェアの全てを含むローカルエリアネットワーク。
・ データベースアプリケーション。ただし，これと関連付けられるリモートクライアントソフトウェア
は除く。
5.2.1
TOEの様々な形態
この規格類では，TOEは複数の形態を取ることがある。（ソフトウェアTOEの場合の）例を次に示す。
・ 構成管理システムの一連のファイル。
・ コンパイルされたばかりの単一のコピー原本。
・ 顧客に発送する準備の整った箱詰めされたCD-ROM及びマニュアル。
・ インストール済みの運用可能なソフトウェア。
これらの全てがTOEとみなされる。この規格類の他の部分で“TOE”という用語が使用される場合，文
脈によって意図する形態が決定される。
5.2.2
TOEの様々な構成
一般に，IT製品はいろいろな方法で構成される。すなわち，様々な方法でインストールされ，様々なオ
プションを有効又は無効にすることができる。この規格類の評価中にTOEが特定の要件を満たしているか
どうかを決定する場合，構成の柔軟性が，TOEの全ての可能な構成が要件を満たさなければならないとい
う問題をもたらすことがある。このため，TOEのガイダンス部分では，TOEで可能な構成を強く制限する
ことがある。つまり，TOEのガイダンスは，IT製品の一般ガイダンスとは異なることがある。
この一例としては，オペレーティングシステムのIT製品がある。この製品は，多くの使い方（利用者の
種別，利用者の数，許可又は禁止される外部接続の種別，任意機能の有効化又は無効化など）に応じて構
成できる。このIT製品をTOEとし，妥当な機能要件の集合で評価する場合は，多くの任意機能（全ての
種別の外部接続の許可又はシステム管理者の認証の不要など）によって，TOEが要件を満たさなくなるこ
とがあるため，構成をなおさら厳格に制限した方がよい。このため，一般に（多くの構成を許容する）IT
製品のガイダンスと（唯一の構成又はセキュリティ関連の方法に関して異ならない構成だけを許容する）
TOEのガイダンスとの間には相違がある。TOEのガイダンスが複数の構成を許容する場合には，これらの
構成を一括したものを“TOE”と呼び，各構成はTOEに課される要件を満たさなければならないことに注
意する。
5.3
この規格類の対象読者
TOEのセキュリティ特性の評価に一般的に関心をもつのは，利用者，開発者及び評価者の三つのグルー
プである。この規格で示す基準は，これら三つのグループ全ての要求に対応できるように構成されている。
この三つのグループは，全て，この規格類の主な読者とみなされている。この三つのグループは，この後
に示すようにこの基準からの恩恵を受けることができる。
5.3.1
利用者
この規格類は，評価が利用者の要求を満たすことを保証するように記述しているが，それは，これが評
価プロセスの基本的な目的及び意義だからである。
利用者は，TOEが利用者のセキュリティに関する要求を満たしているかどうかを決定する一助として，
24
X 5070-1：2011 (ISO/IEC 15408-1：2009)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
評価結果を用いることができる。通常，これらのセキュリティに関する要求は，リスク分析及び方針の双
方の結果として，決定されている。利用者はまた，異なるTOEを比較する場合に評価結果を用いることも
できる。
この規格類は，利用者，特に関心をもつ利用者のグループ及びコミュニティに対して，セキュリティ要
件を明確に表現するための，プロテクションプロファイル（PP）と呼ばれる実装に依存しない要件定義の
ひな（雛）形を提供する。
5.3.2
開発者
この規格類は，TOEの評価の準備及び支援並びに各TOEが満たすべきセキュリティ要件の特定におい
て，開発者を支援することを目的としている。これらの要件は，セキュリティターゲット（ST）と呼ばれ
る実装に依存する要件定義書に含まれている。このSTは，一つ以上のPPに基づき，当該PPの規定に従
ってSTが利用者からのセキュリティ要件に適合していることを示してもよい。
この規格類は，これらの要件に対してTOEの評価を裏付けるのに必要な証拠を提供する責任及び行動を
決定するために用いることができる。また，その証拠の内容及び提示も規定している。
5.3.3
評価者
この規格類は，セキュリティ要件に対するTOEの適合について判断を下すときに，評価者が用いる基準
を含んでいる。この規格類は，評価者が実施しなければならない一般的な行動の集合を記述している。こ
の規格類は，それらの行動の実行に当たって従うべき手続を具体的に述べていないことに注意する。これ
らの手順の詳細については，5.5に示されている。
5.3.4
その他の対象読者
この規格類は，TOEのITセキュリティ特性の仕様及び評価を指向していると同時に，ITセキュリティ
に興味又は責任のある全ての関係者のための参考資料としても役に立つものである。この規格類に含まれ
ている情報から恩恵を受けることができる，その他の関心のあるグループの幾つかを次に示す。
a) 組織のITセキュリティ方針及び要件を決定し実現する責任のある，システム管理者及びシステムセキ
ュリティ担当役員。
b) （TOEから構成された又はTOEを含む）ITソリューションのセキュリティの妥当性評定に責任のあ
る，内部及び外部の監査員。
c) IT製品のセキュリティ特性の仕様に責任のあるセキュリティの設計者。
d) 特定の環境内におけるITソリューション使用の受入れに責任のある調達者。
e) 評価の依頼及び支援に責任のある評価のスポンサー。
f)
ITセキュリティ評価プログラムの管理及び監督に責任のある認証機関。
5.4
この規格類の各部
この規格類は，次に示すように，関連する三つの部として提供している。各部の記述に用いられている
用語については，箇条6で説明する。
a) この規格は，この規格類の序説である。ITセキュリティ評価の一般的な概念及び原則を定義し，評価
の一般モデルを提示する。
b) 第2部の“セキュリティ機能コンポーネント”は，TOEの機能要件の基となる標準ひな（雛）形とし
て，機能コンポーネントの集合を規定している。この規格類第2部は，機能コンポーネントの集合を
カタログ化し，ファミリ及びクラスを編成している。
c) 第3部の“セキュリティ保証コンポーネント”は，TOEの保証要件の基となる標準ひな（雛）形とし
て，保証コンポーネントの集合を規定している。この規格類第3部は，保証コンポーネントの集合を
25
X 5070-1：2011 (ISO/IEC 15408-1：2009)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
カタログ化し，ファミリ及びクラスを編成している。また，この規格類第3部はPP及びSTの評価基
準も定義し，更に評価保証レベル（EAL）と呼ばれる七つの定義済み保証パッケージも示している。
この規格類の三つの部を支援するために，その他の文書が発行されている。例えば，ISO/IEC 18045は
この規格類に基づくITセキュリティ評価の方法を示す文書である。技術的根拠に関する資料及びガイダン
ス文書を含め，その他の文書も発行されることが予想される。
表1に，三つの主な対象読者グループがこの規格類の各部をどのように利用すべきかを示す。
表1−“ITセキュリティの評価基準”の役割別用途
利用者
開発者
評価者
第1部
予備知識として使用する。
そして，参考資料として使
用する義務がある。PPの構
造の手引である。
予備知識及び参考資料として使用
する。そして，TOEのセキュリティ
仕様を開発するために使用する義
務がある。
PP及びSTを評価するときの
予備知識及び参考資料として
使用する義務がある。
第2部
TOEの要件に関する記述
を定式化するときの手引
及び参考資料として使用
する。
TOEの機能要件に関する記述を解
釈するとき及びTOEの機能仕様を
定式化するときの参考資料として
使用する義務がある。
機能要件に関する記述を解釈
するときの参考資料として使
用する義務がある。
第3部
必要な保証レベルを決定
するときの手引として使
用する。
TOEの保証要件に関する記述を解
釈するとき及びTOEの保証アプロ
ーチを決定するときの参考資料と
して使用する。
保証要件に関する記述を解釈
するときの参考資料として使
用する。
5.5
評価の枠組み
評価結果間の比較可能性を高めるために，標準を定め，評価の品質を監視し，評価設備及び評価者が遵
守しなければならない規則を管理する信頼すべき評価制度の枠組みの中で評価を実施することが望ましい。
この規格類は，規制上の枠組みに関する要件を記述していない。しかしながら，こうした評価結果に対
する相互承認の目標を達成するには，様々な認証機関の規制上の枠組み間の一貫性が必要になろう。
評価結果間で比較可能性を高める第二の方法は，評価結果を生成するために共通の方法を使用すること
である。この規格類については，この方法がISO/IEC 18045で説明されている。
共通評価方法を用いることは，結果の再現性及び客観性に寄与するが，それだけでは十分とはいえない。
一貫性を達成するのがより困難であるために，評価基準の多くには，専門家の判断及び予備知識の適用が
必要である。評価結果の一貫性を高めるために，最終評価結果を認証プロセスにかけてもよい。
認証プロセスは，通常公開される最終的な認証書の発行に至る独立した評価結果の検査である。認証プ
ロセスは，ITセキュリティ基準の適用における一貫性を高める手段である。
評価制度及び認証プロセスは，この制度及びプロセスを実行する認証機関の責任であり，この規格類の
適用範囲外である。
6
一般モデル
6.1
序説及び一般モデル
箇条6では，この規格類全体にわたって用いられる一般的概念を示す。これには，この規格類の概念が
用いられる背景及びこの概念を適用するアプローチを含む。
この規格の利用者が参考とすべき，この規格類の第2部及び第3部では，これらの概念の使用について
26
X 5070-1：2011 (ISO/IEC 15408-1：2009)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
詳述しており，ここに示すアプローチを用いることを前提としている。さらに，評価のためにこの規格を
使用する者にとっては，ISO/IEC 18045が適用可能である。箇条6は，ITセキュリティについて相応の知
識があることを前提としており，この分野に関する手引の役割を果たすことを意図していない。
この規格類は，セキュリティの概念及び用語を用いてセキュリティについて論じる。これらの概念及び
用語を理解することが，この規格類を効果的に用いるための必要条件である。ただし，概念自体は極めて
一般的なものであり，この規格類が適用されるITセキュリティの課題の種類を限定することを意図してい
ない。
6.2
資産及び対抗策
セキュリティは，資産の保護に関係する。資産とは，何者かが価値があると認めるものである。資産の
例を次に示す。
・ ファイル又はサーバの内容。
・ 投票で投じられた票の真正性。
・ 電子商取引の処理の可用性。
・ 高価なプリンタの使用権。
・ 制限区画への立入り。
ただし，価値とは非常に主観的であるため，ほとんど全てのものが資産になり得る。このような資産が
ある環境は，運用環境と呼ばれる。運用環境の（側面の）例を次に示す。
・ 銀行のコンピュータルーム
・ インターネットに接続するコンピュータネットワーク
・ LAN
・ 一般的なオフィス環境
資産の多くは，情報の所有者が規定した要件を満たすIT製品によって保存されたり，処理されたり，伝
送されたりする情報の形をとる。情報の所有者は，このような情報の可用性，流出及び改変を厳格に管理
し，対抗策によって資産を脅威から保護する。図2に，上位レベルの概念及び関係を示す。
27
X 5070-1：2011 (ISO/IEC 15408-1：2009)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
注記 対応国際規格の図2は，矢印のとおりに単語を続けて読むと，次の例のように意味のある英語の文となる。こ
れを，日本語に訳すと，図の意図を必ずしも反映することはできないので，矢印部分は対応国際規格のとおり
とした。
例 左上の“所有者”から右下の“資産”に対して，矢印のとおりに単語を並べる。
Owners impose countermeasures to reduce risk to assets.
所有者は，資産に対するリスクを減少させる対抗策を講じる。
図2−セキュリティの概念及び関係
対象となる資産を保護することは，それらの資産の価値を認めている所有者の責任である。実在する又
は想定の脅威エージェントもまたその資産の価値を認め，所有者の利益に反する形で資産を悪用しようと
する可能性がある。脅威エージェントの例には，ハッカー，悪意のある利用者，悪意はないが誤りを犯す
ことがある利用者，コンピュータ処理及び事故がある。
資産の所有者は，そうした脅威を，所有者にとっての資産の価値が減少することになるような資産の侵
害の可能性ととらえる。一般に，セキュリティ固有の侵害には，資産の機密性の損失，資産の完全性の損
失，資産の可用性の損失などがあるが，これらだけではない。そのため，このような脅威が実現する可能
性と，その場合の資産への影響とに基づいて，脅威から資産に対するリスクが生じる。したがって，資産
へのリスクを減らすために，対抗策が講じられる。対抗策は，IT対抗策（ファイアウォール，スマートカ
ードなど）及びIT以外の対抗策（警備員，手続など）から構成されることがある。セキュリティ対抗策（管
理），その実装方法及び管理方法に関する，より一般的な議論については，JIS Q 27001及びJIS Q 27002
も参照する。
資産の所有者は，それらの資産に対する責任を負う（負わされる）ことがあるため，資産を脅威にさら
すリスクを受け入れる判断の正しさを立証できることが望ましい。この判断の正しさを立証するために重
要な点は，次のことを示すことである（図3参照）。
所有者
(Owners)
value
wish to minimize
対抗策
(Countermeasures)
impose
to reduce
リスク
(Risk)
脅威エージェント
(Threat agents)
that increase
to
give rise to
脅威
(Threats)
資産
(Assets)
to
wish to abuse and/or may damage
28
X 5070-1：2011 (ISO/IEC 15408-1：2009)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
・ 対抗策が集合として十分であること。つまり，それぞれの対抗策が主張する動作を実行すれば，資産
の脅威が対抗されること。
・ それぞれの対抗策が正確であること。つまり，対抗策が主張する動作を確実に実行すること。
資産の所有者の多くは，対抗策の十分性及び正確性を判断するのに必要な知識，技能又は資源を欠いて
いるが，対抗策の開発者の主張だけに頼ることを望まないこともある。したがって，資産の所有者は，こ
れらの対抗策の評価を依頼することによって，対抗策の一部又は全部の十分性及び正確性に対する信頼度
を向上させる選択を行ってもよい。
注記 図2の注記に同じ。
例 Owners require confidence that countermeasures are correct and therefore minimize risk to assets.
所有者は，対抗策が正確であり，したがって資産に対するリスクを最小限にするという信頼性を要求す
る。
図3−評価の概念及び関係
6.2.1
対抗策の十分性
評価において，対抗策が十分であるかどうかは，セキュリティターゲットと呼ばれる要件定義書を通じ
て分析する。箇条6では，この要件定義書の概要を示す。より詳細で完全な記述を，附属書Aに示す。
セキュリティターゲットでは，初めに資産及び資産への脅威について記述する。次に，セキュリティタ
ーゲットは，（セキュリティ対策方針の形式で）対抗策を記述し，その対抗策の集合が脅威に対抗するため
に十分であること，つまりそれぞれの対抗策が主張する動作を実行すれば，脅威が対抗されることを示す。
次に，セキュリティターゲットは，対抗策を次の二つに分ける。
a) TOEのセキュリティ対策方針： 評価の過程で，正確性を判断する対抗策を記述する。
評価
(Evaluation)
所有者
(Owners)
信頼性
(Confidence)
対抗策
(Countermeasures)
正確である
(Correct)
provides
require
that
are
and therefore
minimize
十分である
(Sufficient)
リスク
(Risk)
資産
(Assets)
to
and therefore
minimize
are
29
X 5070-1：2011 (ISO/IEC 15408-1：2009)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
b) 運用環境のセキュリティ対策方針： 評価の過程で，正確性を判断しない対抗策を記述する。
このように分ける理由は，次のとおりである。
・ この規格類は，IT対抗策の正確性の評定に適している。そのため，IT以外の対抗策（警備員，手続な
ど）は，常に運用環境のセキュリティ対策方針とする。
・ 対抗策の正確性の評定には時間及び資金がかかるため，全てのIT対抗策の正確性の評定は不可能なこ
とがある。
・ 一部のIT対抗策の正確性は，別の評価で既に評定されていることがある。そのため，この正確性を再
評定することは，費用効率が悪い。
セキュリティターゲットには，TOEのセキュリティ対策方針（評価の過程で正確性が評定されるTOE
のIT対抗策）を，セキュリティ機能要件（SFR）でより詳細に記述する必要がある。SFRは，正確性を確
保し，比較を容易にするために，（この規格類第2部で記述する）規格化された表現で規定する。
要するに，セキュリティターゲットでは次のことを示す。
・ SFRがTOEのセキュリティ対策方針を満たしている。
・ TOEのセキュリティ対策方針及び運用環境のセキュリティ対策方針が，脅威に対抗する。
・ したがって，SFR及び運用環境のセキュリティ対策方針が脅威に対抗する。
つまり，（SFRを満たす）正しいTOEと（運用環境のセキュリティ対策方針を満たす）正しい運用環境
との組合せによって，脅威に対抗する。次の6.2.2及び6.2.3では，TOEの正確性及び運用環境の正確性に
ついて規定する。
6.2.2
TOEの正確性
TOEは正確に設計及び実装されるとは限らず，ぜい弱性の原因となる誤りが含まれることがある。この
ようなぜい弱性に付け込まれ，攻撃者によって資産に損害が与えられたり，悪用されたりする可能性があ
る。このようなぜい弱性は，開発中の不慮の誤り（不十分な設計，悪意あるコードの意図的な追加，不十
分な試験など）から生じることがある。TOEの正確性を判定するために，次のような様々なアクティビテ
ィを実施できる。
・ TOEの試験。
・ TOEの様々な設計資料の検査。
・ TOEの開発環境の物理的セキュリティの検査。
セキュリティターゲットでは，セキュリティ保証要件（SAR）の形式で，正確性を判定するために，こ
れらのアクティビティについて記述する。SARは，正確性を確保し，比較を容易にするために，（この規
格類第3部で記述する）規格化された表現で規定する。SARが満たされている場合は，TOEの正確性が保
証されるため，攻撃者に悪用されるぜい弱性がTOEに含まれる可能性が低くなる。TOEの正確性に関す
る保証の程度は，SARによって決定される。つまり，少数の“弱い”SARでは僅かな保証を，多数の“強
力な”SARでは多くの保証をもたらす。
6.2.3
運用環境の正確性
運用環境も正確に設計及び実装されるとは限らず，ぜい弱性の原因となる誤りが含まれることがある。
このようなぜい弱性に付け込まれ，攻撃者によって資産に損害が与えられたり，悪用されたりする可能性
がある。ただし，この規格類では，運用環境の正確性に関して保証は得られない。言い換えると，運用環
境は評価されない（6.3参照）。
評価に関する限り，運用環境は，運用環境のセキュリティ対策方針が100 %正確に具体化されたものと
みなされる。
30
X 5070-1：2011 (ISO/IEC 15408-1：2009)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
このことは，この規格類の評価対象外であるが，TOEの利用者は，次のような方法を使用して運用環境
の正確性を実現することを防げない。
・ TOEがOSであり，運用環境のセキュリティ対策方針に“運用環境では，（インターネットなどの）信
頼できないネットワークからのエンティティはftpだけによってTOEにアクセスできるようにしなけ
ればならない。”と記述されている場合，利用者は評価済みのファイアウォールを選択し，TOEへの
ftpアクセスだけを許可するようにそのファイアウォールを設定することができる。
・ 運用環境のセキュリティ対策方針に“運用環境では，全ての管理要員が悪意をもって行動しないよう
にしなければならない。”と記述されている場合，利用者は，悪意ある行動に対する懲罰を含むように
管理要員との契約を見直すことができる。
6.3
評価
この規格類は，次に記述するST評価を含むTOE評価と，この規格類第3部に定義されるPP評価との2
種類の評価を対象とする。多くの場合，この規格類では，単なる“評価”という用語は，ST評価を含む
TOE評価を指す。この規格類は，ST評価を含むTOE評価を次の二つの手順で進める。
a) TOE及び運用環境の十分性を判定するST評価。
b) TOEの正確性を判定するTOE評価。上記のTOE評価では，運用環境の正確性は判定しない。
ST評価を実施する場合には，（この規格類第3部のASEの箇条で定義される）セキュリティターゲット
評価基準（ASE基準）をセキュリティターゲットに適用する。ASE基準を適用するための詳細な方法は，
使用される評価方法によって決まる。
TOE評価は，より複雑である。TOE評価の入力となる基本的な証拠資料はTOE及びSTであるが，通常，
設計文書，開発者による試験結果などの開発環境からの証拠資料もまた入力となる。TOE評価は，証拠資
料に対して（セキュリティターゲットで記述した）各SARを適用することからなる。各SARを適用する
ための詳細な方法は，使用される評価方法によって決まる。SARを適用した結果の文書化方法，作成が必
要な報告書及びその詳細度は，使用される評価方法と，実施する評価に適用される評価制度との両方によ
って決まる。TOE評価プロセスの結果は，次のいずれかとなる。
・ 満たされていないSARがあるため，STに記述されたSFRをTOEが満たすという保証のレベルに達
していないとする判定結果。
・ 全てのSARが満たされているため，STに記述されたSFRをTOEが満たすという保証のレベルに達
しているとする判定結果。
TOE評価は，TOE開発が完了した後に，又はTOE開発と並行に実施してもよい。
ST評価の結果及びTOE評価の結果を記述する方法については，箇条9に規定する。この評価の結果で
は，TOEが適合を主張するPP及びパッケージも特定する。PP及びパッケージの構成については，箇条8
に規定する。
7
セキュリティ要件の調整（tailoring）
7.1
操作（Operations）
機能及び保証コンポーネントは，この規格類の第2部及び第3部で定義されたとおりに使用してよいが，
使用する前に許可された操作を行って修正してもよい。操作を行う場合，PP又はSTの作成者は，この要
件に依存する他の要件への依存性の必要性が満たされていることにも注意する。許可された操作は，次の
ものに限られる。
・ 繰返し：異なる操作を行って2回以上同一コンポーネントを使用する。
31
X 5070-1：2011 (ISO/IEC 15408-1：2009)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
・ 割付け：パラメタを指定する。
・ 選択：リストから，一つ以上の項目を指定する。
・ 詳細化：詳細を追加する。
割付け及び選択操作は，コンポーネントで明示された場所だけに許可される。繰返し及び詳細化は，全
てのコンポーネントに許可される。各操作について次に詳述する。
この規格類第2部の附属書に有効な選択及び割付けに関する手引を記述する。この手引は，規定となる
操作の仕方を規定する。定められた規定から外れる場合，PP又はSTの作成者は，その正当性を示さなけ
ればならない。
a) 明示的な選択肢として与えている場合を除き，“なし”以外を書いてはならない。選択肢のリストは，
空欄であってはならない。“なし”を選択した場合，他の選択肢を追記してはならない。“なし”が選
択肢の中になく，“から一つだけ選択”の指定もない場合，選択肢の複数項目を“及び”，“又は”によ
って組み合わせてもよい。選択操作は，必要に応じて繰返し操作と組み合わせてよい。この場合，個
別の繰返しで選んだ選択肢を別の繰返しの選択肢と一致させてはならない。選択肢はそもそも排他的
使用を意図しているからである。
b) 割付け操作については，“なし”と記述できるかについては，この規格類第2部の附属書を参照して判
断する。
7.1.1
繰返し操作（The iteration operation）
全てのコンポーネントに対して繰返し操作を行える。PP又はSTの作成者は，同じコンポーネントを使
って，複数の要件を含めることで，繰返し操作を行う。コンポーネントのそれぞれの繰返しは，同一コン
ポーネントの他のどの繰返しとも異なっていなければならない。これは，異なる方法で割付け及び選択を
完了するか，異なる方法で詳細化を適用することで実現できる。異なる繰返しは，明確な根拠と，これら
の要件との間の追跡のために，一意に識別するのが望ましい。
繰返し操作は，繰返しと同時にある範囲の値のリストを割付け操作できる要件コンポーネントとともに
用いられることもあることに留意することが大切である。その場合，PP又はSTの作成者は，それらの範
囲の値に対して一括した根拠を示すことが必要なのか，又はそれらの値のそれぞれに個別の根拠を示すこ
とが必要なのかを熟慮して，最もふさわしい選択をすることができる。PP又はSTの作成者は，それらの
値に対する個々の根拠が必要かどうかについて念頭に置いておくことが望ましい。
7.1.2
割付け操作（The assignment operation）
割付け操作は，特定のコンポーネントにPP又はSTの作成者によって設定されるパラメタ付きのエレメ
ントが含まれる場合に行う。パラメタは，制限のない変数又は変数を特定の範囲の値に狭める規則にする
ことがある。
PPのエレメントに割付けが含まれる場合には常に，PP作成者は次の四つのいずれかを行わなければな
らない。
a) 割付けを未完了のままにする。PP作成者は，FIA̲AFL.1.2［不成功の認証試行が定義した回数に達す
るか上回ったとき，TSFは，（割付け：アクションのリスト）を実行しなければならない。］をPPに
加えることができる。
b) 割付けを完了する。例えば，PP作成者は，FIA̲AFL.1.2（不成功の認証試行が定義した回数に達する
か上回ったとき，TSFは，今後サブジェクトに結合することを外部エンティティに禁じることを実行
しなければならない。）をPPに加えることができる。
32
X 5070-1：2011 (ISO/IEC 15408-1：2009)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
c) 許可する値の範囲を更に制限するために割付けの範囲を狭める。例えば，PP作成者は，FIA̲AFL.1.1
［TSFは，（割付け：4から9までの正の整数）回の不成功の認証試行が生じた時を検出しなければな
らない。］をPPに加えることができる。
d) 割付けを選択に変えることによって，割付けの範囲を狭める。例えば，PP作成者は，FIA̲AFL.1.2［不
成功の認証試行が定義した回数に達するか上回ったとき，TSFは，（選択：サブジェクトに結合するこ
とを利用者に禁止，管理者に通知）しなければならない。］をPPに加えることができる。
ST作成者は使用する機能要件のエレメントに割付けが含まれる場合には常に，上記のb)に示すように
割付けを完了しなければならない。任意項目a)，c)及びd)はSTでは認められない。任意項目b)，c)及び
d)で選定する値は，割付けで要求される指定された型に適合しなければならない。割付けが（サブジェク
トなどの）集合として完結される場合は，集合の要素を列挙してもよいし，集合の要素を導出できる次の
規則を記述してもよい。
・ 全てのサブジェクト。
・ 種別Xの全てのサブジェクト。
・ サブジェクトa)を除く全てのサブジェクト。
ただし，どのサブジェクトを指しているかが明確であることを条件とする。
7.1.3
選択操作
選択操作は，特定のコンポーネントにPP又はSTの作成者が複数の項目から選択しなければならないエ
レメントが含まれる場合に行う。PPのエレメントに選択が含まれる場合には常に，PP作成者は次の三つ
のいずれかを行うことができる。
a) 選択を未完了のままにする。
b) 一つ以上の項目を選んで，選択を完了する。
c) 幾つかの選択肢を削除し，二つ以上を残すことによって，選択を制限する。
ST作成者は使用する機能要件のエレメントに選択が含まれる場合には常に，上記のb)に示すように選
択を完了しなければならない。任意項目a)及びc)はSTでは認められない。b)及びc)で選定する一つ以上
の項目は，選択で提供される項目から取得しなければならない。
7.1.4
詳細化操作
詳細化操作は，全ての要件で行うことができる。PP又はSTの作成者は，要件を変更することによって
詳細化を行う。詳細化の最初の規則は，そのPP又はSTの文脈において，詳細化された要件を満たすTOE
が詳細化されていない要件も満たすということである（つまり，詳細化された要件は，元の要件に比べ“よ
り厳格”でなければならない。）。詳細化がこの規則を満たさない場合，その詳細化によって生じる要件は
拡張要件とみなされ，拡張要件として扱わなければならない。
この規則に対する唯一の例外として，PP又はSTの作成者は，全部ではなく一部の，サブジェクト，オ
ブジェクト，操作，セキュリティ属性及び／又は外部エンティティに適用するためにSFRを詳細化するこ
とができる。ただし，この例外は，適合を主張するPPから取得されたSFRの詳細化には適用されない。
このようなSFRは，PP内のSFRよりも少ない，サブジェクト，オブジェクト，操作，セキュリティ属性
及び／又は外部エンティティに適用するように詳細化することはできない。
詳細化の2番目の規則は，詳細化は元のコンポーネントに関連付けなければならないことである。
詳細化の特殊なケースには編集上の詳細化がある。この場合，文法に合わせるために，又は読者にとっ
てより理解しやすくするために，文を書き換えるなど，要件に小さな変更が行われる。この変更によって
要件の意味を変更することはできない。
33
X 5070-1：2011 (ISO/IEC 15408-1：2009)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
7.2
コンポーネント間の依存性
コンポーネント間には，依存性が存在する場合がある。あるコンポーネントがそれ自身では不十分であ
り，別のコンポーネントを伴って初めて，セキュリティ機能性又は保証を提供することができるとき，依
存性をもつという。
この規格類第2部の機能コンポーネントは，通常，他の機能コンポーネントに依存し，この規格類第3
部の保証コンポーネントは，通常，他の保証コンポーネントに依存する。この規格類第2部の機能コンポ
ーネントは，同第3部の保証コンポーネントに依存するよう定義し得る。また，拡張機能コンポーネント
が保証コンポーネントに依存し，又はその反対の依存性が生じることがある。
コンポーネントの依存性の記述は，この規格類の第2部及び第3部のコンポーネント定義を参照して決
定する。TOEセキュリティ要件の完全性を保証するには，依存性のあるコンポーネントに基づく要件をPP
及びSTに組み込むときに依存性を満たさなければならない。依存性はパッケージを構成するときにも考
慮に入れなければならない。言い換えれば，コンポーネントAがコンポーネントBに依存する場合，PP
又はSTにコンポーネントAに基づくセキュリティ要件が含まれるときには常に，PP又はSTは次のいず
れかを含まなければならない。
a) コンポーネントBに基づくセキュリティ要件。
b) コンポーネントBに対して上位階層関係にあるコンポーネントに基づくセキュリティ要件。
c) PP又はSTにコンポーネントBに基づくセキュリティ要件が含まれない正当な理由。
a)及びb)において，依存性のためにセキュリティ要件が含まれる場合，実際に依存性を満たすような特
定の方法で，セキュリティ要件に対する操作（割付け，繰返し，詳細化及び選択）を完了することが必要
になるときがある。
c)において，セキュリティ要件を含まないことの正当化では，次のいずれかを示すのが望ましい。
・ 依存性が必要又は有用ではない理由。
・ 依存性が，TOEの運用環境によって対処される場合。この場合，運用環境のセキュリティ対策方針が
この依存性にどのように対処するかを正当化によって記述しなければならない。
・ 依存性が，その他のSFRによって，その他の方法（拡張SFR，SFRの組合せなど）で対処されること。
7.3
拡張コンポーネント
この規格類では，次の二つの例外を除いて，要件は，この規格類の第2部又は第3部のコンポーネント
に基づかなければならない。
a) 第2部のSFRに書き換えることができないTOEのセキュリティ対策方針が存在する，又は第3部の
SARに書き換えることができない第三者要件（暗号の評価に関する法律，標準など）が存在する。
b) 第2部及び／又は第3部のコンポーネントに基づいてセキュリティ対策方針を書き換えることができ
るが，著しい困難及び／又は複雑さを伴う。
いずれの場合にも，PP又はSTの作成者は，独自のコンポーネントを定義する必要がある。これらの新
しく定義されるコンポーネントは，拡張コンポーネントと呼ばれる。拡張コンポーネントは，拡張SFR及
びSARにその背景及び目的を提供するために正確に定義する必要がある。
新しいコンポーネントを正確に定義した後に，PP又はSTの作成者はこれらの新しく定義した拡張コン
ポーネントに基づいて一つ以上のSFR又はSARを作成し，他のSFR及びSARと同じ方法で使用すること
ができる。以降，この規格類に基づくSAR及びSFRと，拡張コンポーネントに基づくSAR及びSFRとを
区別しない。拡張コンポーネントの詳細要件は，この規格類第3部の拡張コンポーネント定義 (APE̲ECD)
及び拡張コンポーネント定義 (ASE̲ECD)として記述されている。
34
X 5070-1：2011 (ISO/IEC 15408-1：2009)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
8
プロテクションプロファイル及びパッケージ
8.1
序説
関心をもつ利用者のグループ及びコミュニティがそれぞれのセキュリティの必要性を表現できるように
し，STの作成を容易にするために，この規格ではパッケージ及びプロテクションプロファイル（PP）と
いう二つの特別な概念を規定している。8.2及び8.3ではこれらの概念についてより詳細に説明する。8.4
ではこれらの概念の使用方法を説明する。
8.2
パッケージ
パッケージとは，セキュリティ要件の集合に名前を付けたものである。パッケージは，次のいずれかで
ある。
・ SFRだけを含む機能パッケージ。
・ SARだけを含む保証パッケージ。
SFRとSARとの両方を含む混合パッケージは認められない。
パッケージは，任意の組織（party）が定義することができ，再利用を意図している。この目的のために
は，パッケージには組み合わせることで有用であり，かつ，効果的である要件を含む方がよい。パッケー
ジは，より大きなパッケージ，PP及びSTの中で使用できる。現在，パッケージの評価に対する基準がな
いため，SFR又はSARの任意の集合をパッケージにすることができる。
保証パッケージの例には，この規格類第3部で定義される評価保証レベル（EAL）がある。この規格の
作成時点では，この規格類に対応する機能パッケージは存在しない。
8.3
プロテクションプロファイル
STが常に特定のTOE（例えば，MinuteGap v18.5 Firewall）について記述するのに対して，PPはTOE種
別（例えば，ファイアウォール）について記述することを意図している。したがって，異なる評価で使用
される様々なSTのひな形として，同一のPPを使用することができる。PPの詳細については，附属書B
に示す。
一般に，STはあるTOEの要件を記述するものであり，そのTOEの開発者によって作成される。これに
対して，PPはあるTOE種別の一般要件を記述するものであり，このため，通常は次の者によって作成さ
れる。
・ 所定のTOE種別の要件について合意の形成を求めている利用者のコミュニティ。
・ あるTOEの開発者，又はその種のTOEに対する最低限の基準レベルの確立を求めている同種のTOE
の開発者団体。
・ 調達プロセスの一部として要件を指定する政府又は大企業。
PPは，STにおいて許可される適合の種別を決定する。すなわち，PPは，［そのPPの適合主張（B.5参
照）の中で］STに許可されている適合の種別が何であるかを宣言する。
・ 正確適合が必要であるとPPが宣言している場合，STはPPに対して正確に適合しなければならない。
・ 例証適合が必要であるとPPが宣言している場合，STはPPに対して正確に又は例証可能な方法で適
合しなければならない。
このことを言い換えると，PPが例証適合を明示的に許可している場合だけ，STはPPに対して例証可能
な方法で適合することができる。
STが複数のPPへの適合を主張する場合，STは各PPに対して，（上記のように）それぞれのPPが指示
する方法で適合しなければならない。このことは，STが正確適合するPPがあれば例証適合するPPもあ
ることを意味する。
35
X 5070-1：2011 (ISO/IEC 15408-1：2009)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
ただし，STは当該PPに適合するかしないか，のいずれかであることに注意する。この規格類では“部
分的な”適合を認めていない。したがって，PPが過度な要求をしてPP又はSTの作成者がPP適合を主張
することを妨げることがないようにするのは，PP作成者の責任である。
STは，あるPPと同等又はそれ以上に制限的であるためには，次の全てを満たさなければならない。
・ STを満たす全てのTOEがPPも満たす。
・ PPを満たす全ての運用環境がSTも満たす。
つまり，言い換えれば，STは，TOEに対しては同等以上の制約を課し，TOEの運用環境に対しては同
等以下の制約を課さなければならない。
この全般的な記述は，STの各項目において，より詳細化する。
セキュリティ課題定義： STの適合根拠では，ST内のセキュリティ課題定義がPP内のセキュリティ課題
定義と同等（又はそれ以上に制限的）であることを例証しなければならない。すなわち，次の二つを例証
しなければならない。
・ ST内のセキュリティ課題定義を満たす全てのTOEがPP内のセキュリティ課題定義も満たす。
・ PP内のセキュリティ課題定義を満たす全ての運用環境がST内のセキュリティ課題定義も満たす。
セキュリティ対策方針： STの適合根拠では，ST内のセキュリティ対策方針がPP内のセキュリティ対策
方針と同等（又はそれ以上に制限的）であることを例証しなければならない。すなわち，次の二つを例証
しなければならない。
・ ST内のTOEのセキュリティ対策方針を満たす全てのTOEがPP内のTOEのセキュリティ対策方針も
満たす。
・ PP内の運用環境のセキュリティ対策方針を満たす全ての運用環境がST内の運用環境のセキュリティ
対策方針も満たす。
プロテクションプロファイルに対する正確適合が指定されている場合，次の要件を適用する。
a) セキュリティ課題定義 STはPP内のセキュリティ課題定義を含まなければならない。追加の脅威及
びOSPを指定してもよいが，追加の前提条件を指定してはならない。
b) セキュリティ対策方針
・ STは，PP内の全てのTOEのセキュリティ対策方針を含まなければならないが，追加のTOEの
セキュリティ対策方針を指定してもよい。
・ STは，（次の項目の場合を除いて）PP内の全ての運用環境のセキュリティ対策方針を含まなけれ
ばならないが，追加の運用環境のセキュリティ対策方針を指定してはならない。
・ STは，PP内のある運用環境の対策方針をTOEのセキュリティ対策方針となるように指定しても
よい。これをセキュリティ対策方針の再配置と呼ぶ。
セキュリティ対策方針がTOEに対して再配置されている場合，セキュリティ対策方針根拠では，
どの前提条件又はその前提条件のどの部分が不必要になっているのかを明確にしなければならない。
c) セキュリティ要件 STはPP内の全てのSFR及び全てのSARを含まなければならないが，追加のSFR
及びSAR，又はより上位階層のSFR及びSARを主張してもよい。STでの操作の完了はPPでの操作
の完了と一貫していなければならない。この場合，PPと同じ操作がSTの中で完了しているか，PPの
要件をより制限的にする（詳細化の規則を適用した）操作が完了することになる。
プロテクションプロファイルに対する例証適合が指定されている場合，次の要件を適用する。
・ STには，そのSTがPPと“同等又はそれ以上に制限的である”ように考慮されているとする根拠
を含まなければならない。
36
X 5070-1：2011 (ISO/IEC 15408-1：2009)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
・ 例証適合では，PP作成者は解決すべき一般的なセキュリティ課題を記述して，その解決に必要な要
件に対する一般的な指針を，複数の解決方法に具体化できるような説明を添えて提供することが許
される。
PP評価は任意選択である。評価はこの規格類第3部のリストに従ってAPEを適用することによって実
施される。この評価の目標は，PPが完全で，一貫性があり，技術的に信頼でき，別のPP又はSTを作成
するためのひな形として使用するのに適していることを例証することである。
評価済みのPPに基づいてPP又はSTを作成することは，次の二つの利点がある。
・ PPに誤り，曖昧さ又は不備が存在するリスクが大きく低下する。新しいSTの作成中又は評価中に，
［PPの評価によって捕捉されていたはずの］PPの問題が発見された場合には，そのPPが訂正される
までに多くの時間がかかることがある。
・ 新しいPP又はSTの評価では，多くの場面で評価済みPPの評価結果を再利用でき，新しいPP又は
STの評価作業をより少ない労力で終わらせることができる。
任意選択：
追加の脅威
及びOSP
任意選択：
追加又は
より厳しい
SAR及びSFR
セキュリティ
ターゲット
セキュリティ要件
SFR
SAR
セキュリティ課題定義
脅威，OSP，
対策方針
セキュリティ
対策方針
前提条件
プロテクションプロファイル
セキュリティ要件
SFR
SAR
セキュリティ課題定義
脅威，OSP，
対策方針
セキュリティ
対策方針
前提条件
TOEの
運用環境
TOE
満たす
同等又はそれ以上に
制限的である
すべて
TOEが満たす
正確適合
だけ
正確適合
だけ
任意選択：
追加の脅威
及びOSP
任意選択：
追加又は
より厳しい
SAR及びSFR
セキュリティ
ターゲット
セキュリティ要件
SFR
SAR
セキュリティ課題定義
脅威，OSP，
対策方針
セキュリティ
対策方針
前提条件
セキュリティ
ターゲット
セキュリティ要件
SFR
SAR
セキュリティ課題定義
脅威，OSP，
対策方針
セキュリティ
対策方針
前提条件
セキュリティ課題定義
脅威，OSP，
対策方針
セキュリティ
対策方針
前提条件
プロテクションプロファイル
セキュリティ要件
SFR
SAR
セキュリティ課題定義
脅威，OSP，
対策方針
セキュリティ
対策方針
前提条件
プロテクションプロファイル
セキュリティ要件
SFR
SAR
セキュリティ課題定義
脅威，OSP，
対策方針
セキュリティ
対策方針
前提条件
セキュリティ課題定義
脅威，OSP，
対策方針
セキュリティ
対策方針
前提条件
TOEの
運用環境
TOE
TOEの
運用環境
TOE
TOE
満たす
同等又はそれ以上に
制限的である
すべて
TOEが満たす
正確適合
だけ
正確適合
だけ
図4−PP，ST及びTOEのそれぞれの内容の関係
セキュリティ
対策方針
前提条件
セキュリティ課題定義
脅威及びOSP
対策方針
任意選択：
追加又は
より厳しい
SAR及びSFR
セキュリティ要件
SFR
SAR
セキュリティ
対策方針
前提条件
セキュリティ課題定義
脅威及びOSP
対策方針
セキュリティ要件
SFR
SAR
任意選択：
追加の脅威
及びOSP
正確適合
だけ
TOEが満たす
満たす
TOE
TOEの
運用環境
正確適合
だけ
37
X 5070-1：2011 (ISO/IEC 15408-1：2009)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
8.4
PP及びパッケージの使用
STが一つ以上のパッケージ及び／又はプロテクションプロファイルへの適合を主張する場合，そのST
の評価では，そのSTが適合を主張しているパッケージ及び／又はPPに（そのSTのその他の部分を含め
て）実際に適合していることが例証される。適合の判断の詳細については，附属書Aに示す。
これは，次のプロセスも許している。
a) 特定の種別のITセキュリティ製品を調達しようとしている組織は，そのセキュリティの必要性をPP
に記述し，その評価を受け，公開する。
b) 開発者はPPを入手し，このPPへの適合を主張するSTを作成し，このSTの評価を受ける。
c) 次に，開発者はTOEを開発し（又は開発済みのTOEを使用し），STに基づいてこのTOEの評価を受
ける。
これによって，開発者は，自らのTOEがその組織のセキュリティの必要性に適合していることを証明で
きる。その結果，この組織はそのTOEを調達することができる。パッケージにも同様の考え方を適用でき
る。
8.5
複数のプロテクションプロファイルの使用
この規格類では，PPを他のPPに適合させることもできる。これによって，各PPがそれ以前からある
PPに基づくような連鎖したPPを構成することができる。
例えば，集積回路用のPPとスマートカードOS用のPPとを入手し，これらを使用して，両方のPPへ
の適合を主張するスマートカードPP（IC及びOS）を構成することができる。
次に，スマートカードPPとアプレットの読込みに関するPPとに基づいて，公共交通機関用スマートカ
ードに関するPPを作成できる。最後に，開発者はこの公共交通機関用スマートカードPPに基づいてST
を作成できる。
9
評価結果
9.1
序説
箇条9では，ISO/IEC 18045に従って実施されるPP及びSTを含むTOEの評価から期待される結果を次
に示す。
・ 複数のPP評価は，評価済みPPのカタログをもたらす。
・ ST評価は，TOEの評価の枠組み内で用いられる中間結果をもたらす。
・ 複数のST評価を含むTOE評価は，評価済みTOEのカタログをもたらす。多くの場合，これらのカタ
ログには特定のTOEではなく，そのTOEの基となるIT製品名が記載される。したがって，カタログ
にIT製品名が記載されていても，IT製品全体が評価を受けていると解釈しないほうがよい。ST評価
を含むTOE評価の実際の範囲は，STによって定義される。このようなカタログ例については参考文
献を参照する。
38
X 5070-1：2011 (ISO/IEC 15408-1：2009)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
図5−評価結果
STは，パッケージ，評価済みPP，又は評価を受けていないPPに基づいてよい。ただし，STは何かに
基づいて作成する必要はないため，これは必須ではない。
評価は，セキュリティ評価の結果を表現する絶対的な客観的尺度がない場合でも，証拠として引用する
ことができる客観的で再現性のある結果を出す方がよい。評価基準のセットが存在することは，評価が意
味のある結果をもたらし，認証機関間での評価結果に対する相互承認の技術的基礎を提供するのに必要な
前提条件である。
評価結果は，TOEのセキュリティ特性についての特定の種類の調査所見を示す。このような評価結果は，
あらゆる適用環境での使用に適していることを自動的に保証するものではない。ある特定の適用環境での
TOEの使用を承認するかどうかは，評価の所見を含む多くのセキュリティの観点での検討に基づいて判断
する。
9.2
PP評価の結果
この規格類第3部は，PPに不備がなく，一貫性があり，技術的に信頼でき，その結果，STの作成にお
いて使用するのに適しているかどうか，を宣言するために参考にすることを，評価者に義務付ける評価基
準を含んでいる。評価の結果には，9.4で定義する“適合主張”も含まれなければならない。
9.3
ST評価を含むTOE評価の結果
この規格類第3部は，TOEがST内のSFRを満たしていることを示す十分な保証が存在するかどうか，
を評価者が決定するために参考にすることを，評価者に義務付ける評価基準を含んでいる。したがって，
TOEを評価した結果として，STに対する合否判定をしなければならない。ST及びTOEの両方を評価した
結果，合格と判定された場合，その基になる製品には登録リストに登録される資格が与えられる。評価の
結果には，9.4で定義する“適合主張”も含まれなければならない。
評価結果は，後に認証プロセスで使用されることがあるが，この認証プロセスは，この規格類の適用範
囲外である。
9.4
適合主張
適合主張は，評価に合格したPP又はSTによって満たされる要件の集合の導出元を示す。この適合主張
は，次の記述で構成されるこの規格類への適合主張を含む。
TOEの評価
TOEの評価結果
PPの評価
STの評価
評価済みPP
PPの評価結果
STの評価結果
評価済みTOE
TOE
登録リスト
PP
登録リスト
評価済みST
39
X 5070-1：2011 (ISO/IEC 15408-1：2009)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
a) PP又はSTが適合を主張するこの規格類の版を記述する。
b) この規格類第2部の（セキュリティ機能要件）への適合を次のいずれかで記述する。
・ ISO/IEC 15408-2適合−PP又はSTは，そのPP又はSTの全てのSFRがこの規格類第2部の機能
コンポーネントだけに基づく場合，ISO/IEC 15408-2適合となる。
・ ISO/IEC 15408-2拡張−PP又はSTは，そのPP又はSTの少なくとも一つのSFRがこの規格類第
2部の機能コンポーネントに基づいていない場合，ISO/IEC 15408-2拡張となる。
c) この規格類第3部の（セキュリティ保証要件）への適合を次のいずれかで記述する。
・ ISO/IEC 15408-3適合−PP又はSTは，そのPP又はSTの全てのSARがこの規格類第3部の保証
コンポーネントだけに基づく場合，ISO/IEC 15408-3適合となる。
・ ISO/IEC 15408-3拡張−PP又はSTは，そのPP又はSTの少なくとも一つのSARがこの規格類第
3部の保証コンポーネントに基づいていない場合，ISO/IEC 15408-3拡張となる。
さらに，適合主張には，パッケージに関してなされる宣言を含んでもよい。この場合には次のうちの一
つが選択される。
a) パッケージ名適合−PP又はSTが，次のいずれかの場合に，あらかじめ定義されたパッケージ（例え
ば，EAL）に適合しているとき。
・ そのPP又はST内のSFRが，パッケージ内のSFRと同じ。
・ そのPP又はST内のSARが，パッケージ内のSARと同じ。
b) パッケージ名追加−PP又はSTが，次のいずれかの場合に，あらかじめ定義されたパッケージへの追
加となるとき。
・ PP又はST内のSFRにはパッケージ内の全てのSFRが含まれるが，追加のSFR又はパッケージ
内のSFRよりも上位階層のSFRが少なくとも一つある。
・ PP又はST内のSARにはパッケージ内の全てのSARが含まれるが，追加のSAR又はパッケージ
内のSARよりも上位階層のSARが少なくとも一つある。
TOEがあるSTで評価に合格している場合，そのSTの適合主張は，そのTOEにも適用できることに注
意する。したがって，TOEは，例えばISO/IEC 15408-2 適合でもあり得る。
最後に，適合主張には，プロテクションプロファイルに関する次の二つの宣言を含んでもよい。
a) PP適合−PP又はTOEが，適合結果の一部として記載されている特定のPPを満たしているとき。
b) 適合の表明（PPだけ）−この表明は，PP又はSTがこのPPに適合しなければならない方法，つまり
正確又は例証を記述する。この適合の表明の詳細については，附属書Bに示す。
9.5
ST評価を含むTOE評価の結果の利用
ST及びTOEが評価されると，資産の所有者は，TOEがその運用環境とともに脅威に対抗することにつ
いて，（STに定義される）保証を得ることができる。資産を脅威にさらすリスクを受け入れるかどうかを
判断するときに，その資産の所有者は評価結果を利用することができる。
ただし，資産の所有者は次のことを慎重に確認する方がよい。
・ ST内のセキュリティ課題定義が資産の所有者のセキュリティ課題と一致している。
・ 資産の所有者の運用環境が，STに記述された運用環境のセキュリティ対策方針に適合している（又は
適合させることができる。）。
上記のいずれかが当てはまらない場合，そのTOEは資産の所有者の目的に適していないことがある。ま
た，評価済みTOEの運用が開始されると，これまで分からなかったTOE内の誤り又はぜい弱性が表面化
することがある。この場合，開発者は（ぜい弱性を改修するために）TOEを修正するか，又はSTを変更
40
X 5070-1：2011 (ISO/IEC 15408-1：2009)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
して評価の範囲からぜい弱性を除去してもよい。いずれの場合も，前の評価結果はもはや有効ではない。
信頼の回復が必要であると思われる場合は，再評価が必要である。この規格類はこのような再評価のた
めに使用してよいが，再評価を行うための詳細な手続はこの規格の適用範囲外である。
41
X 5070-1：2011 (ISO/IEC 15408-1：2009)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
附属書A
（参考）
セキュリティターゲットの仕様
A.1 この附属書の目的及び構成
この附属書の目的は，セキュリティターゲット（ST）の概念を説明することにある。この附属書では，
ASE基準（セキュリティターゲットの評価基準）の定義は行わない。ASE基準の定義は，この規格類第3
部にある。詳述はISO/IEC 15408-3のE.1[3]の中に見つけることができる。
この附属書は，次の四つの主要な部分から構成されている。
a) STに記載しなければならない内容。これについては，A.2で概要を述べ，A.4からA.10まででより詳
細に説明する。これらの箇条では，ST必須記載内容及び各内容間の相互関係について説明し，例を示
す。
b) 望ましいSTの使用法。これについては，A.3で概要を述べ，A.11でより詳細に説明する。これらの
箇条では，STがどのように使用される方がよいかについて及び幾つかの疑問についてSTで回答可能
なことを説明する。
c) 低保証ST。低保証STは，STの記載内容を減らしたSTである。これについては，A.12で詳細に説明
する。
d) 標準への適合の主張。A.13では，TOEが特定の標準を満たしていることを，ST作成者が主張する方
法について説明する。
A.2 ST必須記載内容
図A.1は，この規格類第3部に規定するST必須記載内容を示す。図A.1は，STの構成に関する概略図
として使用してもよいが，別の構成であってもよい。例えば，セキュリティ要件根拠が特に長くなる場合
は，セキュリティ要件の箇条の代わりに，STの附属書にそれを記述することができる。STの各箇条及び
それらの細分箇条の記載内容を，次に手短に述べ，A.4からA.10まででより詳細に説明する。通常，ST
には次の事項を記述する。
a) ST概説。抽象レベルの異なる，TOEについての三つの叙述的記述を含む。
注記 TOEについての三つの叙述的記述とは，ST参照・TOE参照，TOE概要及びTOE記述である。
b) 適合主張。STが，いずれかのPP及び／又はパッケージへの適合を主張するかどうかを示し，適合す
る場合には，どの PP及び／又はパッケージに適合しているかを示す。
c) セキュリティ課題定義。脅威，組織のセキュリティ方針（OSP）及び前提条件を示す。
d) セキュリティ対策方針。セキュリティ課題をTOEのセキュリティ対策方針及びTOEの運用環境のセ
キュリティ対策方針に分割した解決方法を示す。
e) 拡張コンポーネント定義。 （この規格類の第2部又は第3部に含まれていない） 新しいコンポーネ
ントを定義することができる。これらの新しいコンポーネントは，拡張機能要件及び拡張保証要件を
定義するために必要である。
f)
セキュリティ要件。TOEのセキュリティ対策方針から規格化された表現に書き換えたものを示す。SFR
及びSARは規格化された言語で表現される。また，根拠ではSFRからセキュリティ対策方針へ逆方
向に遡れること，SFRの正当性を記述する。
42
X 5070-1：2011 (ISO/IEC 15408-1：2009)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
g) TOE要約仕様。TOEでSFRを実装する方法を示す。
STの記載内容を減らした低保証STも存在する。これについては，A.12で詳細に説明する。この附
属書の他の部分では，上記の全項目を含むSTを想定している。
図A.1−セキュリティターゲットの内容
A.3 STの使用
A.3.1 望ましいSTの使用法
典型的なSTは，次の二つの役割を果たす。
・ 評価前及び評価中の場合，STは“評価の対象が何か”を規定する。この役割において，STは，TOE
の正確なセキュリティ特性及び正確な評価範囲に関して，開発者と評価者との間で合意するための基
となるものを提供する。この役割では，技術的な正確さ及び完全さが主な課題である。この役割にお
いてSTをどのように使用すればよいかについてA.7で説明する。
・ 評価後の場合，STは“評価済みの対象が何か”を規定する。この役割において，STは，TOEの開発
者又は販売代理業者とTOEの潜在的な利用者との間で合意するための基となるものを提供する。ST
は，TOEの正確なセキュリティ特性を抽象的に記述するものであり，このSTを満たすことをTOEが
評価済みであることから，潜在的な利用者は，このSTの記述を信頼することができる。この役割で
セキュリティターゲット
ST参照
TOE参照
TOE概要
TOE記述
ST概説
CC適合主張
PP主張，
パッケージ主張
適合根拠
適合主張
脅威
組織のセキュリティ方針
前提条件
セキュリティ課題定義
TOEのセキュリティ対策方針
運用環境のセキュリティ対策方針
セキュリティ対策方針根拠
セキュリティ対策方針
拡張コンポーネント定義
拡張コンポーネント定義
セキュリティ機能要件
セキュリティ保証要件
セキュリティ要件根拠
セキュリティ要件
TOE要約仕様
TOE要約仕様
43
X 5070-1：2011 (ISO/IEC 15408-1：2009)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
は，使いやすさ及び理解しやすさが主な課題である。この役割においてSTをどのように使用すれば
よいかについてA.11で説明する。
A.3.2 望ましくないSTの使用法
（STの多くの役割の中から）STが果たさない方がよい二つの役割を次に示す。
・ 詳細な仕様：STは，比較的抽象レベルの高いセキュリティ仕様を記述する。一般に，STには詳細な
プロトコル仕様，アルゴリズム及び／又は機構の詳細な説明，詳細にわたる運用の長い説明などを含
まない方がよい。
・ 完全な仕様：STは，セキュリティ仕様を記述したものであって，全体の仕様ではない。セキュリティ
に関係する場合を除いて，相互運用性，物理的な寸法及び重さ，定格電圧などの特性は，STの一部分
でない方がよい。これは一般に，STは，それ自体が完全な仕様ではなく，完全な仕様の一部分であっ
ても差し支えないということを意味する。
A.4 ST概説（ASE̲INT）
ST概説では，次の三つの抽象レベルについて叙述的な方法でTOEを説明する。
a) ST参照及びTOE参照。ST及びSTが参照するTOEの識別情報を提供する。
b) TOE概要。TOEを簡潔に説明する。
c) TOE記述。TOEをより詳細に説明する。
A.4.1 ST参照及びTOE参照
STは，特定のSTを指し示す明確なST参照を含む。典型的なST参照は，名称，バージョン，作成者及
び発行日から構成する。“MauveRAM Database ST，バージョン1.3，MauveCorp Specification Team，2002
年10月11日”は，ST参照の記述例である。
STは，STへの適合を主張するTOEを指し示すTOE参照も含む。典型的なTOE参照は，開発者名，TOE
の名称及びTOEのバージョン番号から構成する。“MauveCorp MauveRAM Database v2.11”は，TOE参照
の記述例である。単一のTOEが，例えば，TOEの様々な利用者によって，何度も評価を受け，その結果，
複数のSTが存在する場合には，ST参照は一意である必要はない。
TOEが一つ以上の既知の製品から構成される場合，その製品名を挙げて，このことをTOE参照に記述
することができる。ただし，利用者に，次のような誤解を与えてはならない，すなわち，主要な部分又は
セキュリティ機能が，その評価において熟慮されていない状況であるにもかかわらず，このことを記述し
ていないTOE参照は，認められない。
ST参照及びTOE参照は，ST及びTOEに索引を付け，これらを参照すること及び評価済みのTOE又は
製品のリストにこれらを掲載することを容易にする。
A.4.2 TOE概要
TOE概要は，自らのセキュリティの必要性を満たし，自らが使用するハードウェア，ソフトウェア及び
ファームウェアで稼動するTOEを見つけるために評価済みのTOE又は製品のリストを調べようとする，
TOEの潜在的な利用者のためのものである。TOE概要の一般的な長さは，数段落である。
このため，TOE概要は，TOEの使用方法及びその主要なセキュリティの特徴について簡潔に説明し，TOE
の種別及びTOEが必要とするTOE以外の主要なハードウェア，ソフトウェア及びファームウェアが何で
あるかを示す。
44
X 5070-1：2011 (ISO/IEC 15408-1：2009)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
A.4.2.1 TOEの使用方法及び主要なセキュリティの特徴
TOEの使用方法及び主要なセキュリティの特徴に関する記述は，セキュリティの点からTOEが潜在的
にもつ能力及びセキュリティに関連したTOEの用途についての，ごく一般的な知識を与えることを目的と
する。この記述は，（潜在的な）TOEの利用者のために，業務運用の視点から，TOEの使用方法及び主要
なセキュリティの特徴についてTOEの利用者が分かる表現を使用して記述するのがよい。この記述例を次
に示す。
例 MauveCorp MauveRAM Database v2.11は，ネットワーク環境での使用を想定した複数利用者向け
のデータベースである。このデータベースは，1 024人の利用者が同時利用できる。このデータベ
ースは，パスワード又はトークンによる認証及び生体認証が使用でき，偶発的なデータ破損を防
止し，10 000トランザクションをロールバックすることができる。このデータベースの監査の特
徴は，一部の利用者及びトランザクションに対する詳細な監査が，それ以外の利用者及びトラン
ザクションのプライバシを保護しつつ，実施できるように，高度に設定ができることである。
A.4.2.2 TOE種別
TOE概要には，ファイアウォール，VPNファイアウォール，スマートカード，暗号化モデム，イントラ
ネット，ウェブサーバ，データベース，ウェブサーバ及びデータベース，LAN，ウェブサーバ及びデータ
ベースを伴うLANなどの，TOEの一般的な種別を示す。
TOEが上記のように容易に種別が記載できない場合には，“なし（none）”を使用することができる。
TOE種別は，幾つかの場合において，利用者に誤解を与えることがある。例を次に示す。
a) TOE種別から，TOEに特定のセキュリティ機能が備わっているものと期待しているにもかかわらず，
TOEがこのセキュリティ機能を備えていないことがある。例を次に示す。
・ ATMカード種別のTOEにおいて，識別機能・認証機能がない。
・ ファイアウォール種別のTOEにおいて，ほとんど一般的に使用されているプロトコルに対応して
いない。
・ PKI種別のTOEにおいて，証明書失効機能がない。
b) TOE種別から，TOEが特定の運用環境で動作するものと期待しているにもかかわらず，TOEがその
運用環境で動作できないことがある。例を次に示す。
・ PCオペレーティングシステム種別のTOEにおいて，ネットワーク接続，フロッピードライブの
使用及びCD/DVDプレーヤの使用を行うと，PCがセキュアに動作しない。
・ ファイアウォール種別のTOEにおいて，そのファイアウォールを通じて接続可能な全ての使用者
が善良でない限り，セキュアに動作しない。
A.4.2.3 必要とするTOE以外のハードウェア，ソフトウェア及び／又はファームウェア
他のITに依存しないTOEもあるが，多くのTOE（特にソフトウェアTOE）は，TOE以外の追加のハー
ドウェア，ソフトウェア及び／又はファームウェアに依存する。後者の場合，TOE概要は，そのような
TOE以外のハードウェア，ソフトウェア及び／又はファームウェアを識別する必要がある。追加のハード
ウェア，ソフトウェア及び／又はファームウェアに関する，全てについての，十分に詳細な識別は必要で
はないが，この識別は，潜在的な利用者に対して，TOEを使用するために必要とする，主要なハードウェ
ア，ソフトウェア及び／又はファームウェアを判断するために十分な程度，それらの全てについて詳細で
ある方がよい。ハードウェア，ソフトウェア及び／又はファームウェアの識別例を，次に示す。
・ Yaizaオペレーティングシステム（バージョン3.0 アップデート6b，6c 若しくは7，又はバージョン
4.0）上で実行し，1 GHzより高速のプロセッサ及び512 MB以上のRAMを搭載した標準PC。
45
X 5070-1：2011 (ISO/IEC 15408-1：2009)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
・ Yaizaオペレーティングシステム（バージョン3.0 アップデート6d）上で実行し，1.0 WMドライバセ
ットを備えたWonderMagic 1.0グラフィックスカード，1 GHzより高速のプロセッサ及び512 MB以上
のRAMを搭載した標準PC。
・ Yaiza OS（バージョン3.0以上）を搭載した標準PC。
・ CleverCard SB2067集積回路。
・ Quick OSスマートカードオペレーティングシステム（バージョン2.0）上で実行するCleverCard SB2067
集積回路。
・ 20xx年xx月に設置された省庁のLAN。
A.4.3 TOE記述
TOE記述は，TOEについての叙述的記述であり，数ページにわたることがある。TOE記述は，TOE概
要よりも詳細に，TOEがもつセキュリティの能力についての一般的な見解を，評価者及び潜在的な利用者
に与えた方がよい。TOE記述は，そのTOEの想定用途よりも幅広い用途を記述するために使用してもよ
い。
TOE記述には，TOEの物理的範囲（TOEを構成する全てのハードウェア，ファームウェア，ソフトウ
ェア及びガイダンスのリスト）を記述する。このリストは，TOEの物理的範囲についての一般的な見解を
読者に与えるのに十分な詳細レベルで記述した方がよい。
TOE記述には，TOEの論理的範囲（一般的な見解を読者に与えるのに十分な詳細レベルで，TOEによ
って提供される論理的なセキュリティの特徴）も記述した方がよい。この記述は，TOE概要に記述する主
要なセキュリティの特徴よりも詳細であることが求められる。
物理的範囲及び論理的範囲において重要なことは，特定の部品又は特徴がTOEの範囲内であるかどうか
についての，また，この部品又は特徴がTOEの範囲外であるかどうかについての疑いを残さない方法で，
TOEを記述することである。これは，TOEがTOE以外のエンティティと相互に関連し，簡単に分離でき
ない場合に，特に重要である。TOEがTOE以外のエンティティと相互に関連している例を次に示す。
・ TOEが，スマートカードIC全体ではなく，スマートカードICの暗号化コプロセッサである場合。
・ TOEが，暗号化プロセッサを除くスマートカードICである場合。
・ TOEが，MinuteGap Firewall v18.5のネットワークアドレスの変換部分である場合。
A.5 適合主張（ASE̲CCL）
STのこの細別箇条には，STが次に挙げるものとどのように適合するかを記述する。
・ この規格類の第2部及び第3部。
・ プロテクションプロファイル（ただし，存在する場合に限る。）。
・ パッケージ（ただし，存在する場合に限る。）。
STがこの規格類とどのように適合するかの記述は，使用するこの規格類の版及びSTに拡張セキュリテ
ィ要件が含まれるかどうか（A.8参照）の二つの項目から成り立つ。
プロテクションプロファイルに対するSTの適合性の記述は，適合性を主張するプロテクションプロフ
ァイルを，STにおいて列挙することをいう。この詳細を9.4に示す。
パッケージに対するSTの適合性の記述は，適合性を主張するパッケージを，STにおいて列挙すること
をいう。この詳細を9.4に示す。
46
X 5070-1：2011 (ISO/IEC 15408-1：2009)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
A.6 セキュリティ課題定義（ASE̲SPD）
A.6.1 概要
セキュリティ課題定義では，対処する必要があるセキュリティ課題を定義する。この規格類に関する限
り，セキュリティ課題定義は自明のこととして扱われる。すなわち，セキュリティ課題定義を導くプロセ
スは，この規格類の適用範囲外である。しかし，評価結果の有用性はSTに大きく依存し，STの有用性は
セキュリティ課題定義の質に大きく依存することに注意する方がよい。したがって，良好なセキュリティ
課題定義を導くために，多くの資源を費やし，明確に定義されたプロセス及び分析を使用することは多く
の場合価値がある。
この規格類第3部によれば，全ての箇条に内容を記述する必要がないことに注意する。例えば，STに脅
威を記述すれば，OSPを記述しなくてもよい，また，逆にOSPを記述すれば脅威について記述しなくても
よい。同様に，いかなるSTも前提条件を省略することができる。
TOEが物理的に分散している場合は，TOE運用環境の個別領域ごとに関連する脅威，OSP及び前提条件
を記述することが望ましいことにも注意する。
A.6.2 脅威
セキュリティ課題定義のA.6.2では，TOE，その運用環境又はこれら二つの組合せによって対抗する必
要がある脅威を示す。
脅威は，資産に対する脅威エージェントの敵対的な動作から構成される。敵対的な動作は，資産価値を
生じる資産の一つ以上の特性に影響を与える。脅威エージェントは個々のエンティティとして記述するこ
とができるが，場合によってはエンティティの種別，エンティティのグループなどとして記述する方が適
切である。脅威エージェントの例には，ハッカー，利用者，コンピュータのプロセス，事故などがある。
脅威エージェントは，専門知識，資源，機会，動機などの側面によって，更に詳細に記述することができ
る。
注記 資源とは，人，もの，金，時間などを指す。
敵対的な動作とは，脅威エージェントが資産に対して行う動作である。これらの動作は，資産価値を生
じる資産の一つ以上の特性に影響を与える。脅威の例を次に示す。
・ 企業のネットワークから機密ファイルを遠隔操作で複製するハッカー（優れた専門知識，標準的な機
器を所有し，この行為に対して報酬を受け取る）。
・ 広域ネットワーク（WAN）の性能を大幅に低下させるワーム。
・ 利用者のプライバシを侵害するシステム管理者。
・ 機密通信を傍受しているインターネット上の第三者。
A.6.3 組織のセキュリティ方針（OSP）
セキュリティ課題定義のA.6.3では，TOE，その運用環境又はこれら二つの組合せによって実施する必
要があるOSPを示す。
OSPとは，実際又は仮想上の組織によって，その運用環境において現在及び／又は将来に課される（若
しくは課されると推定される）セキュリティの規則，手続又はガイドラインである。OSPはTOEの運用
環境を管理する組織によって規定される場合もあれば，立法機関又は規制機関によって規定される場合も
ある。OSPは，TOE及び／又はTOEの運用環境に適用できる。OSPの例を次に示す。
・ 政府によって使用される全ての製品は，パスワード生成及び暗号化に関して国の基準に適合しなけれ
ばならない。
47
X 5070-1：2011 (ISO/IEC 15408-1：2009)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
・ システム管理者の権限と部門機密に対するアクセス許可とをもつ利用者だけが，部門ファイルサーバ
を管理できるようにしなければならない。
A.6.4 前提条件
セキュリティ課題定義のA.6.4では，セキュリティ機能を提供できるようにするために，その運用環境
に対して設定する前提条件を示す。TOEがこれらの前提条件を満たさない運用環境に置かれる場合，その
TOEはそのセキュリティ機能の全てを提供することができなくなる可能性がある。前提条件には，運用環
境の物理的条件，人的条件及び接続に関する条件がある。前提条件の例を次に示す。
a) 運用環境の物理的側面に関する前提条件。
・ TOEは電磁波の放射を最小限にするように設計された部屋に設置されることを前提とする。
・ TOEの管理者コンソールはアクセス制限された領域に設置されることを前提とする。
b) 運用環境の人的側面に関する前提条件。
・ TOEの利用者はTOEを運用するために十分に訓練を受けることを前提とする。
・ 国家機密として分類される情報に対して，TOEの利用者は情報の取扱いについて承認を受けるこ
とを前提とする。
・ TOEの利用者はパスワードを書き留めないことを前提とする。
c) 運用環境の接続性の側面に関する前提条件。
・ TOEを実行するために，ディスク領域が最低10 GBのPCワークステーションを利用できること
を前提とする。
・ TOEは，このワークステーションで実行されているOS以外の唯一のアプリケーションであるこ
とを前提とする。
・ TOEは，信頼できないネットワークに接続されないことを前提とする。
評価中に，これらの前提条件は満たされているとみなされることに注意する。つまり，前提条件は決し
て試験されることはない。このため，前提条件は運用環境だけに対して設定できる。評価は，TOEに関す
る主張を評価することからなり，TOEに関する主張が正しいことを前提条件とすることではないので，
TOEの動作に関して前提条件を設定することはできない。
A.7 セキュリティ対策方針（ASE̲OBJ）
セキュリティ対策方針は，セキュリティ課題定義によって定義される課題に対して意図している解決策
の簡潔かつ抽象的な宣言文である。セキュリティ対策方針には，次の三つの役割がある。
・ 課題に対して，自然言語で記述された上位レベルの解決策を提供する。
・ 異なるエンティティ（TOE及び運用環境）のそれぞれが課題の一部に対処しなければならないことを
反映するように，この解決策を二つの分割式解決策に分ける。
・ これらの分割式解決策が課題に対する完全な解決策を形成することを示す。
A.7.1 上位レベル解決策
セキュリティ対策方針は，あまり詳細過ぎない簡潔かつ明確な宣言文の集まりから構成される。これら
の組合せによって，セキュリティ課題に対する上位レベルの解決策が形成される。セキュリティ対策方針
の抽象化のレベルは，TOEについて知識のある潜在的な利用者にとって，明確かつ理解可能にすることを
目的としている。セキュリティ対策方針は，自然言語で記述する。
A.7.2 分割式解決策
STでは，セキュリティ対策方針に示される上位レベルセキュリティ解決策は，二つの分割式解決策に分
48
X 5070-1：2011 (ISO/IEC 15408-1：2009)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
けられる。このような分割式解決策は，TOEのセキュリティ対策方針及び運用環境のセキュリティ対策方
針と呼ばれる。これは，分割式解決策が，TOE及び運用環境という二つの異なるエンティティによって提
供されることを反映している。
A.7.2.1 TOEのセキュリティ対策方針
TOEは，セキュリティ課題定義によって定義される課題の特定の部分を解決するために，セキュリティ
機能を提供する。この分割式解決策は，TOEのセキュリティ対策方針と呼ばれ，課題の特定の部分を解決
するためにTOEが達成すべき目標のセットから構成される。TOEのセキュリティ対策方針の例を，次に
示す。
・ TOEは，TOEとサーバとの間で転送される全てのファイルの内容の機密を保持しなければならな い。
・ TOEは，TOEが提供する転送サービスへのアクセスを許可する前に，全ての利用者を識別し，認証し
なければならない。
・ TOEは，STの附属書Cに示されるデータアクセス方針に従って，データに対する利用者のアクセス
を制限しなければならない。
TOEが物理的に分散している場合は，TOEのセキュリティ対策方針を含むSTの箇条を，これを反映す
るために複数の細分箇条に分割することが望ましい場合がある。
A.7.2.2 運用環境のセキュリティ対策方針
TOEの運用環境は，TOEが（TOEのセキュリティ対策方針によって定義される）セキュリティ機能を
正しく提供できるようにTOEを支援する技術及び手続に関する手段を実装する。この分割式解決策は運用
環境のセキュリティ対策方針と呼ばれ，運用環境で達成すべき目標を記述する宣言文の集まりから構成さ
れる。
運用環境のセキュリティ対策方針の例を，次に示す。
・ 運用環境では，TOEを実行するためにOS Inuxバージョン3.01bが動作しているワークステーション
を提供しなければならない。
・ 運用環境では，TOEの操作を許可する前に，全てのTOE利用者が適切な訓練を受けるようにしなけ
ればならない。
・ TOEの運用環境では，管理者及び管理者に付き添われた保守員にTOEへの物理的アクセスを制限し
なければならない。
・ 運用環境では，中央監査サーバに送信する前に，TOEによって生成される監査ログの機密性を確保し
なければならない。
TOEの運用環境が特性の異なる複数のサイトから構成されている場合は，これを反映するために，運用
環境のセキュリティ対策方針を含むSTの箇条を，これを反映するために複数の細分箇条に分割すること
が望ましい場合がある。
A.7.3 セキュリティ対策方針とセキュリティ課題定義との関係
STには，次の二つの箇条からなるセキュリティ対策方針根拠も含まれる。
・ どのセキュリティ対策方針が，どの脅威，OSP及び前提条件に対処するかを示す追跡。
・ 全ての脅威，OSP及び前提条件がセキュリティ対策方針によって効果的に対処されることを示す正当
化のセット。
A.7.3.1 セキュリティ対策方針とセキュリティ課題定義との間の追跡
追跡は，セキュリティ対策方針が，セキュリティ課題定義で記述される脅威，OSP及び前提条件までど
のように遡るかを示す。この追跡では，次の三つの規則に従わなければならない。
49
X 5070-1：2011 (ISO/IEC 15408-1：2009)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
a) 見せかけの対策方針の禁止：各セキュリティ対策方針は，少なくとも一つの脅威，OSP又は前提条件
まで遡る。
b) セキュリティ課題定義に関する完全性：脅威，OSP及び前提条件のそれぞれについて，そこまで遡る
少なくとも一つのセキュリティ対策方針がある。
c) 正確な追跡：前提条件は常にTOEの運用環境について設定されるため，TOEのセキュリティ対策方
針は前提条件に遡らない。この規格類第3部で認められる追跡を図A.2に示す。
図A.2−セキュリティ対策方針とセキュリティ課題定義との間の追跡
複数のセキュリティ対策方針が遡った先が同じ脅威になることがあるが，その場合，これらのセキュリ
ティ対策方針の組合せがその脅威に対抗することを示す。OSP及び前提条件にも同じことが当てはまる。
A.7.3.2 追跡の正当化の提供
セキュリティ対策方針根拠では，追跡が有効であることも示す。つまり，特定の脅威，OSP及び前提条
件まで遡る全てのセキュリティ対策方針が達成された場合，その脅威は対抗され，OSPは実施され，前提
条件が確認されることを示す。
この追跡の正当化においては，関連するセキュリティ対策方針を達成することによる，脅威への対抗，
OSPの実施及び前提条件の確認への効果を分析し，実際に対抗，実施及び確認されるという結論を導く。
セキュリティ課題定義が幾つかのセキュリティ対策方針と非常に似ているような状況では，追跡の正当
化が非常に簡単になることがある。例えば，脅威が“T17： 脅威エージェントXは，AB間の転送時に機
密情報を読み取る。”であり，TOEのセキュリティ対策方針が“OT12： TOEは，AB間で送信される全て
の情報の機密が確実に保持されるようにしなければならない。”である場合，“T17は，OT12によって直接
対抗される。”と示される。
A.7.3.3 脅威への対抗について
脅威への対抗とは，必ずしもその脅威を除去することを意味せず，脅威を十分に減らすこと又は脅威を
十分に緩和することを意味する場合もある。
脅威の除去の例は，次のとおりである。
・ 脅威エージェントから悪意ある行為を実行する能力を除去する。
・ 敵対的な動作を資産に対して行うことができなくなるように，資産を移動，変更又は保護する。
・ 脅威エージェントを除去する（例えば，頻繁にネットワークに障害を起こす装置をネットワークから
取り外す。）。
脅威の軽減の例は，次のとおりである。
・ 敵対的な動作を実行する脅威エージェントの能力を制限する。
脅威
組織の
セキュリティ方針
前提条件
TOEの
セキュリティ
対策方針
運用環境の
セキュリティ
対策方針
50
X 5070-1：2011 (ISO/IEC 15408-1：2009)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
・ 脅威エージェントが敵対的な動作を実行する機会を制限する。
・ 実行された敵対的な動作が成功する可能性を減少させる。
・ 抑止によって脅威エージェントが敵対的な動作を実行する動機を減少させる。
・ 脅威エージェントに，より多くの専門知識又は資源を課する。
脅威の影響の緩和の例は，次のとおりである。
・ 資産のバックアップを頻繁に行う。
・ 資産のスペアコピーを取る。
・ 資産に保険をかける。
・ 適切なアクションをとることができるように，成功した全ての敵対的な動作が適切な時期に必ず検出
されるようにする。
A.7.4 セキュリティ対策方針：結論
セキュリティ対策方針及びセキュリティ対策方針根拠に基づいて，次のような結論を導くことができる。
・ 全てのセキュリティ対策方針が達成された場合，ASE̲SPDで定義されるセキュリティ課題は解決され
る。
・ 全ての脅威が対抗され，全てのOSPが実施され，全ての前提条件が確認される。
A.8 拡張コンポーネント定義（ASE̲ECD）
多くの場合，STのセキュリティ要件（A.9参照）は，この規格類の第2部又は第3部のコンポーネント
に基づく。ただし，場合によっては，この規格類の第2部又は第3部のコンポーネントに基づかないST
の要件が存在することがある。この場合は，新しいコンポーネント（拡張コンポーネント）を定義しなけ
ればならない。この定義は拡張コンポーネント定義で行う。これについての詳細を，C.4に示す。
A.8では，拡張コンポーネントだけを扱い，拡張要件（拡張コンポーネントに基づく要件）については
扱わない。拡張要件はセキュリティ要件（A.9参照）に含めることが望ましい，全ての目的のために，こ
の規格類の第2部又は第3部のコンポーネントに基づく要件と同じになる。
A.9 セキュリティ要件（ASE̲REQ）
セキュリティ要件は2種類の要件からなる。
a) セキュリティ機能要件（SFR）：TOEのセキュリティ対策方針の規格化された表現への書換え。
b) セキュリティ保証要件（SAR）：TOEがSFRに対応していることについて，どのように保証されるか
についての記述。
A.9.1及びA.9.2でこれらの2種類の要件について示す。
A.9.1 セキュリティ機能要件（SFR）
SFRはTOEのセキュリティ対策方針の書換えである。SFRは通常，抽象化のより詳細なレベルにあるが，
完全な書換えでなければならない（完全な書換えとは，セキュリティ対策方針が完全に記述されることで
ある。）。
さらに，SFRは特定の技術的解法（実装）から独立していなければならない。この規格類は，次の理由
によって規格化された表現への書換えを必要とする。
・ 評価される対象についての正確な記述を提供するため。TOEのセキュリティ対策方針は通常，自然言
語で表現されるが，規格化された表現への書換えにはTOEの機能の，より正確な記述が求められる。
・ 二つのST間での比較を可能とするため。異なるST作成者がセキュリティ対策方針について説明する
51
X 5070-1：2011 (ISO/IEC 15408-1：2009)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
ときに異なる用語を使用するかもしれないが，規格化された表現では同じ用語及び概念を使用するこ
とが求められる。これによって比較が容易になる。
運用環境は評価されず，その評価を目的とした記述は必要ないので，運用環境のセキュリティ対策方針
のために，この規格類ではどのような書換えも必要ない。運用システムのセキュリティアセスメントに関
連する参考文献を参照する。
運用環境の一部が別の評価で評価されるかもしれないが，これは現行の評価の範囲外である。例えば，
TOEがOSの場合は，ファイアウォールがその運用環境に存在することを必要とするかもしれない。別の
評価ではファイアウォールを評価するかもしれないが，この評価はTOEがOSの場合の評価と関係ない。
A.9.1.1 この規格類がこの書換えを支援する方法
この規格類は，次の三つの方法でこの書換えを支援する。
a) 評価される対象について正確に記述するように設計された，事前に定義された明確な“表現”を提供
することによる。この表現は，この規格類第2部で定義されるコンポーネントの集まりとして定義さ
れる。幾つかの例外はあるが（7.3参照），TOEのセキュリティ対策方針からSFRへの明確な書換えと
して，この表現の使用が必須である。
b) 操作を提供することによる。操作とは，ST作成者が，SFRを変更して，TOEのセキュリティ対策方
針の，より正確な書換えを提供するようにする仕組みのことである。この規格類には，割付け，選択，
繰返し及び詳細化の四つの操作が規定されている。これらはC.2で，より詳しく記述している。
c) 依存性を提供することによる。依存性とは，SFRへの，より完全な書換えを支援する仕組みのことで
ある。この規格類第2部の表現では，一つのSFRは他のSFRへの依存性をもつことができる。これ
は，STがそのSFRを使用する場合に，他のSFRを使用する必要性を意味する。したがって，必要な
SFRを含めることで，ST作成者が入れ忘れないようにし，STの完全性を改善する。依存性は7.2で，
より詳しく示している。
A.9.1.2 SFRとセキュリティ対策方針との関係
STは，SFRについての二つの細分箇条からなる，セキュリティ要件の根拠を含んでいる。
・ どのSFRがTOEのどのセキュリティ対策方針に対応しているのかを示す追跡。
・ そのTOEの全てのセキュリティ対策方針が，それらのSFRによって有効に対応していることを示す，
正当化論拠の集まり。
A.9.1.2.1 SFRとTOEのセキュリティ対策方針との間の追跡
追跡は，SFRがTOEのセキュリティ対策方針までどのように遡るかを示す。この追跡では，次の二つの
規則に従わなければならない。
a) 見せかけのSFRの禁止：各SFRは，少なくとも一つのセキュリティ対策方針まで遡る。
b) TOEのセキュリティ対策方針に関する完全性：TOEのセキュリティ対策方針のそれぞれについて，
そこまで遡る少なくとも一つのSFRがある。
複数のSFRが遡った先が同じTOEのセキュリティ対策方針になることがあるが，その場合，これらの
セキュリティ要件の組合せがそのTOEのセキュリティ対策方針に対応することを示す。
A.9.1.2.2 追跡の正当化の提供
セキュリティ要件の根拠では，追跡が有効であることを示す。つまり，特定のTOEのセキュリティ対策
方針まで遡る全てのSFRが達成された場合，そのTOEのセキュリティ対策方針は対応されることを示す。
この追跡の正当化においては，関連するSFRを達成することによる，TOEのセキュリティ対策方針への対
応を分析し，実際に対応されるという結論に導く。
52
X 5070-1：2011 (ISO/IEC 15408-1：2009)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
SFRがTOEのセキュリティ対策方針と非常に似ているような状況では追跡の正当化が非常に簡単にな
ることがある。
A.9.2 セキュリティ保証要件（SAR）
SARはTOEがどのように評価されるかについての記述である。この記述は次の理由によって規格化さ
れた表現を使用する。
・ TOEがどのように評価されるかについての正確な記述を提供するため。規格化された表現を使用する
ことで，正確に記述するのを助け，曖昧さを避ける。
・ 二つのST間での比較を可能とするため。異なるST作成者が，評価について説明するときに異なる用
語を使用するかもしれないが，標準化された表現では同じ用語及び概念を使用することが求められる。
これによって比較が容易になる。
この規格化された表現は，この規格類第3部で定義されているコンポーネントの集まりとして定義され
る。幾つかの例外は存在するが，この表現の使用は必須である。この規格類は，この表現を次の二つの方
法で支援している。
a) 操作を提供することによる。操作とは，ST作成者が，SARを変更する仕組みのことである。この規
格類には，割付け，選択，繰返し及び詳細化の四つの操作がある。これらは7.1で，より詳しく記述
している。
b) 依存性を提供することによる。依存性とは，SARへの，より完全な書換えを支援する仕組みのことで
ある。この規格類第3部の表現では，一つのSARは他のSARへの依存性をもつことができる。これ
は，STがそのSARを使用する場合に，他のSARを使用する必要性を意味する。したがって，必要な
SARを含めることで，ST作成者が入れ忘れないようにし，STの完全性を改善する。依存性は7.2で，
より詳しく記述している。
A.9.3 SAR及びセキュリティ要件の根拠
STは，このSARの組合せがなぜ適切であると考えたかを説明する，セキュリティ要件の根拠も含んで
いる。この説明に関する特定の要件はない。この説明の目的は，STの読者がこの特定の組合せが選ばれた
理由を理解できるようにすることである。
適切でない例としては，セキュリティ課題定義が非常に高い能力の脅威エージェントに言及している一
方で，SARに含まれるセキュリティ保証要件の一つであるAVA̲VANのレベルが低い（又はAVA̲VANが
ない）が挙げられる。
A.9.4 セキュリティ要件：結論
STのセキュリティ課題定義では，セキュリティ課題は脅威，OSP及び前提条件から成り立つものと定義
される。STのセキュリティ対策方針の箇条では，解決策は二つの分割式解決策の形式で提供される。
・ TOEのセキュリティ対策方針
・ 運用環境のセキュリティ対策方針
さらに，全てのセキュリティ対策方針が達成された場合，セキュリティ課題が解決されることを示す，
セキュリティ対策方針の根拠が提供される。全ての脅威が対抗され，全てのOSPが実施され，全ての前提
条件が確認される。
53
X 5070-1：2011 (ISO/IEC 15408-1：2009)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
図A.3−セキュリティ課題定義，セキュリティ対策方針及びセキュリティ要件の間の関係
STのセキュリティ要件の箇条では，TOEのセキュリティ対策方針はSFRに書き換えられ，全てのSFR
が満たされる場合，全てのTOEのセキュリティ対策方針が達成されることを示す，セキュリティ要件の根
拠が提供される。さらに，SARの集まりは，これらのSARを選択した理由とともに，TOEがどのように
評価されるのかを示すために提供される。上記の全ての内容から，次のことがいえる。
全てのSFR及びSARを満足し，運用環境のセキュリティ対策方針全てが達成される場合，ASE̲SPDで
定義されるセキュリティ課題が解決されるという保証が得られる。すなわち，全ての脅威が対抗され，全
てのOSPが実施され，全ての前提条件が確認される。これを図A.3に示す。
得られる保証の程度はSARによって定義され，この保証の程度が十分であるかどうかは，これらのSAR
を選択した理由によって明らかにされる。
A.10
TOE要約仕様（ASE̲TSS）
TOE要約仕様の目的は，TOEがどのように全てのSFRを満たすかに関する記述をTOEの潜在的な利用
者に対して提供することである。この目的のためにTOEが使用する一般的な技術的なメカニズムを，TOE
要約仕様は提供する。潜在的な利用者がTOEの一般的な形態及び実装を理解できる程度に詳細に記述する。
例えば，TOEがインターネットに接続されたPCであり，SFRが認証を指定するセキュリティ機能要件
の一つであるFIA̲UAU.1を含んでいる場合，TOE要約仕様は，パスワード，トークン，こう（虹）彩走
査など，この認証がどのように行われるかを記述する。SFRを満たすためにTOEが使用する適用可能な標
準のような，詳しい情報を提供してもよいし，より詳細な記述を提供してもよい。
A.11
STを使用して回答できる質問
評価の後，STには“何が評価されたのか”が示される。この役割において，STは，TOEの開発者又は
販売代理業者とTOEの潜在的な利用者との間の合意のために役立つ。したがって，STは次の質問に回答
脅威
TOEの
セキュリティ
対策方針
運用環境の
セキュリティ
対策方針
前提条件
組織の
セキュリティ方針
セキュリティ
機能要件
(SFR)
セキュリティ
保証要件
(SAR)
54
X 5070-1：2011 (ISO/IEC 15408-1：2009)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
することができる。
a) 多くの既存のST及びTOEの中から，必要なST及びTOEを見つけるにはどうしたらよいか。この質
問は，数段落からなるTOEの簡潔な要約を提供する，TOE概要によって回答できる。
b) このTOEは，当方の既存のIT基盤に適合するか。この質問は，TOEを動作させるために必要とする
主要な，ハードウェア要素・ファームウェア要素・ソフトウェア要素を識別する，TOE概要によって
回答できる。
c) このTOEは，当方の既存の運用環境に適合するか。この質問は，TOEが機能するために運用環境に
配置する全ての制約を識別する，運用環境のセキュリティ対策方針によって回答できる。
d) （関心をもった読者にとって）TOEは何をするものか。この質問は，数段落からなるTOEの簡潔な
要約を提供する，TOE概要によって回答できる。
e) （潜在的な利用者にとって）TOEは何をするものか。この質問は，TOEの要約（数ページ）を提供す
る，TOE記述によって回答できる。
f)
（技術的に）TOEは何をするものか。この質問は，TOEが使用するメカニズムの高レベルな（要求仕
様レベルの）記述を提供する，TOE要約仕様によって回答できる。
g) （専門家にとって）TOEは何をするものか。この質問は，抽象的であり高度に技術的な記述を提供す
るSFRと，追加の詳細を提供するTOE要約仕様とによって回答できる。
h) 政府又は組織によって定義された課題をTOEは処理できるか。政府又は組織が，解決策を定義するた
めに，パッケージ及び／又はPPを定義している場合に，STが適合する全てのパッケージ及びPPを
記載するSTの適合主張の箇条において，回答を見つけることができる。
i)
（専門家にとって）TOEは当方のセキュリティ課題を処理できるか。TOEが対抗する脅威は何である
か。どの組織のセキュリティ方針がそれを実施するのか。運用環境に関してどのような前提条件があ
るのか。これらの質問は，セキュリティ課題定義によって回答できる。
j)
TOEはどの程度，信頼できるか。この質問は，TOEを評価するのに使用された保証レベル，つまり
TOEの正確性について評価が提供する信頼を記述した，セキュリティ要件の箇条にあるSARによっ
て回答できる。
A.12
低保証のセキュリティターゲット
STを書くことはさ（些）細な仕事ではなく，特に低保証評価では，評価全体で開発者と評価者とによっ
て費やされた総努力の大半かもしれない。このため，低保証のSTを書いてもよい。
この規格類は，EAL 1評価のための低保証のSTの使用を許すが，EAL 2以上では許さない。低保証の
STは，低保証のPP（附属書B参照）にだけ適合主張できる。全項目を含む通常の非低保証STが，低保
証のPPへの適合を主張してもよい。低保証のSTは，通常の非低保証STと比較して，次に示すように，
かなり内容が少ない。
・ セキュリティ課題定義を記述する必要はない。
・ TOEのセキュリティ対策方針を記述する必要はないが，運用環境のためのセキュリティ対策方針は記
述しなければならない。
・ STにセキュリティ課題定義がないので，セキュリティ対策方針の根拠を記述する必要はない。
・ TOEのセキュリティ対策方針がSTにないので，セキュリティ要件の根拠は，満たしていない依存関
係を正当化するだけでよい。
したがって，低保証STで書かなければならないものは次のとおりである。
55
X 5070-1：2011 (ISO/IEC 15408-1：2009)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
a) TOE及びSTへの参照。
b) 適合主張。
c) 次の叙述的記述。
1) TOE概要
2) TOE記述
3) TOE要約仕様
d) 運用環境のセキュリティ対策方針。
e) SFR，SAR（拡張したコンポーネント定義を含む。）及びセキュリティ要件根拠（満たされない依存性
がある場合だけ。）。
低保証のSTにおける，簡略化された内容を図A.4に示す。
図A.4−低保証セキュリティターゲットの内容
A.13
ST内での他の規格の参照
幾つかの場合，ST作成者は，特定の暗号規格又はプロトコルのような外部規格の参照を迫られるときが
ある。この規格類はこれを行う三つの方法を提供している。
a) 組織のセキュリティ方針（又はその一部）として行う方法。
例えば，政府規格にパスワードをどのように選択するかについての規定が存在する場合，これをST
の組織のセキュリティ方針に指定してもよい。
例えば，TOEの各利用者が各々のパスワードを選ぶ必要がある場合には，環境の対策方針に通じ，
TOEがパスワードを生成する場合には，TOEのセキュリティ対策方針，及び適切なSFR（FIAクラス）
に通じる。いずれの場合も，TOEのセキュリティ対策方針及びSFRが（又は環境の対策方針が）OSP
セキュリティターゲット
（低保証）
ST参照
TOE参照
TOE概要
TOE記述
ST概説
CC適合主張
PP主張，パッケージ主張
適合根拠
適合主張
運用環境のセキュリティ方針
セキュリティ対策方針
拡張コンポーネント定義
拡張コンポーネント定義
TOE要約仕様
TOE要約仕様
セキュリティ要件
セキュリティ機能要件
セキュリティ保証要件
セキュリティ要件根拠
56
X 5070-1：2011 (ISO/IEC 15408-1：2009)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
を満たすのに適切であることを，開発者の根拠が示す必要がある。OSPがSFRによって実装されてい
る場合，評価者は，次に示すように妥当性を検査しなければならない（そしてこのために規格を調査
する場合がある。）。
b) SFRの詳細化に使用される技術的規格（例えば，暗号の規格）として行う方法。
この場合，規格への適合はTOEによるSFRの実現の一部であり，規格の全文がSFRの一部である
かのように扱われる。したがって，この適合はSFRへの他の適合と同様に決定される。すなわち，ADV
クラス及びATEクラスによる評価中に，SFRがTOEにおいて完全かつ十分に実装されているかどう
かが，設計分析とテストとで分析される。規格の一部分だけを参照する場合，SFRの詳細化によって，
誤解が生じないようにその部分を示す。
c) TOE要約仕様で言及する技術的規格（例えば，暗号の規格）として行う方法。
TOE要約仕様はSFRがどのように実現されているかの説明として考えられるだけであって，SFR又
はADV証拠資料のようには厳密な実装要件としては使用されない。したがって，TSSが技術的規格
を参照しており，ADV証拠資料に反映されていない場合，評価者は矛盾を検出することがあるが，規
格を満たしていることを試験するための評価アクティビティはない。
57
X 5070-1：2011 (ISO/IEC 15408-1：2009)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
附属書B
（参考）
プロテクションプロファイルの仕様
B.1
この附属書の目的及び構造
この附属書の目的は，プロテクションプロファイル（PP）の概念を説明することである。この附属書で
は，APE基準の定義は行わない。APE基準の定義は，この規格類第3部にある。詳述はISO/IEC 15408-3
のE.1[3]の中に見つけることができる。
PPとSTとは非常に重複しているため，この附属書ではPPとSTとの相違点に重点を置く。STとPPと
の間で同一の事項については，附属書Aで説明する。この附属書は，次の四つの主要な部分から構成され
ている。
a) PPに記載しなければならない内容。これについては，B.2で概要を述べ，B.4からB.9まででより詳
細に説明する。これらの箇条では，PP必須の記載内容及び各内容間の相互関係について説明し，例を
示す。
b) PPの望ましい使用法。これについては，B.3で概要を示す。
c) 低保証PP。低保証PPは，PPの記載内容を減らしたPPである。これについては，B.11で詳細に説明
する。
d) 標準への適合の主張。B.12では，TOEが特定の標準を満たしていることを，PP作成者が主張する方
法について説明する。
B.2
PPの必須の内容
図B.1は，この規格類第3部に規定するPP必須記載内容を示す。図B.1はPPの構成に関する概略図と
して使用してもよいが，別の構成であってもよい。例えば，セキュリティ要件根拠が特に長くなる場合は，
セキュリティ要件の箇条の代わりに，PPの附属書にそれを記述することができる。PPの各箇条及びそれ
らの箇条における記載内容について，次に手短に述べ，B.4からB.9まででより詳細に説明する。PPには
次の事項を記述する。
a) PP概説 TOE種別の叙述的記述を含む。
b) 適合主張 PPが，いずれかのPP及び／又はパッケージへの適合を主張するかどうかを示し，適合す
る場合には，どのPP及び／又はパッケージに適合しているかを示す。
c) セキュリティ課題定義 脅威，組織のセキュリティ方針（OSP）及び前提条件を示す。
d) セキュリティ対策方針 セキュリティ課題を，TOEのセキュリティ対策方針及びTOEの運用環境に
分割した解決方法を示す。
e) 拡張コンポーネント定義 （この規格類の第2部又は第3部に含まれていない）新しいコンポーネン
トを定義することができる。これらの新しいコンポーネントは，拡張機能要件及び拡張保証要件を定
義するために必要とされる。
f)
セキュリティ要件 TOEのセキュリティ対策方針から規格化された表現への書き換えたものを示す。
この規格化された表現は，SFRの形式をとる。また，B.2ではSARを定義する。
PPの記載内容を減らした低保証PPも存在する。これについては，B.11で詳細に説明する。この例外を
除いて，B.1からB.12までは，上記の全項目を含むPPを想定している。
58
X 5070-1：2011 (ISO/IEC 15408-1：2009)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
図B.1−プロテクションプロファイルの内容
B.3
PPの使用
B.3.1 望ましいPPの使用法
一般に，PPは利用者コミュニティ，行政機関，又は開発者グループによって必要とされるセキュリティ
の共通セットを定義する文書である。PPは，このセットを参照する手段を利用者に提供し，このような必
要性を背景とする将来の評価を容易にする。したがって，PPは一般に次のものとして使用される。
a) 特定の利用者又は利用者グループに対する要件仕様の一部。この利用者又は利用者グループは，PPを
満たしている場合にだけ特定の種別のIT製品の購入を検討する。
b) 特定の行政機関による規制の一部。この行政機関は，PPを満たしている場合にだけ特定の種別のIT
製品の使用を許可する。
c) IT製品開発者のグループによって定義される基準レベル。この開発者グループは，生産するこの種別
の全てのIT製品がこの基準レベルを満たすことに合意する。
上記の例はその他の用途を排除するものではない。
B.3.2 望ましくないPPの使用法
（PPの多くの役割の中から）PPが果たさない方がよい三つの役割を次に示す。
a) 詳細な仕様：PPは，比較的抽象レベルの高いセキュリティ仕様を記述する。一般に，PPには詳細な
プロトコル仕様，詳細なアルゴリズム及び／又は機構の詳細な説明，詳細にわたる運用についての長
い説明などを含まないほうがよい。
PP参照
TOE概要
PP概説
プロテクションプロファイル
CC 適合主張
PP主張，パッケージ主張
適合根拠
適合記述
適合主張
脅威
組織のセキュリティ方針
前提条件
セキュリティ課題定義
TOEのセキュリティ対策方針
運用環境のセキュリティ対策方針
セキュリティ対策方針根拠
セキュリティ対策方針
拡張コンポーネント定義
拡張コンポーネント定義
セキュリティ機能要件
セキュリティ保証要件
セキュリティ要件根拠
セキュリティ要件
59
X 5070-1：2011 (ISO/IEC 15408-1：2009)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
b) 完全な仕様：PPは，セキュリティ仕様を記述したものであって，全体の仕様ではない。セキュリティ
に関係する場合を除いて，相互運用性，物理的な寸法及び重さ，定格電圧などの特性は，PPの一部分
でない方がよい。これは一般に，PPはそれ自体が完全な仕様ではなく，完全な仕様の一部分であって
も差し支えないということを意味する。
c) 単一製品の仕様：STとは異なり，PPは単一の製品ではなく，IT製品の特定の種別について記述する
ことを目的とする。単一の製品だけが目的の場合は，STを使用することが望ましい。
B.4
PP概説（APE̲INT）
PP概説では，次の二つの抽象レベルについて叙述的な方法でTOEを説明する。
a) PP参照。PPの識別情報を提供する。
b) TOE概要。TOEを簡潔に説明する。
B.4.1 PP参照
PPは，特定のPPを指し示す明確なPP参照を含む。典型的なPP参照は，名称，バージョン，作成者及
び発行日から構成される。“Atlantean Navy CablePhone Encryptor PP，バージョン2b，アトラス海軍調達局，
2003年4月7日”は，PP参照の記述例である。参照は，異なるPP間及び同じPPの異なるバージョン間
で区別できるように，一意にしなければならない。
PP参照は，PPに索引を付け，これらを参照すること及びPPのリストにこれらを組み込むことを容易に
する。
B.4.2 TOE概要
TOE概要は，セキュリティの必要性を満たし，自らが使用するハードウェア，ソフトウェア及びファー
ムウェアで稼動するTOEを見つけるために，評価済み製品のリストを調べようとする，TOEの潜在的な
利用者のためのものである。
TOE概要は，TOEの設計又は既存製品の改造でPPを使用することがある開発者も対象としている。
TOE概要の一般的な長さは，数段落である。このため，TOE概要では，TOEの使用方法及びその主要
なセキュリティ機能の特徴について簡潔に説明し，TOEの種別及びTOEが必要とするTOE以外の主要な
ハードウェア，ソフトウェア及びファームウェアが何であるかを示す。
B.4.2.1 TOEの使用方法及び主要なセキュリティの特徴
TOEの使用方法及び主要なセキュリティの特徴に関する記述は，TOEが備えるべき機能及びTOEの用
途についてごく一般的な知識を与えることを目的とする。この箇条は，（潜在的な）TOE利用者のために，
業務運用の点から，TOEの使用方法及び主要なセキュリティの特徴について，TOE利用者が分かる表現を
使用して記述するのが望ましい。この記述例を次に示す。
“Atlantean Navy CablePhone Encryptor”は，Atlantean Navy CablePhoneシステムを通じて船舶間で秘密情
報の通信を実現すべき暗号化デバイスである。このため，最低32人の利用者及び最低100 Mb/sの暗号化
速度をサポートするのが望ましい。これは，船舶間の相互通信及びネットワーク全体のブロードキャスト
の両方を実現するのが望ましい。
B.4.2.2 TOE種別
TOE概要では，ファイアウォール，VPNファイアウォール，スマートカード，暗号化モデム，イントラ
ネット，ウェブサーバ，データベース，ウェブサーバ及びデータベース，LAN，ウェブサーバ及びデータ
ベースを伴うLANなどの，TOEの一般的な種別を示す。
60
X 5070-1：2011 (ISO/IEC 15408-1：2009)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
B.4.2.3 必要とするTOE以外のハードウェア，ソフトウェア及び／又はファームウェア
他のITに依存しないTOEもあるが，多くのTOE（特にソフトウェアTOE）は，TOE以外の追加のハー
ドウェア，ソフトウェア及び／又はファームウェアに依存する。後者の場合，TOE概要は，TOE以外のハ
ードウェア，ソフトウェア及び／又はファームウェアを識別する必要がある。
プロテクションプロファイルは特定の製品について記述されるものではないため，多くの場合，必要と
するハードウェア，ソフトウェア及び／又はファームウェアについて一般的な考え方だけを示すことがで
きる。一部の場合，例えば，プラットフォームが既に確認されている特定の顧客向けの要件仕様などの場
合，（はるかに）多くの具体的な情報が提供されることがある。
ハードウェア，ソフトウェア及び／又はファームウェア識別の例を次に示す。
・ なし（完全なスタンドアロンTOE）。
・ 汎用PCで動作しているYaiza 3.0オペレーティングシステム。
・ CleverCard SB2067集積回路。
・ QuickOSスマートカードオペレーティングシステムのバージョン2.0を実行するCleverCard SB2067回
路。
・ 20xx年xx月に設置予定の省庁LAN。
B.5
適合主張（APE̲CCL）
B.5では，PPが他のPP及びパッケージとどのように適合するかを記述する。これは，適合記述だけを
除いて，STの適合主張のA.5と同じである。
PPの適合記述では，ST及び／又はその他のPPがそのPPにどのように適合しなければならないかを示
す。PP作成者は，“正確”適合又は“例証”適合のいずれを要求するかを選択する。これに関するより詳
細については，附属書Dを参照。
B.6
セキュリティ課題定義（APE̲SPD）
B.6は，STのセキュリティ課題定義のA.6と同じである。
B.7
セキュリティ対策方針（APE̲OBJ）
B.7は，STのセキュリティ対策方針のA.7と同じである。
B.8
拡張コンポーネント定義（APE̲ECD）
B.8は，STの拡張コンポーネントのA.8と同じである。
B.9
セキュリティ要件（APE̲REQ）
B.9は， STのセキュリティ要件のA.9と同じである。ただし，PPにおいて操作を完了する際の規則は，
STにおいて操作を完了する際の規則とはやや異なっている点に注意する。これについては，7.1でより詳
細に説明する。
B.10 TOE要約仕様
PPには，TOE要約仕様は含まれない。
61
X 5070-1：2011 (ISO/IEC 15408-1：2009)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
B.11 低保証プロテクションプロファイル
通常のPP（すなわち，全ての内容を含むPP）に対する低保証PPの関係は，通常のSTに対する低保証
STの関係と同じである。つまり，低保証PPは，次の内容から構成される。
a) PP概説。PP参照及びTOE概要から構成される。
b) 適合主張。
c) 運用環境のセキュリティ対策方針。
d) SFR及びSAR（拡張コンポーネント定義を含む。）及びセキュリティ要件根拠（依存性が満たされて
いない場合だけ。）。
低保証PPは，低保証PPへの適合だけを主張することができる（B.5を参照）。非低保証PPは，低保証
PPへの適合を主張することができる。低保証PPの簡略化された内容を図B.2に示す。
図B.2−低保証プロテクションプロファイルの内容
B.12 PPでの他の標準の参照
B.12は，STの標準に関するA.13と同じである。ただし，PPにはTOE要約仕様がないので，A.13 c) は
除く。
SFRの中で規格を参照することが，（その規格の規模及び複雑さと，要求される保証レベルによっては）
PPを満たすTOEを開発している開発者に大きな負担をかける可能性があり，規格への適合を評価するた
めの代替的な（この規格類に関連しない）方法を採用することが適切な場合があることに，PP作成者は留
意する。
PP参照
TOE概要
PP概説
プロテクションプロファイル
（低保証）
CC 適合主張
PP主張，パッケージ主張
適合根拠
適合記述
適合主張
拡張コンポーネント定義
拡張コンポーネント定義
セキュリティ機能要件
セキュリティ保証要件
セキュリティ要件根拠
セキュリティ要件
運用環境のセキュリティ対策方針
セキュリティ対策方針
62
X 5070-1：2011 (ISO/IEC 15408-1：2009)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
附属書C
（参考）
操作の指針
C.1 はじめに
この規格で示すようにプロテクションプロファイル及びセキュリティターゲットは定義済みセキュリテ
ィ要件を含むとともに，PP作成者及びST作成者にある状況でコンポーネントを拡張する能力を与える。
C.2 操作の例
7.1では4種類の操作について示した。これら操作の例を次に示す。
C.2.1 繰返し操作
7.1.1で示したように，繰返し操作は全てのコンポーネントに対して行える。PP作成者及びST作成者は，
同じコンポーネントに複数の要件を含めることで繰返し操作を実行できる。繰返しを行った各々のコンポ
ーネントは，繰返しを行った他のどのコンポーネントとも異なる。これは，異なる方法で割付けと選択と
を行ったり，異なる方法で詳細化を行っているからである。異なる繰返しは，これらのセキュリティ要件
への／からの理由付け及び遡りが容易になるように，一意に特定できるのが望ましい。この典型例として，
二つの異なる暗号アルゴリズムを実装するために2回繰返しを行ったFCS̲COP.1 の例を挙げることがで
きる。各々の繰返しを一意に特定できる例として，次のものがある。
・ 暗号操作（RSA及びDSA 署名）[FCS̲COP.1(1)]
・ 暗号操作［TLS/SSL：対称鍵操作］[FCS̲COP.1(2)]
C.2.2 割付け操作
7.1.2で示したように，割付け操作は当該コンポーネントのパラメタ付きエレメントをPP作成者及びST
作成者がパラメタを決定する場合に行われる。そのパラメタは，制限のない変数であるか，又はその変数
を特定範囲の値に狭めたものであってもよい。
エレメントへの割付け操作例として，次のものがある。
FIA̲AFL.1.2“不成功の認証回数が既定値に達するかそれを超えた場合，TSFは［割付け：アクションの
リスト］をしなければならない。”
C.2.3 選択操作
7.1.3で示したように，選択操作は，当該コンポーネントが複数の選択肢を含み，PP作成者及びST作成
者によって選択される場合に行われる。
選択の例として，次のものがある。
FPT̲TST.1.1“TSFは，正常動作を実証するために，［選択：初期立上げ中，通常運用中に定期的に，権
限をもった利用者の要求時に，及び条件（割付け：自己テストが作動すべき条件）のときに］自己テスト
一式を実行しなければならない。”
C.2.4 詳細化操作
7.1.4で示したように，詳細化操作は，全ての要件で行われる。PP作成者及びST作成者は当該要件を書
き換えることで詳細化を行う。
詳細化の例として，次のような書換えがある。
FIA̲UAU.2.1“TSFは，その利用者を代行する他のTSF仲介アクションを許可する前に，各利用者に認
63
X 5070-1：2011 (ISO/IEC 15408-1：2009)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
証が成功することを要求しなければならない。”を次のようにする。
FIA̲UAU.2.1“TSFは，その利用者を代行する他のTSF仲介アクションを許可する前に，各利用者にユ
ーザ名とパスワードとによる認証が成功することを要求しなければならない。”
PP作成者及びST作成者に許されるこの規則の唯一の例外は，SFRを全てではなく一部のサブジェクト，
オブジェクト，操作，セキュリティ属性，及び／又は外部エンティティに適用することである。このよう
な具体例としては，次のものがある。
FIA̲UAU.2.1“TSFは，その利用者を代行する他のTSF仲介アクションを許可する前に，各利用者に認
証が成功することを要求しなければならない。”を次のようにする。
FIA̲UAU.2.1“TSFは，その利用者を代行する他のTSF仲介アクションを許可する前に，インターネッ
トからの各利用者に認証が成功することを要求しなければならない。”
第2に実施される詳細化規則は，基となるコンポーネントの範囲に収まっていなければならないことで
ある。例えば，監査要件コンポーネントに漏えい（洩）電磁波防止のための特別な要素を追加して詳細化
することは許されない。
特殊な詳細化として編集上の詳細化があり，要件の小修整，すなわち言語の文法を順守するため，読者
により分かりやすくするため，行われることがある。この小修整で要件の意味を変更してはならない。編
集上の詳細化として次のようなものがある。
FPT̲FLS.1.1“TSFは，次の種別の障害が生じたときはセキュアな状態を保持しなければならない：CPU
故障。”を次のようにする。
FPT̲FLS.1.1“TSFは，次の種別の障害が生じたときはセキュアな状態を保持しなければならない：1CPU
の故障。”，又は更に，次のようにする。
FPT̲FLS.1.1“TSFは，一つのCPUに障害が生じたときにセキュアな状態を保持しなければならない。”
C.3 コンポーネントの構成
この規格類は，この規格類の第2部及び第3部にあるコンポーネントを次に示す階層構造としている。
・ クラス これは次のものからなる。
・ ファミリ これは次のものからなる。
・ コンポーネント これは次のものからなる。
・ エレメント
この，クラス，ファミリ，コンポーネント，及びエレメントへの階層構造は，消費者，開発者及び評価
者が目当てのコンポーネントを見つける手助けとなる。この規格類は，機能コンポーネント及び保証コン
ポーネントに同じ階層構造形態を採用し，同じ構成と用語とを用いている。
C.3.1 クラス
クラスの例としてFIAクラスがあるが，これは利用者の識別，利用者の認証，利用者及びサブジェクト
の結合に焦点を当てている。
C.3.2 ファミリ
ファミリの例として FIAクラスに属する利用者の認証（FIA̲UAU）がある。このファミリは利用者の
認証を専門とする。
C.3.3 コンポーネント
コンポーネントの例として 偽造されない認証（FIA̲UAU.3）があり，偽造されない利用者の認証を専
門とする。
64
X 5070-1：2011 (ISO/IEC 15408-1：2009)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
C.3.4 エレメント
エレメントの例として FIA̲UAU.3.2があり，複写した認証データの阻止を専門とする。
C.4 拡張コンポーネント
C.4.1 拡張コンポーネントの定義方法
PP作成者及びST作成者が拡張コンポーネントを定義するとき，同規格類の既存のコンポーネントと同
様に定義しなければならない。明瞭，曖昧でなく，評価可能（これは当該コンポーネントに立脚する要件
がTOEに対して体系的に例証可能であること）でなければならない。拡張コンポーネントは同規格類の既
存のコンポーネントと同様の命名法，表現法，及び詳細度でなければならない。
PP作成者及びST作成者は拡張コンポーネントを定義するとき，適用する依存性を含めることを忘れて
はならない。
起こり得る依存性の例として，次に示す。
a) 拡張コンポーネントが監査を参照する場合，FAUクラスへの依存性を含めなければならない。
b) 拡張コンポーネントがデータにアクセスしたり，データを改変したりする場合，FDP̲ACCファミリ
への依存性を含まなければならない。
c) 拡張コンポーネントが特殊な設計記述を含む場合，それにふさわしいADVファミリ（例えば，機能
仕様）への依存性を含まなければならない。
拡張機能コンポーネントの場合，PP作成者及びST作成者は，この規格類第2部の既存コンポーネント
と同様に，適用可能な監査と関連操作の情報とをそのコンポーネントの定義に含めなければならない。拡
張保証コンポーネントの場合，PP作成者及びST作成者は，ISO/IEC 18045で提供される手法と同様の当
該コンポーネントを評価する手法を提供しなければならない。
拡張コンポーネントを，既存のファミリに増設してもよいがその場合，PP作成者及びST作成者は増設
に使われたファミリがどのように変更されたかを記述しなければならない。そのとき，それらのコンポー
ネントが既存のファミリになじまない場合，新規ファミリを作ってその中に収めなければならない。新規
ファミリはこの規格類の既存のファミリと同じように定義しなければならない。
65
X 5070-1：2011 (ISO/IEC 15408-1：2009)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
附属書D
（参考）
PP適合
D.1 はじめに
PPはSTへのひな形として使うよう意図されている。つまり，PPは利用者の要求を記述し，そのPPに
適合するSTはPPで記述される要求を満たすTOEを記述する。PPは他のPPへのひな形として使用する
ことも可能であることに注意されたい。これは，STとPPとの関係に酷似している。この附属書はST/PP
関係だけを記述するが，PP/PP関係に対しても適用可能である。
この規格類は，いかなる部分適合も許可しない。したがって，例えばPP適合を主張する場合，PP又は
STは，参照する単一のPP又は複数のPPに完全に適合していなければならない。しかし，適合には2種
類（“正確”適合及び“例証”適合）あり，許可される適合のタイプをPPに記述する。すなわち，PPは，
STへのPP適合の許可されるタイプについて記述する（PPの適合記述に示す。B.5を参照。）。STがPP例
証適合を主張できるのは，PP適合を明示的に記述している場合で，それに対し，STは，どのPPに対して
も正確適合しているといってよい。STが適合を主張するPPに対して，正確適合と例証適合とを区別して
適用できる。つまり，STはあるPP群に正確適合し，他のPP群に例証適合することがある。言い換える
と，PPが明示的に例証適合を許しているなら，STはその場合に限りPPに例証適合しているといえる。
あるPPへの適合は，適合を主張するPP又はSTが（そして，もしSTが評価完了した製品のものであ
るならばその製品も）当該PPの要件を全て満たすことを意味する。
公開されるPPは，通常，例証適合を要求する。これはPPに適合を主張するSTはPPに記述される一般
的なセキュリティ課題に対する解を提供しなければならないことを意味するが，PPの記述と同等か又は制
限をかけたいかなる方法でもよい。この規格類での“同等か制限をかけた”という用語の定義は長くなる
が，原則論では，STがPPと同等以上の制約をTOEに課し，TOEの運用環境にはPPと同等以下の制約で
済ませることができるなら，たとえPP及びSTが全く異なるエンティティについて異なる記述を議論し，
異なる概念を使用していようと，容認されることである。
D.2 正確適合
正確適合は，PPの要件が満たされていること及びSTがPPの実装となっていることの証拠を求めるPP
作成者のためのものである（STは，PPの要件より広がる。）。要するに，STには，PPと同等以上にTOE
が行うことを規定し，PPと同等以下に運用環境が行うことを規定する。
正確適合の典型的な使用法は，製品のセキュリティ要件がPPで既定されるとおりに正確に一致するも
のから調達を行うことである。
PPに正確適合するSTの例証化では，PPに記載されている制約に更に制約を追加してもよい。
D.3 例証適合
例証適合は，STがPPで記述される一般セキュリティ問題への適した解決となっていることの証拠を求
めるPP作成者に向けられたものである。正確適合ではPPとSTとの間には明確な包含関係があるが，例
証適合の場合，その関係はそれほどはっきりしない。一般的な表現をすれば，STはPPと同等か，より限
定的となっていなければならない。
66
X 5070-1：2011 (ISO/IEC 15408-1：2009)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
附属書JA
（参考）
ISO/IEC 15408-2 Part 2: Security functional components
第2部：セキュリティ機能コンポーネント
1
適用範囲
この規格類第2部は，セキュリティ評価の実施に必要なセキュリティ機能コンポーネントを規定してい
る。そして，多くのIT製品に共通なセキュリティ機能要件を満足する機能コンポーネントのカタログを記
述している。
2
引用規格
ISO/IEC 15408-2:2008の2（Normative reference）による。
3
定義及び用語
ISO/IEC 15408-2:2008の3（Terms and definitions，symbols and abbreviated terms）による。
4
概要
ISO/IEC 15408-2:2008の4（Overview）による。
5
機能要件の枠組み
ISO/IEC 15408-2:2008の5（Functional requirements paradigm）による。
6
セキュリティ機能コンポーネント
ISO/IEC 15408-2:2008の6（Security functional components）による。
7
クラスFAU：セキュリティ監査
ISO/IEC 15408-2:2008の7（Class FAU:Security audit）による。
8
クラスFCO：通信
ISO/IEC 15408-2:2008の8（Class FCO:Communication）による。
9
クラスFCS：暗号支援
ISO/IEC 15408-2:2008の9（Class FCS:Cryptographic support）による。
10 クラスFDP：利用者データの保護
ISO/IEC 15408-2:2008の10（Class FDP:User data protection）による。
11 クラスFIA：識別及び認証
ISO/IEC 15408-2:2008の11（Class FIA:Identification and authentication）による。
67
X 5070-1：2011 (ISO/IEC 15408-1：2009)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
12 クラスFMT：セキュリティ管理
ISO/IEC 15408-2:2008の12（Class FMT:Security management）による。
13 クラスFPR：プライバシ
ISO/IEC 15408-2:2008の13（Class FPR:Privacy）による。
14 クラスFPT：評価対象のセキュリティ機能保護
ISO/IEC 15408-2:2008の14（Class FPT:Protection of the TSF）による。
15 クラスFRU：資源利用
ISO/IEC 15408-2:2008の15（Class FRU:Resource utilisation）による。
16 クラスFTA：評価対象へのアクセス
ISO/IEC 15408-2:2008の16（Class FTA:TOE access）による。
17 クラスFTP：高信頼パス及びチャネル
ISO/IEC 15408-2:2008の17（Class FTP:Trusted path/channels）による。
附属書A（規定）セキュリティ機能要件アプリケーションに関する備考
ISO/IEC 15408-2:2008のAnnex A (normative) Security functional requirements application notes による。
附属書B（規定）機能クラス，ファミリ及びコンポーネント
ISO/IEC 15408-2:2008のAnnex B (normative) Functional classes, families, and components による。
附属書C（規定）クラスFAU：セキュリティ監査
ISO/IEC 15408-2:2008のAnnex C (normative) Class FAU: Security audit による。
附属書D（規定）クラスFCO：通信
ISO/IEC 15408-2:2008のAnnex D (normative) Class FCO: Communication による。
附属書E（規定）クラスFCS：暗号支援
ISO/IEC 15408-2:2008のAnnex E (normative) Class FCS: Cryptographic support による。
附属書F（規定）クラスFDP：利用者データの保護
ISO/IEC 15408-2:2008のAnnex F (normative) Class FDP: User data protection による。
附属書G（規定）クラスFIA：識別及び認証
ISO/IEC 15408-2:2008のAnnex G (normative) Class FIA:Identification and authentication による。
68
X 5070-1：2011 (ISO/IEC 15408-1：2009)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
附属書H（規定）クラスFMT：セキュリティ管理
ISO/IEC 15408-2:2008のAnnex H (normative) Class FMT: Security management による。
附属書I（規定）クラスFPR：プライバシ
ISO/IEC 15408-2:2008のAnnex I (normative) Class FPR:Privacyによる。
附属書J（規定）クラスFPT：評価対象のセキュリティ機能保護
ISO/IEC 15408-2:2008のAnnex J (normative) Class FPT: Protection of the TSF による。
附属書K（規定）クラスFRU：資源利用
ISO/IEC 15408-2:2008のAnnex K (normative) Class FRU:Resource utilisation による。
附属書L（規定）クラスFTA：評価対象へのアクセス
ISO/IEC 15408-2:2008のAnnex L (normative) Class FTA: TOE access による。
附属書M（規定）クラスFTP：高信頼パス及びチャネル
ISO/IEC 15408-2:2008のAnnex M (normative) Class FTP: Trusted path/channels による。
69
X 5070-1：2011 (ISO/IEC 15408-1：2009)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
附属書 JB
（参考）
ISO/IEC 15408-3 Part 3: Security assurance components
第3部：セキュリティ保証コンポーネント
1
適用範囲
この規格類第3部は，保証要件を規定している。それは，コンポーネントTOEの保証程度を判定するた
めの尺度を定義する評価保証レベル（EAL）を規定し，統合TOEの保証程度を判定するための尺度を定義
する統合された保証パッケージ（CAP）を規定し，保証レベル及びパッケージから構成する個々の保証コ
ンポーネントを規定し，更に，PP又はSTを評価する基準を規定している。
2
引用規格
ISO/IEC 15408-3:2008の2（Normative reference）による。
3
定義及び用語
ISO/IEC 15408-3:2008の3（Terms and definitions，symbols and abbreviated terms）による。
4
規格の概要
ISO/IEC 15408-3:2008の4（Overview）による。
5
規格の枠組み
ISO/IEC 15408-3:2008の5（Assurance paradigm）による。
6
セキュリティ保証コンポーネント
ISO/IEC 15408-3:2008の6（Security assurance components）による。
7
評価保証レベル
ISO/IEC 15408-3:2008の7（Evaluation assurance levels）による。
8
統合保証のパッケージ
ISO/IEC 15408-3:2008の8（Composed assurance packages）による。
9
プロテクションプロファイルの評価
ISO/IEC 15408-3:2008の9（Class APE: Protection Profile evaluation）による。
10 セキュリティターゲットの評価
ISO/IEC 15408-3:2008の10（Class ASE: Security Target evaluation）による。
70
X 5070-1：2011 (ISO/IEC 15408-1：2009)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
11 開発
ISO/IEC 15408-3:2008の11（Class ADV: Development）による。
12 ガイダンス
ISO/IEC 15408-3:2008の12（Class AGD: Guidance documents）による。
13 ライフサイクル サポート
ISO/IEC 15408-3:2008の13（Class ALC : Life-cycle support）による。
14 テスト
ISO/IEC 15408-3:2008の14（Class ATE: Tests）による。
15 ぜい弱性評定
ISO/IEC 15408-3:2008の15（Class AVA: Vulnerability assessment）による。
16 統合
ISO/IEC 15408-3:2008の16（Class ACO: Composition）による。
附属書A（参考）開発（ADV）
ISO/IEC 15408-3:2008のAnnex A (informative) Development (ADV) による。
附属書B（参考）統合（ACO）
ISO/IEC 15408-3:2008のAnnex B (informative) Composition (ACO) による。
附属書C（参考）保証コンポーネントの依存の相互参照
ISO/IEC 15408-3:2008のAnnex C (informative) Cross reference of assurance components dependenciesによ
る。
附属書D（参考）PPと保証コンポーネントとの相互参照
ISO/IEC 15408-3:2008のAnnex D (informative) Cross reference of PPs and assurance componentsによる。
附属書E（参考）EALと保証コンポーネントとの相互参照
ISO/IEC 15408-3:2008のAnnex E (informative) Cross reference of EALs and assurance componentsによる。
附属書F（参考）CAPと保証コンポーネントとの相互参照
ISO/IEC 15408-3:2008のAnnex F (informative) Cross reference of CAPs and assurance componentsによる。
71
X 5070-1：2011 (ISO/IEC 15408-1：2009)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
参考文献
この規格類の利用者にとって有用と思われる規格・資料を集めたものである。出版年を示していない文
献については，最新の版を参照することが望ましい。
ISO/IEC規格
[1] JIS Q 27001 情報技術−セキュリティ技術−情報セキュリティマネジメントシステム−要求事項
注記 対応国際規格：ISO/IEC 27001，Information technology−Security techniques−Information
security management systems−Requirements（IDT）
[2] JIS Q 27002 情報技術−セキュリティ技術−情報セキュリティマネジメントの実践のための規範
注記 対応国際規格：ISO/IEC 27002，Information technology−Security techniques−Code of practice for
information security management（IDT）
[3] JIS X 19790 セキュリティ技術−暗号モジュールのセキュリティ要求事項
注記 対応国際規格：ISO/IEC 19790，Information technology−Security techniques−Security
requirements for cryptographic modules（IDT）
[4] ISO/IEC 15292，Information technology−Security techniques−Protection Profile registration procedures
[5] ISO/IEC TR 15443 (all parts)，Information technology−Security techniques−A framework for IT security
assurance
[6] ISO/IEC TR 15446，Information technology−Security techniques−Guide for the production of Protection
Profiles and Security Targets
[7] ISO/IEC TR 19791，Information technology−Security techniques−Security assessment of operational
systems
その他の規格
[8] IEEE Std 610.12-1990，Institute of Electrical and Electronics Engineers, Standard Glossary of Software
Engineering Terminology
[9] CCRA, Common Criteria portal, February 2009
http://www.commoncriteriaportal.org