Bezpieczeństwo SAP: dlaczego SIEM nie wykrywa wszystkiego i jak mimo tego skupić się na incydentach SAP

Standardowy monitoring SIEM często nie wystarcza aby utrzymać pełne bezpieczeństwo SAP, ponieważ pewne specyficzne logi SAP oraz ich analiza nie są interpretowane i w konsekwencji, wzorce ataków nie zostają zidentyfikowane ani rozpoznane. Dlaczego należy mieć tę kwestię na uwadze, co mogą zrobić przedsiębiorstwa, aby zintegrować SAP z monitoringiem i dlaczego to kompleksowe zabezpieczenie może przynieść dodatkową wartość – na te pytania odpowiada Ralf Kempf (CTO Akquinet ES - producent SAST Suite) dla magazynu IT Management.

SIEM (Security Information and Event Management) ma na celu zapewnienie ochrony bezpieczeństwa środowisk IT dla przedsiębiorstw i organizacji. Połączenie Security Information Management (SIM) oraz Security Event Management (SEM) generuje analizę alertów bezpieczeństwa w czasie rzeczywistym. Zebranie, korelacja i analiza danych logów, komunikatów systemowych oraz alertów pozwala na identyfikację ataków, niecodziennych wzorców i niebezpiecznych trendów. Innymi słowy, SIEM dostarcza podgląd ważnych dla bezpieczeństwa zdarzeń w środowiskach IT wspierając proces spełniania wymagań prawnych oraz wewnętrznych polityk i zasad zgodności dla bezpieczeństwa IT. Zadania kluczowe: dostarczanie raportów dotyczących incydentów bezpieczeństwa jak na przykład pomyślne i błędne próby logowania czy złośliwe oprogramowanie oraz inne potencjalnie niebezpieczne działania. Następnie odbywa się przesłanie powiadomień w momencie gdy analiza wykaże czynność, która narusza zdefiniowany zbiór zasad i w konsekwencji stanowi potencjalny problem bezpieczeństwa.

Jak działa SIEM

Podczas gdy dane są konsolidowane w jednym miejscu, krytyczne aktywności mogą zostać wcześnie zidentyfikowane za pomocą wzorców analitycznych i trendów. Dane zebrane i zinterpretowane w czasie rzeczywistym oraz otrzymana informacja są zapisywane w formie niemodyfikowalnej. Powszechne źródła dla SIEM zawierają serwery, zapory, rutery, IPS (Intrusion Prevention System) oraz IDS (Intrusion Detection System). Ich dane są przekazywane do punktu centralnego gdzie zostają zapisane, znormalizowane, ustrukturyzowane oraz przeanalizowane. Analiza wykorzystuje zdefiniowane reguły, modele korelacyjne, machine learning oraz sztuczną inteligencję, celem wygenerowania zależności pomiędzy wpisami i identyfikacji anomaliów. W przeciwieństwie do innych środków bezpieczeństwa, w tym przypadku nie zapobiega się atakom z wyprzedzeniem, ale ich wpływ i rozprzestrzenienie się mogą zostać zredukowane na przykład poprzez alerty. Dodatkowo, takie alerty i zautomatyzowane raporty pozwalają na odpowiedzi na różnorodne ataki w czasie rzeczywistym jak i na późniejsze udokumentowanie incydentów bezpieczeństwa. Niestety, zasada ta jest mało skuteczna w systemach SAP.

ŚWIATY RÓWNOLEGŁE: SAP I SIEM

Sporo jest powodów, dla których między SIEM i SAP wynika sporo nieporozumień od samego początku: SIEM wywodzi się z klasycznej technologii sieciowej, na przykład z epoki DOS (Denial of Service) i Eternetu z wielkimi, samodzielnymi aplikacjami komputerowymi dla kont finansowych oraz zarządczych, controllingu i dla wielu innych, wszystkich niezależnych od siebie. W miarę gdy świat IT stawał się bardziej połączony, SIEM został wprowadzony, aby monitorować zdarzenia w warstwie sieciowej – zapytania o źródło informacji, kto ma do niego dostęp, co zostało uznane za poznane i co nie pasuje do założonych wzorców. W tym podejściu zbiór zasad jest kluczowy: są potrzebne do sprawdzania wystąpień w sieci i wyciągania wniosków dla bezpieczeństwa. Innymi słowy, narzędzia SIEM biorą pod uwagę infrastrukturę IT, a nie indywidualne aplikacje. Jednak w ubiegłych latach okazało się, iż aplikacje również powinny zostać wzięte pod uwagę, czy to Microsoft Dynamics czy narzędzia do planowania produkcji lub SPS (Strategic Project Solution) w produkcji. W przypadku SAP tutaj powstaje pewne „ale”: przecież SAP różni się znacznie od innych aplikacji również pod względem sieciowym. W SAP można wykonać wiele operacji, zarówno z rolami czy autoryzacjami i mając na uwadze aspekty bezpieczeństwa. Podczas gdy wiele mechanizmów jest podobnych do tych w IT, SAP posiada różnice w nomenklaturze i zbiorze zasad. W obszarze sprzętu sieciowego i pozostałych obszarów IT, SAP jest wirtualnie swoim własnym odrębnym światem z własnym językiem i dykcją. To właśnie dlatego wiele firm nadal oddziela grubą kreską SAPa od reszty obszaru IT.

SAP JEST IGNOROWANY PRZEZ SIEM – ALE NIE MUSI TAK BYĆ

Konwencjonalne narzędzia SIEM koncentrują się na identyfikacji niecodziennych zachowań wewnątrz infrastruktury. Jednak systemy SAP zostają często zignorowane. Jeśli nie został zapewniony dostęp do systemu SAP, SIEM jest w stanie zidentyfikować co najwyżej szum informacyjny z miliona linii logów. Nikt nie umie (i nie chce) tego interpretować). Innymi słowy, systemy SAP to martwy punkt dla większości narzędzi SIEM ponieważ nie zawierają one specyficznych dla SAPa wzorców sprawdzających. Oznacza to iż nie rozpoznają towarzyszących wzorów ataków i dlatego zespoły bezpieczeństwa nie wykrywają pewnych zagrożeń. Zdarzenia w systemach SAP mogą być niezauważalne na poziomie sieciowym.

