Omnilogy: Proponujemy naturalne, ale nieoczywiste podejście do bezpieczeństwa

Z Tomaszem Płońskim, CTO w Omnilogy, rozmawiamy o punktach styku pomiędzy bezpieczeństwem i obserwowalnością środowisk IT, możliwościach analizy i wykrywania podatności bezpośrednio na poziomie wykonywanego kodu aplikacji, a także o niezbędnych wnioskach z podatności Log4Shell oraz sposobach rozwiązań Dynatrace i Sysdig.

Cyberbezpieczeństwo i obserwowal­ność to, według prognoz, jedne z naj­ważniejszych priorytetów w zakresie inwestycji z obszaru IT. Rzadko jednak występowały w parze…

To jest jeden z mitów, które należy obalić. Jak nigdy dotąd, połączenie obserwowal­ności i bezpieczeństwa staje się czymś tak oczywistym, że aż trudno sobie wy­obrazić, że do tej pory traktowaliśmy je oddzielnie. Wiele osób nie potrafi do­strzec tego, co faktycznie łączy te dwa światy. Mówię tutaj o danych. Bezpie­czeństwo obejmuje tworzenie procedur i standardów, ale opiera się przecież na systemach, które analizują dane nt. za­chowania użytkowników i aplikacji.

Jeżeli popatrzymy z kolei na obserwo­walność, to już w jej definicji znajduje się możliwość pomiaru bieżącego stanu sys­temu na podstawie generowanych przez ten system danych, takich jak logi, metryki i trace’y. W nowoczesnych środowiskach każde urządzenie, oprogramowanie, kom­ponent infrastruktury chmurowej, każdy kontener i każda mikrousługa tworzy za­pisy aktywności.

Celem obserwowalności jest zrozumienie, co dzieje się we wszystkich tych środowi­skach i technologiach. W ten sposób ob­serwowalność zapewnia nowe narzędzia do wykrywania i rozwiązywania proble­mów, co przekłada się na większą nieza­wodność i wydajność systemów, a także na zadowolenie użytkowników lub klien­tów. Cyberbezpieczeństwo analizuje dane z tych samych środowisk i z tych samych komponentów. Dane są więc z jednej stro­ny spoiwem tych dwóch światów, a z dru­giej – sprawiają, że obie dziedziny znajdują wspólny język.

Czy podobną spójność widać już na poziomie narzędzi wykorzystywanych w kontekście bezpieczeństwa i utrzy­mania infrastruktury?

Odpowiedź zależy od stosowanych na­rzędzi. Na poziomie technicznym kwestie bezpieczeństwa oraz monitoringu IT są nadal często postrzegane w sposób od­rębny. Takie rozumienie wynika z faktu, że działy cyberbezpieczeństwa, co do zasady, korzystają z dużej liczby zróżni­cowanych narzędzi, patrzą na zagrożenia z wielu perspektyw i na wielu poziomach. W kontekście utrzymania infrastruktury ciągle odnosimy się zaś głównie do sta­tycznego monitoringu. Obserwowalność to jednak zdecydowanie coś więcej.

Jako Omnilogy oferujemy klientom platformę obserwowalności Dynatrace, obserwowalności, a nie monitoringu. Jej nadrzędnym zadaniem – poza zbiera­niem danych telemetrycznych z obserwowanych komponentów – jest zrozu­mienie i analizowanie zależności między tymi danymi i ich źródłami. Zależności te mają kluczowe znaczenie zarówno w kontekście prac mających na celu zapewnienie jak największej sprawności infrastruktury IT, jak i w procesie analizy skali zagrożeń.

Platforma Dynatrace analizuje wykony­wany kod aplikacji na poziomie każdej transakcji. Widzimy więc dokładnie rze­czywiste ścieżki komunikacji oraz zakres danych, do których poszczególne kom­ponenty środowiska mają dostęp. Taka wiedza jest ogromnym ułatwieniem dla zespołów odpowiedzialnych za bezpie­czeństwo.

Czy oprogramowanie Dynatrace po­zwala także na wykrywanie zagro­żeń?

Tak, choć jest to szerszy temat. Zacznijmy od najprostszego przypadku. Dynatrace jako rozwiązanie agentowe analizuje kod uruchamiany w poszczególnych aplika­cjach. Mogą to być samodzielne aplikacje, ale także mikroserwisy, aplikacje działające w kontenerach, w chmurze prywatnej czy publicznej. Mogą być to również aplikacje typu serverless – jak Azure Functions czy AWS Lambda. Jed­nocześnie, oprogramowanie Dynatrace bazuje na algorytmach AI, wykrywających anomalie w stosunku do tego, co zostało sklasyfikowane jako normalne zachowa­nie danego systemu. Może więc – w pełni automatycznie – wykrywać profile zacho­wania aplikacji odbiegające od normy, np. zwiększony poziom ruchu, błędnych logowań lub błędów biznesowych.

