Incydenty – O Bezpieczeństwie, Jack Bauer i dlaczego Sędzia Dredd to użyteczna acz mało biznesowa postać

O incydentach z serca

Incydenty bezpieczeństwa, to ten obszar, do którego staram się podejść z dużą dozą pokory, bowiem nie jest to temat trywialny w realizacji, ani tym bardziej do przedstawienia w zwięzły sposób. Ma wiele wymiarów i różnie się go definiuje w zależności od tego kto tym procesem zarządza i w jakiej organizacji jest realizowany.

Odnoszę wrażenie, iż ostatnio najwięcej mówi się o naruszeniach ochrony danych osobowych (i to tylko z prawnego punktu widzenia pomijając aspekt operacyjny ) albo o tak poważnych zdarzeniach jak atak ransomware, którego nie życzę nikomu, mimo iż każdy z nas powinien mieć go na względzie – zwłaszcza patrząc jakie produkty i/lub usługi oferuje chroniona firma.

Odkąd zacząłem pracować w bezpieczeństwie (od 2018 roku) miałem możliwość obsługiwać incydenty bezpieczeństwa i naruszenia ochrony danych osobowych. W moim podejściu przy projektowaniu procesów obsługi zdarzeń bezpieczeństwa sugerowałem się zawsze zdrowym rozsądkiem i logiką, bo możemy oprzeć się o popularne normy i wytyczne, ale na nic się zdadzą, jeżeli nie podejdziemy do incydentów bezpieczeństwa z zimną krwią i otwarta głową. W końcu mają miejsce zdarzenia, które nie zawsze wpisują się w ustalony proces.

Do zaprojektowania procesu obsługi zdarzeń (incydentów) bezpieczeństwa (informacji) proponowałbym rozważyć zapoznanie się z:

Warto jednak zaznaczyć, iż poza powyższymi normami i wytycznymi, przy projektowaniu procesu należy wziąć pod uwagę wymogi prawne, w tym: ustawę o Krajowym Systemie Cyberbezpieczeństwa (jeśli się podlega) oraz RODO.

Proces zarządzania incydentów

Jeśli chodzi o sam proces zarządzania (obsługi) incydentów bezpieczeństwa to zgodnie z framework’iem NISTa to:

Krok 1: Przygotowanie
Krok 2: Wykrycie i analiza
Krok 3: Ograniczenie / kwarantanna, Eliminacja, Odtworzenie po incydencie
Krok 4: Działania po incydencie

Przyznam się szczerze, iż trochę niepraktycznie rozpisano te klocki, więc przenieśmy to na bardziej operacyjny grunt:

Krok 0: Przygotowanie (określenie procesu, playbooków, list kontaktowych, list aktywów – zwłaszcza tych wystawionych do Internetu, określenie potencjalnych wektorów ataków i inne – w publikacji wszystko jest opisane)

Krok 1: Wykrycie zdarzenia.

Krok 2: Analiza (określenie czy to w ogóle dotyczy bezpieczeństwa, może to false-positive?, klasyfikacja zgłoszenia, wstępna ocena wpływu zdarzenia na organizację).

Krok 3: Obsługa zdarzenia (wybór strategii obsługi, zbieranie dowodów, ograniczenie lub eliminacja zagrożenia, raportowanie, komunikacja, zgłoszenie zdarzenia do Prezesa UODO, jeżeli to naruszenie ochrony danych osobowych wymagające zgłoszenia).

Krok 4: Odtworzenie po zdarzeniu (systemu, danych, procesu, itp.).

Krok 5: Lessons-learned (czyli co się w ogóle stało, dlaczego doszło do tego, co można zrobić lepiej, jakie informacje podać szybciej, itd.).

Na co należy zwrócić uwagę przy projektowaniu procesu i jej obsłudze?

Zanim zaczniemy z wypiekami na twarzy obsługiwać incydenty i czuć się jak Jack Bauer w serialu „24 godziny” to należy zadbać o podstawy:

1. Przypiszmy role i odpowiedzialności, aby ludzie wiedzieli za co odpowiadają i co mają robić. Przypisanie ról i odpowiedzialność ma też drugi cel – rozliczalność. Nie jestem fanem grożenia ludziom, iż „następnym razem polecą głowy”, bo to raczej hasła (a raczej groźby) mało eleganckie, jednak rozliczalność przy incydentach jest bardzo ważna w trakcie obsługi, jak i po niej.
2. Zapewnijmy odpowiednie zasoby rolom zaangażowanym w procesach, w tym laptop z VPNem oraz telefona. Do dziś zadziwia mnie jak usłyszę, iż główni administratorzy IT nie mają komórek, albo ich nie odbierają.
3. Należy określić OLA i SLA, czyli terminy, w któych należy zgłosić zdarzenie – wewnętrznie: do określonych komórek organizacyjnych, a także „zewnętrznie: do klienta, czy Prezesa Urzędu Ochrony Danych Osobowych.
4. KOMUNIKACJA – bez niej wszystko leży. Należy określić ścisłe drogi komunikacji – co, komu, jak zgłaszamy, jak szyfrujemy oraz „PR control” lub „PR crisis management” (chodzi o to, aby ludzie od PRu / komunikacji wiedzieli iż coś się dzieje i mają się przygotować na niewygodne pytania z zewnątrz).
5. Szkolenia – organizacja musi wiedzieć iż taki proces jest i bezwzględnie należy przestrzegać zasad i czynności w nim opisanych, co by jakiś mistrz świata nie opowiadał, iż on to ma 72h na zgłoszenie incydentu do bezpieczników… Aby tacy młodzi bogowie nie nosili swoich podwładnych na manowce, polecałbym przeprowadzać szkolenia przynajmniej raz w roku i jeszcze przypominać o procesie w jakichś komunikatach w intranecie.

Wspomniałem o ocenie wpływu (lub wagi) zdarzenia na organizację. Ta ocena nabrała znaczenia po wejściu w życie RODO, gdyż od maja 2018 roku „wypadałoby” przeprowadzać ocenę wagi zdarzenia bezpieczeństwa (naruszenia) każdorazowo, aby przynajmniej wiedzieć czy zdarzenie jest już naruszeniem ochrony danych osobowych i czy czasem nie należałoby wysłać powiadomienia do Prezesa Urzędu Ochrony Danych Osobowych oraz podmiotów danych (poszkodowanych osób, któych naruszenie ochrony danych osobowych dotyczyło).

Jak taką ocenę wagi przeprowadzić?

Po Internecie krążą już gotowe metodyki i metody, jednak polecałbym najpierw lekturę wytycznych ENISA: Recommendations for a methodology of the assessment of severity of personal data breaches: https://www.enisa.europa.eu/publications/dbn-severity.

Jak więc obsłużyć incydent bezpieczeństwa aby wszyscy żyli długo i szczęśliwie?

Podczas obsługi incydentu bezpieczeństwa należałoby zastanowić się nad tym co, komu i jak przekazać – jakie interesy w zdarzeniu mają poszczególne strony.

1. Dyrekcja: chcą mieć temat ogarnięty szybko, sprawnie i efektywnie. Nie chcą problemó z klientami, ani organami nadzorczymi. jeżeli jest jakiś błąd w systemie IT lub procesie biznesowym, to najpierw kierownictwo powinno to rozwiązać.
2. Pracownicy: proces zgłaszania zdarzeń do działu bezpieczeństwa, albo SOCu (Security Operations Center), albo innej wskazanej komórki organizacyjnej MUSI być prosty, wręcz idioto-odporny! Należy im również podkreślać i szkolić, iż zdarzenia bezpieczeństwa muszę zgłaszać niezwłocznie.
3. Pracownicy bezpieczeństwa: chcą zdarzenie / incydent / naruszenie ODO obsłużyć jak najszybciej i najefektywniej – to raczej oczywiste, bo strażakowi nie powie się, aby siorbnął se herbatki zanim odpali wodę…
4. Audytor: pomimo iż istnieją audytorzy którzy wolą szukać niezgodności, niż dowodów na zgodność, to ci ludzie raczej wolą zobaczyć iż wszystko jest w porządku.
5. Klient: chce (a choćby powinien) być informowany o każdym incydencie bezpieczeństwa, który go dotyczy. Potrzebuje również wsparcia w dalszej obsłudze, jeżeli coś się stanie.
6. Organ nadzorczy (Urząd): chce informacji wymaganych prawem (przynajmniej) oraz dalszej współpracy. Bez tych obu, bądźmy gotowi na pismo z zapowiedzeniem kontroli, albo od razu kary administracyjnej.

Być jak Dredd…

Kiedyś podczas rozmowy rekrutacyjnej z Dyrektorem Bezpieczeństwa otrzymałem case study, które parafrazując brzmi tak: co byś zrobił, jakbyś w trakcie picia kawki w kuchni firmowej otrzymał informację o niezgodności / incydencie? Zgodziliśmy się, iż nie ma na to ani dobrej, ani złej odpowiedzi; rekacji też raczej nie, chyba iż zbyt dosłownie jesteśmy fanem charakteru Sędziego Dredda (tego w wykonaniu Pana Sylvestra Stalone’a), który poza kozackim hełmem, tekstami i bronią cechował się zapędami psychopatycznymi i działaniami radykalnymi. Sądzę, iż większość bezpieczników nie ma ochoty chodzić po biurze i BYĆ PRAWEM, bo jest to dosyć mało biznesowe zachowanie i może spotkać się z brakiem zrozumienia.

Atmosfera wokół incydentu bezpieczeństwa nie zawsze jest spokojna i kulturalna, to ciężka i ryzykowna robota, tak więc chyba lepiej zgłosić nam incydent, niezgodność, podatność, czy „wątpliwość” wcześniej, niż żebyśmy chodzili korytarzami z „pochodniami” i „rozpalali stosy” między poranną kawą, a lunchem. Być może niektórzy lubią te klimaty, ale to przez cały czas źle wygląda wizerunkowo…

W każdym razie, każdemu czytelnikowi polecałbym przeprowadzić eksperyment myślowy co by zrobił gdyby podczas picia szmacznej kawusi usłyszał od kolegi z innego działu, iż gdzieś tam ktoś coś pobiera na swój prywatny pendrive, albo w samym środku pracy gra w CSa…

Podsumowanie

Jeśli miałbym podsumować swój artykuł, to życzyłbym nam wszystkim, bezpiecznikom oraz menadżerom:

• sensownego procesu obsługi incydentów z kompetentną kadrom,
• jak najmniej incydentów bezpieczeństwa (nieważne co organizacja robi i jak dobry jest poziom security awarness, zdarzenie bezpieczeństwa zawsze wpadnie),
• zdrowego rozsądku,
• zimnej krwi,
• empatii.

O Autorze

Tworzy procesy biznesowe, czyta ISO do kawy, lubi optymalizować, a governance i ryzyko to niemal jego guilty pleasure.
Zwolennik opowiadania o bezpieczeństwie w sposób merytoryczny, przystępny i żartobliwy.
Dostaje gęsiej skórki od malowania trawy na zielono oraz żyje w strachu przed za małymi budżetami na bezpieczeństwo.

Dziękujemy autorowi za to, iż zechciał podzielić się swoją wiedzą i doświadczeniem na łamach SecurityBezTabu.pl