Jakie pytania otrzymuje firma zajmująca się oprogramowaniem na liście kontrolnej NIS2?
Jeśli budujesz oprogramowanie dla klienta, który sam podlega dyrektywie NIS2 — lub ustawie o cyberbezpieczeństwie w Holandii — prawie na pewno otrzymasz listę kontrolną bezpieczeństwa. Pytania na tej liście w przypadku opracowywania oprogramowania zawsze dotyczą dwóch rzeczy: bezpieczeństwa tego, co dostarczasz, i bezpieczeństwa środowiska, w którym to robisz. Ten drugi punkt różni te listy od list dla na przykład firmy instalacyjnej lub dostawcy usług infrastrukturalnych.
Jądro jest zawsze takie samo: czy ktoś przez twoją kod źródłowy, twoją środowisko budowania lub twoje konto u menedżera pakietów może uzyskać dostęp do systemu twojego klienta, i co robisz, aby to uniemożliwić lub szybko to wykryć. Ktoś, kto potrafi odpowiedzieć na te dwa pytania, jest już gotów do zdecydowanej większości listy.
Dlaczego oprogramowanie stanowi osobną kategorię
W przypadku większości dostawców klient patrzy na to, co dzieje się w twoim przedsiębiorstwie: kto ma dostęp do jakich systemów, jak testujesz kopię zapasową. U dostawcy oprogramowania dochodzi do tego dodatkowa warstwa, mianowicie to, co przepuszczasz ze swojego przedsiębiorstwa do przedsiębiorstwa klienta. Może to być aktualizacja, połączenie API lub kod, który działa bezpośrednio w ich środowisku. Dlatego klient zadaje tu głębsze pytania niż w przypadku dostawcy, który używa tylko automatyki biurowej.
Pytania o produkt: co dostarczasz
Duża część listy kontrolnej dotyczy samego oprogramowania. Czy używasz bibliotek i komponentów zewnętrznych i czy prowadzisz ich rejestr — często określany jako przegląd składników oprogramowania. Jak postępujesz z podatnością, która zostanie odkryta w takim komponencie, i w jakim terminie wydajesz wówczas aktualizację. Czy kod jest sprawdzany przez drugą osobę, zanim trafi na produkcję. Czy testujesz znane słabe punkty przed dostarczeniem i kto to robi.
Poniżej znajduje się często pytanie o zgłoszenia: jeśli ktoś spoza twojego przedsiębiorstwa odkryje podatność w twoim oprogramowaniu, czy istnieje sposób, aby to do ciebie zgłosić, i co się dzieje z takim zgłoszeniem. To nie jest obowiązek prawny wynikający z samej dyrektywy NIS2 dla ciebie jako dostawcy, ale klienci w praktyce pytają o to, ponieważ muszą to być w stanie uzasadnić swojemu organowi nadzorującemu.
Pytania o łańcuch rozwojowy: jak budujesz
Drugi blok dotyczy środowiska, w którym powstaje oprogramowanie. Kto ma dostęp do kodu źródłowego i czy jest to dostęp związany z osobą czy wspólny. Czy w środowisku, w którym się buduje i dostarcza, włączona jest weryfikacja wieloskładnikowa. Czy zmiana jest automatycznie testowana, zanim trafi do produkcji, i czy ktoś może pominąć ten krok. Kto zarządza kluczami i certyfikatami, którymi podpisane jest oprogramowanie, i gdzie są przechowywane.
Również dość stale powtarzające się: jak postępujesz z laptopami i kontami deweloperów, którzy pracują z tym środowiskiem, zwłaszcza jeśli pracują zdalnie. I: czy prowadzisz dzienniki z informacją o tym, kto co zmienił w kodzie lub potoku, i na jak długo. To ostatnie nawiązuje do tego, co w szerszym sensie określane jest jako rejestracja incydentów, ale skupione na samym środowisku rozwojowym.
Co klient może i nie może pytać
Lista może dotyczyć bezpieczeństwa twojego produktu i procesu rozwojowego w zakresie, w jakim wpływają to na ryzyko klienta. Pytania dotyczące całej twojej wewnętrznej organizacji, twojej polityki kadrowej niezwiązanej z tym kontekstem lub części twojego przedsiębiorstwa, które nie mają nic wspólnego z dostarczanym oprogramowaniem, są poza zasięgiem. Gdzie dokładnie przebiega ta granica, różni się w zależności od umowy i sektora, i to jest coś do wyjaśnienia w rozmowie z klientem, a nie coś do cichu przejścia.
Jak to raz dobrze zbudować
Większość tych pytań nie jest migawką, ale stałym zestawem, który pojawia się u niemal każdego zamawiającego — tylko w nieco innym sformułowaniu. Kto odpowiedzi raz na miarę ustali — wraz z dowodem i odpowiedzialnym pracownikiem — przy następnej liście pytań musi je tylko skopiować i dostosować. Z kilkoma pytaniami pokazującymi, czy i jak pan/pani jest dotknięty/a widzi pan/pani najpierw swoją sytuację, a w przeglądzie według tematu znajdzie pan/pani szczegółową rozpracowanie poszczególnych środków, takich jak kontrola dostępu i rejestracja zdarzeń. Jeśli ma pan/pani wątpliwości dotyczące konkretnego pytania na liście, którą pan/pani otrzymał/a, to lista często zadawanych pytań często już wskazuje pierwszy kierunek, a wyjaśnienie dotyczące pochodzenia naszych informacji pokazuje, jak utrzymujemy źródła.
Jeśli chce pan/pani najpierw sam/a sprawdzić, czy i jak zakład pracy jest w to zaangażowany, przeprowadź bezpłatny szybki przegląd lub przejrzyj bazę wiedzy. Oba są dostępne bez konta i dają wstępne, faktyczne wskazanie — nie ocenę Pani/Pana konkretnej sytuacji, w przypadku wątpliwości zawsze możliwość skontaktowania się z prawnikiem lub właściwym organem nadzoru dla Pani/Pana sektora.