Jak skutecznie wdrożyć SAP Security Monitoring i integrację z SIEM – podejście praktyczne 

Aktie
  • Säkerhet, SAP

Na początku chwila dla odpowiedzi na pytanie jak środowiska SAP są bezpieczne.
SAPinsider w maju 2025 opublikował raport, z którego wynika, że 23% respondentów doświadczyło ataku na środowiska SAP w ciągu ostatnich 12 miesięcy. 

Zaznaczono również wzrost rok do roku zagrożeń związanych z dostępem nieuprawionym do dnaych czy ataki bezpośrednio na łańcuch dostaw.  

Środowiska SAP często stanowią silos monitoringu bezpieczeństwa. Nawet jeśli jest to zasób danych monitorowany, to czesto niekompletnie. W tym wpisie opiszemy jak możemy podnieść poziom bezpieczeństwa do ram, pozwalających na identyfikację wszelkich wyzwań bezpieczeństwa.  

Wdrożenie monitoringu bezpieczeństwa SAP to nie tylko podłączenie systemu do SIEM.
To proces, który zaczyna się od właściwego określenia zakresu, a kończy na codziennym utrzymaniu i doskonaleniu detekcji incydentów. W tym artykule pokazuję, jak podejść do tego tematu w sposób praktyczny – bazując na realnych doświadczeniach projektowych.

Po pierwsze – zakres

Zakres wdrożenia i integracja to fundament każdego rozwiązania. Musimy klarownie odpowiedzieć na pytanie – co właściwie chcemy zrobić? Co chcemy monitorować i jaka jest tego przyczyna? Czym innym jest monitorowanie zmian paramentrów i konfiguracji a czym innym podejscie do monitorowania dostępów do transakcji czy wprost zmian masterdata. 

Dodatkowo – w jaki sposób i gdzie chcemy monitorować. Tu pojawia sie kolejne wyzwanie: 

  • Jakie systemy mamy w naszym ekosystemie? 
  • Jakie środowiska (DEV/TEST/PROD)? 
  • Jakie jest znaczenie biznesowe powyższych? 


