Runbook-ul pe hârtie

Originea

Pe 30 octombrie 1935, la baza aeriană Wright Field din Ohio, Boeing își prezenta noul bombardier, Model 299, viitorul B-17. Avionul era cel mai complex construit vreodată, cu patru motoare, flapsuri, elice cu pas variabil și tren de aterizare retractabil. La comenzi se afla maiorul Ployer Hill, pilotul-șef de încercări al armatei, unul dintre cei mai experimentați din țară. Avionul a decolat, s-a ridicat, s-a înclinat și s-a prăbușit. Hill și un alt membru al echipajului au murit. Cauza era un pas uitat — blocajul comenzilor, folosit la sol împotriva vântului, nu fusese eliberat înainte de decolare.

Concluzia unui ziar al vremii a fost că avionul era „prea mult pentru un singur om”. Concluzia piloților de încercare a fost alta. Avionul nu era prea complicat, dar memoria unui om, oricât de bun, sub presiune, nu este un loc sigur pentru o secvență de treizeci de pași. Au scris pe o foaie lista verificărilor dinaintea decolării, a decolării, a zborului și a aterizării. Cu lista, B-17 a zburat aproape două milioane de kilometri fără accident și a devenit avionul care a câștigat războiul aerian din Europa. Lista de verificare nu a fost o invenție tehnologică. A fost admiterea că, în cel mai important moment, experiența nu înlocuiește procedura.

Marina britanică avea de secole o variantă, Night Order Book, caietul în care căpitanul scria, înainte de a merge la culcare, ce trebuie să facă ofițerul de cart dacă se schimbă vântul, dacă apare un vas, dacă se rupe ceva. Caietul stătea pe masa de navigație, nu într-un sertar încuiat și nu în cabina căpitanului. Stătea acolo unde era nevoie de el, la ora la care era nevoie de el.

Surse: Atul Gawande, The Checklist Manifesto (2009), cap. 2, pentru accidentul Model 299; raportul oficial al Army Air Corps din 1935; N. A. M. Rodger, The Command of the Ocean (2004), pentru practica ordinelor de noapte.

Principiul

Un plan de răspuns la incidente care se află exclusiv în sistemele informatice ale organizației are o proprietate neplăcută. Devine inaccesibil exact în momentul în care este necesar. Ransomware-ul criptează și SharePoint-ul în care este planul, și serverul de e-mail prin care s-ar trimite, și agenda cu numărul avocatului.

Runbook-ul pe hârtie exploatează două invariante. Primul este independența de eșec — suportul planului nu trebuie să aibă nicio dependență comună cu sistemele pe care planul le salvează, iar hârtia nu are driver de rețea. Al doilea este decizia luată la rece pentru momentul fierbinte. În primele ore ale unui incident, oamenii nu gândesc clar. Lista spune ce să facă în ordine, astfel încât să nu fie nevoie să gândească clar, ci doar să citească și să bifeze.

Amenințarea de azi

Pe 27 iunie 2017, atacul NotPetya a lovit grupul de transport maritim Maersk. În câteva ore, aproximativ 49.000 de laptopuri și mii de servere erau inutilizabile, în 76 de porturi din întreaga lume. Angajații au trecut la WhatsApp pe telefoanele personale, la foi Excel pe laptopuri private și la hârtie pentru a continua să descarce containere. Compania a reconstruit infrastructura în aproximativ zece zile, iar pierderile raportate au fost de 250–300 de milioane de dolari. Detaliul care a salvat Maersk — un singur controler de domeniu din Ghana care supraviețuise pentru că o pană de curent îl deconectase în momentul atacului — spune totul despre cât de subțire este linia dintre recuperare și dezastru.

În martie 2019, producătorul norvegian de aluminiu Norsk Hydro a fost lovit de ransomware-ul LockerGoga în 170 de locații. Compania a refuzat să plătească, a trecut fabricile pe operare manuală și a condus timp de săptămâni pe baza procedurilor tipărite și a muncitorilor mai vechi care încă știau să opereze liniile fără calculator. Costul a fost de aproximativ 70 de milioane de dolari, dar producția nu s-a oprit.

Pentru o firmă românească de mărime medie, scenariul tipic este mai prozaic. Luni dimineață, nimeni nu se poate loga, pe ecrane este o notă de răscumpărare, iar planul de răspuns la incidente, dacă există, este un PDF pe serverul care tocmai a fost criptat. Primele patru ore se pierd căutând numărul firmei de IT și întrebându-se cine are voie să decidă ce.

Cum o implementezi luni dimineață

Firma de 20 de oameni

