secria.eu

Incidento registracija programinės įrangos kūrimo metu: ką jūs dokumentuojate, kai kas nors nepavyksta?

Apžvalga, ką programinės įrangos kūrimo įmonė dokumentuoja incidento metu: skirtumas tarp jūsų teikiamos kodo pažeidžiamumo ir problemos jūsų pačių kūrimo procese, ir ką apie tai nori žinoti jūsų klientas.

Incidentų registravimo programinės įrangos kūrime atveju kalbama apie du skirtingus dalykus, kurie dažnai supainiojami: pažeidžiamumą arba gedimą programinėje įrangoje, kurią kuriate ir pateikiate, ir incidentą jūsų pačių kūrimo procese — aplinkoje, kurioje tą programinę įrangą kuriate. Tai, ką dokumentuojate, kas turi apie tai žinoti ir koks tolimesnis veiksmas yra reikalingas, skiriasi priklausomai nuo tipo. Jei nedarote šio skirtumo, dažnai praleižiate labiausiai svarbų incidentą: taninimą surinkimo grandinėje, kuris per kodą pasklinda visiems klientams, kurie jį naudoja.

Pažeidžiamumas pateiktame kode tiesiogiai paliečia jūsų klientą: jis naudoja programinę įrangą, todėl turi riziką. Incidentas jūsų kūrimo procese — pavogtas prieigos raktas, kompromituotas surinkimo paskyra, šaltinio kodo saugyklos nuotėkis — iš pradžių paliečia jus, tačiau gali turėti reikšmę kiekvienam klientui, kuris dirba su tuo kodu. Abiem atvejais galioja tai, kad saugos klausimynas arba auditorius neklausia, ar kada nors kažkas nepavyko, o ar galite parodyti, ką dokumentavote ir iš to išmokote.

Ką dokumentuojate incidento atveju kode

Pažeidžiamumo arba gedimo pateiktoje programinėje įrangoje atveju tai apima: kada tai buvo aptikta, kas arba kas tai nustatė (vidiniai bandymai, kliento pranešimas, nuskaitymas, išorinės šalies tyrimas), kuri programinės įrangos dalis yra paveikta, koks galimas poveikis, kokie veiksmai buvo atlikti ir kokią dieną, ir kas jūsų organizacijoje yra atsakingas už tolesnę priežiūrą. Gera registracija taip pat parodo, ar pataisymas buvo išplatintas visiems klientams, kurie naudoja susijusią versiją, ar tik tiems, kurie tai pranešė. Pastarasis būdas yra būtent tai, apie ką atsakingas asmuo klausimyne paklaus: ne tai, ar jūs kada nors turėjote pažeidžiamumą, o ar jūsų procesas garantuoja, kad visi, kurie juo yra paveikti, apie tai sužinos.

Ką dokumentuojate incidento atveju jūsų kūrimo procese

Incidentas jūsų pačių kūrimo aplinkoje — kompromituota paskyra su prieiga prie šaltinio kodo, surinkimo serveris, kuris reaguoja netikėtai, priklausomybė, kuri vėliau pasirodo žalinga — reikalauja šiek tiek kitokios registracijos. Čia tai apima: kuris kompiuterių tinklas arba paskyra tai liečia, kas turėjo prieigą per laiką, kada tai vyko, ar yra žymių, kad kodas buvo pakeistas ar peržiūrėtas, ir kurie klientai galbūt naudoja programinę įrangą, kuri buvo sudaryta arba pateikta tuo laikotarpiu. Tai yra incidento tipas, kuris tiesiogiai liečia prieigos valdymą jūsų kūrimo procese: be šiuo metu galiojančio to, kas turi prieigą ir prie ko, yra daug sunkiau atsakyti į šį tirinėjimo klausimą.

Ką informuojate ir ką ne

Tai, ar patys išduodami NIS2 direktyvos pagal Cybersaugos įstatymą nustatytą prievolę, arba ne, lemia, ką apie incidentą jūs informuojate. Subjektai, kurie patys pažymėti kaip esminiai arba svarbūs, turi pareigą pranešti savo priežiūrėtojui; kas būtent turi būti pranešta ir kokia procedūra, nurodyta direktyvoje ir nacionaliniame įstatyme, ir skiriasi priklausomai nuo situacijos. Programinės įrangos bendrovė, kuri paveikta grandinės — tai yra, pati nėra prievolinga, bet teikia paslaugas klientui, kuris yra — neturi tokios pareigos pranešti priežiūrėtojui, tačiau paprastai turi sutartinę nuostatą informuoti klientą. Tai nepadaro savos registracijos mažiau svarbios: klientas, kuris paklaus, ar jūs kada nors turėjote incidentą, norės pamatyti konkretų atsakymą, ne vėlesnę apskaičiavimą.

Dinamiška saugykla, ne archyvas

Incidentų registracija geriausiai veikia kaip gyvas dokumentas: sąrašas, kuriame kiekvieno incidento atveju galima rasti statusą, įrodymą ir atsakingą asmenį, o ne atskiras pranešimas, kuris po sutvarkymo dingsta į aplanką. Tai atitinka, kaip suformuota plačioji priežiūros prievolė, kurioje dešimt priemonių kiekviena iš jų reikalauja statuso ir atsakingo asmens. Norintieji pamatyti, kaip incidentų registracija susijusi su kitomis devyniomis priemonėmis, tą apžvalgą rasite adresu puslapyje su visais temomis pagal situaciją.

Ar jūsų organizacija pati patenka į priežiūros prievolę, ar paveikiama per tiekimo grandinę, ar nė vieno iš šių variantų, galima sužinoti uždavus kelis klausimus per NIS2 patikrinimą, kuris per kelis klausimus suteikia orientacinę nuorodą. Kas tiksliai nori žinoti, iš kur kilusi informacija secria.eu ir kaip ji palaikoma, tas gali tai perskaityti puslapyje, kuriame aprašyta, kaip tai veikia. O kas po skaitymo nori sužinoti, ką prenumerata prideda prie to, kas čia yra nemokamai, tą rasite akivaizdu susumuotą aprašyme, kas yra įtraukta.

Šis tekstas yra bendroji išaiškinimas ir ne teisinė nuomonė apie jūsų konkrečią situaciją. Jei norite išvados dėl jūsų konkretaus incidento proceso arba pranešimo pareigos, galite kreiptis į teisininką arba į tolesio institucija, atsakingą už jūsų sektorių.

Šis straipsnis yra bendroji informacija, o ne teisinė konsultacija.