To właśnie dzięki takim obserwacjom można w bardzo łatwy sposób wykrywać potencjalne zagrożenia czy próby naru­szenia polityk bezpieczeństwa. W jed­nej z organizacji, dzięki tego typu funk­cjonalności, bardzo szybko wykryliśmy próbę skopiowania bazy klientów przez automat przeszukujący w godzinach noc­nych zbiory danych przy użyciu losowo ge­nerowanych identyfikatorów. Tego typu możliwości, choć być może nie są wprost związane z bezpieczeństwem, Dynatra­ce zapewnia w bardzo naturalny sposób. Przykładem dedykowanej funkcjonalności bezpieczeństwa w ramach tej platformy jest wykorzystanie agenta analizującego uruchamiany kod aplikacji do wykrywa­nia podatności potencjalnie w tym kodzie istniejących.

Czy chodzi o tego samego agenta Dynatrace, który zbiera dane tele­metryczne?

Dokładnie tego samego oraz stojącą za nim sztuczną inteligencję. Agent ma do­stęp do załadowanych bibliotek, analizuje kod wykonywanych transakcji. Nie trzeba zatem na serwerach instalować dodatko­wego narzędzia. Nie trzeba też wykony­wać żadnych dodatkowych skanów. Dy­natrace synchronizuje się z publicznymi bazami podatności – m.in. SNYK i NVD – i sprawdza uruchomiony kod aplikacji pod kątem znanych luk. Co ważne, takie rozwiązanie działa w trybie ciągłym i nie powoduje żadnego narzutu wydajnościo­wego na obserwowaną aplikację.

Równolegle, wszystkie gromadzone dane są interpretowane w czasie rzeczywistym – sztuczna inteligencja tworzy model ana­lizowanych aplikacji oraz mapę powiązań między komponentami na poziomie fi­zycznym i logicznym. Poza tym na bazie przyjętego modelu ocenia poziom ryzyka – rozumie bowiem zależności oraz kon­tekst zbieranych danych. W przypadku wykrytych podatności Dynatrace – oprócz wskazania ich istnienia – dodatkowo ana­lizuje czy dany komponent jest dostępny z sieci publicznej oraz czy ma dostęp do baz danych. Dostarcza więc komplet in­formacji o tym, jakie usługi lub bazy da­nych mogą być zagrożone wskutek odna­lezionej w kodzie aplikacji podatności.

Jak dużym ułatwieniem dla zespo­łów odpowiedzialnych za bezpie­czeństwo IT jest tego rodzaju funk­cjonalność?

Ogromnym! Działy bezpieczeństwa z reguły zasypywane są informacjami o kolejnych incydentach, faktycznych lub potencjalnych. W efekcie, skutecz­ność ich pracy zależy w dużej mierze od umiejętności właściwego definiowania priorytetów i planowania prac, tak aby w pierwszej kolejności rozwiązywać zgło­szenia, które mają naprawdę krytyczne znaczenie. Tymczasem zdecydowana większość informacji o wykrytych po­datnościach to fałszywe alarmy albo po­datności o małym prawdopodobieństwie wykorzystania.

Warto pamiętać, że każda podatność raportowana z publicznej bazy ma oce­nę ryzyka CVSS w skali od 0 do 10, gdzie 10 oznacza maksymalny poziom ryzyka. Jest to metryka przydatna, jednak ode­rwana od kontekstu danej organizacji. Nie znając kontekstu, w którym działa komponent z wykrytą podatnością, nie mamy podstaw, aby określić rzeczywi­sty poziom ryzyka. Każdy alarm musimy analizować z najwyższą uwagą.

W tym kontekście podejście Dynatrace wyróżnia m.in. funkcjonalność automa­tycznej oceny poziomu zagrożenia – bar­dzo trafnej zresztą. Platforma Dynatrace definiuje bowiem własny wskaźnik zwa­ny Davis Security Score, który wyjściowo bazuje na ocenie CVSS, ale zrewidowany pod kątem konfiguracji konkretnego śro­dowiska. Przykładowo, system Dynatrace jest w stanie zmniejszyć ocenę ryzyka, jeśli do komponentu, w którym wykryta została podatność, nie można dostać się z sieci publicznej – czyli potencjalny atak jest mniej prawdopodobny – lub też nie ma on dostępu do bazy danych, zatem ry­zyko kompromitacji danych jest mniejsze.