Pregătiți „pachetul de incident”, un dosar tipărit în două exemplare, unul la sediu, dar nu în camera serverelor, și unul acasă la director sau la un asociat. Conținutul lui, în ordinea în care este nevoie de el, este singura listă pe care merită să o ținem în această carte, pentru că lista este chiar tehnica.

1. Prima pagină, primele zece acțiuni. Deconectați de la rețea, fără să opriți, echipamentele afectate. Nu plătiți, nu negociați, nu reinstalați nimic. Fotografiați ecranele. Sunați persoanele de la punctul 2. Începeți jurnalul de la punctul 5.
2. Lista de telefoane, pe hârtie, cu numere personale — administratorul IT sau furnizorul de servicii IT, directorul, responsabilul cu protecția datelor, avocatul, banca pentru blocarea plăților, asiguratorul, furnizorul de internet, linia de urgență 1911 a Directoratului Național de Securitate Cibernetică.
3. Ce trebuie evaluat, notificat și în cât timp. Dacă sunt afectate date personale, evaluați riscul pentru persoanele vizate și documentați incidentul; dacă încălcarea este susceptibilă să genereze un risc, notificați ANSPDCP fără întârzieri nejustificate și, dacă este posibil, în cel mult 72 de ore de la luarea la cunoștință (art. 33 GDPR), iar dacă riscul este ridicat, informați și persoanele (art. 34). Dacă sunteți entitate NIS2 și incidentul este semnificativ în sensul legii, avertizare timpurie la DNSC în 24 de ore și notificare în 72 de ore. Clienții și partenerii, dacă îi afectează. Criteriile de evaluare stau scrise în dosar, ca să nu le decideți în panică.
4. Unde sunt copiile de rezervă și cum se restaurează fără acces la sistemele obișnuite, inclusiv parola consolei de backup, în plic sigilat (fișa 4).
5. Jurnalul incidentului — pagini goale, liniate, cu coloanele oră, cine, ce a făcut, ce a observat. Va fi cel mai important document la notificarea autorității și la discuția cu asiguratorul.

Păstrați și un laptop care nu a fost niciodată în domeniul firmei, cu un stick USB cu instalările de bază, pentru a avea de unde lucra.

Firma de 500 de oameni

Același pachet, dar pe roluri — o versiune pentru echipa de criză, una pentru IT, una pentru comunicare, una pentru fiecare sucursală. Exemplare tipărite stau la fiecare locație și la domiciliile a trei persoane din echipa de criză, iar o copie electronică pe un serviciu complet separat de infrastructura firmei, cu alt furnizor, alt cont și alte credențiale.

De două ori pe an se face un exercițiu pe masă. Se citește scenariul, se deschide dosarul, se urmează pașii cu ceasul în mână. Veți descoperi că trei numere de telefon sunt vechi și că nimeni nu știe cine are cheia de la camera serverelor. Acesta este scopul exercițiului.

Unde eșuează

Primul eșec este versiunea veche. Un runbook tipărit în 2023 și neactualizat are numărul fostului administrator IT. Puneți o dată pe copertă și un memento trimestrial în calendar. Al doilea este dosarul pe care nu-l găsește nimeni, pentru că stă „pe undeva prin biroul contabilei” în loc să fie în același loc, cunoscut de toată echipa de criză.

Al treilea este planul care presupune că sistemele merg. Dacă un pas spune „trimiteți e-mail la toți angajații”, planul nu a fost scris pentru ransomware. Apoi, hârtia se fură și arde, așa că dosarul conține numere de telefon și proceduri, nu parole în clar; parolele stau în plicuri sigilate separate.

Și, în sfârșit, runbook-ul nu înlocuiește pregătirea. Lista de verificare din 1935 funcționa pentru că piloții erau pregătiți și apoi aveau lista. Un runbook citit prima oară în timpul incidentului ajută, dar un runbook exersat salvează.

Cadrul legal

Art. 21 alin. (2) lit. (b) din Directiva NIS2 cere gestionarea incidentelor, iar lit. (c) continuitatea activității, gestionarea copiilor de rezervă și gestionarea crizelor; art. 23 impune, pentru incidentele semnificative, avertizarea timpurie în 24 de ore și notificarea în 72 de ore, termene greu de respectat fără un plan accesibil în afara sistemelor compromise. Sub GDPR, art. 33 cere evaluarea riscului și, când este cazul, notificarea autorității fără întârzieri nejustificate și, dacă este posibil, în 72 de ore de la luarea la cunoștință, iar art. 33 alin. (5) documentarea fiecărei încălcări, notificate sau nu; jurnalul pe hârtie este exact această documentare. În ISO/IEC 27001:2022, controalele A.5.24–A.5.28 (gestionarea incidentelor) și A.5.29–A.5.30 (continuitate și pregătirea TIC) acoperă întregul lanț.