Pomagamy klientom, którzy chcą używać rozwiązań SAP w sposób świadomy

Z Jackiem Bugajskim, prezesem zarządu w firmie SNOK, rozmawiamy o podejściu polskich firm do zabezpieczenia systemów klasy ERP; specyfice środowisk SAP w kontekście bezpieczeństwa, integracji z platformami SIEM oraz Security Operations Center, możliwościach oprogramowania SecurityBridge, wykrywaniu luk bezpieczeństwa i błędów w warstwie ABAP, a także usługach audytu i poprawy bezpieczeństwa środowisk SAP.

O bezpieczeństwie systemów klasy ERP nie mówi się zbyt dużo…

Ten temat faktycznie nie jest jeszcze w Polsce szczególnie popularny – pewnie dlatego, że jest dość trudny. Tymczasem należy pamiętać, że w systemach klasy ERP znajdują się dane krytyczne dla biznesu, a same rozwiązania tego typu mają zwykle kluczowe znaczenie dla funkcjo­nowania całej organizacji.

Ponadto, systemy tej klasy są często po­strzegane jako pewnego rodzaju „czarne skrzynki” – złożone technicznie i skom­plikowane w działaniu – i jako takie po­zostają poza obszarem szczególnego zainteresowania działów bezpieczeństwa dopóty, dopóki ktoś nie przełamie ich zabezpieczeń.

Jednocześnie, zagrożeń wymierzonych wprost w takie systemy jest bardzo dużo. Mogą być to ataki generowane przez kon­kurencję, działania motywowane chęcią uzyskania okupu za zaszyfrowane dane, wreszcie ataki prowadzone przez sfru­strowanych pracowników czy osoby, które zmieniając pracę, chcą wyprowadzić tro­chę wiedzy biznesowej.

Jak wygląda poziom bezpieczeństwa u klientów SAP w Polsce?

W Polsce istnieje duży rozstrzał kom­petencyjny pod względem podejścia do bezpieczeństwa. Dobitnie widać to w ob­szarze rozwiązań SAP. Niektóre organi­zacje nie mają dziś żadnych działów bezpieczeństwa, a kwestiami tymi zajmują się – niejako przy okazji – administratorzy SAP. Istnieją także firmy, które dysponują działem obsługi SAP i bezpieczeństwa, ale najczęściej są to dwa różne światy, które nie komunikują się ze sobą. Niewie­le jest natomiast organizacji, w których te dwa działy współpracują ze sobą na bieżąco.

Dlaczego bezpieczeństwo systemów SAP jest tak często bagatelizowane?

Po pierwsze, kiedyś bezpieczeństwo śro­dowisk SAP było tematem tabu, a wiedza na ich temat wśród hakerów należała do rzadkości. Bardzo wąska grupa osób na świecie zajmowała się włamywaniem do nich. Nie było również GitHuba i publi­kowanych publicznie informacji o lukach w oprogramowaniu SAP. W efekcie, szansa na to, że konkretna instalacja SAP stanie się celem ataku była niewielka.

Poza tym kiedyś SAP był systemem monoli­tycznym, napisanym we własnej technolo­gii i nie korzystał z rozwiązań open source czy produktów firm trzecich. Dziś to się zmieniło. Niektóre elementy środowiska SAP są tworzone np. w Javie i wystawia­ne do internetu. Pokazał to przykład luki Log4Shell, która została wykorzystana do ataków na systemy SAP. Faktem jest, że SAP co miesiąc udostępnia poprawki i noty bezpieczeństwa usuwające znane luki, ale hakerzy są znacznie szybsi. Jeśli uda im się wykorzystać taką lukę i dostać do wnę­trza środowiska SAP, to jest to zagrożenie o charakterze krytycznym dla biznesu.

Druga kwestia to podejście do projektów zakładających wdrożenie oprogramowa­nia SAP. Projekty takie są realizowane po to, aby pozyskać określoną funkcjonal­ność biznesową, ale w czasie przygotowań do takich wdrożeń mało czasu poświęca się aspektom związanym z technologią czy bezpieczeństwem. Wdrożenie jest realizowane szybko, a elementy istotne pod względem wzorcowej konfiguracji SAP oraz bezpieczeństwa są często pomija­ne, bo nie ma na nie czasu ani budżetu. Praktyka pokazuje, że środowiska SAP w Polsce wymagają dużo pracy, aby były idealnie zabezpieczone.

Które elementy środowiska SAP są najbardziej narażone na działania cyberprzestępców?

