会社情報
採用情報
お問い合わせ
Article

セキュリティインシデント発生時の対応手順

高田晃太郎
セキュリティインシデント発生時の対応手順

セキュリティインシデント発生時の対応手順

統計が示す現実は想像以上に厳しい。IBM Cost of a Data Breach 2024では平均被害コストが約4.88百万ドル、円換算でおよそ7億円に達するとされ、Mandiant M-Trends 2024は内部検知の中央値が10日、外部通知の場合は74日に延びると報告している¹²。つまり、検知の速さと初動の質が損害規模を決める。私はプロダクト組織とCSIRT（Computer Security Incident Response Team）の両輪を回してきた立場から、初動60分、72時間の調査・復旧、30日の恒久対策という時間軸で、業務改善とシステム効率化を同時に満たす実務的な手順（インシデントレスポンスのランブック）を示したい。専門用語は最小限に置き換えつつも、経営に響くKPIと現場が動けるコマンド例を併記する。結論として、標準化された手順と自動化は、平均対応時間（MTTR: Mean Time to Recovery）を短縮し、被害コストを有意に圧縮しうることが複数の調査で示唆されている¹⁴⁵。

初動60分でやるべきこと：トリアージ、封じ込め、証拠保全

初動のゴールは、被害の拡大を止め、後続の調査に必要な証拠を残し、関係者の行動を同期させることだ。過度な遮断で業務を止めすぎるのも、逆に悠長に構えて横展開（攻撃者が他の端末やアカウントへ移動すること）を許すのも、どちらもコストを膨らませる。研究データでは、対応計画を整備・演習している組織は平均被害額を抑えられる傾向が示されている³。だからこそ、判断基準が明文化されたランブック（手順書）を用意し、その通りに動くことが効率化の近道になる⁴。

トリアージの基準と封じ込めの幅を決める

私が必ず確認するのは、影響範囲、横移動の兆候、特権濫用の有無、データ持ち出しの痕跡の四点だ。影響範囲が限定的で横移動が見られないなら、ネットワーク隔離よりもログ採取を先行させる。逆に特権アカウントの乗っ取りやドメインコントローラ（認証の中枢）の異常が疑われる場合は、証拠保全を並行しながら、被疑端末の即時隔離や資格情報の強制無効化を躊躇しない。ここでのキーワードは可逆的な封じ込めだ。たとえばEDR（Endpoint Detection and Response）のネットワーク隔離機能は復帰が容易で、証拠も保持されやすい。電源断のような不可逆な措置は最終手段と捉える。

初動採取のために、Linuxでのプロセス・接続・ログのスナップショットをワンショットで残す小さなスクリプトを用意しておくと良い。以下は例だ（初動対応や証拠保全、インシデント対応手順の標準化に役立つ）。

