48
X 5070-1 : 2011 (ISO/IEC 15408-1 : 2009)
けられる。このような分割式解決策は,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及び前提条件までど
のように遡るかを示す。この追跡では,次の三つの規則に従わなければならない。
――――― [JIS X 5070-1 pdf 51] ―――――
49
X 5070-1 : 2011 (ISO/IEC 15408-1 : 2009)
a) 見せかけの対策方針の禁止 : 各セキュリティ対策方針は,少なくとも一つの脅威,OSP又は前提条件
まで遡る。
b) セキュリティ課題定義に関する完全性 : 脅威,OSP及び前提条件のそれぞれについて,そこまで遡る
少なくとも一つのセキュリティ対策方針がある。
c) 正確な追跡 : 前提条件は常にTOEの運用環境について設定されるため,TOEのセキュリティ対策方
針は前提条件に遡らない。この規格類第3部で認められる追跡を図A.2に示す。
脅威 組織の 前提条件
セキュリティ方針
TOEの 運用環境の
セキュリティ セキュリティ
対策方針 対策方針
図A.2−セキュリティ対策方針とセキュリティ課題定義との間の追跡
複数のセキュリティ対策方針が遡った先が同じ脅威になることがあるが,その場合,これらのセキュリ
ティ対策方針の組合せがその脅威に対抗することを示す。OSP及び前提条件にも同じことが当てはまる。
A.7.3.2 追跡の正当化の提供
セキュリティ対策方針根拠では,追跡が有効であることも示す。つまり,特定の脅威,OSP及び前提条
件まで遡る全てのセキュリティ対策方針が達成された場合,その脅威は対抗され,OSPは実施され,前提
条件が確認されることを示す。
この追跡の正当化においては,関連するセキュリティ対策方針を達成することによる,脅威への対抗,
OSPの実施及び前提条件の確認への効果を分析し,実際に対抗,実施及び確認されるという結論を導く。
セキュリティ課題定義が幾つかのセキュリティ対策方針と非常に似ているような状況では,追跡の正当
化が非常に簡単になることがある。例えば,脅威が“T17 : 脅威エージェントXは,AB間の転送時に機
密情報を読み取る。”であり,TOEのセキュリティ対策方針が“OT12 : TOEは,AB間で送信される全て
の情報の機密が確実に保持されるようにしなければならない。”である場合,“T17は,OT12によって直接
対抗される。”と示される。
A.7.3.3 脅威への対抗について
脅威への対抗とは,必ずしもその脅威を除去することを意味せず,脅威を十分に減らすこと又は脅威を
十分に緩和することを意味する場合もある。
脅威の除去の例は,次のとおりである。
・ 脅威エージェントから悪意ある行為を実行する能力を除去する。
・ 敵対的な動作を資産に対して行うことができなくなるように,資産を移動,変更又は保護する。
・ 脅威エージェントを除去する(例えば,頻繁にネットワークに障害を起こす装置をネットワークから
取り外す。)。
脅威の軽減の例は,次のとおりである。
・ 敵対的な動作を実行する脅威エージェントの能力を制限する。
――――― [JIS X 5070-1 pdf 52] ―――――
50
X 5070-1 : 2011 (ISO/IEC 15408-1 : 2009)
・ 脅威エージェントが敵対的な動作を実行する機会を制限する。
・ 実行された敵対的な動作が成功する可能性を減少させる。
・ 抑止によって脅威エージェントが敵対的な動作を実行する動機を減少させる。
・ 脅威エージェントに,より多くの専門知識又は資源を課する。
脅威の影響の緩和の例は,次のとおりである。
・ 資産のバックアップを頻繁に行う。
・ 資産のスペアコピーを取る。
・ 資産に保険をかける。
・ 適切なアクションをとることができるように,成功した全ての敵対的な動作が適切な時期に必ず検出
されるようにする。
A.7.4 セキュリティ対策方針 : 結論
セキュリティ対策方針及びセキュリティ対策方針根拠に基づいて,次のような結論を導くことができる。
・ 全てのセキュリティ対策方針が達成された場合,ASESPDで定義されるセキュリティ課題は解決され
る。
・ 全ての脅威が対抗され,全てのOSPが実施され,全ての前提条件が確認される。
A.8 拡張コンポーネント定義(ASEECD)
多くの場合,STのセキュリティ要件(A.9参照)は,この規格類の第2部又は第3部のコンポーネント
に基づく。ただし,場合によっては,この規格類の第2部又は第3部のコンポーネントに基づかないST
の要件が存在することがある。この場合は,新しいコンポーネント(拡張コンポーネント)を定義しなけ
ればならない。この定義は拡張コンポーネント定義で行う。これについての詳細を,C.4に示す。
A.8では,拡張コンポーネントだけを扱い,拡張要件(拡張コンポーネントに基づく要件)については
扱わない。拡張要件はセキュリティ要件(A.9参照)に含めることが望ましい,全ての目的のために,こ
の規格類の第2部又は第3部のコンポーネントに基づく要件と同じになる。
A.9 セキュリティ要件(ASEREQ)
セキュリティ要件は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作成者がセキュリティ対策方針について説明する
――――― [JIS X 5070-1 pdf 53] ―――――
51
X 5070-1 : 2011 (ISO/IEC 15408-1 : 2009)
ときに異なる用語を使用するかもしれないが,規格化された表現では同じ用語及び概念を使用するこ
とが求められる。これによって比較が容易になる。
運用環境は評価されず,その評価を目的とした記述は必要ないので,運用環境のセキュリティ対策方針
のために,この規格類ではどのような書換えも必要ない。運用システムのセキュリティアセスメントに関
連する参考文献を参照する。
運用環境の一部が別の評価で評価されるかもしれないが,これは現行の評価の範囲外である。例えば,
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) OEのセキュリティ対策方針に関する完全性 : TOEのセキュリティ対策方針のそれぞれについて,
そこまで遡る少なくとも一つのSFRがある。
複数のSFRが遡った先が同じTOEのセキュリティ対策方針になることがあるが,その場合,これらの
セキュリティ要件の組合せがそのTOEのセキュリティ対策方針に対応することを示す。
A.9.1.2.2 追跡の正当化の提供
セキュリティ要件の根拠では,追跡が有効であることを示す。つまり,特定のTOEのセキュリティ対策
方針まで遡る全てのSFRが達成された場合,そのTOEのセキュリティ対策方針は対応されることを示す。
この追跡の正当化においては,関連するSFRを達成することによる,TOEのセキュリティ対策方針への対
応を分析し,実際に対応されるという結論に導く。
――――― [JIS X 5070-1 pdf 54] ―――――
52
X 5070-1 : 2011 (ISO/IEC 15408-1 : 2009)
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に含まれるセキュリティ保証要件の一つであるAVAVANのレベルが低い(又はAVAVANが
ない)が挙げられる。
A.9.4 セキュリティ要件 : 結論
STのセキュリティ課題定義では,セキュリティ課題は脅威,OSP及び前提条件から成り立つものと定義
される。STのセキュリティ対策方針の箇条では,解決策は二つの分割式解決策の形式で提供される。
・ TOEのセキュリティ対策方針
・ 運用環境のセキュリティ対策方針
さらに,全てのセキュリティ対策方針が達成された場合,セキュリティ課題が解決されることを示す,
セキュリティ対策方針の根拠が提供される。全ての脅威が対抗され,全てのOSPが実施され,全ての前提
条件が確認される。
――――― [JIS X 5070-1 pdf 55] ―――――
次のページ PDF 56
JIS X 5070-1:2011の引用国際規格 ISO 一覧
- ISO/IEC 15408-1:2009(IDT)
JIS X 5070-1:2011の国際規格 ICS 分類一覧
- 35 : 情報技術.事務機械 > 35.040 : 文字セット及び符号化