1 dzień temu
Awaria systemu po ataku ransomware zwykle zaczyna się od pytania technicznego: czy da się przywrócić dane? Dla zarządu równie pilne powinno być inne: czy spółka potrafi wykazać, iż cyberbezpieczeństwo firmy było zarządzane z należytą starannością? Odpowiedź nie zależy wyłącznie od tego, czy przedsiębiorstwo kupiło oprogramowanie ochronne. Decydują o niej także podział odpowiedzialności, dokumentacja decyzji, umowy z dostawcami oraz sposób działania w pierwszych godzinach incydentu.
Cyberincydent jest bowiem jednocześnie zdarzeniem operacyjnym, potencjalnym naruszeniem ochrony danych osobowych, problemem kontraktowym i źródłem ryzyka odpowiedzialności członków organów. W sektorach regulowanych dochodzą obowiązki szczególne, wynikające między innymi z przepisów o krajowym systemie cyberbezpieczeństwa, regulacji finansowych oraz rozporządzenia DORA. Nie każda spółka podlega każdemu z tych reżimów, ale każda powinna umieć ustalić, które z nich dotyczą jej działalności.
Cyberbezpieczeństwo firmy jest zagadnieniem governance
Błędem jest traktowanie bezpieczeństwa cyfrowego jako wyłącznej domeny działu IT. IT wdraża zabezpieczenia i reaguje technicznie, ale to organy spółki odpowiadają za zorganizowanie procesu podejmowania decyzji. Zarząd nie musi samodzielnie oceniać konfiguracji zapory sieciowej ani analizować logów. Powinien jednak zapewnić, iż osoba kompetentna wykonuje te zadania, ma odpowiednie zasoby i składa zarządowi zrozumiałe raporty.
Z perspektywy prawa handlowego znaczenie ma standard należytej staranności. W spółce działającej w branży technologicznej, fintech, e-commerce lub obsługującej istotne zasoby danych, oczekiwana staranność będzie z reguły wyższa niż w podmiocie o ograniczonej cyfrowej ekspozycji. Nie wynika z tego obowiązek eliminacji każdego ryzyka. Taki cel byłby nierealistyczny. Chodzi o racjonalne rozpoznanie ryzyk, wybór środków adekwatnych do skali działalności i okresową ocenę, czy przyjęte środki przez cały czas działają.
Dobrze zaprojektowane governance obejmuje w praktyce cztery elementy: wskazanie właściciela ryzyka, regularne raportowanie do zarządu, określenie progów eskalacji oraz dokumentowanie decyzji. o ile zarząd akceptuje ryzyko, przykładowo opóźnienie wymiany krytycznego systemu, warto aby decyzja wskazywała przyczyny, czas obowiązywania odstępstwa i środki kompensujące. Po incydencie właśnie taka dokumentacja może przesądzać, czy decyzja była przemyślana, czy była jedynie zaniechaniem.
Ocena ryzyka nie powinna być dokumentem do szuflady
Rejestr ryzyk cybernetycznych ma wartość wtedy, gdy łączy aktywa, zagrożenia i konsekwencje biznesowe. W przypadku spółki rozwijającej produkt oparty na generatywnej AI najważniejsze mogą być dane treningowe, kod źródłowy, klucze API i tajemnica przedsiębiorstwa. Dla platformy inwestycyjnej szczególnie dotkliwe będą przejęcie kont klientów, niedostępność usług, manipulacja danymi lub wyciek informacji mogących wpływać na rynek.
Ocena powinna uwzględniać także zależności od podmiotów trzecich. Dostawca chmury, operator płatności, firma utrzymująca system CRM albo zewnętrzny zespół programistyczny mogą stać się punktem wejścia ataku. To nie oznacza, iż outsourcing jest błędem. Oznacza natomiast, iż ryzyko dostawcy nie znika wraz z podpisaniem umowy.
Obowiązki prawne zależą od roli i sektora spółki
Podstawowym, horyzontalnym źródłem obowiązków jest RODO, o ile incydent narusza poufność, integralność lub dostępność danych osobowych. Administrator musi ocenić ryzyko dla praw i wolności osób fizycznych. Gdy ryzyko jest realne, zgłoszenie do organu nadzorczego co do zasady następuje bez zbędnej zwłoki, w miarę możliwości nie później niż w ciągu 72 godzin od stwierdzenia naruszenia. Przy wysokim ryzyku może powstać również obowiązek zawiadomienia osób, których dane dotyczą.
Termin 72 godzin nie jest terminem na pełne techniczne wyjaśnienie sprawy. Jest terminem na uruchomienie procesu, zebranie faktów i przekazanie informacji dostępnych na danym etapie. Z tego względu plan reagowania powinien przewidywać stały kontakt między IT, inspektorem ochrony danych, działem prawnym, komunikacją i zarządem. Nie należy czekać, aż zespół techniczny zakończy wszystkie czynności śledcze.
Dla części podmiotów zastosowanie znajdą obowiązki sektorowe związane z cyberbezpieczeństwem. Zakres ten może obejmować organizacje działające w sektorach uznanych za najważniejsze lub ważne, przy czym kwalifikacja wymaga analizy rodzaju świadczonych usług, skali podmiotu oraz aktualnych przepisów krajowych wdrażających unijny model NIS2. Instytucje finansowe i określeni dostawcy usług ICT dla finansów muszą dodatkowo badać obowiązki wynikające z DORA, w szczególności w obszarze zarządzania ryzykiem ICT, testowania odporności cyfrowej i relacji z dostawcami zewnętrznymi.
Nie wolno automatycznie zakładać, iż młoda spółka technologiczna jest poza zakresem regulacji. Model biznesowy może prowadzić do objęcia obowiązkami, choćby gdy przedsiębiorca postrzega siebie przede wszystkim jako twórcę oprogramowania. Analiza powinna zaczynać się od faktycznie świadczonej usługi, a nie od marketingowej etykiety produktu.
Umowy z dostawcami są częścią ochrony
Wiele sporów po incydencie nie dotyczy samego ataku, ale tego, kto ma wykonać określone działania i kto ponosi ich koszt. Standardowa umowa SaaS często ogranicza odpowiedzialność usługodawcy do wielokrotności miesięcznego abonamentu, nie przewiduje konkretnych czasów reakcji ani nie daje klientowi wystarczających praw audytowych. Dla systemu pomocniczego może to być akceptowalne. Dla dostawcy przechowującego dane klientów lub obsługującego proces krytyczny – już niekoniecznie.
Umowa powinna w sposób praktyczny regulować minimalne wymagania bezpieczeństwa, zgłaszanie incydentów, współpracę dowodową, zasady korzystania z podwykonawców i zwrot lub usunięcie danych po zakończeniu współpracy. W relacjach przetwarzania danych konieczne jest też prawidłowe ukształtowanie powierzenia zgodnie z RODO. Sama obecność klauzuli powierzenia nie przesądza jednak, iż dostawca rzeczywiście spełnia deklarowane standardy.
Szczególnej uwagi wymaga korzystanie z narzędzi AI. Pracownik, który wklei do publicznego modelu fragment kodu, projekt umowy inwestycyjnej lub dane kontrahenta, może narazić spółkę na utratę kontroli nad informacją. Polityka korzystania z AI powinna określać, jakie klasy danych wolno wprowadzać do konkretnych usług, kto zatwierdza nowe narzędzia oraz kiedy wymagane są ustawienia korporacyjne ograniczające wykorzystanie danych przez dostawcę.
Plan reakcji musi uwzględniać dowody i komunikację
Pierwszy odruch po wykryciu włamania – szybkie usunięcie zainfekowanego środowiska – bywa zrozumiały, ale może utrudnić ustalenie przebiegu zdarzenia. Spółka potrzebuje procedury, która równoważy przywracanie działalności z zabezpieczaniem dowodów. W zależności od przypadku należy zachować logi, obrazy systemów, korespondencję z atakującymi, informacje o kontach uprzywilejowanych oraz chronologię podjętych działań.
Plan powinien rozstrzygać, kto może odłączyć system od sieci, kto kontaktuje się z dostawcą, kto ocenia obowiązki notyfikacyjne i kto zatwierdza komunikat dla klientów. Warto także wcześniej przygotować zasady komunikacji z pracownikami. Nieprecyzyjne wiadomości wysyłane w pośpiechu mogą ujawnić więcej, niż jest konieczne, albo prowadzić do sprzecznych przekazów wobec kontrahentów i organów.
Zapłata okupu wymaga odrębnej analizy prawnej i biznesowej. Nie daje gwarancji odzyskania danych ani usunięcia ich kopii przez sprawców. Może też rodzić pytania o sankcje, obowiązki raportowe oraz pokrycie kosztów przez ubezpieczyciela. Taka decyzja nie powinna być podejmowana przez pojedynczego administratora systemów pod presją czasu.
Od czego zacząć w spółce, która nie ma dojrzałego programu
Najrozsądniejszym pierwszym krokiem jest krótki przegląd stanu faktycznego, a nie zakup kolejnego narzędzia. Zarząd powinien wiedzieć, jakie systemy są krytyczne, gdzie znajdują się dane, kto ma dostęp administracyjny, jakie podmioty zewnętrzne uczestniczą w procesach oraz czy istnieje przetestowany plan przywracania działania. Następnie można ustalić priorytety – czasem największą poprawę daje wieloskładnikowe uwierzytelnianie i uporządkowanie uprawnień, a czasem niezależnie testowana kopia zapasowa.
Warto przeprowadzić ćwiczenie stolikowe z udziałem zarządu, IT, prawnika i osoby odpowiedzialnej za dane osobowe. Symulacja przejęcia konta administratora lub wycieku bazy klientów gwałtownie ujawnia niejasności, których nie widać w formalnej polityce. Pozwala również ustalić, czy firma umie podjąć decyzję w pierwszych godzinach, zanim incydent stanie się kryzysem prawnym i reputacyjnym.
Dojrzałość w tym obszarze nie polega na deklaracji, iż firma jest bezpieczna. Polega na umiejętności uczciwego wskazania, czego jeszcze nie kontroluje, kto ma to naprawić i do kiedy. Taka wiedza daje zarządowi znacznie lepszą ochronę niż najdłuższa polityka bezpieczeństwa, której nikt nie stosuje.
