W rejestracji incydentów w oprogramowaniu chodzi o dwie różne rzeczy, które często się mylą: lukę lub awarię w oprogramowaniu, które budujesz i dostarczasz, oraz incydent w twoim własnym procesie developmentu — środowisku, w którym to oprogramowanie tworzysz. To, co dokumentujesz, kto musi o tym wiedzieć i jaki jest kolejny krok, różni się w zależności od rodzaju. Jeśli nie rozróżniasz tych różnic, często przegapisz incydent, który ma największe znaczenie: zainfekowanie w pipeline'u budowy, które rozprzestrzenia się przez kod do wszystkich klientów, którzy go pobierają.
Luka w dostarczonym kodzie bezpośrednio dotyczy klienta: on uruchamia oprogramowanie, więc on ponosi ryzyko. Incydent w procesie developmentu — skradziony klucz dostępu, zaatakowane konto do budowania, wyciek w repozytorium kodu źródłowego — wprost dotyczy ciebie, ale może się przełożyć na każdego klienta pracującego z tym kodem. W obu przypadkach kwestionariusz bezpieczeństwa lub audytor nie pyta, czy kiedykolwiek coś poszło nie tak, ale czy możesz wykazać, co z tego udokumentowałeś i czego się nauczyłeś.
Co dokumentujesz w przypadku incydentu w kodzie
W przypadku luki lub awarii w dostarczonym oprogramowaniu chodzi o: kiedy to zostało odkryte, przez kogo lub co (test wewnętrzny, zgłoszenie klienta, skan, badanie zewnętrzne), którą część oprogramowania to dotyczy, jaki jest możliwy wpływ, jakie działanie zostało podjęte i w jakim terminie, oraz kto w twojej organizacji jest odpowiedzialny za dalsze działania. Dobra rejestracja pokazuje również, czy poprawka została wdrożona u wszystkich klientów, którzy używają danej wersji, czy tylko u tego, który zgłosił problem. Tenże warunek to dokładnie to, na co pytania od odbiorcy są kierowane: nie o to, czy kiedykolwiek miałeś lukę, ale czy twój proces gwarantuje, że wszyscy, których to dotyczy, się o tym dowiadują.
Co dokumentujesz w przypadku incydentu w procesie developmentu
Incydent w twoim własnym środowisku developmentu — zaatakowane konto z dostępem do kodu źródłowego, serwer budowy reagujący inaczej niż oczekiwano, zależność, która okazała się złośliwa — wymaga nieco innej rejestracji. Tutaj chodzi o: którym system lub konto to dotyczyło, kto miał dostęp w okresie, gdy to się działo, czy są dowody, że kod został zmieniony lub przeglądnięty, i którzy klienci potencjalnie używają oprogramowania zbudowanego lub dostarczonego w tym okresie. To jest rodzaj incydentu, który bezpośrednio dotyczy zarządzania dostępem w procesie developmentu: bez aktualnego przeglądu tego, kto gdzie ma dostęp, odpowiedź na to pytanie badawcze w przypadku incydentu będzie znacznie trudniejsza.
Kogo informujesz, a kogo nie
To, czy sam podlegasz obowiązkowi ochrony określonemu w ustawie o cyberbezpieczeństwie, czy nie, decyduje, kogo informujesz o incydencie. Podmioty określone jako essential lub important mają obowiązek zgłoszenia swoemu organowi nadzoru; co dokładnie trzeba zgłosić i w jakim terminie, opisano w dyrektywie i ustawie krajowej, i różni się w zależności od sytuacji. Firma zajmująca się tworzeniem oprogramowania, która jest uciskana przez łańcuch — czyli sama nie podlega obowiązkowi, ale dostarcza klientowi, który tak podlega — nie ma tego obowiązku zgłoszenia organowi nadzoru, ale zwykle ma umowne porozumienie, aby poinformować klienta. To nie czyni własnej rejestracji mniej ważną: klient pytający, czy kiedykolwiek miałeś incydent, chce zobaczyć konkretną odpowiedź, nie szacunek ex post.
Żywy rejestr, nie archiwum
Rejestracja incydentów działa najlepiej jako dokument żywy: lista, w której na każdy incydent znajduje się status, dowód i właściciel, zamiast oddzielnego raportu, który znika w teczce po obsłużeniu. To zgodne z tym, jak skonstruowany jest szerszy obowiązek należytej staranności, z dziesięcioma działaniami, z których każde wymaga statusu i właściciela. Kto chce zobaczyć, jak rejestracja incydentów ma się do pozostałych dziewięciu działań, znajdzie ten przegląd na stronie zawierającej wszystkie tematy dla danej sytuacji.
Czy Twoja organizacja sama podlega obowiązkowi należytej staranności, jest dotknięta łańcuchem dostaw, czy żaden z nich, można sprawdzić za pomocą kilku pytań za pośrednictwem kontroli NIS2, która za pośrednictwem kilku pytań daje wskazanie. Kto dokładnie chce wiedzieć, skąd pochodzą informacje na secria.eu i jak są utrzymywane, przeczyta to na stronie wyjaśniającej, jak to działa. A kto po przeczytaniu chce wiedzieć, co dodaje subskrypcja do tego, co jest tutaj bezpłatne, znajdzie to w przejrzysty sposób u przeglądu tego, co jest wliczone.
Ten tekst jest ogólnym objaśnieniem i nie stanowi porady prawnej dotyczącej Twojej konkretnej sytuacji. Aby uzyskać ocenę Twojego konkretnego procesu obsługi incydentów lub obowiązku zgłoszenia, możesz się zwrócić do prawnika lub do organu nadzoru właściwego dla Twojego sektora.