În ceea ce privește înregistrarea incidentelor în dezvoltarea de software, sunt în joc două lucruri diferite care se confundă adesea: o vulnerabilitate sau defecțiune în software-ul pe care îl construiți și îl furnizați, și un incident în propria dumneavoastră linie de dezvoltare — mediul în care creați acel software. Ceea ce înregistrați, cine trebuie să fie informat și ce pas următor este implicat diferă în funcție de tip. Cine nu face această distincție adesea pierde incidentul care contează cel mai mult: o contaminare în pipeline-ul de construcție care se propagă prin cod la toți clienții care utilizează acel cod.
O vulnerabilitate în codul furnizat afectează direct clientul: acesta rulează software-ul, deci acesta corre riscul. Un incident în linia dumneavoastră de dezvoltare — o cheie de acces furată, un cont de construcție compromis, o scurgere în depozitul de cod sursă — vă afectează pe dumneavoastră în primul rând, dar se poate extinde la fiecare client care lucrează cu acel cod. Pentru ambele cazuri, o listă de verificare a securității sau un auditor nu întreabă dacă ceva a mers vreodată prost, ci dacă puteți arăta ceea ce ați înregistrat și ce ați învățat din asta.
Ceea ce înregistrați atunci când apare un incident în cod
În cazul unei vulnerabilități sau defecțiuni în software furnizat, este vorba despre: când a fost descoperit, de cine sau ce (test intern, raportul clientului, scanare, cercetător extern), ce parte a software-ului afectează, care este posibilul efect, ce acțiune a fost luată și la ce dată, și cine din organizația dumneavoastră este responsabil cu urmărirea. O bună înregistrare face, de asemenea, vizibil dacă o corecție a fost implementată la toți clienții care utilizează versiunea respectivă, sau doar la cel care a raportat. Aceasta din urmă este exact ceea ce cere un beneficiar într-o listă de verificare: nu dacă ați avut vreodată o vulnerabilitate, ci dacă procesul dumneavoastră garantează că toți cei afectați sunt, de asemenea, informați.
Ceea ce înregistrați atunci când apare un incident în linia dumneavoastră de dezvoltare
Un incident în propriul mediu de dezvoltare — un cont compromis cu acces la codul sursă, un server de construcție care reacționează diferit de așteptat, o dependență care se dovedește ulterior că este malițioasă — necesită o înregistrare puțin diferită. Aici este vorba despre: ce sistem sau cont era implicat, cine avea acces în perioada în care se întâmpla, dacă există dovezi că codul a fost modificat sau consultat, și ce clienți posibil utilizează software construit sau furnizat în acea perioada. Acesta este tipul de incident în care controlul accesului în linia de dezvoltare este direct implicat: fără o imagine actualizată a cine are permisiunea să acceseze ce, răspunsul la această întrebare de investigație este considerabil mai dificil.
Cine informați și cine nu
Dacă dumneavoastră însuți cadeți sub obligația de diligență a Legii privind securitatea cibernetică sau nu, determină cine informați despre un incident. Entitățile care sunt ele înșile marcate ca esențiale sau importante au o obligație de raportare către autoritatea de supraveghere; ceea ce exact trebuie făcut și în ce termen, este descris în directivă și în legea națională, și diferă în funcție de situație. O companie de software care este afectată prin lanț — deci nu este ea însăși obligată, dar furnizează unui client care este — nu are acea obligație de raportare către autoritatea de supraveghere, dar de obicei are o înțelegere contractuală pentru a informa clientul. Aceasta nu face propria înregistrare mai puțin importantă: un client care întreabă dacă ați avut vreodată un incident dorește să vadă un răspuns concret, nu o estimare retrospectivă.
Un registru activ, nu un arhiv
Înregistrarea incidentelor funcționează cel mai bine ca document viu: o listă în care pentru fiecare incident se pot găsi starea, dovada și proprietarul, în loc de un raport separat care după rezolvare dispare într-un dosar. Aceasta se aliniază cu modul în care obligația mai largă de îngrijire este structurată, cu zece măsuri care fiecare cer o stare și un proprietar. Cine dorește să vadă cum se raportează înregistrarea incidentelor la celelalte nouă măsuri, găsește acea prezentare generală pe pagina cu toate subiectele pe situație.
Dacă organizația dumneavoastră cade sub obligația de îngrijire, este afectată prin lanțul de aprovizionare, sau niciunul dintre cele două, se poate vedea cu câteva întrebări prin verificarea NIS2 care oferă o indicație în câteva întrebăriCine dorește să știe exact de unde provin informațiile de pe secria.eu și cum sunt menținute, citește asta pe pagina despre cum funcționeazăȘi cine după citire dorește să știe ce adaugă un abonament la ceea ce aici este gratuit, găsește asta prezentat clar la prezentarea generală a ceea ce este inclus.
Acest text este o clarificare generală și nu constituie sfat juridic cu privire la situația dumneavoastră specifică. Pentru o apreciere a procesului dumneavoastră specific de incidente sau obligației de raportare, vă puteți adresa unui jurist sau autorității de supraveghere care este competentă pentru sectorul dumneavoastră.