Перейти до змісту

Щоденна рутина — Tier 1 аналітик (сценарій "Петя о 9:00")

Кому це: новим Tier 1 SOC аналітикам, які щойно прийшли в команду. Старші аналітики можуть пропустити.

Стиль: конкретний сценарій з робочого дня — що саме бачить аналітик у браузері, куди клікає, які рішення приймає. Доповнення до 005. SOC Workflow (там — загальна теорія ролей та маршрутизації).

9:00 — Петя сідає за робоче місце

Він відкриває браузер. У нього 3 закладки завжди відкриті (SOC стандарт):

  1. Microsoft Teams — канали SIEM-Alerts (нічні тривоги) + API-Limits (службові сповіщення Cortex)
  2. TheHive — https://thehive.nasbu.edu.ua — основний робочий UI, черга alerts для triage
  3. Wazuh Dashboard — https://wazuh.nasbu.edu.ua — вторинний UI, для health-check i deep drill-down коли потрібна ширша історія

Опційно (якщо чергує і з threat intel): MISP (https://misp.nasbu.edu.ua).

Чому TheHive — головний, а Wazuh — вторинний?

Це типова помилка мисляти "Wazuh = центр SOC, туди я заходжу працювати". Насправді:

Wazuh Dashboard TheHive Alerts queue
Що там ВСЕ (2.3M подій/добу з усіх агентів, FIM, vuln scans, compliance, health метрики, top rules) Тільки level ≥ 10 alert'и (~100-1000/добу), які вимагають триажу
Роль "Рентген-архів" — історичний пошук, метрики, health "Стіл триажної медсестри" — хто щойно прийшов з тривожним симптомом
Workflow Read-only перегляд + пошук Interactive: 📄 Preview and Import на рядку alert'а → модальне вікно з observables → кнопка Import (→ стає Case) або Cancel
Робочий час на UI ~5-10 хв на зміну (health check) ~80-95% часу Tier 1

Аналогія: приймальне відділення лікарні.

  • TheHive = стіл триажної медсестри у приймальному. Сюди приводять пацієнтів з тривожними симптомами. Медсестра вирішує: "у палату" (Preview and Import → Case) чи "додому — застуда" (Ignored).
  • Wazuh Dashboard = рентген-архів лікарні. Лежать ВСІ знімки: здорові, хворі, профілактичні. Лікар приходить коли треба подивитись конкретний знімок у контексті історії.

Аналітик не "живе у рентген-архіві" — живе у приймальному.

Velociraptor, Cortex, Shuffle — не щоденні для Tier 1:

  • Cortex кличе сам з TheHive (клік на observable → автоматична enrichment).
  • Velociraptor — інструмент Tier 3 / IR (форензика конкретного host'а).
  • Shuffle — інструмент SOC Engineer'а (пише playbook'и, не використовує щодня).

9:01 — Teams канал SIEM-Alerts

Петя гортає нічні повідомлення з 18:00 до 9:00 (за 15 годин). Кожне — Adaptive Card формату:

  • Заголовок: Wazuh SOC Alert — 🟠 HIGH (Level 10) (або 🔴 CRITICAL level 12+, 🟡 MEDIUM level 8-9)
  • Rule: 5712 • sshd: brute force trying to get access to the system. Non existent user.
  • Agent: wazuh-manager (або інший CT/host де спрацював rule)
  • Source IP: 198.18.0.99
  • Time: 2026-04-15T14:53:00+0000
  • Full log: перші 500 символів сирого логу (щоб побачити контекст не відкриваючи інших UI)

За типову спокійну ніч — 5-15 повідомлень. За "шумну" (скан або brute force на публічну адресу) — до 100+.

!!! info "Майбутнє покращення (TASK-092d subtask 29)" Наразі картка не має кнопок для переходу у TheHive/Wazuh — аналітик переключає вкладки вручну. Заплановано додати:

- **"Open in TheHive"** — deep-link на конкретний Alert у TheHive (one-click)
- **"View in Wazuh Discover"** — deep-link у Wazuh Dashboard з pre-filter по rule+agent+time

Потребує рефакторингу ланцюга Wazuh integrations — `custom-thehive.py` має передавати створений Alert ID у `custom-teams.sh` (зараз вони незалежні скрипти).

Петя питає себе: "Чи нічна зміна (TheHive alerts queue) вже зайнялась тим що треба?" Відкриває наступну вкладку (ручне переключення — поки не реалізовані кнопки).

9:05 — TheHive черга alerts

У TheHive відкривається головна сторінка org Academy-SOC. Петя бачить:

┌─────────────────────────────────────────────────────┐
│   ALERTS  (17 unassigned)                             │
├─────────────────────────────────────────────────────┤
│ [Wazuh L10] sshd brute force from 82.149.x.x         │
│ Severity: 2 | Date: 03:42 | Status: New              │
│ Observables: ip=82.149.x.x, user=root                │
├─────────────────────────────────────────────────────┤
│ [Wazuh L10] Multiple web server 400 from 118.145.x.x │
│ ...                                                   │
└─────────────────────────────────────────────────────┘

Alert — тривога, ще НЕ підтверджена як реальна атака. Може бути шум (FP — false positive).

Case — вже підтверджена справа, яку розслідують.

Робота Tier 1 на alert (конкретні кліки у TheHive 4.1 UI):

У правій частині кожного рядка alert'а є 4 іконки з tooltip'ами:

Іконка Tooltip Що робить
📄 document Preview and Import Відкриває модал з повними деталями + observables + кнопкою Import внизу
👁 eye Ignore new updates Припинити reused updates цього alert'а (якщо Wazuh повторно шле той самий sourceRef)
✉️ envelope Mark as read / Mark as unread Toggle read стану
⚙️ gear Run responders Запустити Cortex responders (у нас нема responders → "No responders available")

Покроковий triage:

  1. Клік на 📄 (document) → відкривається модал Preview and Import з titles/observables/description/tags.
  2. У модалі можна запустити Cortex аналізатори на observables (кнопка біля кожного observable) — VirusTotal, AbuseIPDB, MISP. Через 5-10 сек — вердикт.
  3. Рішення на основі вердикту:
    • Toxic (VirusTotal detects, AbuseIPDB > 50%, MISP has matches) → клік Import внизу модала → alert стає Case → у Cases tab → автоматично призначається org-admin (у нашому org поки це Samuel).
    • Clean / low risk → клік Cancel на модалі, потім ⚙️ > tag Ignored-FP або просто ⚙️ "Mark as read" і пропустити.
  4. Для явно-bot noise (той самий rule 1000 раз/хв) — виділити чекбоксами зверху → bulk action "Delete" або "Mark as read".

!!! tip "Правило Tier 1" "Не треба бути героєм. Не розслідуй глибоко — просто triage: реальне/шум, важливе/неважливе. Реальне → передати Tier 2."

9:15 — Wazuh Dashboard: що в реальному часі

Петя переходить у Wazuh. Головна сторінка показує:

  • Security events — кількість подій за останні 24h (напр. 2.3M — нормально)
  • Agents status — скільки online (у нас 35, з них 35 active = всі ✅)
  • Active response — скільки banned за ніч (6 IP заблоковано CrowdSec)
  • Top 5 rules — які rule ID тригерились найчастіше (якщо раптом rule X спалахує 10k разів — це сигнал: або атака, або false positive rule треба підкрутити)

Петя залишає цю вкладку у фоні. Якщо вночі буде alert level ≥ 12 (critical) — Teams гуде негайно, а не раз на ніч.

9:30 — 12:00 — рутина

Петя дивиться Teams + TheHive queue кожні 30 хв. Якщо приходить alert — triage (див. 9:05). Якщо нічого нема — перевіряє метрики у Wazuh, читає tickets з вчорашнього дня, навчається.

Ключова метрика для Tier 1: "time to triage" — від появи alert у черзі до його перевірки. Ціль: < 15 хв.

Коли Tier 1 лазить у інші UI

Сервіс Коли Tier 1 відкриває Типова дія
Cortex Майже ніколи напряму — в 99% випадків TheHive кличе Cortex автоматично. Іноді, щоб перевірити аналізатор "чому вердикт такий" Відкрити Jobs → знайти конкретний run → подивитись raw output
Velociraptor Рідко — це інструмент Tier 3 / IR. Tier 1 може подивитись чи host онлайн у списку клієнтів перед тим як ескалувати Clients → пошук по hostname
MISP Якщо хочеться розширити контекст по конкретному IoC (хто ще цим поділився, в якому event) Search attributes
Shuffle Ніколи — це для SOC Engineer'а / Manager'а, хто налаштовує playbooks —

Чого НЕ робить Tier 1

  • ❌ Не розслідує глибоко. Побачив alert → triage → передав. Не витрачає годину на один кейс.
  • ❌ Не править Wazuh rules. Якщо rule видає 100 false positives — ескалує до SOC Engineer / Tier 2/3, не пише код сам.
  • ❌ Не блокує IP вручну. CrowdSec банить автоматично. Якщо потрібен ad-hoc ban — через Shuffle playbook, не через FortiGate CLI.
  • ❌ Не відповідає бізнесу. Питання "чи є ризик для компанії?" — до SOC Manager'а.

Ключові метрики Tier 1

Метрика Розшифровка Ціль
MTTD Mean Time To Detect — середній час виявлення < 5 хв (від події до alert у Teams)
MTTT Mean Time To Triage — середній час тріажу < 15 хв (від alert у Teams до закриття/ескалації)
FP rate False Positive rate — відсоток хибних тривог < 30% (якщо > 50% — Wazuh rules треба tuning)
Coverage Скільки агентів онлайн % від загалу > 95%

Куди копати далі

Природні продовження цієї теми (майбутні розділи handbook):

  1. Що конкретно робить Tier 2 коли отримує case від Tier 1? (alert → case → investigation workflow)
  2. Як Cortex автоматично розуміє що IP toxic? (VirusTotal + AbuseIPDB + MISP integration у деталях)
  3. Що таке proactive threat hunting і хто ним займається? (Tier 3 / Threat Hunter роль)
  4. Коли автоматичний CrowdSec ban = добре, а коли = катастрофа? (active response trade-offs)
  5. Алерт о 3 ночі level 14 — хто прокидається? (on-call rotation, escalation paths)
  6. Що таке false positive tuning і чому це 70% роботи Tier 1? (rule hygiene)

Останнє оновлення: 2026-04-15.