過剰なメンバーとサーバーの認証失敗のログを管理する
現在、SIEM環境では、ノイズや実行不可能なアイテムの削減を試みています。毎週受け取る頻度が最も高いアイテムの1つは、過度のメンバーおよびサーバー認証の失敗に基づくレポートです。
全体的なコンセプトは、24時間にわたってホストでの認証に一貫して失敗するアカウントを通知することです。同じ24時間の間に成功したイベントは見られません。多くの場合、発生しているイベントコードと署名/署名IDに基づいて障害のタイプを決定します。
私たちの標準的なプロセスは、アカウントまたはサーバーの所有者に連絡して、過度の失敗の原因を調査してもらうことです。このプロセスは、かなり長く時間がかかる可能性があり、アカウント所有者へのアナリストのコミュニケーションに依存しています。これらのアラートの95％は対処できないか、フォローアップSIEM検索の後に閉じられたと思います。
起こり得るブルートフォース攻撃を回避するために、これらのログを監視します。私の質問です。これらのログを減らすために調整される追加のフィルタリング層またはルールがありますか。
一般的なイベントコード：
4625
4776
また、このような過剰なアカウントを監視および報告するために使用できる別のプロセスがあるかもしれません。現時点では、現在の基準やしきい値を満たすすべてのアカウントに対して、新しい追跡チケットを作成する必要があります。
分析を通じて、障害が本当にブルートフォースであるかどうかをアナリストが判断できる場合は、必要な手順を完了するよりも実行可能であると考えています。それ以外の場合は、これらの過度のエラーを確認し、必要に応じて尊重されたアカウント所有者に転送できます。
その件についての考えは？ありがとうございました！
あなたが言ったように、両方のイベントID（特にID 4625）は非常にうるさいことがあります。しかし、これらのイベントを処理する方法は、私の経験から、以下の提案で改善できます。
まず、目的がプロセスを改善することである場合、SIEMでこれらのイベントをグループ化および管理する方法を確認することをお勧めします（それが何であれ）。実際、各イベントを単一のイベントとして分析すると、時間の浪費と完全な可視性の喪失につながる可能性があります。興味深いのは、イベントをグループ化して（しきい値を使用して）カウントすることです。たとえば、失敗したログイン試行中にソースIP、ユーザー、またはターゲットが表示される時間などです。これは、いくつかの高度なブルートフォースルール/シナリオ/ユースケースを作成することで実行できます。以下に、私が実行し、実装した概念を示します。左側には、調整可能なパラメーターとは別のパラメーターがあり、グループ化するかしないかをグループ化する必要があります。リスクとは、シナリオやユースケースに合わせて調整する必要がある変数にアラートやしきい値を設定した場合のシナリオの重要度レベルを意味します。
エラーコードをグループ化しないことに気づくでしょう。これは、ブルートフォース攻撃中に攻撃者がさまざまな結果を生み出す可能性があると私が考えるためです。ただし、特定のエラー（ロックアウト、無効、期限切れ、存在しないアカウントなど）の特定のユースケースを構築することはできます。
一方、あなたの目的がそれらのイベントの量を減らすことも減らすことである場合、次のアクションを提案できます。
- 特定のアセット（=機密サーバー、DMZサーバー、データベース、ドメインコントローラー、PKIなど）で失敗したログイン試行の優先度を上げる
- 重要なアカウント（例：サービスまたは管理者アカウント）での失敗したログインに焦点を当てる
- ロックアウトポリシーのしきい値を下回るまで、ユーザーアカウントのロックアウトの失敗を無視する
- 障害イベント（ID 4625および4776）をソースマシンで生成されたイベント（ID 4648）と関連付けます。これにより、Pthや横移動攻撃を検出できる場合があります。次の失敗/成功イベントの表を使用して、ソースとターゲット間のリンクを作成し、アナリストの出力を充実させることができます。
障害イベントID 4625をKerberosイベント（ID 4771、4768）と関連付けて、分析者がチェックする必要がある結果を充実させます。
メインユースケースで特定のエラーコードを無視しますが、優先度の低い新しいユースケースを作成します。これらのインシデントは後で確認します。入力として、次の4625のエラーコードの抜粋を提供して、必要なものを除外します。
ですから、この情報の集まりが皆さんのお役に立てば幸いです。ただし、相関関係は、負荷を減らし、誤検知を減らし、可視性を高めるために重要です。