Kluczowe tu jest rozróżnienie środowisk – system produkcyjny i testowy różnią się nie tylko ważnością, ale też typem zagrożeń. Dodatkowo pojawia się pytanie odnośnie jakości danych na systemach nieprodukcyjnych (czyli jeśli to kopia, to czy mamy kontrolę nad dostępem do danych skopiowanych z produkcji. 

Przykład podziału jest dość intuicyjny: 

  • PROD to krytyczne zdarzenia (takie jak zmiany ról czy dostępów), 
  • TEST to potencjalne ryzyko związane z kopiami danych produkcyjnych. 


Nie można więc stosować identycznych reguł monitoringu dla wszystkich środowisk.

Wdrożenie centralne czy rozproszone? 

Nastepnym fundamentalnym pytanie jest architektura stacku do monitorowania (każda z decyzji ma swoje wady i zalety oraz konsekwencje związane z tym ile czasu i w jaki sposób musimy podejść do monitorowania): 

  • centralny monitoring – czyli wszystko w jednym miejscu – to łatwiejsze zarządzanie i standaryzacja, 
  • rozproszony monitoring – każdy system z osobna, to większa kontrola lokalna, ale większa złożoność utrzymania. 


Podjęcie decyzji o sposobie rozproszenia lub centralizacji wpływa wprost między innymi na: 

  • sposób przetwarzania zdarzeń, 
  • ich agregację, 
  • integrację z SIEM.


Teraz zdarzenia – monitorowanie każdego może nie mieć sensu. Tymbardziej w kontekście tego gdzie takie zdarzenie obserwujemy. Przykład takich, dla których nie koniecznie jest sens dla środowisk nieprodukcyjnych: 

  • Przypisanie ról  
  • Działania administracyjne 
  • Zmiany konfiguracji 
  • Dostęp do danych wrażliwych (jeśli nie mamy kopii systemu produkcyjnego lub dane są scramblowane na poziomie bazy danych). 

 

Sam zakres tego co chcemy obserwować jest bezpośrednio zależny od ryzyk, jakie czynność może mieć na bines, bolączek klienta czy wprost specyfiki systemów, które obserwujemy. 

Po drugie – SIEM

SIEM to dodatkowe możliwości a nie cel sam w sobie, integracja z nimto tylko jeden z elementów układanki. Nie każde zdarzenie to incydent. Fundamentalną zasadą jest stwierdzenie, że SIEM nie służy do zbierania wszystkiego – tylko do identyfikacji incydentów. 

Możemy spojrzeć na SIEM jako na wsparcie monitoringu, pozwalające na odpowiedzenie na kilka zasadniczych kwestii: w jaki sposób filtrować dane, w jaki sposób korelować aktywności SAP z innymi eventami z naszej infrastruktury, i w jaki sposób chcemy analizować zidentyfikowane problemy. 

A skoro w SIEM możemy integrować aktywności, to możliwe jest wsparcie procesu o takie elementy jak: 

  • łączenie zdarzeń z SAP z innymi źródłami (np. Active Directory), 
  • wykrywanie anomalii (np. aktywności poza godzinami pracy), 
  • budowanie scenariuszy ataków (czyli po nitce do kłębka – skąd i kto co robi). 

 

To szczególnie ważne, bo SAP to tylko jedno ze źródeł danych – SIEM agreguje całość obrazu bezpieczeństwa.

Po trzecie – kompetencje

W praktyce zespoły Security Operation Center nie posiadają wyspecjalizowanych kompetencji SAP. SOC to specjaliście od security, ale ze względu na to, że SAP generuje bardzo specyficzne zdarzenia możemy mieć problem, by odpowiednio zaadresować konkretne znalezisko.  

Dlaczego to problem? Bez odpowiedniej wiedzy zdarzenia mogą być źle interpretowane. Same alerty mogą albo być zignorowane (nie wiemy co się dzieje), albo nadinterpretowane (szum informacji). A to ostatnie może prowadzić do rosnącej liczby false positive. Co z kolei skutkuje obniżeniem jakości monitoringu.  

Co jest zatem potrzebne, by skutecznie zaadresować wątek kompetencji? Mamy kilka opcji (i tak jak zawsze – wybór prowadzi do konsekwencji: 

  • Szkolenia SOC z podstaw SAP – napewno nie załatwi to luki wiedzy 
  • Wsparcie zespołu SAP (BASIS) lub wprost SAP Security 
  • Manage service zewnętrznego zespołu SAP Security  

Po czwarte – definicje zdarzeń

Kluczowym elementem monitoringu jest odpowiednia definicja zdarzeń i ich struktury. Głównie sprowadza się to do odpowiedniej standaryzacji danych. Jeśli pola są dobrze oznaczone a struktura zdarzeń jest spójna to łatwiej budować reguły detekcji i analiza zdarzeń przez SOC jest prostsza. 

W praktyce systemy SIEM często pomagają automatycznie wykrywać pola, ale konieczna jest walidacja i konsultacja ekspercka. Tu się kłania wątek komptencji SAP.

Lukardi levererar:

  • implementeringar av SAP:s säkerhetslösningar i Europa,
  • NIS2-checklistor som utarbetats av experter,
  • Benchmarks som bekräftar en minskning av revisionstiderna med 70-80%,
  • Fullständigt PoC-stöd i SAP-miljöer.

Po piąte - samo podłączenie SAP-SIEM to nie wszystko

Bezpośrednie podłączenie SAP do SIEM może okazać się problematyczne. Już mówiliśmy o kompetencjach. Sam fakt podłączenia do wszelkich źródeł logów (a ich jest kilka) powoduje ogromny wolumen danych. To prowadzi do dwóch głównych wad: 

  • Szum informacyjny (kto jest w stanie przerobić taką liczbę zdarzeń i wyłuskać te krytyczne?) 
  • Wysokie koszty przetwarzania (współczesne narzędzia SIEM zazwyczaj roliczane licencyjnie są na podstawie wolumenu przetwarzanych danych)  


Zatem istotne jest wprowadzenie warstwy pośredniej po to by ułatwić i ustandaryzować przesył istotnych informacji z SAP do SIEM. Warstwa taka: 

  • agreguje dane z różnych źródeł SAP (SAL, change logs, system logs), 
  • normalizuje je do postaci zdarzeń, 
  • filtruje je na poziomie aplikacji SAP. 


Konsekwencje to między innymi: redukcja danych – mniej niż 1% logów zawierają krytyczne z perspektywy security informacje; lepsza jakość informacji – baza eventów wprost odpowiada realnym scenariuszom; niższe koszty SIEM – tylko istotne informacje wpadają do SIEMa. 

A jak to wygląda w praktyce? Typowy przepływ informacji z SAP do SIEM to: 

  1. SAP generuje zdarzenia, 
  2. zapis do plików na poziomie OS, 
  3. forwarding (np. agentem) do SIEM, 
  4. korelacja i analiza.. 

 

Po szóste - codzienne aktywności

I tu zaczyna się konkretny monitoring. Celem końcowym nie jest zbieranie danych, tylko: 

identyfikacja realnych incydentów przy minimalnym szumie. 

Do codzienny zadań zespołu bezpieczeństwa należy między innymi: 

  • Analiza alertów 
  • redukcja false positives, 
  • optymalizacja filtrów, 
  • monitorowanie trendów i anomalii, 
  • włączanie nowych źródeł danych. 

 

Monitorowanie SAP to ewolucja. Początkowe aktywności muszą koncentrować się nad odpowiednim wyborze źródeł danych, by ogarnąć ilość szumu oraz wybrać z niego to, co krytyczne dla organizacji.  

Z czasem trwania tej naturalnej ewolucji dochodzimy do momentu, w którym możemy zidentyfikować te zdarzenia, które są niepotrzebne, a w ramach dopracowywania reguł skupiamy się na tym, co naprawdę istotne. 

A stąd już prosta droga do identyfikacji anomalii i trendów. Na przykład nagłe piki zdarzeń, nietypowe wzorce czy po prostu działania, które nie wyglądają na standardowe. Często to coś, że występujące pojedynczo nie wzbudza podejrzeń. 

 

Sammanfattning

Obserwujemy wyzwania związane z brakiem klarownej i przejrzystej wizji bezpieczeństwa SAP. Organizacyjnymi wyzwaniami są kompetencje i synchronizacja ich by ocenić konkretne zdarzenia bezpieczeństwa.  

Technicznie – wyzwaniami jest integracja źródeł danych dostarczanych przez systemy SAP. Bo nie tylko Security Audit Log zawiera konkretne informacje. Logi OS, bazy danych, interfejsy czy change table/documents – tu często jest “mięso”.  

A jeśli jest to wyzwanie – to zaadresowanie jego poprzez filtrowanie zdarzeń na poziomie warstwy aplikacji SAP pozwoli na oszczędności kosztów SAP i wzrost przejrzystości w warstwie bezpieczeństwa SAP.  

Kompetencyjnie – musimy uświadomić sobie oczywiste braki na poziomie SOC w wiedzy odnośnie analizy SAP. Natomiast i to możemy ogarnąć za pomocą wsparcia kompetencji w konkretnych cyklach. Czy to codzienne wsparcie czy kształtowanie alertów i typów zdarzeń.  

Skuteczny monitoring SAP to nie projekt technologiczny – to proces operacyjny. 

Najważniejsze elementy sukcesu: 

  • dobrze określony zakres, 
  • świadoma integracja z SIEM, 
  • kompetencje (lub ich uzupełnienie), 
  • ciągła optymalizacja. 

Największą wartością nie jest liczba zebranych logów – tylko liczba wykrytych realnych incydentów.

Joanna Komsa

Digital Transformation & Business Development |Marketing Manager på Lukardi.
Hon har arbetat med onlinemarknadsföring, strategibyggande och kommunikation i 15 år. Passionerad av ny teknik, AI och neuropsykologi. Hon hjälper organisationer med digital omvandling och att skapa nya affärsmöjligheter genom att kombinera erfarenhet inom dordzdz, försäljning och marknadsföring.