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:


Backupy a cyberbezpieczeństwo

Backupy, czyli o tym jak się mają kopie zapasowe do cyberbezpieczeństwa

Czym są kopie zapasowe?

 Kopie zapasowe (ang. Backup) są dokładną kopią najważniejszych danych naszej organizacji. Takie kopie zapasowe powinny być przechowywane poza systemem, którego dotyczą – tak aby potencjalna awaria lub atak nie pozbawiły nas dostępu do wszystkich naszych danych.
W najbezpieczniejszym przypadku dane powinny być trzymane na dyskach zewnętrznych odłączonych od sieci internetowej oraz energetycznej. Kopie zapasowe mogą być skompresowane, aby ograniczyć zużycie przez nie przestrzeni dyskowej.

Dobrą praktyką jest też szyfrowanie kopii zapasowej, aby utrudnić wykorzystanie jej przez osoby nieupoważnione.

Czym skutkuje brak kopii zapasowych?

Brak aktualnej kopii zapasowej istotnych danych może przynieść opłakane skutki. Utracenie dostępu do ważnych dla nas danych oznacza utratę wielu lat naszej pracy oraz konieczność poświęcenia dodatkowego czasu na ponowną konfigurację dotkniętych systemów.

Do przykładowych zagrożeń dla naszych danych zalicza się:

Kiedy robić kopie zapasowe?

Kopie zapasowe danych powinny być robione tak często jak to tylko możliwe, a w idealnym przypadku – przy okazji każdej zmiany. Idealny przypadek oczywiście dałoby się zrealizować, jednak koszty takiego przedsięwzięcia oraz potrzebne zasoby byłyby absurdalnie duże. Należy więc znaleźć złoty środek pomiędzy jak najmniejszym zużyciem zasobów potrzebnych do utrzymania aktualnych kopii zapasowych a minimalizacją potencjalnej utraty danych, które nie zostały zapisane jako backup. Nie powinno się też ograniczać do wyłącznie jednej kopii zapasowej, dla większego bezpieczeństwa powinno się przechowywać ich więcej. Tworzenie kopii zapasowej najlepiej zaplanować poza godzinami pracy – tak, aby zużywane przez ten proces zasoby nie utrudniały działania organizacji.

Podsumowując: śpieszmy się robić kopie zapasowe danych, w obliczu ataków i awarii, dane tak szybko odchodzą…

autor: Filip Starobrat /Sast Polska Team/

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

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

Warsztaty w Dortmundzie - jakie mamy wnioski po spotkaniu w Niemczech?

Jak wyglądała wymiana doświadczeń?

W dniach 3-4 czerwca 2019 nasi specjaliści Bernadeta Szwarc i Marek Czubaszek uczestniczyli w warsztatach dotyczących projektów reorganizacji uprawnień w siedzibie Akquinetu w Dortmundzie. Każde takie spotkanie jest niezwykle wartościowe i bardzo efektywne.
W ciągu dwóch dni wspólnie ze współpracownikami z Niemiec omawiali tematy związane z prowadzeniem projektów, dzieli się doświadczeniami, poruszając kwestie wykorzystania narzędzi SAST w celu optymalizacji projektów.

Jakie były główne tematy poruszane podczas warsztatów?


Podczas warsztatów Bernadeta i Marek wraz z kolegami z Niemiec omawiali:

Dodatkowo wymienili się doświadczeniami w zakresie dobrych praktyk przeprowadzania projektów oraz użycia odpowiednich funkcjonalności narzędzi SAST, które optymalizują projekt.

Inne zagadnienia poruszane podczas warsztatów:

Wnioski po spotkaniu w Dortmundzie

autor: /Bernadeta Szwarc/

Jak podnieść bezpieczeństwo systemu?

Jak podnieść bezpieczeństwo systemu związane

z logowaniem?

