サイバーインシデント対応ガイド：ベストプラクティス、ツール、戦略

インシデント対応（IR）とは？

インシデント対応とは、サイバー攻撃を受けた際に企業が組織的かつ戦略的に行う対処です。ユーザーと資産を守り、被害や脆弱性を最小限に抑え、将来の侵害を防ぐことを目的とします。セキュリティ担当者は、インシデント対応を通じてセキュリティインシデントを管理し、新たな脅威に迅速に対処します。侵害が発生した場合に、組織をできるだけ早く支えることが目標です。

インシデント対応の目的

インシデント対応は、サイバー攻撃の影響を迅速に最小化し、セキュリティ侵害を防ぐことを目指します。インシデントから得たインサイトやインテリジェンスを、今後のサイバーセキュリティ対策の改善に活用します。事業継続の確保、進行中の脅威の検知と封じ込め、インシデント後のプロセスとしての振り返りも目的です。

インシデント対応とインシデント管理の違い

インシデント対応とインシデント管理の主な違いは次のとおりです。インシデント対応計画は、重大な事象からの事業復旧時間を大幅に短縮します。サイバー脅威はかつてないほど深刻化しており、複雑に絡み合った技術とセキュリティリスクに対処する必要があります。効果的なインシデント対応計画の重要性を示す主な要因を以下に示します。

リスク管理
• インシデント対応では、インシデントの特定に重点を置き、SIEMなどのツールでアラートを生成・送信します。状況を担当者やSOCチームに通知し、脅威に迅速に対処します。
• インシデント管理では、必要に応じて第三者に支援を要請します。インシデント解決後のフォローアップや、今後のインシデント管理戦略の評価も行います。
• インシデント対応では、ネットワークから感染を除去します。バックアップからデータを復元し、事業継続も確保します。

今、インシデント対応が重要な理由

インシデント対応により、組織は潜在的なサイバー脅威の影響を迅速に評価し、必要な是正措置を講じられます。インシデントの根本原因を特定し、同様の事態の再発を防げます。

インシデント対応はユーザーの意識を高め、データの不正使用や損失を防ぎます。組織のコンプライアンスとサイバーセキュリティ態勢を強化し、事業継続にもつながります。組織が信頼に値し、預かったデータを安全に守っていることを顧客に示せます。

さらに、チーム全員が従うべき指針と手順を定めます。これにより、サイバーセキュリティインシデントの影響を軽減して対処し、脅威に迅速に対応できます。侵害時も速やかに復旧し、通常のセキュリティ運用に戻せます。

攻撃は年々高度化しています。組織は、高度な持続的脅威（APT）、ゼロデイ脆弱性、RaaS（サービスとしてのランサムウェア）、従来のセキュリティツールをすり抜けるAIを活用した攻撃に直面しています。攻撃者は今や、サプライヤーや第三者を狙ってネットワークに侵入します。強固なインシデント対応計画では、脅威を監視し、攻撃パターンを追跡し、対応計画を更新します。新たな攻撃が大きな被害をもたらす前に阻止します。

200日以内に特定・封じ込めた侵害は、対応にそれ以上かかった侵害と比べて解決費用が23%低くなります。2025年のデータ侵害の平均コストは$4.44 millionです。IBMの調査によると、侵害が未解決のまま続くと、組織には1時間あたり約$800の費用が発生します。重大度の高いインシデントでは、この費用が大幅に増加します。プロアクティブな検知機能を備えた組織は、平均検知時間（MTTD）を平均44%短縮できます。

組織内の優れたIRチームは、業界標準の30分超に対し、5分未満で検知できます。また、重大なインシデント1件あたりの平均対応時間（MTTR）をわずか5.5時間短縮するだけで、一般的なインシデントでは年間$352,000の侵害コストを回避できます。

GDPR、HIPAA、SOC 2などの規制や基準でも、組織はインシデントを検知・記録し、影響を受けた関係者に速やかに通知する必要があります。コンプライアンスにとどまらず、顧客やステークホルダーもインシデント発生時の透明性を求めています。確かなインシデント対応計画は評判を守り、顧客の信頼を築き、セキュリティを重視していることを規制当局に示します。対応の不備やコンプライアンス違反は、多額の罰金、法的問題、長期にわたる評判の低下につながりかねません。

NISTのインシデント対応ライフサイクル

データ侵害と漏洩： データ侵害および漏洩は、機密保持または保護されるべき機微な情報が、不正な第三者によって容易にアクセスされ、開示され、または盗まれる場合に発生します。データ漏洩は、脆弱なセキュリティ対策に起因して、意図的または偶発的な性質を持つ可能性があります。その一般的な原因は、内部者脅威、不十分なセキュリティ慣行、設定ミス、およびマルウェア、ブルートフォース攻撃、フィッシングなどのサイバー攻撃です。これらはまた、ユーザープライバシー法の違反につながり、システム内の隠れた脆弱性を悪用する可能性があります。データ侵害で入手された情報は、ダークウェブで販売されたり悪用されたりする可能性があります。

内部者脅威攻撃: 組織内の契約社員、従業員、信頼された個人が権限を悪用することで発生します。通常、これは企業の内部規則に対するポリシー違反であり、意図的か否かを問わずコンプライアンス法が破られます。インサイダー脅威の一般的な原因には、不満を抱えた従業員、ヘイトクライム、過失、従業員のサイバーセキュリティ訓練不足による無知や不注意なミスが含まれます。内部脅威はデータ窃盗、詐欺、知的財産権侵害を引き起こし、外部者がセキュリティ対策を迂回することを可能にします。一部の内部関係者は組織内部からデータを漏洩させ、外部関係者が機密情報にアクセスするのを支援し、結果として評判の毀損や信頼の喪失を招く可能性があります。

