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

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

*目次 [#j43be54a]
#contents

*概要 [#x990ddbc]
-情報セキュリティ、ITサービス（規格と制度）
-ネット、IT、情報化で組織・システムの評価制度が必要になって来た。

*詳細 [#cf4405d0]

**ISO/IEC 15408 [#l11b00f4]

***概要 [#s7da15f4]
TCSEC（Trusted Computer System Evaluation Criteria）など~
を元に策定されたCommon Criteria（CC）と呼ばれる評価基準を定めている。
を元に策定された[[Common Criteria（CC）>#a1337543]]と呼ばれる評価基準を定めている。

-建付けは[[こちら>SC：法制度#pf85eae4]]。

-TCSEC（Trusted Computer System Evaluation Criteria）
--米国国防総省のNCSCによって1983年に策定されたセキュリティ評価基準
--コンピュータシステムの信頼性を図るための指標として用いられている。
--A1 - D の division、classに分類されたセキュリティ要求レベル
--レインボーシリーズ : 技術的文書とポリシー文書のセット

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

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

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

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

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

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


***Common Criteria（CC） [#a1337543]
主要な概念
-コンピュータ・セキュリティのための国際規格（[[ISO/IEC 15408>#l11b00f4]]）

-プロテクションプロファイル (PP, Protection Profile)~
-IT製品・システムに対して、情報セキュリティを評価し認証する評価基準を定める。

-名称~
Common Criteria（CC）
--Common Criteria for Information Technology Security Evaluation
--情報技術セキュリティ評価のためのコモンクライテリア

-概念

--プロテクションプロファイル (PP, Protection Profile)~
セキュリティ要件（要求仕様）を特定する文書（利用者が書く）。

-セキュリティターゲット (ST, Security Target)
--製品のセキュリティ性能を特定する文書（利用者が書く）。
--製品を評価・認証するための基礎として使用する。
--ST作成講座 - IPA~
--セキュリティターゲット (ST, Security Target)
---製品のセキュリティ性能を特定する文書（利用者が書く）。
---製品を評価・認証するための基礎として使用する。
---ST作成講座 - IPA~
https://www.ipa.go.jp/security/jisec/seminar/documents/st_v3_2_20120702.pdf

-評価対象 (TOE, Target Of Evaluation)~
--評価対象 (TOE, Target Of Evaluation)~
簡単に言えば、ST にセキュリティ主張が記述された製品。

-セキュリティ機能要件 (SFR, Security Functional Requirements)
--製品が提供する個々のセキュリティ機能を規定する条文。
--標準カタログとして PP や、ST を書くときに使用する。
--セキュリティ機能要件 (SFR, Security Functional Requirements)
---製品が提供する個々のセキュリティ機能を規定する条文。
---標準カタログとして PP や、ST を書くときに使用する。

-セキュリティ保証要件 (SAR, Security Assurance Requirements)~
--セキュリティ保証要件 (SAR, Security Assurance Requirements)~
セキュリティ機能性の主張に製品が準拠していることを保証するために、~
製品開発の間にとられる施策を規定する条文。

-評価保証レベル (EAL, Evaluation Assurance Level)~
--評価保証レベル (EAL, Evaluation Assurance Level)~
製品の開発過程全般をカバーする保証要件のパッケージ、7段階の厳格さに対応する。


***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;広範囲のテストを使用する包括的分析を要求|

***国内対応状況 [#ubacf8c2]
-[[建付け>SC：法制度#pf85eae4]]を参照（JIS化）。

-IPAが認証機関を運営している

--評価及び認証制度として「JISEC」が運用されている。
---ITセキュリティ評価及び認証制度
---JISEC : Japan Information Technology Security Evaluation and Certification Scheme

--情報処理推進機構：情報セキュリティ：ITセキュリティ評価及び認証制度(JISEC)：評価認証制度概要~
https://www.ipa.go.jp/security/jisec/scheme/index.html

**FIPS140(FIPS PUB 140-2) [#sd4874f0]

***概要 [#z0312b04]
FIPS 140 (Federal Information Processing Standardization 140)

-暗号モジュール（ハード＆ソフト）に関する~
セキュリティ要件の仕様を規定する米国連邦標準規格。

-FIPS（連邦情報処理標準）はNIST（米国国立標準技術研究所）が発行する。

-2013年6月現在、規格の最新版は2001年5月25日発行のFIPS 140-2。

***国内対応状況 [#i93f8071]
IPAが認証機関を運営している

-名称
--暗号モジュール試験及び認証制度
--JCMVP : Japan Cryptographic Module Validation Program

-内容
--FIPS 140-2 が主要な提供文書となっている規格に ISO/IEC 19790:2006 があり、
--この ISO/IEC 19790:2006 を基に作成された X 19790：2007 の認証を行う。

**PCI DSS [#ib3cb3bd]
-PCI DSS : Payment Card Industry Data Security Standard
-PCIデータセキュリティスタンダード

***概要 [#jb57c52c]
-クレジットカード情報および取り引き情報を保護するセキュリティ基準
-2004年12月、クレジット業界で共同策定されたグローバルセキュリティ基準 
-国際ペイメントブランド5社（JCB・American Express・Discover・Master・VISA）

***6つの目標とそれに対応する12の要件 [#v6981f24]
+安全なネットワークとシステムの構築と維持
++カード会員データを保護するために、ファイアウォールをインストールして維持する
++システムパスワードおよびその他のセキュリティパラメータにベンダ提供のデフォルト値を使用しない
+カード会員データの保護
++保存されるカード会員データを保護する
++オープンな公共ネットワーク経由でカード会員データを伝送する場合、暗号化する
+脆弱性管理プログラムの整備
++マルウェアにしてすべてのシステムを保護し、ウィルス対策ソフトウェアを定期的に更新する
++安全性の高いシステムとアプリケーションを開発し、保守する
+強力なアクセス制御手法の導入
++カード会員データへのアクセスを、業務上必要な範囲内に制限する
++システムコンポーネントへのアクセスを識別・認証する
++カード会員データへの物理アクセスを制限する
+ネットワークの定期的な監視およびテスト
++ネットワークリソースおよびカード会員データへのすべてのアクセスを追跡および監視する
++セキュリティシステムおよびプロセスを定期的にテストする
+情報セキュリティポリシーの整備
++すべての担当者の情報セキュリティに対応するポリシーを整備する

***認定審査機関 [#bd405068]
-QSA
--Qualified Security Assessor
--訪問審査を行い、PCI DSSの順守状況を確認・判定する。

-ASV
--Approved Scanning Vendors
--PCI DSS要件11.2に規定される、脆弱性スキャンサービスを提供するベンダ。

-PFI
--PCI Forensic Investigator
--PCI DSS要件に規定されるフォレンジック調査を行う認定団体。

-PA-QSA (P2PE)~
P2PEアプリケーションを開発するベンダーに対して~
--インタビュー
--ドキュメント調査
--システム設定調査

>などの審査を正式に行う。

-P2PE QSA~
PCI Point-to-Point Encryptionへの認定を調査する。

***PCI DSS対応のプロセス [#z7e860ee]
-PCI DSS準拠対象範囲の確定
-改善計画の立案
-実装と確認
-テスト実施と本審査~
PCI DSS認証取得の方法
--QSAによる訪問審査
--ASVによるサイトスキャン検査

**CMMI [#u340f404]
CMMI : Capability Maturity Model Integration（能力成熟度モデル統合）

***概要 [#pfb5912f]
-組織のパフォーマンスを向上させる枠組み。~
組織がプロセスをより適切に管理できるようになることを~
目的として遵守するべき指針を体系化したもの。

--工学、PM、組織開発の分野に適応される。

--組織がプロセスを定め洗練するための手段を提供、~
遵守するべき指針を体系化し、評価・改善できる。

--アプレイザルやアセスメント~
CMMIのプロセスモデルを使用して~
組織のプロセス状況を診断すること。

-年表
--2000年: CMMI v1.02 公表。
--2002年: CMMI v1.1 公表。

--2006年
---CMMI v1.2 公表
---CMMI-DEV（CMMI for Development）に改称

--2007年~
IT調達のCMMI-AQC（CMMI for Acquisition）
--2009年~
ITサービスのCMMI-SVC（CMMI for Service）

--2010年
---CMMI v1.3 公表。
---CMMI-DEV, CMMI-AQC, CMMI-SVC

***CMM [#d53ec615]
-もともとは（個別の）能力成熟度モデル (CMM) として開発された。

-CMM : Capability Maturity Model（能力成熟度モデル）
--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）~
製品開発に焦点を当てた統合プロダクト開発成熟度モデル

-年表
--1987年:~
SEI-87-TR-24（SW-CMM 質問書）公表。
--1989年:~
書籍 Managing the Software Process が出版される。
--1990年:~
SW-CMM v0.2 公表。（最初の外部向け公表、資料を参照）
--1991年:~
SW-CMM v1.0 公表。
--1993年:~
SW-CMM v1.1 公表。
--1996年:~
[[SSE-CMM>#y043a016]] v1.0 公表。
--1997年:~
SW-CMM の開発を終了する（CMMIを開発するため）。

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

-能力レベル（連続表現）~
レベル0-3までの4段階で能力レベルを表し、~
プロセスの達成度の評価に使用する。
--レベル0 : 不完全な
--レベル1 : 実施された
--レベル2 : 管理された
--レベル3 : 定義された

***プロセス領域 [#v7d137e4]
-プロセス改善における活動を分類したもの

-各プロセス領域には固有ゴールと共通ゴールがあり
--固有ゴールには固有プラクティスが設定
--共通ゴールには共通プラクティスが設定

-CMMI-DEVのプロセス領域
|連続表現のグループ|プロセス領域|>|>|>|段階表現のグループ（成熟度レベル）|h
|プロセス管理|OPF：組織プロセス重視||3|||
|~|OPD：組織プロセス定義＋IPPD||3|||
|~|OT：組織トレーニング||3|||
|~|OPP：組織プロセス実績|||4||
|~|OID：組織改革と展開||||5|
|プロジェクト管理|PP：プロジェクト計画策定|2||||
|~|PMC：プロジェクトの監視と制御|2||||
|~|SAM：供給者合意管理|2||||
|~|IPM：統合プロジェクト管理+IPPD||3|||
|~|RSKM：リスク管理|||3||
|~|QPM：定量的プロジェクト管理|||4||
|エンジニアリング|RD：要件開発|||3||
|~|REQM：要件管理|2||||
|~|TS：技術解|||3||
|~|PI：成果物統合|||3||
|~|VER：検証|||3||
|~|VAL：妥当性確認|||3||
|支援|CM：構成管理|2||||
|~|PPQA：プロセスと成果物の品質保証|2||||
|~|MA：測定と分析|2||||
|~|DAR：決定分析と解決|||3||
|~|CAR：原因分析と解決||||5|

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

***SSE-CMM [#y043a016]
-SSE-CMM : Systems Security Engineering - Capability Maturity Model 
-セキュリティエンジニアリングに関する組織能力成熟度モデル
-国際的な非営利組織であるISSEAによってメンテナンスされている。
-2002年10月に国際標準化され、ISO/IEC 21827として出版されている。

**PCI DSS [#ib3cb3bd]
-PCI DSS : Payment Card Industry Data Security Standard
-PCIデータセキュリティスタンダード

***概要 [#jb57c52c]
-クレジットカード情報および取り引き情報を保護するセキュリティ基準
-2004年12月、クレジット業界で共同策定されたグローバルセキュリティ基準 
-国際ペイメントブランド5社（JCB・American Express・Discover・Master・VISA）

***6つの目標とそれに対応する12の要件 [#v6981f24]
+安全なネットワークとシステムの構築と維持
++カード会員データを保護するために、ファイアウォールをインストールして維持する
++システムパスワードおよびその他のセキュリティパラメータにベンダ提供のデフォルト値を使用しない
+カード会員データの保護
++保存されるカード会員データを保護する
++オープンな公共ネットワーク経由でカード会員データを伝送する場合、暗号化する
+脆弱性管理プログラムの整備
++マルウェアにしてすべてのシステムを保護し、ウィルス対策ソフトウェアを定期的に更新する
++安全性の高いシステムとアプリケーションを開発し、保守する
+強力なアクセス制御手法の導入
++カード会員データへのアクセスを、業務上必要な範囲内に制限する
++システムコンポーネントへのアクセスを識別・認証する
++カード会員データへの物理アクセスを制限する
+ネットワークの定期的な監視およびテスト
++ネットワークリソースおよびカード会員データへのすべてのアクセスを追跡および監視する
++セキュリティシステムおよびプロセスを定期的にテストする
+情報セキュリティポリシーの整備
++すべての担当者の情報セキュリティに対応するポリシーを整備する

***認定審査機関 [#bd405068]
-QSA
--Qualified Security Assessor
--訪問審査を行い、PCI DSSの順守状況を確認・判定する。

-ASV
--Approved Scanning Vendors
--PCI DSS要件11.2に規定される、脆弱性スキャンサービスを提供するベンダ。

-PFI
--PCI Forensic Investigator
--PCI DSS要件に規定されるフォレンジック調査を行う認定団体。

-PA-QSA (P2PE)~
P2PEアプリケーションを開発するベンダーに対して~
--インタビュー
--ドキュメント調査
--システム設定調査

>などの審査を正式に行う。

-P2PE QSA~
PCI Point-to-Point Encryptionへの認定を調査する。

***PCI DSS対応のプロセス [#z7e860ee]
-PCI DSS準拠対象範囲の確定
-改善計画の立案
-実装と確認
-テスト実施と本審査~
PCI DSS認証取得の方法
--QSAによる訪問審査
--ASVによるサイトスキャン検査

**[[ISO/IEC 20000 及び ITIL>SM：法制度 - ISO/IEC 20000 及び ITIL]] [#a4f852f1]

***[[情報セキュリティ管理>SM：法制度 - ISO/IEC 20000 及び ITIL#x9e7f3b1]] [#v84cd835]
-情報セキュリティ基本方針
-情報セキュリティ管理策
-情報セキュリティの変更及びインシデント

*参考 [#ef6a3c90]

**Wikipedia [#x56d47eb]
-コモンクライテリア~
https://ja.wikipedia.org/wiki/%E3%82%B3%E3%83%A2%E3%83%B3%E3%82%AF%E3%83%A9%E3%82%A4%E3%83%86%E3%83%AA%E3%82%A2
-能力成熟度モデル統合~
https://ja.wikipedia.org/wiki/%E8%83%BD%E5%8A%9B%E6%88%90%E7%86%9F%E5%BA%A6%E3%83%A2%E3%83%87%E3%83%AB%E7%B5%B1%E5%90%88
-PCIデータセキュリティスタンダード~
https://ja.wikipedia.org/wiki/PCI%E3%83%87%E3%83%BC%E3%82%BF%E3%82%BB%E3%82%AD%E3%83%A5%E3%83%AA%E3%83%86%E3%82%A3%E3%82%B9%E3%82%BF%E3%83%B3%E3%83%80%E3%83%BC%E3%83%89
トップ   新規 一覧 単語検索 最終更新   ヘルプ   最終更新のRSS