情報システムの構築等における

ST 評価・ST 確認の実施に関する解説書

2011 年 4 月

内閣官房情報セキュリティセンター

DM6-08-101

ii

改訂履歴

改訂日 改訂理由

2006/6/16 初版

2006/9/1 説明補足及び誤記訂正

2007/11/9 政府機関統一基準(第２版)の策定に伴う修正等

2011/4/21 政府機関統一管理基準及び政府機関統一技術基準の策定に伴う修正

本書は、2005 年度に独立行政法人情報処理推進機構に設置された「政府機関における機

器等の購入ガイドラインに関する研究会」がとりまとめた「政府機関調達者向けセキュリ

ティ要件活用ガイドブック」（2006 年 3 月）を元に、「政府機関の情報セキュリティ対策の

ための統一基準(2005 年 12 月版(全体版初版))」（2005 年 12 月 13 日情報セキュリティ政策

会議決定）に関連する内容等を内閣官房情報セキュリティセンターにおいて加筆して作成

したものである。 また、「政府機関の情報セキュリティ対策のための統一管理基準」及び「政府機関の情報セ

キュリティ対策のための統一技術基準」（2011年 4月 21日情報セキュリティ政策会議決定）

への改訂にあわせて本書も見直し、2011 年 4 月に改訂した。

iii

本書の目的と内容

本書は、府省庁において情報システムの構築又はソフトウェアの開発（以下「情報シス

テムの構築等」という。）を外部委託により行う場合に、「政府機関の情報セキュリティ対

策のための統一管理基準」及び「政府機関の情報セキュリティ対策のための統一技術基準」

