Partea cea mai dificilă a unui incident de securitate apare de obicei după ce incidentul în sine s-a încheiat: când afacerea trebuie să explice ce s-a întâmplat, când a fost descoperit, ce date au fost implicate, cine a fost afectat și de ce au fost luate anumite decizii.
Pentru multe IMM-uri, aceste înregistrări nu există într-o formă completă. Detaliile pot fi răspândite prin mesaje de chat, inboxuri, tichete de asistență, capturi de ecran și în memoria membrilor echipei. Afacerile se mențin pe linia de plutire în timpul unui incident cu aceste înregistrări fragmentare, dar acestea devin o problemă când autoritățile de supraveghere, un asigurător, un client sau un membru al consiliului de administrație cer o cronologie clară.
Afacerile de toate dimensiunile au nevoie de un jurnal amănunțit al incidentelor de securitate. Acesta ar trebui să fie o sursă unică de adevăr pentru a înregistra ce s-a întâmplat, cum a fost gestionat incidentul și ce probe susțin deciziile luate pe parcurs.
Înregistrarea este valoroasă chiar și atunci când nu trebuie să raportați un incident. Vom explica de ce jurnalele incidentelor de securitate sunt utile pentru afacerea dumneavoastră și cum să vă creați propriile jurnale.
De ce contează jurnalele incidentelor de securitate
Jurnalele incidentelor vs planurile de răspuns la incidente
Ce ar trebui să conțină un jurnal al incidentelor de securitate
Un model simplu de jurnal al incidentelor pentru IMM-uri
Cum să înregistrați deciziile privind notificarea
Ce așteaptă autoritățile de supraveghere de la jurnalele incidentelor de securitate
Jurnalul de accesare a acreditărilor
De ce contează jurnalele incidentelor de securitate
Jurnalele incidentelor de securitate creează responsabilitate în momentul în care o afacere este cel mai probabil să piardă urma detaliilor. În timpul unui incident, acțiunile se desfășoară rapid: parolele sunt resetate, conturile sunt dezactivate, furnizorii IT sunt contactați, datele clienților sunt verificate și conducerea este informată. Acești pași pot fi exact ceea ce are nevoie afacerea în acel moment, dar devin mult mai greu de explicat mai târziu dacă nimeni nu înregistrează când s-a întâmplat fiecare acțiune, cine a aprobat-o și ce probe au susținut decizia.
Pentru afacerile din Europa, aceasta nu este doar o bună practică. Conform Regulamentului general privind protecția datelor (GDPR), atât în Regatul Unit, cât și în UE, încălcările securității datelor cu caracter personal trebuie evaluate, iar unele trebuie raportate autorității de supraveghere competente.
În Regatul Unit, ghidul ICO privind raportarea unei încălcări(fereastră nouă) explică faptul că organizațiile trebuie să evalueze riscul probabil la adresa drepturilor și libertăților persoanelor și să notifice ICO atunci când acest risc este probabil. Articolul 33 le impune, de asemenea, operatorilor să documenteze încălcările securității datelor cu caracter personal, inclusiv faptele încălcării, efectele acesteia și acțiunile de remediere întreprinse. Aceleași cerințe se aplică în temeiul GDPR al UE.
De exemplu, ICO nu se așteaptă ca fiecare IMM să aibă sisteme de nivel enterprise, dar se așteaptă la înregistrări adecvate. Cadrul său de răspuns la încălcări și monitorizare spune că organizațiile ar trebui să aibă proceduri pentru a se asigura că incidentele și încălcările privind datele cu caracter personal sunt detectate, gestionate și înregistrate în mod corespunzător. Aceasta înseamnă că un jurnal al incidentelor nu ar trebui creat doar atunci când a avut deja loc o încălcare gravă. Ar trebui să facă parte din procesul normal de răspuns.
Înregistrările bune susțin, de asemenea, cererile de despăgubire către asigurători. Asigurătorii cibernetici pot cere dovezi privind momentul descoperirii incidentului, măsurile de izolare luate, conturile afectate și dacă afacerea a urmat procesul de răspuns la incidente. Un jurnal bine ținut poate arăta că afacerea a acționat prompt și consecvent.
De asemenea, ajută compania să învețe. Amintirile și înregistrările verbale nu sunt fiabile, dar o înregistrare care arată că incidentul a început cu o parolă reutilizată, lipsa autentificării multifactor (MFA), accesul unui furnizor sau un offboarding întârziat oferă afacerii ceva concret de remediat și o direcție mai clară pentru consolidarea securității în timp.
Jurnalele incidentelor vs planurile de răspuns la incidente
Un jurnal al incidentelor de securitate și un plan de răspuns la incidente sunt conectate, dar nu sunt același document.
Un plan de răspuns la incidente explică ce ar trebui să facă afacerea atunci când ceva merge prost. Acesta atribuie roluri, rute de escaladare, măsuri de limitare, responsabilități de comunicare și proceduri de recuperare. Jurnalul incidentelor înregistrează ce s-a întâmplat de fapt. Acesta este cronologia, lanțul de probe, registrul deciziilor și dosarul de urmărire pentru un anumit eveniment.
Această distincție contează pentru că până și un plan bun poate să nu reușească fără documentație. O afacere poate urma pașii corecți, dar poate întâmpina dificultăți în a dovedi acest lucru mai târziu. Jurnalul ar trebui să permită răspunsul la întrebări practice: când am aflat, cine a acționat, ce am limitat, ce date au fost expuse riscului, ce am decis și ce s-a schimbat ulterior?
| Plan de răspuns la incidente: Ce ar trebui să facă afacerea dumneavoastră | Jurnal al incidentelor de securitate: Ce s-a întâmplat de fapt |
| Cine conduce răspunsul Cine contactează IT-ul, departamentul juridic, asigurătorul sau autoritățile de reglementare Cum să limitați, să recuperați și să comunicați | Când a fost descoperit incidentul Ce sisteme și date au fost afectate Ce acțiuni au fost întreprinse, de către cine și când |
Ce ar trebui să conțină un jurnal al incidentelor de securitate
Un jurnal al incidentelor util trebuie să fie suficient de consecvent pentru ca o afacere să poată reconstrui evenimentul ulterior și să explice deciziile luate în timpul răspunsului.
Data și ora descoperirii
Înregistrați când afacerea a luat cunoștință pentru prima dată de incident, cine l-a observat și cum a fost descoperit. Dacă ora este aproximativă, marcați-o ca fiind aproximativă. Momentul descoperirii contează deoarece termenele de raportare GDPR și cerințele asigurătorilor depind adesea de momentul în care afacerea a luat cunoștință de problemă.
Natura incidentului
Descrieți ce s-a întâmplat într-un limbaj simplu. Evitați etichetele vagi precum „problemă de securitate” sau „posibilă încălcare” fără context. Jurnalul ar trebui să explice ce sisteme au fost afectate și dacă incidentul a implicat acreditări, e-mail, fișiere, date ale clienților, sisteme de plată, puncte finale sau acces din partea unor terți.
Datele implicate
Dacă este posibil ca datele cu caracter personal să fi fost afectate, înregistrați ce tip de date au fost implicate: nume, adrese de e-mail, numere de telefon, adrese, detalii de cont, informații financiare, dosare ale angajaților, comunicări cu clienții, acreditări de conectare sau orice altă categorie relevantă. Estimați câte persoane pot fi afectate și clarificați dacă numărul este confirmat sau se află încă în curs de investigare.
Cauza probabilă
Înregistrați cauza cunoscută sau suspectată, chiar dacă investigația este încă în curs. Pe măsură ce apar noi detalii, jurnalul poate fi actualizat de la „cauză necunoscută” la „e-mailul de phishing a dus la compromiterea acreditărilor” sau „contul unui fost contractor a rămas activ”. Jurnalul ar trebui să arate cum s-a schimbat înțelegerea afacerii în timp.
Măsuri imediate de limitare
Documentați ce s-a făcut pentru a limita daunele. Acestea pot include resetarea parolelor, revocarea sesiunilor, aplicarea MFA, suspendarea conturilor, eliminarea regulilor din căsuța poștală, izolarea dispozitivelor, eliminarea accesului furnizorilor, modificări ale firewall-ului sau întreruperi temporare ale serviciilor. Acolo unde este posibil, includeți responsabilul și marca temporală pentru fiecare acțiune.
Decizii privind notificarea
Înregistrați dacă afacerea a notificat autoritatea de supraveghere competentă, respectiv ICO în Regatul Unit sau autoritatea națională pentru protecția datelor din alt stat din UE, precum și persoanele afectate, clienții, furnizorii, asigurătorii, consilierii juridici sau autoritățile de aplicare a legii. Dacă decizia a fost de a nu notifica, documentați raționamentul. Această explicație este adesea la fel de importantă ca notificarea în sine.
Pași de remediere și cronologie
Limitarea se adresează incidentului imediat. Remedierea reduce șansa ca aceeași problemă să se repete. Înregistrați acțiunile de urmărire, cum ar fi aplicarea MFA, eliminarea acreditărilor partajate, actualizarea politicilor de acces, îmbunătățirea offboarding-ului, corectarea unei configurări greșite sau schimbarea modului în care sunt protejate backup-urile.
Lecții învățate
Încheiați cu ceea ce a învățat afacerea și cu ceea ce se va schimba. Acest lucru nu ar trebui scris ca o vină. Ar trebui să identifice punctul slab, îmbunătățirea necesară și cine răspunde de urmărire.
Un model simplu de jurnal al incidentelor pentru IMM-uri
Software-ul specializat nu este necesar pentru documentarea incidentelor. O foaie de calcul, un formular intern securizat, un sistem de ticketing sau un registru partajat pot funcționa dacă accesul este controlat și înregistrările sunt menținute consecvente.
Un jurnal al incidentelor eficient ar trebui să includă următoarele câmpuri:
- ID incident: Un număr de referință unic.
- Data și ora descoperirii: Când afacerea a luat cunoștință de incident.
- Raportat de: angajat, furnizor, client, vânzător, alertă de monitorizare sau parte externă
- Tip de incident: phishing, malware, compromiterea acreditărilor, pierdere de date, accesare neautorizată, ransomware, incident la furnizor, pierderea dispozitivului, e-mail trimis greșit sau alt tip
- Rezumat: ce s-a întâmplat, scris într-un limbaj simplu
- Sisteme afectate: aplicații, conturi, dispozitive, baze de date, inboxuri sau servicii terțe implicate
- Date implicate: dacă au fost afectate date personale, ce tip și câte persoane pot fi afectate
- Cauză probabilă: cunoscută, suspectată sau în curs de investigare
- Acțiuni de limitare: ce s-a făcut imediat
- Decizia de notificare: autoritatea de supraveghere, persoanele, clienții, asigurătorul sau nicio notificare cu justificare
- Linkuri către dovezi: capturi de ecran, tichete, jurnale, e-mailuri, înregistrări de accesare, fișiere de export sau rapoarte ale furnizorilor
- Acțiuni de remediere: pași întreprinși după limitare
- Responsabil: persoana responsabilă de urmărire
- Stare: deschis, în monitorizare, limitat, rezolvat, închis
- Lecții învățate: ce ar trebui schimbat
Cum să înregistrați deciziile de notificare
Deciziile de notificare merită un spațiu propriu într-un jurnal de incidente de securitate, deoarece sunt adesea analizate după incident.
În temeiul GDPR din Regatul Unit și al GDPR din UE, organizațiile trebuie să evalueze riscul probabil pentru drepturile și libertățile persoanelor atunci când are loc o încălcare a datelor cu caracter personal. Dacă riscul este probabil, autoritatea de supraveghere trebuie notificată cât mai curând posibil, iar atunci când este posibil, în termen de 72 de ore, ICO(fereastră nouă) din Regatul Unit, autoritatea națională de protecție a datelor din fiecare stat membru al UE. Dacă riscul este ridicat, persoanele afectate trebuie, de asemenea, notificate fără întârziere nejustificată. Pragurile și termenul sunt aceleași de ambele părți; doar autoritatea se schimbă.
Un jurnal de incidente bine întocmit ar trebui să arate că compania a făcut această evaluare. Ar trebui să înregistreze dacă au fost implicate date cu caracter personal, ce tip de prejudiciu ar putea rezulta, ce protecții existau și de ce compania a decis să raporteze sau să nu raporteze.
De exemplu, un incident care implică o parolă de administrator expusă poate să nu dezvăluie imediat dacă au fost accesate date cu caracter personal. Jurnalul ar trebui să reflecte această incertitudine. Poate înregistra îngrijorarea inițială, pașii de investigare, analiza activității contului și concluzia finală odată ce dovezile sunt disponibile.
În acest punct al procesului, multe companii se concentrează pe organizarea soluției tehnice și uită să înregistreze raționamentul de conformitate. Parolele sunt resetate, conturile sunt securizate, iar operațiunile continuă. Săptămâni mai târziu, compania nu poate explica de ce a decis că incidentul nu era raportabil.
Ce așteaptă autoritățile de supraveghere de la înregistrări
Autoritățile de supraveghere nu verifică doar dacă o încălcare a fost raportată. Ele pot, de asemenea, să întrebe cum compania:
- a identificat incidentul
- a evaluat riscul
- a decis dacă notificarea era necesară
- a documentat acțiunile întreprinse
O înregistrare bună ar trebui să facă povestea incidentului clară de la început până la sfârșit. Ar trebui să arate ce s-a întâmplat, ce date cu caracter personal au fost implicate, ce prejudiciu ar putea rezulta, ce a făcut compania pentru a limita problema și de ce a raportat sau nu a raportat încălcarea.
Nivelul de detaliu ar trebui să corespundă gravității incidentului. Un e-mail trimis greșit nu va avea nevoie de aceeași înregistrare ca un atac de ransomware, dar trebuie totuși documentat pentru a arăta că compania l-a evaluat corespunzător.
Aceste înregistrări ar trebui, de asemenea, stocate în siguranță. Jurnalele de incidente pot include detalii sensibile despre persoanele afectate, sisteme expuse, acțiuni ale angajaților, capturi de ecran, jurnale de accesare sau pași de remediere. Accesarea ar trebui limitată la persoanele care au nevoie de ea, iar păstrarea ar trebui să fie aliniată la politica mai largă de păstrare a datelor a companiei.
Jurnalul de accesare a acreditărilor
Multe incidente implică acreditări: ele pot fi declanșate de o parolă reutilizată, un cont partajat, un inbox compromis, o conectare de administrator expusă, o solicitare MFA suspectă sau un angajat care nu a fost eliminat din sisteme corespunzător.
Din acest motiv, înregistrările de accesare a acreditărilor pot deveni o intrare directă în documentarea incidentelor de securitate cibernetică. Atunci când un incident implică o conectare partajată sau un cont sensibil, compania trebuie să știe cine a avut acces, cum a fost partajat accesul, dacă permisiunile s-au schimbat și dacă acreditarea a fost rotită după incident.
Un manager de parole pentru companii precum Proton Pass for Business ajută echipele să gestioneze acreditările în seifuri criptate, să genereze parole unice, să folosească completarea automată, să partajeze acreditările în siguranță, să gestioneze chei de acces și să folosească autentificarea cu doi factori integrată. Pentru documentarea incidentelor, cea mai mare valoare o are urma de accesare din jurul acreditărilor: cine a avut acces la seifuri/conturi partajate, cum a fost gestionat accesul și cine l-a folosit și ce s-a schimbat după incident.
Un manager de parole pentru echipele IT adaugă funcții de administrare precum politici, raportare, jurnale, control al accesului bazat pe roluri, provisioning SCIM și integrare SSO. Aceste funcții pot ajuta companiile să arate cum este controlată accesarea acreditărilor și să furnizeze dovezi atunci când este investigat un incident legat de acreditări.
Un manager de parole nu poate înlocui un jurnal de incidente, o evaluare juridică, un proces de notificare reglementară sau un plan de răspuns la incidente. Dar oferă dovezi privind acreditările care pot alimenta aceste procese.
Păstrați o urmă completă de audit a accesării acreditărilor cu un manager de parole pentru companii.
