Az incidentregisztrációban szoftverfejlesztésben két különböző dolgról van szó, amelyeket gyakran összekevernek: egy biztonsági rés vagy meghibásodás az Ön által épített és szállított szoftverben, és egy incidens az Ön fejlesztési folyamatában — a környezetben, ahol ezt a szoftvert készítik. Mit rögzít, kinek kell tudnia és milyen követő lépésre kerül sor, az incidenstípusoddal függ. Aki nem tesz meg ezt a különbségtételt, gyakran elmulasztja a legfontosabb incidenst: az olyan fertőzést a build-pipeline-ban, amely a kódon keresztül szétterjedhet az összes ügyfélre, akik azt felhasználják.
Az egy szállított kódban lévő biztonsági rés közvetlenül érinti az ügyfelet: az szoftvert futtat, így veszélynek van kitéve. Az Ön fejlesztési folyamatában egy incidens — egy ellopott hozzáférési kulcs, egy kompromittált build-fiók, egy szivárgás a forráskód-tárban — kezdetben Önt érinti, de az összes olyan ügyfélre kiterjeszthető, aki ezzel a kóddal dolgozik. Mindkettőre érvényes, hogy a biztonsági kérdőív vagy egy auditor nem azt kérdezi, hogy valaha rosszul ment-e valami, hanem azt, hogy képes-e Ön bemutatni, mit rögzített belőle és mit tanult meg belőle.
Mit rögzít egy incidensnél a kódban
Az egy szállított szoftverben lévő biztonsági rés vagy meghibásodásnál az alábbiak szerepelnek: mikor fedezték fel, ki vagy mi (belső teszt, ügyfélbejelentés, scan, külső kutató), a szoftver mely része érinti, mi az lehetséges hatás, milyen lépéseket tett és milyen dátumon, valamint az Ön szervezetén belül ki a felelős a követésért. A jó regisztráció azt is láthatóvá teszi, hogy a javítás ki lett-e helyezve az összes ügyfélnek, akik az adott verziót használják, vagy csak annak, aki jelezte. Az utóbbi pont pontosan az, amit egy megkérdezett felhasználó egy kérdőívben megkérdez: nem azt, hogy valaha volt-e biztonsági rése, hanem azt, hogy az Ön folyamata garantálja-e, hogy mindenki, akiben érintett, azt is meghallani fogja.
Mit rögzít egy incidensnél a fejlesztési folyamatban
Az Ön fejlesztési környezetében egy incidens — egy kompromittált fiók, amely hozzáféréssel rendelkezik a forráskódhoz, egy build-kiszolgáló, amely váratlanul viselkedik, egy függőség, amely később kártékonynak bizonyul — valamivel más regisztrációt igényel. Itt az alábbiak szerepelnek: mely rendszer vagy fiók érintetett, kinek volt hozzáférése az incidens alatt, vannak-e nyomok arról, hogy a kód módosítva vagy megtekintve lett, és mely ügyfelek használnak lehetőleg olyan szoftvert, amely az adott időszakban épített vagy szállított volt. Ez az a típusú incidens, ahol a fejlesztési folyamatban a hozzáférésvezérlés közvetlenül érintett: egy aktuális áttekintés nélkül arról, hogy kinek mit szabad, ez az incidensvizsgálat jelentősen nehezebb megválaszolható.
Kit értesít, és kit nem
Nem azt határozza meg, hogy Ön maga a Cyberbeveiligingswet biztonsági kötelezettsége alá tartozik-e vagy sem, akitől értesít egy incidensről. Az olyan szervezetek, amelyeket lényegesnek vagy fontosnak minősítettek, meldingplicht van felügyeleti szervük felé; pontosan mit és milyen időn belül kell ezt tennünk, a Richtlijn és az nemzeti törvényben van leírva, és helyzettől függően változik. Egy szoftverbedrijf, amely az ellátási láncon keresztül érint — tehát maga nem plichtig, de egy olyan ügyfélnek szállít, amely az — a felügyeleti szervnél nincs meldingplicht, de rendszerint szerzödéses megállapodása van az ügyfél tájékoztatására. Ez a saját regisztrációt nem kevésbé teszi fontossá: az a kliens, aki azt kérdezi, hogy valaha volt-e incidensünk, konkrét választ szeretne látni, nem utólagos becslést.
Egy élő regiszter, nem egy archív
Az incidensregisztrálás akkor működik a legjobban, mint élő dokumentum: egy lista, amelyben minden incidenshez az állapot, a bizonyíték és a felelős megtalálható, ahelyett, hogy egy önálló jelentés lenne, amely feldolgozás után egy mappában eltűnik. Ez összhangban van azzal, ahogyan az átfogóbb gondossági kötelezettség felépül, tíz intézkedéssel, amelyek mindegyike állapotot és felelőst igényel. Aki szeretné látni, hogy az incidensregisztrálás hogyan viszonyul a többi kilenc intézkedéshez, az áttekintést itt találja meg: az összes témát a helyzet szerint feldolgozó oldalon.
Az Ön szervezete közvetlenül a gondossági kötelezettség alá tartozik-e, a szállítási láncon keresztül érinti-e, vagy sem, néhány kérdéssel megtudható a következőn keresztül: a NIS2-ellenőrzés, amely néhány kérdésben orientációt adAki pontosan szeretné tudni, hogy a secria.eu oldalon található információk honnan származnak és hogyan tartják naprakészen, az ezt itt olvashatja meg: az oldal működésérről szóló oldalon. És aki az olvasás után szeretné tudni, mit ad hozzá az előfizetés ahhoz, ami itt ingyenesen elérhető, az ezt áttekinthetően megtalálja a következő helyen: az, amit tartalmaz az áttekintés.
Ez a szöveg általános magyarázat, és nem jogi tanácsadás az Ön saját helyzetéről. Az incidensfolyamatával vagy bejelentési kötelezettségével kapcsolatos véleményhez forduljon ügyvédhez vagy az Ön szektora számára illetékes felügyelethez.