„ATAKUJĄ BANKI”. THREAT INTELLIGENCE OSTRZEGA – CO ROBI BANK?

Przychodzi komunikat:

„Obserwujemy aktywne ataki wymierzone w sektor finansowy.”

Pojawiają się nowe IOC, wykorzystywane podatności, domeny, adresy IP albo informacje o kampanii ransomware.

I co dalej?   Czy bank:  czyta komunikat i archiwizuje go    czy   zmienia na jego podstawie poziom gotowości?

Bo właśnie na tym polega praktyczne wykorzystanie Threat Intelligence w banku.

Nie chodzi o posiadanie informacji o zagrożeniu.   Chodzi o to, co bank zrobi z tą informacją zanim pojawi się incydent.

Threat Intelligence nie powinno kończyć się na mailu

Informacja o aktywnym zagrożeniu powinna uruchomić konkretną ocenę.

Bank powinien szybko ustalić:

• czy zagrożenie dotyczy używanych technologii,
• czy posiadamy wskazane podatności,
• czy nasze systemy są eksponowane,
• czy SOC posiada odpowiednie reguły detekcji,
• czy IOC występują w logach,
• czy ryzyko dotyczy procesów krytycznych.

Najważniejsze pytanie brzmi:

czy ostrzeżenie ma znaczenie dla naszego banku?

Czy bank posiada podatny system?

Jeżeli Threat Intelligence wskazuje konkretną podatność, pierwszym krokiem powinno być sprawdzenie ekspozycji.

Warto ustalić:

• czy podatna technologia występuje w banku,
• na ilu systemach,
• czy jest dostępna z Internetu,
• jaki proces wspiera,
• czy istnieje exploit,
• czy podatność jest aktywnie wykorzystywana.

Wtedy zwykły wpis w rejestrze podatności może nagle stać się priorytetem działania.

SOC powinien dostać konkretne zadanie

Komunikat Threat Intelligence powinien zostać przełożony na monitoring.

SOC może otrzymać:

• IOC do wyszukania,
• adresy IP,
• domeny,
• hashe,
• zachowania charakterystyczne dla ataku,
• nowe reguły detekcji,
• informację o systemach wymagających szczególnej obserwacji.

Kluczowe pytanie brzmi:

czy potrafimy wykryć ten atak, jeśli rozpocznie się dziś wieczorem?

Ostrzeżenie powinno zmienić priorytety

Nie każda podatność High lub Critical wymaga identycznej reakcji.

Jeżeli pojawia się potwierdzona informacja o aktywnym wykorzystaniu konkretnej luki, jej priorytet może wzrosnąć natychmiast.

Warto więc łączyć:

CVSS → ekspozycja → BIA → aktywne zagrożenie → możliwość wykorzystania → wpływ na bank

Threat Intelligence dostarcza właśnie tego elementu, którego często brakuje w statycznej ocenie:

co atakujący robią teraz.

Co powinno zrobić IT?

Jeżeli zagrożenie dotyczy środowiska banku, działania mogą obejmować:

• pilną aktualizację,
• zmianę konfiguracji,
• ograniczenie ekspozycji,
• blokadę określonego ruchu,
• dodatkową segmentację,
• zwiększenie monitoringu,
• zastosowanie zabezpieczenia kompensującego.

Nie zawsze można natychmiast wykonać patch.

Ale prawie zawsze można odpowiedzieć na pytanie:

co zrobimy, aby ograniczyć ryzyko do czasu pełnej naprawy?

Co robi ABI?

ABI powinien połączyć informacje techniczne z obrazem ryzyka dla banku.

W praktyce warto ustalić:

• jakie aktywa są zagrożone,
• jakie procesy są z nimi związane,
• jaki jest potencjalny wpływ,
• jakie działania już wykonano,
• jakie ryzyko nadal pozostaje,
• czy potrzebna jest eskalacja.

Threat Intelligence staje się wtedy elementem zarządzania ryzykiem ICT, a nie tylko źródłem informacji dla IT.

Kiedy informować Zarząd?

Nie każdy alert Threat Intelligence powinien trafiać do Zarządu.

Ale warto eskalować sytuację, gdy zagrożenie:

• dotyczy procesów krytycznych,
• jest aktywnie wykorzystywane,
• obejmuje podatny system banku,
• wymaga pilnych zmian,
• może wpłynąć na klientów,
• tworzy istotne ryzyko ciągłości działania.

Zarząd nie potrzebuje pełnej analizy technicznej.

Potrzebuje odpowiedzi:

Co się dzieje?
Czy dotyczy naszego banku?
Co już zrobiliśmy?
Jakie ryzyko pozostaje?

Threat Intelligence powinno kończyć się dowodem działania

Dobry proces można przedstawić tak:

