Sigmaルールの概要

Sigmaは、ログデータに対する検知ルールを汎用的な形式で記述できるオープンなシグネチャフォーマットです。セキュリティコミュニティで検知手法を共有することを目的としており、YAML形式で記述されるため比較的容易に読み書きできます。アナリストや開発者は、Sigmaを使うことでさまざまな攻撃を検出するルールを標準化された形式で作成できます。

最大の特徴は変換の柔軟性にあります。汎用的に記述したSigmaルールを、対応するSIEMやログ分析ツールのクエリに変換することで、同じ検知ロジックを異なるプラットフォーム上で再利用できます。

SQLインジェクションの脅威と検知の難しさ

SQLインジェクションはWebアプリケーションを対象とした代表的な攻撃手法です。攻撃者は入力値にSQL断片を含めることで、データベースからの情報漏洩、データ改ざん、場合によってはサーバの完全な奪取を狙います。実際の検知では以下のような困難があります。

• 攻撃パターンが多岐にわたり、単一のルールでは網羅しきれない
• 正規の業務操作と悪意のある入力の境界が曖昧になりやすい
• 大量のログから攻撃パターンを正確に検出する負荷が高い

Sigmaルールは柔軟な検知機構を提供することで、これらの課題に対処し、効果的なSQLインジェクション検知を実現します。

Sigmaルールの基本構造

SigmaルールはYAMLで記述され、主に以下の要素で構成されます。

• metadata：タイトル、ID、ステータス、説明など
• logsource：ルールが適用されるログの種類と取得元
• detection：検知条件やマッチパターンの定義
• その他情報：タグ、参考文献、誤報情報など

以下は、データベースエラーメッセージを監視してSQLインジェクションの兆候を検出するルールの例です。

title: Abnormal SQL Error Indicators
id: 4f2e1b5c-9c8d-44a3-b7e1-6d5f3a2c9e08
status: test
description: Detects database error messages potentially caused by SQL injection probes
logsource:
    category: application
    product: sql
detection:
    indicators:
        - "quoted string not properly terminated"
        - "You have an error in your SQL syntax"
        - "Unclosed quotation mark"
        - "near '*': syntax error"
        - "SELECTs to the left and right of UNION"
    condition: indicators
falsepositives:
    - Syntax errors caused by empty IN() clauses
level: high

このルールは、Oracle、MySQL、SQL Server、SQLiteなどで確認される典型的なSQLエラーメッセージを検知対象としています。データベースの種類に応じてエラーメッセージが異なるため、複数のパターンをまとめて監視することで、注入試行の早期発見を目指します。

効果的なSQLインジェクション検知ルールの構築手順

1. ログソースとフィールドの確認

検知ルールの精度は、ログの質と取得項目に大きく依存します。SQLインjection検知では、アプリケーションログ、Webサーバアクセスログ、データベース監査ログなどが主な対象です。Sigmaルールではlogsourceセクションで対象を指定します。

logsource:
    category: application
    product: sql
    definition: 'Requirements: application error logs must be collected (with LOG_LEVEL ERROR and above)'

取得するログには、エラーッセージ、リクエストパラメータ、クライアントIP、HTTPメソッド、リクエストパスなどが含まれている必要があります。

2. SQLインジェクションの特徴を識別する

SQLインジェクションには複数の種類があり、それぞれに対応した特徴を捉える必要があります。

• エラーベース：データベースエラーを発生させて情報を収集
• ブーリアンベースブラインド：True/Falseの応答差を利用
• タイムベースブラインド：意図的な遅延で成功有無を判断
• UNIONベース：UNION SELECTを使ってデータを取得

たとえば、UNIONベースではUNION SELECTのような文字列が出現し、エラーベースでは前述のデータベースエラーメッセージが発生します。

3. 検知ロジックの記述

detectionセクションで条件を定義します。以下に、代表的な3つの検知パターンを示します。

エラーメッセージの検知

