インシデント対応フローでサイバー攻撃に備える。実施のポイントも紹介
脅威アクターによるサイバー攻撃が日々発生しており、デジタル環境を利用するあらゆる組織・企業が潜在的なターゲットとなっています。
クラウドサービスを始めとするIT技術の発達・普及、また経済活動におけるサプライチェーンの拡大が、サイバー攻撃者や犯罪組織に格好の機会を与えています。
このような環境下で、組織がインシデント対応（レスポンス）のための体制を確立し、サイバー攻撃に備えることは必須の課題となっています。
この記事では、インシデント対応の重要性について説明した後、必要な準備、具体的な対応フロー、そして組織のサイバー・レジリエンスを向上させるためのさらなる改善策について紹介します。
記事に関するご意見・お問い合わせはこちらへお寄せください。
(ＳＯＭＰＯホールディングス、損害保険ジャパンなどグループ各社へのお問い合わせはご遠慮下さい)
セキュリティ・インシデントとは
定義
セキュリティ・インシデントは、サイバーセキュリティが目標とする情報の機密性、完全性、可用性を侵害する事象です。
米国標準技術研究所（NIST）は、セキュリティ・インシデントを次のように定義しています。
この定義は、アメリカ国防総省が防衛企業に対し義務付けし、また我が国の防衛省も参照しているセキュリティ基準NIST SP800-171でも利用されています。
An occurrence that actually or imminently jeopardizes, without lawful authority, the confidentiality, integrity, or availability of information or an information system; or constitutes a violation or imminent threat of violation of law, security policies, security procedures, or acceptable use policies.
（法的権限なしに、情報または情報システムの機密性、完全性、または可用性を実際の危険あるいは差し迫った危険にさらす事象。または法律、セキュリティポリシー、セキュリティ手順、許可ポリシーへの違反、あるいは違反のおそれからなる事象。）
つまり、我々が普段利用している情報システムやそのシステムが取り扱う情報、あるいはセキュリティポリシーやサイバーセキュリティ関連法規を脅かす事象全般を指すといえます。
セキュリティ・インシデントの例
セキュリティ・インシデントの厳密な定義は出典によって様々であり、また抽象的でイメージが掴みにくいものもあります。
「では具体的にどのようなパターンがあるのか」ということを明示するため、本項ではニュース等で目にする機会の多い事例を参考に、いくつかの種類を紹介します。
- マルウェア感染
- ランサムウェア感染
- メールサーバー不正中継
- DDoS攻撃
- 不正アクセスによる情報窃取
- Webサイト改ざん
- 決済システム改ざん
- フィッシング詐欺
- サポート詐欺
- ビジネスメール詐欺（BEC）
- アカウント乗っ取り
- 内部脅威
- ヒューマンファクター（操作ミス、設定ミス、紛失）
- 従業員や退職者による意図的な犯行
本記事がスコープとするセキュリティ・インシデント
このように列挙するだけでも、セキュリティ・インシデントがとても身近に潜むリスクであることがわかります。
なおセキュリティ・インシデントの定義には、いわゆるサイバー攻撃やインサイダー攻撃（内部犯による）に加えて、事故や災害等による情報の毀損等も含まれます。
インシデント対応フローとその確立に焦点を置く本記事では、外部・内部の攻撃者によって生起するセキュリティ・インシデントに対象を絞って説明を進めていきます。
インシデント対応はなぜ重要なのか？
サイバーセキュリティ・リスクは、企業・組織がマネジメントすべき重要課題です。
冒頭に記載したとおり、IT・デジタル環境とサプライチェーンの広がりに伴い、サイバーセキュリティリスク、つまりセキュリティ・インシデントの発生によるリスクの発生確率や影響も増大を続けています。
インシデント対応は、速やかに事態を収束させ、また被害を最小化するための極めて重要なプロセスです。
インシデント対応を行うための体制整備や計画が欠如していた場合、いざセキュリティ・インシデントが発生した場合に適切に対応できないのみならず、インシデントに起因する損害や信用の低下を招きかねません。
インシデント対応の重要性を簡単にまとめると次のとおりです。
理由1 初動対応によって被害を最小化
セキュリティ・インシデントの兆候を検知したとき、速やかに対応できるかどうかで、その後の結果が大きく変わります。
例えばエンドポイント製品やEDRが不審な活動やマルウェアの存在を検知したとしても、この事象をスピード感をもって処理できない場合、攻撃者がさらに組織の環境を侵害する猶予を与えてしまいます。
今日のランサムウェア、例えばLockBitやロールシャッハ等は、高速な暗号化アルゴリズムの利用や断続的暗号化により、従来と比して高速な暗号化能力を行使します。
BlackByteランサムウェアのように、組織のシステム侵入から短期間で暗号化を行う戦術を運用するグループもあるため、初動対応の重要性は高まっています。
理由2 コミュニケーション保持による事態の早期収束
セキュリティ・インシデント発生時に、組織内のコミュニケーション、またステークホルダーや顧客等とのコミュニケーションを適切に処理することは重要です。
重大なセキュリティ・インシデントが発生した場合、影響はセキュリティ部署や情報システム部署を超えて波及します。
- 重要システムやネットワークが運用中断し、業務が継続できなくなった
- 顧客の個人情報やクレジットカード情報が流出した
- 従業員のアカウントから顧客や取引先に対して迷惑メールが大量送信された
事前の準備や組織体制の確立、セキュリティ・インシデント発生時の対応要領が定まっていないと、混乱や不信を招くおそれがあります。
理由3 事後対応を通じたレジリエンスの向上
サイバー攻撃の手段は日々変化・進化しており、いかなる組織であっても攻撃を100%阻止するのは至難の業です。
攻撃者に侵入された状況を想定し体制を整備することで、被害を受けた後の見直しや改善につなげることができます。
インシデント・レスポンス・サイクルは、セキュリティ・インシデント後の改善や、教育、訓練演習を通じた組織のサイバーレジリエンス向上を目的の1つとしています。
サイバー攻撃の被害を被ったものの、その時のログや行動記録がなければ見直しもできず、改善点を挙げていくことも困難です。
インシデントの発生から適切な知見を吸収・反映できない組織は、将来的に同じような攻撃に遭う可能性が高いといえます。
インシデント対応計画がないと……
適切なインシデント対応ができない場合、様々な問題が発生します。
|
経済産業省「サイバーセキュリティ経営ガイドライン3.0」（外部リンク）では、「インシデント発生時の緊急対応体制の整備」を怠った場合のシナリオとして、以下の4項目をあげています。
- 調査作業において、内外関係者間のコミュニケーションが取れず、速やかな対処ができない
- 速やかな情報開示ができず、損害賠償請求など責任を問われる
- 所轄官庁等への報告義務に抵触し、罰則等を受ける
- 演習を行わないため担当者の練度が十分でなく、事態発生時に被害拡大・長期化を招く
海外拠点を持つ企業や海外との取引を行う企業については、インシデント発生時や個人情報漏洩時の迅速な報告を義務付けるGDPR等も遵守する必要があります。
GDPRに違反した場合の罰則金は莫大であり、組織運営に直結するリスクとなります。
地震や火災に備えた防災計画や避難訓練を、多くの組織・企業が実践しています。
「うちは大丈夫だろう」、「その場で何とかなる」という風に、セキュリティ・インシデントに対する計画や訓練を行わないということは、組織としてサイバーセキュリティ・リスクへの備えを放棄しているととらえられる可能性があります。
インシデント対応のための事前準備
セキュリティ・インシデント対応を行うためには、組織としての事前準備が必要です。
この章の目的は、セキュリティ・インシデントに適切に対応するための体制を確立することです。インシデント対応に必要な基盤を整備し、攻撃や不正に対する準備、検知、速やかな対応を実現します。
この項では、国内外で利用されているガイドラインを参考に、事前準備事項について紹介します。
各準備事項におけるよくある失敗例についても掲載しています。
1 ポリシーの整備
ポリシー（Policy）は、組織におけるセキュリティ・ガバナンス、運用等に関する原則・ルールを規定するものです。
ポリシーは、セキュリティに関する役割分担や権限、責任分界点が明確化されている必要があります。
また、技術的な要件（ログの取得、モニタリング、システム要件）や手続き等を含めて、ポリシーに沿った運用が行われているかを適切な方法で常に点検しなければいけません。
|
よくある失敗例：
|
2 CSIRTと組織化
CSIRT
CSIRTはインシデント対応体制を統括する組織です。CSIRTの形態は、その組織や企業の構造によって様々ですが、デジタル化の進んだ現在は、セキュリティ・インシデントに対し組織全体で取り組むために、このようなチーム編成が重要となります。
CSIRTの役割はインシデント対応に留まらず、平時の情報収集やセキュリティ対策向上施策等も実施しているケースが一般的です。
多くの組織・企業が、組織の名を冠したCSIRT的なチームを立ち上げ、窓口として機能させるとともに、協議会やFIRSTといったCSIRTコミュニティでの情報共有に取り組んでいます。
CSIRTは組織を統括するチームですから、法務、人事、広報、IT等必要な部門が漏れなく代表者を選出している必要があります。
なお、製品に係るセキュリティ・インシデントを対象とするPSIRTも存在します。
|
よくある失敗例：
|
コミュニケーションの確立
セキュリティ・インシデント発生時は、組織内・組織外・ステークホルダー・顧客との迅速・適切なコミュニケーションが事態収束のカギとなります。
サイバー攻撃や、不正アクセス被害、ランサムウェアによるシステム障害が発生した場合、初動対応の際の多数の連絡通報が発生します。
このようなコミュニケーションに際し、然るべき部署が最も効果のある発信を行うために、あらかじめ連絡先・通報先を含めた計画を定めておくことを推奨します。
その際、法執行機関やセキュリティ当局、個人情報当局に対する連絡タイミングについても確認します。
|
よくある失敗例：
|
3 対応計画
セキュリティ・インシデント対応の根幹となる対応計画は、事前に準備しておく必要があります。
インシデントの態様は、シチュエーションによって様々です。
インシデントの定義ごとに対応パターンを作成
一般的には、大まかなセキュリティ・インシデントの種別（マルウェア感染、ランサムウェア感染、情報漏洩）と、組織へのインパクト（一部業務停止、国内事業に影響、グローバル事業に影響等）に応じた分類を作成し、各パターンごとの行動を定めておくことが推奨されています。
対応計画の策定にあたっては、経営層と、インシデント対応の中核となるCSIRTとの意思統一が図られており、対応中も円滑にコミュニケーション（報告、指示等）がとれるよう配慮することが重要です。
実際に重大インシデントが発生した場合、そのセキュリティ・インシデントがどの程度のインパクトを持つのか判断に迷う場合があります。重大度のレベルに応じて、責任者が部門責任者なのか、現地法人なのか、グローバル本部なのか等、態勢が変化します。
精確かつ迅速にセキュリティ・インシデントのレベルを判断する（インシデント・トリアージ）にあたって、CISが公開するCIS Controls（外部リンク）では以下の情報を判断材料として用いることを例示しています。
- 法令・規則
- 開示規則
- パートナーや顧客とのSLA
- 利益・事業への影響
支援リストとコミュニケーション計画
前項「CSIRTと組織化」で挙げたように、セキュリティ・インシデント発生時の連絡先も計画に含め、定期的に見直し・更新を行います。
インシデント・レスポンスに必要なあらゆる専門技術（フォレンジック等）を自組織で賄うということは稀ですので、事態発生時の支援ベンダーや調査会社等も支援リストに含めておきます。
4 ツールの準備
近年増大しているランサムウェア被害でよく聞かれるのが、いざ対応しようと思ったもののすべてのPCが暗号化されてしまい作業ができないという事象です。
インシデント対応には、計画を実現するためのツールが必要です。
非常に範囲が広いため全ては挙げませんが、ガイドライン等では必要なツールとして以下を挙げています。
※ 組織がどの程度セキュリティ業務を内製しているかによって、必要なセキュリティツールは変わります。
- オフラインPC
- 筆記用具・ホワイトボード
- 記録用フォーマット
- 連絡先リスト
- セキュリティ・インシデント対応チェックリスト
- 必要なツールを格納した記憶媒体（メディア）
- フォレンジック用ノートPC
- 各種セキュリティツール
5 訓練
インシデント対応において、訓練は「さらなる向上策」ではなく、「事前準備」に含まれます。
対応計画は、訓練を行わなければ実効力のあるものとなりません。訓練なしに、チームは機能しません。
組織は、定期的にシナリオベースの訓練を行い、要領どおりに行動できているか、要領に不備はないか等を点検します。
訓練においては、現実味のあるシナリオを策定することが望ましいでしょう。
訓練の意味：
- リーダーやCSIRTの各メンバーが自身の役割を理解する
- セキュリティ・インシデント発生時の行動に習熟する
- インシデント対応計画や手順・手続きの問題点や不備を特定する
- 想定していなかった課題を発見する
|
よくある失敗例：
|
ここまでで、インシデント対応に必要な組織体制と事前準備が完了しました。
次章では、実際にセキュリティ・インシデントが発生した場合の対応フローを紹介します。
インシデント対応フロー
セキュリティ・インシデント対応フローを全体図で示すと次のようなものとなります。
インシデント対応フロー ※ SANS Incident Response Planを元に当社作成
ここでは、SANSが公開しているガイドライン（外部リンク）を参考に、具体的なフェーズごとの概要を紹介します。
①検知・特定
様々なログやアラートを分析し、インシデントかどうかを判断するフェーズです。
セキュリティ・インシデントの前触れとなるイベントは様々であり、このような兆候を、誤検知や過検知に惑わされずに的確に察知することがセキュリティ部門の重要な職務です。
セキュリティ・インシデントの兆候：
- 不審なログ、アラート
- 従業員や顧客からの通報（不審メール、不審な電話、システムの不具合等）
- 警察等外部機関からの通報
- ダークウェブ上での言及や情報漏洩
攻撃者がターゲットを定めてから、実際に攻撃活動を開始するまでの潜伏期間は様々です。
最近のランサムウェアのように、侵入後素早く攻撃を行う攻撃者もいれば、情報窃取を目的とするAPTのように、長期間対象ネットワーク内に潜伏したり、ソフトウェア・サプライチェーンを狙う等して長期にわたり持続性を確立する脅威アクターもいます。
いずれにせよ、侵害発生から検知までの潜伏期間が長引けば長引くほど、被害影響は増大します。
速やかな検知と特定が、初動対応のカギとなります。
|
よくある失敗例：
|
活動例
- セキュリティ・インシデントの特定
- インシデント・レベル（重大度）や影響範囲の判断
- 対応優先順位の決定
- CSIRTチームによる対応の開始
- 対応記録の作成
- IoCの収集・照合
②封じ込め
このフェーズでは、セキュリティ・インシデントによって発生した影響を最小限に抑え、さらなる被害を防止します。
影響を局限するだけでなく、後の根絶や復旧フェーズに備えるために、攻撃の証拠を保全しておくことが重要です。手順を踏まずに侵害システムを消去したり、システムを初期化した場合、攻撃の全貌を解明する手掛かりが失われてしまいます。
活動例
- 短期的封じ込め
- 侵害されたシステムやネットワークの分離
- 感染ホストのシャットダウン
- システムバックアップ
- 侵害されたシステム等をワイプ・消去する前に、フォレンジック・イメージを取得する
- 実施事項や発生事象の記録
- 長期的封じ込め
|
よくある失敗例：
|
③根絶
侵害されたシステムやネットワークにおける駆除活動を行うフェーズです。フェーズ②封じ込めと併せて実行されることもあります。
適切な手順を踏むことで、攻撃者の潜伏や、インシデント対応活動自体のかく乱を防止することが重要です。
サイバー攻撃を阻止するための防護策の改善もこのフェーズで行われます。
活動例
|
よくある失敗例：
|
④復旧
復旧フェーズにおいては、侵害を受けたシステムを通常の体制に復帰させます。
インシデントがもたらした被害や影響を特定し、全貌を解明することは、インシデント・レスポンスにおける重要目的です。
攻撃者の痕跡を調査し、明らかにしなければ、侵害されたシステムやネットワークを復旧することができません。
また、この過程で行われる調査・分析は、その後の教訓収集フェーズにとっても重要となります。
活動例
- 復旧計画策定
- 運用再開日時の決定
- テスト・検証方法策定
- モニタリング期間
- 必要ツール選定
- 復旧作業
- 安全確認のためのテスト、モニタリング、検証
|
よくある失敗例：
|
⑤教訓収集
セキュリティ・インシデント対応を振り返り、組織のセキュリティ向上を行うフェーズです。
SANSガイドラインでは、インシデント対応における最重要フェーズとされています。
「何がおこったのか？ どうすれば発生を防げたのか？」を明らかにし、体制の改善・強化につなげることは、インシデントの再発防止にもっとも効果のある活動です。
インシデント対応の総括として、一連の発生事象や対応を文書化することが非常に有効です。
ドキュメントとしてまとめることにより、インシデントから得られた教訓を活用することができ、また当局や外部への報告といった業務にも利用することができます。
組織はセキュリティ・インシデント全体の振り返り（デブリーフィング）を、2週間以内に実施することが望ましいとされます。
活動例
- 文書化
- インシデント全体のデブリーフィング
- 検知の経緯
- インシデントの範囲
- 封じ込めと根絶の詳細
- 復旧作業の詳細
- CSIRTチームが達成できた事項
- 改善を要する事項
|
よくある失敗例：
|
対応力をさらに向上させるポイント
インシデント対応は、体制確立と計画策定で終わりではありません。実際のインシデント対応を通じた改善点の発見等、サイクルとして常に運用していくプロセスが必要です。
ここでは、CISのガイドラインを参考に、組織の対応能力をさらに向上させるための方策として、脅威インテリジェンスと脅威ハンティングを紹介します。
脅威インテリジェンスおよび脅威ハンティングを活用することで、組織は受け身（リアクティブ）ではなくプロアクティブにセキュリティ対策をとることができます。
脅威インテリジェンスとは
脅威インテリジェンスとは、攻撃者や脅威に関する情報を先行的に収集し、インテリジェンスサイクルを通じて処理することで、組織の対策に役立てるプロセスです。
図 FBI資料を参考に当社作成
脅威、すなわちサイバー攻撃に関するインテリジェンスを基盤とすることで、組織にとって真に必要なセキュリティ対策を定め、防護すべき重要領域に的を絞った投資をするといった判断が可能となります。
脅威インテリジェンスプラットフォームは、当社のCognyteを含め様々な製品・サービスが展開されています。
しかし、この概念は元々組織の情報処理・活用プロセスを指すものであり、インテリジェンスを活かす組織的基盤が整備されていることが前提となります。
脅威ハンティングとは
脅威ハンティングは、脅威情報や攻撃者のTTP、IoCといった情報を活かし、組織のシステムやネットワークに潜伏している攻撃の兆候を予防的に探索し検知するプロセスです。
セキュリティシステムを回避しつつ高度な手法を用いて行動するサイバー攻撃者の動きをつかむために、脅威情報やログ、データを活用します。
脅威ハンティングの実践においては、EDR等のツールや、マネージドサービスによる提供も行われています。
さいごに
組織がインシデント対応（レスポンス）のための体制を確立し、サイバー攻撃に備えることは必須の課題です。
インシデント対応フローの主要フェーズである「特定→封じ込め→根絶→復旧→教訓収集」は、組織によってはMSSに委託しているケースもありますが、組織体制の整備や、外部との対応、セキュリティ・インシデントを通じた教訓の活用といった部分は、組織自ら取り組まなければならない部分です。
ビジネスや事業を推進するために、サイバー攻撃に備え、レジリエンスのある組織を作りましょう。
参考サイト
- https://www.cisecurity.org/controls
- https://www.sans.org/white-papers/33901/
- https://www.meti.go.jp/policy/netsecurity/mng_guide.html
- https://www.ncsc.gov.uk/collection/board-toolkit/planning-your-response-to-cyber-incidents
- https://www.ncsc.gov.uk/collection/incident-management/cyber-incident-response-processes/developing-your-plan
記事に関するご意見・お問い合わせはこちらへお寄せください。
(ＳＯＭＰＯホールディングス、損害保険ジャパンなどグループ各社へのお問い合わせはご遠慮下さい)
上級研究員
・自衛官時代に言われた一言「レーダー整備にそんな筋肉はいらない」