Ponadto, dla każdej zidentyfikowanej po­datności Platforma Dynatrace dostarcza informację o ewentualnym istnieniu pu­blicznych eksploitów, za pośrednictwem których realizowana jest największa licz­ba ataków. Tego rodzaju selekcja odby­wa się na poziomie każdego komponentu z osobna, co pozwala odpowiednio usta­wić priorytety zadań w przypadku jedno­czesnego wykrycia podatności na wielu komponentach – tak jak miało to miejsce w przypadku luki Log4Shell.

Z jakimi nakładami pracy wiąże się konfiguracja funkcji Application Se­curity w Dynatrace?

Nie trzeba nic konfigurować. Wykorzy­stywana jest tu wyłącznie natywna funk­cjonalność agenta i samej platformy. Jedyne, co trzeba zrobić, to zdecydować czy alarmy bezpieczeństwa chcemy obserwować w samym Dynatrace, czy zin­tegrować je z centralną konsolą SOC. Tego typu funkcjonalność jest trudna do przecenienia – zdolność do wykrywania podatności w stosowanych bibliotekach w czasie prawie rzeczywistym, bez ob­ciążania systemu monitorowanego, bez żadnej konfiguracji jest dzisiaj niezbędna.

Funkcjonalność Application Security diametralnie zmienia możliwości wy­krywania podatności. Dotychczas stan­dardową praktyką dla większości – tych bardziej świadomych – organizacji było wykonywanie skanów pod kątem po­datności w środowiskach produkcyjnych regularnie, ale rzadko – na przykład raz na tydzień. Takie skany są kosztowne, a jednocześnie zwykle generują dużą liczbę fałszywych alarmów. Z kolei ich niewystarczająca częstotliwość sprawia, że luka w publicznie dostępnej usłudze może być otwarta przez kilka dni.

Dynatrace eliminuje takie ryzyko w spo­sób automatyczny. Automatyzacja wy­krywania podatności jest szczególnie istotna w projektach transformacji cy­frowej zakładających modernizację apli­kacji za sprawą mikroserwisów i chmury obliczeniowej, które znacząco zwiększają dynamikę zmian i skomplikowanie po­wiązań w aplikacjach. Dynatrace swoim rozwiązaniem wychodzi naprzeciw tym wyzwaniom dzięki zastosowaniu auto­matyzacji i AI.

Wykrywanie podatności to jednak nie wszystko…

Faktycznie. Prawdziwa siła Platformy Dynatrace objawia się w funkcjonalno­ści analizy własnego kodu pod kątem możliwości przeprowadzenia ataków. Innymi słowy, zapewnia ona możliwość oceny czy tworzony w organizacji kod nie zawiera błędów, które mogą być wykorzystane przez cyberprzestępców. Jest to o tyle istotne, że kod aplikacji jest dziś tworzony w ogromnym tempie. Jeśli zestawimy ten fakt z problematyką luki kompetencyjnej i koniecznością zatrud­niania początkujących deweloperów, to błędy w kodzie oprogramowania stają się wręcz naturalne.

Takie błędy, nawet najmniej oczywiste, potencjalnie mogą generować nowe po­datności. Dlatego, analizując kod wyko­nywany na poziomie każdej transakcji, agent Dynatrace jest w stanie stwierdzić, czy jest on w pełni bezpieczny, czy może zostać wykorzystany na potrzeby ataku. Oczywiście, analogicznie, jak w przypad­ku wykrywania podatności bibliotek, au­tomatycznie wykonywana jest też analiza ryzyka, ekspozycji na atak i naruszenia bezpieczeństwa danych.

Ponadto, taka analiza dostarcza konkret­nych informacji o typie każdej podatności, stwierdzając, czy pozwala ona na prze­prowadzenie ataku typu SQL Injection, Command Injection czy Improper Input Validation. Programista otrzymuje więc kompletną informację na czym polega problem wraz ze wskazaniem miejsca w kodzie, w którym taka podatność wy­stępuje – nie zostaje mu nic innego jak rozpocząć naprawę.

A co w sytuacji, kiedy taka podatność zostanie wykorzystana do przeprowa­dzenia ataku jeszcze zanim zostanie naprawiona?

Istnieją dwa scenariusze. W pierwszym z nich agent Dynatrace wykryje atak, za­raportuje użycie luki i wskaże całą ścież­kę ataku, włącznie z informacjami o tym, do jakich danych próbowano się dostać. Drugi scenariusz działania jest szerszy. Zakłada bowiem, że po wykryciu próby ataku agent Dynatrace zablokuje kod wy­konywanej transakcji – tylko tej konkret­nej, dzięki czemu cała aplikacja pozostaje w pełni funkcjonalna. Decyzja o tym, w ja­kim trybie pracuje agent, to jedyna istotna konfiguracja, którą trzeba wykonać.