W artykule "Bezpieczne hasło SAP" przy pomocy parametrów kernela dotyczących złożoności haseł rozbieraliśmy je na części pierwsze.
Wiemy już, jak znacznie podnieść bezpieczeństwo systemów SAP oraz jak „zmotywować” użytkowników do
większej sumienności w tym aspekcie.

Ten artykuł również będzie nawiązywał do haseł, jednak już bardziej pośrednio i w szerszym spektrum.

Zastanowimy się w jaki sposób podnosząc bezpieczeństwo systemu związane z logowaniem możemy pomóc administratorom.
Przecież admini zasługują na odrobinę oddechu wykonując swoje ciężkie i odpowiedzialne zadania, prawda?

Drodzy administratorzy, chcemy pomóc.

Dlaczego tracimy dostęp do systemu?

CapsLock… jeden z przykładów, który powoduje, że tracimy dostęp do systemu.
Kto nigdy się w ten sposób nie pomylił, niech pierwszy wystąpi o podwyżkę.

Ale gdzie tu bezpieczeństwo? Przecież ktoś się tylko pomylił.

Ano tu, że system ma to gdzieś i traktuje uczciwego, niefrasobliwego użytkownika tak jak włamywacza i wrzuca ich do jednego worka.

Chcesz się włamać? STOP!

Nie umiesz się zalogować? Możesz nabroić 😉 STOP!

Aby ograniczyć liczbę nieprawidłowych logowań ustawiamy ‘login/fails_to_user_lock’ na przykład na wartość 3.
Za każdym razem, gdy logujemy się nieprawidłowo licznik błędnych logowań zwiększa się o jeden, aż do wartości granicznej, w tym przypadku 3.

Następnie konto jest blokowane.

Może nas odblokować administrator, albo sam system dzięki parametrowi ‘login/failed_user_auto_unlock’.

Ustawienie wymienionego parametru na wartość 1 powoduje, że blokada pozostaje tylko na dzień, w którym nastąpiło zablokowanie.

Należy jednak uważać, aby nie „oberwać rykoszetem”, gdyż włamywacz również będzie miał następnego dnia możliwość próby logowania.
Z pomocą przychodzi wtedy Security Audit Log.

Kto nie sprawdza SALa, ten gapa.

Jaka jest długość życia haseł?

No właśnie. Hasła mają swoją długość życia i domyślnie życie to jest tak długie jak życie systemu, chyba że użytkownik zdecyduje się z własnej inicjatywy na zmianę hasła.

Spoglądając na to zagadnienie z punktu widzenia bezpieczeństwa systemu nie zmienianie w ogóle jest niedopuszczalne.

Hasła powinny być regularnie zmieniane (względnie często).

Nie należy jednak popadać w skrajności i maltretować użytkowników codziennymi zmianami (chyba, że wewnętrzna polityka bezpieczeństwa mówi inaczej).

W jaki sposób uszczęśliwić użytkowników, aby żyli ze świadomością,

że ich konta są bezpieczne?

Ustanowić parametr ‘login/password_expiration_time’. Wartość przypisana parametrowi będzie oznaczała liczbę dni, po której użytkownik będzie musiał zmienić hasło od momentu kiedy ustanowił ostatnie.

Kiedy użytkownik otrzymuje nowe konto lub prosi administratora o zmianę hasła na istniejącym koncie, administrator przypisuje do konta hasło inicjalne.
Ten rodzaj haseł również ma swój czas życia i podobnie jak wyżej, domyślnie jest on tak długi jak długo żyje system. Użytkownik logując się na konto z hasłem inicjalnym zmienia je na hasło znane tylko sobie.
Oznacza to, że im szybciej użytkownik zmieni hasło inicjalne tym lepiej i bezpieczniej.

Jak przymusić do zmiany hasła inicjalnego?

Proste. Kolejny parametr ‘login/password_max_idle_initial’.

