secria.eu

Intsidentide registreerimine tarkvara arenduses: mida te fikseerite, kui midagi läheb valesti?

Ülevaade sellest, mida tarkvarafirma intsidendi korral fikseerib: erinevus teie tarkvara koodis oleva haavatavuse ja teie enda arendusprotsessi probleemi vahel ning see, mida klient sellest näha soovib.

Tarkvaraarenduse intsidentide registreerimisel käib tegelikult kaks erinevat asja, mis segunevad sageli: haavatavus või tõrge tarkvaras, mille te ehitate ja tarnistate, ning intsidendid teie omaenda arenduskeskkonnas — keskkond, kus te seda tarkvara loote. See, mida te salvestate, kes sellest teada saama peab ja milline järgnev sammv selle juurde kuulub, erineb olenevalt tüübist. Kes seda erinevust ei teegi, jätab sageli märkamata intsidendi, millel on suurim mõju: saastunud ehitusprotsess, mis levib teie koodis kõigile klientidele, kes sellest tarkvara kasutavad.

Haavatavus tarnitatud koodis mõjutab klienti otseselt: ta käitab tarkvara, seega kannab ta riski. Intsidendid arenduskeskkonnas — varastatud juurdepääsuvõti, ohustatud ehitustegevuse konto, lekkefr lähtekoodi hoidlas — mõjutavad esialgu teid, kuid võivad levida igale kliendile, kes selle koodiga töötab. Mõlema puhul kehtib, et turvalisuse kontrollnimekiri või auditor ei küsi, kas kunagi midagi valesti läks, vaid kas te saate näidata, mida sellest salvestasite ja õppisite.

Mida te salvestate intsidendi kohta koodis

Haavatavuse või tõrke puhul tarnitatud tarkvara loobis käib: millal avastati, kes või mis (sisemine test, klientide teatamine, skaneerimine, välisekspert), millist osa tarkvarast see puudutab, mis on võimalik mõju, milline tegevus võeti ja millisel kuupäeval, ja kes teie organisatsioonis on järgimise eest vastutav. Hea registreering näitab ka, kas parandus on juurutatud kõigile klientidele, kes kasutavad vastavat versiooni, või ainult kellele teatati. Viimane on täpselt see, mida ostja kontrollnimekirjas küsib: mitte seda, kas teil kunagi haavatavus oli, vaid seda, kas teie protsess tagab, et kõik, kes sellest mõjutatud on, sellest ka teada saavad.

Mida te salvestate intsidendi kohta arenduskeskkonnas

Intsidendid teie omaenda arenduskeskkonnas — ohustatud konto juurdepääsuga lähtekoodile, ehitusserver, mis reageerib oodatult teisiti, sõltuvus, mis hiljem osutub pahatahtlikuks — nõuavad veidi teistsugust registreerimist. Siin käib tegelikult: milline süsteem või konto oli tegemist, kellel oli juurdepääs perioodil, mil see toimus, kas on märke koodis muudatustest või vaatamistest, ja millised kliendid võivad võimalikult kasutada tarkvara, mida sel perioodil ehitati või tarniti. See on intsidendi tüüp, kus juurdepääsu kontroll arenduskeskkonnas on otseselt seotud: ilma tänapäevase ülevaateta, kes millele tohib, on selle uurimisküsimuse lahendamine intsidendi korral märgatavalt keerulisem.

Kes te teavitate ja kes mitte

Kas te ise Küberjulgeoleku seaduse zorgplicht-n alla kuulete või mitte, määrab, kes on teavitatud intsidendist. Üksused, mis on märgitud kui essentsiaalsed või olulised, peavad teatama oma järelevalveasutusele; mis täpselt peab olema ja millise aja jooksul, on kirjeldatud richtlijnina ja rahvuslikuks seaduseks, ja erineb sõltuvalt olukorrajast. Tarkvaraettevõte, kes satub ketina valitsusse — ehk ise pole kohustuslik, kuid tarningud kliendile, kes seda on — ei ole kohustatud teatama järelevalveasutusele, kuid on tavaliselt lepinguliselt kohustatud klienti teavitama. See ei tee enda registreerimist vähem oluliseks: klient, kes küsib, kas teil kunagi intsidendid olid, soovib konkreetset vastust näha, mitte tagantjärele hinnangut.

Elusad registreering, mitte arhiiv

Intsidentide registreerimine toimib kõige paremini elava dokumendina: nimekiri, kus iga intsidendi puhul on ülesleitav olek, tõend ja vastutaja, mitte üksik aruanne, mis pärast lahendamist kausta kaob. See on kooskõlas sellega, kuidas laiem hoolsuskohustus on üles ehitatud, kümne meetmega, millest igaüks nõuab olekut ja vastutajat. Kes tahab näha, kuidas intsidentide registreerimine seostub teiste üheksa meetmega, leiab selle ülevaate leheküljel, kus on kõik teemad iga olukorra kohta.

Kas teie organisatsioon kuulub ise hoolsuskohustuse alla, tagatakse jada kaudu või kumpagi ei kehti, on selge väheste küsimuste pealt NIS2-kontrollist, mis annab väheste küsimuste pealt hinnanguKes tahab täpselt teada, kust tulevad secria.eu-s olevad andmed ja kuidas neid peetakse, loeb seda lehel, kuidas see toimibJa kes soovib pärast lugemist teada, mida lisab tellimus sellele, mis siin tasuta on, leiab selle selgelt kaasatute ülevaate juures.

See tekst on üldine selgitus ja mitte juriidiline nõu teie konkreetse olukorra kohta. Oma konkreetse intsidentprotsessi või teatamiskohustuse otsuse jaoks võite pöörduda juristkonsulendi või oma sektori jaoks pädev järelevalvaja poole.

See artikkel on üldine teave ja mitte õiguslik nõu.