.NET 開発基盤部会 Wiki」は、「Open棟梁Project」,「OSSコンソーシアム .NET開発基盤部会」によって運営されています。

目次

概要

詳細

ISO/IEC 15408

概要

TCSEC(Trusted Computer System Evaluation Criteria)など
を元に策定されたCommon Criteria(CC)と呼ばれる評価基準を定めている。

Common Criteria(CC)

Part1 総則および一般モデル

製品およびシステムのセキュリティを確保するための枠組みを示す。

Part2 セキュリティ機能要件

Part3 セキュリティ保証要件

#保証クラス略称概要
1プロテクションプロファイル評価(Protection Profile Evaluation)APEPPが正しく記述されていることを検査
2セキュリティターゲット評価(Security Target Evaluation)ASESTが正しく記述されていることを検査
3開発(Development)ADVSTに従って設計書が正しく記述されていることを検査
4ガイダンス文書(Guidance Document)AGDマニュアルに(TOEをセキュアな状態で使用するために)
必要な事項が適切に記述されていることを検査
5ライフサイクルサポート(Lifecycle Support)ALC開発から保守に使用する手続きがセキュアで適切に行われたことを検証
6テスト(Tests)ATETOEがST記述、設計書仕様に従うかどうかを、開発者自身と評価者のテストにより検証
7脆弱性評定(Vulnerability assessment)AVA脆弱性に関して、運用環境で問題のないレベルであることを検証する。
8統合(Composition)ACO統合 TOE が、すでに評価されたソフトウェア、ファームウェア、ハードウェアの
コンポーネントが提供するセキュリティ機能性に依存する場合に
セキュアに動作するという信頼を提供するために策定された保証要件を特定
#レベル概要要求と効果
1EAL1機能テスト特定の機能の要件が対処されていることを最小の費用で評価できるため、
セキュリティへの脅威が重大ではない場合に適用される。
保証の増加を提供する。
2EAL2構造テスト低レベルから中レベルの保証されたセキュリティを要する、
開発資料を提供できないようなレガシー・システムの
安全性を確保するようなケースに適用される。
EAL1の保証に加え、
開発者テスト、評価者テストを要求
3EAL3方式テスト及びチェック中レベルの保証されたセキュリティを要する環境で、
TOEとその開発の完全な調査を要する状況に適用される。
EAL2の保証に加え、
テストの網羅性や開発時の
TOE改竄防止メカニズムや手続を要求
4EAL4方式設計、テスト及びレビュー中レベルの保証されたセキュリティを要する既存の商用製品の開発で
エンジニアリングコストの追加を受け入れられる状況で適用される。
EAL3の保証に加え、
より多くの設計記述、実装表現、
改善されたTOE改竄防止メカニズムや手続を要求
5EAL5準形式的設計及びテスト高レベルの保証されたセキュリティを要する
EAL5レベルの保証をはじめから達成する意図を持って開発で、
専門的なセキュリティエンジニアリング技法の
適切なコストを負担する場合に適用される。
EAL4の保証に加え、
準形式的な設計記述、
構造化され分析可能なアーキテクチャ、
さらに改善されたTOE改竄防止メカニズムや手続を要求
6EAL6準形式検証済み設計及びテスト保護する資産の価値が高く、
保証のための追加的な開発コストを正当化するような
リスクの高い状況で使用する場合に適用される。
EAL5の保証に加え、
準形式的な検証済み設計、実装の構造化表現、
さらに広範囲に分析可能なアーキテクチャ構造、
さらに広範囲な評価者の脆弱性評定、
さらに改善された構成管理と開発環境の制御を要求
7EAL7形式的検証済み設計及びテストリスクが非常に高いか、高い資産価値により、
さらに高い開発コストが正当化される場合に適用される。
EAL6の保証に加え、
数学的検証を伴う形式的表現と対応、
広範囲のテストを使用する包括的分析を要求

国内対応状況

FIPS140(FIPS PUB 140-2)

概要

FIPS 140 (Federal Information Processing Standardization 140)

国内対応状況

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

PCI DSS

概要

6つの目標とそれに対応する12の要件

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

認定審査機関

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

PCI DSS対応のプロセス

CMMI

CMMI : Capability Maturity Model Integration(能力成熟度モデル統合)

概要

CMM

レベル

プロセス領域

IDEALモデル

SSE-CMM

ISO/IEC 20000 及び ITIL

情報セキュリティ管理

アメリカ国立標準技術研究所(NIST)

NIST CSF

                        │組織に強い
                        │
                        │
     (CSF)            │         (ISMS)
                        │
サイバー攻撃対応に特化  │
────────────┼────────────
                        │    情報セキュリティ全般
                        │
     (CIS Controls)   │         (PCI DSS)
                        │
                        │
                        │技術に強い

SP 800-61

コンピュータセキュリティ
インシデント対応ガイド

SP 800-63-3

(Digital Authentication Guideline)
https://pages.nist.gov/800-63-3/

#DocumentTitleURL
1SP 800-63-3Digital Identity Guidelineshttps://doi.org/10.6028/NIST.SP.800-63-3
2SP 800-63AEnrollment and Identity Proofinghttps://doi.org/10.6028/NIST.SP.800-63a
3SP 800-63BAuthentication and Lifecycle Managementhttps://doi.org/10.6028/NIST.SP.800-63b
4SP 800-63CFederation and Assertionshttps://doi.org/10.6028/NIST.SP.800-63c

クラウドへのパッチ適用

NIST定義の組合せは以下の通り。

Open PaaSならできそうだが、古い?

SMSを使った2要素認証を非推奨〜禁止

参考

Wikipedia


トップ   新規 一覧 単語検索 最終更新   ヘルプ   最終更新のRSS