私はTrustwaveSpiderLabsResearchTeamのModSecurityプロジェクトリーダーです。2つのルールセットを比較し、アプリケーションのセットアップと必要なセキュリティのニーズに応じてどちらが「優れている」かを尋ねる場合。これはeコマースサイトだとおっしゃいました。osCommerceなどの公開ソフトウェアを使用していますか?
Trustwaveの商用ModSecurityルールには、いくつかの一般的な利点があります。
ルールは、ModSecurityコードを開発するTrustwave SpiderLabs Research Teamによって作成され、ルールの精度のエラーが低くなります(GotRootの問題については以下のデータを参照してください)。
SpiderLabs Research Teamは、ルールを改善するために、ルールに対して広範なテストと調査を実施しています。最近のSQLインジェクションチャレンジをご覧ください-http://blog.spiderlabs.com/2011/07/modsecurity-sql-injection-challenge-lessons-learned.html
ルールは、単独で使用することも、OWASP ModSecurityコアルールセット(同じTrustwave SpiderLabs Research Teamによって管理されている)と統合して使用することもできます。これにより、展開の柔軟性が高まり、攻撃ペイロードの共同検出が行われるため、精度も向上します。その結果、フォールスネガティブ(攻撃の失敗)の可能性が低くなります。
Trustwaveルールは、攻撃タイプまたはアプリケーションタイプの方法論を使用して適用できます。たとえば、osCommerceサイトを実行している場合、その特定のアプリケーション専用の仮想パッチを含むパッケージ化されたルールセットがあります。このアプローチの利点は、数百または数千の不要なルールを実行するのではなく、環境に適用できるルールのみをアクティブ化することです。このアプローチの追加の利点は、リクエストの処理時間/レイテンシーが削減されることです。
Trustwave仮想パッチには、OSVDBなどのサードパーティの脆弱性データへのhttpリンクを含むメタデータも含まれています。
GotRootルール自体に関しては、偽陰性の問題が発生した場合に発生する可能性のある公開遅延ルールを確認した後、私が見つけた精度の問題がいくつかあります。主な問題は、変換関数の不適切な使用にあります。変換関数(例t:base64Decode)は、演算子を適用する前にデータを正規化するために使用されます。悪意のあるデータが存在する場合でも、オペレーターが決して一致しない方法でデータを変更する不適切な変換関数を適用する多くのGotRootルールがあります。これは、これらの精度がテストされていないことを示しています。
この情報がお役に立てば幸いです。