SOC NIE WIDZI WSZYSTKIEGO. CZY BANK ZNA SWOJE ŚLEPE PUNKTY?

Bank ma SOC. Ma EDR. Logi trafiają do SIEM. Alerty są analizowane.

Czy to oznacza, że bank zobaczy każdy rozpoczynający się incydent?

Nie zawsze.

Największym problemem może nie być brak SOC. Może nim być to, czego SOC w ogóle nie widzi.

EDR jest wdrożony. Ale gdzie?

Pierwsze pytanie jest bardzo proste: czy EDR rzeczywiście działa na wszystkich urządzeniach, na których powinien działać?

Warto sprawdzić m.in.:

• serwery,
• stacje robocze,
• laptopy,
• urządzenia administracyjne,
• systemy krytyczne,
• urządzenia pracujące poza główną siecią.

Wystarczy kilka aktywów poza monitoringiem, aby powstał ślepy punkt.

SIEM analizuje logi. Ale czy ze wszystkich ważnych systemów?

SIEM może przetwarzać miliony zdarzeń. To nadal nie oznacza pełnej widoczności.

Trzeba wiedzieć: które systemy wysyłają logi, a które nie.

Firewall?

Active Directory?

VPN?

Systemy krytyczne?

Aplikacje bankowe?

Backup?

Urządzenia sieciowe?

Systemy bezpieczeństwa?

Jeżeli krytyczne aktywo nie przekazuje odpowiednich logów, SOC może dowiedzieć się o problemie dopiero wtedy, gdy skutki będą już widoczne.

A co z systemami lokalnymi?

W bankach nadal funkcjonują rozwiązania, które mogą pozostawać poza centralnym monitoringiem.

Starsza aplikacja.

Lokalny serwer.

Urządzenie sieciowe.

System techniczny.

Komputer wykorzystywany do szczególnego zadania.

Pytanie brzmi:

czy ktoś świadomie zdecydował, że tego aktywa nie monitorujemy, czy po prostu o nim zapomniano?

To ogromna różnica.

ZDU to również część widoczności banku

Jeszcze trudniejsza sytuacja pojawia się przy zewnętrznych dostawcach usług ICT.

Bank korzysta z usługi.

Ale kto widzi zdarzenia bezpieczeństwa po stronie ZDU?

Czy SOC banku otrzymuje informacje?

Czy dostawca posiada własny monitoring?

Jak szybko zgłosi incydent?

Jakie logi są dostępne dla banku?

Outsourcing usługi nie oznacza outsourcingu ryzyka.

Jeżeli krytyczny proces zależy od ZDU, bank powinien wiedzieć, jak zobaczy problem po drugiej stronie połączenia.

Najpierw aktywa. Potem monitoring.

Nie da się odpowiedzieć na pytanie:

„Czy SOC widzi wszystko, co powinien?”

jeżeli bank nie ma aktualnej wiedzy o swoich aktywach ICT.

Dlatego warto połączyć:

AKTYWA ICT → KRYTYCZNOŚĆ → ŹRÓDŁA LOGÓW → EDR → SIEM → SOC → ALERT → REAKCJA

Dopiero wtedy można znaleźć miejsca, w których łańcuch się urywa.

7 pytań, które warto zadać SOC, IT i ASI

1. Czy wszystkie krytyczne aktywa ICT są objęte monitoringiem?
2. Na których urządzeniach nie działa EDR i dlaczego?
3. Które systemy nie przekazują logów do SIEM?
4. Czy monitorujemy systemy lokalne i starsze rozwiązania?
5. Jak wykrywamy incydenty dotyczące usług świadczonych przez ZDU?
6. Czy wiemy, kiedy źródło logów przestaje raportować?
7. Czy ktoś okresowo porównuje rejestr aktywów z zakresem monitoringu SOC?

Jeżeli na któreś pytanie trudno odpowiedzieć od razu, warto sprawdzić ten obszar dokładniej.

Bo brak alertu nie zawsze oznacza brak incydentu.

Czasem oznacza tylko: nie mieliśmy miejsca, z którego można było go zobaczyć.

Czy Twój SOC naprawdę widzi to, co najważniejsze?

Nie pytaj wyłącznie:„Czy mamy SOC?” 

Zapytaj: „Czego nasz SOC dzisiaj NIE widzi?”

To pytanie może ujawnić więcej niż kolejny miesięczny raport bezpieczeństwa.

Jeżeli chcesz zweryfikować zakres monitoringu, źródła logów, pokrycie EDR/SIEM oraz aktywa pozostające poza obserwacją, skontaktuj się ze specjalistami Servus Comp Kraków.

