1

ST作成と製品開発

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

2002年3月29日

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

伊藤 昇

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

2

ST作成のポイント

• 評価者はSTのどこを見るか。• 分かりやすいSTを書くには。

• 間違いやすい点とは。

3

STの役割とは

n STの読者n 購入者/利用者、評価者、開発者、認証者

n 評価者の視点を考慮評価者が知りたいことを曖昧さなく記述。

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

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

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

4

TOEの選定

n 「製品」と「システム」の違いn 製品: いろいろなシステムに適用される。n システム: 個別の運用環境における特定のIT装置。

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

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

5

ST概説

n ST識別n STとTOEの識別情報

→TOEと製品とが同一でない場合に注意。

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

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

6

TOE記述

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

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

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

7

前提条件

n 基本の記述項目n 用途、使用条件

n 運用環境n物理的側面n人的側面 (利用者、管理者など)n接続性の側面 (TOEに接続する他の装置)

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

8

脅威

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

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

る情報を記述。

■ 攻撃: 攻撃方法や利用する脆弱性が具体的に分かる情報を記述。

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

9

組織のセキュリティ方針

n 製品やシステムを導入する組織のセキュリティ方針/規則n TOEとその環境が対策を施さねばならない、その組織の方針あるいは規則を書く。

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

10

セキュリティ対策方針

n どのような対策をとるかの簡潔な記述。n セキュリティ機能要件と明確に対応→ 具体的すぎn セキュリティ機能要件への対応困難→ 抽象的すぎn 実装から独立していることが望ましい。

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

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

11

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

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

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

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

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

12

(続き)

人間の利用者

/リモートIT製品

利用者

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

TOEセキュリティ機能

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

(TSP)

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

資源 プロセス

TSF制御範囲 (TSC)

サブジェクト

サブジェクト

セキュリティ属性

セキュリティ属性

セキュリティ属性

サブジェクト

セキュリティ属性

セキュリティ属性

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

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

13

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

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

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

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

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

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

14

機能強度 (SOF)

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

n 脆弱性分析 (VLA) との相互関係 →下表SOFは、個々のセキュリティメカニズムごとに割当て可能。→特定の機能に対して、上位のSOFを適用してもよい。

6～75

1～4EAL(参考)

4高位高

3中位中

1～2基本低

VLASOF攻撃能力

15

保証要件

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

n 資産の価値とリスクn 証拠 (評価用提供物件) 提供の可否

n 評価にかかるコスト

n 評価にかかる時間

n 市場の要求

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

16

要約仕様

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

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

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

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

17

根拠

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

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

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

18

全般的なヒント

n 第三者に理解できる表現。n 章の初めで、その章が何を示すのかを述べる。

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

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

19

製品開発のポイント

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

- あらたに作るもの。

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

20

評価を受ける準備

n 必要なものn ST

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

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

21

評価用提供物件

n 開発に関わる資料n設計資料nテスト関連資料n開発ツール関連資料n開発環境のセキュリティに関する資料

n 製造に関わる資料n製品検査関連資料n出荷/配送関連資料

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

22

あらたに作成する資料

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

n STn表現対応分析 EAL1~n脆弱性分析 EAL2~n機能強度分析 EAL2~n誤使用分析 EAL3~n TOEセキュリティ方針 (TSP) モデル EAL4~nライフサイクルモデル EAL4~

23

既存資料の見直し

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

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

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

n構成管理資料 → 〃

n配付関連資料 → 〃

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

24

設計資料

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

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

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

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

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

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

25

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

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

→その要件を必要とするEALへの対応困難。

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

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

26

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

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