secria.eu

Registrace incidentů při vývoji softwaru: co si poznamenáváte, když se něco pokazí?

Přehled toho, co si softwarová společnost poznamenává v případě incidentu: rozdíl mezi chybou v kódu, který dodáváte, a problémem ve vaší vlastní vývojové infrastruktuře, a co o tom chce vědět váš zákazník.

V registraci incidentů při vývoji softwaru jde o dvě různé věci, které se často pletou dohromady: chybu nebo poruchu v softwaru, kterou vytváříte a dodáváte, a incident ve vaší vlastní vývojové infrastruktuře — prostředí, ve kterém software vytváříte. To, co si poznamenáváte, kdo to musí vědět a jaký je další postup, se liší podle typu. Kdo tento rozdíl neudělá, často zmešká incident, který znamená nejvíce: kontaminaci v pipeline buildu, která se prostřednictvím kódu šíří všem zákazníkům, kteří jej používají.

Chyba v dodaném kódu přímo ovlivňuje zákazníka: ten software provozuje, a proto nese riziko. Incident ve vaší vývojové infrastruktuře — zcizený přístupový klíč, kompromitovaný build-účet, únik v úložišti zdrojového kódu — vás v první řadě ovlivní, ale může se rozšířit na každého zákazníka, který s tímto kódem pracuje. V obou případech platí, že dotazník zabezpečení nebo auditor se neptá, zda se někdy něco pokazilo, ale zda můžete prokázat, co jste si o tom poznamenali a co jste se z toho naučili.

Co si poznamenáváte v případě incidentu v kódu

U chyby nebo poruchy v dodané software jde o: kdy byla zjištěna, kým nebo čím (interní test, hlášení zákazníka, skenování, externí výzkumný pracovník), kterou část softwaru se týká, jaký je možný dopad, jaká opatření byla přijata a kdy, a kdo ve vaší organizaci zodpovídá za následné řešení. Kvalitní registrace také jasně ukazuje, zda byla oprava nasazena všem zákazníkům, kteří danou verzi používají, nebo pouze těm, kteří ji hlásili. Právě to je to, na co se odběratel ptá v dotazníku: ne, zda jste někdy měli chybu, ale zda váš proces zaručuje, že všichni, kterých se to týká, se to dozvědí.

Co si poznamenáváte v případě incidentu ve vaší vývojové infrastruktuře

Incident ve vaší vlastní vývojové infrastruktuře — kompromitovaný účet s přístupem ke zdrojovému kódu, build-server, který se chová jinak, než se čekalo, závislost, která se později ukáže jako škodlivá — vyžaduje o něco jinou registraci. Zde jde o: kterého systému nebo účtu se to týkalo, kdo měl přístup v době, kdy se to dělo, zda jsou stopy toho, že byl kód změněn nebo prohlédnut, a které zákazníky možná používají software, který byl v daném období vytvořen nebo dodán. Toto je typ incidentu, ve kterém řízení přístupu ve vývojové infrastruktuře přímo zasáhne: bez aktuálního přehledu toho, kdo má mít přístup kam, je zodpovězení této vyšetřovací otázky v případě incidentu podstatně obtížnější.

Koho informujete a koho ne

To, zda sami podléháte povinnosti péče podle zákona o kybernetické bezpečnosti, určuje, koho informujete o incidentu. Subjekty, které jsou samy klasifikovány jako podstatné nebo důležité, mají povinnost hlášení vůči svému regulačnímu orgánu; co přesně se musí hlásit a v jaké lhůtě, je popsáno v příslušné směrnici a národním zákoně a liší se podle situace. Softwarová společnost, kterou řetězec ovlivňuje — tedy sama není povinna, ale dodává zákazníkovi, který ano — nemá tuto hlášenou povinnost vůči regulačnímu orgánu, ale obvykle má smluvní dohodu o informování zákazníka. To nezmenšuje důležitost vlastní registrace: zákazník, který se ptá, zda jste někdy měli incident, chce vidět konkrétní odpověď, ne zadní odhad.

Živý registr, ne archiv

Registrace incidentů funguje nejlépe jako živý dokument: seznam, kde lze na jednotlivé incidenty najít stav, doklad a vlastníka, místo volného zprávy, která po vyřešení zmizí v mapě. To koresponduje s tím, jak je konstruována širší povinnost péče, s deseti opatřeními, která každé jednotlivě vyžadují stav a vlastníka. Kdo chce vidět, jak se registrace incidentů vztahuje k ostatním devíti opatřením, najde tento přehled na stránce se všemi tématy podle situace.

Zda vaše organizace sama spadá pod povinnost péče, je zasažena prostřednictvím dodavatelského řetězce, nebo ani jedno z toho, lze vidět pomocí několika otázek pomocí kontroly NIS2, která na základě několika otázek poskytne indikaci. Kdo přesně chce vědět, odkud informace na secria.eu pocházejí a jak se spravují, přečte si to na stránce o tom, jak to funguje. A kdo po přečtení chce vědět, co přihlášení přidá k tomu, co je zde zdarma, najde to přehledně v přehledu toho, co je zahrnuto.

Tento text je obecným vysvětlením a není právním poradenstvím ohledně vaší specifické situace. Pokud si chcete udělat názor na váš konkrétní proces incidentu nebo povinnost hlášení, můžete se obrátit na právníka nebo na orgán dohledu, který je pro váš sektor příslušný.

Tento článek je obecné informace a není právní porada.