Jedynym sposobem aby je zidentyfikować jest analiza samej aplikacji. Wynikiem tych problemów ze zrozumieniem częstokroć ignoruje się warstwę SAP, lub zajmuje się nią w ostatniej kolejności ponieważ prostsze jest zajmowanie się kwestiami, które się rozumie. Dlatego SAP jest często zaniedbywany w tej sferze: nawet firmy, które utrzymują bezpieczeństwo IT na wysokim poziomie i używają SIEM mają tendencję do ignorowania SAP, zarówno nieświadomie jak i intencjonalnie. Być może mają nadzieję, iż pracownicy SAP sami zajmą się weryfikacją lub że niekompletny SIEM będzie wystarczający lub może nie wiedzą o istnieniu możliwości zaradczych dla takich braków. CISO w przedsiębiorstwach, które korzystają z SIEM powinni zadać sobie pytanie: czy jestem pewien/pewna, iż poświęcam odpowiednią uwagę systemom SAP? Jeśli nie, powinni połączyć te dwa światy ponieważ jest to najrozsądniejsza rzecz jaką można w takiej sytuacji zrobić.

NAJLEPSZE Z DWÓCH ŚWIATÓW

Odkąd specjaliści sieciowi stworzyli wydajne narzędzia dostarczające przegląd sieci - mają tendencję do zapominania, że istnieją (oprócz ich własnego) inne światy. Osiągnięcie pełnej ochrony oznacza łączenie obu światów dla korzyści całego przedsiębiorstwa. To właśnie w takim momencie, oprogramowanie jak SAST SUITE wchodzi do gry. Oprogramowanie wyciąga zdarzenia z warstwy aplikacyjnej i transportów oraz tłumaczy je tak, aby środowiska SIEM mogły je zrozumieć. Wykrywanie ataków bazując na plikach logów i analizie ruchu sieciowego wymaga głębokiej wiedzy z zakresu potencjalnych ścieżek i wzorców, po których mogą nastąpić ataki. Inteligentne zarządzanie informacją jest niezbędne aby oszacować bezpieczeństwo danych tego rodzaju. Zdarzenia ważne dla bezpieczeństwa muszą zostać wyfiltrowane w oceanie danych i umiejscowione w odpowiednim kontekście.

Aby zidentyfikować ryzyka, SAST Security Radar nie tylko analizuje logi SAP, ale również integruje analizę konfiguracji i ról. SAST SUITE posiada funkcjonalności praktycznie out-of-the-box, która umożliwia przekazywanie informacji z SAP do istniejących SIEM, w których to informacje mogą być poddane dalszej analizie. Działa to zarówno w środowsiakch małych systemów SAP jak i niektórych większych globalnych środowisk klienckich, nawet z ponad 1000 systemów. Dodatkową korzyścią jest Security Dashboard: poprzez integrację z daleko sięgającym narzędziem SIEM, można skonsolidować wszystkie powiązane z bezpieczeństwem incydenty wykryte w systemach SAP S/4Hana z innymi obszarami IT. Dzięki temu SAP jest brany pod uwagę w SIEM a firmy mogą generować optymalne raporty bazujące na dashboardzie wyświetlające kompletny status bezpieczeństwa za pomocą jednego kliknięcia.

Ralf Kempf (CTO SAST SOLUTIONS)

Artykuł został oryginalnie opublikowany w magazynie it management magazine, Lipiec/Sierpień 2021 i jest dostępny na it-daily.nethttps://www.it-daily.net/leser-service

Niższe koszty w SAP: jak usunąć nieaktywnych użytkowników - optymalizacja licencji SAP

Poniższy wpis zawiera konspekt prac zrealizowanych dla jednego z Klientów SAST, którego głównym trzonem była optymalizacja autoryzacji i dostępu użytkowników realizowany był również remodeling koncepcji autoryzacji. Jednym z elementów wdrożenia była ocena zasadności czy wszystkie dostępy są rzeczywiście potrzebne, projekt zakładał również optymalizację licencji SAP. Takie przedsiewzięcia jak projekt reorganizacji autoryzacji i wdrożenia nowej koncepcji opłacają się gdyż skutkują klasyfikacją użytkowników i redukcją dostępów, co pociąga za sobą zredukowanie kosztów licencji SAP.

Co roku SAP przeprowadza audyt systemów Klientów i na tej podstawie często wymaga dodatkowej opłaty licencyjnej za nadmiarowych użytkowników. Wiadomo, że wszyscy aktywni użytkownicy dialogowi SAP mają wpływ na wysokość opłat licencyjnych. W tym kontekście “aktywni” oznacza ograniczenie czasowe ważności konta użytkownika, a nie blokadę administratora.

Zatem zmniejszenie liczby aktywnych master rekordów użytkowników ma bezpośredni i zauważalny wpływ na oszczędność kosztów. Wiele firm w ramach wątpliwości postanawia zostawić część aktywnych użytkowników z obawy przed tym, że codzienna praca może zostać zakłócona. Obawa jest rownież taka, że konkretny użytkownik może być nadal wykorzystywany jako user techniczny do obsługi np. jobów w tle. Pojawia się zatem oczywiste pytanie:

W jaki sposób można uzyskać wgląd w aktywność użytkowników w systemach SAP i w jaki sposób można efektywnie analizować różne rodzaje dostępy użytkowników?

Czy użytkownik jest aktywny? Brak konkretów

Obserwujemy widoczną tendencję pozostawiania aktywnych użytkowników w obawie przed tym, że ich usunięcie może mieć wpływ na przerwanie procesu biznesowego. Wynika to przede wszystkim z braku konkretnej wiedzy na temat korzystania (zarówno pośredniego jak i bezpośredniego) z master rekordów użytkowników.

Jeśli spojrzymy na znacznik czasu logowania użytkownika - nie będzie to precyzyjna informacja, biorąc dodatkowo pod uwagę skomplikowane środowiska (wielosystemowe), czy np. narzędzia webowe. Poziom skomplikowania takiej analizy wzrasta jeśli bierzemy pod uwagę połączenia RFC lub SOAP i ODATA - tu często brakuje i wiedzy i rozwiązań potrzebnych do tego, by skutecznie ocenić dostępy.

