海の向こうの“セキュリティ”
クラウドで発生したインシデントに対応するためには
クラウドセキュリティの非営利団体CSAがガイドを公開
2021年6月3日 06:00
クラウドインシデント対応フレームワーク
クラウドのセキュリティに関して国際的に活動している非営利団体クラウドセキュリティアライアンス（CSA）は、クラウドで発生したインシデントに対応するためのガイド「Cloud Incident Response（CIR）Framework」を公開しました。これはCSAの「Cloud Incident Response WG」によって作成されたもので、何らかの攻撃によるセキュリティインシデントだけでなく、ミスオペレーションやシステム障害など、さまざまな要因によるインシデントを対象としています。
なお、この文書では以下の省略形が使われています。
CIR = Cloud Incident Response
CSP = Cloud Service Provider
CSC = Cloud Service Customer
今回公開されたフレームワークは基本的にはCSCを対象としたものですが、インシデント対応の方法を顧客と共有することを考えているCSPも対象としています。
フレームワークそのものを紹介する前に、まず本文書ではクラウドのインシデント対応が非クラウドのインシデント対応と異なる重要なポイントとして、以下の4点を挙げています。なお、英語の後ろの括弧内の日本語は参考訳です。
1. Governance（ガバナンス）
クラウド上のデータは複数の場所に存在し、おそらく異なる複数のCSPが存在する。さまざまな組織が集まってインシデントを調査することは非常に困難なことである。また、膨大な数の顧客を抱える大規模なCSPではリソースが不足している。
2. Shared responsibility（共同責任／責任共有）
クラウドサービスの顧客やCSP、サードパーティプロバイダーは、クラウドセキュリティを確保するために、それぞれ異なる役割を担っている。一般的には、顧客は自分のデータに責任を負い、CSPは自らが提供するクラウドインフラストラクチャとサービスに責任を負う。クラウドのインシデント対応は常に全ての当事者間で調整されるべきである。
また、責任を共有する領域は、SaaS（Software as a Service）、PaaS（Platform as a Service）、IaaS（Infrastructure as a Service）など、選択したクラウドサービスのモデルによってCSPとCSCの間で異なる。この考え方をよく理解しなければならない。例えば、IaaSの場合、OSの管理はCSCが行なう。したがって、OSについてのIR（インシデント対応）の責任もCSCが負うことになる。
CSPとの契約やSLA（Service Level Agreement）の中で役割やガバナンスが明確かつ十分に文書化されているか、詳細に議論することが重要である。CSCは実施できないポリシーを作成したり、受け入れたりしてはならない。どの組織もガバナンスや共同責任のうち自らの担当部分を外部に委託することは決してできないと理解すべきである。
3. Service Provider Diversity（サービスプロバイダーの多様性）
組織はCSCやCSP、サードパーティのクラウドプロバイダーとの連携に向けて一貫性がありかつ明確に定義されたマルチクラウド戦略／フレームワークを持つべきである。単一のCSC、CSP、またはサードパーティのクラウドプロバイダーとの「オールイン」戦略を採っている組織はサービスプロバイダー側で障害が発生した場合に間接的に単一障害点を導入していることになる。
クラウドサービスを単一のCSPで提供すると組織が管理できないCSC/CSPで何らかの障害が発生した場合、組織のビジネスが継続的に停止する事態に陥る可能性がある。このシナリオは事業運営に大きな影響を与え、かつ事業継続計画（BCP）戦略が回復できず、結果として組織全体のCIRイベントになる可能性がある。
CIRの観点からサービスプロバイダーの多様性を検討する際には、デジタルサービスの主権（データの保管場所、データの主権など）の側面でも組織は計画の中で考慮することが推奨される。
4. Visibility（可視性）
クラウドに十分な可視性がないことは、すぐに解決できたはずのインシデントが迅速に対処されず、かつ、さらにエスカレートする危険性があることを意味する。クラウドは適切に活用すればより速く、より安く、そしてより効果的にIRを実現できる。CSPとそのパートナーが提供するクラウドプラットフォームには、検知や反応、回復、フォレンジクス能力を大幅に向上させるツールや情報源、サービス、機能が既に数多く組み込まれている。従来のデータセンターモデルの代わりにクラウドアーキテクチャを活用する際にはIRのプロセスや文書の作成に注意を払わなければならない。CIRはプロアクティブでかつプロセス全体を通して障害に耐えられるように設計されていなければならない。
上記の点を踏まえ、今回のフレームワークは以下の4つのフェーズから構成されています。
1. Preparation（準備）
2. Detection and Analysis（検知と分析）
3. Containment, Eradication, and Recovery（封じ込め、根絶、復旧）
4. Post-Mortem（事後検証）
各フェーズの既存の標準やフレームワークとの関係を示したのが以下の表です。
これらの4つのフェーズはそれぞれ以下のような内容になっています。
1. Preparation（準備）
クラウドのインシデントが発生する前に必要な戦略とアクションを記している。効果的なインシデント対応計画にはCIRチーム（CIRT）の結成、戦略の立案と準備、手順の策定、技術的な準備、およびコミュニケーション計画の策定が含まれる。
1.1 Documentation（文書化）
2. Detection and Analysis（検知と分析）
クラウドインシデントを早期に検知するためのさまざまな兆候および考えられる原因を取り上げている。根本的な原因を特定するために、複数の手段について論じられている。また、CSP/CSCの考慮事項としてインシデントの早期通知のスピード（およびビジネスへの影響に応じた解決のタイミング）にも着目している。
2.1 Inducement（誘引）
2.1.1 Cause of Cloud Incident（クラウドインシデントの原因）
2.1.2 Signs of an Incident（インシデントの兆候）
2.1.3 Common Sources of Precursors and Indicators（前兆と指標の一般的な情報源）
2.2 Incident Analysis to Determine Impacts（影響度を把握するためのインシデント分析）
2.2.1 Incident Analysis（インシデントの分析）
2.2.2 Incident Notification（インシデントの通知）
2.2.2.1 Incident Notification Timing（インシデントの通知タイミング）
2.2.3 Incident Impacts（インシデントの影響）
2.3 Evidence Gathering and Handling（証拠の収集と処理）
3. Containment, Eradication, and Recovery（封じ込め、根絶、復旧）
調査やフォレンジクスが行われている間に攻撃者がシステムにさらなるダメージを与えないようにするための適切な戦略を選択することの重要性を説明している。
3.1 Choosing a Containment Strategy（封じ込め戦略の選択）
3.2 Eradication and Recovery（根絶と復旧）
4. Post-Mortem（事後検証）
人員、プロセス、または技術におけるギャップを特定し、これらを準備フェーズに取り込まなければならない「教訓」に変換するプロセスである。この終結フェーズの主な目的は将来のインシデントハンドリングを改善することである。企業のセキュリティ能力を改善するためには、CSP（該当する場合）のインシデント／フォレンジクスサポート、イベント分析をサポートするために利用可能な技術ツール、アクター（攻撃主体）が使用するTTP（Tactics, Techniques and Procedures）、フォレンジクス調査の実施についてレビューすることが極めて重要である。
4.1 Incident Evaluation（インシデントの評価）
4.1.1 Incident Evaluation Metrics（インシデントの評価指標）
4.1.2 Incident Classification（インシデントの分類）
4.2 Incident Closing Report（インシデントの終結報告）
4.2.1 Lessons Learned（学んだ教訓）
4.3 Incident Evidence Retention（インシデントの証拠の保持）
フレームワーク自体は上記4つのフェーズで構成されていますが、クラウドのインシデント対応において重要なポイントとして、本文書ではさらに「Coordination and Information Sharing（調整と情報共有）」を挙げ、クラウドに対する脅威が複雑なことから利害関係者が損失を軽減するためにセキュリティ情報を調整および共有する必要があることを説明しています。項目は以下の通り。
1. Coordination（調整）
1.1 Coordination Relationships（調整関係）
1.2 Sharing Agreements and Reporting Requirements（共有契約と報告要件）
2. Information-Sharing Techniques（情報共有技術）
3. Granular Information Sharing（粒度の高い情報共有）
3.1 Business Impact Information（ビジネスへの影響に関する情報）
3.2 Technical Information（技術情報）
3.3 CSP Dashboard （CSPダッシュボード）
4. Table-Top Exercises and Incident Simulations（机上演習とインシデントシミュレーション）
結論として本文書ではこのフレームワークを以下のように使えるとまとめています。
1. CSCがセキュリティ要件と適切なインシデント保護レベルを決定する際の指針
2. CSCがCSPやサードパーティと交渉して能力や共同責任を確認する際の指針
多くの企業や組織がインシデント対応のポリシーやプロセスを定めていますが、その一方で、従来のオンプレミスを前提にした内容のまま更新しておらず、インシデントが発生して初めて「実はアウトソースされていた」ことをCSIRTなどのセキュリティ担当者が認知するケースも少なくありません。ログを確認するといったインシデント対応の基本中の基本のアクションですら、クラウドの場合は極めて困難、契約によっては不可能な場合もあります。今回公開されたフレームワークを参考に、改めて自組織のインシデント対応のポリシーやプロセスを見直してみることを強くお勧めします。
- CSA （Cloud Security Alliance） Press Release （2021年5月4日）
Cloud Security Alliance’s New Cloud Incident Response Framework Serves as Transparent, Common Blueprint Through Which to Share Best Practices - https://cloudsecurityalliance.org/press-releases/2021/05/04/cloud-security-alliance-s-new-cloud-incident-response-framework-serves-as-transparent-common-blueprint-through-which-to-share-best-practices/
- Cloud Security Alliance（2021年5月4日）
Cloud Incident Response Framework - https://cloudsecurityalliance.org/artifacts/cloud-incident-response-framework/
- まるちゃんの情報セキュリティ気まぐれ日記（2021年5月5日）
Cloud Security Alliance がクラウド利用時のインシデント対応のためのガイドを公表していますね。。。 - http://maruyama-mitsuhiko.cocolog-nifty.com/security/2021/05/post-22bb96.html
- ITリサーチ・アート（2021年5月12日）
クラウドの障害対応・フォレンジック-CSAのクラウド・インシデント対応枠組 - https://itresearchart.biz/?p=2810
CSIRT研究家、フリーライター、翻訳家、コンサルタント。最近は主に組織内CSIRTの構築・運用に関する調査研究や文書の執筆、講演などを行なっている。JPCERT/CC専門委員。日本シーサート協議会専門委員。