情報セキュリティマネジメント試験 用語辞典
経済産業省や厚生労働省の資料では、BCPの発動から全面復旧に至るまでを以下の4段階のフェーズに分けている。
- 1.BCP発動フェーズ
- 災害や事故の発生（或いは発生の可能性）を検知してから、初期対応を実施し、BCP発動に至るまでのフェーズ
- 2.業務再開フェーズ
- BCPを発動してから、バックアップサイト・手作業などの代替手段により業務を再開し、軌道に乗せるまでフェーズ
- 3.業務回復フェーズ
- 最も緊急度の高い業務や機能が再開された後、さらに業務の範囲を拡大するフェーズ
- 4.全面復旧フェーズ
- 代替設備・手段から平常運用へ切り替えるフェーズ
- 別名：
- 事業継続計画
- 分野：
- 情報セキュリティ管理 » 情報セキュリティ継続
(シラバス範囲外) - 重要度：
(Wikipedia 事業継続計画より)
事業継続計画（Business continuity planning、BCP）は「競争的優位性と価値体系の完全性を維持しながら、組織が内外の脅威にさらされる事態を識別し、効果的防止策と組織の回復策を提供するためハードウェア資産とソフトウェア資産を総合する計画」のこと。事業継続と復旧計画（Business Continuity & Resiliency Planning、BCRP）とも呼ばれる。
歴史
2004年に、イギリスは民間緊急事態法2004（すべての救急隊と地方自治体に、非常事態に対して積極的に備えと計画するよう命じる法規）を制定した。地方自治体も、それぞれの地理的地域に事業継続経験の促進を積極的に導くこの法令の下で法的義務がある。
2006年12月に、英国規格協会はBCP ? BS 25999-1のための新しい独立した標準を発行した。の発表以前のBCP専門家date=2011年7月は、組織の情報セキュリティ遵守を改善するためにBCP周辺を論じるだけのBSI情報セキュリティ標準であるを頼りにした。BS 25999の適用性は、政府及び民間、営利及び非営利、大規模及び小規模、あるいは産業セクタのどちらでも、種類、規模、及び業務のすべてにまで拡大された。
2007年に、BSIは、ドキュメント化された事業継続管理システム（BCMS）の実装、運用および改良のための要求を規定する、第２部、BS 25999-2「事業継続管理のための仕様」を出版した。
概論
完全なBCPサイクルは混乱の事前、最中、及び事後に利用可能な、印刷されたマニュアルである。その目的は、中断の範囲（それがどの程度何にどんな影響するか）と期間（たとえば、何時間、何日、何ヶ月）との両方によって決まる影響を受ける不利な利害関係者を減らすことである。測定可能な事業影響分析（BIA）『ゾーン』（危険と脅威のある領域、市民、経済、自然、技術、２次的及び後続の存在）を含む領域。
BCPにおける長期的災害は、自然災害、人災、及び混乱を表すため使われる。
2001年1月1日以前、政府は2000年問題と呼ばれた、銀行、 電力、 電信、健康及び財政産業のような、重要な公的ユーティリティのインフラにおける、コンピュータ不具合を予測した。 1983年から、及びなどの規制機関は、彼らの支援メンバーに公的利益を守る運営継続プラクティス（後により公式なBCPマニュアルよって支援された）の行使を要求した。より新しい規制は、しばしばISO/IEC 17799又はBS 7799の下で定義された公式の標準を基盤とする。
BCPに焦点を当てた規制とグローバル事業は2000年問題解決の後、衰退した。ある人date=2011年7月はアメリカ同時多発テロ事件で、ニューヨークの荒廃したダウンタウンを同時テロ攻撃し、そして事業継続計画の最悪のシナリオのパラダイムを変えた時、この緩んだ姿勢が終わったと確信した。
BCP方法論は、あらゆる規模とあらゆる複雑な組織のためスケーラブルである。方法論は、をルーツに持つにもかかわらず、組織のあらゆる特徴は、一つのBCPマニュアルを作成する可能性がある。そして間違いなく、すべての組織は組織の延命を確かにするためそれを持つべきである。企業がBCPの準備に十分な時間と資源を投資しない証拠は、災害生残り統計で明らかにされる。火災は影響を受けた事業の44％を永久に凍結するため。世界貿易センター爆破事件で150～350の事業が影響を受け、その後を生残れなかった。逆に、BCPマニュアルを良く開発しテストしていたアメリカ同時多発テロ事件によって影響を受けた企業は、数日中に事業に戻ることができた。
小さな組織のためのBCPマニュアルは、第1次作業場所から離れて安全に保管された、オフサイトの場所、データ、バックアップ、保管メディア、保険契約のコピー、その他の組織生残りに必要な重要書類を伴う、危機管理スタッフ、通常スタッフメンバー、クライアント、及びベンダーのための名前、アドレス、及び電話番号を含む、単純な印刷されたマニュアルである。最も複雑なところでのBCPマニュアルは、第2次作業サイト、技術要求と覚悟、規制報告要求、作業回復測定、物理的記録の再確立の手段、新しいサプライチェーン確立の手段、新しい生産センター確立の手段をアウトラインすることである。企業は、これらのBCPマニュアルが危機中に使うため現実的でかつ容易であることを確かめるべきである。このようにBCPは、危機管理と災害復旧のそばに置く、組織のリスクマネジメントの一部である。
BCPマニュアル開発は次の5つのフェーズを持つ。
- 分析
- ソリューション設計
- 実装
- テストと検収
- 維持、修理と運用
上記のリストは決定的なものではなく、事業自身の計画／マニュアルに含まれ得るその他の考慮点がいくつかある。
- リスク識別マトリックス
- 役割と責任 （名前は残されるがタイトルは含まれることを確認する、例えばHR Manager）
- 最大リスクと緩和戦略の識別
- 資源配置のための考慮点、例えば大規模組織の技能マトリックス
インターネット上でのBCPマテリアルの多くは、BCPソリューション開発のためのフリーベース・サービスを提供するコンサルタントによってスポンサーされるが、しかし基本チュートリアルは、正しくモティベートされた組織のためのインターネット上で自由に利用可能。
分析
BCPマニュアルの開発における分析フェーズは、影響分析、脅威分析、及びBCP計画の要求ドキュメント化に帰着する影響シナリオから成る。
影響分析
影響分析（事業影響分析、BIA）は組織機能／活動の重要（緊急）と非重要（非緊急）間の違いに帰結する。ある機能は、もしその組織の結果的な被害の利害関係者への影響が受け入れられないと考えられるとき、重要と考えることができる。混乱の受入れ可能性の認識は、適切な事業あるいは技術回復ソリューションを確立し維持するコストによって変更することができる。ある機能はまた、法律によって決定されたなら重要と考えられるかもしれない。それぞれの重要な（スコープ内）機能 のため、次の2つの値が割り当てられる。
- (RPO) - 回復されるデータの受入れ可能な待ち時間
- (RTO) - その機能を復元するため受入れ可能な時間の量
回復ポイント目標は、各活動のための最大許容可能データ損失を超えないことを確かめねばならない。回復時間目標は、各活動のための(MTPD)が超えないことを確かめねばならない。
次に、影響分析は、各重要機能のための復旧要求に帰着する。復旧要求は下記の情報から成る。
- 重要機能の復旧のための事業要求
- 重要機能の復旧のための技術要求
脅威分析
は2002年にSARS流行の原因物質として提唱された。]]
復旧要求の定義の後、可能性ある脅威の文書化が特定災害に固有な復旧ステップを詳細化するため推奨されます。幾つかの一般的脅威は以下を含む。
- 疫病
- 地震
- 火災
- 洪水
- サイバーテロ
- サボタージュ（内外の脅威）
- ハリケーン又は大きな嵐
- 停電
- テロリズム
- 窃盗（内外の脅威、重要な情報及び物品）
- 基幹システムの偶発的故障
上の例にある全ての脅威は、共通の影響（組織インフラへの被害の可能性）を共有する。その影響は純粋に人間として考えられ、技術とビジネスソリューションで緩和されることもある。しかしながら、もしこれら復旧計画の裏にある人間が災害によって影響を受けるとすると、そこでプロセスは失墜し得る。
2002-2003年のSARS発生の間、ある組織はスタッフを別々のチームにグループ化し、そのチームごとの災害の潜伏期間を均等化するため、輪番周期で、1次及び2次作業サイト間で交代させた。その組織はまた、勤務時間及び非勤務時間を問わず、相手チームメンバー間の対面的接触を禁止しました。そのような分離によって組織は、もし契約されたチーム又は災害に露出した人物がいても、政府支持の防疫対策の脅威に対する彼らの回復性を増大させることができた。
洪水からの被害はまた固有な特徴を持つ。もし（例えば、配管の破裂の出来事で）、事務所環境が汚染されていない淡水で浸水したなら、装置は徹底的に乾燥すればまだ機能する可能性を持っているからである。
影響シナリオの定義
潜在的な脅威定義の後、事業復旧計画の基盤を形づくる影響シナリオの文書化が推奨される。一般に最も広範囲に及ぶ災害あるいは混乱の計画化は、ほとんどすべての小規模問題が大規模災害の部分的要素であるように、より小規模問題を計画する方が望ましい。「ビル喪失」のような典型的な影響シナリオは、すべての重要な事業機能、及びあらゆる潜在的脅威からの最悪の潜在的な結果を包括する。
事業継続計画は、もし組織が一つ以上のビルを保持するなら、追加的影響シナリオもまた文書化することができる。たとえば、あるビルの特定のフロアの一時的あるいは永久的喪失のためのシナリオのような、その他のより特定な影響シナリオもまた文書化することもできる。組織は時には、一つの現場から他に移動するため必要なスペースを低く見積もります。現場を移動することは問題を持たないため、組織はそれらを計画段階で考慮することが不可欠である。
復旧要求ドキュメント
分析フェーズ完了の後、事業と技術の計画要求は実装フェーズを始めるため文書化される。良い資産管理プログラムは、これへの大きな援助となり、資源の素早い利用性の識別と再配置可能性を可能にし得ます。一つのオフィスベース、情報技術集約的事業のため、計画要求は、データとしてクラス化される以下の要素を網羅することができる。
- 2次的場所における、一時事業所の外で求められる固定あるいは共用のいずれの、机の種類と数
- 復旧に係わる個人の連絡先と技術的詳細を伴う努力
- 重要な事業機能のため2次的場所の机から要求されるアプリケーションとアプリケーションデータ
- ワークアラウンド解決のマニュアル
- アプリケーションに許される最大停止時間
- プリンター、 コピー機、 ファックス、電卓、紙、ペン等のような周辺機器要求
生産、配送、倉庫などのその他の事業環境は、これらの要素を網羅する必要があるが、混乱の出来事に続く管理する追加的課題を持つ。
ソリューション設計
ソリューション設計フェーズの目標は、影響分析ステージからの主要な2つの要求にこたえる最もコスト効果的な災害復旧ソリューションを識別することである。ITアプリケーションのためにこれは次のように共通に表現される。
- 最低のアプリケーションとアプリケーションデータ要求
- 最低のアプリケーション及びアプリケーション・データが利用可能にならなければいけない時間フレーム
災害復旧計画はまた、例えば、ハードコピー形式での情報の保存、技能スタッフの管理、あるいはプロセスプラントに組み込まれた技術の復旧のような、ITアプリケーション以外の領域にも要求される。
このBCPフェーズは、ディザスタリカバリ方法論とオーバーラップします。ソリューションフェーズでは以下を決める。
- 危機管理コマンド構造
- 2次作業サイトの場所（必要な場合）
- 1次と2次作業サイト間の電信アーキテクチャ
- 1次と2次作業サイト間のデータ複製方法
- 2次作業サイトで要求されるアプリケーションとソフトウエア
- 2次作業サイトでの物理的データ要求の種類
実装
実装フェーズは単純で、ソリューション設計フェーズで識別された設計要素を実行することです。ワークパッケージ『テスト』は、ソリューションの実装期間中に行われることもあるが、ワークパッケージ『テスト』は組織的テストのところでは行われない。
テストと組織的受入
テストの目的は、事業継続ソリューションが組織の復旧要求を充たす組織的受入れに到達することである。計画は、不十分あるいは不正確な復旧要求、ソリューション設計、あるはソリューション実装エラーのために失敗する場合がある。テストは以下を包括する。
- 危機指令チーム呼出しチーム
- 1次から2次作業場所への技術スイングテスト
- 2次から1次作業場所への技術スイングテスト
- アプリケーションテスト
- ビジネスプロセステスト
最低限テストは、半年度あるいは年度スケジュールで一般に実行されます。初期テスト段階で識別された問題は、維持段階にロールアップされ、次期テストサイクル中に再テストすることができる。
英国規格協会（BSI）によって発行された2008年の本『Exercising for Excellence』で危機ソリューションは、事業継続計画をテストする際採用される次の3つの試験のタイプを識別した。
単純試験
単純試験はしばしば「デスクトップ」あるいは「ワークショップ」と呼ばれます。それは典型的に、おそらく5～20の少人数が係わり、事業継続計画の特定の局面、あるいは特定の主題領域（例えば、人的資源、情報技術あるいはメディア）に集中して行われる。しかしながら、単純試験の美しさは、事業の様々な領域から完全なチームを容易に対応させることができることである。その数は、そのロジスティックとともに増大されることもあるが、その目的は変わらない。
あるいは、全体チームが参加する必要よりむしろ、複数チームから一つの代表が係わることができる。それは、仮想世界の環境や日々の資源以外の必要性の提供が伴われない。一般的に、参加者は単純なシナリオを与えられ、その後会社のBCPの特定局面を議論するため招かれる。例えば、作業時間外に発見された火災では、「手順から現在の呼び出しはなにか」、「どのように事故管理チームが活性化されるか」、「どこにこれが合致しないか」、「現在の文書化された手順はすべての不測の事態をカバーするか」などである。
それはおそらく、3時間以内で最終化され、それぞれ異なったテーマに集中した2つないし3つのセッションにしばしば分離される。この場合、2つないし3つの異なったシナリオのいずれもが使われ、一つのシナリオは、アドレスされるべきニーズのテーマを導入するため進歩的に開発され得る。実時間のプレッシャーは、単純試験の通常の要素ではない。質問は、ファシリテーターが議論が生産的で出来事の目的に対して適切であることを確かにするため、時間に先だって作業されることが必要である。
中間検査
中間検査は、常に仮想世界内で実行され、通常は複数の部門、チーム、あるいは専門分野で同時に行われる。それは一般的にチーム間のBCPを促す複数の側面に集中する。
中間試験のスコープは、一つのビルを共有する一つの組織の少数のチームから、分散した場所の複数のチームの広範囲におよぶ。試みは実行可能と同じ程度の現実的環境を作り出すべきで、参加者の数は現実的状況を反映すべきである。要求される現実性の度合いに依存し、それは、シミュレートされたWebサイトとともに、シミュレートされたニュース放送を生じるのに必要となる。
中間試験は数日間にわたって取り組まれますが、通常2～3時間で最終化されるでしょう。 それらは典型的に、情報を提供し行動を促すことの試験を通してプリスクリプトされた射出で導かれたシナリオセルに関わる。
複合試験
複合試験はおそらく、可能な限り少数の境界として持つことを目的として定義することが困難である。それはおそらく中間試験の一部とより多くの局面を含む。試験の要素は、必然的に仮想世界内で残されなければならないが、しかし全ての試みが現実性達成するためになされるべきである。これは、災害復旧（DR）サイトの、通知なしの起動、実際の避難、及び呼び出しを含む。
開始時間とカットオフ時間が同意されなければならない一方で、もし出来事がリアルタイムでそれらのコースを実行することを許されるなら、試験の実際期間は未知となる。もしそれが期待される45分の代わりにDRサイトを得るため2時間が必要なら、試験はこれを扱うため、十分に柔軟でなければなりません。もし主要なプレイヤーが対応できないなら、代理者がそれに備えなければなりません。
定義
これらの定義は、利用可能な試験のタイプについて幅広いガイダンスを提供するが、それは考慮すべき「エッジのぼかし」があり得ることを認識すべきである。それは、異なった次元を追加することによって、復旧サイトで単純試験を実行することは可能であるが、これは必ずしも中間試験をするため必要ではない。分類に関わらず、試験の重要性は、その定義された目的を達成することにあるのである。
維持
BCPマニュアルの維持は、3つの周期的活動に分解される。
- 最初の活動は、役割が対応と復旧において重要と認識される個人のための自覚と特定のトレーニングのため、全てのスタッフに次々現れる、マニュアルにおける情報の確認である。
- 2番目の活動は、復旧オペレーションのための確立された技術的ソリューションのテストと検証である。
- 3番目の活動は、文書化された組織復旧手順のテストと検証です。半年あるいは1年の維持サイクルが一般である。
情報更新とテスト
全ての組織は時間を超えて変化します。そのためBCPマニュアルは、その組織に適切さを保持するため変化しなければなりません。一旦データ精度が検証されたら、通常ツリーと呼ばれるテストが、連絡先データの精度と同じように、通知計画の効率を評価することため実行される。マニュアルで識別され更新されるべき変更の幾つかのタイプは以下を含む。
- スタッフ変更
- スタッフ人材
- 重要なクライアントと彼らの連絡先の詳細の変更
- 重要なベンダー／サプライヤと彼らの連絡先詳細の変更
- 新規、閉止、又は基本的に変更された部門のような部門的変更
- 会社の投資ポートフォリオとミッション表明における変更
- サプライヤ経路における上流／下流の変更
技術ソリューションのテストと検証
進行中の維持の一部として、あらゆる特別課された技術の配備は、機能性のためチェックされねばならない。幾つかのチェック項目は下記を含む。
- コンピュータウイルス定義の配布
- アプリケーション・セキュリティとサービスのパッチの配布
- ハードウエア運用性のチェック
- アプリケーション運用性のチェック
- データ検証
- データ・アプリケーション
組織的復旧手順のテストと検証
時間を超えての作業プロセスの変更として、事前に文書化された運用的復旧手順はもう適切ではないかもしれない。そのいつかは以下を含む。
- 文書化された重要な機能のため、全ての作業プロセスか？
- 変更された重要な機能の実行において使われるシステムを持っているか？
- 文書化された作業チェックリストはスタッフのため有意義で正確か？
- 文書化された作業プロセス復旧タスクと支援する災害復旧インフラはスタッフにあらかじめ決められた復旧時間目的内で復旧することを可能にするか？
テスト不具合の取り扱い
この論文に含まれるダイアグラムで推奨されるように、テストと維持フェーズと影響フェーズ間の直接的関係がある。スクラッチからBCPマニュアルと復旧インフラを確立するとき、しばしばテストフェーズ中に見つけられた課題は、分析フェーズに再度紹介されなければならない。
ロジスティクス計画
BCPで使われるロジスティクス計画は、と呼ばれる。BCP の意図する効果は、実行中の状態及びどのように事業を行うかを統治する方法論である、事業継続を確実にすることである。BCPを策定し、運用し、訓練し、継続的改善する取組みを事業継続マネジメントという。
平易な言葉では、BCPは災害時に事業を継続する方法について定めている。典型的な事態としては、ビル火災のようなローカルな事態、地震や洪水のような地域的な事態、または世界的伝染病の流行のような国家的事態を含む。しかし、そのような事態に限らない、供給元の喪失、重要なインフラ（機械またはコンピューティング／ネットワーク資源の主要な部分）の喪失、または窃盗や破壊の結果のような、事業が依存しているあらゆる事態を含み、事業喪失の可能性を引き起こし得るあらゆる事態が考慮されなければならない。このように、リスク管理はBCPの一部として取り入れられなければならない。
- 情報セキュリティ管理(4)
- 情報資産の調査・分類(0)
- リスクの種類(2)
- 情報セキュリティアセスメント(5)
- 情報セキュリティリスク対応(10)
- 情報セキュリティ継続(6)
- 情報セキュリティ諸規定(2)
- 情報セキュリティマネジメントシステム(5)
- 情報セキュリティ組織・機関(10)
このページのWikipediaよりの記事は、ウィキペディアの「事業継続計画」(改訂履歴)の記事を複製、再配布したものにあたり、このページ内の該当部分はクリエイティブ・コモンズ 表示 - 継承 3.0 非移植 ライセンスの下 に提供されています。