Odpowiadając na tak zadane pytanie odpowiedź jest prosta - nie.
Ale niepełna, bo po prostu żaden system nie będzie nigdy bezpieczny. Natomiast nie jest tak, że nie możemy dążyć do bezpieczeństwa - wprost przeciwnie. Wszystko sprowadza się do zarządzania ryzykiem, jego akceptacją, ale przede wszystkim świadomością wystąpienia ryzyka. Jakie są zatem największe wyzwania w bezpieczeństwie SAP?
SAP jest największym system ERP na świecie, co realnie pokazują statystyki. Ma to swoje konsekwencje związane z wymaganiami klientów, którzy globalnie mają realny wpływ na rozwój narzędzi zarówno przez samego producenta, jak i przez rozwiązania klienckie (tzw. zetki).
Ekosystem zbudowany dookoła technologii zawiera zarówno warstwę technologiczną (np. BASIS), jak i warstwę związaną z doradztwem biznesowym (które to doradztwo optymalizuje procesy biznesowe, przynajmniej w teorii). Z tego wynikają dwie główne wyzwania związane
z zabezpieczeniem SAP, co w konsekwencji sprowadza się do zarządzania ryzykiem.
Dwie grupy wyzwań bezpieczeństwa bazują właśnie na tych dwóch głównych obszarach, a ich mogą być roboczo zgrupowane według poniższego zestawienia:
Wyzwanie 1 - kontekst biznesowy
Zapewnienie użytkownikom możliwości realizacji procesów biznesowych adekwatnych do ich stanowiska. To powoduje, że organizacja musi wiedzieć jakie ryzyka niesie ze sobą nadmiar uprawnień - tu wprowadzamy pojęcie SoD (konflikty uprawnień, separation of duties).
Wyzwanie 2 - technologia
Np. odpowiednia konfiguracja systemu, kernela, ustawienia interfejsów, raportowanie czy automatyzmy. Konsekwencją jest posiadanie przez organizację wiedzy pozwalającej na ocenę podatności technicznych mających wpływ na stabilność i bezpieczeństwo systemu oraz w nim danych. Każde z powyższych wyzwań można traktować osobno,
jednak dopiero całościowe (kompleksowe) zaadresowanie wyzwań pozwala na odpowiednie zabezpieczenie systemu.
Procesy biznesowe realizowane przez system SAP są realizowane
(w uproszczeniu) w oparciu o transakcje. To ich obecność w roli, przypisanej do konkretnego użytkownika, pozwala na realizację pracy wymaganej przez dane stanowisko. Świadomość organizacji związana z tym czym jest ryzyko jest kluczowa. Dlatego jego identyfikacja jest oparta o identyfikację:
Podczas webinaru 18 kwietnia o godzinie 14:00 opowiem o poszczególnych elementach powyższych kroków oraz zasugeruję garść argumentów, którymi można użyć w dyskusji z biznesem (by w konsekwencji przekonać do konieczności zaadresowania realizacji projektu podniesienia poziomu bezpieczeństwa).
SAP rozwija się w zawrotnym tempie. Można zobrazować to porównując tę technologię do największych na świeci. Liczba linii kodu składającego się na system jest większa niż łącznie linie kodu Mac OS, Firefoxa, Windowsa, Office
i jeszcze kilku technologii.
W gąszczu setek i tysięcy parametrów systemu, kernela, baz danych, interfejsów znajdują się takie, których zmiana z 0 na 1 może spowodować spore wyzwania bezpieczeństwa. Istnieją też takie ryzyka, które nie dotyczą wprost warstwy aplikacji, jak przykład poniżej, gdzie można zrealizować atak na system operacyjny podmieniając klucze SSH.
Dodatkowo w Internecie znajdziemy gotowe (albo prawie gotowe) exploity znanych podatności. Okazuje się, że by spróbować wykorzystać podatność atakujący w niektórych przypadkach nie musi posiadać wyrafinowanej wiedzy (patrz script kiddie https://pl.wikipedia.org/wiki/Script_kiddie))
Istnienie szeregu źródeł logów dodatkowo wprowadza wyzwania związane
z tym co konkretnie badać. Każde ze źródeł logów ma swoją charakterystykę, która monitoring SAP w czasie rzeczywistym może skomplikować.
Powyższe wyzwania bezpieczeństwa SAP to zaledwie ich zebranie
i pogrupowanie. Podczas mojego webinaru skoncentrujemy się na przykładowych jego elementach po to, by zwiększyć świadomość na temat poszczególnych wyzwań. Bo tylko całościowe spojrzenie na wdrożenie procesów GRC w SAP oraz identyfikację zagrożeń od strony technologicznej pozwala na odpowiednie zarządzenie ryzykiem.
