〇：差分バックアップ

バックアップの方法には、完全、差分、増分があります。ほとんどのファイルは非常に時間とリソースを節約するために、毎日変更されず、それが継続的に変更されていないデータについてはバックアップしないバックアップ計画を策定するのが良いでしょう。バックアップソフトウェアでは、ファイルが変更または作成された場合、ファイルシステムはアーカイブビットを設定し、バックアップソフトウェアはそのファイルをバックアップするべきかを判断します。差分バックアップは、最後の完全バックアップ以降に変更されたファイルをバックアップします。よって正解は、「差分バックアップ」になります。

×：増分バックアップ

増分バックアップは、最後のバックアップから変更されたすべてのデータをバックアップします。

×：完全バックアップ

完全バックアップとは、データベース全体またはシステムのすべてをバックアップします。

×：部分バックアップ

バックアップのカテゴリーにありません。

〇：変更管理委員会によって全員一致で承認された変更は、実機テストは不要なステップとなる。

これは、誤っている選択肢を選ぶ問題です。さまざまな種類の環境の変化のためには、構造化された変更管理プロセスを導入する必要があります。変更要件の重大さによっては、変更と実装を変更管理委員会に提示する必要があります。変更管理委員会によって承認された変更要求は、予期しない結果を発見するためにテストされなければなりません。これは、変更の目的と結果および可能性のある影響をさまざまな側面で示すのに役立ちます。つまりは、変更管理委員会によって承認されたからと言ってテストされなくてもよいというわけではありません。変更管理委員会は変更に関して実行を命じており、それが適切であるかはテストで担保しなければなりません。よって正解は、「変更管理委員会によって全員一致で承認された変更は、実機テストは不要なステップとなる。」になります。

×：変更管理委員会によって承認された変更は、変更のログとして残すべきである。

正しい変更管理と言えます。

×：変更の計画段階では大まかなスケジュールを作成する必要がある。

正しい変更管理と言えます。

×：提案された変更は、優先順位を設け検討されるべきである。

正しい変更管理と言えます。

クラスタリングはフォールトトレランスのために設計されています。多くの場合には負荷分散と組み合わされますが、本質的には別物です。クラスタリングは稼働をアクティブ/アクティブにすることができます。その上で負荷分散の機能により、複数台サーバのトラフィックを処理します。一方で、アクティブ/パッシブでは、指定されたプライマリアクティブサーバーとセカンダリパッシブサーバーがあり、パッシブは数秒ごとにキープアライブまたはハートビートを送信します。

クリッピングレベルとは、ある閾値を超えたときにレポーティングすることで対応負担を少なくするためのテクニックです。具体的には、ログイン試行回数やアクセス数や処理速度などが正常ではないことを判断するための閾値のことです。

〇：固定されたメンバーで会議を実施し、人数はできるだけ少ない方がよい。

BCP委員会は、組織内の各部門を代表するために必要な規模でなければなりません。各部門が独自の機能と独特のリスクと脅威を持っているため、社内のさまざまな部門に精通した人で構成されている必要があります。すべての問題と脅威が持ち込まれ、議論されたときに策定されていきます。これは、少数の部門や少数の人々と効果的に行うことはできません。委員会は、少なくとも事業部、上級管理職、IT部門、セキュリティ部門、通信部門、法務部門の担当者から構成されていなければなりません。

×：委員のメンバーは、計画段階、テスト段階、実施段階に関与する必要があります。

委員会のメンバーが計画段階とテスト段階および実装段階に関与する必要があることが正しいため、回答としては正しくありません。 BCPのコーディネーターであるマシュー氏が優れた経営リーダーであれば、チームメンバーに自分の任務や役割に関わる所有権を感じさせるのが最善である考えるでしょう。 BCPを開発する人々も、それを実行する人でなければなりません。危機の時期にいくつかの重要なタスクが実行されることが予想される場合は、計画とテストのフェーズでさらに注意を払う必要があります。

×：事業継続コーディネーターは、経営陣と協力して委員会メンバーを任命すべきである。

BCPコーディネーターが管理職と協力して委員会メンバーを任命する必要があるため、間違っています。また、経営陣の関与はそこで終わりません。 BCPチームは、経営陣と協力して計画の最終目標を立て、災害時に最初に処理しなければならないビジネスの重要な部分を特定し、部門やタスクの優先順位を確認する必要があります。また経営陣は、チームにプロジェクトの範囲と具体的な目標を指示するのに役立つ必要があります。

×：チームは、社内のさまざまな部門の人で構成する必要があります。

チームが社内の異なる部門の人で構成されるべきであるため、正しくありません。これは、チームが各部門が直面する組織に応じたリスクと脅威を考慮する唯一の方法になります。