物理的セキュリティ侵害：これはセキュリティインシデントとしては比較的稀な形態です。許可されていない個人が物理的セキュリティ対策を操作し、施設へのアクセスを得て機密データを掌握するケースを指します。主な原因として、尾行侵入（テールゲティング）、USBやノートPCなどのデバイス盗難、サーバールームやデータセンターへの不正アクセスが挙げられます。これには必要な許可を得ずにオフィスに侵入したり、施設に不法侵入したりする行為も含まれます。

ゼロデイ攻撃： ゼロデイ は、更新プログラム、パッチ、修正プログラムが存在しない未知のソフトウェア脆弱性です。これらは、まだ一般に公開されていない、または開発者によって発見されていないセキュリティ上の隙間です。組織はこれらに対する防御手段を持ちません。ゼロデイ攻撃の最も一般的な原因は、脆弱性管理の不備、政府支援による他国を標的としたサイバー諜報活動、ベンダーが発見または認識する前にセキュリティ上の欠陥を発見する攻撃者です。

 

クリプトジャッキング: これは、アカウント所有者の同意なしに暗号通貨のマイニングのために計算能力を搾取するため、システムに悪意のあるスクリプトを密かにインストールする行為です。システムを遅延させ、パフォーマンスを低下させ、電力消費を増加させる目的で使用されます。クリプトジャッキングの主な原因には、クリプトジャッキングのペイロードを配信するフィッシングメール、広告やウェブページへの悪意のあるJavaScriptの埋め込み、クラウドサービスやウェブサイトに見つかった脆弱性の悪用などがあります。

マルウェアとランサムウェア：マルウェア およびランサムウェアは、システムに感染し、損傷を与え、不正アクセスを引き起こす可能性があります。データ操作、虚偽情報の拡散、データの複製を行い、攻撃者が他の機密情報を盗むのを助ける可能性があります。ランサムウェアはデータを暗号化し、ユーザーをシステムから締め出すマルウェアの一種です。組織はデータを復号化するために多額の支払いを迫られます。ランサムウェア攻撃は、最も効果的な金銭的恐喝の手法の一つとして知られています。

NISTのインシデント対応ライフサイクルの主なフェーズは次のとおりです。

準備

このフェーズでは、まずインシデント管理計画を策定します。この計画を使って、組織の環境内でインシデントを検知します。準備フェーズでは、さまざまなサイバー攻撃を特定し、その影響を把握します。また、セキュリティインシデントへの対応、進行の阻止、発生の予防に必要なツールを確保します。

検知と分析

次のフェーズでは、データを収集・分析して手がかりを見つけ、新たな攻撃元を特定します。攻撃の性質とシステムへの影響を把握します。セキュリティ担当者と連携し、ツールを使って侵害の痕跡（IOC）を特定するとともに、影響を受けたシステムを追跡します。

封じ込め

封じ込めフェーズでは、さまざまな手法でマルウェアやウイルスの拡散を防ぎ、ランサムウェアを阻止します。システムをネットワークから切り離す、デバイスを隔離する、不審なトラフィックや悪意のあるIPアドレスをブロックするなどの措置を講じます。

根絶

脅威インテリジェンスツールは、組織がデータを収集し、ログを分析し、情報に基づいたビジネス判断を下すことを可能にします。ブランドを評判リスクから保護し、多様かつ複数のソースからのデータを分析します。脅威インテリジェンスプラットフォームはAPIとして容易に統合でき、あらゆる規模の企業に最適です。詳細についてはSingularity Threat Intelligenceをご覧ください。

SIEMプラットフォーム—SIEMプラットフォームは、自動化されたインシデント対応、データ分析、ログ管理を通じて包括的なビジネスセキュリティを提供します。クラウドアプリケーション、ユーザー、ネットワークなどに対する保護を実現します。自律型SOC向けのAI搭載SIEMソリューションは、ハイパーオートメーションによるワークフローの加速と大幅なコスト削減を実現します。企業全体での脅威ハンティングを可能にし、検知と調査の可視性を高めます。

ここでは脅威の根本原因を特定します。悪意のあるコードを隔離し、感染したデバイスを切り離した後、環境から脅威を除去します。最新のウイルス対策ソフトウェアや手動での脅威除去手法を使用する場合もあります。ソフトウェアを最新の状態に保ち、パッチを適用して将来のセキュリティインシデントを防ぎます。。

復旧

事業運用を速やかに再開します。復旧フェーズでは、システムを本番環境に戻します。信頼できるバックアップから以前の状態に復元します。その後、バックアップをテストし、システムを強化します。

得られた教訓

このフェーズでは、過去または現在のデータ侵害に関するすべての文書を分析します。実際のインシデントと模擬演習の両方から得た教訓を振り返り、対策の抜け穴を見つけます。その結果を活かしてサイバー防御を強化し、将来の攻撃を防ぎます。

IRチームの役割、責任、体制

ディスカッションベースのテストと机上演習 –インシデント対応チームは様々な危機シナリオを順を追って体験します。重大なセキュリティイベント発生時に生じる複数の問題に直面し、それに対する対応を観察します。また、インシデント対応スキルとプロセスに関する知識もテストされます。

主要指標の分析 ―御社は、検出までの平均時間（MTTD）、対応までの平均時間（MTTR）、封じ込めまでの平均時間（MTTC）、解決までの平均時間（MTTR）といった主要なKPIに焦点を当てます。また、コンプライアンスコスト、エスカレーションやインシデントの頻度、セキュリティインシデントからの復旧コストも評価します。

