SIEMForge の構築：Sigma、Sysmon、MITRE ATT&CK を備えたポータブル SIEM デテクション ツールキット

複数の SIEM に跨ってデテクションコンテンツを運用しようとして見たことがある人なら、痛みは既に知っていることでしょう。Sigma ルールは 1 つのレポジトリにあるのに、Sysmon 構成は別のところ、Wazuh のカスタムルールは 3 つの局所ファイルに散在しており、MITRE マッピングはスプレッドシートに埋もれた雑学に過ぎません。そのために SIEMForge を構築しました。 SIEMForge は、Sigma ルール、Sysmon 構成、Wazuh カスタムルール（すべて MITRE ATT&CK にマッピングされ）をパッケージ化し、オフラインログスキャン器和複数バックエンドのルール変換機能を備えた、単一の Python ツールキットです。ホームラブからプロダクション SOC まで、ワークフローの変更なしに動作します。 リポジトリ：github.com/TiltedLunar123/SIEMForge 私はセキュリティ専門学生の者ですが、ホームラブ向けのデテクション作成を始めた当初、ツールギャップの存在はすぐに明らかになりました。あらゆるチュートリアルは、Splunk のライセンスを持つか、完全な Elastic スタックを備えていることを前提としています。実際の Sigma エコシステムは素晴らしく、Sigma ルールを実際のログに対して実行させるために SIEM を起動せずに何かを構築する場合、その摩擦は学習の動向を殺し始めます。 私は 3 つのことを望んでいました： 1. Sigma で一度だけデテクションロジックを書き、どこにでも展開する 2. 本番環境に何かも押し込む前に、サンプルログに対してオフラインでルールを検証する 3. MITRE ATT&CK カバー率を一瞥で確認し、ギャップを知る SIEMForge は、私が始めた時に存在していたツールです。 **ログスキャンエンジン**：JSON、JSONL、syslog、CSV ログファイルを示すと、SIEM を必要とせずに Sigma ルールをそれらに適用します。デフォルトで人間読みやすいアラート、パイプする必要がある場合は JSON 出力。 **複数バックエンドルール変換**：1 つの Sigma ルールを Splunk SPL、Elasticsearch Lucene、または Kibana KQL に変換します。ベンダーロックインなし。プラットフォーム変更時にデテクションを再書き込みすることなし。 **MITRE ATT&CK カバー率マトリックス**：バンドルされたすべてのルールは技法でタグ付けされます。1 つのコマンドで、何をカバーしているかを正確に確認できます。 **ルール検証**：デプロイする前に、悪い YAML、壊れたフィールド条件マッピング、不正確な Sigma 文法を発見します。 **Sysmon と Wazuh のバンドル**：プロジェクトには、同じ技法にマッピングされたプロダクション準拠の Sysmon 構成と Wazuh カスタムルールが同梱されています。 私が最も誇りに思うのはオフラインログスキャナーです。これは、何もデプロイすることなく生のログに対してデテクションロジックを検証することを可能にします。概念としては以下のようになります： `python -m siemforge --scan /var/log/sysmon/events.json` 内部では、スキャナーは： - `rules/sigma/` 内のすべての Sigma ルールを読み取り、YAML をルールオブジェクトに解析する - ログファイルを開き、レコードをストリーミング（自動検出：JSON / JSONL / syslog / CSV）する - 各レコードに対して、ルールの検出ブロックを巡回し、フィールド条件ロジックを評価する - 一致があった場合、ルール名、MITRE 技法、一致したログ行を含むアラートを発出する 困難な部分です Sigma の検出文法です。それはワイルドカード、正規表現、contains-all、contains-any、選択グループ間の論理的 AND/OR、否定を支援します。エビュエーターを正しく得るのは、138 テストスイートが主に目的としています。似たものを構築しているなら、それをハードにテストドライブしてください。Null 周縁、大文字小文字感度、リスト対スカラー一致のケースでは、あなたを生き殺すことになります。 以下の Splunk SPL に変換された PowerShell デテクションルールは以下のような外観をしています： `index=windows EventCode=1 CommandLine="*powershell*"`\n`AND (CommandLine="*-ep bypass*" OR CommandLine="*DownloadString*")` この SPL クエリは、以下のような Sigma YAML から来たものです： ``` detection: selection: EventID: 1 CommandLine|contains: 'powershell' suspicious: CommandLine|contains: - '-ep bypass' - 'DownloadString' condition: selection and suspicious ``` 1 つの真実、3 つの SIEM バックエンド。それが全部の目的です。 `git clone https://github.com/TiltedLunar123/SIEMForge.git` `cd SIEMForge` `pip install pyyaml` ログファイルをスキャン： `python -m siemforge --scan samples/suspicious_powershell.json` ルールを変換： `python -m siemforge --convert splunk rules/sigma/proc_creation_suspicious_powershell.yml` MITRE カバー率を印刷： `python -m siemforge --mitre rules/sigma/` v3.1 はテストスイートを拡大し、Windows CI を追加しました

