README.md

SentinelOps v2.0

This is the clean Phase 6 build of SentinelOps v2.0. It is separated from later experimental work so the detection-engine version can be developed, tested, and published on its own.

Phase 1 Foundation

• Modular Python backend
• Versioned /api/v2 endpoints
• Environment-based configuration
• JSON structured logging
• Ordered SQLite migrations
• Consistent validation and API errors
• ES-module frontend
• Python and JavaScript tests

Phase 2 Detection Engine

• Sigma-inspired JSON detection rules
• Built-in and custom rule persistence
• Rule enable, disable, update, delete, and JSON import
• Configurable event counts and time windows
• User, host, source IP, and process allowlists
• Duplicate alert suppression
• Confidence scoring and match explanations
• Severity and threshold overrides
• In-browser rule test bench

Phase 3 Windows And Sysmon Coverage

• Expanded built-in rule pack from 4 rules to 15 rules
• Sysmon process creation detections for LOLBins and suspicious parent-child chains
• Sysmon network connection detections for scripting tools making outbound traffic
• Sysmon registry autorun persistence detections
• Sysmon suspicious file-drop detections in user-writable folders
• Defender tamper and security-control modification detections
• Security log clear, service installation, account manipulation, and RDP logon detections
• Additional normalized fields for parent process, logon type, destination, registry, file, service, and hash data

Phase 4 Incident Workflow

• Create incidents from real detection alerts
• Store incidents locally in SQLite
• Track status: New, Investigating, Contained, Resolved, and False Positive
• Track severity, owner, source, alert ID, rule ID, MITRE ID, and risk score
• Add analyst investigation notes
• Maintain a case timeline for creation, updates, and notes
• Filter the incident queue by status
• Open incident details from the SOC dashboard

Phase 5 AI Incident Summary Engine

• Generate executive and technical incident summaries
• Explain suspicious behaviour using only saved alert and event evidence
• Report only MITRE ATT&CK mappings already present in the evidence
• Explain the stored risk level without inventing additional risk
• Recommend investigation and conditional containment actions
• Display evidence limitations and an evidence fingerprint
• Save summary history in SQLite
• Support correlated incidents containing multiple alerts and events
• Optional OpenAI Responses API with strict Structured Outputs
• Local evidence-only mode when no API key is configured

Phase 6 Threat Hunting And Detection Expansion

• Six built-in threat hunting queries
• Local IOC lists for IPs, domains, hashes, usernames, and file paths
• IOC matching against loaded event data
• Simple Sigma JSON/YAML conversion into SentinelOps rules
• MITRE ATT&CK frequency heatmap
• Chronological incident investigation timeline
• Local HTML and PDF incident report export
• SQLite hunt history and IOC persistence

Screenshots

These screenshots use safe synthetic telemetry created only to demonstrate the workflow. SentinelOps does not ship with sample findings and analyzes logs supplied by the user.

Command Center

Incident Workbench

Threat Hunting

Detection Studio Simple Mode

Detection Studio Advanced Mode

AI Configuration

The default mode does not send data outside the computer. To enable OpenAI summaries for the current PowerShell session:

$env:OPENAI_API_KEY = "your-api-key"
$env:SENTINELOPS_OPENAI_MODEL = "gpt-5.6-terra"   # optional; this is the default
.\start.ps1

Never commit an API key or place one in the frontend. When cloud mode is enabled, the app sends a restricted evidence packet containing allowlisted incident, alert, and event fields. API requests use store: false.

Event fields such as command, message, and process are chosen by whoever ran the activity on the monitored host, so they are attacker-influenced text. They are sent inside an <untrusted_evidence> block and the model is instructed to treat that block as inert data: never to obey directives found in it, and never to accept a claim from the evidence that the activity was authorized or already investigated.

Instructions alone are not a boundary, so every generated summary is then re-checked in code against the evidence it came from. This runs for all providers:

• MITRE techniques not present in the stored evidence are discarded, and the discard is disclosed under evidence limitations.
• The risk statement is prefixed with the stored severity and risk score, read from the incident record rather than from the summary, so a summary cannot talk the recorded risk down.
• Evidence text that reads like instructions is flagged unconditionally, rather than relying on the model to notice and report it.

The narrative prose is still model-written; these checks constrain the machine-readable claims and keep the recorded risk visible.

Run

..\start-v2.ps1

Open http://127.0.0.1:8081.

Port 8081 is used so this folder can run beside SentinelOps v1.0 on port 8080. Override it with $env:SENTINELOPS_V2_PORT.

To collect from the Security channel, start the launcher from an elevated PowerShell window. Being signed in as an Administrator is not enough: under UAC an ordinary window runs with a filtered token and that log is denied to it. Every other channel works unelevated, and an unelevated Security collection returns 403 event_log_forbidden instead of an empty result. GET /api/v2/status reports elevated and restrictedChannels. See the Administrator Rights section for details.

Test

.\test.ps1

Structure

v2.0/
|-- backend/
|   |-- api.py
|   |-- app.py
|   |-- config.py
|   |-- database.py
|   |-- rules.py
|   |-- server.py
|   |-- validation.py
|   |-- windows.py
|   `-- migrations/
|-- frontend/
|   |-- js/
|   |-- styles/
|   `-- index.html
|-- rules/
|-- tests/
|-- start.ps1
`-- test.ps1

See docs/architecture.md for module responsibilities and docs/detection-rules.md for the rule schema.