説明/参照:
RFC 2459 : インターネット X.509 公開キー基盤証明書および CRL プロファイル。GUTMANN, P.、X.509 スタイル ガイド。SMITH、Richard E.、インターネット暗号化、1997 年、Addison-Wesley Pub Co.

セクション: リスク、対応、および回復
説明/参照:
ウォーム サイトには、いくつかの基本的な機器、場合によってはほぼすべての機器が備わっていますが、最後のバックアップや、場合によっては追加のコンピュータやその他の機器を導入しないと運用するには不十分です。
次の答えは正しくありません。
ホットなサイト。ホットサイトは必要なハードウェアをすべて備えて完全に構成されているため、これは不正解です。不足しているのは最後のバックアップだけであり、稼働しています。
ローリングホットサイト。ローリング ホット サイトは必要なハードウェアをすべて備えて完全に構成されているため、これは不正解です。
寒い現場。これは不正解です。コールド サイトには基本的に電源、HVAC、基本的なケーブル配線がありますが、処理装置に関する限りはまったくないか、ほとんどありません。他のすべての機器はこの場所に持ち込む必要があります。再構築には1〜2週間かかる場合があります。
参考文献:
OIG CBK の事業継続性と災害復旧計画 (368 ～ 369 ページ)

人事異動が頻繁にある組織では、アクセス制御が組織内での個人の役割または役職に基づいているため、非裁量アクセス制御 (役割ベースのアクセス制御とも呼ばれます) が役立ちます。事前定義されたロールにユーザーを割り当てることで、新しい従業員のアクセスを簡単に構成できます。ユーザーは、そのロールのメンバーになることによって、そのロールの権限を暗黙的に継承します。
ロール内で定義されたこれらのアクセス許可は、新しい人がロールを引き継ぐたびに変更する必要はありません。
非任意アクセス制御モデルの別のタイプは、ルール ベースのアクセス制御 (RBAC または RuBAC) です。このモデルでは、リソースにアクセスするすべてのサブジェクトにグローバルなルール セットが均一に適用されます。
RuBAC の良い例はファイアウォールです。
この質問は卑劣な質問であり、選択肢の 1 つに単語が 1 つだけ追加されていることがよくあります。
実際の試験では、質問とその選択肢を注意深く読むことが必須です。必要に応じて 2 回読むことをお勧めします。
Shon Harris は著書の中で、RBAC を管理する次の方法を挙げています。
ロールベースのアクセス制御は、次の方法で管理できます。
非 RBAC ユーザーはアプリケーションに直接マップされ、ロールは使用されません。(ロールは使用されていません) 制限付き RBAC ユーザーは複数のロールにマップされ、ロールベースのアクセス機能を持たない他の種類のアプリケーションに直接マップされます。(ロールをサポートするアプリケーションのロールと、ロールをサポートしないアプリケーションの明示的なアクセス制御の組み合わせが使用されます) ハイブリッド RBAC ユーザーは、選択された権限のみがそれらのロールに割り当てられたマルチアプリケーション ロールにマップされます。
完全な RBAC ユーザーはエンタープライズ ロールにマッピングされます。(ロールは、付与されるすべてのアクセスに使用されます) NIST では、RBAC を次のように定義しています。
管理者は通常、システム上の各ユーザーのアクセス制御リストを個別に指定するため、セキュリティ管理はコストがかかり、エラーが発生しやすくなります。RBAC を使用すると、組織の構造に密接に対応するレベルでセキュリティが管理されます。各ユーザーには 1 つ以上のロールが割り当てられ、各ロールには、そのロールのユーザーに許可される 1 つ以上の権限が割り当てられます。
RBAC によるセキュリティ管理は、特定のジョブで担当者が実行する必要がある操作を決定し、従業員を適切な役割に割り当てることで構成されます。相互に排他的なロールまたはロール階層によって生じる複雑さは、RBAC ソフトウェアによって処理されるため、セキュリティ管理が容易になります。

ホストベース

セクション: セキュリティ運用管理
説明
説明/参照:
ソフトウェアの計画と要件のフェーズでは、脅威、脆弱性、セキュリティ要件、合理的な注意、デューデリジェンス、法的責任、コスト/利点の分析、必要な保護レベル、テスト計画に対処します。
この実装は、セキュリティ ソフトウェアのインストール、システムの実行、受け入れテスト、セキュリティ ソフトウェア テスト、および完全なドキュメントの認証と認定 (必要な場合) を扱うため、正しくありません。
システムの実現可能性は、情報セキュリティ ポリシー、標準、法的問題、および概念の早期検証を扱っているため、不正確です。
製品設計は、セキュリティ仕様の組み込み、テスト計画とデータの調整、アクセス制御の決定、設計文書、暗号化オプションの評価、および検証を扱うため、間違っています。
出典:
KRUTZ、Ronald L. & VINES、Russel D.、『CISSP Prep Guide: Mastering the Ten Domains of Computer Security』、John Wiley & Sons、2001 年、第 7 章: アプリケーションとシステム開発 (252 ページ)。
KRUTZ、Ronald & VINES、Russel、『The CISSP Prep Guide: Gold Edition』、Wiley Publishing Inc.、2003 年、章
7: セキュリティのライフサイクルコンポーネント、図 7.5 (346 ページ)。