サーバー感染：クリーンアップ後のベストプラクティス
私は 侵害されたサーバーにどのように対処しますか？ を読み、将来の損傷をクリーンアップ/軽減するための手順に従いました。
次のような「ベストプラクティス」と見なされるクリーンアップ後の手順があるかどうか疑問に思っています。
- 顧客に感染を知らせて片付けます
- シェル/感染ファイルをセキュリティ会社に提出する
- 使用されたエクスプロイトの詳細をセキュリティ会社に報告する
- 攻撃しているIPアドレスの調査/報告
この情報のどれかが彼らにとって役立つかどうかはわかりませんので、現在、私は細心の注意を払って記録を取っています。
この質問は、「ベストプラクティス」の観点から非常に意見が分かれる可能性があります。
ただし、顧客への通知または法医学調査のために、特定の業界/契約または法的要件がある場合があります。最適な対応を得るには、特定の事件に固有の弁護士の指導を求める必要があります。一般的な意味で、あなたはすべきことは正しいことをし、顧客/ユーザーの最善の利益のために行うべきですが、あなたがビジネスを運営しているなら、あなたはそれと 継続企業の前提 を持ちたいというあなたの願望とのバランスを取るために。
開始するのに適した一般的な場所は、 NIST SP 800-61： "Computer Security Incident Handling Guide" です。また、 SP 800-86：「フォレンジック手法をインシデント対応に統合するためのガイド」 。
CERT/SANS/etcリソースもいくつかあります。
- Cert Publications （例： コンピュータセキュリティインシデントレスポンスチーム向けハンドブック ）
- ビジネスパーソンの簡単なガイダンス
- SANS閲覧室：インシデントハンドラーハンドブック
法律および業界の要件に関する参考資料（米国固有の例）：
- GLBA（金融業界）： FDIC FIL-27-2005ガイダンス 、 FTCガイダンス
- HIPAA（ヘルスケア）： 違反通知ルールに関するHHSガイダンス
- PCI（クレジットカード）： VISAガイダンス （ 追加 ）、 PCI違反対応に関するSANSペーパー（意見/調査）
- カリフォルニア違反通知法： 法的要件（1798.82に進みます。（a））
この Congressional Research Serviceによるレポート は、いくつかの米国連邦法の要約も提供します。この Berkley Law Paper は、米国連邦法にとっても興味深いかもしれません。
私はあなたの質問に可能な限り答えようとします。
顧客に感染を知らせて片付けます
SLAが必要であるか、コンプライアンスに拘束されていない限り、お客様に通知しません。多くの場合、これはビジネス関係者によるパニックを引き起こします。PIIが失われた場合は、最善の利益になる可能性があります。 。
使用されたエクスプロイトの詳細をセキュリティ会社に報告するセキュリティ会社にシェル/感染ファイルを提出する
ファイルをVirus Total（virustotal.com）に送信できます。これは多くの場合AVベンダーに配布されており、他のベンダーからすでに送信されているかどうかを確認できます。通常、ベンダーが必要とするものはすべて、提出する実行可能ファイルに含まれています。
攻撃IPアドレスの調査/報告
IPアドレスの詳細をベンダーに送信できます。私はマカフィーの経験に精通しており、マカフィーのレピュテーションエンジンはTrusted Source（trustedsource.org）であり、フィードバックを送信できます。
細心の注意を払った記録管理はあなたの最大の利益です。ドキュメントを使用して、セキュリティとインシデントレスポンスに関する追加のポリシーの正当化と構築を支援します。確かにこれはあなたが違反する最後の時間ではありませんが（あなたに対して何かはありませんが、それはまさにそれです）構築できる特定のプロセスは、人々が最初の対応者の頭を明確に保ち、彼らに取る方向を与えるのに役立ちます。これを開始するには、インシデント対応レポートのテンプレートを検索してください。
私が働いたすべての場所（公共およびF100民間部門）で、事故後の行動の最も貴重な部分は報告です。 Hindsightは20/20であり、あなたとあなたのチームが発見されたすべての詳細と症状を理解することが重要です。このようなインシデントやサービスへの影響を処理するためのセキュリティ体制とプロセスをよりよく理解するには、これらのポイントを使用する必要があります。違反が発生した場合、ビジネスの意思決定者は巾着でより緩くなるため、これはアーキテクチャを確認するのに最適な時期でもあります。セキュリティインシデントがない場合、セキュリティは見落とされたり、ビジネス費用としてのみ見られたりして、ビジネスの利益率に利益をもたらさないことがよくあります。
基本的に、インシデント処理のベストプラクティスについて尋ねていますが、本質的には、インシデントをすでに処理した後の「適用後」です。私の知る限り、あなたが提示した特定の質問に基づいて、あなたの組織が「学んだ教訓」フェーズを投稿するために必要なことに対するクッキーカッターのアプローチはありません。それは本当にあなたが法的に責任があるか、単に単に喜んで/したいのかという問題です。貴重な知的財産が関与していた場合、それは潜在的にワームの缶を開けます。同様に、法執行機関に連絡することをあなたに要求する特定の「もの」があります。など。誰もがポイントを得ると思います。インシデントの種類（IP攻撃と盗難、DoS、マルウェア、嫌がらせやフィッシングなどの電子メール、スパイ行為、不正使用などのポリシー違反、違法な活動、カジュアルな非破壊から意図的な破壊などのインサイダー脅威など）を特徴付け、範囲を決定する被害とその後の適切な関係者への連絡は、封じ込め段階で行われるべきすべてのものです。これは、分類を支援するリソースです。 CSIRTケース分類文書
さて、あなたはすでに識別、封じ込め、根絶、および回復を経験しているようであり、攻撃者の復帰を注意深く監視している、あるいは注意深く監視していると思いますか？それでは、標準的な「本による」インシデント処理のフェーズ6で一般的にベストプラクティスと見なされているものについて見ていきましょう。多くの組織/人々は「時間がない」か、このフェーズを本当に通過するのに面倒ですが、それに直面することができます。攻撃者は常に改善しているので、改善する必要もあります。先に進んで新しい間違いを犯す時が来ましたが、このプロセスの全体的なポイントは、同じ古いものを繰り返さないようにすることです。ここですべきことは、何が起こったのか、そしてそれと同様の事件が再び起こらないように運用能力をどのように改善できるかを文書化することです。そのための1つの方法は、フォローアップレポートを作成することです。理想的には、回復後すぐにこのレポートを開始する必要があります。 SANS Instituteは、このプロセスで使用できるいくつかの 便利なインシデントフォーム を提供しています。一般に、影響を受けるすべての関係者にドラフトのレビューを促すことをお勧めします。レポートを確認したら、可能であれば「教訓」会議をスケジュールします。理想的には、この会議は、イベントがまだ全員の記憶に「新鮮」である間に、制作を再開してから1〜2週間以内に開催される必要があります。一般に、会議の主な目的は、インシデントレポートのエグゼクティブサマリーについてコンセンサスを得ることです。エグゼクティブサマリーの鍵となるIMOは、効果的なインシデント処理手順を実施することの重要性を示しています。
また、事件処理の「七つの大罪」を調べてください。あなたはそれが役に立つと思うかもしれません。