Wszystko zależy od konkretnej instalacji SAP, serwera aplikacyjnego, bazy danych, a nawet systemu operacyjnego serwera oraz SAP GUI. Jeśli nie zostały ściśle zde­finiowane uprawnienia, to wiele można „zepsuć” nawet z poziomu zwykłego użytkownika. Przykładowo, w 2022 roku wykryty został błąd, który pozwalał na wykonanie z kodu ABAP każdej komendy systemu operacyjnego z uprawnieniem ad­ministratora. Dawało to niewątpliwie duże możliwości ewentualnym atakującym.

Najciekawsze dane pozostają jednak we wnętrzu SAP. To, że atakujący uruchomi coś na systemie operacyjnym serwera, to może zdestabilizować działanie środowiska SAP, ale newralgiczne dane pozostaną w tabe­lach bazy danych SAP. Co innego, jeśli ha­ker potrafi poruszać się wewnątrz świata SAP. Wówczas jest w stanie wydobyć wiele krytycznych informacji. Tego typu eskala­cje najczęściej odbywają się przez serwer aplikacyjny, bo dostęp z poziomu bazy da­nych jest trudniejszy do zrozumienia przez średniej klasy hakera. Z poziomu serwera aplikacyjnego dostęp jest łatwiejszy.

Trzeba zatem chronić dostęp do systemu SAP, a tu przychodzi z pomocą promowa­na powszechnie polityka zero-trust, któ­ra zakłada, że ufamy tylko urządzeniom, które znamy i użytkownikom, którzy się właściwie uwierzytelnią. Jeśli mamy to do­brze uszczelnione, to trudno jest włamać się do systemu SAP z zewnątrz organizacji. Nadal jednak spotykamy firmy, które mają wystawiony serwer bazodanowy razem z aplikacyjnym, więc nawet osoba niepo­siadająca dostępu do SAP widzi te serwery w sieci wewnętrznej, co samo w sobie po­zwala jej na podjęcie określonych działań.

W jakim stopniu bezpieczeństwo sys­temów SAP jest zależne od sposobu ich wdrożenia?

Mamy dziś trzy główne modele wyko­rzystania oprogramowania SAP. Pierw­szy, znany od lat i najczęściej stosowany w Polsce, to model on-premise, który zakłada, że dana organizacja ma własne środowisko i to w ramach tego środowi­ska utrzymuje system SAP. W tym modelu poziom bezpieczeństwa oprogramowania i danych krytycznych jest w rękach osób, które tym środowiskiem zawiadują.

Drugi model zakłada wykorzystanie mo­delu chmurowego. Polskie firmy coraz częściej decydują się na używanie roz­wiązań SAP na bazie zasobów udostęp­nianych w ramach tzw. publicznej chmury obliczeniowej – choćby na potrzeby ob­sługi wybranych modułów oprogramo­wania SAP, jak DRC lub HA, czy środowisk dewelopersko-testowych. W tym podej­ściu, jeśli chodzi o bezpieczeństwo, jest o tyle łatwiej, że jesteśmy w stanie bardzo szybko stworzyć środowisko i podpiąć pod nie różne mechanizmy bezpieczeństwa oferowane przez dostawcę usług chmu­ry. Jako partner Microsoft mamy bardzo mocno rozeznane wszystkie narzędzia tej firmy, które można w łatwy i szybki sposób wdrożyć, aby podnieść poziom bezpieczeństwa SAP, nie angażując w to wszystkich zespołów IT w organizacji.

Trzecim podejściem jest oferta RISE with SAP. Zakłada ona model, w którym to SAP bezpośrednio oferuje klientom dostęp do oprogramowania SAP opar­tego na wybranej platformie chmurowej na zasadzie subskrypcji. W tym podej­ściu to producent, a zarazem dostawca usługi, dostarcza klientom mechani­zmy zabezpieczające, aczkolwiek one także wymagają świadomego użycia, ponieważ nie zawsze mogą pasować do potrzeb danej firmy oraz polityk bez­pieczeństwa.

Mamy już zapytania o przeglądy bezpie­czeństwa bądź testy penetracyjne śro­dowisk RISE with SAP – i takie projekty realizujemy, sprawdzamy, czy wszyst­kie mechanizmy oferowane przez SAP rzeczywiście są wdrożone i czy działają jak należy. Niezależnie od tego, że SAP w modelu RISE with SAP jest rozwiąza­niem zarządzanym przez producenta, to takie instalacje także wymagają obsługi technologicznej od osób, które rozumieją charakterystykę danego projektu.

W jaki sposób SNOK prowadzi analizy poziomu bezpieczeństwa systemów SAP?

Nie jest naszą rolą wykonywanie prze­glądów bezpieczeństwa całej organiza­cji, czyli przełamywanie się z zewnątrz do środka. Funkcjonujemy jako zaufana firma, działająca w ramach środowiska klienta. Wychodzimy więc od poziomu zewnętrznego konsultanta dysponują­cego najmniejszymi uprawnieniami albo osoby, która jest w stanie wpiąć komputer do sieci wewnętrznej – i na tej podstawie badamy co można zrobić.