Analiza - możliwości i trudności

Jedną z opcji analizy wykorzystania transakcji jest ST03N (STAD - analiza transakcji biznesowych). Transakcja ta pozwala na analizę wykorzystania różnych typów komunikacji:

Rysunek 1 - Elementy menu system load monitor - click w Business Transaction Analysis
Rysunek 2 - Analiza transakcji biznesowych (STAD) - konfiguracja raportu
Rysunek 3 - Wybór opcji typów komunikacji
Rysunek 4 - rezultat listy analizy transakcji biznesowych

Analiza wskazuje którzy użytkownicy generują obciążenie systemu za pomocą konkretnego typu komunikacji. Z tych danych wynika oczywiście którzy użytkownicy są aktywni, ale jest pewne ograniczenie - dane dotyczą tylko określonego dnia. Do głębszej analizy potrzebujemy większego zakresu czasu, zwłaszcza, gdy potrzebujemy wyciągać daleko idące wnioski. ST03N pozwala na analizę transakcji i wywołania programów. Wystarczy tylko dwuklik, aby wyświetlić użytkowników, którzy korzystali z określonej transakcji lub programu ABAP.

Rysunek 5 - profil transakcji z widokiem użytkownika

Niewątpliwym wyzwaniem jest połączenie obu źródeł danych. Bez tego nie uzyskamy pełnego obrazu sytuacji. Standardowe narzędzia SAP dostarczą nam tylko źródła danych. Niestety nie mamy możliwości elastycznej analizy (na przykład dla indywidualnych użytkowników). Zatem dla uzyskania odpowiedniej informacji wymagana jest ręczna analiza i agregowanie danych.

Best Pratice - analiza wykorzystania transakcji za pomocą SAST

Przykład jednego z Klientów - mieszanka dostępów, przy braku konkretnej wiedzy odnośnie tego w jaki sposób użytkownicy wykorzystują transakcje. Podczas analizy przyglądaliśmy się ogólnym informacjom o dostępach - dotyczyło to wszystkich poziomów użytkowania (dialog, batch, RFC, http, itd…).

Dla optymalizacji czasu analizy wykorzystaliśmy funkcję SAST Suite pozwalającą na szczegółową analizę wykorzystania transakcji. Analiza ta została przeprowadzona dla wszystkich aktywnych użytkowników w oparciu o CCMS. Kompleksowo zostały przeanalizowane wszystkie poziomy komunikacji z systemem w dłuższym okresie niż jeden dzień. Dostarczamy tym sposobem również informacje o częstotliwości dostępów (klasyfikacja od A do D na rysunku 7 oznacza częstotliwość, których wartość jest opisana na rysunku 6).

Rysunek 6 - Wykorzystanie transakcji za pomocą SAST
Rysunek 7 - Rezultat analizy wykorzystania transakcji i ich częstotliwość (SAST)

25% nieaktywnych użytkowników - wymiernie niższe koszty

W tym przypadku analiza zawierała takie elementy jak:

W efekcie powyższego otrzymaliśmy informację o tym jacy użytkownicy nie pozostawili żadnego śladu aktywności w tym okresie - ci użytkownicy stali się zatem kandydatami do usunięcia. Jest to zatem bezpośredni przykład jak można zająć się optymalizacją licencji SAP.

Rezultat:

Procedura optymalizacji:

Faza 1 - Przygotowanie

- Przygotowanie projektu
- Instalacja SAST

Faza 2 - Analiza

- Ocena aktywności user master rekordów
- Połączenie danych
- Dokumentacja aktywności
- Koordynacja z administratorem

Faza 3 - Wykonanie

- Poinformowanie biznesu (odpowiednich departamentów)
- Usunięcie nieaktywnych UMR

Sporo informacji o naszym podejściu do zarządzania autoryzacjami SAP znajdziesz tutaj.

Oryginalny wpis pierwotnie ukazał się tutaj.

CZYTAJ POWIĄZANE ARTYKUŁY:


Bezpieczeństwo SAP - od czego zacząć?

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:

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.:

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Ć RÓWNIEŻ NA TEMAT BEZPIECZEŃSTWA SAP:

[/et_pb_text][/et_pb_column][/et_pb_row][/et_pb_section]

Co powinna zawierać koncepcja uprawnień SAP?

Co powinna zawierać koncepcja uprawnień SAP?

Z mojej obserwacji wynika iż Koncepcja Uprawnień, obok projektu reorganizacji uprawnień jawi się niczym zgroza audytowanych kierowników oraz administratorów uprawnień.
Jednak tylko w przypadku, gdy takiej dokumentacji nie prowadzono w organizacji lub nie była ona aktualizowana wiele lat, a często od czasów wdrożenia SAP w danym przedsiębiorstwie.
Można by się zapytać, gdzie podziała się nasza kultura piśmiennicza? 😉

Warsztaty z Koncepcji Uprawnień często zaczynam (niczym na wykładzie akademickim) rozgrzewką w postaci pytań skierowanych do klientów:

Co to jest Koncepcja Uprawnień waszym zdaniem?

Jakie treści i elementy może, a które powinna zawierać?

Zdecydowanie najtrudniej jest organizacjom, które odkładają wszelkie działania dokumentacyjne na ostatni moment (lub nigdy).

„Skupiamy się na ciągłości biznesu, nie na pisaniu procedur.”

„Mamy zbyt mało zasobów żeby zajmować się tworzeniem, przeglądem i aktualizacją dokumentacji, musimy dostarczać wyniki.”

„Jako administrator uprawnień codziennie przerabiam kilkadziesiąt ticketów, czy naprawdę myślisz, że mam czas na dokumentację?”

To wszystko brzmi znajomo, prawda?
Co więcej, trudno się nie zgodzić z zasadnością przytoczonych pytań.

A teraz wyobraźcie sobie następujące sytuacje i odpowiedzi:

SYTUACJA 1

