LinuxでのSIEM監査のログ情報
Linuxによって生成されたすべてのタイプのイベントを知るにはどうすればよいですか。これはログから取得できますが、ログの読み取りとIDの記録には非常に時間がかかります。すべてのイベントがトリガーされるとは限りません。
SIEM監査にこの情報が必要です。この情報を入手できるソースはありますか？
監査は広義の用語であり、SIEMが期待どおりに動作していることを監査したり、詳細な使用統計を提供するレポートを生成したりすることを意味します。 （それ以外にも多くの他のことを意味する可能性があります）
SIEMはデータソースと同じくらい優れているだけなので、最初に確認する必要があります。多数の定義済みのユースケースがあることを確認します。たとえば、低レベルのユースケースは、Sudoを使用したり、cronにジョブを追加したりする通常のユーザーアカウントである可能性があります。
1つは、ログが記録されていることを確認するために必要なユースケースのコレクションです。 Linuxは、デフォルトですべてのアクションをログに記録するわけではありません。デフォルトでログを記録する場合でも、SIEMへのコネクターが未加工のログを受信していることを確認する必要があります。 Linuxシステムと使用する方法によって異なりますが、最近見た最も一般的なセットアップでは、通常、rsyslogとauditdを使用します。
SIEMコネクターによって生データが収集されたら、生ログが正しく解析および正規化されていることを確認する必要があります。これは、以前に正しく構成されていないため、後で問題が発生する可能性があります。標準のsyslogコネクタは、正規化プロセスの基礎を形成する可能性がありますが、収集されるログと、ログの形式によっては、おそらくある程度の調整が必要になります。
これが行われると、イベントがログによってSIEMで生成されていることを確認する必要があります。すべて問題なければ、SIEMソリューションでフィルター可能なイベントのストリームが表示されます。これは、イベントがユースケースに一致することを意味する必要はありません。次に行う必要があるのは、各ユースケースのルールを作成することです。たとえば、通常のユーザーがSudoを使用するたびにルールが実行されるようにすることができます。
次の段階はテストです。ルールをトリガーする何かを行う必要があり、多くの事務処理を伴うか、まったく不可能であるほとんどの本番サーバーでは、テストが難しい場合があります。これは、システムをイベントでいっぱいにするテストシステムまたはリプレイファイルを使用する必要があることを意味します。ルールとアクションをトリガーするアクティビティを意図的に実行するように構成できます。このアクションは、他のイベントとの相関、アラートまたはキーをこの質問フィードに直接送信して、監査用のレポートまたはクエリに直接送ることができます。
さらに、ユースケースを実行してログエントリを生成しようとするスクリプトを記述できます。これにより、生のログからSIEMルールまでのプロセス全体がテストされます。 （幸運にも、このようなスクリプトを本番サーバーに取り込むことはできます）
各ユースケースが必要なルール/アクションをトリガーしていることを十分にテストしたら、セキュリティの問題ではないイベントのチューニングを開始できます。たとえば、一部の通常のユーザーがSudoコマンドに正当なアクセス権を持っている可能性があります。 Sudoを使用するたびにルールを実行する必要はありません。
SIEMの優れた点の1つは、レポートが組み込まれているため、一般に監査が非常に簡単なことです。ユースケースごとに一連のレポートを構成できます。これらは、ルールが実行された回数、実行された回数、実行されたアクションなどをカウントできます。ルールを実行したかどうかに関係なく、さらに掘り下げてすべてのイベントを監査できます。本当にSIEMを使用してセキュリティイベントのレポートを作成する必要がありますが、想像力やコンピューティングリソースによってのみ制限されます。
これらのレポートは、詳細な統計分析または一般的な集計データを提供するように構成できます。もう一度、見たいものを決める必要があります。たとえば、特定の規制に準拠していることを証明する必要がありますか？もし、そうなら;規制を目立たない証明可能な目標に分解し、それぞれに基づいてレポートを生成します。このプロセスは、環境ごとに、また準拠する必要がある規制ごとに異なります。
SIEMは成熟するのに時間がかかります。それは、獣の性質であり、物事は、調整、テスト、およびレポートの継続により、時間とともに改善する必要があります.
非常に注意する必要があることの1つは、自分自身を対象範囲外にすることではありません。非常にタイトなルールセットを作成して、盲点になり、環境内の悪意のあるアクティビティや異常なアクティビティを見逃してしまう可能性があります。これはレポートには含まれません。お手伝いします。
TL：DR
- データソースが正しく構成されていることを確認してください。つまり、正しいログが正しい場所に転送されています。
- SIEMがデータを正しく認識していることを確認します。
- すべてのルールをテストして調整します。
- 固有の監査ニーズに基づいてSIEM内でレポートを構成します。つまり、レギュレーション/監査要求/環境/ SIEMの各セットは、レポートおよび監査フェーズに対して個別の構成を必要とします。
- これに加えて、予想されるイベントのベースラインとこのSIEMの成熟度が確立されるまでに時間がかかります。
これを行う方法の詳細についての情報源を見つけるのは難しい場合があります。ほとんどのエンタープライズクラスのSIEMソリューションは適切な製品であり、顧客がベンダーに直接行ってサポートを求めている場合、文献はかなり厳重に保護されています。オンラインについてはいくつかのリソースが点在していますが、一般的に私は情報の質が低く、多くの場合古くなっています。
SANSには、成功したSIEMおよび監査とコンプライアンスのためのログ管理戦略と呼ばれる論文があり、PDF format here。
オセックを見てください。これは、複数のクライアントで異なるログを監視するように構成できる監視システムです。ルールは、アクティブな応答と電子メールのログに対して定義できます。それは無料でオープンソースです。