Snortルールとアラートチューニングに関するドキュメント、特に新規ユーザー向け
私はSnortを使い始めました。それにはたくさんあります。 Snortルールのいくつかが実際に何を意味するかについてのより良いドキュメントを探しています-つまり、特定のルールのポップアップに関するアラートがある場合、どのようにそれらに対応する必要がありますか？ Snortのドキュメント、例、およびフォーラムは、私が（まだ）持っていないように見える、多くの難解なネットワークセキュリティ管理者の背景知識を前提としているようです。
たとえば、私はこれを見つけました：
https://www.snort.org/rule-docs/119-
ただし、Snort Webサイトのそのセクションはひどく古くなっていて検索部分が機能せず、関心のあるルールIDの多くを手動で入力すると404がポップアップします。
例、stream5プリプロセッサーの場合：
- https://www.snort.org/rule-docs/129-1 <-これは機能します
- https://www.snort.org/rule-docs/129-12 <-これは404です
2番目の「129：12」には、「連続TCP小さいセグメントがしきい値を超えています」というテキスト記述があります。それはどういう意味ですか？それはどのように問題を示していますか？I私たちのネットワークを調べたところ、許容できるネットワークアクティビティしかありませんでした（私が知ることができます）。Snortがこの特定の問題について非常に詳細なイベント（1分あたり100メッセージ程度）の間、問題は、通過した承認済みトラフィックに追跡されましたイカのプロキシ。
では、これらのメッセージをすべて抑制すればよいのでしょうか。これはSnortを調整する通常の方法ですか？ただノイズを抑えますか？気が狂ってしまいます...これらのメッセージをすべて抑制した場合、このクラスのメッセージが実際に問題を示しているとしたらどうでしょうか。
私はあなたがアイデアを得ることを望みます。
現在、pulldporkを使用してルールセットを組み立てており、threshold.confの抑制ディレクティブを介してノイズの多いルールを抑制しています。
最後に、AWSクラウドで実行中にPCIのIDS要件を満たすための回避策として、Snortを従来とはまったく異なる方法で実行していることを述べておきます。端的に言えば、「エッジ」ボックスとして分類されるすべてのボックスでSnortを実行し、それらのトラフィックをスニッフィングしています。必要に応じて詳細をお知らせしますが、この質問の基本的な要点は変わりません。
ほとんどすべての監視システムで最も基本的な問題の1つが発生しています。適切に生成されたデータを処理し、信号をノイズから分離する方法です。
残念ながら、すべてのリソースとリソースの価値に依存しているため、簡単な答えはありません。
具体的に説明します。小規模で価値の高いネットワークを使用していて、タスクを処理する（有能な）人がたくさんいる場合は、すべてのアラートをオンのままにして、すべてを完全に調査できます。それは明らかに非常に高価であり、正しく処理できるようにするには高度な訓練を受けた人々（そしておそらく非常に賢いソフトウェア）が必要です。
一方、インシデント処理に利用できる人がほとんどいない大規模で価値の低いネットワークを使用している場合は、すべてをログに記録し、別のチャネルを通じてインシデントとして明示的にフラグが付けられている問題のみを調査することを決定できます（ " CEOの電子メールのパスワードを変更したのは誰ですか？」）。インシデントの事後分析にログを使用できるため、IDSは引き続き価値がありますが、プロアクティブに対応することはできません。
ほとんどのネットワークはこれら2つの極端の中間にあるため、実際の脅威レベルと対応能力にできる限り近いアラートを作成する必要があります。これには時間がかかり、プロセスは継続する必要があります。新しい脅威、使用状況の変化、または容量の変化に常に対応するには、ルールを調整する必要があります。