"Przyszło kilka nowych osób do obsługi procesów do departamentu Kasi i nie za bardzo wiedzą jak złożyć wniosek o nowe uprawnienia, najgorsze, że codziennie dostaję te same pytania od pojedynczych osób. Ja nie mam czasu im tłumaczyć tego jak to u nas wygląda…

ROZWIĄZANIE

- Nadam im dostęp do części Koncepcji Uprawnień przeznaczonej dla Biznesu, niech przeczytają ze zrozumieniem, jest tam informacja o składaniu wniosków, formułce i niezbędnych informacjach potrzebnych do poprawnego przetworzenia zgłoszenia.

- Super, dzięki, zaoszczędziłaś mi czasu na codziennie mini szkolenia.

SYTUACJA 2

- Marek, szybko! Wpadli do mnie znienacka audytorzy i pytają się o Koncepcję Uprawnień SAP, co to jest? Mamy to? Kurczę, co roku pytają i Marta zawsze coś miała pod ręką, ale teraz jest na swoim sabbatical year, najpewniej w buszu w Nowej Zelandii, nie odpisuje na WA i nikt nie wie co się stało z tymi plikami.

ROZWIĄZANIE

- Jest na zasobie, zaraz podeślę link i nadam Ci stałe uprawnienia do wglądu.

-Uffff, co za ulga. Dzięki za ratunek!”

SYTUACJA 3

- Hey, nasz nowy kierownik developerów na dzisiejszym spotkaniu zespołu wyraził niezadowolenie z powodu częstych sytuacji z brakiem uprawnień u jego pracowników. Od jutra nakazał żeby wszyscy mieli SAP_ALL, żeby uniknąć czekania na analizę i rozwiązanie ticketów.

ROZWIĄZANIE

- Nie nadajemy developerom ani konsultantom modułowym SAP_ALL, jest o tym osobny rozdział w przyjętej przez naszą firmę Koncepcji Uprawnień. Mamy procedurę na rozszerzone uprawnienia Firefightera, zaproponuj proszę twojemu kierownikowi 15 minutowy slot na spotkanie, przedstawię mu możliwości. Jestem pewna, że będzie zadowolony z takiego rozwiązania.

- Pewnie, brzmi dobrze. Robi się!

Czy i te przytoczone scenki brzmią dla Was znajomo?
Jeśli tak, to znaczy, że jesteście na dobrej drodze ku stworzeniu czy ulepszeniu Waszej Koncepcji Uprawnień, bo zidentyfikowaliście potrzeby biznesowe takiej dokumentacji.

Co powinna zawierać Koncepcja Uprawnień?

Każdy klient i każde przedsiębiorstwo jest inne, ale wyróżniamy cztery główne rdzenie Koncepcji Uprawnień:

  1. Podstawowy podział ról w organizacji (pojedyncze, zbiorcze, pochodne, referencyjne, szablonowe)
  2. Proces zarządzania użytkownikami (wnioski, akceptacja, wykonanie, dokumentacja z działań)
  3. Proces zarządzania rolami (wnioski, akceptacja, wykonanie, dokumentacja z działań)
  4. Polityka SoD (obowiązująca matryca uprawnień, konflikty krytyczne, odpowiedzialni za cykliczną kontrolę)

Powyższe przykłady to tylko część istotnych informacji, które powinny znaleźć się w Koncepcji Uprawnień.

Zespół konsultantów SAST Polska posiada doświadczenie zarówno w pracach supportowych jak i projektowych. Pomagamy naszym klientom projektować i tworzyć Koncepcje Uprawnień.
Oferujemy szablony dopasowane do potrzeb klienta, które omawiamy na dedykowanych warsztatach.
Jeśli zależy Ci na stworzeniu kompletnej dokumentacji Koncepcji Uprawnień SAP, chętnie Was w tym wesprzemy. Nie jest to takie straszne jak by się mogło wydawać. Zapraszamy do kontaktu.

Tomasz Jurgielewicz: tomasz.jurgielewicz@lukardi.com
Bernadeta Szwarc: bernadeta.szwarc@lukardi.com

autor: Bernadeta Szwarc /Sast Polska Team/

-------------------------------------------------------------------------------------------------

WARTO PRZECZYTAĆ:

SECPOL - jak używać go w bezpieczny sposób

Być może już wiesz, że od wersji SAP 7.40 SP8 możesz używać zasad bezpieczeństwa (SECPOL) SAP do definiowania parametrów bezpieczeństwa specyficznych dla użytkownika, w przeciwieństwie do wartości profilu systemowego.

Ale czy wiesz również, że w wyniku tego możesz nieumyślnie osłabić bezpieczne wartości, takie jak ograniczenia logowania i złożoność hasła?

Nasza praktyczna wskazówka pokaże Ci, jak skutecznie zapobiegać takiemu osłabieniu.

Możesz ustawić parametry swoich zasad bezpieczeństwa w inny sposób, zgodnie z:
1. złożoność hasła
2. interwał zmiany hasła
3. ograniczenia logowania

Transakcji „SECPOL” używasz do utrzymywania zasad bezpieczeństwa i masz możliwość zdefiniowania dowolnej liczby zasad.

Zależność między „znacznikiem zasad bezpieczeństwa” a wartościami profilu systemu w skrócie:

W transakcji SU01 jest następnie używana do przypisania dla użytkowników.

Ale bądź ostrożny, ponieważ jest duży haczyk!
Zasady bezpieczeństwa nie zastępują wartości poszczególnych profili, ale zastępują WSZYSTKIE wartości. Oznacza to, że wartości, które nie zostały zdefiniowane w Polityce bezpieczeństwa, nie są ustawione na wartości bezpieczne zgodnie z parametrami RZ10, ale na niezabezpieczone wartości w kontekście użytkownika. W ten sposób można przypadkowo osłabić bezpieczne wartości, takie jak ograniczenia logowania i złożoność hasła.

Poniższy przykład pokazuje takie zachowania:

Nasze doświadczenie w projektach pokazało, że wielu klientów nie podziewa się takiego zachowania systemu. Ogólne oczekiwanie jest takie, że parametry można ustawić wbrew ustawieniom domyślnym. Tak jednak nie jest.