W jaki sposób rozwiązania Dynatrace ułatwiają prowadzenie takich analiz?

Scenariusz przeszukiwania olbrzymich ilości danych w kontekście bezpieczeń­stwa był impulsem do odejścia od trady­cyjnych systemów indeksujących logi. Na potrzeby Dynatrace stworzono autorską koncepcję „Grail Data Lakehouse”, która nie wymaga m.in. indeksowania i umożli­wia budowanie wynikowej struktury da­nych w locie. Mechanizmy równoległego przetwarzania pozwalają na natychmia­stowy dostęp do danych historycznych, tak samo jak do danych bieżących. Dzięki temu zyskujemy dowolność przy robieniu analizy typu post mortem, a dział bezpie­czeństwa może z łatwością poszukiwać nieprzewidzianych wcześniej zależności.

Mówiliśmy o bezpieczeństwie aplikacji w środowiskach produkcyjnych, a co z ochroną środowisk przedprodukcyj­nych, typowych dla świata DevSecOps?

DevSecOps, podobnie jak DevOps, ba­zuje na automatyzacji i możliwości szyb­kiego dostępu do wskaźników pozwala­jących na ocenę jakości dostarczanego oprogramowania. Dostępną w platfor­mie Dynatrace funkcjonalność Appli­cation Security można z powodzeniem wykorzystać do automatycznej oceny wydań pod kątem braku istotnych po­datności i na podstawie dostarczonych danych np. wstrzymać promocję kon­kretnego wydania aplikacji do kolejnych środowisk.

Czy zautomatyzować można także kwestie, takiej jak weryfikacja konfi­guracji aplikacji pod kątem zgodności z obowiązującymi w organizacji poli­tykami?

Oczywiście! Tego typu potrzebom świet­nie odpowiada rozwiązanie Sysdig – de­dykowane narzędzie, które rekomendu­jemy w projektach chmurowych, zarówno w obszarze chmury prywatnej, jak i chmu­ry publicznej. Jesteśmy bowiem w stanie włączyć Sysdig w proces tworzenia infra­struktury w modelu GitOps – Infrastruc­ture as Code, a rozwiązanie to automa­tycznie zidentyfikuje potencjalne ryzyka i niezgodności z politykami w szablonach konfiguracji oraz pozwoli zablokować ich wykorzystanie. Podobnie w przypadku obrazów maszyn.

W efekcie, Sysdig zapobiega uruchomie­niu aplikacji, która nie spełnia standardów bezpieczeństwa. W ramach projektów, które realizujemy przy użyciu Sysdig, je­steśmy w stanie sprawdzić zgodność konfiguracji z takimi standardami, jak CIS benchmarks, NIST 800-53, SOC2 czy PCI­-DSS. Zapewniamy poświadczenia, które mogą być wykorzystane do wewnętrznych i zewnętrznych audytów.

Co więcej, właśnie Sysdig pomaga w nada­waniu uprawnień minimalnych, sugerując odpowiednie zasady, tak aby eliminować przypadki przydzielania nadmiarowych przywilejów. Jest to o tyle ważne, że struk­tura uprawnień w środowiskach chmuro­wych jest bardzo granularna, skompliko­wana i stale się rozrasta.

Czy zapewnienie bezpieczeństwa środowisk aplikacyjnych opartych na zasobach chmurowych wymaga zupeł­nie innego rozłożenia ciężaru działań w obszarze bezpieczeństwa IT?

Zdecydowanie tak. Nie ma przypadku w tym, że kładziemy dzisiaj nacisk na bezpieczeństwo samej aplikacji i kon­kretnych zasobów chmurowych. Naj­większy wpływ mamy bowiem na to, co uruchamiamy i na to, gdzie uruchamiamy. Dobierając odpowiednie techniki i narzę­dzia, a także włączając bezpieczeństwo w procesy DevOps, jesteśmy w stanie stworzyć rozwiązania, które w sposób w pełni zautomatyzowany pozwolą na zapewnienie bezpieczeństwa opartego na warstwie aplikacji i infrastruktury. My­ślę, że w tym kontekście oferta Omnilogy jest naprawdę unikalna. Jesteśmy blisko procesów zagwarantowania niezawod­ności, a nie da się zapewnić niezawodno­ści bez bezpieczeństwa aplikacji. Znamy się na tym, choć – przyznaję – proponu­jemy naturalne, ale ciągle nieoczywiste podejście.