Wartość parametru, to liczba dni dana użytkownikowi kiedy ma czas na zmianę. Jeśli tego nie zrobi, to klops, konto zostaje zablokowane.

Warto dodać jeszcze jeden ciekawy parametr: ‘login/password_max_idle_productive’.

Jego wartość oznacza liczbę dni, po których produkcyjne hasło (ustanowione przez użytkownika) zostanie unieważnione, gdy nie będzie używane.

Nie pracujesz? BAN.

A jak wygląda kwestia logowania?

Logowanie. Użytkownik i hasło. Ognia. Wykonujemy obowiązki na systemie. Wylogowanie. Koniec. Do domu.

Wszystko w porządku, prawda? Prawda, jeśli to jeden użytkownik i jedno konto.

Co w przypadku, gdy dwóch użytkowników skorzysta z tego samego konta i logują się jednocześnie na ten sam mandant (klient) w systemie?

Taka sytuacja jest już niestety – niepożądana. Dlaczego? Ano dlatego, że chodzi tutaj o pieniądze, o licencje.
Ilu użytkowników, tyle licencji. Ile licencji, tyle pieniędzy dla producenta oprogramowania.
Chcąc nie chcąc należy tego pilnować, taki biznes.

Aby nie mówić użytkownikom: „Hej, pamiętajcie: logujcie się roztropnie, bo inaczej nas SAP po… kieszeniach kopnie”, ustanawiamy parametr ‘login/disable_multi_gui_login’ na 1 (słownie: jeden). Sprawa załatwiona.

Nadmieńmy, ze mówimy tutaj o produkcji.

W wyjątkowych i kontrolowanych okolicznościach można zezwolić użytkownikom na wielokrotne logowanie poprzez parametr ‘login/multi_login_users’.
Jako wartości podajemy nazwy kont (użytkowników) w systemie, którym będzie wolno „łamać” zasadę wielokrotnego logowania.

Na śpiochów lub takich co stoją w kuchni na kawie może podziałać ‘rdisp/gui_auto_logout’,
zrobią miejsca dla tych co chętnie pracują.

PODSUMOWANIE

Jedni wiedzą, inni nie. Jedni korzystają, inni nie. Wiedząc o tym, że informacja to klucz do… wielu rzeczy, starajmy się za wiele nie podpowiadać. Zwłaszcza tym, którzy nie muszą lub nie powinni zbyt wiele wiedzieć.

O czym mowa?

O prostym parametrze, ale jakże przyjemnym ‘login/show_detailed_errors’. Ustawiamy oczywiście na wartość 0 (zero).

To by było tyle.

Pamiętajcie: kto wdraża bezpieczeństwo w organizacji, bezpiecznie może spać na delegacji.

Autor: Bartosz /Sast Team Polska/

WARTO PRZECZYTAĆ NA TEMAT BEZPIECZEŃSTWA SAP:

Monitoring zachowania użytkowników SAP

Monitoring zachowania użytkowników SAP

Zwiększające się wymagania (na przykład pochodzące z regulacji RODO), wymusza na organizacjach wdrożenie takich rozwiązań, które zwiększą poziom bezpieczeństwa systemów przetwarzających dane osobowe. SAP nie jest wyjątkiem. Dzisiejszy artykuł pokaże Wam jak w 3 krokach zwiększyć bezpieczeństwo danych.

Bezpieczeństwo danych to nie tylko autoryzacje

Aby rozłożyć temat na czynniki pierwsze - zacznijmy od podstaw. Każdy użytkownik w SAP ma nadane uprawnienia. To one decydują o tym, czy użytkownik powinien uzyskać dostęp do jakichś partii danych, czy taki dostęp ma zostać zablokowany. Na podstawie przydzielonych ról możemy ograniczyć dostępy. To fakt. Tu natomiast pojawia się dość poważny problem związany z potencjalnym wyciekiem danych poza system.

1. Monitoring wyświetlania danych osobowych