インシデント対応チームは、サイバー攻撃から迅速かつ効果的に立ち直るための専門チームです。ダウンタイムを短縮し、サービス停止を防ぎ、根本原因に対処して問題の再発を防ぎます。

IRチームの一般的な役割と責任を見ていきましょう。理想的なチーム体制も紹介します。

インシデント対応マネージャー（IRマネージャー）

専門知識の不足—スキルギャップは広く見られ、多くの企業は新たな脅威に対抗する適切な人材を擁していません。予算、知識、リソースが不足している組織もある。

連携ツールの欠如 — 組織には、チームとしてインシデントの優先順位付けと修復を行うためのツールが不足している。

IRチームの責任者です。検知から解決まで、対応全体を管理・監督します。また、経営幹部とインシデント対応チームの連絡窓口も務めます。

セキュリティアナリスト

IRチームのセキュリティアナリストは、セキュリティインシデントを検知・分析し、対応します。脆弱性と脅威を監視し、アラートをトリアージしてインシデントの重大度と影響を評価します。インシデント記録の作成と更新も担当します。

フォレンジックアナリスト

フォレンジックアナリストは、法廷で使用するデジタル証拠を収集・保全・提示します。調査における法的要件やコンプライアンス要件への対応を支援します。詳細なフォレンジックレポートを作成し、証拠保管の連続性を維持するとともに、法的手続きで法執行機関や法務チームを支援します。

脅威ハンター

中立的な支援を受け、法的立場やコンプライアンス状況の全体像を把握できます。インシデントに迅速に対応したい場合、アウトソーシングサービスは巨額の資本投資を必要とせず、脅威インテリジェンスや専門ツールへの即時アクセスを提供します。

ISO 27001やNISTなどの基準への認証や加盟といった業界コンプライアンスの達成を支援し、高度なサイバーセキュリティ実践への取り組みを証明します。IRプロバイダーは24時間体制のサポートを提供し、即時サービス利用を可能にします。

応答時間の保証、業界経験、既存セキュリティインフラとの互換性が得られます。SentinelOneは優れた選択肢です。

脅威ハンターは、従来のセキュリティツールを回避する隠れた脅威や高度な持続的脅威（APT）をプロアクティブに探します。脅威インテリジェンス、振る舞い分析、仮説に基づく調査を活用し、被害が発生する前に悪意のある活動を特定します。ネットワークトラフィック、システムログ、エンドポイントデータを継続的に分析し、侵害の痕跡や新たな攻撃パターンを見つけます。インシデント対応サービス

広報担当者

広報担当者は、セキュリティインシデントの発生中および発生後の社内外への連絡を管理します。透明性を保ち、機密情報を守りながら、ステークホルダー、経営幹部、顧客、規制当局に向けて明確かつ正確なメッセージを作成します。PRチーム、法務顧問、経営幹部と連携し、一貫したインシデント情報の開示と評判の管理に取り組みます。

法務顧問

法務顧問は、規制への準拠、データ侵害の通知要件、セキュリティインシデントの法的影響について助言します。調査と是正措置において、IRチームがGDPR、HIPAA、業界固有の規制など、適用法令に従うよう確認します。また、賠償責任のリスクを評価し、法執行機関との連携を図り、インシデント対応に関する契約上の義務について助言します。

インシデント対応計画（IRP）に盛り込むべき内容

インシデント対応計画には、欠かせない基本要素があります。IR計画には次の項目を含めてください。

目標と使命

インシデント対応計画には、使命と具体的な目標を明記します。これらがインシデント対応戦略の中核となります。また、機密データの保護、被害の最小化、業務の復旧など、計画の目的も説明します。計画に記載するすべての目標について、関係者とチームメンバーの合意を得て、定期的に見直してください。

役割と責任

インシデント対応チームのメンバーは、自分の役割と責任を明確に理解している必要があります。特に役割の名称と割り当てに曖昧さを残してはいけません。外部のサイバーセキュリティ事業者や第三者の担当者を起用する組織もあります。その場合は、全員の氏名と担当する責任を記載してください。

サイバー脅威への備え（24時間365日の監視を提供するマネージド検知・対応サービス）、Singularity XDR（複数の攻撃対象領域にわたる拡張検知・対応を提供）、Singularity Threat Intelligenceは、AIと機械学習を活用したリアルタイムの脅威インサイトを提供します。

計画のこの項目では、潜在的なサイバー脅威に対する組織の準備状況を評価します。サイバーセキュリティ意識向上トレーニング、侵入検知、ランサムウェアやマルウェア、ソーシャルエンジニアリングなどへの対応方針といったIRPの要素を含めてください。テスト計画には模擬演習も盛り込み、継続的に更新して脅威に先手を打ちます。

被害軽減と封じ込めの戦略

インシデントを検知したら、まず環境内での脅威の拡散を阻止します。影響を受けたシステムを迅速に隔離し、攻撃者がネットワークの他の領域へ横展開するのを防ぐ明確な手順が必要です。侵害されたユーザーアカウントの無効化、悪意のあるコードの除去、不正なアクセスポイントの遮断を行います。チームが遅滞なく実行できるよう、隔離手順と封じ込めの手順を事前に定めてください。

連絡とエスカレーションのプレイブックSentinelOneをお試しください。

インシデント対応計画には、各段階で誰にどの連絡手段で通知するかを定める必要があります。経営層、ITチーム、関係部門が連絡のタイミングと方法を把握できるよう、社内のエスカレーション経路を明確にしてください。また、法律で義務付けられる場合に備え、顧客、規制当局、法執行機関への対外的な通知手順も必要です。事前に用意したテンプレートと承認済みの文面により、通知の一貫性、正確性、法令遵守を確保します。インシデント対応中の連絡頻度も定め、機密情報の保護には安全な連絡手段を使用してください。

