KSC NIS2 a software house: Dlaczego audyt od klienta to nowa rzeczywistość biznesowa?

Jako CEO software house’u, Twoim celem jest pozyskiwanie nowych projektów, wzrost przychodów i budowanie stabilnej pozycji na rynku. Prawdopodobnie celujesz w klientów „enterprise” – duże, stabilne firmy z sektora finansowego, produkcyjnego czy energetycznego, ponieważ to one gwarantują długoterminowe, wysokomarżowe kontrakty. Do tej pory, aby zdobyć taki kontrakt, musiałeś udowodnić kompetencje technologiczne, efektywność kosztową i jakość kodu. Teraz do gry wchodzi nowy, najważniejszy czynnik: cyberbezpieczeństwo.

Rewolucja KSC/NIS2 (oraz DORA dla finansów) fundamentalnie zmienia Twoją relację z klientami korporacyjnymi. Nowe przepisy nakładają na Twoich klientów (podmioty kluczowe i ważne) bezpośrednią odpowiedzialność prawną za bezpieczeństwo ich łańcucha dostaw ICT – czyli za bezpieczeństwo Twojej firmy i Twojego oprogramowania. Dla Ciebie to moment prawdy. Bezpieczeństwo przestaje być wewnętrznym kosztem. Staje się kluczowym czynnikiem decydującym o wygraniu (lub przegraniu) kontraktu.

Dlaczego KSC/NIS2 zmienia zasady gry dla każdego dostawcy ICT?

Dotychczas bezpieczeństwo w relacji z klientem było kwestią umowną, często sprowadzoną do ogólnych zapisów o poufności. KSC/NIS2 to zmienia. Twój klient (np. bank, fabryka, elektrownia) będzie teraz audytowany przez regulatora nie tylko z własnego bezpieczeństwa, ale także z tego, jak zarządza ryzykiem swoich dostawców.

Dla zarządu Twojego klienta oznacza to, że jeśli Twój software house będzie miał lukę w zabezpieczeniach, która doprowadzi do ataku na systemy klienta, to odpowiedzialność (w tym finansowa) spadnie nie tylko na Ciebie, ale także na zarząd Twojego klienta – za brak należytej staranności w procesie wyboru i nadzoru dostawcy.

To całkowicie odwraca dynamikę. Klient nie będzie Ci już „ufa_ć_” na słowo. Będzie musiał Cię zweryfikować i audytować, aby chronić sam siebie przed sankcjami. Twój poziom bezpieczeństwa staje się jego problemem regulacyjnym.

Czego dokładnie będą wymagać klienci enterprise od swojego software house’u?

Przygotuj się na to, że proces zakupowy (RFP) u klientów korporacyjnych fundamentalnie się zmieni. Dział zakupów Twojego klienta, współpracując ze swoim CISO, zacznie zadawać bardzo konkretne i twarde pytania. Zanim w ogóle dojdzie do rozmowy o cenie, będziesz musiał przejść przez nowy etap kwalifikacji: ocenę ryzyka dostawcy.

Będziesz musiał dostarczyć twarde dowody na swoje bezpieczeństwo. Klienci zażądają:

1. Dowodów na posiadanie Systemu Zarządzania Bezpieczeństwem Informacji (SZBI): Najprostszym dowodem jest certyfikat ISO 27001. Jego brak będzie wymagał odpowiedzi na setki pytań w kwestionariuszu.
2. Wyników testów penetracyjnych: Klient będzie chciał zobaczyć aktualny raport z testów penetracyjnych Twoich aplikacji (webowych, mobilnych, API)  lub nawet Twojej infrastruktury.
3. Dowodów na bezpieczny proces wytwarzania oprogramowania (Secure SDLC): Jak zarządzacie podatnościami w kodzie? Czy stosujecie analizę kodu (SAST)? 
4. Akceptacji rygorystycznych klauzul umownych: Będziesz musiał umownie zobowiązać się do raportowania incydentów czy poddania się audytowi klienta.

Firmy, które nie będą w stanie dostarczyć tych dowodów, będą automatycznie odrzucane z postępowań przetargowych w sektorach regulowanych.

Jak „bezpieczeństwo” z kosztu przekształca się w przewagę konkurencyjną?