Standardowe rozwiązania SAP ograniczone są do zarządzania autoryzacjami. Standard nie dostarczy czytelnej odpowiedzi na pytania dotyczące tego "kto", "co" i "kiedy" wyświetlał na swoim ekranie. Obecnie, dysponując zwykłym telefonem komórkowym każdy użytkownik jest w stanie zrobić zdjęcie ekranu, na którym wyświetlone są dane osobowe (bądź zrobić print screen), ślad po tej czynności jest praktycznie żaden. Istotne jest zatem szczegółowe monitorowanie i logowanie ryzykownych operacji użytkowników z większą dokładnością niż dostarczane funkcjonalności w standardzie.

Przykładów potencjalnych nadużyć jest więcej. Na przykład użytkownicy uprzywilejowani (chociażby administratorzy) mają wręcz nieograniczony dostęp do danych zawierających wrażliwe informacje. Nowe wymogi GDPR mówią o tym, by możliwie skutecznie monitorować dostępy do danych. Nie tylko wymogi regulacyjne powinny być tym jedynym czynnikiem, który ma na celu wprowadzenie zmian w procesy dostępu do danych osobowych. Bo przecież sam wyciek danych o płacach może spowodować zakłócenie porządku pomiędzy pracownikami. Dane mogą również zostać przejęte przez konkurencje - a to również biznesowy problem.

Powyżej przedstawiamy istotne elementy logowanie zachowania użytkowników z dokładnością do wyświetlenia danych osobowych, w sposób globalny. Rozdzielczość monitoringu użytkowników powinna być zatem na tyle duża, by precyzyjnie dostarczać informację związaną z dostępem (wyświetleniami) danych SAP HR.

2. Zapisywanie danych do plików

Standardowo system SAP pozwala na globalne włączenie lub wyłączenie możliwości pobierania danych (np. z raportu, do którego użytkownik ma dostęp). Domyślnie logi pozwalają jedynie na informację o tym kiedy i kto ściągnął plik o konkretnej nazwie, do konkretnej ścieżki. W standardzie brak jest jakichkolwiek informacji o zawartości pobieranych plików.

Można zwrócić uwagę na powyższy screen przez pryzmat informacji o potencjalnych naruszeniach:
1 - jakie dane zostały pobrane? Brak informacji
2 - czy w pliku zawarte były krytyczne dane osobowe? Brak informacji
3 - czy jesteśmy w stanie odtworzyć pobrany plik? Nie

Na szczęście (dla bezpieczeństwa danych w SAP) istnieją rozwiązania, które powyższe problemy są w stanie skutecznie rozwiązać. Dostarczając rozszerzonych informacji w logach o konkretnych działaniach, ze zdecydowanie większą rozdzielczością.

Za pomocą zdefiniowanych słów kluczowych, raportów czy rozmiaru plików - administratorzy są w stanie otrzymywać informacje o potencjalnych nadużyciach związanych ze ściągnięciem krytycznych porcji danych. Dodatkowo każde z pobrań jest odkładane (na konkretną ilość czasu), istnieje zatem możliwość całkowitego odtworzenia pobranego pliku

3. Wykorzystywanie transakcji

Zmniejszenie ryzyk związanych z nieuprawnionym dostępem do danych to również dbanie o to, by ograniczać do niezbędnego minimum przyznane uprawnienia. Założenie jest takie - przyznane autoryzacje nie zawsze w 100% odpowiadają wymaganym (często są o wiele większe, niż te, które rzeczywiście pracownik potrzebuje do realizacji swoich codziennych czynności). Należy zatem analizować wykorzystanie transakcji pod kątem ich wykorzystania.

Statystyki znajdują się w ST03N i aktualizowane comiesięcznie. Dzięki temu:
- transakcje niewykorzystywane można usunąć z uprawnień użytkownika
- transakcje niewykorzystywane w roli (przez żadnego z użytkowników) - można z niej usunąć całkowicie

Podsumowanie

Powyższy zestaw trzech elementów monitoringu użytkowników, o który możesz poszerzyć Twój system SAP wspiera procesy związane z zarządzaniem ryzykiem i bezpośrednio podnośni poziom bezpieczeństwa. Taka operacja pozwoli na szybkie uporządkowanie potencjalnych możliwości nadużyć.

Tu warto dodać jeszcze jedną szalenie istotną rzecz z perspektywy monitorowania użytkowników.

Podczas jednego z naszych projektów, po kilku tygodniach od wdrożenia powyższych funkcjonalności, poinformowani zostali użytkownicy o tym, że ich działania są monitorowane. Spadek pobrań danych do pliku spadł o około 63%.

A co robią Twoi użytkownicy w SAP?

WARTO PRZECZYTAĆ:

Bezpieczeństwo SAP

Bezpieczeństwo SAP

Wymogi dotyczące bezpieczeństwa nieprzerwanie wzrastają, a zabezpieczenie krytycznych danych w organizacji jest jedną z podstawowych kwestii, gwarantujących ciągłość podstawowych procesów biznesowych.
Środowiska systemowe stają się coraz bardziej złożone (komunikacja z systemami zewnętrznymi, wymiana danych oraz ciągły rozwój istniejących systemów).

Podczas ewentualnego ataku na system SAP (bez względu na to, czy atak pochodzi z wewnątrz czy z zewnątrz organizacji) osoba atakująca może uzyskać dostęp do cennych informacji systemowych.
W związku z tym może wykorzystać te informacje do dalszych ataków na inne systemy SAP a także uzyskać ważne dane firmowe (dane klientów, informacje o produkcie, np. receptury i rysunki techniczne, dane o wynagrodzeniu itp.) w sposób niezauważony.

Zarządzanie bezpieczeństwem sprowadza się do zarządzania ryzykiem

Przede wszystkim, aby zrobić to odpowiednio należy zewidencjonować wszystkie ryzyka i pogrupować je wg priorytetów po to, by organizacja posiadająca system SAP mogła poznać i skorygować ewentualne zagrożenia dla systemu SAP (na przykład z pomocą zewnętrznego wsparcia).
Badanie bezpieczeństwa i zgodności SAP obejmuje sprawdzenie sieci, systemu operacyjnego, bazy danych, parametrów, konfliktów SoD w systemie SAP w oparciu o dostarczane matryce ryzyk i konfliktów.

6 podstawowych obszarów ryzyk

Wyszczególniliśmy 6 podstawowych obszarów ryzyk, które należy wziąć pod lupę w pierwszej kolejności.
Obszary podzieliliśmy na dwie części: techniczną oraz użytkowników.

Warstwa techniczna

1. Ustawienie konfiguracji SAP

Warstwa parametrów konfiguracyjnych, które powinny odpowiadać polityce bezpieczeństwa organizacji. Parametry te należy kontrolować regularnie.

Przykład:

login/password_expiration_time (wartość domyślna 0, nasza rekomendacja 30)
Użytkownik musi zmienić hasło po określonej ilości dni (dla parametru 0 wymuszenie nie jest włączone).


login/min_password_lng
(wartość domyślna 3, nasza rekomendacja 8+)
Ustawienie minimalnej długości hasła.

login/fails_to_user_lock (wartość domyślna 12, nasza rekomendacja 5)
Ilość źle wpisanego hasła do blokady konta użytkownika.

2. Weryfikacja zdarzeń i ustawień "na" i "poza" warstwą SAP

Poziom SAP

SAP Security Audit Log:

  • główny log bezpieczeństwa,
  • część informacji jest mało czytelna z perspektywy bezpieczeństwa,
  • zalogowanie usera SAP* nie stanowi wg logu ryzyka, podczas gdy ryzykiem jest źle wpisane hasło logowania.