Nasza wskazówka dla Ciebie:

W celu zabezpieczenia Waszych systemów SAP, SAST SUIT zapewnia obszerne testy w kontekście zasad bezpieczeństwa. SAST wskazuje istotne błędy konfiguracyjne i niewłaściwe wartości wprowadzone w systemie SAP.

autor: Marek Czubaszek /Sast Polska Team/

------------------------------------------------------------------------------------------------

WARTO PRZECZYTAĆ NA TEMAT BEZPIECZEŃSTWA SAP:

Jak zdefiniować koncepcje autoryzacji?

Jak zdefiniować koncepcje autoryzacji?

SAP HANA to koncepcja szybkiego dostępu do danych in-memory. Pozwala ona na analizę dużej, często niezagregowanej, ilości danych, w sposób o wiele szybszy niż w pozostałych bazach danych. Obsługa danych w SAP HANA różni się znacznie od tej, którą znamy z SAP NetWeaver. Posiada swój własny system do zarządzania użytkownikami i autoryzacjami.

Architektura bezpieczeństwa SAP HANA

Koncepcja autoryzacji zaimplementowana w bazach SAP HANA bazuje na autoryzacjach.
Szyfrowanie SSL powinno być skonfigurowane na każdym z trzech typów połączeń:

  1. połączenie klienta i bazy SAP HANA
  2. wewnętrzne połączenia pomiędzy komponentami SAP HANA
  3. połączenie do data center (na przykład backup z użyciem SAP HANA System Replication)

SAP HANA pozwala również na logowanie krytycznych zdarzeń, takich jak zmiany na użytkownikach, rolach, uprawnieniach oraz zmiany konfiguracji i nieprawidłowe logowania. Dodatkowo logowane są odczyt i zapis danych (na przykład via tabele) oraz uruchomienia. Dostępny jest również pewien rodzaj logowania awaryjnego.

SAP HANA - Zarządzanie autoryzacjami i użytkownikami

Baza danych SAP HANA rozróżnia 3 typy użytkowników:

Operacje na SAP HANA dla tych użytkowników wymagają odpowiednich uprawnień. Można przypisywać uprawnienia bezpośrednio do użytkowników lub grupować je ze sobą w role.


SAP HANA - Uprawnienia

Podstawowa zasada - dostęp dozwolony jest tylko wtedy, gdy odpowiednie uprawnienia zostały użytkownikowi udzielone. Tak zwana pozytywna autoryzacja.

Żadne autoryzacje w SAP HANA nie są za to negatywne, czyli nie istnieje sposób, dla których użytkownikowi BLOKUJEMY jakiekolwiek dostępy. Dokładnie tak jak w SAP NetWeaver - autoryzacje są jedynie addytywne.

Są trzy typy uprawnień:


Role SAP HANA

W SAP HANA role są zbiorem uprawnień (lub w niektórych przypadkach zbiorem ról). Role mogą być dziedziczone (zagnieżdżone). Pozwala to dokładnie odwzorować role biznesowe w koncepcją autoryzacji.

Aby zarządzać rolami, powinieneś zawsze pracować w Repozytorium HANA i tworzyć role jako obiekty design-time (role Repozytorium), które później przetransportujesz. Po przetransportowaniu, rola jest aktywowana automatycznie. Tylko te role runtime’owe (role katalogowe) mogą być przypisane.


Koncepcja autoryzacji - Ramy i podstawy

Udzielenie dostępów do obiektów SAP HANA odbywa się standardowo poprzez przypisanie autoryzacji. Ramowa koncepcja określa zasady przypisania uprawnień i ról. Koncepcja taka to gwarant bezpieczeństwa (pod warunkiem, że będą istnieć odpowiednie mechanizmy weryfikujące jej przestrzeganie).

Ramowa koncepcja pomaga poprawić poziom bezpieczeństwa IT przez wdrożenie odpowiednich polityk dostępów. Dlatego ramowa koncepcja autoryzacji powinna odpowiadać na następujące pytania:

Koncepcja ramowa musi posiadać następujące informacje:

  1. opis podziału funkcji pomiędzy administracją IT, a działami biznesowymi
  2. opis typów użytkowników (standard i restricted)
  3. obsługę użytkowników SYSTEM
  4. użycie takich użytkowników jak:

5. opis ról dla konkretnych grup użytkowników

6. opis ról z rekomendacjami i wymaganiami:

7. użycie repozytorium i ról HDI

8. korzystanie z autoryzacji:

9. ustawienia dla weryfikacji bazy SAP HANA:

10. opis metod dostępów

Dodatkowo (opcjonalnie) można opisać użycie użytkowników awaryjnych oraz dostęp LDAP (jeśli jest). Również należy uwzględnić ewentualne wymogi prawne (takie jak RODO).

Jeśli chcesz dowiedzieć się czegoś więcej o SAP HANA i zarządzaniu autoryzacjami - zapraszamy.


autor:
Tomasz Jurgielewicz /Sast Polska Team/
kontakt: tomasz.jurgielewicz@lukardi.com

————————————————————————————————

WARTO PRZECZYTAĆ:

Czy wiesz jakie uprawnienia mają Twoi pracownicy?

Biznes nie lubi chaosu i nie znosi niepewności

Role, uprawnienia i autoryzacje w SAP to temat rzeka, który poruszaliśmy już kilkukrotnie.
Pisaliśmy o zagrożeniach, które wynikają z braku koncepcji uprawnień, źle prowadzonych procach ich nadawania oraz ryzykach z tym związanych dla organizacji. Dzisiaj, w tej nowej dla wielu przedsiębiorstw rzeczywistości temat jest tym bardziej "gorący".

Raport PWC "Global Economic Crime Survey 2020" jednoznacznie wskazuje, że wśród Polskich firm spory wzrost odnotowują nadużycia księgowe. Okazuje się, że około 63% nadużyć było dokonywanych przez pracowników (insider).