Wchodząc do sieci wewnętrznej, widać jak na dłoni wszystkie serwery SAP, wówczas szukamy dziur po kolei na różnych pozio­mach – od systemu operacyjnego, przez bazę danych, po serwer aplikacyjny. Jeśli z powodzeniem zamkniemy ten etap ana­lizy, to kolejnym krokiem naszych działań jest dokonanie przeglądu bezpieczeń­stwa w roli konsultanta z najmniejszy­mi uprawnieniami SAP – i tu zwykle jest ogromne pole do popisu. Działamy deli­katnie i pokazujemy wszystko, co moż­na zrobić. Jesteśmy w stanie udowodnić swoje obserwacje, ale w tym zakresie najczęściej korzystamy ze środowisk te­stowych. Unikamy bowiem działań, któ­re mogą zdestabilizować pracę systemu produkcyjnego.

Naprawdę jest to zwykle ciekawa przygo­da, której w niektórych firmach towarzy­szy wiele niespodziewanych odkryć. W grę wchodzą uprawnienia, które często są nieszczelne i udaje nam się zdobyć bardzo dużo. Stale zdarzają się domyślne hasła lub konta użytkowników. Często niezabezpieczone są też interfejsy integracyjne.

Poza odpowiednią konstrukcją aplikacji i wspomnianą weryfikacją treści podawa­nych za pośrednictwem różnego rodzaju interfejsów graficznych, kluczowe znacze­nie ma odpowiednia budowa ról i upraw­nień w systemie SAP. Trzeba przyznać, że ten obszar w polskich firmach nie wygląda dziś najgorzej, ponieważ architektura uprawnień jest zwykle naturalną częścią większości projektów wdrożeniowych i rozwojowych związanych z oprogramo­waniem SAP. Bywa jednak, że w samych uprawnieniach znajdują się luki pozwa­lające np. użytkownikom o najniższych uprawnieniach wykonywać komendy zewnętrzne lub debugować kod. Jeśli ta­kie luki istnieją w systemie testowym lub produkcyjnym, to wówczas włamywacz ma niemal otwartą drogę nawet do naj­bardziej newralgicznych obszarów środo­wiska SAP.

Kiedy jest najlepszy moment na pod­jęcie działań zmierzających do popra­wy bezpieczeństwa systemów SAP?

Właśnie teraz. Świat SAP stoi przed wy­zwaniem zmiany wersji systemu, kon­wersji do S/4HANA czy platformy RISE with SAP. W większości przypadków są to wdrożenia typu greenfield, zakładające implementację od nowa. Przy tej oka­zji, warto rozważyć dodatkowy wysiłek pozwalający zagwarantować, że nowe środowisko będzie odpowiednio zabez­pieczone i zaangażować firmę wyspecjali­zowaną w bezpieczeństwie SAP. Działając niezależnie od dostawcy systemu, będzie ona w stanie wypracować odpowiednie reakcje na różnego rodzaju zdarzenia.

Taki przegląd jest pierwszym krokiem. W kolejnym – pomagamy opracować strategię bezpieczeństwa w obszarze SAP. Co z tego, że podłączymy system SAP do platformy SIEM i pojawi się alert, że użytkownik Kowalski próbuje wydobyć tabele z listą płac. Jeśli nie mamy odpowiednich procedur reagowania, nie mamy SOC, któ­ry jest w stanie właściwie zareagować na tego typu zdarzenia, to nadal nie osiągnie­my oczekiwanego efektu.

Kwestii bezpieczeństwa środowisk SAP powinny przyjrzeć się też te organiza­cje, które nie przewidują zmiany modelu wykorzystania albo wersji używanego oprogramowania. Dzisiaj systemy SAP generują bardzo dużo informacji, także do systemów SIEM. Dane te są jednak najczęściej niezrozumiałe dla takich na­rzędzi i większości specjalistów ds. bez­pieczeństwa.

Dlatego zdecydowaliśmy się zaoferować na polskim rynku unikalny produkt, który jest w stanie bardzo szybko podnieść bez­pieczeństwo rozwiązań SAP, jak również koreluje i wykrywa próby włamań. Tłu­maczy także informacje płynące z syste­mu SAP na język zrozumiały dla działów bezpieczeństwa, a jednocześnie unifi­kuje strumienie logów, tak aby były one łatwiejsze do wykorzystania.

W 2021 roku firma SNOK została pol­skim przedstawicielem SecurityBrid­ge. Jaką rolę pełni to rozwiązanie?

