W obecnych czasach praktycznie co chwilę dowiadujemy się o nowych, opublikowanych podatnościach typu 0-day. Słynny Log4shell, czyli podatność (albo raczej podatności, ponieważ była to cała lawina wykrywanych kolejno po sobie zagrożeń) w obszarze najpopularniejszego loggera jest tego doskonałym przykładem. Dzisiaj (30 marca) pojawiła się podobna podatność, tym razem w Spring-u – Spring4shell. Obie pozwalają na zdalne wykonywanie kodu.
Nikt już nie kwestionuje konieczności monitorowania wydajności – systemy klasy APM (Application Performance Monitoring) są czymś oczywistym w organizacjach nastawionych na wysoki poziom dostępności i wydajności aplikacji, niezależnie od wielkości firmy. Dedykowane platformy jak Dynatrace automatyzują zadania związane z konfiguracją takiego monitoringu – same wiedzą co monitorować i nie wymagają żadnych zmian w kodzie czy konfiguracji serwerów. Więc skoro mamy narzędzia monitorujące kod aplikacji pod względem błędów i wydajności, dlaczego to samo oprogramowanie nie może monitorować bezpieczeństwa naszych aplikacji? Przy olbrzymiej liczbie wykrywanych podatności taka potrzeba wydaje się oczywista, ale tylko Dynatrace był w stanie umiejętnie dołączyć do swojej platformy Observability nową funkcjonalność – Application Security. Ten sam agent, który zbiera dane z transakcji i analizuje wykonywany przez nie kod jednocześnie weryfikuje, czy ten kod jest bezpieczny. Duża część kodu pochodzi z bibliotek firm trzecich – wykorzystywanie gotowych frameworków jest dzisiaj najpopularniejszym sposobem wytwarzania oprogramowania. Oszczędzamy przez to czas i zachowujemy pewien poziom standaryzacji. Zwłaszcza w dobie powszechnych mikroserwisów, skonteneryzowanych usług musimy mieć pełną kontrolę nad bezpieczeństwem wykonywanego kodu.
Oczywiście poziom bezpieczeństwa osiągamy zwykle wielowarstwowo. Systemy typu SIEM, WAF są standardem. Również skanowanie pod kątem bezpieczeństwa repozytoriów z kodem ma na celu wykrycie zagrożeń. Wszystkie te rozwiązania mają jednak swoje wady – albo bazują na ściśle określonych wektorach ataku, albo wymagają szczegółowej konfiguracji. Albo skanowanie odbywa się rzadko, na przykład raz w nocy i nie pozwala na wykrycie podatności po ich opublikowaniu.
Wykorzystując moc agenta Dynatrace analizuje w trybie prawie rzeczywistym działający kod, opierając się przy tym o aktualizowaną non stop bazę podatności (poprzez integrację ze SNYK). Dzięki temu mamy pewność, że zaraz po opublikowaniu podatności nasze systemy zostaną przeanalizowane pod kątem istnienia tej podatności w wykonywanym kodzie.
Rysunek 1: Dynatrace wykrywa i klasyfikuje znalezione zagrożenia
Czy musimy coś konfigurować? – NIE
Czy musimy coś zmieniać w aplikacji? – NIE
To wszystko dzieje się automatycznie. Platforma rozpoznaje faktycznie wykorzystywane biblioteki – skanowanie jest wykonywane w oparciu o agenta analizującego w czasie rzeczywistym kod wykonywanych transakcji. Mamy więc pewność, że wykryte zagrożenie dotyczy faktycznie aktywnej funkcji, a nie biblioteki niewykorzystywanej przez nasze oprogramowanie.
System klasyfikuje zagrożenia pod względem ich wpływu – od poziomu krytycznego, przez wysoki, średni aż po niski. Jako bazę do klasyfikacji Dynatrace wykorzystuje wartość CVSS (Common Vulnerability Scoring System). Ale czy CVSS daje rzeczywistą informację o krytyczności problemu w naszej organizacji? Odpowiedź jest następująca: CVSS wskazuje nam potencjalne zagrożenie – nie zna naszego systemu, więc nie może ocenić realnego scenariusza wykorzystania podatności. Tak samo będzie traktował podatność na warstwie frontend, dostępnej z internetu i łatwej do zaatakowania, jak również zaalarmuje nas dla systemu głęboko osadzonego w serwerowni, do którego dostęp ma zaledwie kilka osób z wydzielonej, bezpiecznej sieci lokalnej. Dlatego Dynatrace idzie o krok dalej - wykorzystując Davis-a (asystenta sztucznej inteligencji) pokazuje rzeczywisty, kontekstowy współczynnik zagrożenia DSS, czyli Davis Security Score. DSS oparty jest o model zależności między komponentami, czyli Dynatrace Smartscape. Ten model dostarcza prawdziwy obraz zagrożenia, pokazując czy komponenty z wykrytą podatnością są:
- Dostępne z publicznego internetu, czyli łatwo je zaatakować;
- Mają dostęp do bazy danych, czyli grozi nam kompromitacja danych.
Rysunek 2: Dynatrace sprawdza rzeczywisty poziom zagrożenia
Dodatkowo, bazując na danych ze SNYK, Dynatrace sprawdza czy są dostępne publiczne exploity. Mając te informacje jest w stanie zmodyfikować CVSS, urealniając go i pokazując faktyczne zagrożenie. A wszystko po to, abyśmy w pełni świadomie rozwiązywali problemy tam, gdzie są najbardziej istotne – nie ma nic gorszego niż tablica alarmów, gdzie wszystkie są krytyczne i wszystkie są tak samo pilne. Działając pod silną presją możemy dokonać niewłaściwego wyboru. Wskazując rzeczywisty poziom zagrożenia, Dynatrace przychodzi nam z pomocą.
Rysunek 3: Dynatrace może obniżyć krytyczność jeżeli komponent nie ma dostępu do danych i nie jest publicznie dostępny
Dynatrace pokrywa jeden z wielu aspektów bezpieczeństwa. Najważniejsze cechy rozwiązania to:
- Baza podatności aktualizowana w trybie ciągłym;
- Skanowanie kodu w trybie ciągłym;
- Wykrywanie podatności w rzeczywiście wykorzystywanych funkcjach;
- Świadoma priorytetyzacja realnego poziomu zagrożenia w oparciu o model dostępu do komponentów;
- Pełna automatyzacja – zero konfiguracji i zero wysiłku na utrzymanie.
Najlepszy system monitoringu działa tylko wtedy, gdy jest dobrze skonfigurowany. Dzięki braku konieczności konfiguracji Dynatrace jest zawsze gotowy do akcji i nie musi być dostrajany – działa od razu po włączeniu funkcjonalności Application Security.
Oczywiście skanowanie pod kątem podatności to dopiero początek Application Security w Dynatrace. Już za chwilę uruchomione zostanie wykrywanie i blokowanie ataków w trybie rzeczywistym. Ale to już materiał na kolejny wpis… Update niebawem!