Jako CEO, prawdopodobnie postrzegałeś wydatki na ISO 27001 czy regularne pentesty jako koszt. KSC/NIS2 sprawia, że jest to jedna z najlepszych inwestycji w sprzedaż. Rynek w naturalny sposób podzieli się na dwie grupy software house’ów.

Pierwsza grupa to firmy, które zignorują ten trend. Będą one mogły konkurować tylko ceną i tylko o projekty w nieregulowanych, często mniej rentownych sektorach. Stracą dostęp do klientów enterprise. Druga grupa to firmy, które proaktywnie zainwestują w swoją „gotowość audytową”.

Należąc do tej drugiej grupy, zyskujesz potężną przewagę konkurencyjną. Możesz startować w przetargach, które są zamknięte dla 90% rynku. Możesz skrócić cykl sprzedaży, ponieważ na pytanie klienta o bezpieczeństwo, zamiast obiecywać, kładziesz na stół certyfikat ISO i raport z pentestu. Budujesz reputację zaufanego partnera, co w sektorach regulowanych jest cenniejsze niż niska cena.

Czy samo oświadczenie o bezpieczeństwie wystarczy mojemu klientowi?

Absolutnie nie. To najważniejsza zmiana. Era „deklaracji” i „oświadczeń” o bezpieczeństwie właśnie się skończyła. Twój klient (np. bank) sam jest kontrolowany przez regulatora (np. KNF). Gdy regulator zapyta bank: „Jak zweryfikowaliście bezpieczeństwo tego software house’u?”, bank nie może odpowiedzieć: „Wysłali nam oświadczenie”.

Bank musi pokazać twarde dowody na przeprowadzenie procesu due diligence. Musi mieć w archiwum Twój raport z audytu, Twój certyfikat ISO 27001 lub wyniki wypełnionego kwestionariusza.

Dlatego kluczowa staje się niezależna walidacja. Twoje własne oświadczenie ma niską wartość. Raport z testu penetracyjnego przeprowadzonego przez zewnętrzną, renomowaną firmę (jak nFlo) ma wartość ogromną. To obiektywny dowód, który Twój klient może pokazać swojemu audytorowi.

Na czym polega audyt łańcucha dostaw, który przeprowadzi u mnie klient?

Przygotuj się na to, że Twoi klienci zaczną stosować ustrukturyzowane metody audytu. Proces ten będzie miał zazwyczaj dwa etapy, w zależności od tego, jak krytycznym dostawcą dla klienta jesteś.

Etap pierwszy to audyt proceduralny (kwestionariusz). Otrzymasz obszerny formularz (często oparty na ISO 27001), w którym będziesz musiał odpowiedzieć na pytania dotyczące Twoich polityk bezpieczeństwa, zarządzania dostępem, planów ciągłości działania, procedur reagowania na incydenty itd. Będziesz musiał załączyć dowody (np. same polityki).

Etap drugi, zarezerwowany dla dostawców krytycznych, to audyt techniczny. Klient może zażądać (jeśli ma to w umowie) prawa do przeprowadzenia własnego testu penetracyjnego na Twojej aplikacji lub infrastrukturze. Może też chcieć przeprowadzić audyt „na miejscu” w Twojej siedzibie. Musisz być gotowy na oba scenariusze.

Jakie są kluczowe obszary, które software house musi natychmiast zabezpieczyć?

Jako CEO software house’u, Twoje ryzyko koncentruje się w dwóch głównych obszarach: bezpieczeństwie Twojego produktu i bezpieczeństwie Twojej firmy. Klienci będą audytować oba.

1. Bezpieczeństwo Produktu (Aplikacji): To jest absolutna podstawa. Twój kod jest „towarem”, który dostarczasz. Musisz wdrożyć regularne testy penetracyjne aplikacji webowych, mobilnych i API. Testy te powinny być oparte na uznanych metodykach (np. OWASP). Musisz pokazać, że proaktywnie szukasz luk w swoim kodzie.
2. Bezpieczeństwo Procesu Wytwórczego (Secure SDLC): Jak chronicie kod źródłowy? Czy stosujecie narzędzia do przeglądu podatności kodu (SAST)? Jak zarządzacie bibliotekami open-source i ich podatnościami?
3. Bezpieczeństwo Wewnętrzne (Firmy): Jak chroniona jest Twoja własna infrastruktura? Czy stosujecie MFA, EDR? Czy macie procedury reagowania na incydenty?
4. Zgodność Formalna (SZBI): Czy posiadasz formalne polityki i procedury, które opisują wszystko powyższe? Czy masz Plan Ciągłości Działania?

