Stack bezpieczeństwa dla sektora finansowego

kolejność priorytetów narzucona przez DORA

Czytany pod kątem DORA stack układa się w jasną kolejność. Governance ryzyka ICT jest krytyczny: udokumentowany framework ryzyka, nazwany właściciel, zatwierdzenie i odpowiedzialność zarządu. Kontrole tożsamości i dostępu są krytyczne: least privilege, MFA na dostępie uprzywilejowanym i zdalnym, recertyfikowany dostęp, osoby odchodzące usuwane bez zwłoki, wszystko logowane. Ryzyko stron trzecich ICT jest wysokim priorytetem: rejestr dostawców, nadzór nad tymi krytycznymi i kontrola nad tym, kto trzyma stały dostęp. Odporność i odzyskiwanie są wysokim priorytetem: przetestowane kopie zapasowe, disaster recovery, ciągłość i testy odporności wymagane przez DORA. Detekcja i raportowanie incydentów są wysokim priorytetem: szybkie wykrywanie, klasyfikacja wagi i zgłaszanie poważnych incydentów w ciasnych terminach DORA. Dane, endpointy, poczta i sieć to bazowe minimum, pokryte porządnie. Bezpieczeństwo aplikacji przychodzi później, dla podmiotów, które budują własne systemy.

zaczyna się od zarządu, nie od firewalla

DORA zaczyna się od organu zarządzającego, co jest nietypowe i warte zrozumienia. Zarząd musi posiadać framework ryzyka ICT, zatwierdzać go i pozostawać za niego odpowiedzialny, więc bezpieczeństwo przestaje być sprawą czysto techniczną, a staje się sprawą governance. W praktyce oznacza to udokumentowany framework, jasnego właściciela i sposób raportowania ryzyka w górę w języku, na którym zarząd może działać. Jeśli bezpieczeństwo do tej pory żyło wyłącznie wewnątrz funkcji IT, to jest właśnie ta zmiana, i to zwykle ten element mniejsze podmioty mają najsłabiej poukładany.

kontrole dostępu to serce sprawy

Rdzeń techniczny DORA jest szczegółowo rozpisany w jej regulacyjnych standardach technicznych, a czytany wprost jest precyzyjnym opisem dobrze prowadzonego programu tożsamości: zarządzanie tożsamością, dostęp na zasadzie need-to-know i least privilege, rozdział obowiązków, silne uwierzytelnianie, recertyfikacja praw dostępu, usuwanie dostępu bez zbędnej zwłoki, kiedy ktoś odchodzi, i logowanie, kto po co sięgnął. Dla większości podmiotów finansowych luka nie leży w intencji, tylko w dowodzie. Zespół może wierzyć, że jego dostęp jest zgodny z least privilege, a osoby odchodzące straciły dostęp, ale DORA oczekuje, że to zostanie udowodnione aktualnym obrazem, nie założeniem w dobrej wierze.

twoje strony trzecie też są w zakresie

DORA kładzie duży nacisk na dostawców, od których zależy podmiot, bo awaria u krytycznego dostawcy jest awarią samego podmiotu. Potrzebujesz rejestru swoich stron trzecich ICT, realnego nadzoru nad tymi, które mają znaczenie, i uczciwego obrazu ryzyka koncentracji, kiedy za dużo zależy od jednego dostawcy. Po stronie dostępu oznacza to wiedzę, które strony trzecie i podpięte aplikacje trzymają stały dostęp do twoich systemów i danych, pytanie, na które większość podmiotów nie potrafi czysto odpowiedzieć.

odporność to sedno sprawy, nie dodatek

Ta ustawa nazywa się od odporności operacyjnej i traktuje to poważnie. Od funkcji krytycznych oczekuje się, że będą działać dalej mimo zakłócenia, z ciągłością biznesową i disaster recovery, które faktycznie działają, kopiami zapasowymi, które zostały przetestowane i da się z nich odtworzyć dane, oraz odpornością udowodnioną testami, nie założoną. Sektor finansowy jest też jednym z najczęściej atakowanych ransomware sektorów właśnie dlatego, że przestój jest tak kosztowny, co czyni tę sprawę czymś więcej niż punktem do odhaczenia w zgodności. Plan odzyskiwania, którego nigdy nie przećwiczono, to zwykle najpilniejsza luka.

detekcja na termin

DORA ustala ciasne okna na zgłaszanie poważnych incydentów ICT, a nie zgłosisz tego, czego nie zauważyłeś, więc detekcja i działający proces raportowania przesuwają się wyżej na liście. Oznacza to monitoring, który wychwytuje atak, sposób oceny, czy incydent jest poważny, i ścieżkę, która trafia w terminy. Wiele średniej wielkości podmiotów finansowych nie ma zespołu operacji bezpieczeństwa, i dla nich usługa managed detection obejmująca tożsamość i chmurę to zwykle realistyczna odpowiedź zamiast obsadzania własnego stanowiska monitoringu.

wątkiem przewodnim przez to wszystko jest dowód

DORA robi mniejsze wrażenie kontrolami, które deklarujesz, niż kontrolami, które możesz pokazać, z dokumentacją, logami i aktualnym rejestrem. Podmiot finansowy może mieć rozsądne kontrole dostępu i wciąż mieć problem w przeglądzie, bo nie potrafi na żądanie przedstawić czystego obrazu, kto ma dostęp do czego, które strony trzecie trzymają stały dostęp, i dowodu, że osoby odchodzące straciły swój. Dlatego widoczność jest tu na pierwszym miejscu tak samo jak wszędzie indziej: uczynienie powierzchni dostępu widoczną i rejestrowalną to jednocześnie praca nad wyprodukowaniem dowodu, o który poprosi audytor.

proporcjonalność i to, gdzie jesteś

DORA stosuje się proporcjonalnie, więc mniejszy podmiot nie jest rozliczany według skali operacyjnej dużego banku, choć podstawowe obowiązki nadal obowiązują. Dla mniejszego podmiotu praktyczna ścieżka to naprawdę wprowadzić kontrole dostępu i je udowodnić, zbudować rejestr stron trzecich i upewnić się, że podstawy odporności i obsługi incydentów są realne, nie papierowe. Dla większego podmiotu, który już prowadzi funkcję bezpieczeństwa, praca polega bardziej na domykaniu konkretnych luk dowodowych, formalizowaniu nadzoru nad stronami trzecimi i udowadnianiu odporności testami, na bazie kontroli, które już w większości ma.

od czego zacząć

Kontrole dostępu to jednocześnie serce standardów technicznych DORA i miejsce, gdzie większość podmiotów finansowych ma najmniej czyste dowody, więc tu praca procentuje najpierw. Wyraźne zobaczenie powierzchni dostępu domyka realne ryzyko i produkuje zapis, o który poprosi audytor, w tym samym ruchu.