Nejobtížnější část bezpečnostního incidentu obvykle přichází poté, co incident sám skončí: když firma musí vysvětlit, co se stalo, kdy byl odhalen, jaká data byla zasažena, kdo byl postižen a proč byla přijata určitá rozhodnutí.
U mnoha malých a středních podniků tyto záznamy neexistují v úplné podobě. Detaily mohou být rozptýlené v chatových zprávách, doručené poště, tiketech helpdesku, snímcích obrazovky a v paměti členů týmu. Firmy se během incidentu s těmito neúplnými záznamy udrží nad vodou, ale stanou se problémem, když orgány dohledu, pojišťovna, zákazník nebo člen představenstva požadují jasnou časovou osu.
Firmy všech velikostí potřebují důkladný log bezpečnostních incidentů. Měl by být jediným zdrojem pravdy pro zaznamenání toho, co se stalo, jak byl incident řešen a jaké důkazy podporují rozhodnutí přijatá v průběhu řešení.
Záznam je cenný, i když nemusíte incident hlásit. Vysvětlíme, proč jsou logy bezpečnostních incidentů užitečné pro vaši firmu a jak si vytvořit vlastní.
Proč jsou logy bezpečnostních incidentů důležité
Logy incidentů vs. plány reakce na incidenty
Co by měl log bezpečnostního incidentu obsahovat
Jednoduchá šablona logu incidentů pro malé a střední podniky
Jak zaznamenávat rozhodnutí o oznámeních
Co orgány dohledu očekávají od logů bezpečnostních incidentů
Log přístupu k přihlašovacím údajům
Proč jsou logy bezpečnostních incidentů důležité
Logy bezpečnostních incidentů vytvářejí odpovědnost v okamžiku, kdy firma nejspíš ztratí přehled o detailech. Během incidentu se akce dějí rychle: hesla se resetují, účty se deaktivují, kontaktují se poskytovatelé IT, kontrolují se zákaznická data a vedení je informováno. Tyto kroky mohou být přesně to, co firma v danou chvíli potřebuje, ale později se mnohem hůře vysvětlují, pokud nikdo nezaznamená, kdy k jednotlivým akcím došlo, kdo je schválil a jaké důkazy rozhodnutí podporovaly.
Pro firmy se sídlem v Evropě to není jen dobrá praxe. Podle obecného nařízení o ochraně osobních údajů (GDPR), a to jak ve Spojeném království, tak v EU, je třeba posuzovat úniky osobních údajů a některé z nich hlásit příslušnému orgánu dohledu.
Ve Spojeném království pokyny ICO pro nahlášení úniku(nové okno) vysvětlují, že organizace musí posoudit pravděpodobné riziko pro práva a svobody lidí a oznámit ICO, pokud je toto riziko pravděpodobné. Článek 33 rovněž vyžaduje, aby správci dokumentovali úniky osobních údajů, včetně skutečností o úniku, jeho dopadů a přijatých nápravných opatření. Stejné požadavky platí i podle GDPR v EU.
ICO například neočekává, že každý malý a střední podnik bude mít systémy na úrovni velkých firem, ale očekává přiměřené záznamy. Jeho rámec pro reakci na úniky a monitorování uvádí, že organizace by měly mít postupy, které zajistí, že incidenty a úniky osobních údajů jsou odhaleny, zvládnuty a odpovídajícím způsobem zaznamenány. To znamená, že log incidentu by neměl být vytvářen jen tehdy, když už k závažnému úniku došlo. Měl by být součástí běžného procesu reakce.
Dobré záznamy také podporují pojistné nároky. Kybernetičtí pojišťovatelé mohou požadovat důkazy o tom, kdy byl incident odhalen, jaká opatření k omezení dopadu byla přijata, které účty byly zasaženy a zda firma postupovala podle svého procesu reakce na incidenty. Dobře vedený log může ukázat, že firma jednala rychle a konzistentně.
Pomáhá to také firmě učit se. Vzpomínky a ústní záznamy nejsou spolehlivé, ale záznam, který ukazuje, že incident začal opětovně použitým heslem, chybějícím vícefaktorovým ověřením (MFA), přístupem dodavatele nebo opožděným ukončením přístupů, dává firmě něco konkrétního k opravě a jasnější směr k dlouhodobému posílení bezpečnosti.
Logy incidentů vs. plány reakce na incidenty
Log bezpečnostního incidentu a plán reakce na incidenty jsou propojené, ale nejde o stejný dokument.
Plán reakce na incidenty vysvětluje, co by firma měla dělat, když se něco pokazí. Přiděluje role, eskalační cesty, kroky k omezení dopadu, odpovědnosti za komunikaci a postupy obnovy. Log incidentu zaznamenává, co se skutečně stalo. Je časovou osou, stopou důkazů, záznamem rozhodnutí a souborem pro následné kroky u konkrétní události.
Tento rozdíl je důležitý, protože i dobrý plán může selhat bez dokumentace. Firma může postupovat správně, ale později to stále obtížně prokazuje. Log by měl umožnit odpovědět na praktické otázky: kdy jsme se to dozvěděli, kdo jednal, co jsme omezili, jaká data byla v ohrožení, co jsme rozhodli a co se poté změnilo?
| Plán reakce na incidenty: Co by vaše firma měla dělat | Log bezpečnostního incidentu: Co se skutečně stalo |
| Kdo vede reakci Kdo kontaktuje IT, právní oddělení, pojišťovnu nebo regulátory Jak omezit dopad, obnovit provoz a komunikovat | Kdy byl incident odhalen Které systémy a data byly zasaženy Jaké akce byly provedeny, kým a kdy |
Co by měl log bezpečnostního incidentu obsahovat
Užitečný log incidentu musí být dostatečně konzistentní, aby firma mohla později rekonstruovat událost a vysvětlit rozhodnutí přijatá během reakce.
Datum a čas odhalení
Zaznamenejte, kdy se firma o incidentu poprvé dozvěděla, kdo si ho všiml a jak byl odhalen. Pokud je čas přibližný, označte ho jako přibližný. Čas odhalení je důležitý, protože lhůty pro hlášení podle GDPR a požadavky pojišťoven často závisí na tom, kdy se firma o problému dozvěděla.
Povaha incidentu
Popište, co se stalo, srozumitelným jazykem. Vyhněte se vágním označením, jako je „bezpečnostní problém“ nebo „možný únik“, pokud chybí kontext. Log by měl vysvětlit, které systémy byly zasaženy a zda incident zahrnoval přihlašovací údaje, e-mail, soubory, zákaznická data, platební systémy, koncové body nebo přístup třetích stran.
Dotčená data
Pokud mohly být zasaženy osobní údaje, zaznamenejte, o jaký druh dat šlo: jména, e-mailové adresy, telefonní čísla, adresy, údaje o účtu, finanční informace, záznamy o zaměstnancích, komunikaci se zákazníky, přihlašovací údaje nebo jakoukoli jinou relevantní kategorii. Odhadněte, kolik jednotlivců může být zasaženo, a ujasněte, zda je počet potvrzený, nebo se stále vyšetřuje.
Pravděpodobná příčina
Zaznamenejte známou nebo předpokládanou příčinu, i když vyšetřování stále probíhá. Jak se objevují nové podrobnosti, log lze aktualizovat z „příčina neznámá“ na „phishingový e-mail vedl ke kompromitaci přihlašovacích údajů“ nebo „účet bývalého dodavatele zůstal aktivní“. Log by měl ukázat, jak se chápání firmy v průběhu času měnilo.
Bezprostřední opatření k omezení dopadu
Zdokumentujte, co bylo provedeno pro omezení škod. Může jít o resetování hesel, zrušení relací, vynucení MFA, pozastavení účtů, odstranění pravidel poštovní schránky, izolaci zařízení, odebrání přístupu dodavatele, změny firewallu nebo dočasné vypnutí služeb. Pokud je to možné, u každé akce uveďte vlastníka a časové razítko.
Rozhodnutí o oznámeních
Zaznamenejte, zda firma oznámila příslušnému orgánu dohledu (ve Spojeném království ICO, jinde v EU národnímu úřadu pro ochranu osobních údajů), zasaženým jednotlivcům, zákazníkům, dodavatelům, pojišťovnám, právním poradcům nebo orgánům činným v trestním řízení. Pokud se rozhodla neoznámit, zdokumentujte odůvodnění. Toto vysvětlení je často stejně důležité jako samotné oznámení.
Kroky k nápravě a časová osa
Omezení dopadu řeší bezprostřední incident. Náprava snižuje pravděpodobnost, že se stejný problém bude opakovat. Zaznamenejte následné kroky, jako je vynucení MFA, odstranění sdílených přihlašovacích údajů, aktualizace zásad přístupu, zlepšení ukončování přístupů, oprava chybné konfigurace nebo změna způsobu ochrany záloh.
Získané poznatky
Zakončete tím, co se firma naučila a co se změní. Nemělo by to být psáno jako obviňování. Mělo by identifikovat slabinu, potřebné zlepšení a kdo má na starosti následné kroky.
Jednoduchá šablona logu incidentů pro malé a střední podniky
Pro dokumentaci incidentů není nutný specializovaný software. Tabulka, zabezpečený interní formulář, systém pro správu tiketů nebo sdílený registr mohou fungovat, pokud je přístup řízen a záznamy jsou vedeny konzistentně.
Efektivní log incidentu by měl obsahovat tato pole:
- ID incidentu: Jedinečné referenční číslo.
- Datum a čas odhalení: Kdy se firma o incidentu dozvěděla.
- Nahlášeno od: Zaměstnanec, poskytovatel, zákazník, dodavatel, upozornění ze sledování nebo externí strana.
- Typ incidentu: Phishing, malware, kompromitace přihlašovacích údajů, ztráta dat, neoprávněný přístup, ransomware, incident u dodavatele, ztráta zařízení, e-mail na špatnou adresu nebo jiný.
- Shrnutí: Co se stalo, popsáno srozumitelným jazykem.
- Ovlivněné systémy: Aplikace, účty, zařízení, databáze, doručená pošta nebo služby třetích stran.
- Zasažená data: Zda byla zasažena osobní data, jaký typ a kolik lidí může být zasaženo.
- Pravděpodobná příčina: Známá, předpokládaná nebo prověřovaná.
- Opatření k zamezení šíření: Co bylo okamžitě provedeno.
- Rozhodnutí o oznámení: Dozorný orgán, dotčené osoby, zákazníci, pojišťovna nebo žádné oznámení s odůvodněním.
- Odkazy na důkazy: Snímky obrazovky, tikety, logy, e-maily, záznamy o přístupu, exportované soubory nebo zprávy poskytovatele.
- Nápravná opatření: Kroky provedené po zamezení šíření.
- Vlastník: Osoba odpovědná za další postup.
- Stav: Otevřeno, sledování, pod kontrolou, vyřešeno, uzavřeno.
- Poučení: Co by se mělo změnit.
Jak zaznamenávat rozhodnutí o oznámení
Rozhodnutí o oznámení si zaslouží vlastní prostor v logu bezpečnostních incidentů, protože se často přezkoumávají až po incidentu.
Podle britského i unijního GDPR musí organizace při úniku osobních údajů posoudit pravděpodobné riziko pro práva a svobody lidí. Pokud je riziko pravděpodobné, musí být dozorný orgán informován co nejdříve, a pokud je to možné, do 72 hodin, a to ve Spojeném království ICO(nové okno), v každém členském státě EU příslušný národní orgán pro ochranu osobních údajů. Pokud je riziko vysoké, musí být bez zbytečného odkladu informovány také dotčené osoby. Prahové hodnoty a lhůty jsou na obou stranách stejné, mění se pouze příslušný orgán.
Dobrý log incidentu by měl ukazovat, že firma toto posouzení provedla. Měl by zaznamenat, zda byly zapojeny osobní údaje, jaká újma by mohla vzniknout, jaké ochranné prvky byly zavedeny a proč se firma rozhodla incident nahlásit, nebo nenahlásit.
Například incident s odhaleným heslem správce nemusí okamžitě ukázat, zda došlo k přístupu k osobním údajům. Log by měl tuto nejistotu odrážet. Může zaznamenat prvotní obavu, kroky vyšetřování, kontrolu aktivity účtu a konečný závěr, jakmile jsou k dispozici důkazy.
V této fázi procesu se mnoho firem soustředí na organizaci technické nápravy a zapomíná zaznamenat odůvodnění z hlediska souladu s předpisy. Hesla se resetují, účty se zabezpečí a provoz pokračuje. O několik týdnů později firma nedokáže vysvětlit, proč se rozhodla, že incident není nutné hlásit.
Co dozorné orgány očekávají od záznamů
Dozorné orgány se nezajímají jen o to, zda byl únik nahlášen. Mohou se také ptát, jak firma:
- Identifikovala incident
- Posoudila riziko
- Rozhodla, zda bylo oznámení nutné
- Zdokumentovala přijatá opatření
Dobrý záznam by měl ujasnit průběh incidentu od začátku do konce. Měl by ukazovat, co se stalo, jaké osobní údaje byly zapojeny, jaká újma by mohla vzniknout, co firma udělala pro zamezení šíření problému a proč únik nahlásila, nebo nenahlásila.
Míra podrobností by měla odpovídat závažnosti incidentu. E-mail odeslaný na špatnou adresu nebude potřebovat stejný záznam jako útok ransomwaru, ale i tak musí být zdokumentován, aby bylo zřejmé, že firma incident řádně posoudila.
Tyto záznamy by také měly být bezpečně uloženy. Logy incidentů mohou obsahovat citlivé detaily o dotčených osobách, exponovaných systémech, jednání zaměstnanců, snímky obrazovky, přístupové logy nebo kroky k nápravě. Přístup by měl být omezen na osoby, které jej potřebují, a doba uchovávání by měla odpovídat širší zásadě společnosti pro uchovávání dat.
Log přístupu k přihlašovacím údajům
Mnoho incidentů zahrnuje přihlašovací údaje: mohou být způsobeny opakovaně použitým heslem, sdíleným účtem, kompromitovanou doručenou poštou, odhaleným přihlášením správce, podezřelou výzvou MFA nebo zaměstnancem, u něhož nebylo řádně provedeno ukončení přístupu.
Z tohoto důvodu se záznamy o přístupu k přihlašovacím údajům mohou stát přímým vstupem pro dokumentaci kybernetických incidentů. Když incident zahrnuje sdílené přihlášení nebo citlivý účet, firma potřebuje vědět, kdo měl přístup, jak byl přístup sdílen, zda se změnila oprávnění a zda byly přihlašovací údaje po incidentu obměněny.
Firemní správce hesel, jako je Proton Pass for Business, pomáhá týmům spravovat přihlašovací údaje v šifrovaných trezorech, generovat jedinečná hesla, používat automatické vyplňování, bezpečně sdílet přihlašovací údaje, spravovat přístupové klíče a používat vestavěné dvoufázové ověření. Pro dokumentaci incidentů je nejsilnější hodnotou přístupová stopa kolem přihlašovacích údajů: kdo měl přístup ke sdíleným trezorům/účtům, jak byl přístup spravován, kdo jej použil a co se po incidentu změnilo.
Správce hesel pro IT týmy přidává funkce pro správce, jako jsou zásady, reportování, logy, řízení přístupu na základě rolí, zřizování SCIM a integrace SSO. Tyto funkce mohou firmám pomoci ukázat, jak je přístup k přihlašovacím údajům kontrolován, a poskytnout důkazy při vyšetřování incidentu souvisejícího s přihlašovacími údaji.
Správce hesel nemůže nahradit log incidentu, právní posouzení, proces oznámení regulačním orgánům nebo plán reakce na incident. Poskytuje však důkazy o přihlašovacích údajích, které mohou vstoupit do těchto procesů.
Udržujte kompletní auditní stopu přístupu k přihlašovacím údajům pomocí firemního správce hesel.
