これはインシデント対応を管理するための良い方法ですか
インシデントに対処する良い方法を見つけようとしています。今のところ、これらは私の考えです：
xログに参加し、splunkで分析します（rsyslogで警告します、splunkは高すぎる）
x構成管理と自動再配置（パペット、カピストラーノ）、
xファイルシステムマウントによるフォレンジック（クリーンなハッシュデータベースと比較）、ルートキットのメモリダンプの分析（volatilitux）...
私はいくつかのコメントを本当に感謝します、それは私を改善するのに役立ちます。
これが完全なプロセスであり、他の決定が既に行われているサブセットではない場合、最初の決定ポイントは侵入の有無ではなく、ビジネスサービスに影響があるかどうかであることをお勧めします。
アラート->ログの確認->ビジネスサービスへの影響？
ビジネスサービスへの影響を確認したら、それを使用してインシデントレスポンスの残りの部分を推進できます。サービスに影響がある場合は、ビジネスの正しい担当者（既に文書化されているはずです）を関与させて影響を通知し、問題の早期概要を提供する必要があります。
ビジネスサービスへの影響？ ->はい->ビジネスインシデントマネージャーに通知
ビジネスに通知されたら、問題の正確な性質を判別し、残りのプロセスフローを処理することに進むことができます。
ビジネスサービスに影響がない場合でも、問題判別に移ります。
ビジネスサービスへの影響->いいえ->侵入？
次のポイントは、イベントが侵入ではない場合でも、結果としてアクションを実行したい（または必要な）セキュリティイベントである可能性があるということです。
たとえば、Webアプリケーションの何らかの形の自動または手動スキャンを検出します。攻撃者のIPアドレスをブロックしたい場合があります。これは単なる1つの例です。
このような決定には、適切なビジネスまたはテクノロジーの代表者からの承認が必要な場合があるため、ビジネスへの必要なフックをプロセスフローに反映する必要があります。
要約すると、私のフィードバックのポイントは次のとおりです。
ビジネスアプリケーションを防御していることを忘れないでください。インシデント対応プロセスが、必要な技術手順だけでなく、ビジネスのニーズを反映していることを確認してください。
侵入は明らかに最悪のケースですが、他のセキュリティ関連のイベントに必要なアクションを軽視しないでください。それは単に設定ミスではないかもしれません。
HTH !!
OSSIMにはOSSECがあります。 OSSECは、ファイルの整合性の監視とsyslogの管理に加えて、mod-security、Wordpress、MySQL UDFロギングインターフェイスなどで使用できます。
Novell Sentinel Log Manager 25とQ1Labs QRadar Log Managerに 無料でダウンロード可能なオプション がある場合、Splunkの必要性や要望が理解できません。より良い（特に価格について）。 Splunkは高すぎることに同意します。
原則はシンプルであり、あなたが概説したとおりです。
- リモートロギング。遅延ロギングではなく、リアルタイム。 rsyslogはうまく機能します。完璧主義者として、私は最初にファイルにログを記録するのではなく、ソースからログを直接キャプチャして送信し、rsyslogによってログを取得するようにします。
- ファイルの整合性の監視を含めます。この分野ではOSSECは優れていますが、私は自分のOSSECを使用しています。
- ライブ分析。私はMozDef（Mozilla防御プラットフォーム）を使用しています。 OSSIMは独自性があり、制限が厳しすぎました（しばらくすると、OSSIMの唯一の目的は有料製品を宣伝することであると感じました）。初めての場合は、Dockerイメージをお試しください。本番環境で使用するには、コンポーネントがどのように結び付いているかを理解し、自分用のカスタム構成を作成する必要があります。よろしければ、喜んでお手伝いさせていただきます。
- 構成管理はい。
- 自動再デプロイメントお待ちください！ DevOps機能としてはこれは素晴らしいですが、IRに関しては非常に保守的になりたいと考えています。自動化は多くのシナリオをカバーする必要があります。これを行うのは、単純なWebサーバーだけです。それは、実際の生活では、ほとんどすべてのシナリオが私たちが想像して準備していたものとは異なるためです（十分な想像や準備ができていないことを意味することもあります）。
- 自動キャプチャを使用したリモートフォレンジック。自動化されているかどうかは議論の余地がありますが、非常に便利です。非常に厳格に管理された環境がない限り、リスクが多すぎます（私はあまり多くは遭遇していません）。 GRR /同等のものを使用することをお勧めします。ライブフォレンジックの必要性はまれです（私たちの経験）。高価値の資産（銀行/軍事/ ...）を管理している場合を除き、すべてのエンドポイント（サーバーのみを含む）を試して構成するには、これを少しやり過ぎる可能性があります。したがって、これを選択的に行います。