セキュリティインシデント対応#2

セキュリティインシデントへの対応について前回の続きをお話しします。
今回は「封じ込め～教訓」までとなります。

3. 封じ込め

封じ込めの目的は、自システム内への攻撃者の行動を止めることです。
「封じ込め」をするにあたり、「識別」のプロセスの中でスコーピング（被害範囲の特定）が出来ていないと封じ込めはできないので、「識別」のプロセスは正確に実施しましょう。

封じ込めをするにあたっての対応例は以下の通りです。
・端末のNW隔離（EDRなどを使用）
・パッチの適用
・悪意のあるプロセスを停止（killコマンドなどを実施）
・バックドアアカウントの停止、削除
・ルータやFWに対してフィルタリング（Black List登録などを実施）
・DNSエントリの変更（システムを変えずに攻撃者のアクセスを拒否）

4. 根絶

「根絶」の段階では、攻撃者が残したものを駆除することにフォーカスします。

例えば、脆弱性診断を行い、今回の攻撃の原因となったセキュリティホールを無くすことが有効です。その他にも「封じ込め」のフェーズで行った、悪意のあるプロセスの停止、バックドアアカウントの削除も徹底的に実施することも有効な手の一つです。

5. 復旧

業務活動を正常に戻すための行動をする必要があります。
大抵の場合、システムの再構築をしたほうがコストパフォーマンスが高い場合が多いです。また、バックアップをしている場合は、バックアップからの復旧も大事です。
例えば、以下のようなサービスを使ってバックアップを実施します。
Tape Backup Software | Server Backup Software | Arcserve

復旧のフェーズで気を付けることは、以下2点です。
・システムの再構築をする際には、業務時間外に戻す
（業務時間中は、「封じ込め」にフォーカス。）
・セキュリティ責任者の指示に従う
（この手の「復旧」の権限は、担当者レベルではなく、CISOなどの情報セキュリティの総責任者が権限を持っている場合が多いです。）

その他には、BCP対策の訓練を定期的に実施し、バックアップの手順を理解しておくことも重要です。

6. 教訓

「教訓」のフェーズにおいては、セキュリティインシデントが起きてしまった根本原因の特定が重要となります。

例えば、以下のようなものが原因でセキュリティインシデントの発生が起きます。
・社員の教育が不足していた
・社内セキュリティポリシーが十分なものではなかった
（弱いパスワード設定が出来てしまうなど）
・システムの監視、運用ができていなかった
（ログの監視をしていない、パッチあてやOSバージョンアップをしていないなど）

セキュリティインシデントの原因を突き止めましたら、
報告書の作成を行い、情報共有をする必要があります。
報告書のクオリティに差が生まれないよう、事前に報告書のフォーマットは決めておいたほうが良いですね。

報告書を作成することで、社内への情報共有も実施しやすくなり、同様のインシデントの予防や、数ヶ月後に報告書で記載した改善策に基づき社内の対応が改善したのか指標を立てやすくなります。