SAP Change Documents and Table Loggin:

  • logowanie zmian dokumentów oraz zmian w tabelach,
  • niska jakość w przypadku braku archiwizacji dokumentów w czasie.

SAP System Log:

  • główny log systemu SAP,
  • logi nadpisywane po 14 dniach.

Poziomy poza SAP

Log systemu operacyjnego Windows/UNIX - problemem jest np. fakt, że administrator musi posiadać uprawnienia root do samego odczytu logów

Log bazy danych – brak możliwości analizy ustawień bazy danych z poziomu SAP (np. Informacja o kontach i ich autoryzacjach)

Logi sieciowe SAP Router/HTTP - problemem jest brak standardowych rozwiązań do przekierowania logów do syslogu

3. Aktualizowanie Patchy systemowych

Każdy system jest podatny na działania hackerskie, SAP nie jest wyjątkiem, dlatego istotne jest, aby regularnie instalować łatki systemowe.
Dzięki nim pojawiają się informacje o włamaniach z wykorzystaniem znanych podatności.

Przykład 1 - raport Departamentu Bezpieczeństwa USA wskazującego na włamania do co najmniej 36 globalnych systemów SAP z wykorzystaniem luki znanej (i naprawionej) od 2010 roku. Więcej na https://bit.ly/28Kpk5r

Przykład 2 - coroczne spotkanie społeczności zajmującej się tematyką bezpieczeństwo the PWNIE Awards w 2015 roku przyznało pierwszą nagrodę w kategorii Best Server-Side Bug za wykrycie podatności w SAP, pozwalającej na nieautoryzowany dostęp do systemu https://bit.ly/29Se5hB

Warstwa użytkowników

4. Domyślne konta

Podczas wdrożenia systemu SAP tworzone są domyślne konta użytkowników. Służą one do wstępnej instalacji systemu, powszechnie znane są zarówno z nazwy jak i hasła.
Niezwykle ważna jest odpowiednia ochrona tych kont.
Najbardziej krytyczne konto to SAP* (pozwala na praktycznie nieograniczoną możliwość dostępu i zmian w systemie).

Hasła kont domyślnych należy zmienić, a profile wysoko uprzywilejowane (np. SAP_ALL) należy usunąć.
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*).

5. Domyślne profile

Tak jak w przypadku kont domyślnych, SAP posiada (dostarczane wraz z instalacją) zestawy profili autoryzacyjnych, pozwalających na szeroki dostęp do systemu. Wykorzystanie tych profili powinno być bardzo restrykcyjnie zarządzane, a ich użycie ograniczone tylko do sytuacji awaryjnych.

Najważniejszym profilem szerokiego dostępu jest SAP_ALL - pozwala on na wykonanie dowolnej transakcji, dostępu do dowolnego obiektu, funkcji czy akcji (nie bez powodu w żargonie administratorów SAP o tym profilu zwykło się mówić "Bóg na systemie"). Istotne jest by ten profil nie został nigdzie przypisany. Podobnie sprawa ma się z profilem SAP_NEW

6. Konflikty uprawnień

Nieodpowiednie dostarczenie użytkownikom praw dostępu do różnych części systemu to zwiększone ryzyko defraudacji.

Przykład: jeśli jedna osoba posiada zarówno możliwość zmiany numeru konta bankowego oraz możliwość wykonania przelewu - istnieje możliwość obejścia polityk organizacji w celu wyprowadzenia pieniędzy na zewnątrz.

Reasumując: istotne jest aby odpowiednio zarządzać matrycą konfliktów uprawnień. Matryca taka pozwala przede wszystkim na identyfikację istniejących konfliktów, a weryfikacja dostępów poszczególnych użytkowników pozwoli na ocenę ryzyk. Realizacja skutecznej polityki dostępów do danych w SAP stanowi jeden z najważniejszych elementów uszczelnienia środowiska SAP pod kątem ryzyk, których głównym czynnikiem jest działanie użytkownika.

