Prvních 24 hodin po incidentu

Odkdy se těch 24 hodin vlastně počítá?

Od zjištění incidentu, ne od chvíle, kdy firma pochopí, co se stalo. To je celý problém té lhůty. V okamžiku, kdy vám někdo řekne „nejde přihlášení do skladu a na sdíleném disku jsou přejmenované soubory“, začíná běžet čas, i když ještě nikdo neví, jestli jde o útok, chybu zálohy, nebo omyl administrátora.

Prvotní hlášení přitom nechce vyšetřování. Obsahuje identifikační údaje organizace a základní údaje o incidentu, tedy to, co v tu chvíli víte. Jaké další lhůty pak běží a které incidenty se vůbec hlásí, rozebírá článek o zákonu o kyberbezpečnosti, protože rozsah povinnosti se liší podle režimu.

Co musí být rozhodnuté předem?

Pět věcí, a žádná z nich se nedá vymyslet v den, kdy je potřeba. Rozhoduje se o nich ve chvíli, kdy je klid, protože jinak se v první hodině improvizuje o tom, kdo má právo co udělat:

• Kdo hlášení odešle a kdo ho odešle, když je ten člověk na dovolené.
• Odkud vezme údaje o postiženém systému, tedy jestli existuje mapa aktiv.
• Kdo smí rozhodnout o odpojení systému od sítě, i když tím zastaví provoz.
• Kdo mluví se zákazníky a s médii, a co se říká, dokud se neví.
• Kam se zapisuje časová osa, protože tu bude chtít vidět úřad i pojišťovna.

Tohle je zároveň odpověď na otázku, proč se bezpečnost nedá koupit jako produkt. Většina těch rozhodnutí je organizační, ne technická, a musí je udělat vedení, ne dodavatel.

Proč je detekce těžší část než hlášení?

Protože lhůta běží od zjištění, ale nikde není napsáno, že se zjistí rychle. Firma bez dohledu se o incidentu dozví obvykle tak, že něco přestane fungovat, případně že se ozve někdo zvenčí. Do té doby útočník v prostředí je, jen o tom nikdo neví, a formálně lhůta ještě neběží.

Praktický důsledek je nepříjemný: firma, která nic nemonitoruje, může formálně lhůty plnit a přitom být v horší situaci než ta, která incident objevila druhý den a hlásila ho pozdě. Proto má smysl řešit monitoring dřív než šablonu hlášení.

Co dělat v prvních hodinách a co naopak ne?

Zastavit šíření, zachovat stopy a psát si, co se kdy stalo. Izolace postiženého stroje je obvykle správný první krok, ale vypnutí a přeinstalování je ten nejčastější drahý omyl: s ním zmizí i to, z čeho by se dalo zjistit, jak se útočník dostal dovnitř a kam všude se dostal.

Druhý omyl je mlčení dovnitř firmy. Lidé, kteří nevědí, že je incident, dělají normální věci: přeposílají soubory, obnovují ze zálohy a mění hesla na místech, kam se útočník dívá. Informovat je proto přednější než napsat tiskovou zprávu.

Co se ukáže o zálohách až ve špatný den?

Že existovat nestačí. Při ransomwaru rozhoduje, jestli je záloha z doby před napadením, jestli se k ní útočník nedostal stejnými přístupy jako ke zbytku sítě a jak dlouho trvá obnova celého provozu, ne jednoho souboru. Odpověď na poslední otázku je obvykle ta nepříjemná: obnovení se zkouší na jednom dokumentu, zatímco v krizi jde o desítky systémů naráz.

Proto jsou plány kontinuity provozu a obnovy dokumenty, které se píšou dopředu a jednou za čas zkoušejí. Bez zkoušky je to seznam přání: v něm stojí, že se provoz obnoví, ale nikdo neví za jak dlouho a v jakém pořadí, a právě pořadí rozhoduje, jestli firma po dvou dnech vydává zboží, nebo jen čte e-maily.

Kdo to všechno dělá, když nemáte bezpečnostní roli?

Buď někdo z vašich lidí, nebo externí role, se kterou je to domluvené předem. Součástí služby ICT služeb je nastavení postupu pro případ napadení, takže se v tu chvíli neimprovizuje, a IT kontrola zjistí ještě předtím, jestli je firma na útok připravená. Securent k tomu přidává vyšetřování incidentů, komunikaci s NÚKIB a plány kontinuity provozu a obnovy.

Ať to dělá kdokoli, platí jedno: povinnost hlásit má organizace. Dodavatel může připravit podklady a jednání vést nebo podpořit, ale adresátem té povinnosti zůstáváte vy. Z toho plyne i jediný test, jestli je váš postup skutečně připravený: zkuste si ho projít nanečisto v den, kdy se nic neděje.