インシデントハンドリング

読み：いんしでんとはんどりんぐ　／　英語表記：Incident Handling

• セキュリティ
• 性能・監視・運用

セキュリティインシデントの検知や報告の受付から解決までを、あらかじめ定めた手順に沿って進める一連の対応活動である。影響や緊急度から対応の優先順位を決め、被害の拡大を防ぐ封じ込め、原因の除去と復旧を行い、再発防止につなげる。

イマシルちゃんの解説

会社のPCがウイルスに感染したかもしれない、と連絡が来たらどうしたらいいかな。
慌てて電源を切ったり思いつきで調べ回ったりすると、原因を探す手がかりが消えちゃうこともあるんだ。
そこで、セキュリティ上の事故であるインシデントには、決まった流れで対応する活動が必要になるよ。
連絡の受付から解決までを手順に沿って進めるこの活動を、インシデントハンドリングというんだ。
まず本当に対応が必要な事故なのかを見極めて、どれから手を付けるかを決めるの。
次に感染した端末をネットワークから切り離すなどして、被害が広がらないようにするよ。
原因を取り除いて元に戻したら、同じことが起きないように手順や設定も見直すんだ。

より深い解説

定義と位置付け

インシデントとは、情報システムやデータの機密性・完全性・可用性を損なう、またはその恐れがある事象である。マルウェア感染、不正アクセス、情報漏えい、サービス妨害などが該当する。これに対し、観測できる出来事全般はイベントと呼ぶ。ログイン失敗の記録一件はイベントであり、それがすぐにインシデントとは限らない。

インシデントハンドリングは、インシデントが発生してから解決するまでの一連の処理を指す。JPCERT/CCのインシデントハンドリングマニュアルは、言葉の範囲を次のように整理している。

実務では「インシデント対応」「インシデントレスポンス」をハンドリングとほぼ同じ意味で使うことも多い。資料を読むときは、その資料がどの範囲を指しているかを確かめる。

ハンドリングの中心となるのは、組織内のCSIRTである。ただしCSIRTだけで完結する活動ではなく、システム運用担当、利用者、経営層、法務・広報、外部の専門家などが関わる。誰が何を決めるかを事前に定めることが、対応の速さを左右する。

JPCERT/CCの基本の流れ

JPCERT/CCのマニュアルは、ハンドリングの基本的な流れを四つの段階で示している。

1. 検知／連絡受付：自組織での検知や、外部・利用者からの通報を受け付ける。
2. トリアージ：対応すべきインシデントかを判断し、対応の優先順位を付ける。
3. インシデントレスポンス（対応）：事象を分析し、対応計画を立てて実施し、解決を確認する。
4. 報告／情報公開：関係者への報告、監督官庁への届出、プレスリリースなどを行う。

この言葉は、もともと災害医療で治療の優先度を決める選別の考え方に由来する。インシデントでも、同時に多数の報告が届くことがあり、すべてに全力で対応することはできない。影響を受ける業務の重要度、被害の広がり、情報漏えいの有無などから、どれを先に扱うかを決める。担当範囲外の報告は、適切な窓口へ回す。

NIST SP 800-61 Rev.2のライフサイクル

国際的に広く参照されてきたのが、米国NISTのSP 800-61 Rev.2「Computer Security Incident Handling Guide」（2012年）である。インシデント対応を次の四つのフェーズの繰り返しとして示した。

この四つは一方向に一度だけ進むものではない。被害の拡大を止める作業中に新たな感染端末が見つかれば、検知と分析へ戻る。最後のフェーズで得た教訓は、次のインシデントに向けた準備へ反映される。

NIST SP 800-61 Rev.3（2025年）での整理

2025年4月、NISTはSP 800-61 Rev.3を公開し、Rev.2を置き換えた。表題は「Incident Response Recommendations and Considerations for Cybersecurity Risk Management」であり、サイバーセキュリティフレームワーク（CSF 2.0）のコミュニティプロファイルとして位置付けられている。

Rev.3は、インシデント対応を独立した手順ではなく、組織全体のリスク管理の一部として扱う。この枠組みの六つの機能、統治（Govern）・識別（Identify）・防御（Protect）・検知（Detect）・対応（Respond）・復旧（Recover）に沿って推奨事項を整理した。

Rev.3は、具体的な対応手順は変化が速く組織ごとに異なるため、一つの文書で固定的に示さない方針をとる（NISTの解説）。一方で、試験や多くの教材では、Rev.2の四つのフェーズが基本の型として今も使われる。両者は対立するものではなく、Rev.2が対応の流れ、Rev.3が組織のリスク管理との結び付きを中心に示していると考えるとよい。

