ethan-andrews/threatintel-aggregatorSelbstgehostete Threat-Intelligence-Plattform — Feed-Aggregation, KI-Triage, MITRE-ATT&CK-Abdeckung und Sentinel-integrierte Detection-Engineering. Läuft eigenständig oder vollständig Azure-integriert.
Eine selbst gehostete Threat-Intelligence-Plattform, die RSS-Feeds von über 60 Sicherheitsanbietern aggregiert, KI-gestützte Triage durchführt, Ergebnisse mit Ihrem RunZero-Asset-Inventar korreliert und umsetzbare Warnmeldungen über ein Dark-Mode-Web-Dashboard bereitstellt.
Entwickelt, um eigenständig ohne Cloud-Abhängigkeit zu laufen oder vollständig in eine Azure/Entra/Sentinel-Umgebung integriert zu werden — wählen Sie die Stufe, die zu Ihren Gegebenheiten passt.
| Stufe | Skript | KI-Triage | Authentifizierung | Speicher | Das erhalten Sie |
|---|---|---|---|---|---|
| Basic | scripts/setup-basic.sh | Aus | Lokaler API-Schlüssel | Lokales Postgres (Docker) | Feed-Aggregation, IOC-Extraktion, MITRE-Matrix, Dashboards — keine KI, keine Cloud, keine Registrierung erforderlich |
| Basic + API | scripts/setup-basic-api.sh | Anthropic (direkt) | Lokaler API-Schlüssel | Lokales Postgres (Docker) | Alles oben Genannte, plus KI-gestützte Triage von Schweregrad/TTP/Zusammenfassung |
| Azure + API | scripts/setup-azure.ps1 | Azure AI Foundry | Microsoft Entra ID SSO | Ihr eigenes Postgres (Azure DB for PostgreSQL usw.) | Vollständige Bereitstellung in Azure Container Apps, SSO mit benutzerspezifischen Rollen. (Die Integration der detections.ai-Pipeline kommt in einer zukünftigen Version — siehe unten.) |
Alle drei führen exakt denselben Anwendungscode aus — das Einzige, was sich ändert, sind die gesetzten Umgebungsvariablen. Die vollständige Referenz finden Sie unter Environment Variables.```bash
./scripts/setup-basic.sh
./scripts/setup-basic-api.sh
./scripts/setup-azure.ps1
Die beiden Bash-Skripte starten einen lokalen Postgres-Container, wenden das Schema an und generieren `backend/.env` / `frontend/.env.local` für dich — dann geben sie die beiden Befehle aus, mit denen du die App tatsächlich startest (`pip install` + Backend ausführen, `npm install` + Frontend-Dev-Server ausführen). `setup-azure.ps1` ist ein dünner Wrapper um `infra/provision.ps1`, das eigentliche Azure Container Apps Deployment-Runbook.
---
## Features
- **Feed-Aggregation** — fragt 60+ Tier-1/2/3-Security-RSS-Feeds nach einem Zeitplan ab; dedupliziert und filtert Werbeinhalte automatisch heraus
- **KI-Triage** — klassifiziert jeden Eintrag mit Schweregrad (Critical/High/Medium/Low/Informational), MITRE ATT&CK TTPs und einer allgemein verständlichen Zusammenfassung. Provider-modular: direkte Anthropic API oder Azure AI Foundry, umschaltbar über eine einzige Env-Variable, ohne dass in beiden Fällen Funktionalität verloren geht
- **IOC-Extraktion** — extrahiert automatisch IPs, Domains, URLs, Datei-Hashes und CVEs aus jedem Eintrag
- **RunZero-Integration** — synchronisiert dein Asset-Inventar und korreliert Threat Intel mit Live-Assets; Abgleich über CVEs, Softwarenamen, OS-Versionen und IP-Adressen. Drei Unter-Tabs unter `RUNZERO`: **Matches** (Einträge, die mit deinem Inventar korreliert wurden, filterbar nach Schweregrad/Datum/Konfidenz/KEV), **Exposure** (organisationsweiter bestätigter/möglicher Status mit Remediation-Tracking) und **Metrics** (Trends von Eingang vs. Remediation über die Zeit)
- **Your Stack** — definiere die Software/OS in deiner Umgebung; bewertet alle Einträge neu nach Relevanz
- **IOC-Ledger** — durchsuchbares Verzeichnis aller extrahierten Indikatoren mit Eintrags-Querverweisen und STIX/CSV-Export
- **MITRE ATT&CK-Matrix** — Heatmap der TTP-Abdeckung über deinen erfassten Threat Intel
- **Feed-Health-Dashboard** — Poll-Status pro Feed, Verfolgung aufeinanderfolgender Fehler und Artikelvolumen über 7 Tage
- **Detections** — eine Review-Oberfläche mit 9 Tabs (siehe unten), die alles abdeckt, was als Detection registriert ist, egal ob KI-generiert, aus deinen eigenen Dateien importiert oder aus einem Live-Sentinel-Workspace synchronisiert
- **Modulare Authentifizierung** — Microsoft Entra ID SSO mit rollenbasierter Zugriffskontrolle oder ein einzelner gemeinsam genutzter lokaler API-Key ohne jegliche Azure-Abhängigkeit. Wird vom Frontend automatisch erkannt; siehe [Auth-Modi](#auth-modes)
### Zwei detections-bezogene Features
Dieses Repo liefert tatsächlich zwei verwandte, aber unabhängig nutzbare Dinge unter dem Dach „detections":
1. **Der `DETECTIONS`-Tab** — eine in sich geschlossene Review-Oberfläche, aufgeteilt in neun Unter-Tabs:
- **All Detections** — der vollständige Katalog registrierter Analysen, filterbar nach Technik/Disposition/Review-Status, jede erweiterbar zu ihrer Beschreibung und vollständigem KQL.
- **Defender Custom Detections** — derselbe Katalog, beschränkt auf Detections, die für die Custom Detection Rules von Microsoft Defender for Endpoint statt für Sentinel Analytics Rules bestimmt sind.
- **Alignment Reviews** — wann immer eine Detection-Analyse gegen eine MITRE-Technik registriert wird, vergleicht eine KI-Prüfung ihre tatsächliche Abdeckung mit MITREs eigener Beschreibung dieser Technik. Wenn sie abweicht oder die Technik nur teilweise abdeckt, landet sie hier als menschlicher Review-Eintrag mit der Begründung der KI, einem vorgeschlagenen KQL-Fix und dem eigenen Validierungsergebnis dieses Fixes (statisches Gate + Backtest) — niemals ein blinder Vorschlag.
- **Disposition Alerts** — eine Rot-Detection-Warteschlange: eine genehmigte Analyse, deren Telemetrie verfällt oder deren zugrundeliegende Regel anfängt zu fehlern, wird hier zur erneuten Prüfung markiert, benannt nach ihrer eigenen Detection statt nur nach der geteilten MITRE-Technik.
- **Generated Hunts** — Detections werden in Hunts gruppiert (heute eine pro importierter Datei; eine pro ursprünglichem TI-Artikel/detections.ai-Projekt, sobald diese Integration ausgeliefert wird), passend zu Microsoft Sentinels eigener Hunts-Funktion. Eine Hunt kann als `Microsoft.SecurityInsights/hunts`-Objekt plus ihre zugehörigen Saved-Search-Queries in einen echten Sentinel-Workspace synchronisiert werden (gesteuert durch `SENTINEL_HUNTING_SYNC_ENABLED` und einen `mode` — off/manual/auto — pro Team konfigurierbar unter Settings > API Settings; niemals ein stiller Auto-Push, es sei denn, du entscheidest dich dafür).
- **Sentinel Hunts** — das Live-Inventar dessen, was tatsächlich in der Hunting-Funktion deines Sentinel-Workspace deployt ist, direkt aus ARM gezogen statt aus der eigenen Sync-Historie dieser App; enthält Test-/Tune-Vorschläge pro Query, die du direkt anwenden oder verwerfen kannst.
- **Sentinel Analytics Rules** — dieselbe Idee für Microsoft Sentinels Analytics Rules (`Microsoft.SecurityInsights/alertRules`) — ein von Hunting verschiedener Sentinel-Ressourcentyp, da diese es sind, die tatsächlich nach Zeitplan Incidents/Alerts auslösen — mit demselben Workflow zum Anwenden/Verwerfen von Tune-Vorschlägen.
- **Local Detections** — siehe [Running without Sentinel or an AI provider](#running-without-sentinel-or-an-ai-provider-local-detections-import) unten.
- **Audit Log** (nur Admin) — eine pipelineübergreifende Aufzeichnung jeder Prüfung, die diese App tatsächlich ausgeführt hat: KI-generierte Detection-Gate-/Control-Probe-Ergebnisse, Sentinel-Hunt-Sync-Versuche und Testläufe von Sentinel-Hunt-Queries/Analytics-Rules, kombiniert in einer paginierten, filterbaren Liste — bewusst abdeckend, was kein einzelner Review-Tab für sich allein tut.
Läuft vollständig im Haupt-Backend, kein zusätzliches Deployment für die Review-Oberfläche selbst nötig. Ihr eigenes API-Design folgt bewusst den detections.ai-Konventionen unten, obwohl sie vollständig eigenständig ist.
2. **detections.ai Pipeline-Orchestrator — kommt bald.** detections.ai hat eine öffentliche API in Entwicklung für KI-gestützte Detection-Generierung, und dieses Repo hat eine echte Integration dafür gebaut (`backend/detection_pipeline/orchestrator.py`), die triagierten Threat Intel nimmt, ihn gegen bestehende Detection-Abdeckung prüft und Entwurfs-KQL für deinen Sentinel-Workspace als geplanten Job generiert. Diese Integration wird diese API unterstützen, sobald sie verfügbar ist, und ist noch nicht Teil dieses öffentlichen Releases. In der Zwischenzeit **brauchst du sie überhaupt nicht, um den Detections-Tab zu nutzen** — [Local Detections Import](#running-without-sentinel-or-an-ai-provider-local-detections-import) unten deckt dasselbe Ziel „echte Detections in diese App bekommen" für Setups ohne KI-Generierung und ohne Sentinel heute ab.
### Running without Sentinel or an AI provider: Local Detections Import
Angesichts des Namens und des Hauptversprechens der App wird die häufigste Frage eines Self-Hosters auf dem **Basic**-Tier wahrscheinlich sein: *„Ich habe weder Sentinel noch einen KI-Provider konfiguriert — kann ich trotzdem etwas aus den Detections-/Hunts-Tabs herausholen?"* Die Antwort ist ja: Richte die App auf einen Ordner mit deinen eigenen Detection-Regeldateien (handgeschrieben, aus einem echten Sentinel-/Defender-Tenant exportiert oder aus einem öffentlichen Sigma-/Sentinel-Regel-Repo gezogen) und sie wird sie katalogisieren, MITRE-taggen und statisch validieren — dafür ist weder eine Sentinel-Verbindung noch ein `DETECTIONS_AI_API_KEY`/Anthropic-Key erforderlich.
- **Unterstützte Formate, ab Tag eins:** rohe `.kql`/`.txt`/`.yar`/`.spl`- oder Dateien mit beliebiger Endung, jeweils optional mit einer `.json`/`.yaml`-Sidecar-Datei (`{"file": "myrule.kql", "title": "...", "description": "...", "technique_id": "T1059.001"}`) für Metadaten, die Microsofts eigener Export nicht separat deklarieren muss; YARA; Suricata; Sigma YAML (ein- oder mehrdokumentig); Splunk SPL; und Microsofts eigene native exportierte Analytics Rule/Hunting Query JSON (nur Regeln vom Typ `Scheduled` tragen eine rohe KQL-Query, die diese App auswerten kann — jeder andere Typ wird erkannt und gemeldet, nicht stillschweigend übersprungen).
- **Was bei einer importierten Datei tatsächlich läuft:** statische Validierung (dieselbe Durability-/Findings-Engine, die der KI-Generierungspfad nutzt) für KQL-Inhalte; außerdem eine MITRE-Alignment-Prüfung, wenn du *tatsächlich* einen KI-Provider konfiguriert hast (eine von Sentinel unabhängige Achse — du kannst eines, beides oder keines haben); alles Sentinel-Abhängige (Backtesting, Telemetrie-Probes, Disposition-Tracking) bleibt außerhalb des Geltungsbereichs und wird als „no Sentinel connection configured" dargestellt statt als irreführende leere Zelle.
- **Wo es auftaucht:** importierter Inhalt wird zu einer normalen Hunt-/Detection-Zeile — dieselben Tabellen, derselbe Review-Workflow, dieselbe MITRE-Technik-Anzeige wie alles, was die KI-Pipeline generiert — sodass er auch in den regulären `ALL DETECTIONS`/`GENERATED HUNTS`-Ansichten erscheint, nicht nur in seinem eigenen Tab. Der dedizierte **Local Detections**-Unter-Tab (unter `DETECTIONS`, nur Admins können einen Import auslösen) ist der Ort, an dem du ihn auf einen Ordner richtest und den Fortschritt/die Ergebnisse pro Datei beobachtest.
- **Setup:** setze `LOCAL_IMPORT_DIR` auf einen absoluten Pfad im Dateisystem des Backends (ein gemountetes Volume in einem Container-Deployment) — alles Importierte muss unter diesem Root liegen; die UI lässt dich einen Unterpfad darunter auswählen, niemals einen beliebigen Dateisystemort. Siehe [Environment Variables](#environment-variables).
- **Sofort ausprobieren:** `examples/local-detections-samples/` liefert einen kleinen, sofort importierbaren Ordner — zwei gültige KQL-Regeln (eine mit einer `.json`-Sidecar-Datei, um diesen Mechanismus zu zeigen), eine absichtlich ungültige Regel (um das als ungültig markierte Banner zu sehen) und eine nicht erkannte Datei (um das fehlgeschlagene Import-Banner zu sehen). Richte `LOCAL_IMPORT_DIR` darauf, um alle drei Ergebniszustände bei deinem allerersten Import zu sehen, ohne eine Regel schreiben zu müssen.
**Local Detections** — ein abgeschlossener Importlauf: das Zusammenfassungs-Banner hebt Dateien hervor, die katalogisiert, aber von der statischen Analyse als ungültig markiert wurden (hier eine Regel, die bei einem einzelnen hartcodierten Hash alarmiert), direkt neben denen, die sauber importiert wurden, und jede Datei wird zu einer normalen Hunt-/Detection-Zeile darunter
---
## Screenshots
Alle Screenshots unten verwenden synthetische Daten (fiktive Organisationsnamen, RFC 5737-Beispiel-IPs, `.example`-Domains), die für die Dokumentation generiert wurden — keine echten Threat-Intel- oder Kundendaten.
**Feed** — triagierte Threat-Intel-Einträge mit Schweregrad, Tags, IOCs und TTPs durchsuchen und filtern
<br>
**Dashboard** — Schweregrad-Aufschlüsselung auf einen Blick und Top-MITRE-ATT&CK-Techniken
<br>
**MITRE ATT&CK** — vollständige Matrix-Heatmap der Technik-Abdeckung über den erfassten Intel
<br>
**Your Stack** — definiere deine Umgebung; Feed-Einträge werden nach Relevanz neu bewertet
<br>
**IOCs** — durchsuchbares Verzeichnis aller extrahierten Indikatoren mit STIX/CSV-Export
<br>
**Integrations** — Connector-Übersicht für Sentinel, Defender und RunZero: konfigurierter/aktivierter Status und Shortcuts in den jeweiligen eigenen Tab
<br>
**RunZero** — Asset-Korrelation, organisationsweites Exposure-Tracking und Remediation-Metriken, alle aus deinem RunZero-Inventar bezogen
<br>
**Exposure** — Organisationen nach Anzahl der Threat-Matches gereiht; klicke auf eine beliebige Karte, um passende Einträge zu sehen
<br>
**Detections** — der vollständige Katalog registrierter Analysen (KI-generiert und lokal importiert gleichermaßen), jede mit ihrem Static-Gate-/Backtest-/Review-Status und MITRE-Technik
<br>
**Settings** — KI-Triage-Steuerung, Feed-Health-Monitoring, Source-Trust-Scores und Benutzerverwaltung
---
## Architektur```
┌─────────────────────────────────────────┐
│ Next.js 16 frontend (port 3000) │
│ Tailwind CSS · dark theme │
└──────────────┬──────────────────────────┘
│ REST API (Bearer token)
┌──────────────▼──────────────────────────┐
│ FastAPI backend (port 8000) │
│ APScheduler · slowapi rate limiting │
└──┬──────────┬──────────┬────────────┬───┘
│ │ │ │
Postgres AI provider RunZero API detections.ai
(modular: (asset sync) (coming soon --
Anthropic or see Features below)
Azure AI Foundry)
Backend (backend/) — Python 3.12 + FastAPI. Postgres für die gesamte Speicherung (SQLite und Azure Blob Storage wurden vollständig eingestellt). KI-Anbieter und Authentifizierungsmethode werden beide per Umgebungsvariable ausgewählt, nicht fest codiert — siehe unten.
Frontend (frontend/) — Next.js 16, reines JavaScript, Tailwind CSS. Erkennt den Authentifizierungsmodus automatisch vom Backend beim Laden.
Infra (infra/) — Azure Bicep-Vorlagen für Container Apps, Key Vault und Container Registry (apps.bicep + platform.bicep + app-stack.bicep, bereitgestellt über provision.ps1). Nur relevant für den Azure + API-Tier.
AZURE_AD_TENANT_ID gesetzt → Entra-Modus: Microsoft Entra ID SSO, benutzerspezifische Rollen (erste Anmeldung wird Admin, alle anderen standardmäßig Viewer).
AZURE_AD_TENANT_ID nicht gesetzt → Lokaler Modus: ein einzelner gemeinsamer LOCAL_API_KEY gewährt Admin-Zugriff für jeden, der ihn besitzt. Keine Benutzerverwaltung, keine Azure-Abhängigkeit. Das Frontend ruft beim Laden GET /api/auth/mode auf und rendert automatisch den passenden Anmeldebildschirm — auf der Frontend-Seite ist nichts zu konfigurieren.
Beide Modi stellen anschließend dieselbe Art von app-signiertem JWT aus, sodass jede andere Route (require_auth/require_admin) identisch funktioniert, unabhängig davon, welcher Modus das Token ausgestellt hat.
Führen Sie scripts/setup-basic.sh oder scripts/setup-basic-api.sh aus (siehe Deployment-Stufen) — sie kümmern sich um Postgres und die .env-Generierung für Sie. Dann:```bash
cd backend && pip install -r requirements.txt && uvicorn main:app --reload --port 8000
cd frontend && npm install && npm run dev
### Manuelle Einrichtung```bash
cd backend
python -m venv .venv
source .venv/bin/activate # Windows: .venv\Scripts\activate
pip install -r requirements.txt
cp env.example .env # fill in required values — see Environment Variables below
uvicorn main:app --reload --port 8000
| --no-verify | -n | SSL-Zertifikatsprüfung überspringen |
| --timeout | -t | HTTP-Anfrage-Timeout in Sekunden (Standard: 10) |
| --user-agent | -A | Benutzerdefinierter User-Agent-String |
| --proxy | -p | Proxy-URL (z. B. http://127.0.0.1:8080) |
| --header | -H | Benutzerdefinierter Header (wiederholbar) |
| --cookie | -b | Cookie-String |
| --follow-redirects | -L | HTTP-Weiterleitungen folgen |
| --max-redirects | | Maximale Anzahl von Weiterleitungen (Standard: 5) |
| --threads | | Anzahl gleichzeitiger Threads (Standard: 10) |
| --delay | | Verzögerung zwischen Anfragen in Sekunden |
| --retries | | Anzahl der Wiederholungsversuche bei fehlgeschlagenen Anfragen (Standard: 3) |
| --output | -o | Ausgabedatei (Standard: stdout) |
| --format | -f | Ausgabeformat: text, json, csv (Standard: text) |
| --verbose | -v | Ausführliche Ausgabe |
| --quiet | -q | Stiller Modus (nur Ergebnisse) |
| --no-color | | Farbige Ausgabe deaktivieren |
| --config | -c | Pfad zur Konfigurationsdatei |
| --version | -V | Version anzeigen und beenden |
| --help | -h | Hilfemeldung anzeigen und beenden |
# Grundlegende Verwendung
scanner -u https://example.com
# Mehrere URLs aus einer Datei
scanner -l urls.txt
# Mit benutzerdefinierten Headern und Cookies
scanner -u https://example.com -H "Authorization: Bearer token" -b "session=abc123"
# Ausgabe im JSON-Format
scanner -u https://example.com -f json -o results.json
# Mit Proxy und erhöhten Threads
scanner -u https://example.com -p http://127.0.0.1:8080 --threads 20
# Stiller Modus mit Weiterleitungsverfolgung
scanner -u https://example.com -q -L
Das Tool unterstützt eine YAML-Konfigurationsdatei. Standardmäßig sucht es nach ~/.scanner/config.yaml.
# Beispiel für eine Konfigurationsdatei
timeout: 15
threads: 20
user_agent: "Mozilla/5.0 (Windows NT 10.0; Win64; x64)"
follow_redirects: true
max_redirects: 10
headers:
Authorization: "Bearer your-token"
X-Custom-Header: "value"
cookies:
session: "abc123"
proxy: "http://127.0.0.1:8080"
output_format: "json"
verbose: false
| Code | Beschreibung |
|---|---|
| 0 | Erfolg |
| 1 | Allgemeiner Fehler |
| 2 | Ungültige Argumente |
| 3 | Netzwerkfehler |
| 4 | Authentifizierungsfehler |
| 5 | Zeitüberschreitung |
| Variable | Beschreibung |
|---|---|
SCANNER_TIMEOUT | Standard-Timeout in Sekunden |
SCANNER_THREADS | Standardanzahl von Threads |
SCANNER_USER_AGENT | Standard-User-Agent |
SCANNER_PROXY | Standard-Proxy-URL |
SCANNER_CONFIG | Pfad zur Konfigurationsdatei |
SCANNER_NO_COLOR | Farbige Ausgabe deaktivieren (1 oder true) |
SCANNER_VERBOSE | Ausführliche Ausgabe aktivieren (1 oder true) |
Wenn Verbindungszeitüberschreitungen auftreten, erhöhen Sie den Timeout-Wert:
scanner -u https://example.com --timeout 30
Wenn SSL-Zertifikatsfehler auftreten, können Sie die Überprüfung überspringen (nicht für die Produktion empfohlen):
scanner -u https://example.com --no-verify
Wenn Sie auf Ratenbegrenzung stoßen, reduzieren Sie die Anzahl der Threads und fügen Sie eine Verzögerung hinzu:
scanner -u https://example.com --threads 5 --delay 1
Wenn Sie Probleme mit der Proxy-Verbindung haben, überprüfen Sie, ob der Proxy erreichbar ist:
curl -x http://127.0.0.1:8080 https://example.com
Beiträge sind willkommen! Bitte lesen Sie die CONTRIBUTING.md für Richtlinien.
git checkout -b feature/amazing-feature)git commit -m 'Add amazing feature')git push origin feature/amazing-feature)Dieses Projekt ist unter der MIT-Lizenz lizenziert – siehe die LICENSE-Datei für Details.
Dieses Tool ist nur für Bildungs- und autorisierte Sicherheitstests gedacht. Die Nutzer sind dafür verantwortlich, die geltenden Gesetze und Vorschriften einzuhalten. Die Autoren übernehmen keine Haftung für Missbrauch oder Schäden, die durch dieses Tool entstehen.
Hinweis: Stellen Sie immer sicher, dass Sie die Erlaubnis haben, das Zielsystem zu testen, bevor Sie dieses Tool verwenden.```bash cd frontend npm install cp env.local.example .env.local # set NEXT_PUBLIC_API_URL=http://localhost:8000 npm run dev
### Docker Compose (beide Dienste)```bash
cp backend/env.example backend/.env # fill in required values
docker compose up --build
Frontend → http://localhost:3000 Backend-API-Dokumentation → http://localhost:8000/docs
Kopiere backend/env.example nach backend/.env und fülle sie aus. Gruppiert danach, welcher Tier sie benötigt:
Immer erforderlich:
| Variable | Beschreibung |
|---|---|
PG_DSN | Postgres-Verbindungszeichenfolge |
JWT_SECRET_KEY | Secret zum Signieren von App-Session-Tokens (python -c "import secrets; print(secrets.token_hex(32))") |
Authentifizierung — einen Modus wählen:
| Variable | Beschreibung |
|---|---|
LOCAL_API_KEY | Lokaler Modus: gemeinsamer Schlüssel, der Admin-Zugriff gewährt. Lasse AZURE_AD_TENANT_ID ungesetzt, um diesen Modus zu aktivieren |
AZURE_AD_TENANT_ID | Entra-Modus: Tenant-ID für SSO. Das Setzen aktiviert den Entra-Modus |
AZURE_AD_CLIENT_ID | Entra-Modus: Client-ID der App-Registrierung |
AZURE_AD_CLIENT_SECRET | Entra-Modus: Secret der App-Registrierung (nur Frontend) |
NEXTAUTH_SECRET | Entra-Modus: NextAuth-Session-Verschlüsselungs-Secret (nur Frontend) |
KI-Triage — optional, einen Anbieter wählen (beide weglassen, um mit deaktivierter Triage zu laufen):
| Variable | Beschreibung |
|---|---|
AI_PROVIDER | anthropic (Standard) oder azure |
ANTHROPIC_API_KEY | Direkter Anthropic-API-Schlüssel |
AZURE_FOUNDRY_ENDPOINT | Azure AI Foundry-Endpunkt, z. B. https://<resource>.services.ai.azure.com/anthropic |
AZURE_FOUNDRY_API_KEY | Azure AI Foundry-API-Schlüssel |
AZURE_FOUNDRY_DEPLOYMENT | Foundry-Bereitstellungsname (Standard claude-haiku-4-5) |
AZURE_FOUNDRY_API_VERSION | Foundry-API-Version (Standard 2025-05-01) |
Optional:
| Variable | Beschreibung |
|---|---|
RUNZERO_API_TOKEN | Aktiviert RunZero-Asset-Synchronisierung und -Korrelation |
ALLOWED_ORIGINS | Kommagetrennte CORS-Allowlist (Standard http://localhost:3000) |
ENABLE_SCHEDULER | Auf false setzen, um den Hintergrund-Feed-Poller zu deaktivieren (Standard true) |
ARCHIVE_AFTER_DAYS | Auto-Archivierungsschwelle in Tagen (Standard 90) |
PG_POOL_MIN / PG_POOL_MAX / PG_POOL_TIMEOUT | Postgres-Verbindungspool-Tuning (Standardwerte 1 / 10 / 30) |
LOCAL_IMPORT_DIR | Aktiviert Local Detections Import — absoluter Pfad im Dateisystem des Backends, auf den jeder Import beschränkt ist. Ungesetzt deaktiviert die Funktion vollständig (der zugehörige Tab zeigt eine „nicht konfiguriert"-Meldung) |
Frontend (frontend/.env.local oder frontend/env.local.example):
| Variable | Beschreibung |
|---|---|
NEXT_PUBLIC_API_URL | Backend-URL aus Sicht des Browsers. Wird zur Build-Zeit in das JS-Bundle eingebettet. Ungesetzt lassen, um API-Aufrufe stattdessen über den integrierten Same-Origin-Proxy (frontend/pages/api/[...proxy].js) zu leiten — erforderlich, wann immer das Backend keinen öffentlichen Ingress hat (z. B. die nur intern erreichbare Container App des Azure + API-Tiers) |
BACKEND_URL | Backend-URL aus Sicht des Next.js-Servers selbst. Wird vom Login-Austausch von NextAuth verwendet und, wenn NEXT_PUBLIC_API_URL ungesetzt ist, vom Same-Origin-Proxy, der jede /api/*-Browser-Anfrage serverseitig weiterleitet |
detections.ai-Orchestrator — demnächst verfügbar (noch nicht Teil dieses öffentlichen Releases; hier dokumentiert für den Fall der Veröffentlichung. Azure + API-Tier, separat bereitstellbar — siehe backend/detection_pipeline/orchestrator.py):
| Variable | Beschreibung |
|---|---|
DETECTIONS_AI_API_KEY | Erforderlich, um den Orchestrator überhaupt auszuführen |
SENTINEL_WORKSPACE_ID | Customer ID (GUID) des Log Analytics Workspace, für Backtesting. Optional |
PIPELINE_BATCH_SIZE | Einträge pro Lauf (Standard 5) |
PIPELINE_DRY_RUN | true, um zu beanspruchen und zu protokollieren, ohne die API aufzurufen |
PIPELINE_LANGUAGE | Abfragesprache für Detections (Standard kql) |
Sentinel Hunts-Synchronisierung (optional, standardmäßig aus — siehe Einstellungen > API-Einstellungen für den Modus an/aus/manuell/automatisch):
| Variable | Beschreibung |
|---|---|
SENTINEL_HUNTING_SYNC_ENABLED | true, um überhaupt einen Hunt-Sync-Versuch zuzulassen. Ungesetzt/false ist ein reiner No-Op — null ARM-Aufrufe |
AZURE_SUBSCRIPTION_ID | Subscription, die den Sentinel-Workspace enthält |
AZURE_RESOURCE_GROUP | Ressourcengruppe, die den Sentinel-Workspace enthält |
SENTINEL_WORKSPACE_NAME | Der Name des Workspace, nicht seine Customer ID — ein anderer Wert als SENTINEL_WORKSPACE_ID oben, den stattdessen der Data-Plane-Client für Backtesting verwendet |
Die echte, aktuelle IaC ist infra/apps.bicep + infra/platform.bicep + infra/app-stack.bicep, bereitgestellt über infra/provision.ps1 (oder den dünnen Wrapper scripts/setup-azure.ps1). Sie provisioniert Container Apps, Key Vault-gestützte Secrets und Managed Identities — Postgres selbst wird von diesem Repository nicht provisioniert; richte PG_DSN (gespeichert als das Key Vault-Secret pg-dsn) auf einen beliebigen erreichbaren Postgres-Server aus.```powershell
./scripts/setup-azure.ps1
cd infra cp migration.psd1.example migration.psd1 # fill in your resource group, apps, etc. ./provision.ps1
`provision.ps1` ist idempotent — kann nach dem Bearbeiten des Manifests bedenkenlos erneut ausgeführt werden. Siehe den eigenen Header-Kommentar für die vollständige Schritt-für-Schritt-Anleitung (Plattform → App-Stack → Secrets → Easy Auth → Image-Import → Apps → Post-Checks).
Der detections.ai-Orchestrator (ein geplanter Container Apps Job, gesteuert durch einen `Orchestrator`-Block in `migration.psd1` — siehe `migration.psd1.example` für die Struktur, und speichere deinen Schlüssel als `DETECTIONSAIAPIKEY` Key Vault Secret) ist noch nicht Teil dieses öffentlichen Releases — siehe [Two detections-related features](#two-detections-related-features) oben.
---
## Projektstruktur```
├── backend/
│ ├── main.py # FastAPI app, all endpoints
│ ├── db.py # Postgres queries
│ ├── pgcompat.py # connection pool + SQLite-style placeholder translation
│ ├── feed_manager.py # RSS polling, AI triage (provider-modular), scheduler
│ ├── enrichment.py # IOC extraction, KEV cache, stack rematch
│ ├── runzero_sync.py # RunZero asset sync and correlation engine
│ ├── dedup.py # CVE deduplication logic
│ ├── auth.py # Entra ID SSO + local API-key auth, app JWT sign/verify
│ ├── ioc_export.py # STIX 2.1 and CSV export
│ ├── stack_presets.py # Pre-built tech stack templates
│ ├── detection_pipeline/ # detections.ai orchestrator, MITRE alignment-check,
│ │ # Sentinel hunts/analytics-rules sync + tuning,
│ │ # audit log, local_import.py (Local Detections Import)
│ └── tests/ # pytest test suite, incl. fixtures/local_import/
├── frontend/
│ ├── pages/
│ │ ├── index.js # Main app shell + tab routing
│ │ └── login.js # Entra ID or local API-key login, auto-detected
│ ├── lib/
│ │ ├── authMode.js # GET /api/auth/mode, cached per page load
│ │ ├── authFetch.js # Bearer auth + 401-retry wrapper
│ │ └── authSession.js # token storage, JWT decode/expiry helpers
│ └── components/
│ ├── layout/ # TopBar, Sidebar, TabBar, TopFilterBar, TimeRangeToggle
│ ├── feed/ # FeedList, FeedCard
│ ├── integrations/ # IntegrationsPanel, ExposurePanel, RunZeroPanel,
│ │ # RunZeroMatchesPanel, RunZeroMetricsPanel
│ ├── detections/ # DetectionsPanel (tab shell) + one component per
│ │ # sub-tab: DetectionsCatalogPanel, AlignmentReviewPanel,
│ │ # DispositionAlertsPanel, HuntsPanel, SentinelHuntsPanel,
│ │ # SentinelAnalyticsRulesPanel, LocalDetectionsPanel,
│ │ # AuditPanel, plus shared TuningSuggestionBadge
│ ├── settings/ # SettingsPanel, CadencePicker, SeverityCards
│ └── mitre/ # MitreMatrix
├── infra/ # Azure Bicep templates + provision.ps1
├── scripts/ # Tiered setup scripts (see Deployment tiers)
└── docker-compose.yml
63 Feeds über drei Stufen:
Authorization: Bearer <token>secrets.compare_digest) für den lokalen Auth-Schlüssel.env / Azure Key Vault geladenMIT — siehe LICENSE.