インシデントの分類と優先順位付け

インシデントの重大性はそれぞれ異なります。深刻度と影響に応じて分類するための明確な枠組みを計画に定めてください。影響を受けるシステム、リスクにさらされるデータの量、業務への支障を基に、重大、高、中、低に分類できます。分類ごとに対応期限と具体的なエスカレーション手順を定めます。

迅速な復旧計画とインシデント後の振り返り

脅威を封じ込めたら、次は業務をできる限り迅速に復旧します。詳細な復旧手順を盛り込み、影響を受けたシステムをオンラインに戻す方法を明記してください。システムをテストして継続的な稼働とデータの整合性を確認し、失われたデータも復元します。今後のインシデントを防ぐため、継続的に改善を重ねます。

さらに、インシデント後の正式な振り返りプロセスを確立してください。チームは発生した事象を記録し、対応手順の不足を特定して、得られた教訓を組織全体で共有します。定期的な振り返りを通じて、インシデント対応能力を継続的に強化できます。

外部ベンダーの管理

多くの組織は、業務に不可欠な外部ベンダーやサービスプロバイダーに依存しています。インシデント対応計画には、対応に関与すべきベンダーと各社の責任を明記してください。エスカレーション手順と連絡手順を文書化し、ベンダー契約に通知要件を定めます。

ベンダーのシステムやデータアクセスに関わるインシデントの調査手順も含めてください。重要なベンダーを定期的にセキュリティ評価することで、適切なセキュリティ基準を維持し、インシデント対応を効果的に支援できる状態を確認します。

法的事項とコンプライアンス上の考慮事項

法的・規制上の事項は、管轄区域ごとに従うべき法律が異なるため、扱いが難しい場合があります。基本的には、機密データを保護し、顧客の信頼を守るために、HIPAA、CCPA、GDPRなどの主要な規制を遵守してください。

法的リスクへの対処、適時の報告、変化する規制要件への対応について組織に指針を示し、罰金や評判への損害を避けてください。インシデント報告とデータページに関する法的義務を果たすための明確な手順も必要です。

IRで使用するツールとテクノロジー

現在、IRでよく使用されるツールとテクノロジーは次のとおりです。

EDR/XDR

エンドポイント検知・対応（EDR）ツールは、ネットワーク内の個々のデバイスで起きていることを監視します。攻撃者がシステムに侵入すると、EDRはその行動を正確に把握するためのデータを記録します。拡張検知・対応（XDR）はさらに、エンドポイント、ネットワーク、クラウドシステムのデータをひとつのビューに統合します。これにより、セキュリティチームは攻撃の全容を把握し、より迅速に対応できます。EDR/XDRがなければ、被害が発生するまで、侵害されたマシンで何が起きているのかを把握できません。

SIEMとSOAR

SIEMはインフラ全体からログを収集し、不審なパターンを検出します。脅威が深刻化する前に見つけるには、この可視性が欠かせません。SOARはチームの対応ワークフローを自動化し、インシデントごとに同じ封じ込め手順を手動で繰り返す必要をなくします。脅威を検知すると、人の操作を待たずにシステムの隔離、アカウントの無効化、フォレンジックデータの収集を直ちに実行できます。

脅威インテリジェンス

誰が攻撃しているのか、どのように行動するのかを知れば、チームの対応が変わります。脅威インテリジェンスは、既知の攻撃者、その戦術、狙われている脆弱性に関する情報を提供します。インシデントの調査では、攻撃者の行動を既知の脅威アクターと照合できます。これにより、無差別な攻撃なのか、自社の業界を狙った標的型キャンペーンなのかを判断できます。脅威インテリジェンスは、セキュリティに関するインサイトを提供し、多様な情報源を調査します。何に対処しているのかを把握しなければ行動できないため、欠かせません。

ログ管理とフォレンジックツール

ログは証拠です。インシデントが発生した際、チームには侵害されたシステムで何が起きたかを示す詳細な記録が必要です。ログ管理ツールは記録を安全に保存し、調査時に参照できるようにします。フォレンジックツールを使えば、侵害されたデバイスからデータを抽出し、法的な検証に耐える形で保全できます。適切なログの保存とフォレンジック能力がなければ、分析する材料も、何が起きたかを示す証拠も残りません。

自動化とAI駆動のIR

新たに現れ、変化し続ける脅威に対応するには、セキュリティの自動化と迅速な対応が必要です。AIを活用したツールは膨大なデータを分析し、チームが手作業では発見に何時間もかかるパターンを見つけます。自動化により、システムの隔離やアカウントの無効化といった反復作業を、数分ではなく数秒で処理できます。

機械学習は、既知のシグネチャに一致しない攻撃など、チームが見逃しかねない異常を検知します。手動分析だけに頼る組織は、自動化とAIを活用する組織よりも対応が遅れます。

セキュリティインシデントの種類と必要な対応

把握しておくべきセキュリティインシデントの種類と、それぞれに必要な対応の概要を紹介します。

マルウェアとランサムウェア

マルウェアは気づかれないうちにシステムにインストールされ、攻撃者にリモートアクセスを与えます。ランサムウェアはファイルをロックし、解除と引き換えに支払いを要求します。どちらも未修正の脆弱性を悪用し、共有ドライブを介して横展開することでネットワーク全体に広がります。