被害の拡大を止める判断

封じ込めは、被害がそれ以上広がらないようにする措置である。原因を完全に取り除く前に、まず被害の拡大を止めることを優先する。

どの方法を選ぶかは、技術だけでは決まらない。Rev.2は措置の方法を選ぶ観点として、被害の大きさ、証拠を保全する必要性、サービスの可用性、必要な時間と資源、効果、措置の継続期間などを挙げている。

措置の時期にも判断が要る。攻撃者の活動範囲を把握しないまま一部の端末だけを遮断すると、攻撃者が異変に気付き、別の侵入経路を使ったり痕跡を消したりすることがある。被害が進行中なら即座に止めるべきだが、調査で全体像をつかんでから一斉に措置する判断もあり得る。誰がこの判断を下すかを、事前に権限として定めておく。

証拠の保全

原因を調べるにも、後で法的な手続をとるにも、証拠が必要になる。対応を急ぐあまり、証拠を壊さないよう注意する。

コンピュータ上の情報は、失われやすさが異なる。証拠は揮発性の高いものから順に集めるのが原則である（RFC 3227）。

この順序から分かるように、感染が疑われる端末の電源をすぐに切ると、メモリ上にしかない攻撃プログラムや通信先の情報が失われる。ネットワークから切り離して電源は入れたままにする、という対応がよく勧められるのはこのためである。ただし暗号化を進めるランサムウェアのように、動かし続けるほど被害が増える場合もある。状況に応じた判断基準を手順書に定めておく。

集めた証拠は、ハッシュ値を記録して改変されていないことを示す。誰がいつ受け取り、どう扱ったかを記録するChain of Custody（証拠の保管の連鎖）も残す。詳しい手法はデジタルフォレンジックスで扱う。

原因の除去と復旧

根絶は、インシデントの原因を取り除く作業である。マルウェアを削除するだけでは足りない。侵入に使われた脆弱性の修正、盗まれた可能性のあるパスワードの変更、攻撃者が作ったアカウントや設定の削除まで行う。侵入口をふさがずに復旧すると、同じ手口で再び侵入される。

復旧は、システムを正常な状態に戻して業務を再開する作業である。感染した端末は、マルウェアを除去するよりも、OSを再インストールする方が確実なことが多い。データは感染前の正常なバックアップから戻す。ランサムウェアはネットワーク上の保存先まで暗号化することがあるため、オフラインや変更できない形での保管が重要になる。

復旧後は、しばらく監視を強化する。攻撃者が別の経路を残していれば、再び同じ兆候が現れる。

事後の活動と報告

解決後は、何が起き、対応のどこがうまくいき、どこに問題があったかを振り返る。検知が遅れた理由、連絡が滞った場面、手順書になかった判断などを洗い出し、対策と手順に反映する。これが再発防止の中心である。

外部への報告が必要な場合もある。日本では、改正された個人情報保護法が2022年4月に施行され、一定の個人データの漏えい等が起きた場合に個人情報保護委員会への報告と本人への通知が義務となった。業種によっては、監督官庁への報告が求められる。報告の期限と判断者を手順書に定めておく。

関係者と連携先

JPCERT/CCは、国内外の組織間でインシデントの調整を行う。自組織が攻撃の踏み台にされた場合など、相手先の組織と連絡をとる必要があるときの窓口になる。

対応の例

次は、ランサムウェアへの対応の独自例である。

この例では、目の前のPCだけでなく、侵入口となったVPN装置まで突き止めている。被害を受けた端末を直すだけで終えると、同じ入口から再び侵入される。

よくある誤りと設計上の注意

ハンドリングの速さは、事件が起きる前の準備で決まる。手順書と連絡体制を整え、ログを十分な期間保存し、機器の時刻をNTPでそろえる。定期的な訓練で手順の不備を見つけておく。

午後での問われ方

• インシデントの経過を示し、封じ込め・根絶・復旧のどの段階の作業かを区別させる。
• 感染が疑われる端末について、電源を切らずにネットワークから切り離す理由を説明させる。
• 端末を復旧しただけでは不十分な理由を、侵入経路と関連付けて説明させる。
• 複数のログから侵入の起点と影響範囲を特定させ、時刻同期やログの保存期間の重要性を問う。
• CSIRT・SOC・運用担当などの役割分担や、判断の権限を問う。
• 再発防止策として、手順書や監視の何を改善すべきかを考えさせる。

この用語が出てくる記事

• EDR
• CSIRT
• SOC
• ハクティビスト