1

ST作成と製品開発

-開発者が注意したいポイント -

2002年3月29日

情報処理振興事業協会セキュリティセンター

伊藤昇

ITセキュリティ評価・認証セミナー資料

2

ST作成のポイント

• 評価者はSTのどこを見るか。

• 分かりやすいSTを書くには。

• 間違いやすい点とは。

3

STの役割とは

STの読者購入者/利用者、評価者、開発者、認証者評価者の視点を考慮

評価者が知りたいことを曖昧さなく記述。

セキュリティ評価におけるSTの役割

TOEを評価するための土台を提供すること。

→ TOEのセキュリティに関わるすべての要求事項を明示する。

4

TOE選定

「製品」と「システム」の違い製品: いろいろなシステムに適用される。

システム: 個別の運用環境における特定のIT装置。

TOEの範囲評価対象となるセキュリティ機能を含む。

評価用の資料、データを準備できること。保証レベルによって要求するものが異なる。

他社製品を含めてもよい。

5

ST概説

ST識別STとTOEの識別情報→TOEと製品とが同一でない場合に注意。

キーワードとEALを含めることを推奨。

CC適合の主張CC パート2: 「適合」/「拡張」CC パート3: 「適合」/「追加」/「拡張」適合するPP

6

TOE記述

製品種別の明記:「製品種別 (あるいはシステム種別)」という節を作ると分かりやすい。

製品とTOEの範囲が異なる場合:TOEの境界を明確に定義する。どの部分の説明なのか、区別を明確に。

正確な説明図:不用意な図は読者の誤解を招く。

7

前提条件

基本の記述項目

用途、使用条件

運用環境

物理的側面

人的側面 (利用者、管理者など)

接続性の側面 (TOEに接続する他の装置)

運用や管理に関わる、妥当性のある条件

8

脅威

脅威とは、TOEあるいはその環境内で、脆弱性を利用して資産に対する危険を生じさせるもの。

脅威エージェント、攻撃、資産の三点セット。■ 脅威エージェント: 攻撃者を具体的にイメージでき

る情報を記述。

■ 攻撃: 攻撃方法や利用する脆弱性が具体的に分か

る情報を記述。

■ 資産: 守るべき情報 (利用者データ) /リソース、TSFデータなどを記述。

9

組織のセキュリティ方針

製品やシステムを導入する組織のセキュリティ方針/規則

TOEとその環境が対策を施さねばならない、その組織の方針あるいは規則を書く。

セキュリティ対策方針にブレークダウンできるよう、必要ならば説明/解釈を付ける。

10

セキュリティ対策方針

どのような対策をとるかの簡潔な記述。セキュリティ機能要件と明確に対応→具体的すぎ

セキュリティ機能要件への対応困難→抽象的すぎ

実装から独立していることが望ましい。

「環境に対するセキュリティ対策方針」TOEで完全に対抗できない脅威に対抗。TOEで完全に満たせないOSPを満たす。環境の前提条件が満たされることを保証。

→必要に応じて、TOE/環境の両方に含める。

脅威 OSPs 前提条件

TOE IT環境 非ITセキュリティ要件

環境のセキュリティ対策方針

TOEセキュリティ対策方針

ITセキュリティ要件

TOEセキュリティ環境

11

間違えやすいセキュリティ機能要件-1

アクセス制御（FDP_ACC)FDP_ACC.1.1 TSFは、[割付: サブジェクト、オブジェクト、

及びSFPで扱われるサブジェクトとオブジェクト間の操作のリスト]に対して[割付: アクセス制御SFP]を実施しなければならない。

サブジェクト: TOE内のプロセス★利用者や外部装置はサブジェクトではない。

オブジェクト: 情報の入れもの★情報自体はアクセス制御の対象ではない。

12

(続き)

人間の利用者

/リモートIT製品

利用者

評価対象 (TOE) TOEセキュリティ機能インタフェース (TSFI)

TOEセキュリティ機能

(TSF)

TOEセキュリティ方針の実施

(TSP)

オブジェクト/情報 サブジェクト

資源 プロセス

TSF制御範囲 (TSC)

サブジェクト

サブジェクト

セキュリティ属性

セキュリティ属性

セキュリティ属性

サブジェクト

セキュリティ属性

セキュリティ属性

(CC パート2　図1.1　「セキュリティ機能要件の枠組み」から)

