# 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