予防的対策は、インシデントの発生を回避することを目的としています。試験では、さまざまなセキュリティ対策に関する以下の情報を知っておく必要があります。
抑止制御 抑止制御は、潜在的な攻撃者を思いとどまらせることを目的としています。アクセス制御は、制御が存在するだけで、潜在的な攻撃者が制御を回避しようとしないという単純な事実によって、脅威や攻撃に対する抑止力として機能します。これは多くの場合、制御を回避するために必要な労力が、攻撃者が成功した場合の潜在的な報酬よりもはるかに大きいか、あるいは逆に、攻撃が失敗した場合（または捕まった場合）の悪影響が、成功した場合の利益を上回るためです。たとえば、ユーザー、サービス、またはアプリケーションの識別と認証、およびそれに伴うすべてのことを強制することで、攻撃者がインシデントとの関連付けを恐れるため、システムに関連するインシデントの可能性が大幅に減少します。特定のアクセスパスに制御がない場合、インシデントの数と潜在的な影響は無限になります。制御は、プロセスに対する監視を適用することで、本質的にリスクへの露出を減らします。この監視は抑止力として機能し、起こりうる結果に直面して攻撃者の意欲を抑制します。抑止制御の最良の例は、従業員が意図的に不正な操作を行い、望ましくない事態を引き起こす傾向があることです。ユーザーが、システムへの認証によって操作を実行すると、その活動がログに記録され監視されることを理解し始めると、そのような操作を試みる可能性が低くなります。多くの脅威は、攻撃者の匿名性に基づいており、攻撃者の特定や行動との関連付けの可能性はあらゆる手段を講じて回避されます。これが、アクセス制御が攻撃者による回避の主要な標的となる根本的な理由です。抑止力は、ユーザーが不正な操作を行った場合に罰則を科すという形をとることもあります。たとえば、組織のポリシーで、不正な無線アクセスポイントを設置した従業員は解雇されると規定されている場合、ほとんどの従業員は無線アクセスポイントの設置を思いとどまるでしょう。
予防的制御 予防的制御は、インシデントの発生を回避することを目的としています。予防的アクセス制御は、ユーザーが特定のアクティビティや機能を実行できないようにします。予防的制御は、制御が任意ではなく、（容易に）回避できないという点で、抑止的制御とは異なります。抑止的制御は、制御を回避するリスクを冒すよりも、制御に従う方が容易であるという理論に基づいています。言い換えれば、行動する権限はユーザー（または攻撃者）にあります。予防的制御では、行動する権限はシステムにあり、制御に従うことは任意ではありません。制御を回避する唯一の方法は、制御の実装に欠陥を見つけることです。
補完的制御 補完的制御は、システムの既存の機能ではポリシーの要件を満たせない場合に導入されます。補完的制御は、技術的、手続き的、または管理的なものがあります。既存のシステムが必要な制御をサポートしていない場合でも、既存の環境を補完し、制御のギャップを埋め、ポリシーの要件を満たし、全体的なリスクを低減できる他のテクノロジーやプロセスが存在する可能性があります。たとえば、アクセス制御ポリシーでは、インターネット経由で認証プロセスを実行する場合は暗号化する必要があると規定されている場合があります。認証目的で暗号化をネイティブにサポートするようにアプリケーションを調整するのは、コストがかかりすぎる可能性があります。暗号化プロトコルであるセキュアソケットレイヤー（SSL）を認証プロセスの上に重ねて使用することで、ポリシーの記述をサポートできます。その他の例としては、職務分掌環境があります。これは、システムの技術的な制限を補い、トランザクションのセキュリティを確保するために、特定のタスクを分離する機能を提供します。さらに、認可、監視、管理などの管理プロセスを使用して、アクセス制御環境のギャップを補うことができます。
検出制御 検出制御は、何かが起こったときに警告を発し、インシデント後のタイムラインの最も早い段階です。アクセス制御は脅威に対する抑止力であり、最小権限の適用によって有害なインシデントを防止するために積極的に利用できます。しかし、アクセス制御の検出的な性質により、アクセス環境に対する重要な可視性が得られ、組織がアクセス戦略と関連するセキュリティリスクを管理するのに役立ちます。前述のように、認証されたユーザーに提供される厳密に管理されたアクセス権限は、認証されたユーザーが持つ機能を制限することによって、企業の資産のリスクへの露出を軽減する機能を提供します。ただし、権限が付与された後にユーザーが実行できる操作を制御するオプションはほとんどありません。たとえば、ユーザーにファイルへの書き込みアクセス権が付与され、そのファイルが破損、変更、またはその他の方法で悪影響を受けた場合（意図的か意図的でないかを問わず）、適用されたアクセス制御を使用することで、トランザクションの可視性が得られます。制御環境は、システムの識別、認証、認可、および権限の使用に関するアクティビティをログに記録するように構築できます。これは、エラーの発生、不正な操作の試み、または提供された認証情報がいつ使用されたかを検証するために使用できます。ログシステムは、検出装置として、正規ユーザーによって実行された操作（成功したものと失敗したもの両方）およびタスクの証拠を提供します。
是正措置 セキュリティインシデントが発生した場合、セキュリティインフラストラクチャ内の要素に対して是正措置が必要になることがあります。是正措置とは、環境のセキュリティ態勢を変更して欠陥を修正し、環境を安全な状態に戻すための措置です。セキュリティインシデントは、1つ以上の指示的、抑止的、予防的、または補償的制御の失敗を示します。検出制御によってアラームや通知が発せられたとしても、今度は是正措置によってインシデントの進行を食い止める必要があります。是正措置は、状況や対処すべきセキュリティ障害の種類に応じて、さまざまな形態をとることができます。
復旧制御 セキュリティインシデントへの対応や一時的な補償制御の提供など、アクセス制御環境への変更はすべて、正確に復元され、通常の運用状態に戻される必要があります。アクセス制御、その適用性、状態、または管理に影響を与える可能性のある状況はいくつかあります。システム障害、攻撃、プロジェクトの変更、技術的な要求、管理上の不備、本格的な災害状況などが挙げられます。たとえば、アプリケーションが正しくインストールまたは展開されていない場合、システムファイルに設定された制御に悪影響を及ぼしたり、インストール時にデフォルトの管理者アカウントが意図せず実装されたりする可能性があります。さらに、従業員が異動、退職、または一時休暇を取ると、職務分離に関するポリシー要件に影響を与える可能性があります。システムへの攻撃によりトロイの木馬プログラムが埋め込まれ、クレジットカード情報や財務データなどのユーザーの個人情報が漏洩する可能性があります。これらのすべての場合において、望ましくない状況はできるだけ早く是正され、制御は通常の運用状態に戻されなければなりません。
以下の回答は誤りです。
抑止力 - 抑止制御は、潜在的な攻撃者を思いとどまらせることを目的としています。
是正措置 - 是正措置とは、事故発生後にコンポーネントやシステムを修復する措置です。
復旧 - 復旧制御は、環境を通常の運用状態に戻すことを目的としています。
この質問を作成するにあたり、以下の参考文献が使用されました。
CISAレビューマニュアル2014年版44ページ、およびISC2公式CISSPガイド第3版50ページと51ページ

