Pēc ransomware uzbrukuma: kā pierādīt, ka uzņēmums spēj atjaunoties?

Atjaunot vienu datubāzes kopiju testa serverī un atjaunot uzņēmuma darbību nav viens un tas pats. Biznesa process var prasīt identitātes pakalpojumu, DNS, tīkla maršrutēšanu, sertifikātus, lietojumprogrammu konfigurācijas, šifrēšanas atslēgas, piekļuvi ārējam maksājumu pakalpojumu sniedzējam un cilvēku, kuram ir tiesības pieņemt operatīvu lēmumu. Ja kaut viens no šiem priekšnosacījumiem nav pieejams, tehniski atjaunotā datubāze var palikt praktiski nelietojama.

Tāpēc atjaunošanās pārbaudē jānodala vismaz četri rezultāti: vai dati ir atgūstami; vai atgūtie dati ir uzticami un savstarpēji saskanīgi; vai no pārbaudīti tīras infrastruktūras iespējams palaist kritisko pakalpojumu; un vai biznesa īpašnieks pieņem šī pakalpojuma darbību kā pietiekamu. Pēdējais punkts ir būtisks. Lietojumprogrammas pieteikšanās ekrāns, kas ielādējas bez kļūdas, vēl nepierāda, ka var izpildīt pasūtījumu no sākuma līdz beigām, nosūtīt rēķinu, saskaņot atlikumu vai atjaunot klienta piekļuvi.

Ieteiktu katram kritiskajam procesam ieviest atjaunošanās pierādījumu ķēdi: sākotnējais apdraudējuma scenārijs → izvēlētie tīrie atjaunošanas avoti → infrastruktūras un identitātes atjaunošana → datu pārbaude → biznesa transakciju tests → faktiskie laika mērījumi → atbildīgā apstiprinājums. Tā ir šī raksta piedāvāta pārbaudes metode, nevis NIST vai CISA noteikta obligāta dokumenta forma.

RTO (recovery time objective) ir mērķis, cik ilgā laikā pēc traucējuma jāatjauno noteiktā funkcija vai pakalpojums. RPO (recovery point objective) raksturo pieļaujamo datu zudumu laikā, proti, cik senam stāvoklim organizācija ir gatava atgriezties. Abiem jābūt noteiktiem konkrētam pakalpojumam un saskaņotiem ar biznesa ietekmes analīzi; vienots RTO visai infrastruktūrai bieži noslēpj būtiskākās atkarības.

Pieņemsim ilustratīvu uzņēmumu, kura pasūtījumu apstrādei ir RTO četras stundas un RPO 30 minūtes. Testā lietojumprogrammu serveri tiek palaisti pēc divām stundām, taču pasūtījumu apstiprināšana atsākas tikai pēc septiņām, jo nav pieejama identitātes federācija un ārējās integrācijas atslēgas. Tehniskais komponents ir atjaunots, bet biznesa RTO nav sasniegts. Ja pēdējā derīgā datu kopija ir trīs stundas pirms incidenta noteiktā atskaites punkta, nav sasniegts arī RPO. Šie skaitļi ir hipotētisks aprēķina piemērs, nevis nozares statistika.

Ir vēl viena nianse: ransomware gadījumā jaunākā kopija ne vienmēr ir uzticamākā. Uzbrucējs var būt iekļuvis vidē pirms šifrēšanas, mainījis konfigurāciju, izveidojis neatļautus kontus vai bojājis datus. Tādēļ vajadzīgs atsevišķs lēmums par pēdējo pietiekami uzticamo atjaunošanas punktu. Tā izvēle var palielināt faktisko datu zudumu, un vadībai šī atšķirība jāredz. Microsoft Active Directory atjaunošanas dokumentācija arī skaidro, ka, atjaunojot domēna vidi no iepriekšējas kopijas, pēc izvēlētā punkta ieviestie objekti un izmaiņas var pazust S03.

Praktiskā atskaitē līdzās mērķiem jāparāda novērojumi: kad mērīšana sākās un beidzās, kad sasniegta minimālā pieņemamā pakalpojuma darbība, cik liels datu iztrūkums konstatēts, kuras transakcijas izgāzās un kuras atkarības paildzināja darbu. Bez vienotas laika atskaites sistēmas RTO un RPO salīdzināšana var kļūt par maldinošu skaitļu vingrinājumu.

Smagā incidentā kļūdaini ir pieņemt, ka esošā pārvaldības vide būs piemērota atjaunošanai. Ja uzbrucējam bijusi privileģēta piekļuve, apdraudēti var būt domēna administratori, rezerves kopiju konsoles, hipervizori, slepeno atslēgu krātuves un pat automatizācijas skripti. Šādos apstākļos pareizais pirmais jautājums nav “kurā serverī ielādēt kopiju?”, bet “no kādas neatkarīgi pārbaudītas kontroles vides mēs droši drīkstam sākt?”.

