クラウドの障害対応・フォレンジック-CSAのクラウド・インシデント対応枠組

クラウドからの情報流出が世間を騒がせたということも記憶に新しい(「責任共有モデル」という前に とか、「 Salesforceの設定不備に起因した外部からのアクセス事案についてまとめてみた」を参照)ところですが、クラウド・セキュリティアライアンスから、「クラウド・インシデント対応枠組」が公表されています。

ちなみに2021年5月12日 現在、「米セールスフォースで障害 日本もワクチン予約で影響」という記事も世間を騒がしています。

一般のインシデント対応については、いろいろな解説も出ていますし、また、法的な観点に重点をおいたものとしては、情報処理推進機構「情報漏えいインシデント対応方策に関する調査報告書」( 委託先カーネギーメロン大学日本校)調査委員会 座長(平成19年8月発表」があります。

しかしながら、クラウドコンピューティングというのは、仮想化技術と分散コンピュータ技術の上になりたっているのですが、フォレンジックスの最後の砦であるデータの分析が、そのままでは使えないので、インシデント対等において、フォレンジックスをどのようにして行うかというのが大きな論点のひとつになっています。そのような問題も含めて、どのようにインシデント対応枠組が論じているかというのをみていくことにしましょう。

1 は序です。クラウドのインシデント対応枠組が必要な理由について

 しかし、クラウドコンピューティング環境が組み込まれると、従来のインシデント対応フレームワークで定義されていた役割と責任を クラウドサービスプロバイダ(CSP)とクラウドサービスカスタマ(CSC)の役割と責任に合わせて従来のインシデント対応フレームワークを見直し、改良する必要があります。

2は、規範的参考文献です。

具体的には、

などが参照されています。

マッピングは、こんな感じです。

準備 探知および分析 封じ込め、根絶、および回復 事後処理
CSA Sec.ガイダンス v4.0 9.1.2.1 準備フェーズ 9.1.2.2 探知および分析 9.1.2.3 封じ込め、根絶、および回復 9.1.2.4事後処理
NIST 800-61r2 3.1 準備 3.2 探知および分析 3.3 封じ込め、根絶、そして回復 3.4 インシデント後の活動
TR 62 0.1 4.2 COIRのカテゴリー
5.1 クラウドが停止する前に CSC
6.1 クラウドが停止する前に CSP
5.2 停電時の CSC
6.2 障害発生時 CSP
5.3 障害発生後 CSC
6.3 障害発生後 CSP
FedRAMPインシデント 一般手順 5.1 準備 5.2 検知と分析 5.3 封じ込め、根絶、および回復 事件後の活動
NIST 800-53 3.1 セキュリティコントロール

ベースラインの選択

付録F-IR
AT-2, 1R-4, IR-6, 1R-7, IR-9,
SC-5, SI-4
付録F-IR 1R-4、IR-6、IR-7、IR-9
インシデント ハンドラーズ ハンドブック 2 準備 8チェックリスト 3 識別 8 チェックリスト 4 封じ込め 5 撲滅
6 回収
8 チェックリスト
7 学習した教訓
8 チェックリスト
NISA クラウド・コンピューティング・リスク・アセスメント 事業継続性管理

3は、定義です。資産、インシデント、報告可能なインシデント、インシデント取扱、インシデント対応プラン、などが定義されています。

4は、フレームワークの概略です。ここで興味深いのは、非クラウドにおけるインシデント対応との違いとしては、ガバナンス、責任の共有、可視性などの特徴があげられていることです。

責任の共有というのは、

クラウドサービスのお客様、CSP、またはサードパーティ・プロバイダーは、クラウド・セキュリティを確保するためにそれぞれ異なる役割を担っています。一般的には、顧客は自分のデータに責任を負い、CSPは提供するクラウドインフラストラクチャとサービスに責任を負います。クラウドのインシデント対応は、常にすべての当事者間で調整されるべきです。

ほかに、サービスプロバイダの多様性

組織は、CSC、CSP、またはサードパーティのクラウドプロバイダーとの連携に向けて、一貫した明確なマルチクラウド戦略の枠組みを持つ必要があります。単一の CSC、CSP、またはサードパーティのクラウド・プロバイダーとの「オールイン」戦略をとる企業は、サービス・プロバイダー側で障害が発生した場合に、間接的に単一障害点を導入することになります。

可視性というのは、

クラウドでは可視化されていないため、すぐに修復できたはずのインシデントがすぐに対処できず、さらにエスカレートする危険性があります。クラウドは、適切に活用すれば、より早く、より安く、より効果的なIRを実現することができます。CSPとそのパートナーが提供するクラウド・プラットフォームには、検知、反応、回復、フォレンジックの能力を大幅に向上させるツール、情報源、サービス、機能がすでに数多く組み込まれています。従来のデータセンターモデルではなく、クラウド・アーキテクチャを活用する際には、IRのプロセスや文書の作成に注意を払う必要があります。CIR はプロアクティブであり、プロセス全体を通して障害が発生しないように設計されていなければなりません。

とされています。

上のマッピングのところでもでていますが枠組は、NIST の800-61 rev2 08/2012でも用いられている

  • 準備
  • 探知および分析
  • 封じ込め、根絶、および回復
  • 事後処理

の段階からなる一般的な枠組を採用しています。

個別の段階ごとに、クラウドに特徴的なものをピックアップしてみましょう。

準備

CSC は、すべてのシステムの所有者ではありません。採用されているサービスモデルとそれに対応する責任共有モデルに応じて、一部の成果物やログはCSPが管理します。サードパーティの IR プロバイダを採用した場合、CIR プランには彼らもプロセス全体に含める必要があります。この機会に、緊急対応時にリソースへの迅速なアクセスを確保するために、サードパーティのIRベンダーの精査を検討することをお勧めします。

探知および分析

兆候やインディケータについては、特段の違いがあるわけではありません。

インシデント分析/通知においては、クラウドカスタマーとクラウドサービスプロバイダが、事案をエスカレーションさせて対応させるマトリックスを発展させるべきことが記載されています。

また、5.2.3 は、証拠収集および取扱です。この点がもっともおおきなポイントといえるというのが私の意見となります。

CSPは、GDPRやその他のコンプライアンス要件により、ログの保持期間を制限する場合があることに注意してください。 これらの制限を理解し、インシデント対応計画において考慮する必要があります。ログの可用性は、必要な証拠収集に影響を与えるからです(選択したクラウドサービスによって異なります)。

関連するデータの場所としては、仮想インスタンスに接続されたストレージ・ドライブやインスタンスのメモリ領域などが考えられます。CIRチームは、インスタンス用スナップショットなどのCSPの機能を利用することで、インシデントに接続された仮想ストレージ・ドライブのスナップショットを取得し、さらなる分析や発見に役立てることができます。これらのスナップショットは、デジタル・フォレンジック調査リソースにマウントされ、広く使用されているフォレンジック分析ツールセットで精査することができます。

また、収集した証拠品は、ハッシュ化処理を行う必要があります。これにより、収集した情報の完全性と、データが元のソースから変更されていないことを確認することができます。また、この作業は、潜在的な法的手続きに関する証拠の許容性を確保するのにも役立つ。法廷で認められるために、収集した証拠のコピー(ハッシュ化されたオリジナルのデータではなく)に対してフォレンジック作業を確実に実施する。

スナップショットというのは、

スナップショットとは、ある時点でのソースコードや、ファイル、ディレクトリ、データベースファイルなどの状態を抜き出したもののことです。

となります(IDC 用語集|スナップショット)。クラウドでない場合には、ディスクをクローンして、そのディスクを分析するという手法を最終的にとることができます。しかしながら、クラウドのもとでは、このようなディスクのデータを探していくという技術が使えないので、スナップショットに頼ることになります。

封じ込め、根絶、回復 /事後処理

これらについては、特段クラウド環境におけるものとしての特別な配慮というものは記載されていないように思われます。

ので、省略。

関連記事

  1. サービスとしてのランサムウエア-「サイバー攻撃、実行容易に」の記…
  2. 「責任共有モデル」という前に
  3. ワッサナーアレンジメント・外為法と安全保障-「留学生へ安保技術 …
  4. 「政府機関等における 今後の LINE サービス等の利用の際の考…
  5. 通信の秘密と「トロイの楯」作戦の法的枠組-保存通信データの捜査令…
  6. サイバー攻撃に「おとり」・・ウイルスを誘導
  7. 脅威情報共有のプラットフォーム(5)-MISPとNIS指令
  8. 「サイバー攻撃の国際法」(タリン・マニュアル2.0の解説)を読む…
PAGE TOP