Skala nadużyć jest także coraz większa - ponad 61% firm, w których wykryto nadużycie poniosło z tego tytułu straty większe niż 400k PLN (ponad połowa z nich osiągnęła straty powyżej 4 mln PLN).
Warto jeszcze zaznaczyć, że w większości wykrycia nadużyć zostały dokonane przez działania rutynowe (takie jak audyty czy przeglądy dokumentów). Zaledwie 23% wykryć pochodziło przez automatyzację działań podejrzanych i systemy ochrony IT.

Skoro większość z dokonanych nadużyć było realizowane przez pracowników - warto przyjrzeć się możliwym przyczynom. Podczas realizacji projektów - w kontekście autoryzacji SAP obserwujemy trzy znaczące trendy w tym zakresie: zaniedbanie autoryzacji na początkowym etapie wdrożenia systemu, proces akceptowania oraz konflikty uprawnień.

Zaniedbanie autoryzacji na początkowym etapie wdrożenia systemu

Projekty wdrożeniowe mają to do siebie, że istnieje dość duży nacisk na budżet i prędkość realizacji projektu. Ma to oczywiście swoje uzasadnienie, gdyż biznes musi generować przychód, a czas ma kolosalne znaczenie. Niemniej w późniejszym etapie życia systemu i użytkowników w nim - istotne jest zabezpieczenie zarządzania autoryzacjami konkretnymi wytycznymi.

Stąd też pojęcie koncepcji uprawnień, czyli zestawu szczegółowych informacji o podstawowych zasadach tego wyzwania. Począwszy od nazewnictwa i zawartości ról, przez zmapowanie ról ze stanowiskami, na określeniu ram i ryzyk związanych z dostępami kończąc. I wydaje się, że taka spójność dostępów powinna być w każdej organizacji priorytetem - powyższe opracowanie PWC pokazuje, że sporo jest jeszcze do zrobienia.

Skoro system działa parę (często paręnaście) lat - jest spore prawdopodobieństwo, że nieuprawnione
(z definicji) osoby mają potencjalną możliwość realizacji nadużyć przez zbyt duże dostępy.

Użytkownikowi łatwiej jest dodać rolę niż jakąś zabrać - a to wychodzi z naszych obserwacji, gdzie około 10-15% autoryzacji nadanych użytkownikom jest używana w codziennym życiu (reszta jest po prostu zbędna).

Proces akceptowania - brak wiedzy

Znasz taki scenariusz?

- "Poproszę o rolę taką jak ma Pan Staszek"

- "Ok, akceptuję"

Co w tej sytuacji robi BASIS (lub dział autoryzacji)?
Jeśli proces akceptacji się w tym momencie kończy - realizowana jest prośba.

Czy osoba akceptująca posiada wiedzę odnośnie wszystkich transakcji i ról, związanych z nimi ryzyk i potencjalnych zagrożeń?
Śmiem twierdzić, że jest to mało prawdopodobne.

Wnioski na mailu, w formie papierowej lub w systemie ticketowym, których weryfikacja jest oderwana od kontekstu systemu (brak możliwości sprzężenia zwrotnego z ryzykami w SAP) powodują, że organizacja
w tym zakresie nie działa proaktywnie. Dzięki temu do systemu regularnie przedostają się niebezpieczne zestawy autoryzacji.

Konflikty Uprawnień - czyli wypływ pieniędzy z organizacji

Pracownik w ciągu wielu lat pracy w organizacji przechodzi przez różne jej szczeble. Dostaje nowe dostępy, zmienia funkcje, dostaje następne role. Jest to również pochodna dwóch pierwszych punktów (typowych zaniedbań).

Konsekwencje są tu bardzo widoczne, bo jego dostępy pozwalają na wykonanie całych procesów biznesowych. Często wielu...

Dobrze, gdy organizacja zna ryzyka i potrafi sobie z nimi poradzić wdrażając odpowiednie procesy GRC
w SAP. Jednak są to wyjątkowe sytuacje, a w większości przypadków aktywności sprowadzają się do wykonania ogólnych raportów z pojedynczych konfliktów.

Nadużyć związanych z Konfliktami Uprawnień (SOD) można mnożyć. Dotyczą one praktycznie każdego obszaru biznesu realizowanego przez SAP.

Prosty scenariusz dla FI:

Autoryzacja nr 1 - FK01 / XK01 - Zarządzanie danymi podstawowymi dostawców

Autoryzacja nr 2 - FB60 / FB65 / FB01 / F-53 - Fakturowanie towarów przychodzących

Konflikt uprawnień - Ryzyko wysłania faktury dla fikcyjnego dostawcy. Wypłynięcie pieniędzy z tytułu rozliczenia faktury.

Obszar SD

VA01/VA02/WCS0

+

Np.: V32/V32/V33/V35

Możliwość wprowadzenia dokumentów sprzedaży i obniżenia cen celem osiągnięcia korzyści finansowych dla użytkownika, który może edytować fikcyjnych dostawców i inicjować zakupy na danego dostawcę.

Obszar HR/PY

Np.:F-18/F-46/F-58_K

+

Np.: FEBA/FF.5/FF/4/FF/5

Wprowadzenie nieautoryzowanych płatności i realizacja salda rachunku bankowego. Ryzyko wprowadzenia nieautoryzowanej płatności i potwierdzenia salda bankowego przez tą samą osobę.

Podsumowanie

W tak potężnym narzędziu, przetwarzającym najważniejsze dane w organizacjach - kwestie optymalnego zarządzania dostępem to nic innego jak wymóg, by organizacja mogła panować nad ryzykiem i potencjalnymi nadużyciami.

I to nie jest tylko potrzeba, na którą zwracamy uwagę, jako producent narzędzi do zarządzania procesami GRC w SAP. To również opracowania Wielkiej Czwórki, oraz ich Klienci, którzy spotykają się z wymiernymi problemami właśnie ze względu na nadużycia użytkowników, którzy nie powinni mieć dostępu, lub dostęp ten powinien być ściśle monitorowany.

Co można zatem zrobić?

Przede wszystkim przyjrzeć się obecnej infrastrukturze SAP:

1 - jaka jest aktualna Twoja koncepcja uprawnień? Czy jest brana pod uwagę w codziennych czynnościach?

