脅威インテリジェンスアグリゲーター

60以上のセキュリティベンダーからのRSSフィードを集約し、AIトリアージを実行し、検出結果をRunZeroの資産インベントリと照合し、ダークモードのWebダッシュボードを通じて実行可能なアラートを表示する、セルフホスト型の脅威インテリジェンスプラットフォームです。

クラウド依存ゼロでスタンドアロンで動作するように構築されており、Azure/Entra/Sentinel環境に完全統合することもできます — お持ちの環境に合ったティアを選択してください。

---

デプロイメントティア

ティア	スクリプト	AIトリアージ	認証	ストレージ	得られるもの
Basic	scripts/setup-basic.sh	オフ	ローカルAPIキー	ローカルPostgres (Docker)	フィード集約、IOC抽出、MITREマトリックス、ダッシュボード — AIなし、クラウドなし、サインアップ不要
Basic + API	scripts/setup-basic-api.sh	Anthropic (直接)	ローカルAPIキー	ローカルPostgres (Docker)	上記すべてに加え、AIによる重大度/TTP/サマリーのトリアージ
Azure + API	scripts/setup-azure.ps1	Azure AI Foundry	Microsoft Entra ID SSO	独自のPostgres (Azure DB for PostgreSQLなど)	Azure Container Appsへの完全デプロイ、ユーザーごとのロールを持つSSO。(detections.aiパイプライン統合は今後のリリースで提供予定 — 以下を参照。)

