Incident Response

Proč potřebujete Incident Response¶

Otázka není JESTLI se incident stane, ale KDY. Organizace bez IR procesu:

• Detekují pozdě — průměrný dwell time (útočník v síti bez detekce) je 204 dní
• Reagují chaoticky — kdo má co dělat? Kdo rozhoduje? Kdo komunikuje?
• Opakují chyby — stejný incident za 3 měsíce, protože root cause nebyla opravena
• Eskalují špatně — buď příliš pozdě, nebo na špatné lidi

SIEM & Detekce¶

Sběr dat¶

Centralizujeme security events z celé infrastruktury:

• Infrastructure — Firewally, VPN, load balancery, DNS servery
• Identity — Azure AD/Okta login events, MFA failures, privileged access
• Application — WAF logy, API gateway, application security events
• Endpoint — EDR (CrowdStrike, Defender), antivirus, device compliance
• Cloud — Azure Activity Log, AWS CloudTrail, GCP Audit Log

Korelační pravidla¶

Surová data bez korelace jsou šum. Stavíme detection rules pro:

• Brute force — N failed logins z jedné IP za M minut
• Lateral movement — Unusual service-to-service komunikace
• Privilege escalation — User gains admin role, unusual sudo usage
• Data exfiltration — Large data transfer to unknown destination
• Credential abuse — Login from impossible location (GeoIP), credential stuffing patterns

Anomaly Detection¶

ML modely pro detekci neznámých hrozeb:

• Baseline normálního chování per uživatel, per služba
• Odchylky v access patterns, data volumes, API usage
• Alerting s kontextem — ne „anomálie detected”, ale „user X přistoupil k 500 záznamům v DB, průměr je 20”

Runbooky¶

Struktura runbooku¶

Každý runbook má jednotnou strukturu:

1. Detekce — Jak se incident projeví? Jaký alert ho triggerne?
2. Triage — Je to skutečný incident nebo false positive? Jaká je severity?
3. Containment — Zastavit šíření. Izolace postiženého systému.
4. Eradication — Odstranění příčiny. Patch, config change, revokace.
5. Recovery — Obnovení normálního provozu. Verifikace.
6. Post-incident — Timeline, lessons learned, action items.

Top 10 runbooků¶

Píšeme runbooky pro nejpravděpodobnější a nejimpaktovější scénáře:

1. Compromised credentials — Stolen password/token, unauthorized access
2. Ransomware — Encrypted files, ransom demand
3. DDoS — Service unavailable, traffic spike
4. Data breach — Unauthorized data access/exfiltration
5. Insider threat — Malicious or negligent employee action
6. Phishing — Successful phishing, compromised endpoint
7. Supply chain — Compromised dependency, malicious update
8. API abuse — Automated scraping, credential stuffing
9. Cloud misconfiguration — Exposed storage, public database
10. Certificate expiry — TLS certificate expired, service disruption

On-Call Procesy¶

Rotace a eskalace¶

• Primary on-call — Reaguje na alerty. Týdenní rotace.
• Secondary on-call — Backup, pokud primary nereaguje do 5 minut.
• Incident Commander — Pro SEV1/SEV2. Koordinuje response, komunikuje se stakeholdery.
• Eskalační matice — Jasně definované: kdo, kdy, jak. Žádné „zavolám, koho najdu”.

Severity Framework¶

Severity	Popis	Response Time	Komunikace
SEV1	Business down, zákazníci postiženi	15 min	War room, 15-min updates, exec notification
SEV2	Degradovaný výkon, partial outage	30 min	Slack channel, hourly updates
SEV3	Minor issue, workaround existuje	4h	Ticket, next business day
SEV4	Cosmetic, no impact	Backlog	Sprint planning

Kompenzace¶

On-call není zadarmo. Doporučujeme: - Příplatek za on-call dostupnost (i bez incidentu) - Extra kompenzace za noční/víkendové zásahy - „Day off” po noční eskalaci - Rotace, aby zátěž byla rovnoměrná

Post-Mortem¶

Blameless kultura¶

Post-mortem hledá systémové příčiny, ne viníky. „John udělal chybu” není root cause — „systém umožnil Johnovi udělat chybu bez safeguards” je.

Formát¶

1. Timeline — Co se stalo, chronologicky, s timestampy
2. Impact — Koho to postihlo, jak dlouho, finanční dopad
3. Root cause — Proč se to stalo (5 Whys)
4. Contributing factors — Co situaci zhoršilo
5. What went well — Co fungovalo (detekce, komunikace, recovery)
6. Action items — Konkrétní úkoly s vlastníky a deadliny
7. Lessons learned — Co se naučíme pro příště

Post-mortem databáze¶

Všechny post-mortemy v jednom místě (Confluence, Notion, Git). Vyhledávatelné, tagované. Nový člen týmu si přečte posledních 10 post-mortemů a ví víc o systému než z jakékoliv dokumentace.

Table-Top Exercises¶

Simulace incidentů bez reálného dopadu:

• Kvartální exercises pro IR tým
• Scénář: „Je pátek 17:00, zákazník nahlásil data breach. Co děláte?”
• Procvičení komunikace, eskalace, rozhodování
• Identifikace gaps v runboocích a procesech

Technologie¶

Elastic SIEM, Microsoft Sentinel, Splunk, Grafana Loki, PagerDuty, OpsGenie, Slack (incident channels), Jira (post-mortem tracking), Confluence (runbook repository), CrowdStrike, Microsoft Defender.