検知では正しいリクエストを誤っていると判断しても、悪いリクエストを無視しても良くありません。そのため、True Positive（本当の攻撃を検知する）、True Negative（本当の攻撃を検知しない）、False Positive（偽の攻撃を検知する）、False Negative（偽の攻撃を検知しない）の検知の精度結果に分かれます。

〇：ビジネスインパクト分析を実施

事業継続計画を作成するために特定の方法論を守らなければならないわけではありませんが、ベストプラクティスは時間の経過とともに証明されています。国立標準技術研究所（NIST）の組織は、これらのベストプラクティスの多くを開発し、すべての人が容易に利用できるように文書化する責任があります。 NISTは、Special Publication 800-34 Rev 1「連邦情報システムの継続計画ガイド」の7つのステップを概説しています。ビジネスインパクト分析を実施する。予防的コントロールを特定する。偶発的戦略を作成する。情報システム緊急時対応計画を策定する。計画のテスト、トレーニング、演習を確実にする。計画を確実に維持する。ビジネスインパクト分析においては、重要な機能やシステムを特定し、必要に応じて優先順位を付けることができます。また、脆弱性や脅威を特定し、リスクを計算することも含まれます。

×：予防的コントロールを特定

予防的コントロールを特定では、重要な機能やシステムが優先され、その脆弱性、脅威、および特定されたリスク（すべてビジネスインパクト分析の一部である）の後で予防制御を特定する必要があります。

×：継続計画方針声明を作成

継続計画方針声明を作成では、事業継続計画の策定に必要な指針を提供し、これらのタスクを実行するために必要な役割に権限を割り当てるポリシーを作成する必要があります。正しくありません。これは、ビジネス継続計画を作成する最初のステップであり、ビジネス影響分析の一部である重要なシステムと機能を特定し、優先順位を付ける前に行われます。

×：コンティンジェンシー戦略を作成

コンティンジェンシー戦略の作成には、システムと重要な機能を迅速にオンライン化できるようにするための方法を策定する必要があります。これを実行する前に、重要なシステムと機能を判断するためにビジネスインパクト分析を実施し、復旧中に優先順位を付ける必要があります。

適切な構成変更をスタッフに指示するためには、構造化された変更管理プロセスを確立する必要があります。標準的な手続きでは、プロセスを管理下に保ち、予測可能な方法で確実に実行できるようにします。変更管理ポリシーには、変更の要求、変更の承認、変更の文書化、テストおよび表示、実装、および管理への変更の報告手順が含まれている必要があります。構成管理の変更管理プロセスは、通常サービスレベル契約の承認には関係がありません。

変更依頼、変更依頼の評価、変更依頼を承認/却下、変更のテスト、変更リリースの計画及び実施（管理者への変更報告）、ドキュメント化を経て進んでいきます。

リモートジャーナリングとは、ファイル自体ではなくトランザクションログファイルをリモートに送信します。トランザクションとは、ファイルに対して行われる1つ以上の更新処理を指します。つまり、ファイルに対する更新履歴です。これにより、元のファイルが失われたとしても、トランザクションログから再構築されます。

〇：監査ログの形式は不明であり、侵入者はそもそも利用できません。

監査ツールは、ネットワーク内、ネットワークデバイス上、または特定のコンピュータ上のアクティビティを追跡する技術的なコントロールです。 監査はネットワークやコンピューターへのエンティティのアクセスを拒否するアクティビティではありませんが、セキュリティ管理者が行われたアクセスの種類の理解、セキュリティ違反の特定、または疑わしいアクティビティの管理者への警告を行うようにアクティビティを追跡します。 この情報は、他の技術的コントロールの弱点を指摘し、管理者が環境内で必要なセキュリティレベルを維持するために変更を加える必要がある場所を理解するのに役立ちます。侵入者はこれらの弱点を悪用するためにもこの情報を使用することができます。したがって、ハッシュアルゴリズムのように、権限、権限、および整合性の制御によって監査ログを保護する必要があります。 しかし、システムログのフォーマットは、一般にすべての同様のシステムで標準化されています。 ログ形式を非表示にするのは通常の対策ではないため、監査ログファイルを保護する理由ではありません。

×：適切に保護されていない場合、その監査ログは起訴中に認められないことがあります。

監査ログが裁判所で認められるためには、監査ログを保護するために細心の注意を払わなければならないので、間違っています。 監査証跡を使用して、後で調査できる疑わしい活動についてのアラートを提供することができます。さらに、攻撃がどれほどの距離で行われたのか、また、発生した可能性のある損傷の程度を正確に把握する上で有益です。 刑事訴訟や調査のような後の出来事に使用する必要がある場合に備えて、収集されたすべてのデータを適切かつ正確に表すことができるように、適切な管理の連鎖が維持されていることを確認することが重要です。