Sākuma secībai tipiski vajadzīga izolēta atjaunošanas vide, atsevišķas ārkārtas administratoru piekļuves, dokumentēta un pārbaudīta atslēgu atgūšanas procedūra, uzticami instalācijas materiāli, DNS un laika sinhronizācijas pakalpojumi. Pēc tam iespējams atjaunot identitātes un infrastruktūras pamatu, bet tikai tik plašā apjomā, cik nepieciešams izvēlēto biznesa pakalpojumu drošai atsākšanai. Konkrētā secība katrā organizācijā būs citāda, tāpēc tai jāizriet no atkarību kartes, nevis universāla serveru saraksta.

Microsoft norāda, ka Active Directory meža atjaunošanai attiecīgos scenārijos nepieciešams izvēlēties uzticamas kopijas, atjaunot domēnu kontrolierus un īstenot atjaunošanu izolēti, lai izvairītos no nevēlamas replikācijas ar bojāto vidi S03. Vienlaikus šīs instrukcijas nav pilnvērtīga kompromitēta domēna drošības izmeklēšanas metodika: Microsoft atsevišķi brīdina par šīs dokumentācijas tvēruma ierobežojumiem uzlauztas vides gadījumā S04. Tāpēc atjaunošanas instrukciju nevar aizstāt ar kompromitējuma likvidēšanas apliecinājumu. Pirms uzticēšanās atjaunotajai identitātes videi jāpārbauda noturīgas uzbrucēja piekļuves iespējas, privilēģijas, uzticamības attiecības, kontu un atslēgu rotācija un tīrās vides robežas atbilstoši incidenta izmeklēšanas secinājumiem.

Reālistisks tests sākas ar formulētu traucējumu: piemēram, “nav pieejama produkcijas domēna vide un rezerves kopiju administrēšanas sistēma; daļa jaunāko kopiju ir neuzticamas”. Jānosaka, kuri cilvēki drīkst izmantot ārkārtas piekļuves, kas apstiprina atjaunošanas punktu un kurš pieņem lēmumu par pieslēgšanu produkcijas tīklam. Tests nav ticams, ja dalībnieki jau iepriekš izmantojuši sagatavotu, ideāli strādājošu rezerves vidi, kura incidenta scenārijā faktiski nebūtu pieejama.

NIST atjaunošanās ceļvedis iesaka apvienot vingrinājumus ar praktiskiem testiem un balstīt tos reālistiskos scenārijos S01. Taču vadībai vienkāršs paziņojums “tests veiksmīgs” dod maz. Noderīgāk ir fiksēt pārbaudes rezultātu tā, lai cits atbildīgais var saprast, ko izdarīja, ko neizdarīja un kur joprojām pastāv risks.

Kontrolsumma ir noderīgs pierādījums tam, ka pārnestie baiti sakrīt ar sagaidāmo paraugu, ja pats paraugs ir uzticams. Tā pati par sevi nepierāda, ka sākotnējie dati nav bijuši ļaunprātīgi izmainīti pirms kopēšanas, ka ieraksti ir savstarpēji loģiski saskaņoti vai ka atjaunotās sistēmas darbība ir droša. Piemēram, grāmatvedības sistēmā jāspēj salīdzināt kontroles summas, ierakstu secības un biznesa atlikumus, nevis aprobežoties ar datubāzes startēšanas faktu.

Pēc katras nozīmīgas atjaunošanas pārbaudes būtu jāsaglabā vienots pierādījumu kopums. Tajā ietilpst testētais biznesa process un scenārija robežas, saskaņotie RTO/RPO, izmantoto sistēmu un atkarību versijas, izvēlēto kopiju identifikatori, izolācijas un piekļuves nosacījumi, izpildes laika žurnāls, kontrolsumma vai cita atbilstoša integritātes pārbaude, kritisko transakciju rezultāti, konstatētās novirzes un par tām atbildīgais. Īpaši nozīmīgs ir neizdevušos soļu saraksts — to nevajag izņemt no vadības kopsavilkuma, lai rezultāts izskatītos labāks.

Pierādījumiem jābūt reproducējamiem un aizsargātiem pret nepamanītām izmaiņām. Tas nenozīmē, ka žurnāli obligāti jāievieto vienā noteiktā produktā vai jāpublicē sensitīvas infrastruktūras detaļas. Pietiek ar pārbaudāmu glabāšanas un piekļuves kārtību, skaidru izcelsmi un saiti starp testa rezultātu un attiecīgo biznesa pakalpojumu. Ja atjaunošanas tests paveikts ar papildu ārpakalpojuma speciālistiem, iepriekš sagatavotām privileģētām piekļuvēm vai netipiski jaudīgu aprīkojumu, arī šie priekšnosacījumi jāatspoguļo. Pretējā gadījumā uzņēmums sev piedēvē spēju, kura reāla incidenta dienā var nebūt.

Valdei visvērtīgākais ir vienkāršs, bet stingri pamatots lēmuma formāts: pakalpojums; pieļaujamais pārtraukums; testā izmērītais pārtraukums; pieļaujamais datu zudums; faktiski konstatētais datu iztrūkums; drošības pieņemšanas statuss; neatrisinātās atkarības; nākamā pārbaude. No šādas atskaites var pieņemt budžeta un riska lēmumus. No zaļa rezerves kopēšanas indikatora — gandrīz nevienu.

