Od wielu lat spotykając się z C-Level, dyskutując o bezpieczeństwie SAP dostaję zwrotnie taki komunikat:
“wydaliśmy kilka milionów złotych na wdrożenie SAP i Pan chce powiedzieć, że to nie jest bezpieczny system?”
Jakby na to nie patrzeć – pytanie w punkt. W końcu potężny vendor, mnóstwo partnerów wdrożeniowych, ogromne kompetencje, rozwój narzędzia oraz permanentne wsparcie producenta.
Odpowiedź na pytanie jest prosta – SAP jest bezpieczny, ale…
To Klient odpowiada za odpowiednie sparametryzowanie systemu. Jest masa ustawień konfiguracyjnych, których niepoprawna definicja może doprowadzić do szeregu niebezpiecznych sytuacji.
Przykład:
hasła kont domyślnych powinny zostać zmienione, a profile wysoko uprzywilejowane (np. SAP_ALL) powinny zostać usunięte.
Istotne jest to, że w przypadku usunięcia konta domyślnego - odtworzy się ono automatycznie (z domyślnym hasłem). Konto SAP* powinno zatem mieć zmienione hasło, a parametr login/no_automatic_user_sapstar ustawione na wartość 1 (brak możliwości odtworzenia automatycznego konta SAP*).
To Klient odpowiada zatem za to, by te parametry dostosować do swoich potrzeb.
W kwestii technicznej dodatkowo SAP regularnie reaguje na znalezione podatności (vulnerabilities), publikując noty bezpieczeństwa, które skutecznie ładają dziury oraz ryzyka. Jednak to od Klienta zależy odpowiednie wgranie noty, a to nie zawsze jest proste i szybkie.
Przykład:
Komunikacja bez enkrypcji – często wręcz wymuszona przez skomplikowane środowiska łączące się do systemu. Wystarczy nasłuchiwać w sieci wewnętrznej by dostać treść komunikacji.
Zwróć uwagę, na powyższą architekturę. Nie można zapominać o wszystkich warstwach, również tych „pod” warstwą aplikacji. Zatem odpowiednie sparametryzowanie DB czy OS jest kluczowe, aby sprytny użytkownik nie miał możliwości obejścia swoich autoryzacji.
Obserwując projekty wdrożeniowe SAP można odnieść wrażenie, że kwestie bezpieczeństwa jeśli w ogóle zostały zaadresowane – to traktowane są po macoszemu. Nie widziałem wdrożenia SAP, w którym kompleksowo zajętoby się stworzeniem takiej koncepcji uprawnień, w których temat krytycznych autoryzacji i konfliktów uprawnień byłby wiodącym elementem.
W sumie można się nie dziwić, jeśli wdrożenie musi skończyć się w odpowiednim czasie i budżecie – najważniejszymi elementami takiego wdrożenia jest szybkie uruchomienie funkcjonalności biznesowych (i z tym w żaden sposób nie polemizuję).
W końcu SAP dostarcza predefiniowane role i profile, i bardzo łatwo można rozpocząć prace z nimi. Jest to droga na skróty, która może odbić się czkawką przy audytach, lub (co gorsze) w skutecznych nadużyciach ze strony użytkowników.
Jeśli mowa o nich - użytkownicy w dojrzałych systemach, gdzie historycznie „podróżowali” po organizacji, mają zbyt dużo uprawnień. Jest to konsekwencja tejże „podróży”, oraz konkretnej cechy SAP – uprawnień dodatnich. W SAP nie można po prostu odjąć uprawnień, wektor jest tylko dodatni. Dodatkowo odjęcie autoryzacji w roli rozpropaguje się na innych użytkowników momentalnie.
To wszystko powoduje, że gdy przysłowiowy Kowalski pracuje w organizacji wiele lat – role są częściej dopisywane niż zabierane. A tu dochodzimy do jakże nie miłej dla oka wartości:
To jest średnia wartość wykorzystanych autoryzacji w systemach, które mieliśmy okazję badać pod kątem bezpieczeństwa. Oznacza to ni mniej ni więcej, że 90% autoryzacji jest po prostu niepotrzebnych. A to prosta droga do krytycznych dostępów i konfliktów uprawnień, a więc pierwszego przylądka czerwonych lampek przy audytach.
Konflikty uprawnień – tu sprawa jest z definicji prosta.
„Utrzymuj zasadę 2 par oczu przy realizacji krytycznych procesów”.
Niemniej standardowo w SAP jest sto kilkadziesiąt tysięcy transakcji. Nie jesteśmy w stanie bez odpowiednich automatyzmów zweryfikować co oznaczają wszystkich transakcje. Mało tego osoba posiadająca wiedzę ze swojego zakresu modułów nie będzie wiedziała o innych, a kross-modułowe konflikty to zmora.
W powyższym przykładzie zwróć uwagę na kolumnę „Transakcje”.
Czy za pomocą tej nomenklatury jesteś w stanie odpowiedzieć na pytanie z jakim ryzykiem się wiąże taki zestaw transakcji?
A co jeśli powiem Ci, że tych zestawów konfliktów mogą być setki?
Wtedy zagadnienie się komplikuje.
Mniej niż ćwierć systemów klasy SIEM monitoruje aplikacje biznesowe w organizacjach globalnie (badanie HPE/2016). Nie sposób bez mozolnego definiowania ryzyk w prosty sposób stworzyć definicji ryzyk, by SOC mógł intepretować zdarzenia krytyczne.
Mnogość źródeł logów SAP jest również elementem wspierającym brak przejrzystości tego, co dzieje się w systemie.
Powyżej przykład tego, jakie grupy logów chodzą „dookoła” SAP.
Każdy z tych logów to swoiste wyzwania związane na przykład z niepoprawną klasyfikacją zdarzeń, nadpisywaniem, bądź brakiem czytelności. A to powoduje, że wyzwania z monitoringiem SAP nie są takie łatwe.
Przykład ataku
Spotkaliśmy się ze sprytnymi nadużyciami, dokonywanymi przez administratora, który realizował zamówienia towaru i ich rozliczenia (na fałszywe konta) używając wcześniej przygotowanego użytkownika. Proceder trwał około roku, i byłby niezauważony, gdyby nie zachłanność (ale o tym nie dziś).
Administrator wyszedł z założenia, że wystarczy utworzyć backdoor usera w taki sposób, by możliwie zatrzeć ślady. Proces jest prosty:
Zmieniam typ użytkownika technicznego na „service”. (Tu trzeba dodać, że użytkownik techniczny to taki, który często ma spore uprawnienia i nikt nie powinien mieć możliwości zalogowania się do niego w trybie dialogowym przez SAP GUI).
Po tej zmianie przez SU01 zakładamy użytkownika backdoor.
Tu jeszcze tylko dopiszemy sobie SAP_ALL, i nie ma granic dla naszych działań.
Na koniec sprzątanie i powrót usera technicznego do trybu System. Całość trwa nie więcej niż 5 minut. Spójrzmy na ślady w systemie. Zajrzyjmy do SAL:
A tam:
Można oczywiście wspomóc się gotowymi narzędziami jak SAST Security Radar (więcej na https://lukardi.com/pl/sap-data-security/security-intelligence/), który tego typu scenariusze ma zaszyte w bibliotekach, w teraz takie działanie nie przejdzie bez echa.
I tu cały zestaw alertów, np.:
SAP jest bezpieczny sam w sobie. Jednak to od działań Klienta zależy w jaki sposób zadbamy o kwestie bezpieczeństwa danych. W tym konkretnie kontekście nie sposób zignorować dobrodziejstw inwentarzy, jakimi są dedykowane narzędzia do SAP Security.
autor: Tomasz Jurgielewicz/Sast Polska Team/
mail: tomasz.jurgielewicz@lukardi.com
-------------------------------------------------------------------------------------------------
WARTO PRZECZYTAĆ RÓWNIEŻ NA TEMAT BEZPIECZEŃSTWA SAP:
[/et_pb_text][/et_pb_column][/et_pb_row][/et_pb_section]