×：監査ログには機密データが含まれているため、特定のサブセットのユーザーのみがアクセスできるようにする必要があります。

管理者およびセキュリティ担当者だけが監査証跡情報を表示、変更、および削除できる必要があるため、正しくありません。 他の人はこのデータを見ることができず、変更や削除はほとんどできません。 デジタル署名、メッセージダイジェストツール、強力なアクセスコントロールを使用することで、データの完全性を保証することができます。 その機密性は、必要に応じて暗号化とアクセス制御で保護することができ、データの損失や改ざんを防ぐためライトワンスメディアに保管することができます。 ログを監査する権限のないアクセス試行をキャプチャして報告する必要があります。

×：侵入者は、活動を隠すためにログをスクラブしようとすることがあります。

侵入者があなたの家に侵入した場合、指紋や犯罪行為と結びつけるために使用できる手がかりを残さないように最善を尽くします。コンピュータ詐欺や違法行為についても同様です。攻撃者は、この識別情報を保持する監査ログを削除することがよくあります。文中では削除することをスクラブと表現しています。この情報を削除すると、管理者に警告やセキュリティ侵害を認識し、貴重なデータが破壊されることができないことがあります。 したがって、厳密なアクセス制御によって監査ログを保護する必要があります。

災害復旧計画（Disaster Recovery Planning）には、軽減、準備、対応、および回復のライフサイクルがあります。

• 軽減：災害の影響と可能性を減らします。
• 準備：対応のためのプログラム、手順、ツールを作成します。
• 対応：手順に従って、災害時にどのように対応するか。
• 回復：基本機能を再確立し、完全な本番環境に戻します。

〇：ウイルスがパッチされていないファイルバージョンをバックアップメディアから復元します。

最善の方法は、バックアップメディアからパッチされていないファイルの未感染バージョンをインストールすることです。 ファイルを駆除しようとすると破損する恐れがあり、クリーンであることがわかっているファイルを復元することが重要です。何より影響を広げないことが大事ですが、ファイルを一方的に削除しようとすると、後の調査に利用できなくなる恐れもあります。よって正解は、「ウイルスがパッチされていないファイルバージョンをバックアップメディアから復元します。」になります。

×：前日に保存したファイルに置き換えます。

前日保存したファイルにもウイルスが存在している可能性があります。

×：ファイルを削除し、ベンダーに連絡します。

ファイルを削除した場合、正常なファイル内容そのものが損傷する可能性があることが、本問題の条件となっていますので、不正解になります。

×：データをバックアップし、ファイルを削除します。

ウイルスの入っているデータをバックアップし、ファイルを削除してもクリーンな状態にはならないため、不正解となります。

RPO（Recovery Point Objective）とは、障害発生時、過去時点のデータの復旧目標値です。障害が発生した際には、現在扱っているデータがなくなります。なくなってしまったデータはバックアップから復旧する必要がありますが、そのバックアップが現時点からどれぐらい過去のものであるかが重要になります。

RTO（Recovery Time Objective）とは、障害発生時、いつまでに復旧させるかを定めた目標値です。障害が発生した際に、いつまでもサービスを利用できないことは避けなければなりません。障害対応手順と災害訓練を実施し、障害が発生してからサービス起動に係るまでの目標値を定めておく必要があります。

アーカイブビットとは以前のバックアップ時点からの更新されたものを示します。フルバックアップは全量バックアップ対象であり、変更箇所を意識する必要がありません。増分バックアップも、バックアップ部分があらかじめ決められているため、変更箇所を意識する必要がありません。したがって、両方ともにアーカイブビットをクリアします。しかし、差分バックアップは変更箇所のみをバックアップ対象と知るため、アーカイブビットをクリアしません。

〇：オペレーション継続計画

オペレーション継続計画（COOP）は、上級管理職や災害後の本部を確立します。また、役割と権限、個々の役割タスクの概要を示します。COOPを作成すると、組織はミッションクリティカルなスタッフ、資源、手順、機器を識別するためにどのように動作するかを評価することから始まります。サプライヤー、パートナー、請負業者が日常的に相互に協力する他の企業を特定し、これらの企業のリストを作成します。よって正解は、「オペレーション継続計画」になります。

×：サイバーインシデント対応計画

サイバーインシデント対応計画（Cyber Incident Recovery）とは、サイバー攻撃を受けた時の復旧計画です。

×：乗員緊急計画

乗員緊急計画とは、施設のスタッフを円滑に安全な環境に移行させるための計画です。

×：ITコンティンジェンシープラン

コンティンジェンシープランとは、事故や災害など非常事態が発生した場合に備えて、対応策をまとめた計画です。