Pirmais gadījums: atjaunošanas tests izdevies, jo identitātes sistēma testā palika dzīva. Ja reālajā incidentā tā pati sistēma ir kompromitēta, tests nav pierādījis pilna scenārija atjaunošanu. Iespējams, tas ir labs lietojumprogrammas vai datubāzes testa rezultāts, taču tas nevar kalpot par pierādījumu uzņēmuma atkopšanās spējai pēc privileģētas vides kompromitējuma.

Otrais gadījums: atjaunota ļoti jauna, bet neuzticama kopija. Testā pakalpojums sāk darboties ātri, tomēr kopijā atrodas neatļauta konfigurācija vai agrāk ievadīti bojāti dati. Uzņēmums ir atguvis pieejamību, bet vēl nav pierādījis datu integritāti un drošību. Šādu rezultātu var atzīmēt kā daļēji sasniegtu, nevis pasludināt par pilnu atjaunošanos.

Trešais gadījums: tehnoloģija darbojas, bet cilvēki un lēmumi nav pieejami. Ja atjaunošanas atslēgām piekļūst tikai viens darbinieks, ārpakalpojuma līgumā nav ārkārtas atbalsta vai juridiski nozīmīgai datu saskaņošanai vajadzīgs nesasniedzams apstiprinātājs, pakalpojuma darbības atjaunošana joprojām nav pierādīta. Kibernoturība ir tehnisku un organizatorisku spēju kopums; abas puses jāpārbauda vienā scenārijā.

Šie ir analītiski scenāriji, nevis konkrētu organizāciju dokumentēti incidenti. Tie ilustrē, kāpēc pārbaudes robežām jābūt redzamām atskaitē.

Sākumā nav nepieciešams izmēģināt vienlaikus visu uzņēmumu. Pirmajā ciklā jāizvēlas viens kritisks process un jāuzzīmē tā minimāli nepieciešamā atkarību ķēde, ieskaitot cilvēkus, identitātes pakalpojumus, tīklu, atslēgas, datu kopijas un ārējās integrācijas. Otrajā solī jāizpilda atjaunošana izolētā vidē ar apzināti ierobežotām priekšrocībām: nepieņemt, ka produkcijas domēna administrators, kopēšanas konsole vai jaunākā kopija ir droša. Trešajā solī jāmēra biznesa transakcija un datu zudums, jāfiksē šķēršļi un jāsaskaņo riska atlikums ar procesa īpašnieku.

Atkārtotā testā jāpierāda, ka iepriekš atklātais šķērslis patiešām novērsts. Ja pirmajā reizē izrādās, ka atslēgu atgūšana prasa piecas stundas, nepietiek ar jaunu procedūras aprakstu. Jāizmēģina atslēgu atgūšana no jauna. Tas pats attiecas uz identitātes vidi, tīkla segmentāciju, piegādātāju atbalstu un datu saskaņošanu. Atjaunošanās spējas pierādījums noveco, mainoties arhitektūrai, komandai, ārpakalpojumiem un apdraudējumu scenārijiem, tādēļ testu biežums jāizvēlas pēc riska un izmaiņām, ne tikai pēc kalendāra.

Nozīmīga ir arī robeža starp krīzes treniņu un bīstamu eksperimentu. Pilna apjoma ransomware imitācija produkcijas tīklā nav priekšnoteikums labam atjaunošanas testam. Var droši simulēt piekļuves nepieejamību, izmantot izolētu laboratoriju, sintētiskus vai kontrolēti maskētus datus un pārbaudīt lēmumus ar scenāriju mācībām. Šādi iegūtais pierādījums jāapraksta precīzi: laboratorijas tests apliecina konkrētu atjaunošanas ceļu laboratorijas nosacījumos; tas automātiski nepierāda visas ražošanas vides mēroga atjaunošanos.

Neviena pārbaude nevar garantēt, ka uzņēmums atjaunosies pēc jebkura nākotnes uzbrukuma. Uzbrucēja ilgstoša klātbūtne, nezināma kompromitējuma sākuma diena, vienlaicīgs mākoņpakalpojuma traucējums vai kritiska piegādātāja nepieejamība var mainīt situāciju. Taču tas nav arguments atteikties no mērījumiem. Gluži pretēji: jo precīzāk organizācija formulē, ko ir pārbaudījusi, jo skaidrāk redzams tās patiesais atlikušais risks.

Līdz ar to atbilde uz sākotnējo jautājumu ir praktiska. Uzņēmums var pamatoti apgalvot, ka spēj atjaunot konkrētu kritisku pakalpojumu pēc definēta ransomware scenārija, ja tas ir drošos apstākļos izpildījis un dokumentējis visu atkarību ķēdi, sasniedzis biznesa pieņemšanas kritērijus un izmērījis faktisko laiku un datu zudumu. Vispārīgs apgalvojums “mums ir rezerves kopijas, tātad esam gatavi” nav tāds pierādījums. Un atsevišķa testa panākums jāattiecina tikai uz tā pārbaudītajiem priekšnosacījumiem.