7 lekcji bezpieczeństwa dla banków i operatorów płatności po ostatniej wpadce Revoluta

Revolut przekazał oszustom dane około 680 klientów, mimo że jego systemy nie zostały zhakowane. Przestępcy wykorzystali słabszy punkt – procedurę obsługi zapytań od organów państwowych. Ta sprawa powinna być ważną lekcją dla całej branży finansowej, ponieważ pokazuje, że nawet prawidłowo uwierzytelniona wiadomość nie zawsze oznacza, że po drugiej stronie znajduje się uprawniona osoba.

W klasycznym scenariuszu cyberataku przestępca próbuje przejąć konto administratora, wykorzystać lukę w aplikacji, wykraść bazę danych albo zainstalować złośliwe oprogramowanie. W przypadku głośnej afery Revoluta wydarzyło się coś zupełnie innego. Cyberprzestępcy wykorzystali prawdziwy kanał komunikacyjny włoskiej administracji publicznej i, podszywając się pod organ ścigania, zwracali się do Revoluta o przekazanie danych konkretnych klientów.

Revolut uznał część tych żądań za autentyczne i przekazał informacje. Według medialnych ustaleń incydent objął około 680 klientów. Ujawnione dane mogły obejmować m.in. dokumenty tożsamości, adresy zamieszkania, numery rachunków, dane kontaktowe, a w części przypadków również historię transakcji oraz informacje dotyczące operacji kryptowalutowych. Firma podkreśla, że nie doszło do włamania do jej infrastruktury, a środki klientów nie zostały naruszone.

To właśnie sposób przeprowadzenia ataku jest najciekawszy z punktu widzenia banków, fintechów i operatorów płatności. Przestępcy nie musieli pokonać zabezpieczeń technicznych Revoluta. Wystarczyło, że udało im się sprawić, aby pracownicy firmy uznali ich za osoby uprawnione do otrzymania danych.

1. Prawdziwa domena nie oznacza prawdziwego nadawcy

Według ujawnionych informacji przestępcy wykorzystali kanał komunikacyjny powiązany z włoską administracją publiczną. Z perspektywy odbiorcy wiadomość mogła więc wyglądać bardzo wiarygodnie. Nie była wysyłana z przypadkowego Gmaila czy domeny podobnej do adresu urzędu, ale z infrastruktury związanej z prawdziwą instytucją.

To podstawowa lekcja z całej sprawy: potwierdzenie, że wiadomość pochodzi z autentycznego systemu, nie jest tym samym co potwierdzenie, że osoba korzystająca z tego systemu rzeczywiście jest uprawniona do żądania danych.

Jeżeli konto urzędu zostanie przejęte, poprawne certyfikaty, domena czy inne mechanizmy techniczne mogą jedynie potwierdzić, że przestępca faktycznie korzysta z prawdziwej infrastruktury.

Dlatego w przypadku żądań dotyczących szczególnie wrażliwych informacji powinno istnieć dodatkowe potwierdzenie innym kanałem.

2. Należy weryfikować nie tylko organ, ale także konkretną osobę i sprawę

Samo ustalenie, że wiadomość pochodzi z policji, prokuratury czy urzędu, nie powinno kończyć procesu weryfikacji. Instytucja finansowa powinna mieć możliwość potwierdzenia, czy osoba podpisana pod zapytaniem rzeczywiście pracuje w danej jednostce, czy wskazany numer sprawy istnieje oraz czy nadawca posiada kompetencje do występowania o określony zakres informacji.

Przy bardziej wrażliwych żądaniach dobrym rozwiązaniem jest tzw. callback verification. Pracownik operatora sam inicjuje kontakt z organem, korzystając z wcześniej zweryfikowanych danych kontaktowych. Nie powinien przy tym używać numeru telefonu ani linku zawartego w wiadomości, której autentyczność właśnie sprawdza.

Dobrze zaprojektowana procedura powinna więc zakładać, że jeden kanał komunikacji może zostać przejęty. Dopiero niezależne potwierdzenie pozwala ograniczyć to ryzyko.

3. Trzeba sprawdzać podstawę prawną i zakres żądania

Drugim poziomem kontroli powinna być analiza samej treści wniosku. Nawet prawdziwy funkcjonariusz czy urzędnik nie jest automatycznie uprawniony do otrzymania dowolnych danych dowolnego klienta.

Operator powinien więc weryfikować nie tylko, kto pyta, ale również na jakiej podstawie prawnej występuje o informacje, jaki jest numer postępowania i jakiego dokładnie zakresu danych potrzebuje.

