AWatch-rus/docs/security-analytics-stack-v1.md

AW-rus Security Analytics Stack v1

Goal

Build a sufficient internal security analytics stack for the current environment without pretending to be Splunk-class infrastructure.

Scope

Sources:

• Windows EVTX
• ActivityWatch buckets
• DLP incidents
• file operations
• outbound email
• session/logon markers

Core outcomes:

• ingest
• normalize
• detect
• correlate
• case
• notify
• investigate

v1 Architecture

Windows side

• collectors and DLP scripts write to deployment-config.json
• export-evtx-for-hayabusa.ps1 exports bounded EVTX packages
• export-upload-hayabusa-to-aw-server.ps1 uploads:
  • zip
  • .meta.json
  • optional .caseid
• ActivityWatch Hayabusa Upload scheduled task runs every 6 hours
• on SHARKON2025 the task runs as interactive/highest Администратор; SYSTEM PowerShell tasks fail with 0xC0000142 before the script starts
• sidecar JSON is written as UTF-8 without BOM; server-side readers also tolerate BOM for older files

Server side

• aw-hayabusa-drop.path watches /opt/activitywatch/aw-rus-ops/drop
• aw-hayabusa-drop.service runs aw-hayabusa-autoprocess
• /opt/activitywatch/aw-rus-ops/drop is writable by awops and processed by root-owned systemd units
• aw-hayabusa performs:
  • accept
  • process-inbox
  • report generation
• Windows zip entries with backslash separators are normalized during extraction
• autoprocess drains the incoming queue after accepting a drop package, preventing stale failed-run packages from being linked to a newer drop upload
• aw-hayabusa-case-alert performs:
  • severity scoring from timeline.jsonl
  • optional auto-case creation
  • bounded Hayabusa linkage
  • summary comment
  • Telegram alerting

Case layer

• DLP case API remains the source of truth for incident lifecycle
• Hayabusa writes bounded metadata into forensics.hayabusa
• auto-created cases use:
  • incident_id = hayabusa:<host>:<intake_id>

Severity Model v1

Inputs:

• Hayabusa Level
• top RuleTitle
• failed logon count
• suspicious PowerShell count
• credential-related detections
• timestomp detections

Outputs:

• low
• medium
• high
• critical

Rules:

• critical for crit alerts, very high score, or strong compound signals
• high for at least one high alert or elevated score
• medium for med alerts, notable failed logons, or moderate score
• low otherwise

Automation Policy v1

• EVTX upload every 6 hours
• lookback window: 6 hours
• auto-case enabled from medium
• Telegram enabled from high
• human operator only for final triage/escalation

Non-goals

Not trying to implement:

• distributed search cluster
• Splunk-style indexers/search heads
• full SIEM content ecosystem
• petabyte-scale retention design

Definition of Done

The stack is sufficient when it can, without a dedicated analyst:

• collect relevant data
• process EVTX on schedule
• score severity
• create/update a case
• send an alert
• preserve investigation artifacts
• let a human understand what happened in a few minutes