Bankowość i finanse | Bezpieczeństwo – Omnilogy | Architektura odporności cyfrowej – o technologicznej odpowiedzialności w dobie zaawansowanych zagrożeń

Michał Igor Dacko
Cybersecurity Architect, Omnilogy

W tym kontekście szczególnie istotna staje się kwestia projektowania odporności na poziomie architektury systemowej, a nie tylko zarządzania incydentami post factum. Z perspektywy architekta cyberbezpieczeństwa – to nie kolejne narzędzie, ale sposób jego wdrożenia i integracji z pozostałymi warstwami systemu decydują o skuteczności całej infrastruktury obronnej.

Dlaczego standardowe wdrożenia technologii nie wystarczą, by mówić o odporności?

Wiele organizacji może pochwalić się obecnością rozwiązań klasy SIEM, EDR czy DLP. Często również procesy zarządzania tożsamością są już częściowo zautomatyzowane, a dane szyfrowane zarówno w tranzycie, jak i w spoczynku. Jednak sama obecność tych systemów nie gwarantuje ich skuteczności. Odporność architektoniczna nie wynika bowiem z posiadania konkretnych komponentów, lecz z tego, czy te komponenty zostały właściwie dobrane, skonfigurowane, zsynchronizowane oraz wkomponowane w szerszy model zarządzania ryzykiem.

Nie wystarczy mieć platformę SIEM – konieczne jest, by korelował on dane z różnych źródeł w sposób spójny i kontekstowy. EDR musi być świadomy wyjątków w politykach dostępu i nie może ignorować punktów końcowych wykorzystywanych do utrzymania. Segmentacja sieciowa, by była skuteczna, musi być nie tylko fizyczna, ale również logiczna, uwzględniająca zależności między systemami. Jeżeli jedna z warstw zawiedzie – cała koncepcja odporności traci spójność, a systemy stają się jedynie iluzją zabezpieczeń.

Jak możemy sprawdzić, czy nasza architektura rzeczywiście chroni?

Weryfikacja skuteczności środowiska bezpieczeństwa nie może opierać się wyłącznie na zgodności dokumentacyjnej. Audyty, przeglądy, testy penetracyjne mają swoje miejsce, ale współczesna złożoność środowisk bankowych wymaga rozwiązań bardziej dynamicznych i cyklicznych. Coraz większą rolę odgrywają narzędzia, które umożliwiają realistyczną symulację zagrożeń w sposób zautomatyzowany i powtarzalny. Dzięki nim możliwe jest nie tylko wykrywanie luk technicznych, ale również testowanie spójności architektury w praktyce.

Wspomniane narzędzia nie ograniczają się do wykrywania pojedynczych podatności. Weryfikują one cały łańcuch potencjalnego ataku – od dostępu, przez eskalację, aż po eksfiltrację danych. Potrafią modelować rzeczywiste wektory zagrożeń i badać, jak zachowuje się środowisko w odpowiedzi na próbę ich realizacji. Wartością dodaną takich rozwiązań jest ich zdolność do testowania skuteczności narzędzi, które już zostały wdrożone. Symulując ataki, można sprawdzić, czy systemy klasy IAM prawidłowo egzekwują polityki dostępowe, czy SIEM wykrywa anomalie behawioralne, a systemy reagowania rzeczywiście inicjują odpowiednie procedury. Przykładem takiego rozwiązania jest platforma Ridgebot, która umożliwia praktyczną ocenę jakości istniejącej architektury bezpieczeństwa poprzez systematyczną symulację działań ofensywnych.

Czy zgodność z regulacjami wystarczy, by mówić o dojrzałym bezpieczeństwie?

Spełnianie wymogów regulacyjnych, choć nieodzowne, nie jest tożsame z osiągnięciem dojrzałości operacyjnej w zakresie bezpieczeństwa. Dyrektywa NIS2 oraz rozporządzenie DORA wprowadzają wymóg zarządzania ryzykiem operacyjnym i odpornością cyfrową, ale ich realizacja opiera się na ustandaryzowanych, uogólnionych wymaganiach. Tymczasem każda organizacja działa w innym kontekście zagrożeń, w innej topologii infrastrukturalnej i przy innym profilu ryzyka.

Zgodność nie gwarantuje więc odporności – jest jedynie punktem odniesienia. Dojrzałość organizacji polega na zdolności do adaptacji, na elastyczności reagowania na niestandardowe scenariusze, na umiejętności podejmowania decyzji opartych o dane płynące z infrastruktury. W organizacjach rzeczywiście świadomych ryzyka zgodność jest efektem ubocznym prawidłowo zbudowanej architektury – nie jej celem.

W jaki sposób testowanie staje się elementem strategicznej odporności?

Testowanie nie jest jedynie narzędziem kontrolnym – staje się integralnym elementem strategii rozwoju odporności cyfrowej. Instytucje, które traktują testy jako jednorazowe wydarzenie, z góry ograniczają swój potencjał adaptacyjny. Nowoczesne środowiska bezpieczeństwa muszą być testowane w sposób ciągły – w szczególności po wdrożeniach, zmianach konfiguracyjnych, migracjach oraz integracjach zewnętrznych.

Testy prowadzone regularnie pozwalają na wykrycie niespójności między stanem założonym a rzeczywistym. Często okazuje się, że polityki bezpieczeństwa nie zostały wdrożone we wszystkich lokalizacjach, że niektóre punkty końcowe nie raportują stanu zdrowia do SIEM-u, lub że nowe repozytoria danych nie zostały objęte systemem klasyfikacji. W takich sytuacjach testowanie nie służy wykazaniu błędu – lecz szybkiemu jego wykryciu i naprawieniu, zanim zostanie wykorzystany przez podmiot zewnętrzny.

Jak powinna myśleć organizacja projektująca bezpieczny stos technologiczny?

Budowa architektury bezpieczeństwa to zadanie architektoniczne w pełnym znaczeniu tego słowa. Wymaga myślenia modułowego, integracyjnego i perspektywicznego. Organizacja projektująca swój stos technologiczny nie może kierować się tylko wyborem najlepszych produktów – powinna przede wszystkim rozumieć, w jaki sposób poszczególne komponenty będą ze sobą współdziałać oraz jak zostanie zapewniona możliwość ich testowania.

Dojrzała architektura bezpieczeństwa nie powstaje z katalogu produktów. Powstaje z decyzji projektowych: jak dane będą klasyfikowane i kontrolowane, jak będzie wyglądać segmentacja logiczna usług, jak monitorowane będą anomalie w ruchu sieciowym, jak będą egzekwowane polityki dostępu i wreszcie – jak i kiedy system sam się przetestuje. Tylko w takim modelu możliwe jest osiągnięcie rzeczywistej odporności – nie deklarowanej, lecz mierzalnej i dowiedzionej.