災害は原因によって自然、人的、環境の分類されます。人的とは、テロリズム、ハクティビズム、フィッシングなど、人間が意図的または無意識に行うヒューマンエラーです。

〇：ビジネスパートナーにあなたの会社が準備ができていないことを知らせる

計画済みのビジネス継続性手続きにより、組織は多くのメリットを得ることができます。組織は、以前にリストされた他の回答オプションに加えて、緊急事態への迅速かつ適切な対応を提供し、ビジネスへの影響を軽減し、復旧期間中に外部ベンダーと協力することができます。これらの分野における取り組みは、災害発生時に備えて準備されていることをビジネスパートナーに伝える必要があります。

×：重要なビジネス機能の再開

事業継続計画により、組織は重要なビジネス機能を再開できるため、間違っています。 BCPの作成の一環として、BCPチームは重要なリソースの最大許容ダウンタイムの特定を含むビジネスインパクト分析を行います。この取り組みは、チームが最も重要なリソースを最初に回復できるように、復旧作業の優先順位付けに役立ちます。

×：人命の保護と安全の確保

事業継続計画により、組織は人命を守り安全を確保することができるため、間違っています。人々は会社の最も貴重な資産です。したがって、人的資源は、復旧と継続のプロセスにとって不可欠な要素であり、完全に考慮して計画に統合する必要があります。これが完了すると、事業継続計画は企業が従業員を守るのに役立ちます。

×：ビジネスの存続可能性の確保

計画された事業継続計画により企業が事業の存続可能性を保証できるため、誤りである。事業継続計画は、長期的な停電や災害に対処するための方法と手順を提供します。それは、元の施設が修復されている間に、重要なシステムを別の環境に移すことと、通常の操作が戻ってくるまで別のモードでビジネス操作を行うことを含みます。要するに、ビジネス継続計画は、緊急事態の後にビジネスがどのように行われるかを扱っています。

〇：ソフトウェア構成管理

ソフトウェア構成管理（SCM）を提供する製品は様々な点でのソフトウェアの属性を識別し、ソフトウェア開発ライフサイクル全体を通してソフトウェアの完全性と追跡可能性を維持するために、統合的な制御を行います。ソフトウェア開発プロジェクトの間に、中央集中型のコードリポジトリとして管理し、単一のマスターセットに対して複数の人によって作られたリビジョンを追跡するSCM機能を行うことができるでしょう。

×：ソフトウェア変更管理

ソフトウェア変更管理は、ソフトウェア構成管理の一部のみです。変更管理では古いバージョンを使用することへの抑止の意図に即しません。

×：ソフトウェアエスクロー

コードを開発したベンダーが破産など特定の状況が発生した場合に、顧客にリリースする予定のソフトウェアエスクローフレームワークでは、第三者がソースコードのコピーを保持します。

×：ソフトウェアリストア

ソフトウェアリストアは利用される場面によってその意味は変わってくるでしょう。一般的には、初期状態に戻すことやバックアップから以前の安定稼働できる状態に復元することを指します。

〇：オフサイトの選択肢のとして最も安くなりえますが、混合操作により多くのセキュリティ上の問題が生じる可能性があります。

相互扶助もしくは互恵協定は、A社がB社は、災害に見舞われた場合、両社がその施設を利用することを可能にすることに同意するものとします。これは、他のオフサイトの選択肢よりも安価な方法ですが、常に最良の選択ではありません。ほとんどの環境では、施設の空間、資源、および計算能力の使用に関する限界に達しています。別の会社が両方に有害になるかもしれません。相互扶助は、新聞印刷業者のように特定の企業にうまく機能することが知られています。これらの企業は、任意のサブスクリプションサービスを介して利用できませんし、具体的な技術と設備を必要とします。他のほとんどの組織では、互恵協定は一般的には災害保護のための二次的なオプションになります。

×：完全なサイトとして設定され、数時間内で動作する準備ができますが、オフサイトの選択肢の中で最も高価です。

ホットサイトに関する説明です。

×：安価な選択肢ですが、災害後に起動して実行得るために最も時間と労力がかかります。

コールドサイトに関する説明です。

×：プロプライエタリなソフトウェアに依存する企業のための良い代替ですが、毎年定期的に行うテストは通常​​使用できません。

プロプライエタリなソフトウェアに依存企業に関して記述しているので間違っています。プロプライエタリなソフトウェアを他ベンダーとの共有スペースに置くことは、ライセンス契約にかかわる観点から基本的には望まれません。

災害は原因によって自然、人的、環境の分類されます。自然災害は自然、ヒューマンエラーは人的、施設や装備などは環境に当たります。よって正解は、「自然」になります。