8
X 5070-1 : 2011 (ISO/IEC 15408-1 : 2009)
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)
――――― [JIS X 5070-1 pdf 11] ―――――
9
X 5070-1 : 2011 (ISO/IEC 15408-1 : 2009)
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との階層的な関係。
――――― [JIS X 5070-1 pdf 12] ―――――
10
X 5070-1 : 2011 (ISO/IEC 15408-1 : 2009)
注記 この関係は,“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をセキュリティ対策方針に逆変換できることを意味す
るものでもない。
――――― [JIS X 5070-1 pdf 13] ―――――
11
X 5070-1 : 2011 (ISO/IEC 15408-1 : 2009)
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
の機能要件に関係し,その他のものは,運用環境に関係している。
――――― [JIS X 5070-1 pdf 14] ―――――
12
X 5070-1 : 2011 (ISO/IEC 15408-1 : 2009)
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内部構造(ADVINT)ファミリは,全てのコンポーネントで複雑性分析を要求する。
開発者は,複雑性が十分に軽減されたことを主張するために,その裏付けを提供することが求
められる。この裏付けとしては,開発者が使用したプログラミング標準,及び全てのモジュー
ルが標準に適合していること(適合しない場合には,ソフトウェア工学の論証によって例外が
――――― [JIS X 5070-1 pdf 15] ―――――
次のページ PDF 16
JIS X 5070-1:2011の引用国際規格 ISO 一覧
- ISO/IEC 15408-1:2009(IDT)
JIS X 5070-1:2011の国際規格 ICS 分類一覧
- 35 : 情報技術.事務機械 > 35.040 : 文字セット及び符号化