(NISD-K304-101 及び NISD-K305-101 以下「政府機関統一管理基準及び技術基準」とい

う。）の求める事項に従い、ST 評価・ST 確認等の適切な情報セキュリティ対策を実現す

るための実施手順を示す解説書である。

1 章では、情報システム及びソフトウェア（以下「情報システム等」という。）のセキ

ュリティ要件、セキュリティ機能及び ST 評価・ST 確認等について、関連する政府機関

統一管理基準及び技術基準の遵守事項及び「業務・システム最適化指針（ガイドライン）」

との関係を説明する。

2 章では、調達者が、セキュリティ要件を具体化して調達仕様に含める「セキュリティ

要求仕様」を作成し、提案者が作成する「セキュリティ提案仕様」を評価する手順の概要

を説明する。また、この手順に関する詳細な解説書である「情報システムの構築等におけ

るセキュリティ要件及びセキュリティ機能の検討に関する解説書」の活用方法を説明す

る。

3 章では、ST 評価・ST 確認の適用における留意事項を説明する。なお、本書は ST を

作成するための解説書ではないことから、ST の作成については、「関連資料等」中の独立

行政法人情報処理推進機構が公開している ST 関連資料の記述を参照されたい。

4 章では、情報システムを構成する機器及びソフトウェア製品（以下「機器等」という。）

について、IT セキュリティ評価及び認証制度に基づく認証の取得を調達手続における提

案の評価に加える場合の留意事項を説明する。

本書の読者

本書は、次の者を対象とする。

府省庁において情報システムの構築等を外部委託により行う調達者

ここでいう調達者には、以下の者を含む。

１）情報システムセキュリティ責任者： 情報システムにおける情報セキュリテ

ィ対策に関する事務を統括する者

２）情報システムの構築等及びその調達に責任を持つ者

３）調達を担当する部門の者

なお、省庁対策基準及びこれに基づき策定する各種実施手順においては、「政府機関統

一管理基準及び技術基準」（NISD-K304-101 及び NISD-K305-101）に基づき、上記１）

の情報システムセキュリティ責任者に対して、情報システムの構築等の外部委託において

本書で説明するセキュリティ機能の装備その他の情報セキュリティ対策の実施を求める

こととなる。本書では、情報システムに関する調達を適切に行うために、情報システムセ

キュリティ責任者のほかに、上記２）及び３）の者も読者に想定する。

iv

関連資料等

「情報システムの構築等におけるセキュリティ要件及びセキュリティ機能の検討に

関する解説書」（DM6-07-101）

内閣官房情報セキュリティセンター、2011 年 4 月

本関連資料では、府省庁において情報システムの構築等を調達する場合に、適

切な情報セキュリティ対策の実現を支援することを目的として、求めるセキュ

リティ要件を提案者に正確に伝えるとともに、応札において提示される提案仕

様を的確に審査するための情報を提供している。

本書においては、本関連資料を「セキュリティ要件及びセキュリティ機能の検

討に関する解説書」とも記す。

「政府機関の情報セキュリティ対策のための統一管理基準」及び「政府機関の

情報セキュリティ対策のための統一技術基準」 （NISD-K304-101 及び NISD-K305-101）

内閣官房情報セキュリティセンター、2011 年 4 月 21 日

以下、「政府機関統一管理基準及び技術基準」と記す。なお、政府機関統一管

理基準及び技術基準の項目を、統 1.1.1.1(2) のように、「統」文字と政府機関

統一管理基準及び技術基準の項目番号を示す場合がある。

「政府機関の情報セキュリティ対策のための統一管理基準解説書」 （NISD-K304-101C）

内閣官房情報セキュリティセンター、2011 年 4 月 21 日

以下、「政府機関統一管理基準解説書」と記す。

「政府機関の情報セキュリティ対策のための統一技術基準解説書」 （NISD-K305-101C）

内閣官房情報セキュリティセンター、2011 年 4 月 21 日

以下、「政府機関統一技術基準解説書」と記す。なお、政府機関統一管理基準

解説書及び政府機関統一技術基準解説書をあわせて、「政府機関統一管理基準

及び技術基準解説書」と記す。

政府機関統一管理基準及び技術基準に基づき府省庁において策定する省庁対策基

準

省庁対策基準に基づき府省庁において策定する各種実施手順

本書に関係する各種実施手順として、「情報システムにおける情報セキュリテ

ィ対策実施規程」「ソフトウェア開発における情報セキュリティ対策実施規程」

「機器等の購入における情報セキュリティ対策実施規程」及び「外部委託にお

ける情報セキュリティ対策実施規程」又は府省庁で作成するこれらに相当する

ものがある。

「業務・システム最適化指針（ガイドライン）」

各府省情報化統括責任者(CIO)連絡会議決定、2006 年(平成 18 年)3 月 31 日

以下、「最適化ガイドライン」とも記す。

v

「ISO/IEC 15408: 2005 Information technology – Security techniques- Evaluation criteria for IT security -- Part 1, 2, 3」

以下、「ISO/IEC 15408」と記す。

「Common Criteria for Information Technology Security Evaluation Version 2.3 -- Part 1, 2, 3」及び 「Common Criteria for Information Technology Security Evaluation Version 3.1 -- Part 1, 2, 3」

ISO/IEC 15408 は、Common Criteria for Information Technology Security Evaluation を採用した国際標準で、本資料の Version 2.3 と同等の内容となっ

ている。Common Criteria for Information Technology Security Evaluationを CC とも記す。

IT セキュリティ評価及び認証制度

機器等及びシステムにセキュリティ機能が実装されていることを ISO/IEC 15408 に基づき第三者が評価し、認証するための制度である。独立行政法人情

報処理推進機構（IPA）が運営している。 http://www.ipa.go.jp/security/jisec/index.html

vi

目次

1. 情報システムの構築等における セキュリティ機能の装備 ............................................... 1

1.1. 政府機関統一管理基準及び技術基準における要求事項 ............................................. 1 1.1.1. 情報システムのセキュリティ要件とセキュリティ機能に関する遵守事項 ......... 1 1.1.2. ソフトウェアの開発におけるセキュリティ要件と

セキュリ ティ機能に関する遵守事項 ............. 3 1.1.3. 機器等の購入におけるセキュリティ要件と

セキュリティ機能に関する遵守事項 ............... 4 1.2. 「業務・システム最適化指針（ガイドライン）」における工程 ................................. 6

2. セキュリティ要件とセキュリティ機能の 明確化 ............................................................. 8

2.1. セキュリティ要件とセキュリティ機能の明確化の手順 ............................................. 8 2.2. セキュリティ要求仕様作成における「セキュリティ要件及びセキュリティ機能の

検討に関する解説書」の活用例 .................... 10 2.3. セキュリティ提案仕様の審査の際の「セキュリティ要件及びセキュリティ機能の

検討に関する解説書」の活用例 ..................... 11

3. ST 評価・ST 確認の実施手順 ......................................................................................... 12

3.1. ST 評価・ST 確認を実施する工程 ............................................................................ 13 3.2. 基本設計と詳細設計以降とをそれぞれ別に調達する 場合の

ST 評価・ST 確認の実施について ................ 15 3.3. 重要なセキュリティ要件の変更と ST 評価・ST 確認の有効性 ............................... 17

3.3.1. 情報システムの構築等における重要なセキュリティ要件の 変更 .................... 17 3.3.2. 情報システム等の更改における重要なセキュリティ要件の 変更 .................... 17

3.4. ST 評価・ST 確認における評価保証レベル(EAL)の扱い ........................................ 18

4. 認証製品の活用について ................................................................................................ 19

4.1. 認証に関する確認事項 .............................................................................................. 19 4.2. 認証製品情報の利用法 .............................................................................................. 20

付録 セキュリティ設計仕様書（ST） ................................................................................. 21

-1-

1. 情報システムの構築等における

セキュリティ機能の装備

1.1. 政府機関統一管理基準及び技術基準における要求事項

政府機関統一管理基準及び技術基準では、情報システムの構築等において適切なセキュ

リティ機能が装備されることを目的として、本節に挙げる遵守事項を定めている。構築す

る情報システムは、開発するソフトウェア、製品として購入するソフトウェア及び製品と

して購入する機器から構成されることから、情報システムに装備すべきセキュリティ機能

は、これらの構成要素において適切に装備することが求められる。

1.1.1. 情報システムのセキュリティ要件とセキュリティ機能に関す

る遵守事項

政府機関統一管理基準及び技術基準 1.5.1.1 情報システムのセキュリティ要件

(1) (b) 情報システムセキュリティ責任者は、情報システムのセキュリティ要件を決

定すること。この場合、国民・企業と政府との間で申請・届出等のオンライン

手続を提供するシステムにおいては、「オンライン手続におけるリスク評価及

び電子署名・認証ガイドライン」に基づき決定すること。【基本遵守事項】

本遵守事項では、情報システムの計画・設計を行う際に、情報システムのセ

キュリティ要件を決定することを情報システムセキュリティ責任者に求めてい

る。

政府機関統一管理基準及び技術基準 1.5.1.1 情報システムのセキュリティ要件 (1) (c) 情報システムセキュリティ責任者は、情報システムのセキュリティ要件を

満たすために機器等の購入（購入に準ずるリースを含む。）及びソフトウェア

開発において必要な対策、情報セキュリティについての機能の設定、情報セキ

ュリティについての脅威への対策、並びに情報システムの構成要素についての

対策について定めること。【基本遵守事項】

-2-

本遵守事項では、前事項 ((1)(b))で定めた情報システムのセキュリティ要件を

満たすために、構成要素であるソフトウェア及び機器における情報セキュリテ

ィ対策を定めることを情報システムセキュリティ責任者に求めている。関連文

書の「情報システムの構築等におけるセキュリティ要件及びセキュリティ機能

の検討に関する解説書」では、本遵守事項で求める手順を、組織的に行う方法

の例を示している。

政府機関統一管理基準及び技術基準 1.5.1.1 情報システムのセキュリティ要件

(1)(d) 情報システムセキュリティ責任者は、構築する情報システムに重要なセキュリ

ティ要件があると認めた場合には、当該要件に係るセキュリティ機能の設計に

基づいて、製品として調達する機器及びソフトウェアに対して要求するセキュ

リティ機能を定め、当該機能及びその他の要求条件を満たす採用候補製品が複

数ある場合には、その中から当該セキュリティ機能に関して IT セキュリティ

評価及び認証制度に基づく認証を取得している製品を情報システムの構成要

素として選択すること。【基本遵守事項】

本遵守事項では、情報システムの構成要素となる機器及びソフトウェアを選

定する際に、要求するセキュリティ機能その他の要求条件を満たす製品に選択

肢がある場合、ISO/IEC 15408 に基づく IT セキュリティ評価及び認証制度に基

づく認証を取得している製品を選択することを求めている。製品が求めるセキ

ュリティ機能を持つことは、製品の提供者が示す仕様書や説明により知ること

ができる。さらに本遵守事項も適用し、セキュリティ要求仕様に対して適切な

セキュリティ機能が装備されていることを第三者が確認している製品を選択す

ることにより、セキュリティ機能の確実な装備を担保することができる。

政府機関統一管理基準及び技術基準 1.5.1.1 情報システムのセキュリティ要件

(1)(g) 情報システムセキュリティ責任者は、構築する情報システムに重要なセキュリ

ティ要件があると認めた場合には、当該情報システムのセキュリティ機能の設

計について第三者機関によるセキュリティ設計仕様書（ST：Security Target）の ST 評価・ST 確認を受けること。ただし、情報システムを更改し、又は開

発中に仕様変更が発生した場合であって、見直し後のセキュリティ設計仕様書

において重要なセキュリティ要件の変更が軽微であると認めたときは、この限

りでない。 【基本遵守事項】

-3-

本遵守事項では、構築する情報システムに重要なセキュリティ要件がある場

合には、セキュリティ機能が確実に実装されることを目的として、ISO/IEC

15408 に基づくセキュリティ設計仕様書（セキュリティターゲット、ST）につ

いて ST 評価・ST 確認を行うことを求めている。情報システムに重要なセキュ

リティ要件があるか否かについては、情報システムセキュリティ責任者が判断

する。

1.1.2. ソフトウェアの開発におけるセキュリティ要件とセキュリ

ティ機能に関する遵守事項

政府機関統一管理基準及び技術基準 1.5.2.3 ソフトウェア開発

(1)(a)(オ) 情報システムセキュリティ責任者は、開発するソフトウェアが運用される

際に関連する情報資産に対して想定されるセキュリティ脅威の分析結果、及び

当該ソフトウェアにおいて取り扱う情報の格付けに応じて、セキュリティ機能

の必要性の有無を検討し、必要と認めたときは、セキュリティ機能を適切に設

計し、設計書に明確に記述すること。【基本遵守事項】

本遵守事項では、ソフトウェアの開発を行う際に、セキュリティ機能を適切

に設計し、設計書に明確に記述することを求めている。

政府機関統一管理基準及び技術基準 1.5.2.3 ソフトウェア開発

(1)(a)(ケ) 情報システムセキュリティ責任者は、開発するソフトウェアに重要なセキ

ュリティ要件がある場合には、これを実現するセキュリティ機能の設計につい

て第三者機関によるセキュリティ設計仕様書（ST：Security Target）の ST 評

価・ST 確認を受けること。ただし、当該ソフトウェアを要素として含む情報

システムについてセキュリティ設計仕様書の ST 評価・ST 確認を受ける場合、

又はソフトウェアを更改し、若しくは開発中に仕様変更が発生した場合であっ

て見直し後のセキュリティ設計仕様書において重要なセキュリティ要件の変

更が軽微であると認めたときは、この限りでない。 【基本遵守事項】

本遵守事項では、開発するソフトウェアに重要なセキュリティ要件がある場

合には、セキュリティ機能が確実に実装されることを目的として、ISO/IEC

-4-

15408 に基づくセキュリティ設計仕様書（セキュリティターゲット、ST）につ

いて ST 評価・ST 確認を行うことを求めている。そのソフトウェアに重要なセ

キュリティ要件があるか否かについては、情報システムセキュリティ責任者が

判断する。

1.1.3. 機器等の購入におけるセキュリティ要件とセキュリティ機能

に関する遵守事項

政府機関統一管理基準及び技術基準 1.5.2.2 機器等の購入

(1) (a) 統括情報セキュリティ責任者は、機器等の選定基準を整備すること。 【基本遵守事項】

本遵守事項では、統括情報セキュリティ責任者に対して、情報セキュリティ

の観点から、機器等の選定基準を整備することを求めている。

政府機関統一管理基準及び技術基準 1.5.2.2 機器等の購入

(2) (a) 情報システムセキュリティ責任者は、機器等の選定時において、選定基準に

対する機器等の適合性を確認し、その結果を機器等の候補の選定における判断

の一要素として活用すること。【基本遵守事項】

本遵守事項では、情報システムセキュリティ責任者に対して、前記(1) (a)に基

づき定められた機器等の選定基準を、機器等の候補の選定において判断の一要

素として活用することを求めている。

政府機関統一管理基準及び技術基準 1.5.2.2 機器等の購入

(1)(b) 情報システムセキュリティ責任者は、機器等の購入において、セキュリティ機

能の要求仕様があり、総合評価落札方式により購入を行う際には、IT セキュ

リティ評価及び認証制度による認証を取得しているかどうかを評価項目とし

て活用することを選定基準として定めること。【基本遵守事項】

-5-

本遵守事項では、機器等の購入において、示された条件の下で、機器等が IT セ

キュリティ評価及び認証制度による認証を取得しているかどうかを評価項目と

して活用することを求めている。

1.2

本書

システ

ライ

な仕様

「最

におけ

調達

仕様」

の構築

する。

. 「業務・

工程

書では、情報

テムの構築等

ン」という）

様書を、図

最適化ガイド

ける要求事項

達者は、「セ

」を提案書に

築等におけ

。

・システ

報システムの

等は、「業務

）で定められ

1.1 に示す。

図 1.1 最適

ドライン」で

項」で求めら

セキュリティ

に含めて提案

るセキュリテ

ム最適化

の構築等を外

務・システム

れた工程及び

適化ガイドラ

で定める工程

られる事項を

要求仕様」

案させる。こ

ティ要件及び

-6-

化指針

外部委託によ

最適化指針

び仕様書に従

ラインに基づ

程に沿って「

を行う手順の

を調達仕様

この手順につ

びセキュリテ

（ガイド

より行うこと

（ガイドライ

従うものとす

づく情報シス

1.1 政府機関

の例を、図 1

様書に含めて

ついては、本

ティ機能の検

ライン）

とを前提とす

イン）」（以下

する。その工

ステムの構築

関統一管理基

.2 に示す。

提示し、「セ

本書の 2 章と

検討に関する

」におけ

する。また、

下「最適化ガ

工程と作成す

築等

基準及び技術

セキュリティ

、「情報シス

る解説書」で

ける

情報

ガイド

する主

術基準

ィ提案

ステム

で説明

セ

先に

項につ

キュリティ提

ST 評価・S

ついては、本

提案仕様の妥

ST 確認の手

本書の 3 章で

図

妥当性につい

手続を行わせ

で説明する。

1.2 調達か

-7-

いて第三者に

、その結果

から検収まで

による評価

を提出させる

での関係者の

・確認を得る

る。この手順

の業務

る場合には、

順に関する留

委託

留意事

2. セ

府省

基準

の構築

書の作

の提案

の提案

の構築

方法

2.1

情報

機能

セキュ

明確化

省庁において

に基づき、情

築等は外部委

作成段階か

案を求める必

案に関する審

築等におけ

を説明する。

. セキュ

報システムの

を明確化する

図

ュリティ

化

て情報システ

情報セキュ

委託により行

らセキュリテ

必要がある。

審査方法の概

るセキュリテ

。

リティ要

の構築等を外

る手順を図 2

図 2.1 セキュ

ィ要件

テムの構築等

リティ要件の

行うことが多

ティ要件を検

。本章では、

概要を説明し

ティ要件及び

要件とセ

外部委託によ

2.1 に示す。

ュリティ要件

-8-

とセキ

等を行う場合

の明確化が求

多いと想定さ

検討し、これ

、セキュリテ

し、また、こ

びセキュリテ

セキュリ

より行う場合

件とセキュリ

キュリテ

合には、政府

求められる。

される。この

れを応札者に

ティ要件の作

これらを詳し

ティ機能の検

ティ機能

合に、セキュ

ティ機能の

ティ機能

府機関統一管

一般的には

のため、調達

に提示し、セ

作成方法とセ

しく説明した

検討に関する

能の明確

ュリティ要件

明確化の手順

能の

管理基準及び

は、情報シス

達者は、調達

セキュリティ

セキュリティ

た「情報シス

る解説書」の

確化の手順

件とセキュリ

順

び技術

ステム

達仕様

ィ機能

ィ機能

ステム

の活用

順

リティ

-9-

調達者は、情報システムの構築等において、要求するセキュリティ要件を調達仕様書に

おいて明確に示し、セキュリティ機能を含む提案を適切に審査する必要がある。

「セキュリティ要件及びセキュリティ機能の検討に関する解説書」では、調達仕様に含め

て提示するセキュリティ要件を「セキュリティ要求仕様」といい、「システム概要」、「保護

すべき情報資産」、「前提条件」及び「脅威」の各項目を含めることとしている。また、応

札における提案に応札者が「セキュリティ提案仕様」を含めることを求める。「セキュリテ

ィ提案仕様」には、「セキュリティ要求仕様」の各項目に加えて、その情報システム等に装

備すべきセキュリティ機能を記した「情報セキュリティ対策」、必要に応じて IT セキュリ

ティ評価及び認証制度に基づく機器等の認証について記した「セキュリティ機能を実現す

る機器等」、及び前提条件等の変更に関する事項を記した「制約条件」が含まれている。

このため、「セキュリティ要件及びセキュリティ機能の検討に関する解説書」では、調達

者がセキュリティ要求仕様の作成とセキュリティ提案仕様の審査を行うために、セキュリ

ティ要求仕様の作成とセキュリティ提案仕様の審査のポイントをまとめている。また、同

書の参考例には、政府機関で使用される代表的な情報システムを例として取り上げてセキ

ュリティ要求仕様の事例とセキュリティ提案仕様の審査例を示しているので、審査する際

の参考にすることができる。

情報システムの開発等について委託先を決定し、委託先においてこれを行わせる段階では、

セキュリティ機能の設計が適切に行われていることを第三者機関に評価・確認させる「ST 評価・

ST 確認」の実施を契約に含めて委託先に行わせることもできる。この場合に実施工程等につい

て調達者が留意すべき事項を、本解説書の 3 章で説明している。

2.2

図

キュ

「セキ

キュ

護すべ

. セキュ

及びセ

図 2.2

2.2 に「セキ

リティ要求仕

キュリティ要件

リティ要求仕

べき情報資産

リティ要

キュリテ

「セキュリ

を活

キュリティ要

仕様作成の業

件及びセキュ

仕様の例が示

産、前提条件

要求仕様

ティ機能

ティ要件及

活用したセキ

要件及びセキ

業務の流れを

ュリティ機能

されており、

及び脅威を含

-10-

様作成に

能の検討

及びセキュリ

キュリティ要

キュリティ機

を示す。

能の検討に関す

構築する情

含めたセキュ

おける

に関する

ティ機能の検

要求仕様の作

機能の検討に

する解説書」

報システムに

ュリティ要求仕

「セキュ

る解説書

検討に関する

作成

関する解説書

には情報シ

に類似してい

仕様を作成す

リティ要

書」の活用

る解説書」

書」を活用し

システムにおけ

いる例を参考

することがで

要件

用例

したセ

けるセ

に、保

できる。

2.3

図

キュ

「セ

仕様の

を参照

脅威

示した

様にお

検討す

. セキュ

及びセ

図 2.3

2.3 に「セキ

リティ提案仕

セキュリティ

の審査のポイ

照して審査を

に対する情報

た「保護すべ

おいて変更を

する。

リティ提

キュリテ

「セキュリ

を活

キュリティ要

仕様審査の業

要件及びセ

イントが情報

を行うことが

報セキュリテ

べき情報資産

を提案してい

提案仕様

ティ機能

ティ要件及

活用したセキ

要件及びセキ

業務の流れを

キュリティ機

報システム等

ができる。調

ティ対策の妥

産」、「前提条

いる場合及び

-11-

様の審査

能の検討

及びセキュリ

キュリティ提

キュリティ機

を示す。

機能の検討

等の例ととも

調達者は、セ

妥当性を検討

条件」及び

び制約条件を

の際の

に関する

ティ機能の検

提案仕様の審

機能の検討に

に関する解説

もに記述され

セキュリティ

討し、また、

「脅威」につ

を提示してい

「セキュ

る解説書

検討に関する

審査

関する解説書

説書」にはセ

れており、類

ィ提案仕様で

セキュリテ

ついて、セキ

いる場合には

リティ要

書」の活用

る解説書」

書」を活用し

セキュリティ

類似システム

で提案されて

ティ要求仕様

キュリティ提

は、その妥当

要件

用例

したセ

ィ提案

ムの例

ている

様で提

提案仕

当性も

-12-

3. ST 評価・ST 確認の実施手順

本章では、情報システムの構築等において、ST 評価・ST 確認を行う場合の手順を説明

する。

ST 評価・ST 確認は、IT セキュリティ評価及び認証制度において定められている確認手

続である。ST 評価・ST 確認では、情報システム、開発するソフトウェア及び機器等のセ

キュリティ設計仕様書（セキュリティターゲット、ST）が ISO/IEC 15408 に適合している

ことを、第三者である評価機関が評価し、評価結果を確認機関（IT セキュリティ評価及び

認証制度の運用元である独立行政法人 情報処理推進機構）が確認する。本書の 2 章で説明

したセキュリティ要件とセキュリティ機能の明確化が情報システム、開発するソフトウェ

ア及び機器等の設計において適切に行われていることが、ST 評価・ST 確認を実施するこ

とにより客観的に確認できる。

なお、政府機関統一管理基準及び技術基準では、重要なセキュリティ要件がある情報システ

ムの構築及びソフトウェアの開発において、ST を作成し、ST 評価・ST 確認を取得することを

求めている1。一般的には、情報システムの構築及びソフトウェアの開発は外部委託により行う

ことが多いと想定されることから、調達者は、調達仕様及び契約において委託先に対して ST 評

価・ST 確認の実施を求め、その条件を示す。

1 政府機関統一基準では、セキュリティ機能の装備を第三者による評価に基づき調達者が確認する方法と

して、IT セキュリティ評価及び認証制度に基づく認証の取得を提案の評価に加味する方法と、ST 評価・ST 確認の実施を求める方法がある。製品として調達する機器等（ソフトウェア製品及び機器）には、前者を適用する（統 1.5.1.1(1)(f)、1.5.2.2(1)(b)）。情報システムの構築及びソフトウェアの開発については、個別の仕様に基づき構築・開発を行うことにかんがみ、後者を適用する（統 1.5.2.3(1)(a)(ケ)）。なお、適用条件等の詳細は、「1.1 政府機関統一管理基準及び技術基準における要求事項」を参照されたい。

3.1

ST

工程

ST

ソフ

報シス

ことに

価の

評価

機関統

. ST 評価

T 評価・ST 確

を図 3.1 に示

T は、一般に

トウェアの機

ステム等の機

により作成す

申請をすべき

・ST 確認の

統一管理基準

価・ST 確

確認を委託先

示す。

図

に、設計工程

機能を設計す

機能を設計す

する仕様書で

きである。政

の）申請行為

準及び技術基

確認を実

先に行わせる

3.1 ST 評

程で作成する

するものと想

する一環で、

であり、詳細

政府機関統一

為は設計段階

基準解説書 1

-13-

実施する

る場合に、S

評価・ST 確認

。図 3.1 で

想定している

、情報セキュ

細設計やコー

一管理基準及

階のうちに行

1.5.2.3(1)(a)

工程

T を作成し、

認を実施する

は、基本設計

る。ST は、業

ュリティの側

ーディングに

び技術基準解

われることが

)(ケ)の解説）

