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…

 

“Ale” nr 1 – konfiguracja

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.

 

„Ale” nr 2 – autoryzacje

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:

 

10%

 

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.

 

„Ale” nr 3 – monitoring

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:

  • brak info o profilu SAP_ALL
  • brak info o zmianie usera techniczne w tryb serwisowy
  • na czerwono utworzenie użytkownika (tak, SAL na czerwono pokazuje utworzenie każdego użytkownika, więc w gąszczy codziennych zajęć łatwo przeoczyć).

Można oczywiście wspomóc się gotowymi narzędziami jak SAST Security Radar (więcej na https://lukardi.com/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.:

  • zmiana trybu na service i logowanie dialogowe usera technicznego,
  • dopisanie SAP_ALL.

 

PODSUMOWANIE

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.

Im bardziej kompleksowo zaadresowane są tematy bezpieczeństwa (czyli zarówno kwestie monitoringu, autoryzacji i techniczne są dostarczane) – tym mniejsze ryzyka dla Twoich danych.

 

autor: Tomasz Jurgielewicz/Sast Polska Team/

mail: tomasz.jurgielewicz@lukardi.com

————————————————————————————————-

WARTO PRZECZYTAĆ: