În textul de ieri, în cazul DRP am scris că include și ”izolarea sistemelor infectate: deconectarea mașinilor și rețelelor compromise pentru a opri răspândirea.” Afirmația aceasta a iscat o mică dezbatere pe Linkedin și mi s-a atras atenția că am făcut confuzia între Incident Response Plan (IRP) și Disaster Recovery Plan (DRP).

Am înțeles că ar fi trebuit să scriu cum se ”leagă” IM cu DRP atunci cînd un incident devine dezastru, chiar dacă nu am detaliat procesele specifice fiecăruia. Am revenit la final și am scris că textul meu nu a avut drept scop ”rigoarea academică” și nici nu m-am raportat la vreun standard. Poate fi greșit cum am scris din dorința de a simplifica/ușura lectura, dar confuzie nu am făcut. Explic raționamentul.

Pentru rigoare (ISO 27035, ISO 27031, ISO 27462 NIST 800-34 și cerințe legale) scriu acum că managementul incidentelor, Planul de răspuns la incidente de securitate sînt proceduri/procese din ”prăvălia” angajaților care se ocupă de securitate IT. Are definite faze și activități specifice (de exemplu praguri de semnificație).

DRP-ul este din prăvălia celor care se ocupă de operațional și vizează întreruperile pe termen lung care necesită relocarea infrastructurii IT (RTO, RPO….). La fel și aici, există faze și activități. Disponibilitatea ține de operațional dar este și una din cele trei caracateristici ale securității.

De ce totuși am trecut ”izolarea” acolo?

Să ne ducem spre situațiile practice și să luăm în discuție contextele diferite din organizațile autohtone. Și maturități diferite în primul rînd la nivelul managementului de la nivel înalt.

Prima întrebare este: cîte organizații au un proces de management incidente de securitate cibernetică ? Un răspuns cu o probabilitate mare de corectitudine este următorul: toate organizațiile care lucrează în domenii în care acest subiect este reglementat la nivel european/național (NIS1/2, DORA – unde există doar ”incidente legate de TIC”) sau care au certificări ISO27001 au cel puțin un document numit ”politică/procedură management incidente de securitate cibernetică”. Nu știu însă în cîte astfel de organizații procesul este operațional (testat) așa cum este descris în documente (în timpul unui audit am raportat un posibil incident la adresa de mail din procedură și nu am primit răspuns nici după o săptămînă). Am scris nu cu mult timp în urmă și că organizațiile cumpără SOCaaS…fără să știe ce cumpără (de exemplu SOC fără IM, doar ”monitorizare”, dar există totuși minunea de procedură de ”management incidente”)

Procesul de mai sus poate fi realizat fără anumite roluri (CISO, manager incidente, analist securitate, DPO, administratori IT etc) și fără instrumente software? Răspunsul este afirmativ dacă organizația este mică, evaluarea riscurilor a concluzionat că acestea sînt reduse iar pentru incidentele simple există funcțional un fel de ”plan de răspuns la incidente” (mai simplu spus instrucțiuni (playbook). Altfel spus, ”banii intră în cont”/”apa curge”, nimeni nu moare/pierde bani chiar dacă IT-ul este indisponibil X zile.

Cîte organizații ”mici” și cu profil redus de risc există în România? Nu știu.

Cîte organizații medii-mari există și care au procesul de IM doar pe hîrtie, fără roluri suficiente sau/și instrumente software? Las experiența ta cititorule să răspundă.

Exemplul de la care am scris textul de ieri este unul real: un atac ransomware a criptat 80% din echipamentele unei organizații. Totul este blocat. Organizația NU are ”manager/coordonator de incidente”, ”procedură”, „playbook”, aplicație, SOC etc. Doar 4 angajați la IT (la cîteva sute de active și cam toți atîți utilizatori), cei care sînt ”all in” – factotum. Și nici nu va avea mai mulți în viitorul apropiat.

”Directorului IT” (pompos spus director, de fapt un sysadmin, operațional) i se raportează ”problema” (căci cei din operațional nu cunosc termenul ”incident” deși toată lumea a beneficiat de cursuri de ”instruire și conștientizare”) și înțelege pe loc amploarea și impactul. Nu există backup la zi, ultimul are o vechime de 3 luni. Nu există ”al doilea site”/”site de recuperare”/”cloud”/”3-2-1” etc. Pentru că la IT nu prea există buget iar securitatea este un cost care nu prea ”întoarce rezultate”. Trec cîteva ore pînă cînd managementul superior înțelege că ”incidentul” (pentru alții) este un…..”dezastru” (pentru ei). Fără ”detection, triage” etc căci, așa cum spuneam nu există ”IT security”. Ar trebui să se activeze un DRP. Nu există nici ăsta și totuși se lucreză ordonat și nu haotic. Pe bază de experință, cunoaștere și….cunoștințe.

Managementul (și nu IT-ul) sună la furnizorul care oferă și echipamente de rețea și consultanță. Prima cerință pe care o primesc telefonic: deconectarea/oprirea tuturor echipamentelor afectate. Pentru că nu este timp de nimic altceva decît de recuperat sistemele și datele cât mai rapid și sigur posibil, se caută servere în piață pentru a ridica acele backup-uri. Puțin este mai bun decît deloc…După cîteva zile se pornește și analiza incidentului cu o altă companie specializată.

Concluzie

Pentru realități ca cea descrisă mai sus, , am considerat că DRP începe cu ”izolarea” chiar dacă este activitate de la managementul incidentelor. Același angajat a executat o activitate care aparține în teorie unui proces (management incidente) și mai multe activități corespunzătoare altui proces (recuperare). Practic însă el execută un singur proces: recuperare/restaurare.

Pentru a evita orice confuzie trebuia să scriu că sînt două procese distincte care merg de mînă….