If you've ever tried to stand up detection content across more than one SIEM, you already know the pain. Sigma rules live in one repo, Sysmon config lives in another, your Wazuh custom rules are scattered across three local_rules.xml files, and MITRE mapping is an afterthought buried in a spreadsheet. I built SIEMForge to fix that. SIEMForge is a single Python toolkit that bundles Sigma rules, a Sysmon configuration, and Wazuh custom rules — all mapped to MITRE ATT&CK — with an offline log scanner and a multi-backend rule converter. It runs from a home lab to a production SOC without changing the workflow. Repo: github.com/TiltedLunar123/SIEMForge I'm a cybersecurity student, and when I started building detections for a home lab, the tooling gap became obvious fast. Every tutorial assumed you had a Splunk license or a full Elastic stack. The actual Sigma ecosystem is great, but turning a Sigma rule into something that runs against real logs without spinning up a SIEM is friction that kills learning momentum. I wanted three things: Write detection logic once in Sigma, deploy it anywhere Test rules offline against sample logs before pushing anything to production See MITRE ATT&CK coverage at a glance so I knew where the gaps were SIEMForge is the tool I wished existed when I started. Log Scanner Engine. Point it at a JSON, JSONL, syslog, or CSV log file and it runs your Sigma rules against it — no SIEM required. Human-readable alerts by default, JSON output if you want to pipe it somewhere. Multi-Backend Rule Conversion. Convert one Sigma rule into Splunk SPL, Elasticsearch Lucene, or Kibana KQL. No vendor lock-in, no rewriting detections when you change platforms. MITRE ATT&CK Coverage Matrix. Every bundled rule is tagged with techniques. Run one command and see exactly what you cover. Rule Validation. Catches bad YAML, broken field-condition mappings, and malformed Sigma syntax before you deploy anything. Sysmon + Wazuh bundled. A production-ready Sysmon config and Wazuh custom rules ship with the project, mapped to the same techniques as the Sigma rules. The piece I'm proudest of is the offline log scanner. It lets you validate detection logic against raw logs without deploying anything. Here's how it works conceptually: python -m siemforge --scan /var/log/sysmon/events.json Under the hood, the scanner: Loads every Sigma rule from rules/sigma/ and parses the YAML into a rule object Opens the log file and streams records (auto-detects JSON / JSONL / syslog / CSV) For each record, walks each rule's detection block and evaluates the field-condition logic On a match, emits an alert with the rule name, MITRE technique, and the matching log line The tricky part is Sigma's detection syntax — it supports wildcards, regex, contains-all, contains-any, logical AND/OR between selection groups, and negation. Getting the evaluator right is what the 138-test suite is mostly for. If you're building anything similar, test-drive it hard. Edge cases around null, case sensitivity, and list vs scalar matching will eat you alive otherwise. Here's what a PowerShell detection rule looks like after conversion to Splunk SPL: index=windows EventCode=1 CommandLine="*powershell*" AND (CommandLine="*-ep bypass*" OR CommandLine="*DownloadString*") That SPL query came from a Sigma YAML that looks roughly like: detection: selection: EventID: 1 CommandLine|contains: 'powershell' suspicious: CommandLine|contains: - '-ep bypass' - 'DownloadString' condition: selection and suspicious One source of truth, three SIEM backends. That's the whole point. git clone https://github.com/TiltedLunar123/SIEMForge.git cd SIEMForge pip install pyyaml Scan a log file: python -m siemforge --scan samples/suspicious_powershell.json Convert a rule: python -m siemforge --convert splunk rules/sigma/proc_creation_suspicious_powershell.yml Print MITRE coverage: python -m siemforge --mitre rules/sigma/ v3.1 expanded the test suite, added Windows CI matrix testing, and fixed a Sigma spec edge case around SSH bruteforce detection. Next up: more rules covering cloud attack paths (T1078.004, T1580), a proper detection-as-code pipeline example, and maybe a web UI for the coverage matrix if there's demand. If you're studying blue team, running a home lab, or just want a way to prototype detections without spinning up a full SIEM — clone it, break it, open an issue. Stars help the project surface to more people who'd benefit. Star SIEMForge on GitHub → If you'd build something with it, tell me what rule you'd write first.