、ST 評価・

る工程

計において情

業務仕様やそ

側面に関する

に先立ち確定

解説書では、

が通常の手順

と記述して

ST 確認を受

情報システム

それを実現す

る機能を設計

定し、早期に

、このことを

順である。」

ている。

受ける

ム又は

する情

計する

ST 評

を「（ST

（政府

-14-

また、ST 評価・ST 確認を受ける過程では、評価機関による評価において装備すべきセ

キュリティ機能を追加・変更等すべきであるとの指摘を受ける可能性がある。ST 評価・ST

確認が完了し、ST 確認書が交付されて初めて情報システム等に装備するセキュリティ機能

が最終的に確定することから、情報システムの構築等において手戻りを避ける観点からも、

ST 評価・ST 確認は早期に終了することが重要である。情報システムの構築等を外部委託

する場合には、納品を受けるまでに委託先において ST 評価・ST 確認を終了させ、ST 確認

書を提示させることを原則とする。政府機関統一管理基準及び技術基準解説書では、「開発

が終了するまでにセキュリティ設計仕様書について、ST 評価・ST 確認済みになっている

必要がある」（政府機関統一管理基準及び技術基準解説書 1.5.2.3(1)(a)(ケ)）としている2。

以上のことから、ST 評価・ST 確認を委託先に行わせる場合には、調達仕様に以下の事