多くのランサムウェアはファイルをゆっくり暗号化するため、監視していれば気づけます。パフォーマンスの低下、バックグラウンドで動く不審なプロセス、ファイル名の大量変更が兆候です。攻撃者はランサムウェアを展開する前に、バックアップシステムや価値の高い標的を探して、数週間にわたりネットワークを調査することがよくあります。攻撃グループによっては、まずデータを盗み、その後に暗号化します。バックアップがあっても、情報は危険にさらされます。マルウェアは数か月間潜伏し、誰かが攻撃の次の段階を引き起こすまで、データや認証情報を盗み続けることがあります。

対応指針： 感染したシステムを直ちにネットワークから切り離します。感染が始まった時期と変更されたファイルを確認します。マルウェアが除去されたことを確認してから、感染していないバックアップで復元してください。

フィッシングとビジネスメール詐欺（BEC）

フィッシングメールは正規のメールに見えますが、危険なリンクをクリックさせたり、ファイルをダウンロードさせたりするために作られています。ビジネスメール詐欺では、攻撃者がCEOや信頼できるベンダーになりすまし、送金やログイン認証情報の共有を促します。

BEC攻撃は綿密な調査に基づいています。攻撃者は貴社の組織構造、最近の取引、メールのやり取りのパターンを調べます。新しい口座への緊急送金や従業員の税務書類の提出、偽のポータルでの支払い情報の「更新」を求めるメールが届くことがあります。攻撃者のメールアドレスは本物とほぼ同じに見えます。違いはたった1文字かもしれません。BEC攻撃の中には、まず実際のメールアカウントを侵害し、貴社のシステム内から連絡先にフィッシングメールを送るものもあります。こうした攻撃を見分けにくいほど、従業員がだまされる可能性は高まります。

対応指針： メールヘッダーを調べ、送信者アドレスの偽装や認証の失敗を確認します。不審な支払い要求や、見慣れない場所からのアカウントアクセスを調査します。侵害されたメールボックスの転送ルールと送信済みアイテムを確認してください。

データ侵害

データ侵害とは、第三者がデータに不正アクセスし、コピーした可能性がある状態です。対象には顧客記録、支払い情報、営業秘密、従業員データなどが含まれます。データが盗まれると取り戻せません。関係者に通知し、さらなる被害を抑えることが重要です。

データ侵害は、公開状態のデータベース、盗まれた認証情報、従業員を狙ったフィッシング攻撃、Webアプリケーションの脆弱性を通じて発生します。攻撃者は発見されるまで数か月間システム内に潜伏し、アラートを発生させないよう少しずつデータにアクセスすることがよくあります。盗んだデータをダークウェブで1件あたりわずか数セントで売る攻撃者もいます。詐欺、なりすまし、企業スパイ活動に利用する攻撃者もいます。侵害の発見が遅れるほど、流出するデータは増えます。セキュリティ研究者が貴社のデータの売買を発見するか、法執行機関から連絡を受けるまで、侵害に気づかないこともあります。

対応指針： アクセスされたデータの種類と影響を受けた人数を特定します。アクセスログを確認し、侵害が始まった時期を調べます。該当する州法が定める期限内に顧客と規制当局へ通知してください。

内部脅威

内部脅威とは、正当なアクセス権を持つ人物が、故意または過失によってその権限を不適切に使うことです。従業員が競合他社への転職前に営業秘密をダウンロードする、請負業者がコードにバックドアを残す、ソーシャルエンジニアリングを使った電話にだまされてデータベースのパスワードを渡す、といった例があります。

内部脅威は、気づきにくいものです。当事者がすでにアクセス権を持っているためです。不満を抱く従業員が、数週間かけて機密ファイルを少しずつコピーするかもしれません。不注意な開発者が、GitHubにプッシュするコードに認証情報をハードコードすることもあります。攻撃者は従業員のアカウントを1つ侵害し、それを使って本当の標的である顧客データベースやソースコードにアクセスする可能性があります。アクセス権を持つ人物による行動のため、内部からは正常に見えます。異常なデータ転送や監査ログの削除に気づいたときには、すでに被害が出ているかもしれません。ログを消去して痕跡を消す内部関係者もいるため、何が起きたのか追跡しにくくなります。

対応指針： 通常の業務範囲を超える大量のファイルアクセスに注意します。USBドライブやクラウドストレージへのデータのダウンロードを監視します。従業員アカウントの通常と異なる時間帯や場所からのログインを確認してください。

クラウドセキュリティインシデント

クラウドでのインシデントには、ストレージバケットの設定ミスによるデータ漏洩、ユーザー認証情報の侵害、脆弱なアクセス制御の悪用などがあります。クラウドリソースが侵害されても、クラウドプロバイダーから必ずしも通知されるとは限らず、すぐには気付けない場合があります。

攻撃者は、アクセス権限が公開されたS3バケット、Azure Blob Storage、Google Cloud Storageを探します。初期設定のパスワードが有効なままのデータベースも見つけます。GitHubに漏洩したクラウドのアクセスキーを、気づく前に攻撃者が悪用することもあります。IDとアクセスに関するポリシーの設定ミスがあれば、侵害されたアカウントひとつで環境全体にアクセスされるおそれがあります。攻撃者はこれを悪用して横方向に移動し、重要な資産を探し出して盗みます。クラウドでのインシデントが危険なのは、攻撃者が自社のインフラ内で活動するためです。セキュリティツールがその活動を記録しても、ログはクラウド上にあり、攻撃者に削除される可能性があります。

対応の指針： クラウドストレージバケットの権限を確認し、パブリックアクセスを無効にします。IDとアクセスに関するポリシーを見直し、過剰な権限がないか確認します。クラウドログで予期しないAPI呼び出しやデータのエクスポートを調べます。

クラウドとSaaSのインシデント対応

クラウドとSaaS環境におけるIRについて、知っておくべきことをご紹介します：

