情シスが平時に整備すべき3つの備え
だからフォレンジック調査が失敗する 企業のログ管理と資産把握の盲点とは
サイバー攻撃が増加傾向にある中、デジタルフォレンジック調査の重要性は高まっている。しかし、事前の準備不足によって原因究明が困難になるケースは少なくない。本稿では、情シスが整備すべき備えを紹介する。
サイバー攻撃や不正アクセスへの対応として、デジタルフォレンジック調査を活用する企業が増えている。しかし、実際にインシデントが発生してから初めて、「必要なログが残っていない」「何を調査会社へ依頼すればよいか分からない」といった問題に直面するケースは少なくない。
フォレンジック調査は、インシデントが起きてから準備すればよいものではない。その成否は、平時にどれだけ情報資産やログ管理、初動体制を整備しているかによって大きく左右される。本稿では、フォレンジック調査が機能しない理由を整理するとともに、情報システム部門(以下、情シス)が今から取り組むべき備えを紹介する。
フォレンジック調査が失敗する原因は“3つの準備不足”
併せて読みたいお薦め記事
AIとセキュリティ
「何かあってもバックアップから復旧できるはずだから問題ない」。そのように考えている企業は少なくない。しかし、バックアップはシステムを復旧するための仕組みであり、「何が起きたのか」「どこから侵入されたのか」「情報漏えいはあったのか」を明らかにするものではない。
実際には、インシデント発生後に初めて、「復元テストを実施していなかった」「ログの保存期間が短かった」「資産台帳が整備されていなかった」といった問題が次々に判明するケースがある。
例えば、社内の監視システムが異常なアクセスを検知したとする。担当者が調査を始めても、
- 詳細なログが保存されていない
- 対象となるサーバや端末が把握できない
- 利用しているクラウドサービスの一覧が存在しない
という状況では、原因究明そのものが困難になる。
つまり、問題はインシデントが発生した瞬間ではなく、それ以前の準備不足にある。フォレンジック調査が十分な成果を出せるかどうかは、「調査会社の能力」だけではなく、「依頼する企業側の準備」に左右される。
インシデント発生後に初めて気付く「準備不足」
フォレンジック調査が機能しない企業には、共通する特徴がある。それは、多くの問題がインシデント発生後になって初めて発覚することだ。
ログが存在しない、あるいは残っていない
最も多い問題の1つが、調査に必要なログが保存されていないケースだ。「ログは取得している」と考えていても、実際には保存期間が数日しか設定されていなかったり、一部の機器しか対象になっていなかったりすることは珍しくない。
その結果、「攻撃がいつ始まったのか」「侵入経路は何だったのか」といった重要な情報を確認できなくなる。
調査対象そのものが分からない
もう1つの典型例が、IT資産の把握不足だ。調査会社へ依頼すると、最初に「対象となる機器やシステムの一覧を提示してください」と求められることが多い。しかし、端末やサーバ、クラウドサービスの一覧が整備されていなければ、どこまで調査すべきかを決めることすらできない。
その結果、調査範囲が曖昧になり、時間や費用が余計にかかるだけでなく、本来調査すべき対象を見落とす可能性もある。
平時の備えが調査結果を左右する
フォレンジック調査は、優れた調査会社へ依頼すれば必ず成功する訳ではない。
公表されている各種ガイドラインでも示されているように、十分なログや証拠が存在しなければ、専門家であっても事実を復元することは困難である。また、初動対応を誤れば、調査に必要な証拠そのものが失われる可能性もある。
言い換えれば、フォレンジック調査の成否は、インシデント発生後ではなく、「平時」の設計によって決まる。
情シスが今から整備すべき3つの備え
では、情シスは具体的に何を準備すればよいのだろうか。重要なのは、「IT資産の把握」「ログの保管体制」「初動フロー」の3点だ。この3つが整って初めて、フォレンジック調査は十分に機能する。
IT資産を正確に把握する
調査対象が分からなければ、調査そのものを始められない。そのため、まず必要なのはIT資産台帳の整備である。Microsoft Excelやスプレッドシートで構わないので、
- 端末名
- ユーザー名
- OSのバージョン
- 設置場所
といった基本情報を管理しておくことが重要だ。これだけでも、インシデント発生時に対象範囲を迅速に特定できるようになる。
さらに、クラウドサービスについても、以下を一覧化しておけば、外部サービスへの影響確認も容易になる。
- 利用サービス名
- 管理者アカウント
- 契約部門
特に注意したいのが、現場部門が独自に契約したSaaSだ。いわゆるシャドーITは、情シスが存在自体を把握していないこともある。SaaSが攻撃経路になれば、調査の起点を見つけることは困難になる可能性がある。
しかし、年に一度でも全部門へ利用中サービスの申告を求める仕組みを設ければ、こうした把握漏れを大幅に減らすことが可能だ。
ログの保管体制を見直す
IT資産を把握できても、調査に必要なログが残っていなければ、攻撃の経路や被害範囲を十分に特定することは難しい。「ログは取得しているから大丈夫」と考える企業もある。しかし、実際には保存期間が短かったり、一部のシステムしか対象になっていなかったりするケースは珍しくない。
特にランサムウェア攻撃では、攻撃者が侵入してから実際に暗号化や情報窃取を実行するまで、数週間から数カ月にわたって潜伏する場合がある。そのため、保存期間が数日から数週間程度しかなければ、侵入の痕跡を確認できない可能性が高い。
そこで情シスが確認すべきポイントは、大きく3つある。
- 何のログを取得しているか(保存対象)
- どれくらいの期間保存しているか(保存期間)
- どこに保存しているか(保存場所)
このうち、特に見落とされやすいのが保存場所だ。
例えば、ランサムウェアによってファイルサーバや共有ストレージが暗号化された場合、同じ環境に保存していたログまで失われる可能性がある。そうなれば、フォレンジック調査の重要な証拠も同時に消えてしまう。
証拠保全という観点からは、ログを攻撃対象となるシステムとは別の環境へ保管することが望ましい。また、潜伏期間を考慮すると、可能な限り長期間保存できる体制を整備しておくことが重要である。
初動フローを「言語化」しておく
フォレンジック調査の結果は、初動対応に左右される。しかし、インシデント発生時には「とにかく業務を復旧させたい」という心理が働きやすい。その結果、担当者がシステムを再起動したり、不要だと思ったログを削除したりしてしまい、後から調査に必要な証拠が失われるケースもある。
メモリ上に存在する情報など、一度失われると復元できない証拠も少なくない。そのため、「何をするか」だけでなく、「何をしてはいけないか」を事前に決めておく必要がある。
最低限でも、A4用紙1枚程度の初動フローを用意しておきたい。そこに、以下を明記しておくとよい。
- 第一報の連絡先
- 初動時に実施してはいけない行為(再起動、電源オフ、ログ削除など)
- 外部のフォレンジック調査会社へ連絡するタイミング
ただし、手順書は作成しただけでは意味がない。担当者一人が理解していても、その人が不在であれば機能しないからだ。
年に一度でも読み合わせや訓練を実施し、関係者全員が同じ手順を共有している状態を維持することが重要だ。
フォレンジック調査は「技術の答え合わせ」ではない
ここまで紹介した備えは、「技術的な原因究明」のためだけに必要なのではない。フォレンジック調査の結果は、経営層への報告だけでなく、取引先や顧客、さらには監督官庁への説明にも利用される重要な資料となる。
説明責任を果たすための根拠になる
インシデントが発生した場合、関係者から求められるのは「何が起きたのか」「どの範囲まで影響が及んだのか」「再発防止策は何か」という説明である。
その際、「社内で調べた結果です」という説明だけでは十分な信頼を得られない場合がある。
一方、専門家による客観的な分析結果をまとめたフォレンジック調査報告書は、経営層や取引先とのコミュニケーションを支える重要な根拠となる。
そのため、フォレンジック調査は単なる技術調査ではなく、企業として説明責任を果たすための重要なプロセスでもある。
Copyright © ITmedia, Inc. All Rights Reserved.
この記事の著者
関連記事
新着ホワイトペーパー PR
-
市場調査・トレンド
[AvePoint Japan株式会社] SCS評価制度の死角は“SaaSの中” クラウド標準機能では届かない領域とは? -
製品資料
[デジタルサーカス株式会社] 5分で分かる、「オープンソースCMS」比較ガイド -
製品資料
[デジタルサーカス株式会社] 1つのアプリを各国で運用 多言語モバイルアプリを簡単に開発・導入できる方法 -
製品資料
[ニュータニックス・ジャパン合同会社] 複雑化するKubernetes運用、VMとコンテナの二重管理を解消する方法は? -
市場調査・トレンド
[アルプス システム インテグレーション株式会社] 急増する高度なフィッシング詐欺 先回りしてブロックするには何が必要?
こんなメディアも見られています
TechTargetジャパンに関連する情報をお探しであれば、こちらのメディアもお役に立てるかもしれません。
ベンダーコンテンツ PR
From Informa TechTarget
SpecialPR
アクセスランキング
-
1
PHPはそもそも必要か? 脆弱性で問われる自社サイト安全性と保守負担のバランス
-
2
「セキュリティ運用と侵入後の初動防御」に関するアンケート
-
3
京王電鉄・東京メトロの被害から学ぶ境界防衛 ITの侵害はどこまで波及するか
-
4
「Microsoft 365」が乗っ取られる MFAを破る“本物の画面”の恐怖
-
5
PHP2Shellの「事前の情報流出」でパニックに パッチ公開を巡る“混乱劇”
-
6
PHP脆弱性「PHP2Shell」で2260万件に影響 情シスの緊急チェックリスト
-
7
米国防総省で300万人分の個人情報が流出 その「意外な原因」と教訓
-
8
Microsoft 365導入後も稟議は「Excelをメールで回覧」 承認が止まる理由
-
9
金融・通信で情報漏えいが続出 IPAとJPCERT/CCが情シスに求める緊急点検
-
10
「データ活用とAI活用の実態」に関するアンケート
ホワイトペーパーランキング PR
-
1
AI駆動攻撃にどう対抗する? 超速の攻撃からエンドポイントを保護する方法
-
2
最速72分でデータが流出? 最新の脅威トレンドや侵入手法から分かった防衛策
-
3
経験豊富な即戦力人材に直接アプローチできる、「攻めの採用」への転換術
-
4
2026年のサイバーセキュリティには何が必要か? 最新データに学ぶ傾向と対策
-
5
「IT史に名を残すシステム障害」8選
-
6
「EDR」選定ガイド:比較・検討フェーズで整理すべきポイントを解説
-
7
10G回線の真価をフルに享受するには? 導入前にチェックしたいポイント
-
8
HDDを使わない「SSDオンリー」が無謀なのはなぜ?
-
9
MDMだけでは防げない? Appleデバイスに潜む5つのセキュリティギャップ
-
10
なぜRPA導入は頓挫する? シナリオ作成の壁を乗り越える解決策とは
TechTargetジャパン SNS
インフォメーション
注目情報をチェック
TechTargetジャパンをフォロー