項を記載する必要がある。

当該調達において、構築する情報システム（又は開発するソフトウェア）のセキュリ

ティ機能設計に関して ST 評価・ST 確認を受けること。

ST 評価・ST 確認は当該委託業務が終了するまでに終え、取得した ST 確認書を納品

までに提示すること。

これらの事項は、契約にも含めること。

2 構築した情報システム又は開発したソフトウェアの納品までに委託先が第三者機関による ST 評価・ST

確認を受け、その確認書を提示することができないと見込まれる場合には、納品における ST 評価・ST確認の扱いについて調達者及び委託先があらかじめ協議し、合意した内容を契約に含める必要がある。例えば、まず情報システムの構築又はソフトウェアの開発の成果物について納品・検収を行い、別途 ST評価・ST 確認の結果について納品・検収を行う方法がある。なお、これに該当する場合としては、設計の完了から検収までの期間が短い場合が挙げられる。また、ST 評価は第三者機関が行うため、これに要する期間を調達者及び委託先において確実には予測できない点にも留意する必要がある。

3.2

情報

場合が

確認

セ

的には

が多い

こと

認を終

この

下の事

. 基本設

場合の

報システムの

がある。この

を行わせる工

キュリティ機

は、ST 評価

いと想定され

を避けるため

終えることが