クラウドにおけるIRの課題

クラウドでのインシデントは、オンプレミスへの攻撃より速く進行します。ログの異常なアクティビティに気付いた頃には、攻撃者がすでにデータをコピーし、証拠を削除している可能性があります。基盤となるインフラを管理するのはセキュリティチームではなくクラウドプロバイダーです。そのため、プロバイダーのログシステムと調査への協力に頼ることになります。

クラウドの動的な性質により、根本原因の分析も難しくなります。インスタンスは絶えず起動と終了を繰り返します。攻撃に気付いたときには、侵害されたインスタンスがすでに存在せず、証拠も残っていない可能性があります。

マルチクラウド環境では、問題はさらに複雑になります。AWSを侵害した攻撃者がAzure環境にもアクセスしている場合、AWSから排除するだけではAzureへのアクセスは失われません。環境ごとに排除する必要があります。ログシステム、API、インシデント対応手順が異なる複数のプロバイダー間で、対応を調整しなければなりません。

マルチクラウドとSaaS環境のIR

Cloud Security Posture Management（CSPM）は、マルチクラウドのリソース全体を可視化します。CSPMはAWS、Azure、Google Cloudを継続的にスキャンして設定ミスや脆弱性を検出し、その結果を相関分析のためにSIEMへエクスポートします。マルチクラウドとSaaS環境では、変化し続ける動的なエコシステムに対応するため、従来とは異なるIRが必要です。こうした機能がその対応に役立ちます。

責任共有モデルがIRに与える影響

クラウドプロバイダーがハイパーバイザーのレベルで異常なアクティビティを検出しても、自社のセキュリティ対策が明らかになることを避けるため、すぐには通知しない場合があります。調査に不可欠な情報を待たなければなりません。コンプライアンス法で義務付けられた情報は共有されますが、インシデント対応の速度は落ちます。

SaaS環境では、SaaSベンダーがアプリケーション、データベース、基盤となるインフラを管理します。ユーザーアクセス、権限、連携を管理するのは自社です。攻撃者がSaaSの脆弱性を悪用した場合、誰が修正の責任を負うかを見極めるまで、復旧が遅れます。ベンダーがセキュリティアップデートを適用しなかったのでしょうか。自社が過剰な権限を付与していたのでしょうか。それとも、サードパーティとの連携が原因でしょうか。

責任共有モデルの下では、クラウドプロバイダーがすべてのセキュリティを担うと考えてはいけません。プロバイダーのインシデント対応に関するSLAと、インシデント発生時に受けられるサポートを把握する必要があります。提供されるのは生ログですか、それとも概要だけですか。回答までにどれくらいかかりますか。自社のために、どのデータにアクセスできますか。こうした詳細が調査期間を左右します。

責任共有モデルを理解すると、自社だけではできないことも明確になります。クラウドプロバイダーのインフラにはパッチを適用できません。プロバイダーの生の監査ログには、リクエストせずにアクセスできません。ハイパーバイザーのセキュリティも管理できません。インシデント対応計画にはこうした制約を織り込み、発生前にクラウドプロバイダーへのエスカレーション経路を確立する必要があります。

クラウドにおけるログと証拠の取り扱い

クラウドでのインシデントでは、ログが唯一の証拠の手がかりです。ログがなければ、何が起き、誰が実行し、どう阻止すべきかを特定できません。ただし、クラウドのログ取得はインシデント発生前に意図的に設定しておく必要があります。

ほとんどのクラウドプロバイダーでは、デフォルトのログ保持期間が限られています。AWS CloudTrailが管理イベントを保持する期間は90日です。攻撃者が3か月間目立った活動をしなければ、それ以前のログは失われます。長期保存には、AWSのObject Lockを使用したS3、イミュータブルポリシーを設定したAzure Blob Storage、保持ポリシーを設定したGoogle Cloud Storageなど、変更不可のストレージにログをアーカイブする設定が必要です。ログを変更不可にすれば、メインアカウントが侵害されても攻撃者は削除できません。

攻撃者に発見・削除される前に、証拠の収集とフォレンジックデータの保全を自動化することが重要です。

インシデントを検出したら、IRプレイブックでメモリダンプ、ディスクスナップショット、ネットワークフローデータ、実行中のプロセス一覧を自動収集します。クラウド環境ではシステムに物理的にアクセスできないため、これらの証拠をAPI経由で収集し、追記専用ストレージに保存する必要があります。自動化により収集漏れを防ぎ、証拠を直ちに保全します。

証拠の取り扱いには、保管・管理履歴の記録が必要です。クラウドログはデジタル証拠です。裁判で証拠として認められるよう、慎重に収集し、安全に保管しなければなりません。誰が、いつログにアクセスし、何を行い、ログをどこに保管したかを記録します。適切な保管・管理履歴がなければ、攻撃を証明する証拠でも採用されません。業界でログ保持に適用されるコンプライアンス要件も把握しておく必要があります。

インシデント対応に共通する課題

現在のインシデント対応で直面する、その他の一般的な課題をご紹介します：

データの可視性の欠如

最初の課題は可視性の欠如です。多くのクラウドサービスではログ取得がデフォルトで無効です。事前に有効化していなければ、何が起きたかの記録は残りません。攻撃者はこれを知っており、横方向に移動する前にログ取得を無効化します。基盤となるインフラはクラウドプロバイダーが管理しており、自社がアクセスできるのはプロバイダーが開示する情報だけです。オンプレミスなら数時間で済む対応も、プロバイダー側の調査が必要になると数日かかります。