Zacznij od swojego produktu – to on jest największym ryzykiem dla klienta.

Czy potrzebuję certyfikatu ISO 27001, aby spełnić oczekiwania klientów?

KSC/NIS2 formalnie nie nakazuje posiadania certyfikatu ISO 27001. Wymaga jednak posiadania wdrożonego, udokumentowanego Systemu Zarządzania Bezpieczeństwem Informacji (SZBI). I tu pojawia się kluczowa kwestia biznesowa.

ISO 27001 jest międzynarodowym standardem wdrażania SZBI. Posiadanie tego certyfikatu to dla Twojego klienta najprostszy, najbardziej uznany i obiektywny dowód, że Twoja firma podchodzi do bezpieczeństwa w sposób dojrzały i systemowy.

Możesz nie mieć certyfikatu, ale wtedy będziesz musiał przy każdym kliencie od zera udowadniać, że Twój „autorski” SZBI jest równie dobry, co będzie kosztowało czas i pieniądze po obu stronach. Posiadanie certyfikatu ISO 27001  działa jak paszport bezpieczeństwa – zamyka 90% pytań audytowych klienta, zanim w ogóle padną. Jest to inwestycja, która radykalnie skraca cykl sprzedaży w sektorach regulowanych.

Jak testy penetracyjne aplikacji (API/Web) stają się narzędziem sprzedażowym?

Dotychczas testy penetracyjne mogłeś traktować jako zło konieczne lub koszt. Od teraz jest to jedno z Twoich najsilniejszych narzędzi marketingowych i sprzedażowych.

Wyobraź sobie dwa scenariusze. Scenariusz A: Idziesz na spotkanie z zarządem banku i deklarujesz, że Twoje oprogramowanie jest bezpieczne. Scenariusz B: Idziesz na to samo spotkanie i kładziesz na stół raport z testu penetracyjnego Twojego API, przeprowadzony przez niezależną, renomowaną firmę cybersecurity (jak nFlo). Raport ten potwierdza, że aplikacja została przetestowana zgodnie ze standardem OWASP, a wszystkie znalezione luki zostały naprawione.

Który software house zdobędzie kontrakt? Odpowiedź jest oczywista. Proaktywne testowanie własnych produktów i dzielenie się tymi raportami (oczywiście po usunięciu wrażliwych danych) z potencjalnymi klientami buduje ogromne zaufanie i pokazuje dojrzałość, której szukają klienci enterprise.

Jaką rolę odgrywa tu partner GRC/Cybersecurity taki jak nFlo?

Jako CEO software house’u, Twoi najlepsi ludzie to architekci i deweloperzy. Ich kompetencje leżą w tworzeniu wydajnego i funkcjonalnego kodu. Rzadko kiedy są oni jednocześnie ekspertami od zgodności z ISO 27001 , pisania polityk GRC czy przeprowadzania audytów bezpieczeństwa OT  u swoich klientów.

Potrzebujesz partnera, który uzupełni Twoje kompetencje i stanie się Twoim „gwarantem bezpieczeństwa” w oczach klientów. Partner taki jak nFlo pełni dwie kluczowe role:

1. Wsparcie w Budowie Zgodności (GRC): Pomaga Ci zbudować i wdrożyć SZBI zgodny z ISO 27001  lub KSC/NIS2, tak abyś był gotowy na audyty swoich klientów.
2. Niezależna Walidacja Produktu (Testy): Przeprowadza regularne, obiektywne testy penetracyjne Twoich aplikacji (web/API/mobilnych). Dostarcza Ci raporty, którymi możesz (i powinieneś) chwalić się przed swoimi klientami, budując swoją przewagę konkurencyjną.

Inwestycja w takiego partnera to inwestycja w zdolność do pozyskiwania i utrzymywania najbardziej rentownych klientów na nowym, regulowanym rynku.

Od Dostawcy Kodu do Zaufanego Partnera: Mapa Transformacji Software House’u

Poniższa tabela pokazuje, jak KSC/NIS2 zmienia oczekiwania klientów i jak software house musi na nie odpowiedzieć, aby zdobyć przewagę konkurencyjną.