DNET_SCLawInfoSecITService - NetDevInfraWGinOSSConsortium/NetDevInfraWiki GitHub Wiki

SC：法制度 - 情報セキュリティ、ITサービス（規格と制度）

概要

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

詳細

ISO/IEC 15408

概要（ISO/IEC 15408）

  • セキュリティ評価を行うための共通的な評価基準を定める。

  • コレを元に、セキュリティ評価･認証を行う。
    → Common Criteria（CC）

  • 建付けはSC：法制度の該当節（技術系）を参照。

  • TCSEC（Trusted Computer System Evaluation Criteria）などがベース

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

  • Common Criteria（CC）との関連。

    • 一般的にセキュリティ評価基準を示す用語としては、CCもISO/IEC15408も同じ意味。
    • 現在、CCの規格を元にISO/IEC 15408の作成が行われている。
      • CCの規格化団体とISO/IEC 15408の標準化団体は協力関係にある。
      • CCと ISO/IEC15408のリリース時期やバージョンは厳密には一致しない。

  • 効果

    • サプライサイド

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

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

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

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

    • 加盟国の何れかで評価・認定された製品は相互に認証書が通用する。

      • Certificate authorising participants : 従来からあるメンバのカテゴリ
      • Certificate consuming participants : 他の参加国で認証された製品又はシステムを受け入れる。

Common Criteria（CC）

  • ISO/IEC 15408準拠のセキュリティ評価・認証制度

  • 名称
    Common Criteria（CC）

    • Common Criteria for Information Technology Security Evaluation
    • 情報技術セキュリティ評価のためのコモンクライテリア

  • 概念

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

    • セキュリティターゲット (ST, Security Target)

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

    • セキュリティ機能要件 (SFR, Security Functional Requirements)

      • 製品が提供する個々のセキュリティ機能を規定する条文。
      • 標準カタログとして PP や、ST を書くときに使用する。

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

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

Part1 総則および一般モデル

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

  • 以下の作成の規定

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

    • セキュリティ・ターゲット（ST : Security Target）
      セキュリティ機器、システム（TOE : Target Of Evaluation）の基本設計仕様の作成

      • 製品やシステムに関するセキュリティ上の脅威分析
      • 脅威に対するセキュリティ対策方針の策定
      • その対策を実現するためのセキュリティ要件の設計
      • そのセキュリティ要件を満たすために実装する機能の要約仕様の作成
      • 保証を確保するための開発内容

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

    • ST概説

      • ST参照
      • TOE概要
      • TOE参照
      • TOE記述

    • 適合主張

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

    • セキュリティ課題定義

      • 脅威
      • 組織のセキュリティ方針
      • 前提条件

    • セキュリティ対策方針

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

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

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

    • セキュリティ要件

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

    • TOE要約仕様

      • TOE要約仕様

Part2 セキュリティ機能要件

  • セキュリティ確保に必要な機能について内容を規定。

  • これは、STやPPを作成するために用いられる。

  • 階層構造で記述

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

  • 機能クラス（１１項目）

# 機能クラス 略称 概要
1 セキュリティ監査（Security Audit） FAU セキュリティ・イベント情報の認識 / 記録 / 保存 / 分析の要件
2 通信（Communication） FCO 通信の参加者の識別を保証する否認防止に関する要件
3 暗号サポート（Cryptographic Support） FCS 各種暗号操作の要件
4 利用者データ保護（User Data Protection） FDP アクセス制御、フロー制御、利用者データの保護
（入出力時のセキュリティ属性保護、転送時の機密性保護）の要件
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 セキュリティ保証要件

  • セキュリティ確保に必要な信頼性について内容を規定。

  • 製品やシステムに対して、セキュリティ要件の実装の確かさを確認する要件が記述されている。

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

国内対応状況（ISO/IEC 15408）