のため、この

事項を記載す

計と詳細

ST 評価

の構築等にお

の場合には、

工程を決め、

図 3.2 基

機能の設計は

価・ST 確認

れる。この場

めに、詳細設

が望まれる。

の場合は、基

する必要があ

細設計以

価・ST 確

おいて、基本

調達者は、

ST 評価・

本設計事業者

は情報システ

認を、機能設

場合には、詳

設計の開始ま

（図 3.2 参照

基本設計に関

ある。

-15-

以降とを

確認の実

本設計、詳細

全体の設計

ST 確認の取

者に ST 評価

テム等の機能

計を含む基本

詳細設計を開

までに基本設

照）

関する調達仕

それぞれ

実施につ

細設計以降等

計・開発の工

取得時期を指

価・ST 確認

能を設計する

本設計を担当

開始した後に

設計を担当す

仕様書に、ST

れ別に調

いて

等、工程によ

工程を考慮し

指示する必要

行わせる場合

る一環で行う

当する事業者

にその要求仕

する事業者が

T 評価・ST

調達する

より調達を分

して ST 評価

要がある。

合

うことから、

者に行わせる

仕様が変更さ

が ST 評価・

T 確認に関し

分ける

価・ST

一般

る場合

される

ST 確

して以

-16-

当該調達において、設計する情報システム（又はソフトウェア）のセキュリティ機能

