Banki nie potrzebują atakującego, aby doszło do poważnego incydentu informatycznego
Raport Komitetu Bazylejskiego dotyczący zarządzania ryzykiem związanym z technologiami informacyjno-komunikacyjnymi (ICT) jest interesujący, ponieważ skupia się na kwestii, która czasami spotyka się z mniejszym zainteresowaniem niż cyberataki: na niezamierzonych incydentach związanych z ICT, które zakłócają działanie kluczowych usług bankowych.
Badanie pokazuje, że najczęściej zgłaszane przyczyny źródłowe są zaskakująco dobrze znane:
➡️ luki w kontroli zmian,
➡️ słabe punkty w projektowaniu, tworzeniu i testowaniu systemów,
➡️ problemy z wydajnością i przepustowością,
➡️ awarie zewnętrznych elementów zależnych i dostawców technologii.
Foto: jcomp na Magnific
Luki w kontroli zmian były najczęściej wymienianą przyczyną źródłową, mimo że w większości jurysdykcji banki zostały ocenione jako stosujące stosunkowo dojrzałe praktyki w zakresie zarządzania zmianami. W ośmiu jurysdykcjach kontrola zmian została wskazana jako główna przyczyna incydentów.
Banki dysponują już dojrzałymi strukturami zarządzania, zdefiniowanym systemem zarządzania ryzykiem ICT, sformalizowanymi procesami wprowadzania zmian, testowaniem, zarządzaniem incydentami, planami ciągłości działania (BCP) oraz planami przywrócenia danych (DRP).
Współczesne środowiska bankowe są niezwykle złożone.
➡️Jeden z banków prowadzących działalność międzynarodową, uczestniczący w badaniu branżowym, zgłosił ponad 5 milionów zmian w 2025 roku.
➡️Niektóre instytucje automatyzują nawet do 85% standardowych zmian o niskim ryzyku. Przy takiej skali nawet bardzo niski wskaźnik awaryjności może nadal powodować poważne incydenty.
➡️ W jednej z jurysdykcji nieudana migracja systemu zakłóciła działanie wielu kanałów bankowych i dotknęła około 10% ludności.
W innym przypadku kluczowe operacje bankowe były niedostępne przez kilka dni.
➡️ Inny incydent miał swój początek poza bankiem: niekontrolowane modyfikacje systemu chłodzenia centrum danych spowodowały wzrost temperatury i awaryjne wyłączenie, zakłócając działanie kilku dużych banków, których infrastruktura była tam zlokalizowana.
Jest to również bardzo dobry przykład ryzyka związanego z podmiotami zewnętrznymi oraz ryzyka zależności od podmiotów n-tego rzędu.
Bank może dysponować dopracowanymi mechanizmami kontroli wewnętrznej, a mimo to ponieść straty z powodu awarii elementu łańcucha dostaw znajdującego się kilka warstw niżej.
W raporcie zalecane są takie praktyki, jak testowanie w warunkach zbliżonych do produkcyjnych, mapowanie zależności, wdrażanie stopniowe, wydania typu „canary”, wdrażanie metodą „blue-green”, flagi funkcji, sprawdzone plany przywracania, automatyczne odzyskiwanie danych, architektury o wysokiej dostępności oraz ulepszone monitorowanie. Zwraca również uwagę na rosnące wykorzystanie sztucznej inteligencji (AI) i uczenia maszynowego (ML) do identyfikacji potencjalnie niebezpiecznych zmian, poprawy zasięgu testów, wykrywania anomalii i przewidywania awarii.
Mam jedną uwagę krytyczną dotyczącą tej publikacji. Statystyki są cenne, ale naprawdę chciałbym zobaczyć znacznie bardziej szczegółowe studia przypadków incydentów. Bez tej głębi statystyki mówią nam, co zawiodło, ale nie zawsze dlaczego. Jest to szczególnie ważne, ponieważ, jak pokazuje sam raport, banki dysponują już dość dojrzałymi środowiskami kontroli.
Autor: Sebastian Burgemejster
Komentarze