ディフェンシブ・セキュリティ・ハンドブック第2版

第6章. インシデントレスポンス

この作品はAIを使って翻訳されている。ご意見、ご感想をお待ちしている：[e-mail]

インシデントレスポンスとは、その名前が示すように、セキュリティインシデントが宣言された時点で初期化される一連のプロセスと手順のことである。しかし、現代のコンピューティングでは、インシデントは、侵害された単一のエンドポイントから、大規模なデータ侵害につながる完全なネットワーク侵害まで、さまざまな場合がある。加えて、データ漏洩や企業規模の攻撃はますます一般的になっているため、インシデントレスポンスは、単にこれらのプロセスや手順を超えて、情報セキュリティの分野全体を包含する意味に拡大している。

この章では、インシデントレスポンスに関わる様々なプロセス、ツールやテクノロジーの選択肢、およびインシデント発生時に実行する必要がある可能性が高い、最も一般的な技術的分析の形態について説明する。

プロセス

インシデント・レスポンス・プロセスは、インシデント発生時の迅速な対応、非インシデントの特定、インシデント発生時の効率的な演算子、インシデント発生後の改善を可能にするために不可欠な要素である。インシデントが発生する前にプロセスを整備しておくことは、長期的には大きな利益をもたらす。

インシデント発生前のプロセス

インシデントレスポンスに関連するプロセスは、単にインシデント発生中に何が起こるかに 関わるものではない。インシデントが発生していることを認識し、インシデントレスポンス・プロセスを初期化し、インシデントレスポンスの責任者に通知するプロセスがない場合、インシデントに対処するプロセスがあっても、呼び出されることはないため、ほとんど意味がない。

インシデント発生前のプロセスは複雑である必要はない。これらのプロセスの点は、単にインシデントの可能性があるかどうかを判断し、インシデント・レスポンス・プロセスを開始すること、それだけである！

社内のインシデントレスポンスについて何度も反復してきた経験から、私たちが協力した最も効果的なプロセスは次のようなものだと言える：

イベントに対処するための既存のプロセスを活用する。

ほとんどの組織は、障害、設定の問題、ユーザから報告された問題、その他の事象に、対応している。並行して一連のプロセスを設定しようとせず、すでにあるものを活用する。おそらく、これらの問題に対処する同じ担当者が、いずれにせよインシデントの発生を最初に知ることになるだろう。Linuxホストが夜中に故障したときにオンコールのUnix担当者を呼び出すようにすでに規定されているのと同じように、予想されるインシデントが発生したときにインシデントレスポンスの担当者を呼び出すように、既存のプロセスを変更または補足するだけでよい。

インシデントとは何かを定義する。

何をインシデントとして分類するか（）を定義しておかないと、サポートコールのたびに呼び出しを受けたり、400万件のデータレコードが流出したときに呼び出しを受けなかったりするリスクがある。インシデントとは何かを定義するのが簡単でない場合は、「管理者がイベントをセキュリ ティインシデントと判断したら......」というような表現を選ぶことができる。こうすることで、どのような事象であっても、第一線のサポートによるトリアージを超えてすでに進行しており、判断を下すのに十分な経験を積んだ者が判断を下していることを、少なくとも定義することができる。