SC：法制度 - 情報セキュリティ、ITサービス（規格と制度）のバックアップ差分(No.4)

追加された行はこの色です。
削除された行はこの色です。
「[[.NET 開発基盤部会 Wiki>http://dotnetdevelopmentinfrastructure.osscons.jp]]」は、「[[Open棟梁Project>https://github.com/OpenTouryoProject/]]」,「[[OSSコンソーシアム .NET開発基盤部会>https://www.osscons.jp/dotNetDevelopmentInfrastructure/]]」によって運営されています。

-[[戻る>SC：法制度]]

*目次 [#j43be54a]
#contents

*概要 [#x990ddbc]
情報セキュリティ、ITサービス（規格と制度）

*詳細 [#cf4405d0]

**ISO/IEC 15408 [#l11b00f4]
-概要は[[こちら>SC：法制度#pf85eae4]]。
-建付けは[[こちら>SC：法制度#pf85eae4]]。

-ST作成講座 - IPA~
https://www.ipa.go.jp/security/jisec/seminar/documents/st_v3_2_20120702.pdf

***概要 [#s7da15f4]
-効果

--サプライサイド
---国際的に通用するセキュリティ品質を持った製品の出荷が可能になる。
---認証を得ることで、ある程度の宣伝効果が期待される。

--デマンドサイド~
認証を受けた製品を選定することで、セキュリティ面での不安が軽減される。

-国内対応状況
--[[建付け>SC：法制度#pf85eae4]]を参照（JIS化）。
--評価及び認証制度として「JISEC」が運用されている。
---情報処理推進機構：情報セキュリティ：ITセキュリティ評価及び認証制度(JISEC)：評価認証制度概要~
https://www.ipa.go.jp/security/jisec/scheme/index.html

-国際協定

--ISO/IEC 15408の国際協定であるCCRA（Common Criteria Recognition Arrangement）

--加盟国の何れかで評価・認定された製品は相互に認証書が通用する。
---Certificate authorising participants : 従来からあるメンバのカテゴリ
---Certificate consuming participants : 他の参加国で認証された製品又はシステムを受け入れる。

--日本は、2003/10にCCRA加盟

***Part1 総則および一般モデル [#v6de3493]
製品およびシステムのセキュリティを確保するための枠組みを示す。

-以下の作成の規定

--プロテクション・プロファイル（PP : Protection Profile）~
PP：機器・システムの分野ごとのセキュリティ要求仕様

--セキュリティ・ターゲット（ST : Security Target）~
セキュリティ機器、システム（TOE : Target Of Evaluate）の基本設計仕様の作成
---製品やシステムに関するセキュリティ上の脅威分析
---脅威に対するセキュリティ対策方針の策定
---その対策を実現するためのセキュリティ要件の設計
---そのセキュリティ要件を満たすために実装する機能の要約仕様の作成
---保証を確保するための開発内容

-セキュリティ・ターゲット（ST）の内容

--SE概説
---ST参照
---TOE概要
---TOE参照
---TOE記述

--適合主張
---CC適合主張
---PP主張、パッケージ主張
---適合根拠

--セキュリティ課題定義
---脅威
---組織のセキュリティ方針
---前提条件

--セキュリティ対策方針
---TOEのセキュリティ対策方針
---運用環境のセキュリティ対策方針
---セキュリティ対策方針根拠

--拡張コンポーネント定義
---拡張コンポーネント定義

--セキュリティ要件
---セキュリティ機能要件
---セキュリティ保証要件
---セキュリティ要件根拠

--TOE要約仕様
---TOE要約仕様

***Part2 セキュリティ機能要件 [#t25e6c60]
-セキュリティ確保に必要な機能について内容を規定。

-これは、[[STやPP>#v6de3493]]を作成するために用いられる。

-階層構造で記述
--第１階層：機能クラス（１１項目）
--第２階層：機能ファミリー
--第３階層：機能コンポーネント
--第４階層：機能エレメント

-機能クラス（１１項目）
|#|機能クラス|略称|概要|h
|1|セキュリティ監査（Security Audit）|FAU|セキュリティ・イベント情報の認識 / 記録 / 保存 / 分析の要件|
|2|通信（Communication）|FCO|通信の参加者の識別の保証する否認防止に関する要件|
|3|暗号サポート（Cryptographic Support）|FCS|各種暗号操作の要件|
|4|利用者データ保護（User Data Protection）|FDP|アクセス制御、フロー制御、利用者データの保護&br;（入出力時のセキュリティ属性保護、転送時の機密性保護）の要件|
|5|識別と認証（Identity And Authentication）|FIA|利用者のIDの確立と検証の要件|
|6|セキュリティ管理（Security Management）|FMT|セキュリティ属性、機能に関するデータの管理に関する要件|
|7|プライバシー（Privacy）|FPR|他社によるIDの発見・悪用の防止に関する要件|
|8|TOEセキュリティ機能の保護（Protection of the TOE）|FPT|セキュリティ関連のメカニズムと内部データの正当性及び保護に関する要件|
|9|資源利用（Resource Utilisation）|FRU|資源の耐障害性、優先度制御、資源割当に関する要件|
|10|TOEアクセス（TOE Access）|FTA|利用者とTOE間のセッション確立の制御に関する要件|
|11|高信頼パス/チャネル（Trusted Path/Channel）|FTP|利用者とTOE間の高信頼性通信路に関する要件|

***Part3 セキュリティ保証要件 [#a28173a0]
-セキュリティ確保に必要な信頼性について内容を規定。
-製品やシステムに対して、セキュリティ要件の実装の確かさを確認する要件が記述されている。

--Part2と同じく、~
階層構造をもって記述される要件は10のクラスから構成される。

|#|保証クラス|略称|概要|h
|1|プロテクションプロファイル評価（Protection Profile Evaluation）|APE|PPが正しく記述されていることを検査|
|2|セキュリティターゲット評価（Security Target Evaluation）|ASE|STが正しく記述されていることを検査|
|3|開発（Development）|ADV|STに従って設計書が正しく記述されていることを検査|
|4|ガイダンス文書（Guidance Document）|AGD|マニュアルに（TOEをセキュアな状態で使用するために）&br;必要な事項が適切に記述されていることを検査|
|5|ライフサイクルサポート（Lifecycle Support）|ALC|開発から保守に使用する手続きがセキュアで適切に行われたことを検証|
|6|テスト（Tests）|ATE|TOEがST記述、設計書仕様に従うかどうかを、開発者自身と評価者のテストにより検証|
|7|脆弱性評定（Vulnerability assessment）|AVA|脆弱性に関して、運用環境で問題のないレベルであることを検証する。|
|8|統合（Composition）|ACO|統合 TOE が、すでに評価されたソフトウェア、ファームウェア、ハードウェアの&br;コンポーネントが提供するセキュリティ機能性に依存する場合に&br;セキュアに動作するという信頼を提供するために策定された保証要件を特定|

--またPart3ではEALが規定されている。
---評価保証レベル（EAL : Evaluation Assurance Level）
---実装の確かさの評価方法についてのレベル（7段階）。

|#|>|レベル|概要|要求と効果|h
|1|EAL1|機能テスト|特定の機能の要件が対処されていることを最小の費用で評価できるため、&br;セキュリティへの脅威が重大ではない場合に適用される。|保証の増加を提供する。|
|2|EAL2|構造テスト|低レベルから中レベルの保証されたセキュリティを要する、&br;開発資料を提供できないようなレガシー・システムの&br;安全性を確保するようなケースに適用される。|EAL1の保証に加え、&br;開発者テスト、評価者テストを要求|
|3|EAL3|方式テスト及びチェック|中レベルの保証されたセキュリティを要する環境で、&br;TOEとその開発の完全な調査を要する状況に適用される。|EAL2の保証に加え、&br;テストの網羅性や開発時の&br;TOE改竄防止メカニズムや手続を要求|
|4|EAL4|方式設計、テスト及びレビュー|中レベルの保証されたセキュリティを要する既存の商用製品の開発で&br;エンジニアリングコストの追加を受け入れられる状況で適用される。|EAL3の保証に加え、&br;より多くの設計記述、実装表現、&br;改善されたTOE改竄防止メカニズムや手続を要求|
|5|EAL5|準形式的設計及びテスト|高レベルの保証されたセキュリティを要する&br;EAL5レベルの保証をはじめから達成する意図を持って開発で、&br;専門的なセキュリティエンジニアリング技法の&br;適切なコストを負担する場合に適用される。|EAL4の保証に加え、&br;準形式的な設計記述、&br;構造化され分析可能なアーキテクチャ、&br;さらに改善されたTOE改竄防止メカニズムや手続を要求|
|6|EAL6|準形式検証済み設計及びテスト|保護する資産の価値が高く、&br;保証のための追加的な開発コストを正当化するような&br;リスクの高い状況で使用する場合に適用される。|EAL5の保証に加え、&br;準形式的な検証済み設計、実装の構造化表現、&br;さらに広範囲に分析可能なアーキテクチャ構造、&br;さらに広範囲な評価者の脆弱性評定、&br;さらに改善された構成管理と開発環境の制御を要求|
|7|EAL7|形式的検証済み設計及びテスト|リスクが非常に高いか、高い資産価値により、&br;さらに高い開発コストが正当化される場合に適用される。|EAL6の保証に加え、&br;数学的検証を伴う形式的表現と対応、&br;広範囲のテストを使用する包括的分析を要求|

**CMMI [#u340f404]
-能力成熟度モデル「統合」
--組織のパフォーマンスを向上させる枠組み。
---工学、PM、組織開発の分野に適応される。
---組織がプロセスを定め洗練するための手段を提供、~
遵守するべき指針を体系化し、評価・改善できる。

-レベル1-5までの5段階で組織プロセスの成熟度レベルを評価できる。
--レベル1 : 初期
--レベル2 : 管理された
--レベル3 : 定義された
--レベル4 : 定量的に管理された
--レベル5 : 最適化している。

***CMM [#d53ec615]
-CMMIの前身
--1980年代半ばに能力成熟度モデル（CMM）として開発された。
--カーネギーメロン大学 (CMU) のソフトウェア工学研究所 (SEI) で開発。
--ソフトウェア工学研究所 (SEI)は、国防総省（DOD）が設置した。
--ワッツ・S・ハンフリー（Watts S. Humphrey）教授が著した「Managing the Software Process」が下敷き。
--マーク・C・ポーク（Mark C. Paulk）やビル・カーティス（Bill Curtis）らが改良を加えて作られた。

-様々な分野のCMM（CMMs）が開発された。

--SW-CMM（CMM for Software）~
ソフトウェア能力成熟度モデル（元祖、1991年発行）

--派生
---SE-CMM（System Engineering CMM）~
システムエンジニアリング能力成熟度モデル
---SA-CMM（Software Acquisition CMM）~
ソフトウェア調達能力成熟度モデル
---P-CMM（People CMM）~
人材開発能力の成熟度モデル
---IPD-CMM（Integrated Product Development CMM）~
製品開発に焦点を当てた統合プロダクト開発成熟度モデル

***[[IDEALモデル>高度午前 - システム戦略#g80dd72a]] [#j66c7337]

**PCI DSS [#ib3cb3bd]

**ISO/IEC 20000 及び ITIL [#a4f852f1]
SC：法制度 - 情報セキュリティ、ITサービス（規格と制度） のバックアップ差分(No.4)

SC：法制度 - 情報セキュリティ、ITサービス（規格と制度）のバックアップ差分(No.4)