WARTO PRZECZYTAĆ NA TEMAT BEZPIECZEŃSTWA SAP:

Jaka jest przyczyna wycieku danych?

Jaka jest przyczyna wycieku danych?

Jeszcze kilka lat temu tematy związane z bezpieczeństwem danych były przedmiotem rozmów wąskich grup specjalistów zajmujących się cyber bezpieczeństwem. Przed erą wszechobecnych loginów i haseł - świadomość zagrożeń dla bezpieczeństwa danych nie było przedmiotem trosk wielu ludzi. Te czasy bezpowrotnie minęły.
Dlaczego cyber bezpieczeństwo jest ważne i jaka jest główna przyczyna wycieku danych?
Na te pytania odpowiemy w poniższym artykule.

Wyciek danych do logowania

Do obiegu informacji dostępnej dla przeciętnego Kowalskiego, coraz częściej dochodzą te, przedstawiające różne aspekty bezpieczeństwa danych. Głównie są to wiadomości o wyciekach danych logowania z popularnych portali czy informacje o kradzieżach pieniędzy przez cyberprzestępców. Żyjemy w czasach, w których możemy porozmawiać o bezpieczeństwie IT praktycznie z każdą osobą. Dzieje się tak ponieważ tematy security są szeroko poruszane w masowych mediach.

Przykłady naruszeń bezpieczeństwa:

    1. Pewien znany dziennikarz opisał swój przypadek, podczas którego stając się ofiarą phishingu stracił kilkanaście tysięcy złotych ze swoich kont,
    1. Jeden z banków wyłączył domyślny akcept przelewów via kod SMS, następnie przeprowadzono atak phishingowy, na który złapała się rzesza Klientów Banku,
    1. Przedsiębiorca omawia w kilkuminutowym filmie w jaki sposób stracił 40 tysięcy złotych (wirus podmieniający numer kont bankowych),
  1. Raport DHS, który omawia luki bezpieczeństwa w SAP - omawialiśmy raport na naszym blogu.

Przykładów można mnożyć. Moją ideą  jest próba odpowiedzi na pytanie - co jest główną przyczyną wycieku danych. Odpowiedź jest wydawać by się można - prosta: IGNORANCJA!

Rodzaje ataków na systemy bezpieczeństwa

Ataki phishingowe

To przede wszystkim żerowanie na czyjejś naiwności oraz znikomej wiedzy o zagrożeniach.

Ataki za pomocą podmiany numerów kont na stronie banku

jest to wpuszczenie do swojego komputera wirusa (to, jaką drogą jest sprawą absolutnie pomijalną,olbrzymią wartością dla przestępców jest to, że użytkownicy są po prostu nieuważni).

Na przykład przy weryfikacji numerów kont bankowych w kontrolnym SMS.

Ataki za pomocą znanych luk 

wynikające przede wszystkim z ignorancji administratorów systemów, którzy nie reagują na znaną lukę od kilku lat.

PODSUMOWANIE

Reasumując: niniejszy wpis traktuję z lekkim przymrużeniem oka ponieważ prawdziwe przyczyny nadużyć leżą zarówno w warstwie błędów (mniej lub bardziej świadomych) użytkowników, ale także w warstwie technicznej systemów.
Godne uwagi jest również to, że w znakomitej większości przypadków nieautoryzowanego dostępu do danych w systemach, to tzw "interfejs białkowy" ma z pewnością kluczowe znaczenie.

WARTO PRZECZYTAĆ NA TEMAT BEZPIECZEŃSTWA SAP:

Luka bezpieczeństwa powodem cyber ataku

Luka bezpieczeństwa powodem cyber ataku

Po raz pierwszy w historii Departament Bezpieczeństwa Krajowego USA (Departament of Homeland Security) opublikował raport o zagrożeniach bezpieczeństwa systemów SAP (US-CERT Alert for cybersecurity of SAP business applications). Raport opisuje to jaka luka bezpieczeństwa miała wpływ na przejęcie kontroli nad systemami SAP.

