insident risponsTakéIR, Řešení bezpečnostních incidentů, Incident handlingPokročilý
Definice
Incident response je organizovaný postup, kterým firma detekuje bezpečnostní incident, omezí jeho dopad, odstraní příčinu, obnoví provoz a vyhodnotí, co selhalo. Zahrnuje předem připravený plán, definované role, komunikaci se zákazníky i regulátorem a sběr důkazů. Cílem není jen zastavit útok, ale zkrátit dobu, po kterou útočník zůstává v systému nepovšimnut.
Nezaměňujte: V ITIL označuje incident management obnovu běžné dostupnosti služby po výpadku, zatímco incident response se v bezpečnosti týká reakce na útok nebo únik dat.
Než se na to spolehnete: Odkaz na Wikidata Q-identifikátor jsem si nemohl ověřit, prosím o kontrolu nebo odstranění. Stejně tak URL na csrc.nist.gov a uoou.gov.cz doporučuji ověřit; u ÚOOÚ cituji kořen webu, protože si nejsem jistý přesnou cestou ke stránce o ohlašování.
Proč se incident řeší podle scénáře, ne podle intuice
Incident response existuje kvůli tomu, že v hodině útoku nikdo nepřemýšlí jasně. Když v noci přijde upozornění na podezřelý odchozí provoz z produkční databáze, tým bez plánu začne improvizovat: někdo vypne server, čímž smaže obsah paměti a s ním důkazy, jiný napíše zákazníkům dřív, než ví, co se vlastně stalo. Připravený postup rozděluje role, určuje, kdo rozhoduje o odstavení služby, a stanoví, co se smí říct navenek.
Fáze reakce na incident
Fáze reakce na incident se v praxi drží životního cyklu popsaného v NIST SP 800-61. Příprava znamená logování, zálohy, kontakty a nacvičené scénáře. Detekce a analýza rozhoduje, zda jde o skutečný incident, nebo o falešný poplach, a jak je rozsáhlý. Zadržení (containment) omezí šíření: izolace stanice, zneplatnění relací a rotace klíčů. Eradikace odstraní příčinu, typicky zneužitou zranitelnost nebo ukradený token. Obnova vrací systémy do provozu pod zvýšeným dohledem. Poslední fází je vyhodnocení, ze kterého vzniká seznam konkrétních změn.
Zadržení je vždycky kompromis
Zadržení staví tým před volbu mezi rychlostí a poznáním. Okamžité odpojení útočníka zastaví škodu, ale zároveň ho varuje a připraví vás o možnost sledovat, kam sahá. Delší pozorování dá lepší obrázek o rozsahu, ovšem každá další minuta je riziko exfiltrace dat. Rozhodnutí patří určené osobě s pravomocí, ne diskuzi v chatu.
Postmortem bez hledání viníka
Postmortem má smysl jen tehdy, když se lidé nebojí popsat, co udělali. Kultura blameless postmortem předpokládá, že chybu umožnil systém: chyběl alert, chyběl čtyřoční princip, nasazení šlo mimo pipeline. Výstupem je několik úkolů s termínem a vlastníkem, jinak se stejný incident zopakuje.
Právní lhůty, které běží od zjištění
Právní lhůty mění incident response z čistě technické disciplíny na proces s termíny. Podle GDPR se porušení zabezpečení osobních údajů ohlašuje dozorovému úřadu bez zbytečného odkladu, nejpozději do 72 hodin od okamžiku, kdy se správce o porušení dozvěděl; pokud hrozí vysoké riziko pro dotčené osoby, informují se i ony. Poskytovatelé služeb spadající pod směrnici NIS2 a český zákon o kybernetické bezpečnosti mají vlastní hlásicí povinnosti vůči NÚKIB. Proto do plánu patří i právník a odpovědná osoba za komunikaci, ne jen administrátoři.
Co se měří
Kvalita reakce se měří časem. MTTD (mean time to detect) říká, jak dlouho útočník zůstal neviditelný, MTTR (mean time to respond nebo recover) jak rychle se podařilo situaci zvládnout. Užitečné je i procento incidentů odhalených vlastní detekcí místo hlášení od zákazníka nebo výzkumníka. Phishing zůstává nejčastějším vstupním bodem, takže cvičné scénáře obvykle začínají právě jím.
Příklady z praxe
Uniklý přístupový klíč v repozitáři
Vývojář omylem commitne AWS klíč do veřejného repozitáře a do několika minut se objeví neobvyklé spouštění instancí. Tým klíč okamžitě deaktivuje, projde CloudTrail kvůli rozsahu zneužití a vytvoří nový klíč mimo kód. Odstranění commitu z historie samo o sobě nestačí, protože klíč byl už zkopírován roboty.
# 1. okamžitě zneplatnit klíč, ne až po úklidu historie aws iam update-access-key --access-key-id AKIA... --status Inactive # 2. zjistit, co se s ním dělo aws cloudtrail lookup-events --lookup-attributes \ AttributeKey=AccessKeyId,AttributeValue=AKIA...Kompromitovaná relace administrátora e-shopu
Zákaznická podpora hlásí změněné bankovní údaje u výplat dodavatelům. Analýza logů ukáže přihlášení administrátora z neznámé IP hodinu po phishingovém e-mailu. Tým zneplatní všechny relace, vynutí reset hesel a zapne dvoufaktorové ověření, teprve pak dopočítá škodu z auditního logu změn.
-- zneplatnění všech aktivních relací administrátorů UPDATE sessions SET revoked_at = now() WHERE user_id IN (SELECT id FROM users WHERE role = 'admin');
Časté omyly
- MýtusNapadený server je nejlepší hned vypnout.
- Ve skutečnostiVypnutí smaže obsah operační paměti, kde bývají klíče, běžící malware i síťová spojení. Doporučený postup je systém izolovat od sítě a paměť zajistit, teprve pak řešit vypnutí.
- MýtusIncident response je věc bezpečnostního oddělení, vývoj se do toho neplete.
- Ve skutečnostiVětšinu kroků, jako je rotace tajemství, nasazení opravy nebo dohledání dat v logu, provádějí vývojáři a provoz. Bezpečnostní tým řídí postup, ale bez lidí, kteří systém znají, se nikam nedostane.
- MýtusKdyž jsme incident zvládli, není co hlásit.
- Ve skutečnostiOhlašovací povinnost podle GDPR se odvíjí od rizika pro dotčené osoby, ne od toho, jestli jste útok zastavili. Únik osobních údajů se hlásí i tehdy, když byl útočník rychle vyhozen.
Časté dotazy
- Co má obsahovat plán incident response v malé firmě?
- Plán incident response ve firmě bez vlastního bezpečnostního týmu stačí na několik stran. Patří do něj seznam kritických systémů a dat, kontakty na lidi s přístupem k nim včetně externího dodavatele, jméno člověka, který rozhoduje o odstavení služby, postup pro rotaci hesel a klíčů, místo kde se sbírají poznámky a důkazy, a šablona hlášení pro dozorový úřad. Důležitá je také kopie plánu mimo firemní systémy, protože při ransomwaru se k intranetu nedostanete.
- Kdo tvoří tým pro řešení bezpečnostních incidentů?
- Tým pro řešení bezpečnostních incidentů má obvykle velitele incidentu, který rozhoduje a nekopá se přitom v technice, jednoho nebo dva analytiky pro logy a forenzní stopy, správce systémů a sítí pro zásahy, vývojáře znalého dotčené aplikace, právníka kvůli ohlašovacím lhůtám a osobu pro komunikaci se zákazníky i médii. V menší organizaci jeden člověk zastane víc rolí, ale role by měly být pojmenované předem, ne přidělované během útoku.
- Jak často se má plán reakce na incident cvičit?
- Plán reakce na incident se obvykle cvičí alespoň jednou ročně, u kritických služeb dvakrát až čtyřikrát. Nejlevnější formou je tabletop cvičení: tým si u stolu projde konkrétní scénář, třeba ransomware na souborovém serveru, a nahlas řekne, co by udělal a kde by hledal. Typicky se přitom najdou banální díry, například že nikdo nezná telefon na poskytovatele hostingu nebo že záloha se nikdy nezkoušela obnovit. Cvičení se doplňuje ostrým testem obnovy ze zálohy.
- Kdy volat externí forenzní firmu?
- Externí forenzní firmu má smysl volat, když jde o ransomware, podezření na dlouhodobý průnik do vnitřní sítě, únik osobních údajů většího rozsahu nebo situaci, kde hrozí soudní spor či pojistné plnění. Externí specialisté umí zajistit důkazy způsobem, který obstojí, a mají zkušenost s konkrétními skupinami útočníků. Praktické je smlouvu sjednat dopředu formou retaineru, protože hledání dodavatele uprostřed incidentu stojí hodiny, které nemáte.
Zdroje
- Computer Security Incident Handling Guide (SP 800-61)(otevře se v novém okně)
- Nařízení (EU) 2016/679 (GDPR)(otevře se v novém okně)
- Ohlašování případů porušení zabezpečení osobních údajů(otevře se v novém okně)
- OWASP Cheat Sheet Series(otevře se v novém okně)
Související pojmy