#!/usr/bin/env bash
set -euo pipefail
TS=$(date -u +"%Y%m%dT%H%M%SZ")
HOST=$(hostname)
OUT="/tmp/${HOST}_${TS}_triage"
mkdir -p "$OUT"
ps auxww > "$OUT/process.txt"
ss -plant > "$OUT/net.txt"
who -a > "$OUT/logon.txt"
last -F > "$OUT/last.txt"
journalctl -S -2h > "$OUT/journal_2h.log" || true
sudo tar -czf "/tmp/${HOST}_${TS}_logs.tgz" /var/log 2>/dev/null || true
sha256sum "$OUT"/* > "$OUT/hashes.txt" || true
tar -czf "/tmp/${HOST}_${TS}_triage.tgz" -C /tmp "${HOST}_${TS}_triage"
echo "Saved to /tmp/${HOST}_${TS}_triage.tgz"

WindowsではPowerShellで同等の採取を行う。管理者権限での実行を前提に、イベントログは最近2時間に絞ると初動判断に十分なことが多い。

$ts = (Get-Date).ToUniversalTime().ToString('yyyyMMddTHHmmssZ')
$hostn = $env:COMPUTERNAME
$out = "$env:TEMP\${hostn}_${ts}_triage"
New-Item -ItemType Directory -Force -Path $out | Out-Null
Get-Process | Sort-Object CPU -Descending | Out-File "$out\process.txt"
Get-NetTCPConnection | Out-File "$out\net.txt"
quser | Out-File "$out\logon.txt" 2>$null
Get-ScheduledTask | Out-File "$out\tasks.txt"
$start = (Get-Date).AddHours(-2)
Get-WinEvent -FilterHashtable @{LogName='Security'; StartTime=$start} | Export-Clixml "$out\evtx_security.xml"
Compress-Archive -Path $out -DestinationPath "$env:TEMP\${hostn}_${ts}_triage.zip" -Force
Write-Host "Saved to $env:TEMP\${hostn}_${ts}_triage.zip"

証拠保全とコミュニケーションの同時進行

初動で最も失われやすいのは一時ファイルやメモリ上のアーティファクトだが、現場の体感では関係者の認識のずれのほうが致命傷になりやすい。だからこそ、単一の指揮系統と、SlackやTeamsの専用チャンネル、インシデントID、タイムスタンプ付きの決定ログを整える。調査の仮説、取ったアクション、未解決のリスクを一つのスレッドに集約し、ステークホルダー（経営、法務、PR、IT運用）に短い状況報告を一定間隔で共有する。「誰が、何を、いつまでに」の三点が曖昧になると、MTTRは簡単に二倍化する。可視化の仕組みは大げさでなくていい。JiraやNotionのテンプレートを用意し、チェックリストを淡々と埋めるだけでも、業務改善の効果は明確に出る。

72時間の調査と復旧：スコープ確定、根の切断、段階的再開

ここからの焦点は、最初の侵入口の特定、横展開の経路の遮断、汚染範囲の網羅、そして安全な復旧手順の確立に移る。システムごとのログの粒度が異なるため、SIEM（Security Information and Event Management）とEDRでタイムラインを一本化すると効率が良い。研究データでは、自動化やAI分析を導入している組織は、非導入に比べて検知から封じ込めまでの日数を短縮できる傾向が示されている⁵。ここでも、人の判断を支えるクエリの標準化が効く。

タイムライン再構築とスコープ特定

クラウドとIDのログから侵入の起点を逆引きする。Microsoft Sentinelなどでサインイン異常を水際から洗うKQL（Kusto Query Language）のひな形を用意しておくと使い回しが利く。

let lookback = 3d;
SigninLogs
| where TimeGenerated > ago(lookback)
| where ResultType !in (0, "0") or RiskDetail !in ("none", "None")
| summarize attempts=count(), ips=make_set(IPAddress), apps=make_set(AppDisplayName) by UserPrincipalName, bin(TimeGenerated, 1h)
| order by TimeGenerated desc

AWSならGuardDutyやCloudTrailをAthenaで引く。S3上のログに対して、不審なDescribeやListの急増、異常な地理からのConsoleLoginを軸にする。以下は簡易的なAthena SQLの例だ。

SELECT userIdentity.arn, eventName, sourceIPAddress, count(1) AS cnt,
       date_trunc('hour', from_iso8601_timestamp(eventTime)) AS hour
FROM cloudtrail_logs
WHERE eventTime >= date_add('day', -3, current_timestamp)
  AND (eventName LIKE 'ConsoleLogin' OR eventName LIKE 'Describe%' OR eventName LIKE 'List%')
GROUP BY 1,2,3,5
HAVING cnt > 10
ORDER BY hour DESC, cnt DESC;

エンドポイント側はosqueryが手軽だ。横移動の足場になりやすい常駐プロセスとリスニングポートを一望して、組織のベースラインから外れた差分に注目する。

SELECT p.pid, p.name, p.path, l.port, l.address, l.family
FROM processes p
JOIN listening_ports l ON p.pid = l.pid
WHERE l.port NOT IN (22, 80, 443, 3389)
ORDER BY l.port;

マルウェア疑いのファイルが見つかったら、YARAで特徴抽出をしてサーバ全体をサーフする。検体から得た文字列は一般化しすぎず、誤検知を避けるために限定的にするのがコツだ。

rule Suspicious_Tooling_Minimal {
  meta:
    author = "CSIRT"
    description = "Minimal pattern for suspected tooling"
  strings:
    $s1 = "-enc" ascii nocase
    $s2 = "Invoke-WebRequest" ascii nocase
    $s3 = /[A-Za-z0-9+\/]{200,}={0,2}/
  condition:
    2 of ($s*) and filesize < 5MB
}

復旧の順序と再発防止の短期施策

復旧は段階的に行う。まず認証の安全を取り戻す。被疑期間に発行されたトークンとセッションを無効化し、特権アカウントの資格情報をリセットする。次に、侵入口にあたる脆弱性や誤設定に手当てをする。境界の穴を残したまま業務再開を急ぐと、再侵入で二重にコストを払うことになる。ここで自動化の効果が出る。たとえば、疑わしい端末のローカルユーザやスケジュールタスクを一括無効化するスクリプトを仕込んでおくと、現場の再現性が上がる。

#!/usr/bin/env bash
set -euo pipefail
for host in $(cat suspected_hosts.txt); do
  ssh -o BatchMode=yes "$host" 'sudo systemctl stop suspicious.service || true; sudo usermod -L tempuser || true'
done

自動化の対象は封じ込めだけではない。ログルーティングや監査設定の是正も、構成管理ツールで即時に適用する。これにより、人依存のばらつきが消え、MTTRと人的コストが同時に下がる。なお、復旧に際しては、段階ごとに合意ゲートを設ける。データの整合性、監査要件、ビジネス優先度の三点を小さく確認しながら戻すほど、後戻りのコストが下がる。

30日の振り返りと恒久対策：根本原因、制御の強化、経営への接続

インシデントは改善のための高価なデータセットだ。だからこそ、初動の熱が落ちた頃に、冷静なレビューを行う。ここでの焦点は、個人ではなくシステムに当てる。なぜ気付けなかったのか、なぜ止められなかったのか、なぜ早く戻れなかったのかという三つの「なぜ」に答える形で、検知、予防、復旧の各コントロールを更新する。

根本原因分析と制御の強化

技術的な根は一つとは限らない。脆弱な公開サービスが足掛かりになり、過剰な許可のIAMが横展開を許し、監視の抜けが気付きを遅らせる、といった多段の失敗が普通だ。ここで役立つのは、ファクトベースのタイムラインとKPIだ。平均検知時間（MTTD: Mean Time to Detect）、平均対応時間（MTTR）、高リスク脆弱性の修正リードタイム、EDRのカバレッジ率、ログの保存期間など、改善前後で比較できる指標を選ぶ。一般に、EDRやID保護のカバレッジを高め、疑似攻撃で検知精度をチューニングすることで、横移動の初期兆候を捉える確度が上がり、調査コストの削減が期待できる。検知強化では、具体的な疑似攻撃を流して感度を合わせると良い。たとえば、Microsoft Sentinelに対してKQLアラートのしきい値をABテストするやり方だ。

DeviceLogonEvents
| where Timestamp > ago(7d)
| summarize dcount(DeviceId) by AccountName
| where dcount_DeviceId > 5 // 横展開疑いのしきい値

経営報告、法令・顧客対応、サイバー保険

技術的な対策が落ち着いたら、経営と外部への説明責任を果たす。被害評価、再発防止策、残余リスク、そして投資対効果を一枚絵で示す。ここで、「どのコントロールにいくら投じ、MTTRと被害額がどれだけ下がるのか」を具体的に語れると、意思決定が早くなる。法令や業界ガイドライン（たとえば個人情報保護や重要インフラ関連の指針）に基づく届出や顧客通知は、事前にテンプレートを整備し、法務とPRがレビュー済みの文面を用意する。サイバー保険を利用する場合は、インシデント当日の連絡と、証拠保全の要件を満たしているかの確認が肝になる。保険会社のIRパートナーと連携すると、外部DFIR（デジタル・フォレンジックとインシデント対応）のリソースを迅速に引き込め、効率的な復旧に寄与する。

実装の現実解：自動化、演習、そして日常運用に落とす

対応手順は、書いて終わりではなく、日常の運用で磨かれる。SREのインシデント運用とCSIRTをつなげ、モニタリング、オンコール、ポストモーテムの文化を共有すると、意思決定の速度と質が揃う。実装の取っ掛かりとして、ログの標準化と保存期間の延伸、EDRとID保護のカバレッジ拡大、そして四半期ごとのテーブルトップ演習（机上演習によるインシデント対応訓練）を推す⁴。演習のシナリオは、外部通知を伴うもの、ドメイン侵害、クラウド鍵漏洩、ランサムウェア初動対応など、組織の実情に合わせて負荷を調整する。最後に、小さな自動化を積み上げる文化を根付かせる。たとえば、疑わしいPowerShellのロギングを常時有効化し、SIEMに即時連携する仕掛けだ。

# PowerShell ログの強制有効化とSIEM転送の一例（概念）
Set-ItemProperty -Path HKLM:Software\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging -Name EnableScriptBlockLogging -Value 1 -Type DWord
# 転送はWindows Event Forwardingやエージェント設定で一括適用

こうした小さな積み重ねが、検知の早さ、封じ込めの確実性、復旧の速さの三拍子を揃え、結果として業務改善とシステム効率化の両立につながる。運用の現場で汗をかいた手順は、次の危機で必ず味方になる。

まとめ：次の60分を、今日のうちに設計する

結局のところ、インシデント対応は時間との勝負だ。最初の60分でやることを決め、72時間で根を断ち、30日で仕組みに落とし込む。このリズムを組織の標準にするだけで、平均対応時間と被害額は目に見えて下がる。今日できる一歩として、専用チャンネル、決定ログ、採取スクリプト、そしてKQLの雛形を揃え、来週のテーブルトップ演習をカレンダーに入れてほしい。あなたの組織は、どの指標から改善を始めるだろうか。MTTDか、EDRカバレッジか、それとも資格情報のローテーションか。答えは一つではないが、動き出した組織だけがコストをコントロールできる。

参考文献

  1. IBM Security. What’s new in the 2024 Cost of a Data Breach Report. https://www.ibm.com/think/insights/whats-new-2024-cost-of-a-data-breach-report
  2. Google Cloud (Mandiant). M-Trends 2024 overview. https://cloud.google.com/blog/topics/threat-intelligence/m-trends-2024
  3. SecurityWeek. Incident Response Plans Reduce Cost of Data Breach: Study. https://www.securityweek.com/incident-response-plans-reduce-cost-data-breach-study/
  4. NIST. Computer Security Incident Handling Guide (SP 800-61 Rev. 2). https://www.yumpu.com/en/document/view/5247273/sp-800-61-revision-2-computer-security-resource-center-nist
  5. IBM Security. AI and automation shorten breach lifecycle by nearly 100 days (2024 report insight). https://www.ibm.com/think/insights/whats-new-2024-cost-of-a-data-breach-report#:~:text=Two%20out%20of%20three%20organizations,nearly%20100%20days%20on%20average