2 - jak wygląda Twój proces nadawania uprawnień oraz ich akceptacja? Czy osoby akceptujące posiadają wystarczającą wiedzę o ryzykach?

3 - czy znasz poziom ryzyk związanych z dostępami i konfliktami uprawnień?

Jeśli masz wątpliwości co do któregokolwiek z punktów - jesteśmy do dyspozycji.

autor: Tomasz Jurgielewicz /Sast Polska Team/
tomasz.jurgielewicz@lukardi.com

------------------------------------------------------------------------------------------------
Bibliografia
https://www.slideshare.net/slideshow/embed_code/key/36w8AjPl4t9TcE
https://www.pwc.com/gx/en/forensics/gecs-2020/pdf/global-economic-crime-and-fraud-survey-2020.pdf

-------------------------------------------------------------------------------------------------

WARTO PRZECZYTAĆ:

Projekt reorganizacji uprawnień

W poprzednim artykule pisałam o audycie uprawnień za pomocą narzędzi SAST.
Audyt taki, jeśli przynosi zatrważające rezultaty w obszarze bezpieczeństwa SAP (czytaj: z raportu audytowego jasno wynika, iż jako organizacja potrzebujemy zmian w zakresie lepszego zarządzania użytkownikami i uprawnieniami w organizacji) często prowadzi do dyskusji dotyczącej aktualnych procesów zarządzania uprawnieniami.

Takie dyskusje często są świetnym początkiem drogi do rozpoczęcia projektu.
Warto zauważyć, iż w przypadku reorganizacji uprawnień można też zastosować tzw. „projekt pełzający” czyli naprawiamy i uszczelniamy system krok po kroku.  Jest to dobra opcja, gdy mamy mało zasobów ludzkich, czasu i pieniędzy na wielki projekt reorganizacyjny.

Projekt reorganizacji uprawnień- od czego zacząć?

Klienci zazwyczaj obawiają się wielkiego przedsięwzięcia i wywrócenia do góry nogami świata autoryzacyjnego, a co za tym idzie, świata codziennego biznesu. Często taki świat rządzi się swoimi prawami, role są przepełnione, zawierają setki nieużywanych transakcji lub S_TCODE są wypełnione,
o zgrozo, * (słownie: gwiazdką)!
Jednak coraz częściej atrakcyjniejszy staje się model reorganizacyjny  gdzie porządki robi się stopniowo, dział po dziale, czas na spotkania znajduje się poza gorącymi okresami w przedsiębiorstwie. Kroki milowe nie są wielkie i gwałtowne, ale są wdrażane stopniowo przyczyniając się do wzrostu świadomości autoryzacyjnej we wszystkich działach.

Dobrze, zatem jak robimy projekt?

Audyt
Weryfikuje obecną sytuację i jest argumentem przemawiającym za rozpoczęciem reorganizacji uprawnień. SAST analizuje m.in. wykorzystywane transakcje i generuje raporty, które muszą być przeanalizowane przez sponsora projektu, jego doradców oraz zespół projektowy.
W skład zespołu projektowego muszą wchodzić osoby pełniące rolę administratora uprawnień.

Zdefiniowanie ryzyk projektowych w przedsiębiorstwie
Standard przy każdym projekcie, nie tylko autoryzacyjnym.
W każdej organizacji będą to inne ryzyka. Może brak Key-userów? Może brak zespołu autoryzacyjnego?
Może niezrozumienie istotności obszaru uprawnień SAP przez Zarząd?

Plan projektu
Dzielimy projekt na najważniejsze fazy, podczas których muszą wydarzyć się odpowiednie działania
w nieprzypadkowej kolejności.

Koncepcja Uprawnień
Dokument, który opisuje kompletny model zarządzania uprawnieniami i użytkownikami w SAP
w organizacji. Najważniejsze: nie tworzy się go raz przy wdrożeniu SAP i się o nim zapomina.
Jest to „żyjący” dokument, aktualizuje go na bieżąco zespół autoryzacyjny przy każdorazowej modyfikacji uprawnień. Na wniosek klienta dostarczamy nasz szablon Koncepcji Uprawnień podczas projektu.

 Dobre praktyki

Gotowi na projekt?  Zapraszamy, pomożemy Wam zrobić wiosenne porządki w autoryzacji!

autor: Bernadeta Szwarc /Sast Polska Team/

-------------------------------------------------------------------------------------------------

WARTO PRZECZYTAĆ:

Czym są noty SAP?

Noty bezpieczeństwa SAP® - być spokojnym o system

Czym są noty SAP®?

Uogólniając można powiedzieć, że są małymi aktualizacjami oprogramowania – zawierają korekty kodu, zawierają przy tym opis problemu, itd. Drugą ich rolą jest wsparcie, które nie zawiera korekt/aktualizacji lecz dokumentuje konkretny problem, często w szerokim zakresie.
Te pulę nazywamy odpowiednio po prostu notami (SAP® Notes) oraz artykułami bazy wiedzy
(SAP® Knowledge Base Articles).

Aby dalej przybliżyć funkcję not można wprowadzić kolejny podział, który pozwoli nam dojść do sedna sprawy - bezpieczeństwa.

Widzimy więc, że noty są… pomocne. Wiele z nich jest „nieprzyjaznych’ ze względu na złożoność, jednak wraz z podnoszeniem kompetencji, poziomu wiedzy oraz doświadczenia dot. systemów SAP®, dyskomfort zniknie.

Gdzie i jak szukać not bezpieczeństwa?

