0.00 zł

Brak produktów w koszyku.

BOW-TIE i naruszenie ochrony danych

Jedną z moich ulubionych metod analizy jest BOW-TIE, czyli tzw muszka. Stosuję ją nie do analizy jako takiej, bo raczej używam dedykowanych dla branży metod oceny zagrożeń i szacowania i oceny ryzyka. Niemniej jako wizualizacja jest narzędziem bardzo dobrym.

Struktura

Zaczynamy wyjątkowo od środka. Pośrodku kartki okrąg, a w nim opis zdarzenia szczytowego (top event). W ochronie danych osobowych wiele osób ma problem z identyfikowaniem, czym jest zdarzenie szczytowe. Wynika to z tworzenia nowych rozwiązań na zasadzie “wymyślania koła” i często niezrozumienia istoty RODO. A przecież RODO wprost mówi o tym, co jest wymagane. Mówi też do jakich typów zdarzeń powinniśmy dążyć w opisach zagrożeń. Są to naruszenia:

  • Poufności
  • Integralności
  • Dostępności
  • Oraz przetwarzanie niezgodnie z przepisami.

Można ten krótki katalog nazwać zagrożeniami dla danych osobowych.

Case study, bo przykłady są najlepsze

W ostatnim, dość szybko pisanym artykule odniosłem się do naruszenia ochrony danych poprzez wysłanie maila. W mailu, w polu adresowym pojawiły się jawnie maile pozostałych osób. Oznacza to, że doszło do naruszenia poufności danych osobowych w ten sposób, że osoby nieuprawnione uzyskały dostęp do danych osobowych innych odbiorców.

  • Kategorie danych osobowych, których dotyczy naruszenie: Dane kontaktowe, dane o miejscu zatrudnienia osoby.
  • Format danych: imię, nazwisko, domena firmowa.

Więc mamy zdarzenie szczytowe.

Opis:

  • Naruszenie poufności danych osobowych
  • Skala (tu ilość osób, których naruszenie dotyczy)
  • inne informacje wymagane art 33 RODO.

Czego uczy nas incydent?

Od okręgu pośrodku odprowadzamy teraz w lewo przyczyny, które doprowadziły do zdarzenia. W analizach niezawodności nazywa się to drzewo niezdatności, bądź drzewo błędów. Ma swoje wzory notowania, sposób wyliczania prawdopodobieństwa, ale dziś o BOW-TIE raczej tylko jako o opisie. Dla przypomnienia z ostatniego artykułu, warto szukać do piątego poziomu.

Co doprowadziło do zdarzenia?

Przyczyna 1: Błąd pracownika

  1. Dlaczego? Niewiele zapamiętał ze szkolenia.
  2. Dlaczego? Szkolenie prowadzone w formie teoretycznej, bez prezentacji
  3. Dlaczego? Prowadzący szkolenie nie posiada przygotowania pedagogicznego (formy, metody szkoleń odpowiednie do treści i efektów)
  4. Dlaczego? Firma wymaga organizowania i prowadzenia szkoleń od bezpiecznika (IT, prawnika) bez sprawdzenia przygotowania.

Przyczyna 2: Rozkojarzenie i presja (nadal błąd pracownika – jedna z wielu gałęzi analizy)

  1. Dlaczego? Był ważny temat do “domknięcia”.
  2. Dlaczego (był pod presją)? Bo kierownik ma premię. Zespół też
  3. Dlaczego? W firmie jest “wyścig szczurów”.
  4. Dlaczego? ….

Takich przyczyn, czy drzewka przyczyn możemy dopisać wiele. Zastanowić się następnie, które z nich miały większe znaczenie dla zdarzenia, a które mniejsze. I do nich wprowadzić tzw. warstwy zabezpieczeń. Wizualizując: nałożyć poziomie kreski odcinające gałęzie drzewka. Dlatego, że czasem wystarczy “odcięcie” jednej przyczyny, a już cała kombinacja nie zaistnieje.

Np. wystarczy aby szkolenie było adekwatne. Czyli przetestujmy na aplikacjach pocztowych:

“gdzie się potrafi schowac okienko UDW/BCC”.

A potem wyślijmy czasem przypomnienie w formie infografiki, wtedy gdy jest wysokie ciśnienie sprzedażowe (aktywator kampanii security awareness).

Dygresja. Tak, tak. My bezpiecznicy MUSIMY obserwować co się dzieje w firmie, bo to MY JESTEŚMY DLA BIZNESU, a nie biznes dla nas.

Albo druga przyczyna. Opisać i kierownikowi: “presjonatorowi” skutki naruszenia i to, że czasem kasy zabraknie z jednej umowy, do pokrycia kary z UODO. Albo nie tylko UODO (bo przecież organ właściwy to…). Więc może warto maila wysłać za minutę i spokojnie sprawdzić, bo minuta bywa droga…

Skutki, czyli ryzyko naruszenia praw i wolności

Już pisałem w poprzednim artykule o skutkach i o tym, żeby też schodzić do piątego poziomu, o ile jest taka możliwość. Nie będę powtarzał. Może inny przykład, też autentyczny. Zniszczenie danych kadrowych, brak możliwości wystawienia Rp7 (tak, już coraz mniej).

  • Zagrożenie: utrata dostępności
  • Kategorie danych: Dane kontaktowe, dane o warunkach pracy (do “szkodliwego”), dane o wynagrodzeniu.
  • Skala: 40 osób (małe archiwum popłynęło).

Skutki:

  1. Utrata danych kategorii jak wyżej
  2. I co dalej? Brak właściwie naliczonych świadczeń (naruszone prawo osoby)
  3. I co dalej? Brak kasy na leki (naruszone prawo do ochrony zdrowia)
  4. I co dalej? Brak kasy na żywność (utrudniona) (naruszone prawo do życia na odpowiednim, wypracowanym przez siebie poziomie)
  5. I co dalej? Korzystanie z opieki, zasiłków (naruszone prawo do godności)

Czemu aż tak? Bo człowiek ma prawo żyć jak chce. I nie każdy pójdzie po zasiłek, nie każdy się przyzna. A szacować skutki musimy do tego człowieka, a nie do nas. Nie do naszego subiektywnego uznania, że “e tam gościu przeginasz”.

I tu warstwy zabezpieczeń stawia się na odcięcie możliwego skutku. Np. czasem wystarczy digitalizacja, abyśmy mieli nadal dokumenty pod ręką. I niekoniecznie narażone na czynniki fizyczne. Tak, tak… analiza zagrożeń dla digitalizacji też wymagana, bo każde zabezpieczenie wprowadza swoje własne zagrożenia. Ale wróćmy do przykładu.

Czego uczy nas incydent?

Tak już tytułem podsumowania

  • Po pierwsze – jest weryfikacją poprawności analizy zagrożeń (lewa strona muszki) – szacunków prawdopodobieństwa.
  • Po drugie jest weryfikacją  siły zagrożenia (ilość osób). Z tą siłą zagrożenia to jest zawsze problem, bo samo zagrożenie ma i prawdopodobieństwo wystąpienia i siłę. Ale ostatni case z praktyk ESSA. Zalanie jako zagrożenie. Może być ze szklanki wody, postawionej obok komputera lub z opadu deszczu tzw. poza skalą (wczoraj w Katowicach). Szklanka mniej zrobi niż kilka wiader…
  • Po trzecie jest weryfikacją poprawności szacowania i oceny ryzyka (prawa strona muszki) w kategorii skutków
  • Po czwarte jest weryfikacją poprawności szacowania i oceny skutków (też ryzyko, druga składowa).
  • Po piąte jest obszarem do obserwacji, czy nam się z tego kryzys nie rozwija. Ale to już inny artykuł. Niemniej zgodnie z BS 11200 – standardu brytyjskiego dotyczącego zarządzania kryzysowego jak i naszych badań wynika, że źle obsłużony incydent jest najczęstszym źródłem kryzysu. Więc nie zamiatajmy pod dywan…

Czy się bać incydentów?

Wręcz przeciwnie. Dodałbym kolejne elementy w tej dziedzinie

  • Po szóste – pokazuje nam czy potrafimy działać – a więc realizacja 5.2 RODO (rozliczalność i pokazanie skuteczności).
  • Po siódme – wskazuje nam obszary do doskonalenia. Podobnie jak audyt. Tylko proszę, nie róbcie po incydencie audytu, jak kiedyś komuś się pomyliło… Może odszukam artykuł “Audytem w incydent, czyli z armaty do wróbla”. Pisałem chyba w 2012 roku.
  • Po ósme – budzi z letargu decydentów. Jak dobrze wyszacowane zostaną skutki, w tym “złożone kosztowo”, to nagle okazuje się, że jest kasa na zabezpieczenia. I to sporo…

Najnowsze

Podobne artykuły