コンテナは自動的にスケールし、ログをほとんど残さない一時的なリソースを数千個作成します。インフラが絶えず変化するため、攻撃の開始時点を追跡することはほぼ不可能になります。扱うデータの種類、取得元、量も明確に把握する必要があります。急速にスケールすると、気付かないうちにデータの可視性に欠落が生じ、大きな問題になります。

スキルを持つ人材の不足

クラウドセキュリティの専門人材の採用は容易ではありません。候補者を審査し、保有資格を確認する必要があります。熟練した人材の確保が難しいことは否定できません。需要が高い一方で、供給は限られています。

アラート疲れ

複数のツール、リソース、資産、ワークフロー、クラウド環境を扱うと、大量のアラートに埋もれがちです。アラート疲れは現実の問題であり、多くの誤検知がセキュリティ専門家の負担になります。攻撃者は注意をそらすために悪意あるコードを書いてシステムに注入するなど、あらゆる手段を使います。その間に、自ら仕掛けた真の脅威を見逃させようとします。

分散したハイブリッド環境

分散したハイブリッド環境のセキュリティ管理では、オンプレミスのデータセンター、プライベートクラウド、パブリッククラウドの各プラットフォームで、ポリシーと監視を同時に調整する必要があります。環境ごとにアクセス制御、暗号化基準、コンプライアンス要件が異なるため、複雑さはさらに増します。

インフラが複数のベンダーや導入形態にまたがると、セキュリティチームは可視性の維持と統一した基準の適用に苦慮します。その結果、攻撃者が悪用できる隙が生まれます。

IRを強化するためのベストプラクティス

IRを強化するための主なベストプラクティスをご紹介します：

IRの準備訓練と机上演習

IRの準備訓練と机上演習では、連絡の流れ、エスカレーション経路、意思決定プロセスの検証など、具体的な目標を設定します。部門横断で関係者を巻き込み、人とプロセスの両方に重点を置く必要があります。各演習の後には正式な振り返りを行い、内容を変えながら定期的に訓練を実施します。

ゼロトラストとIRの連携

ゼロトラストアーキテクチャを構築する際は、常に侵害を前提に考えます。厳格なアクセス制御を適用し、最小権限の原則を徹底して、IDとデバイスの検証を優先します。

反復的なIR手順の自動化

マイクロセグメンテーションの適用も推奨します。継続的な監視を徹底し、可視性を高めます。SOARプラットフォームを使用して反復的なIR手順を自動化します。データ収集、トリアージ、ログ分析も自動化します。最適なプロセスの導入には  段階的なアプローチを採用し、自動化と規模を徐々に拡大できます。

脅威インテリジェンスとプレイブックの統合

脅威インテリジェンスとプレイブックを強化するには、地域、業界、リスクプロファイルに最も適した情報源を選びます。内部データと外部フィードを組み合わせ、詳細なコンテキストを得ます。データ形式を標準化し、脅威インテリジェンスをセキュリティツールに組み込むこともできます。  MIを使用します

IRの成果を測る指標とKPI

IRの成果を効果的に測るために注目すべき、主なインシデント対応指標とKPIをご紹介します：

MTTD、MTTR、封じ込め時間

平均検知時間（MTTD）は、セキュリティインシデントの発生からチームが気付くまでの時間です。平均対応時間（MTTR）は、インシデントの検出からチームが阻止に向けて行動を起こすまでの時間を測ります。封じ込め時間は、インシデントを完全に隔離し、被害を抑えるまでの時間です。

この3つの指標は、対応速度を示すため重要です。脅威を素早く検知・封じ込めるほど、被害は小さくなります。MTTDが長い場合は、監視ツールに改善が必要かもしれません。MTTRが長い場合は、チームのリソースやトレーニングが不足している可能性があります。封じ込めに時間がかかる場合は、チーム間の連携に問題があることが少なくありません。

誤検知の削減

セキュリティツールは絶えずアラートを出します。その多くは実際の脅威ではなく、誤検知です。チームが誤ったアラートへの対応に時間を費やすと、実際のインシデントを見逃し、疲弊も早まります。

アラートのうち、ノイズではなく実際の脅威だったものの割合を追跡します。チームの対応力が高まれば、この割合も上がるはずです。監視ツールの設定調整、アラートルールの明確化、チームのトレーニングが誤検知の削減につながります。誤報への対応時間が減れば、実際のインシデントにより迅速に対応できます。

SLAの遵守

サービスレベル契約（SLAs）は、インシデントの種類ごとにチームが守るべき対応時間を定めます。重大な侵害には15分以内の対応が必要な場合があります。中リスクのインシデントなら2時間、低リスクの問題なら24時間の猶予があるかもしれません。

チームがこれらの目標を達成した割合を追跡します。SLAの遵守率が高ければ、IRプログラムの信頼性を関係者に示せます。SLAsを頻繁に守れない場合は、人員の増強、ツールの改善、優先順位の明確化が必要です。

社内IRと外部委託IR：選び方

独自のIRチームを構築する組織もあれば、インシデント対応を外部企業に委託する組織もあります。両方を活用する組織も少なくありません。適切な選択は、予算、直面する脅威、社内にあるスキルによって決まります。

外部委託を検討すべき場合

社内にセキュリティの専門知識がない場合や、専任のIR担当者を雇う費用を正当化できない場合は、外部委託を検討してください。マネージドセキュリティサービスプロバイダー（MSSP）やインシデント対応企業には、さまざまな攻撃への長年の対応経験があります。すでに構築・検証されたツールとプロセスも備えています。

インシデントの発生が時折で、IR担当者を常時配置する必要がない場合、外部委託は有効です。必要なときだけ費用を支払います。大半の時間に対応業務がない担当者を雇うより、コストを抑えられます。

