← 一覧に戻る ↓ このページの最下段に移る

JIS X 5070-1：2011
セキュリティ技術―情報技術セキュリティの評価基準―第1部：総則及び一般モデル 2011改正●2000制定

番号 用語 定義 対応英語
3.1.1 敵対的な動作 脅威エージェントが資産に行う動作。 adverse actions
3.1.2 資産 TOEの所有者が一般に価値を認めるもの。 assets
3.1.3 割付け この規格におけるコンポーネント内又は要件内の識別されたパラメタを規定すること。 assignment
3.1.4 保証 TOEがSFRを満たしていることへの信頼の基盤。 assurance
3.1.5 攻撃能力 TOEへの攻撃に攻撃者が費やすことができる労力の尺度であって，攻撃者の技能，資源及び動機の観点から表現されるもの。 attack potential
3.1.6 要件追加 パッケージへの一つ以上の要件の追加。 augmentation
3.1.7 認証データ 利用者の認証に用いられる情報。 authentication data
3.1.8 正当な利用者 SFRに従って，操作を実行することができるTOE利用者。 authorised user
3.1.9 クラス 共通の目的をもつファミリの集合。 class
3.1.10 理路整然とした 論理的順序で並べられ，識別できる意味をもつ(連体修飾)。注記　証拠資料の場合は，文書内容及び文書構造の両方が，対象読者にとって理解できるものであることを意味する。 coherent
3.1.11 完全な エンティティの全ての必要な部分が提供されている(連体修飾)。注記　証拠資料の場合は，抽象化のレベルにおいてこれ以上の説明が必要ない詳細レベルで，全ての関連する情報が証拠資料において扱われていることを意味する。 complete
3.1.12 コンポーネント 要件を構成する最小の選択可能なエレメントのセット。 component
3.1.13 統合保証パッケージ この規格類第3部(主にACOクラス)から抽出された要件からなる，定義済み統合保証尺度での程度を表す保証パッケージ。 composed assurance package
3.1.14 確認する 詳細にレビューし，充足性を第三者として示す。注記　必要とされる厳格性のレベルは，内容によって異なる。この用語は，評価者アクションだけに適用される。 confirm
3.1.15 接続性 TOEと外部のITエンティティとの対話を可能にするTOEの特性。注記　接続性には，任意の環境又は構成において任意の距離を介して，有線手段又は無線手段によって行われるデータ交換が含まれる。 connectivity
3.1.16 一貫した 複数のエンティティ間に明らかな矛盾が存在しない(連体修飾)。 consistent
3.1.17 対抗する 特定の脅威の影響を緩和する。脅威の影響を完全になくす必要はない。 counter
3.1.18 例証適合 PPにおける一般的なセキュリティ課題の解決方法をSTが提供するというSTとPPとの関係。注記　PP及びSTは，異なるエンティティについて全く異なる記述を含み，異なる概念などを使用することができる。例証適合は，複数の同様のPPが既に存在するTOEの種別にも適している。これによって，ST作成者はこれらのPPに対する適合を同時に主張し，作業量を減らすことができる。 demonstrable conformance
3.1.19 例証する 分析によって得られる結果を提供する。この結果は“証明(proof)”ほど厳格ではない。 demonstrate
3.1.20 依存性 依存するコンポーネントに基づく要件がPP，ST又はパッケージに含まれる場合，一般に，依存されるコンポーネントに基づく要件もそのPP，ST又はパッケージに含まれなければならない，というコンポーネント間の関係。 dependency
3.1.21 記述する エンティティの一定の詳細を提供する。 describe
3.1.22 決定する 独立に分析し，一定の結論に到達する。注記　この用語は，通常，これまでの分析を考慮しない，真に独立した分析を意味する。レビューする必要のある分析が既に行われていることを意味する用語である“確認する(confirm)”又は“検証する(verify)”と対比される。 determine
3.1.23 開発環境 TOEが開発される環境。 development environment
3.1.24 エレメント セキュリティ上必要な事項の，最小単位の記述。 element
3.1.25 確実にする アクション(開発者アクション及び評価者アクション)が結果をもたらすことを保証する。注記　この用語が“助ける(help)”などとともに用いられる場合は，結果が，そのアクションだけでは完全には確実でないことを示す。 ensure
3.1.26 評価 定義された基準に基づき，PP，ST又はTOEを評定すること。 evaluation
3.1.27 評価保証レベル この規格類第3部から抽出された保証要件の集合で，定義済み保証尺度での程度を表し，保証パッケージを構成するもの。 evaluation assurance level
3.1.28 評価機関 特定のコミュニティにおいて，評価制度に基づきこの規格類を適用し，標準を定め，評価の品質を監視する機関。 evaluation authority
3.1.29 評価制度 評価機関が特定のコミュニティにおいて，この規格類を適用するときの管理及び規制の枠組み。注記　我が国における評価制度の名称は，“ITセキュリティ評価及び認証制度”である。 evaluation scheme
3.1.30 徹底的な 曖昧さを排除した計画に従って分析又は他の活動を行う，方法論的に整備されたアプローチ(運体修飾)。注記　この用語は，分析などの活動を実施するときに用い，“系統的な”よりもかなり強い意味で用いる。明快な計画に従って分析又は他の活動を行うときに系統的なアプローチを選択したことだけでなく，活動に使われる計画そのものが全ての可能性を尽くすことを保証するのに十分である。 exhaustive
3.1.31 説明する 行った活動の理由を示す。注記　問われた場合，“行った活動が必然的に最適であった”という議論を試みることをせずに，“なぜ？”という問いへの答えを意図している。この用語は，“記述する(describe)”及び“例証する(demonstrate)”とは異なる。 explain
3.1.32 拡張 この規格類第2部に含まれていない機能要件及び/又はこの規格類第3部に含まれていない保証要件をST又はPPに追加すること。 extension
3.1.33 外部エンティティ TOE境界の外からTOEと交信する可能性がある人エンティティ又はITエンティティ。 external entity
3.1.34 ファミリ 類似する目標をもつが，着眼点又は厳密さが異なるコンポーネントの集合。 family
3.1.35 形式的●形式的な 確立した数学上の概念に基づいて，意味が定義された制限付き構文言語で表現されている(連体修飾)。 formal
3.1.36 ガイダンス文書 TOEの配付，立上げ，操作，管理及び/又は使用法について記述した文書。 guidance documentation
3.1.37 識別情報 TOEの文脈内のエンティティ(利用者，プロセス，ディスクなど)を一意に識別する表現。注記　このような表現の例は文字列である。利用者が人間の場合，表現は利用者の氏名若しくは略称，又は(一意に識別化の可能な)擬似名であってもよい。 identity
3.1.38 非形式的●非形式的な 自然言語で表現されている(連体修飾)。 informal
3.1.39 TSF間転送 TOEと他の信頼できるIT製品のセキュリティ機能との間でデータを通信すること。 inter TSF transfers
3.1.40 内部通信チャネル TOE内部の別々の部分間のチャネル。 internal communication channel
3.1.41 TOE内転送 TOE内部の別々の部分でデータを通信すること。 internal TOE transfer
3.1.42 内部的に一貫した エンティティのどの側面の間にも明らかな矛盾がない(連体修飾)。注記　証拠資料のどの2か所をつき合わせても矛盾していると解釈できる部分がないことを意味する。 internally consistent
3.1.43 繰返し 二つ以上の異なる要件を表現するのに同一コンポーネントを使用すること。 iteration
3.1.44 正当化 決定を導く分析。注記　正当な例証より厳密である。この語は注意深く徹底的に論理的に一つ一つ確認していくという意味で格段の厳密性を要する。 justification
3.1.45 オブジェクト 情報を保持したり受け取ったりするTOE内の受動的なもので，サブジェクトが行う操作の対象となるエンティティ。 object
3.1.46 操作(JIS X 5070のコンポーネントに対する) コンポーネントを修正したり繰り返したりすること。注記　コンポーネントに許される操作は，割付け，繰返し，詳細化及び選択である。 operation (on a component of JIS X 5070)
3.1.47 操作(オブジェクトに対する) オブジェクトに対してサブジェクトが行える，特定の種類のアクション。 operation (on an object)
3.1.48 運用環境 TOEを運用する環境。 operational environment
3.1.49 組織のセキュリティ方針 組織のためのセキュリティ規則，手順又は指針の集まり。注記　セキュリティ方針は，特定の運用環境だけに対応することもある。 organizational security policy
3.1.50 パッケージ 名前の付いた機能要件又は保証要件の集合。注記　パッケージの例に“EAL3”がある。 package
3.1.51 PP評価 定義済みの評価基準を用いてPPを評定すること。 PP evaluation
3.1.52 プロテクションプロファイル●セキュリティ要求仕様書 ある種別のTOEに対するセキュリティの要求を実装に依存しないように記述した文書。 Protection Profile
3.1.53 証明する 数学的な意味での形式的分析による対応関係を示す。注記　この分析では，あらゆる面で完全な厳密性が要求される。通常，二つのTSF表現の対応関係を高いレベルの厳密性で示す必要がある場合に，“証明する”を使用する。 prove
3.1.54 詳細化 コンポーネントに詳細な内容を追加すること。 refinement
3.1.55 役割 利用者とTOEとの間で許されている交信を規定する定義済みの規則の集まり。 role
3.1.56 秘密 特定のSFPを実施するために，正当な利用者及び/又はTSFにしか知らせてはならない情報。 secret
3.1.57 セキュアな状態●セキュリティの確保された状態 TSFデータが一貫しており，TSFがSFRの正確な実施を継続している状態。 secure state
3.1.58 セキュリティ属性 サブジェクト，利用者(TOE範囲外のIT製品を含む。)，オブジェクト，情報，セッション及び/又は資源の特性のうち，SFRを定義する場合に使用し，SFRを実施する場合にその値を使用するもの。 security attribute
3.1.59 セキュリティ機能方針 TSFによって実施され，SFRの集まりとして表現できる特定のセキュリティの振る舞いを記述する規則の集まり。 security function policy
3.1.60 セキュリティ対策方針 識別された脅威へ対抗することを意図した記述，並びに/又は識別された組織のセキュリティ方針及び/若しくは前提条件を満たすことを意図した記述。 security objective
3.1.61 セキュリティ課題 TOEが対処するよう意図されたセキュリティの本質及び範囲を規定する，一定の形式に従った記述。
注記　この記述は次の組合せから構成される。
・TOEが対抗すべき脅威。
・TOEが実施すべきOSP。
・TOEとその運用環境とが満たすべき前提条件。 		security problem
3.1.62 セキュリティ要件 TOEのセキュリティ対策方針の達成に寄与するように定められている，標準的な言い回しで記述された要件。 security requirement
3.1.63 セキュリティターゲット●セキュリティ設計仕様書 特定の識別されたTOEに対するセキュリティの要求を，実装に依存するように記述した文書。 Security Target●ST
3.1.64 選択 コンポーネント内のリストから一つ以上の項目を指定すること。 selection
3.1.65 準形式的●準形式的な 意味が定義された制限付き構文言語で表現されている(連体修飾)。 semiformal
3.1.66 規定する あるエンティティの固有の詳細を，厳密かつ正確に提供する。 specify
3.1.67 正確適合 PPにおける全ての要件がSTにもまた存在する，STとPPとの階層的な関係。注記　この関係は，“STには，PPの全ての項目を含めなければならないか，それ以上の項目を加えることができる”(包含関係)として大まかに定義することができる。正確適合は，指定された方法に厳格に従う要件である。 strict conformance
3.1.68 ST評価 定義済みの評価基準に用いてSTを評定すること。(★「評価基準を」か? 3.1.72参照★) ST evaluation
3.1.69 サブジェクト オブジェクトに対して操作を実行するTOE内の能動的なエンティティ。 subject
3.1.70 評価対象●TOE ガイダンス文書が添付されることもある，ひとまとまりのソフトウェア，ファームウェア及び/又はハードウェア。 target of evaluation
3.1.71 脅威エージェント 資産に対して敵対的な動作を行うエンティティ。 threat agent
3.1.72 TOE評価 定義済みの評価基準を用いてTOEを評定すること。 TOE evaluation
3.1.73 TOE資源 TOE内で使用可能な又は消費可能なもの。 TOE resource
3.1.74 TOEセキュリティ機能 SFRを正確に実現するために必要なTOEのハードウェア機能，ソフトウェア機能及び/又はファームウェア機能の組合せ。 TOE security functionality
3.1.75 たどる●追跡する 最小限の厳密性で，二つのエンティティ間の対応関係の非形式的分析を実施する。注記　例えば，セキュリティ機能要件からその元となるセキュリティ対策方針まで遡って確認できること。 trace
3.1.76 TOE範囲外への転送 TSFの制御下にないエンティティに対して，TSFが仲介して行われるデータ通信。 transfers outside of the TOE
3.1.77 変換 標準的な言い回しでセキュリティ要件を記述する処理。注記　この意味で変換という用語を使用することはこの用語の文字どおりの意味ではなく，また，標準的な言い回しで表現される全てのSFRをセキュリティ対策方針に逆変換できることを意味するものでもない。 translation
3.1.78 高信頼チャネル TSFと別の信頼できるIT製品とが，必要な信頼をもって通信することができる手段。 trusted channel
3.1.79 高信頼IT製品 TOEと運用上，整合されたセキュリティ機能要件をもち，そのセキュリティ機能要件を正しく実現するとみなされるTOE以外のIT製品。注記　高信頼IT製品の一例として，別個に評価されたものがある。 trusted IT product
3.1.80 高信頼パス 利用者とTSFとが，必要な信頼をもって通信することができる手段。 trusted path
3.1.81 TSFデータ SFRの実施に影響する，TOEの動作に必要なデータ。 TSF data
3.1.82 TSFインタフェース 外部エンティティ(又はTSF外にあるTOE内のサブジェクト)が，TSFへデータを提供し，TSFからデータを受信し，TSFからサービスを呼び出す手段。 TSF interface
3.1.83 利用者データ TSFの動作に影響を与えない，利用者のためのデータ。 user data
3.1.84 検証する 充足性について独自の判断ができる程度に厳密に，第三者として確かめる。注記　“3.1.14 確認する(confirm)”も参照する。この“検証する(verify)”という用語は，“確認する(confirm)”よりも厳格な意味合いをもつ。評価者に独自の調査・分析作業を要求する場合，この用語は評価者アクションの中で使用される。 verify
3.2.1 管理者 TSFが実装する全ての方針に関して，あるレベルの信頼を得ているエンティティ。注記　全てのPP又はSTが管理者に対して同一のレベルを仮定しているわけではない。一般的に管理者は，TOEのST中の方針に従うものと仮定されている。これらの方針のうち幾つかは，TOEの機能要件に関係し，その他のものは，運用環境に関係している。 administrator
3.2.2 呼出し木●コールツリー モジュールが相互に呼び出し合っている関係を表す図中で，システム内のモジュールを示す図の形態。注記　IEEE Std 610.12-1990による。 call tree
3.2.3 凝集●凝集度●モジュール強度 単一のソフトウェアモジュールによって実行されるタスクが，相互に関連付けられる方法及びその度合い。[IEEE Std 610.12-1990] 注記　凝集の種類には，偶発的凝集，通信的凝集，機能的凝集，論理的凝集，逐次的凝集及び時間的凝集がある。これらの凝集の種類については，対応する用語の項に定義している。 cohesion
3.2.4 偶発的凝集 モジュール関連が全くない，又はほとんどないアクティビティを実行するような特性をもつ凝集。[IEEE Std 610.12-1990] 注記“凝集”(3.2.3)も参照。 coincidental cohesion
3.2.5 通信的凝集 モジュール内の他の機能に対する出力を生成する機能，又はモジュール内の他の機能からの出力を使用する機能をもつ凝集。[IEEE Std 610.12-1990]
注記1　“凝集”(3.2.3)も参照。
注記2　通信的に凝集するモジュールの例には，強制アクセスの検査，任意アクセスの検査及びアクセス権限の検査を含む，アクセスチェックモジュｮ諢丞袖縺ｧ螟画鋤縺ｨ縺