建付けはSC：法制度の該当節（技術系）を参照（JIS化）。

  • セキュリティ規格については、JIS X 5070-1:2011
  • セキュリティ評価・認証制度については、IPAが「JISEC」を運用
    • 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)

概要（FIPS 140）

FIPS 140 (Federal Information Processing Standardization 140)

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

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

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

国内対応状況（FIPS 140）

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

  • 名称

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

  • 内容

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

PCIデータセキュリティスタンダード（PCI DSS）

PCI DSS : Payment Card Industry Data Security Standard

概要（PCI DSS）

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

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

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

認定審査機関

  • 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対応のプロセス

  • PCI DSS準拠対象範囲の確定
  • 改善計画の立案
  • 実装と確認
  • テスト実施と本審査
    PCI DSS認証取得の方法
    • QSAによる訪問審査
    • ASVによるサイトスキャン検査

能力成熟度モデル統合（CMMI）

CMMI : Capability Maturity Model Integration

概要（CMMI）

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

    • 工学、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

  • もともとは（個別の）能力成熟度モデル (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 v1.0 公表。
    • 1997年:
      SW-CMM の開発を終了する（CMMIを開発するため）。

レベル

  • 成熟度レベル（段階表現）
    レベル1-5までの5段階で組織プロセスの成熟度レベルを評価できる。

    • レベル1 : 初期
    • レベル2 : 管理された
    • レベル3 : 定義された
    • レベル4 : 定量的に管理された
    • レベル5 : 最適化している。

  • 能力レベル（連続表現）
    レベル0-3までの4段階で能力レベルを表し、
    プロセスの達成度の評価に使用する。

    • レベル0 : 不完全な
    • レベル1 : 実施された
    • レベル2 : 管理された
    • レベル3 : 定義された

プロセス領域

  • プロセス改善における活動を分類したもの

  • 各プロセス領域には固有ゴールと共通ゴールがあり

    • 固有ゴールには固有プラクティスが設定
    • 共通ゴールには共通プラクティスが設定

  • CMMI-DEVのプロセス領域

連続表現のグループ プロセス領域 段階表現（成熟度レベル）
プロセス管理 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モデル

SSE-CMM

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

アメリカ国立標準技術研究所（NIST）

情報系は、NISTの情報技術ラボラトリ（ITL: Information Technology Laboratory）

NIST CSF

  • CSF（Cyber Security Framework）
    重要インフラのサイバーセキュリティ対策

  • オバマ大統領の大統領令（2013年2月）に基づき、
    NIST が政府や民間から意見を集め作成した、
    サイバーセキュリティ対策に関するフレームワーク。

  • 特徴

    • サイバー攻撃対策に特化
    • 広く企業に適用できるように要件を汎用化
    • リスクベースアプローチを採用
    • フレームワーク自体を無償公開
　　　　　　　　　　　　　　　　　│組織に強い
　　　　　　　　　　　　　　　　　│
　　　　　　　　　　　　　　　　　│
　　　（ＣＳＦ）　　　　　　　　　│　　　　 （ＩＳＭＳ）
　　　　　　　　　　　　　　　　　│
サイバー攻撃対応に特化　　　　　　│
─────────────────┼─────────────────
　　　　　　　　　　　　　　　　　│　　　　　　　情報セキュリティ全般
　　　　　　　　　　　　　　　　　│
　　（ＣＩＳ　Ｃｏｎｔｒｏｌｓ）　│　　　（ＰＣＩ ＤＳＳ）
　　　　　　　　　　　　　　　　　│
　　　　　　　　　　　　　　　　　│技術に強い

  • 構成

    • コア（Core）
      業種・業態を問わない、共通となるサイバーセキュリティ対策（IPDRR）

      • 特定（Identify）
      • 防御（Protect）
      • 検知（Detect）
      • 対応（Respond）
      • 復旧（Recover）

    • ティア（Tier）
      Measurable（測定可能）にしているのがティア（Tier）の役割

      • ティア1：部分的である（Partial）
        セキュリティ・リスク対策は確立されていない。

      • ティア2：リスク情報を活用している（Risk Informed）
        確立（経営層から承認）されているが、ポリシーが確立されていない。

      • ティア3：繰り返し適用可能である（Repeatable）
        ポリシーが確立されており、繰り返し可能なプロセスで、更新されている。

      • ティア4：適応している（Adaptive）
        継続的な改善プロセスで、進化 / 高度化する脅威にタイムリーに対応。

    • プロファイル（Profile）
      ＝コア（Core）×ティア（Tier）

  • 参考

SP 800シリーズ

  • CSDが発行するコンピュータセキュリティ関係のレポート

  • 米国の政府機関がセキュリティ対策を実施する際に
    利用することを前提としてまとめられた文書だが、
    政府機関、民間企業を問わず、セキュリティ担当者にとって有益。

  • 内容的には、

    • セキュリティ・マネジメント
    • リスク・マネジメント
    • セキュリティ技術
    • セキュリティ対策状況の評価指標
    • セキュリティ教育
    • インシデント対応

SP 800-61

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

  • インシデント対応のポリシー、計画および手順の作成

    • ポリシーの要素

      • マネジメント層の責任表明
      • ポリシーの目的と目標
      • ポリシーの範囲
      • インシデントの定義と、インシデントが自組織にもたらす結果。
      • 組織構造と、役割、責任、権限レベルを表す記述。
      • 事件の優先順位付けまたは重大さの格付け。
      • 実施評価（パフォーマンス測定）
      • 報告と連絡の様式

    • 計画の要素

    • 手順の要素

    • 外部の関係者との情報共有

  • インシデント対応チームの構成

    • チームのモデル

      • 中央のインシデント対応チーム
      • 分散したインシデント対応チーム
      • 調整チーム

    • 要員配置モデル

      • 職員による対応
      • 部分的外部委託
      • 完全な外部委託

    • チームモデルの選択

      • 24時間365日対応の必要性
      • 常勤のチームメンバー
      • 非常勤のチームメンバー
      • モラル
      • コスト
      • 専門知識
      • 組織上の構成
      • 外部委託の検討
        ・現在および将来の業務品質
        ・責任の分割
        ・契約業者に対する機密情報の公開
        ・組織固有の知識の欠如
        ・相関関係の不足
        ・複数の場所での事件の処理
        ・インシデント対応の技能を内部で維持する

    • インシデント対応要員

    • 組織内の依存関係

      • マネジメント層
      • 情報セキュリティ部門
      • 通信部門、ITサポート部門
      • 物理セキュリティと設備管理部門
      • 業務継続計画部門
      • 法務部門、人事部門
      • 広報部門およびマスコミとの窓口

  • インシデント対応チームのサービス

    • アドバイザリの配布
    • 脆弱性評価
    • 侵入検知
    • 教育と意識向上
    • 技術動向の監視
    • パッチ管理

SP 800-63

https://pages.nist.gov/800-63-3/

  • Electronic Authentication Guideline
  • Digital Authentication Guideline
  • Digital Identity Guidelines
  • 電子的認証に関するガイドライン
# Document Title URL
1 SP 800-63-3 Digital Identity Guidelines https://doi.org/10.6028/NIST.SP.800-63-3
2 SP 800-63A Enrollment and Identity Proofing https://doi.org/10.6028/NIST.SP.800-63a
3 SP 800-63B Authentication and Lifecycle Management https://doi.org/10.6028/NIST.SP.800-63b
4 SP 800-63C Federation and Assertions https://doi.org/10.6028/NIST.SP.800-63c

FIPS PUBシリーズ

  • 規定のもとに採択され公布される、公式の規格文書シリーズ

    • 1996 年施行の情報技術マネジメント改革法の第 5131 条
    • 2002 年施行の連邦情報セキュリティマネジメント法

  • これらの規定は、

    • 商務長官および NIST に対し、
    • 連邦政府における
      コンピュータおよびコンピュータ通信システムの
      利用と管理を改善するという重要な責務を課している。

  • NISTは、

    • これらの分野における

      • 規格
      • ガイドライン

    • の開発に向けて下記を行っている。

      • 指導
      • 技術的ガイダンスの提供
      • および政府の取り組みの調整

クラウドへのパッチ適用

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

  • IaaS : パッチ適用可能
  • PaaS : パッチ適用不可
  • SaaS : パッチ適用不可

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

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

NIST SP 800-63Bの策定において。

その他

EDSA認証（制御機器認証）

※ 元 Wiki では見出しのみで、本文は書かれていない。

ISO/IEC 20000 及び ITIL

参考

Wikipedia

移行メモ

  • 「（TOE : Target Of Evaluate）」→「Target Of Evaluation」に正した。
  • セキュリティ・ターゲット（ST）の内容の「SE概説」→「ST概説」に正した。
  • 機能クラス FCO の「通信の参加者の識別の保証する」→「識別を保証する」、 FPR の「他社によるIDの発見・悪用」→「他者による」に正した。
  • PCI DSS の 12 要件の「マルウェアにしてすべてのシステムを保護し」→ 「マルウェアに対してすべてのシステムを保護し」に正した。
  • NIST CSF のティア1「部分的である（Partical）」→「（Partial）」に正した。
  • 元 Wiki の「SMSを使った2要素認証を非推奨〜禁止」にあった「SMS」へのリンクは、 リンク先が元 Wiki 側に存在しない（リンク切れ）ためプレーン・テキストとした。
  • 元 Wiki の結合セル（> / ~）を含む表は、GitHub Wiki では再現できないため、 セルの内容を展開して平坦な表にした（EAL、CMMI-DEV のプロセス領域）。 CMMI-DEV のプロセス領域の表は、成熟度レベルを 4 列（2 / 3 / 4 / 5）で 表す形式だったが、値の置かれた列と値そのもの（2 - 5）が一致しない行が 複数あったため、値のほうを採用して 1 列にまとめた。
  • 元 Wiki の行頭空白による図（CSF / ISMS / CIS Controls / PCI DSS の 4 象限）は、 フェンス付きコードブロックにした。
  • 同名の見出しが複数あり GitHub Wiki でアンカが衝突するため、括弧で文脈を補って一意にした （「概要（ISO/IEC 15408）」「概要（FIPS 140）」「概要（PCI DSS）」「概要（CMMI）」、 「国内対応状況（ISO/IEC 15408）」「国内対応状況（FIPS 140）」）。
  • 元 Wiki で見出しそのものが他ページ・同ページ内へのリンクになっていた箇所 （「IDEALモデル」「ISO/IEC 20000 及び ITIL」）は、 GitHub Wiki では見出しからアンカが生成されるため、 見出しをプレーン・テキストとし、リンクは直下の本文に置いた。
  • マイクロソフト系技術情報 Wiki（techinfoofmicrosofttech.osscons.jp）への URL リンクは、移行済みの Azure Kubernetes Service (AKS) に張り替えた。
  • PukiWiki のページ内アンカ（#xxxxxxxx）は GitHub Wiki では再現できないため、 同一ページ内のアンカは見出しから生成されるアンカに張り替え、 他ページのアンカを指すリンクは「〜（ページ名 の該当節を参照）」の形に置き換えた。
  • 未移行のページはファイル名を予約し、TODO.md に記録した。

Tags: 移行, 資格, SC, 法制度, ISO/IEC 15408, Common Criteria, EAL, JISEC, FIPS 140, JCMVP, PCI DSS, CMMI, CMM, SSE-CMM, NIST, CSF, SP 800, FIPS PUB

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

⚠️ **GitHub.com Fallback** ⚠️