侵害発生時に第三者による信頼性の裏付けが必要な場合も、外部企業が役立ちます。独立したフォレンジックチームによる調査は、法的な立場を強化し、専門的な調査を求める規制当局の期待にも応えられます。

社内IRと外部委託IRを比較し、それぞれの長所と短所を以下に示します。

SentinelOneによるインシデント対応の強化

SentinelOneは、AIを活用した自律型のSingularity™ Platformを提供し、エンドポイント、クラウドワークフロー、アイデンティティにわたる防御、検知、対応を統合します。脅威を即座に封じ込め、悪意あるネットワーク活動をブロックします。さらに、ワンクリックのロールバック機能で変更を修復・ロールバックします。

システムを攻撃前の安全な状態に復元し、ダウンタイムとデータ損失を最小限に抑えられます。SentinelOneのプラットフォームはStorylines™テクノロジーを使用し、複数の情報源に分散したデータとアラートを関連付けます。セキュリティアナリストは、攻撃の全容、根本原因、進行状況を迅速に把握できます。これにより、意思決定を迅速化し、複雑さを軽減するとともに、SentinelOneの統合コンソールでセキュリティ運用全体を管理・監視できます。SentinelOneのOffensive Security Engine™は、Verified Exploit Paths™を活用して攻撃を事前に予測し、攻撃者の視点から脅威を捉えることで、差し迫った脅威への迅速な対応を支えます。

さらに、Singularity™ Network Discoveryも利用できます。IP対応デバイスや管理対象外デバイスをすべて自動的に検出・識別し、ネットワーク上の配置を把握します。これにより、セキュリティ上のギャップを解消し、攻撃対象領域を縮小できます。 Purple AI  は世界で最も高度なサイバーセキュリティアナリストです。自然言語によるクエリを使って、脅威ハンティングとインシデント調査を行います。

SentinelOneの Singularity™ RemoteOps Forensics を使用すると、大規模な証拠収集を簡素化し、カスタムスクリプトを実行して、フォレンジック調査を迅速化できます。SentinelOneはMITRE ATT&CKフレームワークに対応し、最新の業界標準に基づいて攻撃者の戦術と技術を把握します。

脅威インテリジェンスには、 Singularity™ Threat Intelligence を提供しています。Mandiantを基盤とし、新たな脅威、攻撃者の動機、TTPsについて、精度の高いリアルタイムのコンテキストを提供します。一般的な脅威への対応に向け、カスタマイズ可能なプレイブックとインシデント対応の自動化を利用できます。悪意のあるIPのブロック、デバイスの隔離、侵害の痕跡の特定と阻止も自動化できます。

SentinelOneは強力なAPIを使用し、SOARプラットフォームなどのサードパーティ製セキュリティツールと連携できます。また、SentinelOneの AI-SIEM製品 はログ分析とアラートに使用できます。SentinelOneの エージェントレスのCNAPP製品 また、第一線の専門家によるインシデント対応に加え、CSPM、KSPM、CDR、EASM、コンプライアンス管理など、さまざまなセキュリティ機能も提供します。SentinelOneのPrompt Securityは、Google、OpenAI、Anthropicなどの主要なLLMプロバイダーを、モデルに依存せずカバーします。組織内でのシャドーAIの利用を防ぎ、許可されていないエージェンティックAIの動作を阻止し、LLMがユーザーに有害な回答を生成することを防ぎます。プロンプトインジェクション攻撃やウォレット枯渇攻撃、サービス拒否攻撃を防ぎ、AIツールやサービスのコンプライアンス対応も効率化します。

信頼できるMDR

SentinelOneのSingularity MDRで、信頼性の高いエンド・ツー・エンドのカバレッジと、より大きな安心を手に入れてください。

お問い合わせ

実際のIR事例・ケーススタディ

インシデント対応の実例とケーススタディをご紹介します。

Targetのデータ侵害（2013年）

ハッカーは取引先との接続を通じてTargetのシステムに侵入し、4,000万件のクレジットカード番号にアクセスしました。この侵害で、重大な欠落が明らかになりました。Targetには検知ツールがありましたが、明確なエスカレーション手順がなかったのです。対応の速さだけでなく、連携も重要です。Targetのチームは対応を開始すると、影響を受けたシステムを隔離し、顧客に通知しました。インシデント対応計画は存在しましたが、実行上の不備により、同社は和解金として1,850万ドルを支払うことになりました。

Equifaxの情報漏洩（2017年）

Equifaxは既知の脆弱性を数カ月間修正しませんでした。攻撃者はその脆弱性を悪用し、1億4,700万人の個人情報にアクセスしました。真の問題は攻撃そのものではなく、対応の遅れでした。Equifaxは侵害を数週間にわたって発見できませんでした。対応を開始した時点で、攻撃者はすでにデータをコピーしていました。十分なIR計画があれば、定期的な脆弱性スキャンと迅速な検知手順が含まれていたはずです。

Microsoft Exchange Serverへの攻撃（2021年）

Microsoft Exchangeで複数のゼロデイ脆弱性が発覚した際、IR手順のない組織は対応に追われました。一方、対応計画、担当者の役割、連絡経路を文書化していた組織は、数時間以内に対応しました。対応開始まで数日かかった企業では、攻撃者に永続的なバックドアを設置されました。

まとめ

サイバーセキュリティのインシデント対応計画は、将来の防御の基盤となり、あらゆる組織に欠かせません。セキュリティ責任者は、同様のインシデントが二度と起こらないと考えるべきではありません。インシデント対応戦略を磨き、継続的な改善とレジリエンスの強化を進めることが重要です。 SentinelOne のようなプラットフォームは、その取り組みに大いに役立ちます。