間違えやすいセキュリティ機能要件-1

13

TSFを保護する要件を忘れずに。脅威やセキュリティ機能要件間の明示的な依存性によらず、相互サポートを満たすため、以下の機能要件を含めるかどうか考える。

FPT_RVM.1: セキュリティ機能のバイパス防止

FPT_SEP.1: セキュリティ機能の改ざん防止

FMT_MOF.1:セキュリティ機能の非活性化防止

必要に応じ、さらにFAUクラス、FPT_PHPなど

間違えやすいセキュリティ機能要件-2

14

機能強度 (SOF)

攻撃者の攻撃能力に見合う最小のSOFを選択。

脆弱性分析 (VLA) との相互関係→下表SOFは、個々のセキュリティメカニズムごとに割当て可能。

→特定の機能に対して、上位のSOFを適用してもよい。

6～7

5

1～4

EAL(参考)

4高位高

3中位中

1～2基本低

VLASOF攻撃能力

15

保証要件

以下のような要素を考慮して保証パッケージ、コンポーネントを選択。

資産の価値とリスク

証拠 (評価用提供物件) 提供の可否

評価にかかるコスト

評価にかかる時間

市場の要求

機能コンポーネントからの依存性

16

要約仕様

機能要件、保証要件を満たすために、TOEは何を提供するかを記述。

開発資料やガイダンスなどに使用する用語をベースに。

要件とのマッピングは、単純なほうがトレーサビリティ確認をしやすい。

ex. 複数の機能要件を一つのセキュリティ機能にまとめる (1:Nのマッピング)。

17

根拠

主たる目的: 評価に役立つ情報を提供する。→評価者の視点を考慮。

対応表を使うと対応関係の確認が容易。

上記の対応表で必要性を示し、文章で十分性を説明する。

18

全般的なヒント

第三者に理解できる表現。

章の初めで、その章が何を示すのかを述べる。

ex. 要約仕様: 「この章では、TOEのセキュリティ機能を説明する。以下のセキュリティ機能は、5.1で記述したTOEセキュリティ機能要件を満たすものである。・・」 →後半は、必要なクレームを述べている。

用語を統一する。用語解説 (glossary) を付けると効果的。

19

製品開発のポイント

• セキュリティ評価のために何が必要か。-通常の開発資料の適用。

-あらたに作るもの。

• 既存製品を評価するときの注意とは。

20

評価を受ける準備

必要なものST

評価用提供物件STの「保証手段」に記したもの。

TOE製品/システムの開発時と同一のテスト環境を含む。

21

評価用提供物件

開発に関わる資料設計資料

テスト関連資料

開発ツール関連資料

開発環境のセキュリティに関する資料

製造に関わる資料製品検査関連資料

出荷/配送関連資料

TOEに付属するガイダンス資料

22

あらたに作成する資料

CCセキュリティ評価特有の資料

ST

表現対応分析 EAL1~

脆弱性分析 EAL2~

機能強度分析 EAL2~

誤使用分析 EAL3~

TOEセキュリティ方針 (TSP) モデル EAL4~

ライフサイクルモデル EAL4~

23

既存資料の見直し

評価のために見直し/追加が必要になるかもしれない資料

設計資料 → TOEとの完全な整合

テスト関連資料 → CCの基準に沿った記述

構成管理資料 → 〃

配付関連資料 → 〃

設置/生成/立上げ関連資料 → 〃

24

設計資料

設計資料の内容は、完成したTOEと整合したものでなければならない。

■ 機能仕様: TSFの機能と外部インタフェース

■ 上位レベル設計: TSFのサブシステムレベルの機能とインタフェース

■ 下位レベル設計: TSFのモジュールレベルの機能とインタフェース

■ 実装表現: TSF設計の最も抽象度が低い記述レベル (ex. ソースコード)

★これらの資料は、各々が独立した設計書でなくてもよい。

25

開発時に対処が必要なもの

開発工程に対する要件は、開発時に要件が満たされていないと、後からの対応が難しい。→その要件を必要とするEALへの対応困難。

■ 構成管理: 特に、ツールの使用を条件とするコンポーネントの適用。

■ ライフサイクルサポート: 開発環境のセキュリティ手段、開発ツール定義を必要とするコンポーネントの適用。

26

ご質問・ご意見info-cc@ipa.go.jp

IPA セキュリティセンターホームページhttp://www.ipa.go.jp/security/