Jeżeli określona kategoria żądania powinna zawierać dodatkową decyzję, postanowienie lub inny dokument, jego brak powinien automatycznie zatrzymywać proces do czasu wyjaśnienia sytuacji.

W przypadku Revoluta jednym z pytań, które pojawiły się po ujawnieniu afery, było właśnie to, czy wszystkie formalne elementy otrzymywanych zapytań odpowiadały standardowym procedurom. Niezależnie od wyniku prowadzonego śledztwa sam przypadek pokazuje, że sprawdzenie nadawcy nie może zastępować analizy podstawy prawnej.

4. Najbardziej wrażliwe dane powinny wymagać dodatkowego zatwierdzenia

Nie każda informacja przechowywana przez instytucję finansową ma taki sam poziom wrażliwości. Czym innym jest potwierdzenie, że dany klient posiada rachunek, a czym innym przekazanie kopii jego paszportu, selfie wykonanego podczas weryfikacji KYC, adresu zamieszkania oraz pełnej historii transakcji.

Dlatego warto wprowadzić różne poziomy autoryzacji w zależności od zakresu przekazywanych danych.

Wydanie podstawowych danych może podlegać standardowej procedurze, podczas gdy przekazanie dokumentów KYC, pełnej historii rachunku czy informacji o kryptowalutach powinno wymagać dodatkowego zatwierdzenia przez drugą osobę, dział compliance lub dział prawny.

To klasyczna zasada „four eyes”. Jeden pracownik przygotowuje odpowiedź, drugi ją weryfikuje i zatwierdza. Druga osoba może zauważyć element, który został przeoczony wcześniej: nietypową jednostkę, brak wymaganych dokumentów, zbyt szeroki zakres żądania czy serię podobnych wniosków.

5. Operator powinien przekazywać tylko niezbędne dane

Każde żądanie powinno być analizowane również pod kątem minimalizacji danych. Jeżeli organ potrzebuje informacji o trzech konkretnych transakcjach, system nie powinien automatycznie generować kilkuletniej historii rachunku. Jeśli wymagane są dane identyfikacyjne klienta, nie oznacza to automatycznie potrzeby przekazywania jego selfie, wszystkich dokumentów KYC i pełnego profilu finansowego.

W praktyce im większa automatyzacja systemów, tym większa pokusa, aby tworzyć gotowe pakiety danych możliwe do wyeksportowania jednym kliknięciem. Z punktu widzenia operacyjnego jest to wygodne, ale z punktu widzenia bezpieczeństwa może zwiększać skutki pojedynczego błędu.

Zakres odpowiedzi powinien więc wynikać z treści konkretnego żądania, a nie z tego, jakie dane firma jest technicznie w stanie wygenerować.

6. System powinien wykrywać nietypowe zachowania także po stronie organów

Banki i operatorzy płatności od lat rozwijają systemy wykrywania nietypowych zachowań klientów. Nagłe przelewy do nowych odbiorców, logowanie z innego kraju czy nietypowe operacje mogą uruchomić dodatkową kontrolę.

Podobne podejście można zastosować do żądań otrzymywanych od instytucji publicznych.

System powinien zwracać uwagę na sytuacje, w których jeden urząd nagle zaczyna wysyłać wielokrotnie więcej zapytań niż wcześniej, z jednego adresu pojawiają się wnioski dotyczące klientów z wielu państw albo jeden organ regularnie żąda wyjątkowo szerokiego zakresu danych.

Niepokojący może być również nagły wzrost liczby zapytań dotyczących określonej grupy klientów, np. osób korzystających z kryptowalut czy klientów o wysokich saldach.

Pojedynczy wniosek może wyglądać prawidłowo. Dopiero analiza kilkudziesięciu podobnych spraw może ujawnić nietypowy wzorzec. Jeśli oszuści działają przez wiele tygodni lub miesięcy, monitoring takich anomalii może pozwolić wykryć proceder znacznie wcześniej.

7. Każde udostępnienie danych powinno pozostawiać pełny ślad audytowy

Ostatnia lekcja dotyczy możliwości szybkiego odtworzenia tego, co wydarzyło się po wykryciu incydentu.

Operator powinien przechowywać nie tylko informację, że dane zostały przekazane, ale także oryginalne żądanie, załączniki, podstawę prawną, sposób weryfikacji nadawcy, zakres udostępnionych informacji, dane pracownika przygotowującego odpowiedź oraz osoby, która ją zatwierdziła.