SecurityBridge to produkt, który zabez­piecza SAP w wielu aspektach – i pełni rolę platformy SIEM działającej w śro­dowisku ABAP. W odróżnieniu od innych rozwiązań klasy SIEM, jest to rozwiąza­nie, które rozumie, co dzieje się w śro­dowisku SAP. Poza tym platforma Se­curityBridge nie wymaga dodatkowych, dedykowanych serwerów, bo może być zainstalowana na instancji SAP i jest w stanie ujednolicić strumień logów SAP, tak aby był on użyteczny dla kor­poracyjnych rozwiązań klasy SIEM, jak na przykład: QRadar, Splunk Enterprise Security czy Palo Alto.

Jest to o tyle ważne, że – jak powiedzie­liśmy wcześniej – natywne logi SAP nie­wiele mówią zespołom i uniwersalnym systemom bezpieczeństwa. Bezpośrednie podłączenie systemu SAP do rozwiązania klasy SIEM nie poprawi czytelności obra­zu bezpieczeństwa całego środowiska, ponieważ – jeżeli w audyt logów bezpie­czeństwa włączone są wszystkie para­metry SAP – to jest ich tak dużo, że nikt, kto pracuje jako operator SOC, nie będzie w stanie zrozumieć i skorelować wszyst­kich zawartych tam informacji.

Platforma SecurityBridge konsoliduje in­formacje z logów SAP i w sposób czytelny komunikuje do środowiska SIEM przy­padki naruszenia zdefiniowanych polityk bezpieczeństwa. Co ważne, SecurityBrid­ge jest w stanie ograniczyć skalę logów o 80–90%, a zarazem generować logi zrozumiałe dla działów bezpieczeństwa.

W praktyce oprogramowanie SecurityBridge, w zautomatyzowany sposób ko­reluje zdarzenia i może wykryć próby włamania do systemu SAP. Poza tym jest w stanie np. zablokować użytkownika naruszającego reguły bezpieczeństwa bezpośrednio w środowisku SAP. W połą­czeniu z zewnętrznym rozwiązaniem klasy SIEM może inicjować bardziej daleko idące reakcje na potencjalne zagrożenia.

Czy oprogramowanie SecurityBridge oferuje coś jeszcze?

Drugą rozbudowaną funkcjonalnością Se­curityBridge jest badanie poziomu bezpie­czeństwa danej konfiguracji środowiska SAP. Ma bowiem stały dostęp do bazy wszystkich not bezpieczeństwa SAP, więc jest w stanie zweryfikować aktualność po­szczególnych komponentów środowiska, a co więcej, może zainicjować wdrażanie krytycznych poprawek bezpieczeństwa w sposób niewpływający na dostępność systemu.

Równocześnie, SecurityBridge zapewnia skanowanie kodu ABAP pod kątem podat­ności. Jest zatem w stanie wykryć poten­cjalne luki bezpieczeństwa powstałe – lub umieszczone celowo – bezpośrednio w ko­dzie aplikacyjnym SAP. Poza tym, ABAP może okazać się dodatkowym wektorem ataków dokonywanym z poziomu prze­glądarki internetowej i poprzez różnego rodzaju interfejsy użytkownika.

Platforma SecurityBridge jest także w sta­nie wykrywać wycieki danych. Dobrze jest więc pomyśleć o niej jako o produk­cie, który jest instalowany w momencie rozpoczęcia wdrożenia lub reimplemen­tacji SAP, tak aby analizować całą ścież­kę transportową pod kątem luk w kodzie ABAP. Ponadto SecurityBridge może też skanować interfejsy pod kątem poten­cjalnych podatności. Jest to o tyle cenne, że obecnie środowisko SAP bardzo często pozostaje otwarte na inne rozwiązania czy źródła danych.

Jakiego rodzaju usługi świadczy ze­spół firmy SNOK na bazie platformy SecurityBridge?

W odpowiedzi na zdefiniowane uprzednio potrzeby zajmujemy się kompleksowym uruchomieniem i konfiguracją Security­Bridge. Prowadzimy również projekty pi­lotażowe, które zakładają m.in. dwutygo­dniowe testy rozwiązania SecurityBridge w środowisku testowym klienta. Dzięki temu pokazujemy rzeczywiste możliwo­ści tego rozwiązania u klienta.

Zapewniamy też bieżące wsparcie, szko­lenia i doradztwo w zakresie obsługi roz­wiązania SecurityBridge oraz możliwości wykorzystania gromadzonej przez nie wiedzy pod kątem poprawy bezpieczeń­stwa infrastruktury danej organizacji. Jeśli firma nie dysponuje zasobami do przejęcia takich zadań, to jesteśmy w stanie przejąć odpowiedzialność za obszar bezpieczeń­stwa SAP.