3つすべてがまったく同じアプリケーションコードを実行します — 変わるのは設定される環境変数のみです。完全なリファレンスについては環境変数を参照してください。```bash

Basic — no AI, no cloud

./scripts/setup-basic.sh

Basic + API — adds direct Anthropic triage

./scripts/setup-basic-api.sh

Azure + API — full SIEM-integrated deployment (PowerShell 7+, az CLI)

./scripts/setup-azure.ps1

2つのbashスクリプトは、ローカルのPostgresコンテナを起動し、スキーマを適用し、`backend/.env` / `frontend/.env.local` を生成します — その後、アプリを実際に起動するための2つのコマンド（`pip install` + バックエンド実行、`npm install` + フロントエンド開発サーバー実行）を表示します。`setup-azure.ps1` は `infra/provision.ps1` の薄いラッパーであり、実際のAzure Container Appsデプロイ手順書です。

---

## 機能

- **フィード集約** — 60以上のTier 1/2/3セキュリティRSSフィードをスケジュールに従ってポーリングし、重複排除とプロモーションコンテンツのフィルタリングを自動で行います
- **AIトリアージ** — 各エントリを重要度（Critical/High/Medium/Low/Informational）、MITRE ATT&CK TTP、平易な英語の要約で分類します。プロバイダーはモジュール式で、Anthropic API直接またはAzure AI Foundryを、機能を損なうことなく1つの環境変数で切り替え可能です
- **IOC抽出** — 各エントリからIP、ドメイン、URL、ファイルハッシュ、CVEを自動抽出します
- **RunZero統合** — 資産インベントリを同期し、脅威インテリジェンスを稼働中の資産と照合します。CVE、ソフトウェア名、OSバージョン、IPアドレスでマッチングします。`RUNZERO` 配下には3つのサブタブがあります: **Matches**（インベントリと照合されたエントリ。重要度/日付/信頼度/KEVでフィルタ可能）、**Exposure**（組織レベルの確定/可能性のある状態と修復トラッキング）、**Metrics**（取り込みと修復の経時的なトレンド）
- **Your Stack** — 環境内のソフトウェア/OSを定義し、すべてのエントリを関連性で再スコアリングします
- **IOC台帳** — 抽出されたすべてのインジケータの検索可能な台帳。エントリの相互参照とSTIX/CSVエクスポート付き
- **MITRE ATT&CKマトリクス** — 取り込んだ脅威インテリジェンス全体にわたるTTPカバレッジのヒートマップ
- **フィードヘルスダッシュボード** — フィードごとのポーリング状態、連続失敗のトラッキング、7日間の記事ボリューム
- **Detections** — 検出として登録されたすべて（AI生成、独自ファイルからのインポート、稼働中のSentinelワークスペースからの同期）を網羅する9タブのレビュー画面（下記参照）
- **モジュラー認証** — ロールベースアクセスを備えたMicrosoft Entra ID SSO、またはAzure依存ゼロの単一共有ローカルAPIキー。フロントエンドが自動検出します。[認証モード](#auth-modes)を参照

### 検出関連の2つの機能

このリポジトリは、実際には「detections」という傘の下で、関連しつつも独立して使用可能な2つのものを提供しています:

1. **`DETECTIONS` タブ** — 自己完結型のレビュー画面で、9つのサブタブに分かれています:
   - **All Detections** — 登録された分析の完全なカタログ。テクニック/ディスポジション/レビュー状態でフィルタ可能で、それぞれを展開すると説明と完全なKQLが表示されます。
   - **Defender Custom Detections** — 同じカタログですが、Sentinel分析ルールではなくMicrosoft Defender for Endpointのカスタム検出ルール向けの検出に限定されます。
   - **Alignment Reviews** — 検出分析がMITREテクニックに対して登録されるたびに、AIチェックがその実際のカバレッジをMITRE自身のそのテクニックの説明と比較します。乖離している場合、またはテクニックを部分的にしかカバーしていない場合、AIの推論、提案されたKQL修正、およびその修正自体の検証結果（静的ゲート + バックテスト）とともに、人間のレビュー項目としてここに表示されます — 盲目的な提案ではありません。
   - **Disposition Alerts** — 腐敗検出キュー: 承認された分析のテレメトリが劣化したり、基盤となるルールがエラーを出し始めたりすると、再レビューのためにここでフラグが立てられます。共有されたMITREテクニックだけでなく、その検出自体の名前で識別されます。
   - **Generated Hunts** — 検出はハントにグループ化されます（現在はインポートされたファイルごとに1つ。その統合がリリースされると、元のTI記事/detections.aiプロジェクトごとに1つ）。Microsoft Sentinel自身のHunts機能と一致します。ハントは、`Microsoft.SecurityInsights/hunts` オブジェクトとその構成要素である保存済み検索クエリとして、実際のSentinelワークスペースに同期できます（`SENTINEL_HUNTING_SYNC_ENABLED` と `mode` — off/manual/auto — によって制御され、Settings > API Settingsでチームごとに設定可能。オプトインしない限り、暗黙の自動プッシュは決して行われません）。
   - **Sentinel Hunts** — このアプリ自身の同期履歴ではなくARMから直接取得された、SentinelワークスペースのHunting機能に実際にデプロイされているもののライブインベントリ。クエリごとのテスト/チューニング提案が含まれ、その場で適用または却下できます。
   - **Sentinel Analytics Rules** — Microsoft SentinelのAnalytics Rules（`Microsoft.SecurityInsights/alertRules`）についての同じ考え方 — Huntingとは異なるSentinelリソースタイプで、これらはスケジュールに従って実際にインシデント/アラートを発火させるものです — 同じチューニング提案の適用/却下ワークフローを備えています。
   - **Local Detections** — 下記の[SentinelまたはAIプロバイダーなしでの実行](#running-without-sentinel-or-an-ai-provider-local-detections-import)を参照してください。
   - **Audit Log**（管理者専用） — このアプリが実際に実行したすべてのチェックのクロスパイプライン記録: AI生成検出のゲート/コントロールプローブ結果、Sentinelハント同期の試行、Sentinelハントクエリ/分析ルールのテスト実行を、1つのページネーションされたフィルタ可能なリストに統合したもの — 単一のレビュータブでは実現できない範囲を意図的にカバーしています。

   レビュー画面自体はメインバックエンド内で完全に動作し、追加のデプロイは不要です。そのAPI設計は完全に自己完結型でありながら、意図的に下記のdetections.aiの規約に従っています。
2. **detections.aiパイプラインオーケストレーター — 近日公開。** detections.aiはAI支援による検出生成のための公開APIを開発中で、このリポジトリにはそれ用に構築された実際の統合（`backend/detection_pipeline/orchestrator.py`）があり、トリアージ済みの脅威インテリジェンスを受け取り、既存の検出カバレッジと照合し、スケジュールジョブとしてSentinelワークスペース用のKQLドラフトを生成します。この統合はAPIが利用可能になり次第それをサポートしますが、この公開リリースにはまだ含まれていません。それまでの間、**Detectionsタブを使用するためにこれは一切必要ありません** — 下記の[Local Detections Import](#running-without-sentinel-or-an-ai-provider-local-detections-import)が、AI生成なし・Sentinelなしのセットアップで今日実現できる、同じ「実際の検出をこのアプリに取り込む」という目標をカバーしています。

### SentinelまたはAIプロバイダーなしでの実行: Local Detections Import

アプリの名前と主要な売り文句を考えると、**Basic** ティアのセルフホスターからの最も一般的な質問はおそらく *「SentinelもAIプロバイダーも設定していないのですが、それでもDetections/Huntsタブから何か得られますか？」* でしょう。答えはイエスです: アプリを独自の検出ルールファイルのフォルダ（手書き、実際のSentinel/Defenderテナントからのエクスポート、または公開のSigma/Sentinelルールリポジトリから取得したもの）に向ければ、それらをカタログ化し、MITREタグを付け、静的に検証します — そのいずれにもSentinel接続も `DETECTIONS_AI_API_KEY`/Anthropicキーも不要です。

- **初日からサポートされるフォーマット:** 生の `.kql`/`.txt`/`.yar`/`.spl` または任意の拡張子のファイル。それぞれ任意で `.json`/`.yaml` サイドカー（`{"file": "myrule.kql", "title": "...", "description": "...", "technique_id": "T1059.001"}`）とペアにして、Microsoft自身のエクスポートでは別途宣言する必要のないメタデータを付与できます。YARA、Suricata、Sigma YAML（単一または複数ドキュメント）、Splunk SPL、およびMicrosoft自身のネイティブエクスポートであるAnalytics Rule/Hunting Query JSON（`Scheduled` 種別のルールのみがこのアプリで評価できる生のKQLクエリを持ちます — その他の種別は認識され報告されますが、黙ってスキップされることはありません）。
- **インポートされたファイルで実際に実行されるもの:** KQLコンテンツに対する静的検証（AI生成パスが使用するのと同じ耐久性/検出事項エンジン）。AIプロバイダーを設定して*いれば*MITREアラインメントチェックも実行されます（Sentinelとは独立した軸で、片方のみ、両方、またはどちらもなしが可能）。Sentinel依存のもの（バックテスト、テレメトリプローブ、ディスポジショントラッキング）はすべてスコープ外のままで、誤解を招く空白セルではなく「no Sentinel connection configured」と表示されます。
- **表示される場所:** インポートされたコンテンツは通常のハント/検出行になります — 同じテーブル、同じレビューワークフロー、AIパイプラインが生成するものと同じMITREテクニック表示 — そのため専用タブだけでなく、通常の `ALL DETECTIONS`/`GENERATED HUNTS` ビューにも表示されます。専用の **Local Detections** サブタブ（`DETECTIONS` 配下、インポートのトリガーは管理者専用）は、フォルダを指定してファイルごとの進捗/結果を確認する場所です。
- **セットアップ:** `LOCAL_IMPORT_DIR` をバックエンドのファイルシステム上の絶対パス（コンテナデプロイではマウントされたボリューム）に設定します — インポートされるものはすべてそのルート配下に存在する必要があります。UIではその下のサブパスを選択でき、任意のファイルシステム位置を指定することはできません。[環境変数](#environment-variables)を参照してください。
- **すぐに試す:** `examples/local-detections-samples/` には、すぐにインポートできる小さなフォルダが同梱されています — 2つの有効なKQLルール（1つはその仕組みを示すために `.json` サイドカーとペア）、1つの意図的に無効なルール（invalidフラグ付きバナーを確認するため）、1つの認識されないファイル（インポート失敗バナーを確認するため）。`LOCAL_IMPORT_DIR` をそこに向ければ、ルールを書くことなく、最初のインポートで3つの結果状態すべてを確認できます。