OSTRZEŻENIE → OCENA → WERYFIKACJA → DZIAŁANIE → MONITORING → WYNIK → DOWÓD

Dowodem może być:

• wynik wyszukania IOC,
• ticket SOC,
• raport ze skanowania,
• wdrożona poprawka,
• zmiana konfiguracji,
• decyzja o zastosowaniu zabezpieczenia kompensującego,
• retest.

Wtedy bank może wykazać nie tylko:

„otrzymaliśmy ostrzeżenie”

ale:

„otrzymaliśmy ostrzeżenie i odpowiednio zareagowaliśmy”.

7 pytań po otrzymaniu ostrzeżenia Threat Intelligence

1. Czy wskazane zagrożenie dotyczy naszych technologii?
2. Czy posiadamy wskazaną podatność?
3. Czy zagrożony system wspiera proces krytyczny?
4. Czy SOC potrafi wykryć ten sposób ataku?
5. Czy IOC występują już w naszym środowisku?
6. Jakie działanie ograniczające ryzyko wykonujemy teraz?
7. Czy Zarząd powinien wiedzieć o sytuacji?

Jeżeli te pytania mają przypisanych właścicieli i jasną ścieżkę działania, Threat Intelligence zaczyna mieć realną wartość.

Podsumowanie

Threat Intelligence nie jest po to, aby bank wiedział, że „na świecie jest niebezpiecznie”.

Jego wartość zaczyna się wtedy, gdy informacja prowadzi do działania.

Praktyczny model:  zagrożenie → nasza ekspozycja → proces krytyczny → monitoring → zabezpieczenie → decyzja → dowód

Najważniejsze pytanie nie brzmi:   „Czy otrzymaliśmy ostrzeżenie?”   ale:   „Co zrobiliśmy, zanim atakujący sprawdził naszą gotowość?”

Pytania i odpowiedzi

Czym jest Threat Intelligence w banku?

To informacje o aktualnych i potencjalnych zagrożeniach, które bank może wykorzystać do poprawy monitoringu, oceny ryzyka i działań ochronnych.

Czy każde ostrzeżenie wymaga reakcji?

Wymaga przynajmniej oceny, czy dotyczy technologii, procesów lub ekspozycji banku.

Jak Threat Intelligence wpływa na podatności?

Informacja o aktywnym wykorzystaniu luki może znacząco zwiększyć jej priorytet naprawy.

Jaką rolę pełni SOC?

SOC powinien wykorzystywać IOC i informacje o taktykach atakujących do wyszukiwania śladów i ulepszania detekcji.

Kiedy informować Zarząd?

Gdy aktywne zagrożenie dotyczy istotnych systemów, procesów krytycznych lub tworzy znaczące ryzyko operacyjne.

Czy Threat Intelligence powinno być dokumentowane?

Tak. Bank powinien móc wykazać, jakie ostrzeżenie otrzymał, jak je ocenił i jakie działania podjął.

Threat Intelligence ostrzega. Czy Twój bank wie, co robi w ciągu następnej godziny?

Jeżeli informacja o aktywnym zagrożeniu trafia do banku, ale nie ma jasno określonej ścieżki:

kto ocenia → kto sprawdza → kto działa → kto eskaluje → kto dokumentuje

warto uporządkować ten proces zanim pojawi się realny incydent.

Skontaktuj się bezpośrednio ze specjalistami Servus Comp Kraków.

Pomagamy bankom spółdzielczym w:

• analizie aktywnych zagrożeń,
• powiązaniu TI z podatnościami i BIA,
• ocenie ekspozycji systemów,
• definiowaniu zasad eskalacji,
• przygotowaniu dowodów reakcji,
• raportowaniu ryzyka do Zarządu.

Servus Comp Kraków
Bezpieczeństwo • Odporność • Ryzyko ICT • Zgodność

Ostrzeżenie ma wartość dopiero wtedy, gdy prowadzi do działania.

Zadzwoń lub napisz do Servus Comp, aby omówić temat.

• Strona główna: https://premiumbank.zadbajobezpieczenstwo.pl

Servus Comp Data Security, Świętokrzyska 12/403, 30-015 Kraków

tel. +48 608 407 668, +48 12 631 91 22 • biuro@servus-comp.pl

PODEJMIEMY DLA PAŃSTWA KAŻDE WYZWANIE!

JESTEŚ ZAINTERESOWANY? ZADZWOŃ, NAPISZ DO NAS

#UmowaZDostawcąICT #ZDU #BankSpółdzielczy #DostawcaICT #DORA #SLA #RTO #RPO #BIA #Podwykonawcy #RODO #AI #PrawoAudytu #StrategiaWyjścia #RyzykoICT #CiągłośćDziałania #Cyberbezpieczeństwo #ZarządBanku #ServusCompKraków