MTBFが高く、MTTRが低い方が望ましい。
各デバイスには、平均故障間隔（MTBF）と平均修復時間（MTTR）があります。
MTBF推定は、デバイスの予想寿命を決定するために、または内部の要素が
そのデバイスは故障すると予想されます。MTTR値は、
デバイスを修理して、生産を再開させる。」267ページ　ション・ハリス著：オールインワンCISSP
認証

中央機関は、組織のセキュリティポリシーに基づいて、どの主体が特定のオブジェクトにアクセスできるかを決定する。
この問題の重要な焦点は、アクセス権を決定する「中央機関」である。
クイズユーザーの一人であるセシリアからフィードバックが届き、NISTはMACを次のように定義していると教えてくれました。「MAC
ポリシーとは、アクセス制御ポリシーの決定が中央機関によって行われることを意味します。
この質問には2つの良い答えがある可能性を示唆しているようだ。
しかし、下記の参考文献に記載されているNISTR文書を読むと、
つまり、MACは最もよく言及されるNDACポリシーである。したがって、MACはNDACポリシーの一種である。
同じ文書内には次のようにも記載されています。「一般的に、アクセス制御ポリシーのうち、
DACは、非裁量アクセス制御（NDAC）のカテゴリに分類されます。
つまり、このカテゴリーのポリシーには、ユーザーの裁量で定められていないルールが含まれているということです。
非裁量ポリシーは、ユーザーが変更できないコントロールを確立しますが、
行政措置。
NDACでは、以下の2つの選択肢があります。
ルールベースアクセス制御とロールベースアクセス制御
MACはルールを使用して実装されるため、RBACに分類され、これはNDACの一形態です。
NDACのサブセット。
この問題は、実際の試験で出題される問題の一例です。
正しいと思われる選択肢が複数ある。しかし、選択肢の1つが正しいかどうかを注意深く確認する必要がある。
より高いレベルになるか、選択肢のいずれかが他の選択肢のいずれかに該当する場合。この場合、NDAC
ルールベースアクセスを使用することでMACがNDACの対象となるため、こちらの方がより良い選択肢です。
コントロール。
以下は誤った回答です。
強制アクセス制御
強制アクセス制御では、オブジェクトのラベルと対象のクリアランスによって決定されます
アクセス権であって、中央機関ではない。中央機関（データ
所有者がオブジェクトにラベルを割り当て、システムがアクセス権限を決定します。
オブジェクトラベルと対象クリアランスを比較することで自動的に行われます。対象クリアランス
アクセス対象のオブジェクトよりも上位（同等以上）でなければならない。
MACメカニズムが必要となるのは、システムのセキュリティポリシーで以下のことが規定されている場合である。
1. 保護に関する決定は、対象物の所有者が行うべきではない。
2 システムは保護決定を強制する必要がある（つまり、システムはセキュリティポリシーを強制する）
（対象物の所有者の意思や意図に反して）。
通常、ラベル付けメカニズムと一連のインターフェースを使用して、
MACポリシー。例えば、機密区分「Secret」でプロセスを実行しているユーザーは、「Top Secret」ラベルの付いたファイルを読み取ることを許可されるべきではない。これは「単純なセキュリティルール」または「上位レベルの読み取り禁止」として知られている。
逆に、ラベルが「Secret」のプロセスを実行しているユーザーは、ラベルが「Confidential」のファイルに書き込むことを許可されるべきではありません。このルールは「*プロパティ」（「スタープロパティ」と発音）または「書き込み禁止」と呼ばれます。*プロパティは、自動化された環境でシステムセキュリティを維持するために必要です。
裁量によるアクセス制御
裁量アクセス制御では、権限は複数の異なる主体によって決定され、ファイルを作成した各個人がそのファイルの所有者となり、中央の単一の機関によって決定されるわけではありません。
DACでは、アクセス制御の一部はオブジェクトの所有者、またはオブジェクトのアクセスを制御する権限を持つその他の人物の裁量に委ねられます。例えば、一般的には、ユーザーによるファイルへのアクセスを制限するために使用されます。ファイルの所有者が、他のユーザーによるファイルへのアクセスを制御します。所有者によって指定されたユーザーのみが、ファイルに対して読み取り、書き込み、実行、その他の権限の組み合わせを持つことができます。
DAC政策は非常に柔軟性が高く、商業部門と政府部門で広く利用されている。しかし、DACには本質的に2つの弱点があることが知られている。
まず、読み取りアクセス権の付与は推移的です。例えば、アンがボブにファイルへの読み取りアクセス権を付与した場合、ボブがアンのファイルの内容をボブが管理するオブジェクトにコピーすることを妨げるものは何もありません。ボブは、アンの許可なく、アンのファイルのコピーへのアクセス権を他のユーザーに付与することができます。
第二に、DACポリシーはトロイの木馬攻撃に対して脆弱です。プログラムは呼び出し元のユーザーのIDを継承するため、例えばボブはアンのために、表面上は有用な機能を実行するプログラムを作成しながら、同時にアンのファイルの内容を破壊する可能性があります。この問題を調査する際、監査ファイルにはアンが自分のファイルを破壊したと記録されます。したがって、形式的には、DACの欠点は以下のとおりです。
任意アクセス制御（DAC）では、情報が1つのオブジェクトから別のオブジェクトにコピーされる可能性があるため、システム内の情報の流れについて真の保証はありません。
利用者が情報を受け取った後は、その情報の利用に制限は適用されません。
オブジェクトへのアクセス権限は、組織のセキュリティ要件を反映したシステム全体のポリシーではなく、オブジェクトの所有者によって決定されます。
ACLや所有者/グループ/その他のアクセス制御メカニズムは、DACポリシーを実装するための最も一般的なメカニズムです。DACを念頭に置いて設計されていないメカニズムであっても、DACポリシーを実装できる場合があります。
ルールベースのアクセス制御
ルールベースのアクセス制御では、中央機関がアクセスルールを割り当てる際に、どの主体がアクセスできるかを実際に決定することができます。しかし、アクセスを決定するのはルールそのものであるため、これは最も適切な回答ではありません。
RuBAC（ロールベースアクセス制御RBACとは対照的に）は、ユーザーが事前に決定され構成されたルールに基づいてシステムや情報にアクセスできるようにします。ルールベースアクセス制御には、DAC、MAC、RBACのように一般的に理解されている定義や正式に定義された標準がないことに注意することが重要です。「ルールベースアクセス」は、組織が定義した何らかのルールを許可するシステムに適用される一般的な用語であり、したがってルールベースアクセス制御は幅広いシステムを包含します。実際、RuBACは、特にRBACやDACなどの他のモデルと組み合わせることができます。RuBACシステムは、すべてのアクセス要求を傍受し、ルールとユーザーの権限を比較してアクセス決定を行います。ルールベースアクセス制御のほとんどは、セキュリティポリシーによって定義された一連のルールを動的に構成するセキュリティラベルシステムに依存しています。セキュリティラベルは、ファイル、ディレクトリ、デバイスなど、すべてのオブジェクトに添付されます。場合によっては、対象に（属性に基づいて）ロールも割り当てられます。RuBACは、サービスアクセスを制御するというビジネス上のニーズと技術的なニーズの両方を満たします。これにより、アクセス制御にビジネスルールを適用できます。たとえば、未払い残高のある顧客はサービスへのアクセスを拒否される場合があります。MAC のメカニズムとして、RuBAC のルールはユーザーが変更することはできません。ルールは、ドメイン、ホスト、プロトコル、ネットワーク、IP アドレスなど、ユーザーに関連するシステムの任意の属性によって確立できます。たとえば、ユーザーがルーターの反対側にある別のネットワークのオブジェクトにアクセスしたいとします。ルーターは、ネットワーク アドレス、ドメイン、プロトコルで構成されるルールを使用して RuBAC を使用し、ユーザーにアクセス権を付与するかどうかを決定します。従業員が組織内で役割を変更しても、既存の認証資格情報は有効のままであり、再構成する必要はありません。ルールを役割と組み合わせて使用​​すると、ルールをデバイスだけでなく人にも適用できるため、柔軟性が向上します。ルールベースのアクセス制御は、役割ベースのアクセス制御と組み合わせることができ、ユーザーの役割はルール設定の属性の 1 つになります。アクセス制御システムの一部の規定には、役割ベースのポリシー エンジンと特定の実装された動的ポリシーに加えて、ルールベースのポリシー エンジンがあります [Des03]。例えば、ソフトウェアの主要なユーザー層として、製品エンジニアと品質エンジニアの2種類があるとします。両グループは通常同じデータにアクセスできますが、データやアプリケーションの機能に関してそれぞれ異なる役割を担っています。さらに、各グループ内の個々のメンバーは、プログラム開発やテスト領域など、複数の属性を用いて識別できる異なる職務責任を持っています。したがって、製品エンジニアと品質エンジニアのグループ間、および各グループ内の個々のメンバー間のアクセスを制御するスクリプト化されたポリシーによって、アクセス権限の決定をリアルタイムで行うことができます。ルールは、ロールベースのアクセス制御に取って代わることも、補完することもできます。しかし、ルールやセキュリティポリシーの作成は複雑なプロセスであるため、各組織は適切なバランスを見つける必要があります。
この質問に使用した参考文献：http://csrc.nist.gov/publications/nistir/7316/NISTIR-7316pdf
そして
AIO v3 p162-167 および OIG (2007) p186-191
また
KRUTZ, Ronald L. & VINES, Russel D., 『CISSP準備ガイド：コンピュータセキュリティの10の領域をマスターする』、2001年、John Wiley & Sons、33ページ