Istotne jest również zapisanie informacji o dodatkowych czynnościach weryfikacyjnych, np. telefonicznym potwierdzeniu wniosku.

Dzięki temu wykrycie jednego fałszywego zapytania pozwala szybko przeprowadzić analizę historyczną. Można sprawdzić wszystkie wcześniejsze wiadomości pochodzące z tego samego adresu, wszystkie sprawy prowadzone przez konkretną osobę czy wszystkie żądania otrzymane z określonej jednostki.

Bez odpowiedniego audytu samo ustalenie skali incydentu może stać się trudne i czasochłonne.

Problem całej branży, nie tylko Revoluta

Najłatwiej byłoby potraktować tę historię jako jednostkowy błąd Revoluta. W rzeczywistości podobne ryzyko dotyczy praktycznie każdej instytucji finansowej.

Banki, krajowe instytucje płatnicze, małe instytucje płatnicze, operatorzy kart, giełdy kryptowalut czy inni dostawcy usług finansowych regularnie otrzymują zapytania od policji, prokuratur, sądów, organów podatkowych i regulatorów. W wielu przypadkach mają prawny obowiązek udzielenia informacji.

Jednocześnie proces ten musi być wystarczająco szybki, aby nie utrudniać pracy organów. Naturalnym kierunkiem staje się więc jego automatyzacja.

I właśnie tutaj pojawia się potencjalne zagrożenie. Najbardziej ryzykowny model to taki, w którym system automatycznie rozpoznaje wiadomość pochodzącą z określonej domeny, klasyfikuje ją jako zapytanie organu, pracownik wybiera klienta, a następnie jednym kliknięciem generuje pełny pakiet danych.

Dla firmy jest to wygodne. Dla przestępcy, który przejmie zaufany kanał komunikacji, również.

Automatyzować należy więc czynności techniczne, ale niekoniecznie samą decyzję o przekazaniu szczególnie wrażliwych informacji.

Procedura może być równie ważna jak firewall

Afera Revoluta dobrze pokazuje, jak zmienia się współczesne cyberbezpieczeństwo. Przez lata firmy koncentrowały się przede wszystkim na ochronie infrastruktury: firewallach, szyfrowaniu, zabezpieczeniach aplikacji, monitorowaniu logowań czy wieloskładnikowym uwierzytelnianiu.

Wszystkie te mechanizmy nadal są niezbędne, ale przestępcy coraz częściej próbują je ominąć, wykorzystując legalnie działające procesy.

Nie próbują włamać się do systemu. Próbują sprawić, żeby uprawniony pracownik sam wykonał oczekiwaną operację.

Właśnie dlatego procedury obsługi zapytań organów powinny być traktowane jako element systemu bezpieczeństwa, a nie wyłącznie jako zadanie administracyjne czy obowiązek działu compliance.

Warto w tym kontekście stosować zasadę zbliżoną do koncepcji „Zero Trust”: nie ufać automatycznie tylko dlatego, że ktoś znajduje się po drugiej stronie znanego kanału komunikacyjnego. Zaufanie powinno wynikać z pozytywnej weryfikacji konkretnej osoby, konkretnej sprawy i konkretnego żądania.

Najważniejsza lekcja z afery Revoluta

Skala incydentu nie jest ogromna w porównaniu z wyciekami obejmującymi miliony rekordów. Około 680 klientów to niewielka część całej bazy użytkowników Revoluta. Nie liczba poszkodowanych jest jednak w tej historii najważniejsza.

Najważniejsza jest metoda.

Przestępcy nie musieli znaleźć podatności w aplikacji, złamać szyfrowania, dostać się do bazy danych ani przejąć konta pracownika Revoluta. Wystarczyło doprowadzić do sytuacji, w której prawidłowo działająca procedura uznała ich za osoby uprawnione do otrzymania informacji.

To ważna lekcja dla całego sektora płatniczego.

Najgroźniejszą luką w systemie finansowym nie zawsze jest błąd w kodzie. Czasami jest nią poprawnie działający proces zaprojektowany przy założeniu, że druga strona jest tym, za kogo się podaje.

Jeżeli efektem takiego procesu może być przekazanie dokumentu tożsamości klienta, jego adresu oraz pełnej historii finansowej, weryfikacja osoby żądającej tych informacji powinna być równie rygorystyczna jak uwierzytelnienie klienta próbującego wykonać przelew.