設計に関して ST 評価・ST 確認を受けること。

ST 確認書を X 年 A 月 B 日までに提示すること3。

これらの事項は、契約にも含める。

3 この場合にも、前節の脚注と同様に、ST 評価は第三者機関が行い、これに要する期間を調達者及び委託

先において確実には予測できないため、必要に応じて、この点を考慮した契約等とすることが考えられる。

-17-

3.3. 重要なセキュリティ要件の変更と ST 評価・ST 確認の

有効性

3.3.1. 情報システムの構築等における重要なセキュリティ要件の

変更

情報システムの構築等において ST 評価・ST 確認を終えた後に、前提としていた重要な

セキュリティ要件が変更された場合には、変更された要件に基づく情報システム等に対し

ては、ST 評価・ST 確認の結果は無効となる。

セキュリティ要件の変更は、調達者が委託先に提示した要件や前提が変更となった場合

に起こり得る。例えば、情報システムを設置する物理的環境や業務仕様の変更等、調達仕

様の様々な側面がセキュリティ要件の変更につながる。2 章で示した手順では、「セキュリ

ティ要求仕様」の変更が、セキュリティ要件の変更になり得る。このため、実施した ST 評

価・ST 確認を無効としないためにも、調達仕様において要求仕様を明確に提示すること、

また、契約後にも委託先との間で情報システム等の仕様に関して不明確な事項を残さない

ことが重要である。

ただし、重要なセキュリティ要件の変更が軽微であると情報システムセキュリティ責任

者が判断するときには、ST 評価・ST 確認の結果を引き続き有効なものとして調達側で扱

うことができる4。「重要なセキュリティ要件の変更が軽微である」かどうかの判断において

は、その変更に伴う情報セキュリティ上のリスクの増大について慎重に評価する。

3.3.2. 情報システム等の更改における重要なセキュリティ要件の

変更

ST 評価・ST 確認を実施した情報システム等を更改するとき又は開発中に仕様変更が発

生したときに、重要なセキュリティ要件を変更した場合には、更改等した情報システム等

に対して、ST 評価・ST 確認の結果は無効である。必要があれば、更改等した情報システ

ム等において、ST 評価・ST 確認をあらためて受けることになる。

