セキュリティ事故は、起きるかどうかではなく、起きた際にどう動くかが問われる時代になりました。しかし、不審なアクセスやランサムウェアの感染が判明した場面で、誰が何を判断し、どこまで止めるのかが決まっていない企業は少なくありません。
本記事では、インシデント対応とは何を指すのかという整理から、検知から封じ込め、復旧、事後対応までのフロー、ファイルとデータの側で取るべき初動、そして平時のうちに決めておくべき体制やルールまでを解説します。
本記事のサマリ
-
インシデント対応は、事故の検知から封じ込め、復旧、再発防止までを行う一連の活動である
-
対応フローは国内外の枠組みに沿い、検知と分析、封じ込め、根絶と復旧、事後対応の順で進む
-
ファイル側の初動は共有リンクの停止、操作ログでの影響範囲の特定、感染前の世代への復旧が軸になる
-
深刻度の判断基準や役割分担、報告ルートは、事故が起きる前に決めておく必要がある
-
一定の類型に当たる個人データの漏えいでは、個人情報保護委員会への速報と確報、本人への通知が期限つきで義務になる
目次- 1. インシデント対応とは何を指すのか
- 2. インシデント対応フローの各ステップ
- 3. ファイルとデータの側で取るべき初動
- 4. インシデントが起きる前に決めておくこと
- 5. DirectCloudで実現するインシデント対応
- 6. インシデント対応の課題を解決した事例
- 7. よくある質問
- 8. まとめ
インシデント対応とは何を指すのか
インシデント対応とは、情報の漏えいやウイルス感染、システムの停止といったセキュリティ上の事故が起きたときに、被害と影響範囲を最小限に抑え、迅速に復旧し、再発を防ぐ取り組みです。
情報セキュリティ対策の指針を公開する独立行政法人情報処理推進機構(IPA)は、その目的を企業の事業継続の確保と示しています。対象となる事象の範囲、インシデント管理や障害対応との位置づけの違い、侵入を前提とした対応が必要になった背景の3点が、社内の認識をそろえる出発点になります。
参照元:独立行政法人情報処理推進機構(IPA)|中小企業の情報セキュリティ対策ガイドライン 付録8:中小企業のためのセキュリティインシデント対応の手引き
インシデント対応が対象とする事象の範囲
外部からの攻撃だけがインシデントではありません。IPAの「中小企業のためのセキュリティインシデント対応の手引き」は、情報の漏えいや改ざん、破壊・消失、情報システムの機能停止と、それらにつながる可能性のある事象をインシデントとしています。
ウイルスやランサムウェアへの感染、サーバへの不正アクセス、従業員による内部犯行、電子メールの誤送信、業務用パソコンや記録媒体の紛失が代表例です。人的ミスも内部不正も含むため、何をインシデントとするかは自社で決めておく必要があります。
参照元:IPA|中小企業の情報セキュリティ対策ガイドライン 付録8:中小企業のためのセキュリティインシデント対応の手引き
インシデント管理・障害対応との違い
インシデント管理は事象の受付から学習までを回す枠組み、インシデント対応はその中で技術的に対処する工程、システム障害への対応はサービスを再び使える状態に戻す作業です。経済産業省とIPAの「サイバーセキュリティ経営ガイドライン Ver3.0」付録Dでは、緊急対応体制の整備に対応する国際規格ISO/IEC 27002の管理策として、計画と準備、事象の評価と決定、対応、学習、証拠の収集が並びます。
一方、システム障害への対応では、業務への影響を抑えるためにシステムの稼働継続や切り替えを優先します。用語の使い分けが社内でそろわないと、担当者がどちらの手順で動くか迷い、初動が遅れます。
参照元:経済産業省|サイバーセキュリティ経営ガイドラインと支援ツール/IPA|中小企業のためのセキュリティインシデント対応の手引き
侵入を前提とした対応が必要になった理由
攻撃を入り口で防ぎきる前提は成り立ちません。警察庁サイバー警察局の「令和7年におけるサイバー空間をめぐる脅威の情勢等について」は、日々巧妙になるサイバー攻撃を完全に防ぐことは困難だとしています。
検知したあとの動き方が、被害の大きさを左右します。同資料のアンケートでは、被害に遭った企業・団体のうち、復旧に総額1,000万円以上を要した組織が5割を超え、サイバー攻撃を想定した業務継続計画(BCP)を策定済みの組織は約18%にとどまりました。侵入されたあとの手順を先に用意しておくことが、損失を抑える備えになります。
インシデント対応フローの各ステップ
インシデント対応の手順は、自社でゼロから考える必要はありません。検知から事後対応までの流れは公的機関が枠組みとして公開しており、それを土台に自社の手順書を組み立てられます。求められるのは、どの段階で何を判断し、誰が決めるのかを事前に定めておくことです。
対応フローが依拠する国内外の枠組みと、検知と分析、封じ込め、根絶と復旧、事後対応という4つの段階が、手順書を組み立てるときの骨格になります。
対応フローが依拠する国内外の枠組み
自社の手順は、公的機関の枠組みに沿って組み立てます。米国国立標準技術研究所(NIST)のSP 800-61は2025年4月にRev.3へ改訂され、4つのフェーズを示したRev.2を置き換えました。
Rev.3はサイバーセキュリティフレームワーク2.0の6機能に沿って再構成され、インシデント対応をリスク管理の一部として位置づけています。ただし実務の手順書は、準備、検知と分析、封じ込め・根絶・復旧、事後対応という4段階で書かれることが多く、本記事もこの並びに沿って説明します。
国内向けにはIPAの手引きが3段階に分けており、3つの枠組みの段階と位置づけは下表のとおりです。
| 枠組み | 示されている段階 | 位置づけ |
| NIST SP 800-61 Rev.2(2012年8月) | 準備/検知と分析/封じ込め・根絶・復旧/事後対応 | Rev.3により置き換えられた旧版 |
| NIST SP 800-61 Rev.3(2025年4月) | サイバーセキュリティフレームワーク2.0の6機能(統治・識別・防御・検知・対応・復旧)に沿って再構成 | Rev.2を置き換えた現行版 |
| IPA「中小企業のためのセキュリティインシデント対応の手引き」 | 検知・初動対応/報告・公表/復旧・再発防止 | 国内の中小企業向けに3段階で整理 |
| NIST SP 800-61 Rev.2(2012年8月) | |
| 示されている段階 | |
| 準備/検知と分析/封じ込め・根絶・復旧/事後対応 | |
| 位置づけ | |
| Rev.3により置き換えられた旧版 | |
| NIST SP 800-61 Rev.3(2025年4月) | |
| 示されている段階 | |
| サイバーセキュリティフレームワーク2.0の6機能(統治・識別・防御・検知・対応・復旧)に沿って再構成 | |
| 位置づけ | |
| Rev.2を置き換えた現行版 | |
| IPA「中小企業のためのセキュリティインシデント対応の手引き」 | |
| 示されている段階 | |
| 検知・初動対応/報告・公表/復旧・再発防止 | |
| 位置づけ | |
| 国内の中小企業向けに3段階で整理 | |
参照元:米国国立標準技術研究所|NIST SP 800-61r3(1頁・巻頭)
参照元:独立行政法人情報処理推進機構|中小企業のためのセキュリティインシデント対応の手引き(2頁)
検知と分析
検知の起点は3通りに分かれます。ログの確認やセキュリティ機器のアラート、社内の従業員からの報告、外部組織や取引先からの連絡です。
NISTのSP 800-61 Rev.3は、報告を受けたらまず予備的な確認を行い、既知の誤検知も踏まえて対処が必要なインシデントかを見極め、そのうえで重大度と緊急度を見積もるよう求めています。資産の重要度や業務への影響から優先度を決める作業が、トリアージにあたります。ログを保全しないまま先へ進むと、あとから原因をたどれなくなります。
参照元:NIST|NIST SP 800-61r3/IPA|中小企業のためのセキュリティインシデント対応の手引き
封じ込め
封じ込めは、被害がこれ以上広がらないようにする措置です。感染した端末やサーバーをネットワークから切り離す、乗っ取られたアカウントを止める、対象のシステムやサービスを停止するといった手を打ちます。業務が止まる場合もあるため、実行前に影響の大きさを見極める判断が必要です。
警察庁サイバー警察局の資料は、慌てて電源を切るとログなどの侵入の痕跡が失われ、その後のフォレンジック調査が難しくなると注意を促しています。初動では被害の拡大防止とログの保全を並行して進めます。
参照元:警察庁|令和7年におけるサイバー空間をめぐる脅威の情勢等について(17頁)
根絶と復旧
根絶では、インシデントの原因そのものを取り除きます。NISTのSP 800-61 Rev.3は、マルウェアの削除、侵害されたアカウントの無効化、悪用された脆弱性の特定と修正を挙げています。
復旧では、原因を断ったことを確かめたうえでバックアップからの復元や再構築を行い、重要な業務から順にシステムとデータを戻します。復元に使うバックアップが汚染されていないかを、使う前に確認することも求められています。復元手段を平時に検証していなければ、復旧そのものが立ち行きません。
事後対応
事後対応では、対応の経緯、被害状況、原因をまとめた報告書を作成します。目的は記録を残すことではなく、何が起きて誰がどう動き、その動きがどれだけ有効だったかを関係者で振り返り、改善点を洗い出すためです。NISTのSP 800-61 Rev.3は、報告書の作成や振り返りの場から改善点が見つかることが多いとし、対応計画そのものを定期的に見直すよう促しています。
報告書に記す項目は次のとおりです。
- ●発生日時と検知の経緯
- ●被害の範囲と影響を受けた資産
- ●実施した封じ込めと復旧の内容
- ●分析して特定した根本原因
- ●再発防止策とその実施時期
見つかった根本原因にもとづき、技術的な対策の導入、ルールの策定、教育の徹底、運用の改善といった再発防止策を決めます。IPAの手引きは、復旧後に経営者へ対応結果を報告し、被害者や影響を及ぼした取引先へ対応状況と再発防止策を伝えるよう示しています。個別の連絡が難しい場合や影響が広く及ぶ場合は、時期と内容と対象を考えたうえでウェブサイトなどで公表します。
個人データの漏えいのうち、要配慮個人情報が含まれる場合、財産的な被害のおそれがある場合、不正の目的によるおそれがある場合、1,000人を超える場合のいずれかに当たるときは、個人情報保護委員会への報告と本人への通知が義務になります。同委員会は、発覚日から3〜5日以内に速報を、30日以内に確報を提出するよう定めており、不正な目的で行われたおそれがある場合の確報は60日以内です。ウイルス感染や不正アクセスはIPA、犯罪性がある場合は警察が届出先にあたります。振り返りで出た課題は、手順書と連絡先一覧へ反映して次に備えます。
参照元:NIST|NIST SP 800-61r3/IPA|中小企業のためのセキュリティインシデント対応の手引き/個人情報保護委員会|漏えい等の対応とお役立ち資料
ファイルとデータの側で取るべき初動
端末とネットワークを止めても、被害が止まるとは限りません。外部へ発行した共有リンクが開いたままなら、そこからの参照は続きます。暗号化されたファイルも、端末を隔離しただけでは元に戻せません。端末側の封じ込めと並行して、ファイル共有基盤の側でも手を打つ必要があります。
共有リンクとアクセス権の停止、操作ログによる影響範囲の特定、感染前の世代への復元という3つが、データを預かる側で押さえるべき初動です。
共有リンクとアクセス権を即座に止める
最初に手を付けるのは、外部へ発行済みの共有リンクの無効化です。パスワードを設定していないリンク、期限を切っていないリンク、不特定多数に渡った可能性のあるリンクから順に止め、外部から参照できない状態にします。
次に、侵害された可能性のあるアカウントの権限を停止し、接続元のIPアドレスやデバイスを限定して残った経路を塞ぎます。取引先へ発行したリンクは、先に無効化してから連絡します。連絡を待つ間に参照される余地を残さないためです。
参照元:独立行政法人情報処理推進機構(IPA)|中小企業の情報セキュリティ対策ガイドライン 付録8:中小企業のためのセキュリティインシデント対応の手引き
操作ログで影響範囲を特定する
影響範囲は、操作ログから確定させます。誰がいつどのファイルを開き、ダウンロードし、外部へ共有したかを記録でたどり、実際に外へ出たデータを特定します。IPAの手引きも、誤公開の場合はどの範囲で何人が参照したかをアクセスログで調べるとしています。
範囲が固まらないうちは、個人情報保護委員会へ報告すべきか、どの取引先に通知するかも決められません。警察庁の資料によれば攻撃者はログを消して去るため、記録の取得先を端末側だけに寄せない備えが欠かせません。
参照元:IPA|中小企業のためのセキュリティインシデント対応の手引き/警察庁|令和7年におけるサイバー空間をめぐる脅威の情勢等について(16頁)
感染前の世代に戻す
ファイル単位の復旧では、世代管理を使います。暗号化や改ざんが行われる前のバージョンを選び、その時点の状態へ戻す流れです。ただし、戻す前に原因を取り除いたかどうかの確認が欠かせません。マルウェアが残ったまま復元すれば、戻したファイルがまた暗号化されます。
IPAの手引きも、パソコンに常時つないだバックアップは一緒に暗号化される場合があると注意を促しています。復元したデータが正しいと確かめたうえで、業務での利用を再開します。
インシデントが起きる前に決めておくこと
インシデント対応の成否は、起きてからの動きより、その前に何を決めてあるかで分かれます。決めていなければ、担当者はその場で判断を迫られ、報告も対処も後手に回ります。平時に決めておく項目は次の5つです。
- ●インシデントの定義と深刻度の判断基準
- ●対応体制と役割分担
- ●報告・連絡ルートとエスカレーション基準
- ●検知と記録の仕組みを用意する
- ●訓練で手順の実効性を検証する
これらはいずれも、経済産業省とIPAの「サイバーセキュリティ経営ガイドライン Ver3.0」が指示7で求める緊急対応体制の中身にあたり、上から順に着手すると無理なく進められます。
【平時に決めておく5項目のチェックリスト】
| 決めておく項目 | 具体的に決める内容 | 決まっていない場合に起きること |
| インシデントの定義と深刻度の判断基準 | 何をインシデントとして扱うか、深刻度を分ける3つの観点 | 現場が経営層へ上げるかどうかを判断できない |
| 対応体制と役割分担 | 指揮、技術調査、社外連絡それぞれの担当者と兼務の範囲 | 発生時に担当が決まらず対応が止まる |
| 報告・連絡ルートとエスカレーション基準 | 発見者から責任者、責任者から経営者へ上げる順序と連絡先 | 報告が届かず初動が遅れる |
| 検知と記録の仕組み | 認証、ファイル操作、通信の記録の取得範囲と保存期間 | 発覚後に影響範囲を特定できない |
| 訓練による検証 | 机上演習と実機を使う演習の実施時期と対象者 | 手順書どおりに動けない |
| インシデントの定義と深刻度の判断基準 | |
| 具体的に決める内容 | |
| 何をインシデントとして扱うか、深刻度を分ける3つの観点 | |
| 決まっていない場合に起きること | |
| 現場が経営層へ上げるかどうかを判断できない | |
| 対応体制と役割分担 | |
| 具体的に決める内容 | |
| 指揮、技術調査、社外連絡それぞれの担当者と兼務の範囲 | |
| 決まっていない場合に起きること | |
| 発生時に担当が決まらず対応が止まる | |
| 報告・連絡ルートとエスカレーション基準 | |
| 具体的に決める内容 | |
| 発見者から責任者、責任者から経営者へ上げる順序と連絡先 | |
| 決まっていない場合に起きること | |
| 報告が届かず初動が遅れる | |
| 検知と記録の仕組み | |
| 具体的に決める内容 | |
| 認証、ファイル操作、通信の記録の取得範囲と保存期間 | |
| 決まっていない場合に起きること | |
| 発覚後に影響範囲を特定できない | |
| 訓練による検証 | |
| 具体的に決める内容 | |
| 机上演習と実機を使う演習の実施時期と対象者 | |
| 決まっていない場合に起きること | |
| 手順書どおりに動けない | |
インシデントの定義と深刻度の判断基準
何をインシデントとして扱うかは、文書に書き出して初めて社内で共有されます。深刻度は3段階に分け、次の3つの観点で判定します。
- ●影響を受ける業務の範囲
- ●対象となるデータの種類
- ●社外への影響の有無
軽度は現場の担当者が処理して記録を残し、中程度は情報セキュリティ責任者が指揮を執り、重大は経営層へただちに上げます。IPAの手引きも、責任者が対応すべきインシデントだと判断したら速やかに経営者へ報告するとしています。基準がなければ、現場は上げるべきかどうかを判断できません。
| 深刻度 | 影響を受ける業務の範囲 | 対象となるデータの種類 | 社外への影響 | エスカレーション先 |
| 軽度 | 個人または一部の作業にとどまる | 社外秘に当たらない情報 | なし | 現場の担当者が処理して記録を残す |
| 中程度 | 部門単位の業務が滞る | 社外秘の業務データ | 取引先への連絡を検討 | 情報セキュリティ責任者が指揮を執る |
| 重大 | 全社または基幹業務が停止する | 個人データや機密情報 | 通知や公表が必要 | 経営層へただちに上げる |
| 軽度 | |
| 影響を受ける業務の範囲 | |
| 個人または一部の作業にとどまる | |
| 対象となるデータの種類 | |
| 社外秘に当たらない情報 | |
| 社外への影響 | |
| なし | |
| エスカレーション先 | |
| 現場の担当者が処理して記録を残す | |
| 中程度 | |
| 影響を受ける業務の範囲 | |
| 部門単位の業務が滞る | |
| 対象となるデータの種類 | |
| 社外秘の業務データ | |
| 社外への影響 | |
| 取引先への連絡を検討 | |
| エスカレーション先 | |
| 情報セキュリティ責任者が指揮を執る | |
| 重大 | |
| 影響を受ける業務の範囲 | |
| 全社または基幹業務が停止する | |
| 対象となるデータの種類 | |
| 個人データや機密情報 | |
| 社外への影響 | |
| 通知や公表が必要 | |
| エスカレーション先 | |
| 経営層へただちに上げる | |
表2:深刻度3段階の判定基準とエスカレーション先
参照元:独立行政法人情報処理推進機構(IPA)|中小企業の情報セキュリティ対策ガイドライン 付録8:中小企業のためのセキュリティインシデント対応の手引き
対応体制と役割分担
体制は、3つの役割に分けて決めます。指揮を執る責任者、技術的な調査を担う担当、取引先や顧客への連絡を担う担当です。経済産業省とIPAのガイドラインは、初動対応と再発防止策の検討を適時に行える体制として、インシデント対応を専門に担うチームであるCSIRTの整備を求めています。
専任チームを置けない場合は、情報システム部門と総務部門の兼務から始めます。一般社団法人JPCERTコーディネーションセンター(JPCERT/CC)のCSIRTマテリアルが、構想、構築、運用の3フェーズで手順を示します。
参照元:経済産業省|サイバーセキュリティ経営ガイドラインと支援ツール/一般社団法人JPCERTコーディネーションセンター|CSIRTマテリアル
報告・連絡ルートとエスカレーション基準
連絡ルートは、発見者から情報セキュリティ責任者へ、責任者から経営者へという順序で定めます。どの深刻度のときに誰へ連絡するかまで書いておけば、発生時に迷いません。
経済産業省とIPAのガイドラインは、システム運用の委託先やセキュリティ事業者を含む緊急連絡網と、社外への通知先一覧を整備し、対応にあたるメンバーへ共有しておくよう求めています。IPAの手引きが挙げる相談窓口や届出先も、手順書に書き込んでおきます。
参照元:経済産業省|サイバーセキュリティ経営ガイドラインと支援ツール/IPA|中小企業のためのセキュリティインシデント対応の手引き
検知と記録の仕組みを用意する
検知と追跡は、平時の仕組みがあって初めて成り立ちます。NISTのSP 800-61 Rev.3は、監視すべき対象としてネットワークの通信、利用者の操作と認証の試行、メールやファイル共有サービスを挙げています。ここから、取得しておく記録は認証の記録、ファイル操作の記録、通信の記録の3種類になります。
保存期間を決めていなければ、発覚までに数か月かかった事案をさかのぼれません。同資料も、証拠は自社の保存方針に沿って残すよう求めています。
参照元:米国国立標準技術研究所(NIST)|NIST SP 800-61r3
訓練で手順の実効性を検証する
決めた手順が実際に動くかどうかは、訓練でしか確かめられません。机上演習は、特定のシナリオを想定して連絡と判断の流れを口頭でたどるもので、短時間で実施できます。
実機を使う演習は隔離や復元の操作まで踏み込むため、手順書の記述と現場の作業の食い違いが表に出ます。出てきた課題は手順書と連絡先へ反映します。警察庁の資料も攻撃を受けた際の対応訓練が被害の抑制に有効だとしており、体制を決めたら早い段階で着手します。
DirectCloudで実現するインシデント対応
止める、追う、戻すという初動は、ファイル共有基盤にその仕組みがあって初めて実行できます。DirectCloudは、操作ログの取得、アクセス制御、バージョン管理を標準機能として備えており、3つの動作を管理ページから行えます。管理者は、被害の拡大を止めながら影響範囲の確認に取りかかれます。
誰がどのファイルを扱ったかを追える記録、共有範囲とアクセス権を絞る制御、感染前の状態へ戻す復元が、インシデント対応を支える土台になります。
誰がどのファイルを扱ったかを操作ログで追える
DirectCloudは、ユーザーの操作を記録として残します。ログイン、ファイルの送受信、共有リンクの作成など、DirectCloud上で行われた操作は管理者が把握でき、取得できるログは管理者の操作を含めて250種類以上にのぼります。
この記録があれば、どのファイルが誰の手に渡ったかを特定でき、社内への報告や取引先への説明にも裏づけを添えられます。発生してから取り始めても間に合わないため、平時から記録を取得しておく基盤として位置づけます。
参照元:DirectCloud|法人向けクラウドストレージ「DirectCloud」の特徴
共有範囲とアクセス権を即座に絞れる
利用できる範囲は、管理者の設定で狭められます。DirectCloudは7種類のアクセスレベル、機能制限、IPアドレス制限、デバイス認証、二要素認証を標準で備えています。デバイス認証とネットワーク制限を組み合わせておけば、管理者が指定したネットワークの範囲内で、許可済みのデバイスからしか利用できません。
特定のIPアドレスやデバイスから異常が検知された場合は、そのアクセスを即座に遮断できます。端末を紛失したときも、すぐにロックをかけられます。
参照元:DirectCloud|法人向けクラウドストレージ「DirectCloud」の特徴
暗号化されたファイルを感染前の状態に戻せる
暗号化されたファイルは、バージョン管理で元の世代へ戻せます。DirectCloudは全プランにランサムウェア対策を標準提供しており、感染時にはバージョン管理機能でデータを復元できます。誤操作で上書きしてしまった場合も、同じ仕組みで前の世代を選び直せます。
ただし、クラウド側で復元しても、端末上で進む暗号化そのものは止まりません。暗号化のふるまいを監視して遮断するエンドポイント向けサービスWhiteDefenderと組み合わせれば、端末側で被害の進行を止めたうえで、クラウド側のDirectCloudから感染前の世代を呼び戻せます。端末で止める役割と、ファイルを戻す役割を分けて持たせる考え方です。
インシデント対応の課題を解決した事例
インシデント対応の課題は、実際に改善策を行った企業の記録から見えてきます。紹介する3社は、追跡できない操作ログ、ブラックボックス化した権限設定、煩雑なファイル単位のリストア作業という、異なる困りごとを抱えていました。
業種も規模も違いますが、いずれもDirectCloudへの移行で課題を解消しています。3社が導入前に何に困り、導入後に何が変わったのかをご覧になり、自社の体制を見直すヒントとしてください。
追跡できなかったファイル操作を追えるようにした事例
東ソー情報システム株式会社様は、操作ログを取得できない状態に課題を抱えていました。導入前に使っていたオンラインストレージは、ユーザーがファイルに対して行った操作のログが残らず、内部統制の強化が図られていませんでした。また、共通アカウントの利用もあったため、有事の際に誰の操作かをたどれない状態でした。
DirectCloudへの移行後は、250種類以上の操作ログ取得機能により、インシデントが発生した際の追跡性を確保できています。怪しい記録のあるユーザーを無効にする対応も行えるようになりました。
権限のブラックボックス化を解消し統制を強化した事例
権限設定のブラックボックス化に直面したのが、トーセイ・コミュニティ株式会社様です。ファイルサーバー導入当時の管理者が退職しており、誰にどの権限が付与されているのかを把握できない状態でした。Windows Server標準のログ取得機能にも限界があり、いつ誰がどのファイルにどんな操作をしたかまでは記録に残りませんでした。
DirectCloudへ移行後は、フォルダへのアクセス権とファイル操作の権限をユーザーごとに管理ページで把握でき、250種類以上の操作ログ取得機能により内部統制を大幅に強化できています。
ランサムウェア感染時の復旧工数を削減した事例
ファイルサーバーのランサムウェア対策に苦慮していたのが、菊正宗酒造株式会社様です。約5年周期でサーバーを入れ替える負担があり、対策を自力で行うこと自体が重荷になっていました。バックアップは取っていたものの、個々のファイルを戻すリストア作業は煩雑でした。
DirectCloudの導入後は、ランサムウェアなどのウイルス対策が容易になり、業務効率が向上しています。データをDirectCloudへ集約したことで、ファイル単位のリストア対応にかかる工数も削減できました。
よくある質問
体制づくりを進めると、どこまでを自社で担い、どこからを外部や仕組みに任せられるのかという疑問が出てきます。手順書をゼロから書き起こすべきかどうかも、着手前に迷いやすい点です。
外部委託の範囲、対応計画のひな形の入手先、自動化できる範囲、報告の期限、費用の目安という5つの質問に、公的機関の資料をもとに答えます。
インシデント対応は外部に委託できますか
調査や初動対応を支援する専門事業者は存在します。日本ネットワークセキュリティ協会(JNSA)は、被害調査や切り分け、復旧などを有償で請け負う企業の一覧を公開しています。
経済産業省とIPAのガイドラインも、自組織での対応が難しい取組は一部を外部委託することも検討するよう促します。契約は平時に結んでおく形と、発生してから依頼する形のどちらもあります。ただし、業務を止めるかどうかの判断と社外への公表は、自社に残ります。
参照元:独立行政法人情報処理推進機構(IPA)|中小企業の情報セキュリティ対策ガイドライン 付録8:中小企業のためのセキュリティインシデント対応の手引き/経済産業省|サイバーセキュリティ経営ガイドラインと支援ツール
対応計画のテンプレートはどこで入手できますか
JPCERT/CCとIPAが無償で公開しています。JPCERT/CCのCSIRTマテリアルは、構想、構築、運用の3つのフェーズに分けて体制づくりの手順を示し、インシデントハンドリングマニュアルも含みます。IPAの手引きは、相談窓口や届出先の一覧まで収めた内容です。
ただしCSIRTマテリアル自体が、すべての組織が同じ形を達成する必要はないと述べています。自社の体制に合わせて項目を選び直す作業は欠かせません。
参照元:一般社団法人JPCERTコーディネーションセンター|CSIRTマテリアル
インシデント対応はどこまで自動化できますか
検知と初期対応の一部は仕組みに任せられます。NISTのSP 800-61 Rev.3は、各所のログを少数のログサーバへ集め、SIEMやSOARで関連づけて監視することを挙げています。
特定の種類のアラートが出たときにチケットを自動で作成して担当者に割り当てる運用や、マルウェアの隔離、侵害された端末を隔離用ネットワークへ移す措置も自動で行えます。一方、業務を止める判断と社外への公表は、人が決める領域として残ります。
参照元:米国国立標準技術研究所(NIST)|NIST SP 800-61r3
個人データが漏えいした場合、報告はいつまでに必要ですか
報告義務の対象に当たる場合は、速報と確報の2段階で期限が決まっています。個人情報保護委員会は、発覚日からおおむね3〜5日以内に速報を、30日以内に確報を提出するよう求めています。不正な目的で行われたおそれがある場合、確報の期限は60日以内です。
報告義務の対象は、要配慮個人情報、財産的な被害のおそれ、不正の目的によるおそれ、1,000人超という4つの類型です。本人への通知も併せて必要になります。3〜5日という短さを踏まえると、誰がどのデータに触れたかを短時間で確定できる記録の仕組みを、平時から整えておく必要があります。
インシデント対応にかかる費用はどれくらいですか
被害の規模と外部へ委託する範囲によって大きく変わります。警察庁の資料によれば、ランサムウェア被害に遭った企業・団体のうち、調査と復旧に総額1,000万円以上を要した組織が5割を超えました。
専門事業者による被害調査や復旧は有償で、JNSAが公開する緊急対応企業一覧から各社へ直接問い合わせる形になります。平時のログ取得やバックアップに投じる費用は、この復旧費用を抑えるための備えにあたります。
参照元:警察庁|令和7年におけるサイバー空間をめぐる脅威の情勢等について(14頁)/IPA|中小企業のためのセキュリティインシデント対応の手引き
まとめ
インシデント対応は、攻撃を防ぎきれない前提に立って初めて機能します。復旧に多額の費用を要する被害が相次ぐ一方で、備えを終えた組織は限られるのが現状です。検知から事後対応までの流れを公的機関の枠組みに沿って定め、何をインシデントとして扱うか、誰が判断して誰へ上げるかを平時に決めておけば、発生時の迷いは減ります。手順を訓練で確かめておくことで、初動の遅れによる被害の拡大も抑えられるでしょう。
ファイルとデータの側の備えには、DirectCloudが役立ちます。250種類以上の操作ログで影響範囲をたどり、アクセス権と共有範囲を即座に絞り、バージョン管理で感染前の世代へ戻せます。インシデント対応の実効性を高める基盤として、自社の手順に組み込めるかを確かめてみてください。
- タグ:
- セキュリティ