Pomagamy bankom spółdzielczym identyfikować ślepe punkty monitoringu bezpieczeństwa i oceniać, czy rzeczywisty zakres SOC odpowiada krytyczności procesów i aktywów ICT.

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

Najgroźniejszy alert może być tym, którego SOC nigdy nie otrzymał.

Polecane wpisy dla banków spółdzielczych

Zapraszamy również do zapoznania się z innymi materiałami przygotowanymi z myślą o Zarządach i pracownikach banków spółdzielczych, osobach odpowiedzialnych za bezpieczeństwo informacji, ICT, DORA, zgodność i zarządzanie ryzykiem.

1. 1. AUDYT ZA PARĘ SREBRNIKÓW CZY AUDYT, KTÓRY WYTRZYMA PYTANIA SOZ, KNF I BIEGŁEGO REWIDENTA?
   2. SOC nie widzi wszystkiego. Czy bank zna swoje ślepe punkty?
   3. Awaria już trwa – co bank odtwarza jako pierwsze i kto o tym decyduje?
   4. Zostałeś ABI. I co teraz?
   5. „ATAKUJĄ BANKI”. THREAT INTELLIGENCE OSTRZEGA – CO ROBI BANK?
   6. DORA, RTS, EBA, KNF – Jak nie pogubić się w wytycznych i wiedzieć, co naprawdę wdrożyć?
   7. Bank ma procedury. Audytor pyta: „proszę pokazać, że one działają”.
   8. Dostawca nie działa. Bank też. Czy tak miało być?
   9. Exit plan dostawcy a exit plan banku – czy strategia wyjścia naprawdę chroni interes banku?
   10. Umowa chroni dostawcę. A kto chroni bank?
   11. Backup mówi „SUCCESS”. Ransomware mówi „SPRAWDZAM”
   12. Podatność jest critical. Ale czy naprawdę jest najważniejsza?
   13. SOC widzi alert. Ale czy wie, co jest ważne dla banku?
   14. Prezesie, proszę pilnie zatwierdzić przelew. Głos brzmi dokładnie jak głos członka zarządu. To deepfake.
   15. Ocena ryzyka ICT przez KNF wypadła słabo. Co teraz?
   16. Ransomware w banku i inne kryzysy – testy stolikowe i scenariuszowe: czy bank naprawdę potrafi działać?
   17. INCYDENT O 15:47. PREZES PYTA: „CO ROBIMY?” – KTO W BANKU ZNA ODPOWIEDŹ?
   18. DORA I RTS bez BIA to nie wdrożenie. To chaos bez priorytetów.
   19. BIA w banku spółdzielczym – jak przygotować analizę krok po kroku?
   20. Zarząd pyta IT: „Czy jesteśmy bezpieczni?” – czy odpowiedź „tak” cokolwiek znaczy?
   21. PAM w banku spółdzielczym – JumpServer, DORA i kontrola dostępu uprzywilejowanego
   22. Bank bez systemu PAM? JumpServer – bezpłatna ochrona dostępu uprzywilejowanego dla banków spółdzielczych
   23. Skan to za mało. Jakie testy penetracyjne powinien zlecić bank spółdzielczy, żeby nie usłyszeć tego na audycie?
   24. Wysadzenie bankomatu to nie tylko szkoda. To test procedur Banku
   25. 10 wybranych najważniejszych zaleceń KNF po ocenie ryzyka ICT 2025 — praktyczne podsumowanie dla banków spółdzielczych
   26. Dokument jest? KNF zapyta o dowód, że działa
   27. Znalazłeś podatność? KNF zapyta, kiedy ją usunąłeś
   28. Raport ICT do Zarządu — KNF pyta, kto nadzoruje ryzyko ICT w Banku
   29. Jeden dostawca, wiele systemów, jedno duże ryzyko. KNF pyta o koncentrację ICT
   30. Skan podatności to nie test odporności. KNF zapyta, czy Bank naprawdę testuje ICT

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

#SOC #MonitoringSOC #BankSpółdzielczy #EDR #SIEM #LogiBezpieczeństwa #AktywaICT #SystemyLokalne #ZDU #ŚlepePunktyMonitoringu #Cyberbezpieczeństwo #RyzykoICT #IncydentyICT #MonitoringBezpieczeństwa #ProcesyKrytyczne #InfrastrukturaICT #DetekcjaZagrożeń #OdpornośćCyfrowa #DORA #ServusCompKraków