4 政府機関統一管理基準及び技術基準 1.5.2.3(1)(a)(ケ)のただし書きを参照されたい。

-18-

ただし、重要なセキュリティ要件の変更が軽微であると情報システムセキュリティ責任

者が判断するときには、前項の場合と同様に、ST 評価・ST 確認の結果を引き続き有効な

ものとして調達側で扱うことができる。

3.4. ST 評価・ST 確認における評価保証レベル(EAL)の扱い

ST 評価・ST 確認においては、ST 及び機能仕様書のみを評価する。ST には評価保証レベル

（EAL: Evaluation Assurance Level）を含む「TOE セキュリティ保証要件」も記述するが、こ

れらは評価の対象には含まれない5。このため、調達者は、情報システムの構築等について ST

評価・ST 確認の実施を求める場合に、調達仕様においてこれらを指定する必要はない。

なお、情報システムの構築等においては、作成すると考えられる開発資料の範囲にかんがみ、

EAL は 1 又は 2 とすることが通常のこととして想定される。

5 評価保証レベル（EAL）及び TOE セキュリティ保証要件は、IT セキュリティ評価及び認証制度におけ

る認証において評価の対象となる。その内容については、「4.1 認証に関する確認事項」を参照されたい。

-19-

4. 認証製品の活用について

政府機関統一管理基準及び技術基準には、IT セキュリティ評価及び認証制度に基づく認

証を取得した機器等の活用に関する遵守事項がある（1.5.1.1(1)(f) 及び 1.5.2.2(1)(b)、1 章

を参照）。本章では、認証取得を調達における評価に含める際のポイントを説明する。

4.1. 認証に関する確認事項

以下に製品の認証に関する確認のポイントを示す。

（１） 認証されたセキュリティ機能の確認

調達者は、認証取得を製品の評価に活用する場合は、当該製品において想定す

る脅威への対策として求めるセキュリティ機能を明確にし、他方では、認証され

た機器等の認証されたセキュリティ機能を十分に理解する必要がある。認証され

たセキュリティ機能が求めるセキュリティ機能と異なる場合には、期待する認証

を取得した製品には該当しない。認証されたセキュリティ機能は、認証報告書又

はセキュリティ設計仕様書で確認することができる。

（２） 前提条件・使用環境の確認

認証されたセキュリティ機能は、使用する前提条件、使用環境により、不十分

であったり、不適切であったりする場合がある。このため、認証の前提条件、環

境条件を認証報告書又はセキュリティ設計仕様書で調べ、使用する環境に合致し

ているか否かを確認する必要がある。

（３） セキュリティ保証要件及び評価保証レベル（EAL）について

IT セキュリティ評価及び認証制度に基づく認証においては、ISO/IEC 15408 に

基づき、セキュリティ保証要件が明示される。セキュリティ保証要件とは、セキ

ュリティ機能が当該製品において実現されていることを評価する際にその根拠と

した証拠等の範囲・程度を示すものである。また、評価保証レベル（EAL:

Evaluation Assurance Level）とは、標準的なものとして定めたセキュリティ保証

要件であり、レベル 1 からレベル 7 までの 7 段階の EAL が定められている。一般

に、認証におけるセキュリティ保証要件は EAL で示すことが多い。

-20-

セキュリティ保証要件及び EAL は、認証製品のセキュリティ機能に関して実施

した評価の程度を示すものであり、セキュリティ機能やセキュリティ機能強度を

表すものではない。

調達において機器等における認証取得を提案の評価の要素に加える場合には、

その評価において求める EAL を指定することもできるが、機器等を利用する情報

システムや業務の重要性等に見合った EAL を指定することが重要である。特に、

高い EAL を指定する場合は、 製品の調達コストや調達の透明性・公平性に対し

て影響を与えることもあるので、 しかるべき EAL の指定が望まれる。

EAL の選定の目安として以下のものが挙げられている（独立行政法人 情報処理

開発機構）。

EAL1：クローズな環境での運用を前提に安全な利用や運用が保証された場合に用

いられる製品の保証レベル。

EAL2：利用者や開発者が限定されており、安全な運用を脅かす重大な脅威が存在

しない場合に用いられる製品の保証レベル。

EAL3：不特定な利用者が利用できる環境。不正対策が要求される場合に用いられ

る製品の保証レベル。

EAL4：商用製品やシステムにおいて高度なセキュリティ確保を実現するために、

セキュリティを考慮した開発と生産ラインを導入して生産される製品の保証レベ

ル。

4.2. 認証製品情報の利用法

前節で述べた認証製品に関する情報の調査法は、「情報システムの構築等におけるセキュ

リティ要件及びセキュリティ機能の検討に関する解説書」の５章で詳細に説明している。

付録

ST

る解説

本書

設計

機関に

価中に

設計の

能とな

図

以下

（１）

記

録 セ

T は、ISO/IE

説的な説明を

書の手順にお

したセキュリ

に依頼し、そ

に ST に関し

の手直し等を

なる。

A に、ST の

図

下に、ST に

） ST 概説

ST 全体の

記述されてい

１）ST 参

・ ST を

セキュリ

EC 15408 P

を示す。

おいては、S

リティ機能を

その後、認証

して設計上の

を行うことで

の構成を示す

図 A. ST の

に含める項目

の序説。ST や

いる。

参照

を一意に識別

リティ設

art 1 附属書

T は、情報シ

を評価するた

証機関に ST

の不備や不足

で、セキュリ

す。

構造 （ISO

を ISO/IEC

や TOE（評価

別するための

-21-

設計仕

書 C に定義さ

システムの構

ために作成す

T 評価の結果

足のあること

リティ機能に

O/IEC 1540

C 15408 に従

価対象、Ta

の情報

仕様書

されている。