detection:
    indicators:
        - "quoted string not properly terminated"
        - "You have an error in your SQL syntax"
        - "Unclosed quotation mark"
        - "near '*': syntax error"
    condition: indicators

SQLキーワードの検知

detection:
    payload_match:
        request-query|contains:
            - "UNION SELECT"
            - "OR 1=1"
            - "AND 1=1"
            - "EXEC("
            - "xp_cmdshell"
            - "benchmark("
    condition: payload_match

異常リクエストパターンの検知

detection:
    target_requests:
        method: "POST"
        path|endswith:
            - ".php"
            - ".asp"
            - ".aspx"
            - ".jsp"
    suspicious_chars:
        request-query|contains:
            - "'"
            - "\""
            - ";"
            - ")"
            - "("
            - " OR "
            - " AND "
    condition: target_requests and suspicious_chars

4. 報の削減

SQLインジェクション検知では、正規の入力や検索クエリに含まれる記号やキーワードが誤報を生むことがあります。falsepositivesセクションで想定される誤報を記録し、実際の運用で参照できるようにしておきます。

falsepositives:
    - Empty IN() clauses in safe queries can produce MySQL syntax errors
    - Search forms or comment fields that legitimately contain quotes and SQL-like words

さらに、静的リソースリクエストの除外、特定のパスやユーザエージェントの除外、閾値の追加などにより、検知精度を高めることができます。

実践例：Webアクセスログに対する検知ルール

Webサーバのアクセスログを対象に、URLパラメータに含まれる疑わしいパターンを検知するルールを作成します。静的リソースへのリクエストを除外することで、誤報を抑えます。

title: Suspicious SQL Payloads in Access Logs
id: 7a1d9f4e-3c2b-41e8-9f6d-2e4b8c5a1d09
status: test
description: Detects suspicious SQL fragments in query strings of web access logs
logsource:
    category: webserver
    product: apache
detection:
    suspicious_query:
        method: "GET"
        query-string|contains:
            - "'"
            - "\""
            - ";"
            - " OR "
            - " AND "
            - " UNION "
            - " SELECT "
            - " INSERT "
            - " UPDATE "
            - " DELETE "
            - " DROP "
    static_filter:
        query-string|contains:
            - ".css"
            - ".js"
            - ".jpg"
            - ".png"
            - ".gif"
    condition: suspicious_query and not static_filter
falsepositives:
    - Legitimate URL parameters containing SQL-related terms in search or filter forms
level: medium

Sigmaルールの利活用ポイント

クロスプラットフォーム対応

Sigmaルールは、Elastic/Splunk/IBM QRadar等、複数のSIEM向けクエリに変換できます。同じ検知ロジックを環境に合わせて展開できるため、ルールの重複作成や管理コストを削減できます。

コミュニティ資産の活用

Sigmaのプロジェクトリポジトリには、SQLインジェクションを含む多くの検知ルールが公開されています。既存のルールを参考に改変したり、自組織の環境に合わせてカスタマイズしたりすることで、ルール作成の効率が向上します。

継続的な更新

攻撃者の回避手法は日々進化するため、ルールも継続的に見直す必要があります。新たなSQLインジェクション技法やCVE情報を反映し、定期的にチューニングを行うことが重要です。

Sigmaルールを使ったSQLインジェクション検知の始め方

1. ツールの準備：Sigmaのリポジトリを取得し、sigmacなどの変換ツールをセットアップします。
2. 既存ルールの調査：rules/ディレクトリ配下のSQL関連ルールを確認し、検知パターンを理解します。
3. ログ収集の整備：アプリケーション・Webサーバ・データベースのログを、十分な詳細度で収集できるよう設定します。
4. ルールの変換：使用しているSIEM向けにSigmaルールを変換します。
5. 検証と運用：テスト環境で検知動作を確認し、誤報と検漏を抑えながら本番に展開します。
6. 継続的な最適化：実際のアラート傾向を分析し、ルールを定期的に調整します。