36 organizacji ofiarą ataku przy użyciu luki bezpieczeństwa

Co najmniej 36 organizacji (posiadających w swojej infrastrukturze system SAP) zostało zaatakowanych z użyciem luki bezpieczeństwa znanej od około 6 lat. Atak był wycelowany przede wszystkim w systemy, które nie były aktualizowane zgodnie z dostarczanymi patchami w ramach SAP Security Notes. Opisane luki dotyczyły z pewnością adonów SAP NetWeaver Server Java - Invoker Servlet.

Jakie systemy są najbardziej zagrożone?

W związku z tym raport DHS wskazuje na to, że systemy SAP posiadające nieaktualizowane oprogramowanie są podatne na zagrożenia. Dotyczy to systemów działających na platformie SAP Java. Ze względu na fakt, że omawiana platforma SAP Java jest podstawową technologią dla wielu systemów włączając w to SAP:
luka bezpieczeństwa jest umiejscowiona na warstwie aplikacyjnej systemu SAP, zatem jej wystąpienie jest niezależne od systemu operacyjnego oraz bazy danych wspierającej system SAP.

Jakie są efekty wykorzystania luki?

Wykorzystanie omawianej luki Invoker Servlet pozwala z pewnością na zdalną, nieuwierzytelnioną, pełną kontrolę nad zaatakowanymi systemami. Pozwala w związku z tym na pełny dostęp do danych i procesów biznesowych na systemach (lub wręcz dostęp do połączonych z SAPem innych systemów).

Jak się zabezpieczyć?

Najpewniejszym rozwiązaniem jest skorzystanie i użycie SAP Security Note 1445998 oraz wyłączenie Invoker Servlet.

Komentarz naszego eksperta

Ze względu na to, że omawiana podatność jest znana od co najmniej 6 lat wydaje się rzeczą nieprawdopodobną, że ta luka została wykorzystana przez włamywaczy. Niepokojące jest również to, że sytuacja dotyczy aż takiej ilości globalnych systemów. Co to oznacza? Ze względu na fakt, że do tematu bezpieczeństwa danych nie podchodzi się w sposób usystematyzowany powoduje takie zaniechania na poziomie bezpieczeństwa. Trudność polega przede wszystkim na przekonaniu decydentów o konieczności inwestycji w rozwiązania automatyzujące procesy bezpieczeństwa SAP.
Daniel Sikorski / SAP Security / BASIS
kontakt z ekspertem


WARTO PRZECZYTAĆ NA TEMAT BEZPIECZEŃSTWA SAP:

SAST Security Radar otrzymał nagrodę innowacji w IT 2015

Sast Security Radar z nagrodą innowancji w IT 2015

Rozwiązanie SAST Security Radar robi wrażenie nie tylko na naszych Klientach. Jej wartość dostrzegają również organizatorzy konkursów innowacyjności w IT. "Initiative Mittelsland" przyznaje nagrody dla rozwiązań innowacyjnych i posiadające wysokiej jakości wartość użytkową. Nasze rozwiązanie wspomagające bezpieczeństwo SAP jest szczególnie przekonujące i dlatego znaleźliśmy się w czołówce rozwiązań w 2015 roku.

 

Jak działa Sast Security Radar?

 

Moduł SAST Security Radar jest jednym z rozwiązań rodziny SAST GRC Suite. Wspomaga monitorowanie problemów z bezpieczeństwem we wszystkich systemach SAP, na wszystkich poziomach szczegółowości, działa w czasie rzeczywistym. Dzięki integracji z rozwiązaniem IBM QRadar nasi Klienci otrzymują pełny wgląd w poziom bezpieczeństwa środowiska IT.

Więcej o SAST Security Radar tutaj.