構築等の基本

する。委託先

果を持って ST

が判明した

に問題のない

08 に基づき

従い説明する

rget Of Eva

（ST）

ここでは、

本設計がほぼ

先は、ST の第

T 確認を申請

場合にも、情

い情報システ

IPA にて作

る。

aluation）の

ST の内容に

ぼ完了した時

第三者評価を

請する。なお

情報システム

テムの構築等

作成）

の概要、が簡

に関す

時点で、

を評価

お、評

ム等の

等が可

簡潔に

-22-

２）TOE 参照

・ TOE を一意に識別するための情報

３）TOE 概要

・ TOE の使用法、動作環境の記述と、主要なセキュリティ機能の特徴の要約

・ TOE 種別

４）TOE 記述

・ TOE の範囲を明確にする情報

（２） 適合性主張

ST の適合状況が記述されている。

１）CC6適合主張

・ 適合された CC のバージョン、言語

・ CC Part 2 と Part 3 への適合/拡張

２）パッケージ主張

・ EAL の適合、または追加

３）PP 主張

・ PP の適合（正確適合、論証適合）

４）適合主張根拠

・ PP に適合している際、その適合の根拠

（３） セキュリティ課題定義

TOE が対処する必要がある、セキュリティ上の課題を定義する。 脅威、前提条件、

組織のセキュリティ方針（OSP: Organisational Security Policies）が記述されている。

１）脅威

・ TOE やその運用環境によって対抗しなければならない脅威

２）組織のセキュリティ方針(OSP)

・ TOE の運用環境により課せられる、規則、手続き、ガイドラインなど

３）前提条件

・ TOE が機能するために、TOE 利用者が満たす必要がある運用環境の条件

【ポイント】

6 Common Criteria for Information Technology Security Evaluation の略称。

-23-

ST 読者が想定している情報システム等に対して、TOE が脅威や組織のセキュリテ

ィ方針に適合しているか否かを判断できるように説明されている。前提条件には、

認証製品を利用する際に整備すべき前提条件が記述されている。

（４） セキュリティ対策方針

セキュリティ課題定義によって定義される課題に対し、対抗する解決策を記述する。

１）TOE のセキュリティ対策方針

・ TOE が持つ機能で対抗、または実現する解決策

２）運用環境のセキュリティ対策方針

・ 運用環境において達成する必要があり、TOE を支援するために実装する技術・

手続きに関する手段

３）セキュリティ対策方針根拠

・ 脅威への対抗、OSP の実施、前提条件の充足について、すべてのセキュリティ

対策方針の効果を分析

【ポイント】

セキュリティ対策方針の実現方法に関する詳細な説明ではない。

脅威あるいは OSP を踏まえてセキュリティ対策方針が「何を」解決するの

か記述されている。

脅威、OSP、前提条件に対して、抽出された対応方針で十分であるかどうか検討さ

れて記述されている。

【ポイント】

各脅威への対応の十分性（脅威の除去、脅威の軽減、脅威の緩和）が検討さ

れて記述されている。

各 OSP の実現に貢献していることが記述されている。

-24-

（５） 拡張コンポーネント定義

CC に規定されていない、セキュリティ機能コンポーネントまたはセキュリティ保証

コンポーネントを定義する。

１）拡張コンポーネント定義

・ CC part2 に規定されていない、ST/PP 作成者が定義したセキュリティ機能コン

ポーネントの定義

・ CC Part3 に規定されていない、ST/PP 作成者が定義したセキュリティ保証コン

ポーネント定義

・ 拡張コンポーネントが存在する場合、「第２章 CC 適合主張」において、「拡張」

と記述する

- CC Part2 拡張

- CC Part3 拡張

（６） IT セキュリティ要件

TOE セキュリティ対策方針から CC Part2/Part3 を用いた書換えと、セキュリティ

機能要件を満たす保証の範囲を記述する

１）セキュリティ機能要件(SFR)

・ 自然言語で作成された TOE セキュリティ対策方針からの、TOE の機能性につ

いてのより正確な記述

・ CC Part2 の要件記述を利用

・ TOE 及び IT 環境で実現する機能要件が具体的に記述されている。CC Part2

の記述をそのまま使用されている場合と、修整して使用されている場合があ

る。

Assignment(割付)：指定された項目を具体化

Selection(選択)：指定された項目の中から選択

Refinement(詳細化)：必要に応じて具体化

Iteration(繰り返し)：同じ条件の繰り返し(複数の組合せ)

２）セキュリティ保証要件(SAR)

・ TOE の保障範囲についての正確な記述

・ CC Part3 の要件記述を利用

TOE セキュリティ保証要件：TOE への保証要件が記述されている。CC Part3 の

保証パッケージ（EAL1～7）の中から選ばれていることもある。商用製品の多くは、

EAL4 までが選択されている。

-25-

【ポイント】保証要件の妥当性も検討されている。

３）セキュリティ要件根拠

・ すべての TOE セキュリティ対策方針が、SFR によって効果的に対処されてい

ることの根拠

・ 選択された SAR が適切であることの説明

（７） TOE 要約仕様

TOE がどのようにしてすべての SFR を満たすのかを記述する。

TOE セキュリティ機能と保証手段（セキュリティ保証要件をすべて満たすことを示

す資料）が記述されている。

１）TOE 要約仕様

・ TOE が提供するセキュリティ機能の技術的メカニズム

- TOE の一般的な形態、及び実装を理解できる程度の詳細レベル

（認証： パスワード、トークン、虹彩スキャン、等々）

・ TOE 概要、TOE 記述と一環した記述、及び詳細度の増加

（例えば、TOE 概要<TOE 記述<TOE 要約仕様）

【ポイント】

ここで定義した機能が TOE に関する各設計書に記述されることになる。