Najprostsza odpowiedź: na SAP® Support Portal (https://support.sap.com/securitynotes). Nie da się przeoczyć odnośników różnego rodzaju m. in. takich jak ‘Expert Search’. Jednak rekomendowaną opcją jest posiadanie sprawnego systemu Solution Manager, dzięki któremu w łatwy sposób systemy będą mogły być „na czasie”.

Jak? To tylko trochę bardziej trudne. W momencie pisania tego artykułu noty bezpieczeństwa znajdziemy na SAP® Launchpad w sekcji ‘System Operations and Maintenance’, kafelek ‘SAP Security Notes’.

Wstępnie na samym kafelku otrzymamy informację, ile not bezpieczeństwa jest do przejrzenia.
Jeśli jest to spora liczba, to… słabiutko! Ktoś nie wykonuje rutynowej kontroli. Można wytłumaczyć się regularnym aktualizowaniem systemu, ale tylko częściowo. Wyraźnym zaleceniem jest, że każdy klient musi regularnie przeglądać listę not i musi zweryfikować dla każdego wpisu, czy nota bezpieczeństwa nadaje się do systemu, który jest w jego posiadaniu, oraz co zrobić jeśli implementacja noty jest konieczna.

Do dyspozycji mamy kilka filtrów, które ułatwiają weryfikację not bezpieczeństwa pod katem przydatności, takich jak: system (czy dotyczy naszego), kategoria (np.: błąd programu), priorytet (ważność), itd.

Patch Day Notes – na ratunek

Te konkretne noty publikowane są cyklicznie, na tzw. SAP® Security Patch Day, w każdy drugi wtorek każdego miesiąca. Zbiór tych not zawiera noty od priorytetu ‘Low’ do  ‘HotNews’, bardzo często zgłaszane przez zewnętrzne źródła, w większości przypadków posiadające punktację CVSS.
CVSS oznacza ‘Common Vulnerability Scoring System’ i ma za zadanie w postaci punktowej przedstawić charakterystykę podatności bezpieczeństwa i jej krytyczność. W tym artykule nie będziemy się skupiać na tym, co dokładnie składa się na punktację CVSS, niemniej warto się z tym zapoznać. Mnóstwo materiałów i dokumentacji dostępnych jest powszechnie w sieci.

Patch Day Notes powinien (a nawet musi) być jednym z elementów niezbędnego minimum
w kalendarzu administratora bezpieczeństwa.

Podsumowanie

RSECNOTE? Kiedy to było…? Dawniej przyjemny kawałek „softu”. Dziś – ratuj się kto może!
No, może sporo w tym przesady, ale komunikat jest jasny. Nie używamy już tej funkcjonalności. Dlaczego więc została ona tu przywołana? Jako punkt wyjścia do powyżej poruszonego tematu, który doprowadzi nas do: 1890782 - RSECNOTE no longer supported oraz https://support.sap.com/sysrec i po nitce do kłębka, do wielu ciekawych informacji rozszerzających powyższe zagadnienie.

Cóż, miłej lektury i jak to się mówi – STAY SAFE 🙂

autor: Bartosz /Sast Polska Team/

-------------------------------------------------------------------------------------------------

WARTO PRZECZYTAĆ RÓWNIEŻ NA TEMAT BEZPIECZEŃSTWA SAP:

Audyt bezpieczeństwa systemów SAP

Jak się do niego przygotować z SAST i jakie przynosi korzyści dla organizacji?

Każda myśl dotycząca zwiększenia bezpieczeństwa w organizacji, która przybiera formę planu lub chociażby dyskusji jest godna uwagi.

Jak jednak przekuć myśl oraz planowanie w konkretne działanie przynoszące korzyść przedsiębiorstwu?

Dzięki narzędziu SAST wykrycie potencjalnych nieprawidłowości oraz zagrożeń jest łatwe, szybkie
i wyczerpujące.

Zakres audytu bezpieczeństwa systemu SAP

W naszej pracy realizujemy audyty bezpieczeństwa systemów SAP w oparciu o najlepsze praktyki dotyczące projektów bezpieczeństwa SAP dla systemów SAP w odniesieniu do ISO 27001. Podczas audytu sprawdzane i analizowane są wszystkie istotne elementy systemu (stos ABAP, stos Java, system operacyjny, baza danych) oraz ustawienia SAP i autoryzacje użytkownika.
Audyt jest przeprowadzany przy użyciu certyfikowanego przez SAP narzędzia bezpieczeństwa SAST.

Zakres badania obejmuje ponad 3.000 kontroli dotyczących następujących obszarów

Wszystkie przeprowadzone weryfikacje i ujawnione luki zestawiamy w sprawozdaniu pokontrolnym podlegającym ocenie klienta, a następnie przedstawiamy i wyjaśniamy klientowi podczas warsztatów dotyczących wyników i opracowania planu naprawczego.

Etapy audytu bezpieczeństwa SAP

Jak wyglądają poszczególne etapy Audytu Bezpieczeństwa? Ile to wszystko trwa?
Na co musimy się przygotować?

Jeśli chodzi o czasochłonność przeprowadzenia wyżej opisanego audytu, trwa on około dwa tygodnie. Należy jednak wziąć pod uwagę dostępność własnych zasobów wewnętrznych, tak aby
w najbardziej optymalny sposób móc się pochylić nad aspektami związanymi z bezpieczeństwem.

Wyniki kontrolne audytu bezpieczeństwa systemu SAP

Wyniki audytu przekazujemy klientowi w formie elektronicznej (Microsoft Word lub Excel).
Dodatkowo przedstawiamy je w siedzibie klienta podczas spotkania podsumowującego w formie prezentacji. Bardzo ważne jest, aby na spotkaniu byli obecni reprezentanci lub opiekunowie procesów poszczególnych działów, których procesy były weryfikowane w ramach audytu.

Sporządzona dokumentacja zawiera następujące informacje:

Po audycie bezpieczeństwa systemu SAP

Po przeprowadzeniu weryfikacji, nasz zespół powołuje osobę kontaktową służącą pomocą
w przypadku jakichkolwiek zapytań. Wsparcie obejmuje okres kilku tygodni od momentu przekazaniu pisemnych wyników kontrolnych.

Jeśli zastanawiasz  się  nad zbadaniem aktualnego stanu systemu SAP pod kątem bezpieczeństwa jednak skala problemów z perspektywy rozmiaru środowiska oraz złożoności procesów wywołuje wątpliwości – proszę dłużej nie zwlekać. Pomożemy, przeprowadzimy audyt i w klarowny sposób przedstawimy wyniki oraz plan naprawczy.

autor: Bernadeta Szwarc /Sast Polska Team/

-------------------------------------------------------------------------------------------------

WARTO PRZECZYTAĆ RÓWNIEŻ NA TEMAT BEZPIECZEŃSTWA SAP: