Jeff Williams, Założyciel OWASP i Założyciel & CTO Contrast Security – Wywiad

Jeff Williams, Założyciel OWASP i Założyciel & CTO Contrast Security, jest powszechnie uważany za jedną z najbardziej wpływowych postaci w dzisiejszej bezpieczeństwie aplikacji. Przez kilka ostatnich dekad pomógł kształtować, jak organizacje podchodzą do bezpiecznego rozwoju oprogramowania, zarządzania lukami w zabezpieczeniach i ochrony aplikacji w czasie wykonywania. Williams odegrał centralną rolę w budowaniu OWASP z małej inicjatywy wolontariackiej w uznane na całym świecie organizację non-profit, przyczyniając się do przełomowych projektów, takich jak OWASP Top Ten, WebGoat, ESAPI, ASVS i XSS Prevention Cheat Sheet. Przed założeniem Contrast Security w 2014 roku założył także Aspect Security, jedną z pierwszych firm poświęconych wyłącznie konsultacji z zakresu bezpieczeństwa aplikacji, szkoleniom, testom penetracyjnym i bezpiecznym praktykom rozwoju dla organizacji korporacyjnych.

OWASP to organizacja non-profit zajmująca się poprawą bezpieczeństwa oprogramowania za pomocą projektów open-source, globalnej współpracy społeczności, edukacji i standardów branżowych. Założona w 2001 roku, organizacja stała się jedną z najważniejszych władz w dziedzinie bezpieczeństwa aplikacji, z setkami lokalnych oddziałów, tysiącami współtwórców i powszechnie przyjętymi zasobami wykorzystywanymi przez deweloperów, specjalistów ds. bezpieczeństwa, przedsiębiorstwa i rządy na całym świecie. OWASP jest najlepiej znany z projektów, takich jak OWASP Top Ten, który identyfikuje najbardziej krytyczne ryzyka związane z bezpieczeństwem aplikacji internetowych, obok licznych ram bezpieczeństwa, narzędzi testowych, projektów dokumentacji i inicjatyw szkoleniowych. Organizacja działa z filozofią neutralności dostawców, czyniąc swoje zasoby edukacyjne i wytyczne bezpieczeństwa swobodnie dostępnymi dla globalnej społeczności technologicznej.

Contrast Security to firma zajmująca się bezpieczeństwem aplikacji, skupiająca się na ochronie oprogramowania z poziomu samej aplikacji, a nie wyłącznie polegając na zewnętrznych narzędziach skanowania. Platforma firmy wykorzystuje technologię instrumentacji w czasie wykonywania, aby zapewnić rzeczywiste widoczność luk w zabezpieczeniach, ataków, interfejsów API, zależności open-source i zachowania aplikacji w środowiskach developerskich i produkcyjnych. Oferta firmy obejmuje obszary, takie jak interaktywne testy bezpieczeństwa aplikacji (IAST), wykrywanie i reagowanie na aplikacje (ADR), samozabezpieczenie aplikacji w czasie wykonywania (RASP) i analizę składu oprogramowania. Contrast Security pozycjonuje się wokół integracji bezpieczeństwa bezpośrednio w nowoczesne procesy DevSecOps, umożliwiając deweloperom, zespołom AppSec i zespołom operacyjnym bezpieczeństwa identyfikację i likwidację luk w zabezpieczeniach szybciej, jednocześnie utrzymując szybkie cykle dostarczania oprogramowania.

Po tym, jak pomógł ukształtować nowoczesne bezpieczeństwo aplikacji poprzez swoją pracę w Open Web Application Security Project (OWASP), jaka luka w branży skłoniła go do założenia Contrast Security, i jak ta pierwotna teza się utrzymała, gdy wyzwania bezpieczeństwa ewoluowały?

Branża tonęła w teoretycznych wynikach statycznych i nie była w stanie skupić się na problemach, które naprawdę mają znaczenie. Zespoły bezpieczeństwa miały skanery generujące ogromne zaległości bez wiedzy, które luki w zabezpieczeniach są osiągalne, wykorzystywane lub atakowane w produkcji. Założyliśmy Contrast na prostym pomysle: decyzje bezpieczeństwa powinny pochodzić z bezpośredniej obserwacji działających aplikacji, a nie z zewnątrz.

Ostatecznie mam nadzieję, że branża dojdzie do punktu, w którym przestaniemy kręcić się w kółko, szukając problemów, naprawiając je i znajdując kolejne na zawsze. Mam nadzieję, że zaczniemy tworzyć oprogramowanie, które ma silną architekturę bezpieczeństwa i prawdziwy argument, że ma odpowiednie mechanizmy obronne przed oczekiwanymi zagrożeniami. Połączenie bezpieczeństwa w czasie wykonywania i sztucznej inteligencji ma potencjał, ale jesteśmy od tego jeszcze daleko.

Opisał on pojawienie się „luk w zabezpieczeniach na poziomie mitologii”. Co definiuje tę nową klasę ryzyka, i dlaczego są one tak trudne do wykrycia przez konwencjonalne narzędzia bezpieczeństwa?

Luki w zabezpieczeniach na poziomie mitologii to błędy, które wynikają z złożoności nowoczesnych stosów oprogramowania. Interakcja między zachowaniem frameworka, zależnościami i wzorcami architektonicznymi jest tak złożona, że deweloperzy często nie w pełni ją rozumieją. Konwencjonalne narzędzia nadal są zoptymalizowane dla wzorców i zdarzeń obserwowalnych. Luki w zabezpieczeniach na poziomie mitologii często wymagają zrozumienia zachowania aplikacji, przepływu wykonania i kontekstu w czasie wykonywania na znacznie głębszym poziomie.

Dlaczego całe kategorie luk w zabezpieczeniach nie generują alertów w nowoczesnych środowiskach operacji bezpieczeństwa (SOC), i co to ujawnia o tym, jak zespoły bezpieczeństwa obecnie mierzą ryzyko?

Większość SOC jest zbudowana wokół zdarzeń obserwowalnych: logów, sygnatur, ruchu sieciowego, aktywności punktu końcowego. Ale wiele ataków na warstwie aplikacji nie produkuje żadnych znaczących sygnałów w tych systemach. Deweloper nie wiedział, że istnieje luka w zabezpieczeniach, i nie dodał żadnego logowania, które ujawniłoby eksploatację. Więc większość eksploatacji aplikacji jest całkowicie niewidoczna w logach. Zespoły SOC mogą reagować tylko na to, co widzą. Dlatego gdy warstwa aplikacji i API staje się coraz bardziej istotna, jest krytyczne, aby zapewnić, że wyposażyliśmy ją w czujniki bezpieczeństwa, które mogą wykryć i zgłosić nietypowe zachowanie.

Nowoczesne architektury aplikacji, takie jak mikrousługi, API i systemy serwerless, ewoluowały gwałtownie. Gdzie te architektury wyprzedzają obecne podejścia do wykrywania bezpieczeństwa?

Te architektury zniszczyły stary model obwodu. Żądania teraz przechodzą przez dziesiątki usług, efemeryczne funkcje, API, kolejkę i zależności od stron trzecich, zanim zostanie wykonana transakcja. Większość systemów wykrywania nadal widzi fragmenty zamiast pełnej ścieżki wykonania. Mogą one inspekcjonować pakiety lub logi, ale nie mogą zrozumieć intencji, przepływu danych ani czy niebezpieczny kod został rzeczywiście wykonany. Bezpieczeństwo dotyczy kontekstu, więc musimy zbudować model, cyfrową kopię naszej infrastruktury aplikacji, który pozwoli nam (lub agentom AI) rozważać to, co widzimy.

OWASP Top Ten nadal podkreśla problemy, takie jak niebezpieczna konstrukcja i podatne składniki. Dlaczego te ryzyka się utrzymują, pomimo powszechnej świadomości i narzędzi?

Świadomość nie naprawia zachęt ani złożoności. Większość organizacji nadal mierzy sukces liczbą skanów, zamknięciem biletów lub listami kontrolnymi zgodności, a nie rzeczywistą redukcją narażenia.

Jednocześnie łańcuchy dostaw oprogramowania eksplodowały pod względem wielkości. Deweloperzy montują aplikacje z tysiąca składników, których nie napisali i których z pewnością nie oceniali pod kątem bezpieczeństwa. Zespoły bezpieczeństwa są przytłoczone, próbując rozwiązać teoretyczne ryzyka i nie mogą się skoncentrować na 1-2%, które naprawdę mają znaczenie. Bez dowodów z czasu wykonywania, priorytetyzacja się załamuje. A z pojawieniem się potężnych modeli AI i harnessów, objętość rośnie wykładniczo.

Jak organizacje powinny przemyśleć swoją zależność od logów i alertów, gdy niektóre z najbardziej krytycznych luk w zabezpieczeniach nie pozostawiają żadnych obserwowalnych sygnałów?

Logi są dowodem tego, co aplikacje wybierają, aby zgłosić, a nie koniecznie dowodem tego, co się naprawdę wydarzyło. To niebezpieczne rozróżnienie. Organizacje muszą przesunąć się od pośredniej obserwacji do bezpośredniej obserwacji. Zamiast liczyć na to, że eksploatacja utworzy wykrywalny artefakt, systemy bezpieczeństwa powinny identyfikować podatne zachowania i zachowania eksploatacji w czasie wykonywania. Jeśli niebezpieczny kod zostanie wykonany, system powinien o tym wiedzieć natychmiast – niezależnie od tego, czy istnieje wpis w logu.

Opowiedział o widoczności w czasie wykonywania jako o rozwiązaniu. Co to jest prawdziwa widoczność w czasie wykonywania w praktyce, i jak to zmienia sposób, w jaki zespoły bezpieczeństwa działają na co dzień?

Prawdziwa widoczność w czasie wykonywania oznacza zrozumienie, co aplikacja naprawdę robi w produkcji: które trasy są narażone, które biblioteki są aktywne, gdzie płyną dane wrażliwe, jaki kod został wykonany i czy atak dotarł do podatnej funkcjonalności. Operacyjnie zmienia bezpieczeństwo z reaktywnej gry w polowanie w precyzyjną dyscyplinę. Zespoły przestają ścigać ogromne zaległości luk w zabezpieczeniach i zaczynają się koncentrować na małym procentzie narażenia, które jest osiągalne, krytyczne i aktywnie atakowane. To dramatycznie poprawia stosunek sygnału do szumu i szybkość reakcji. Średnio tylko 38% bibliotek open-source pakowanych w aplikację jest rzeczywiście ładowanych do pamięci i wykonywanych. I nie cały kod w tym podzbiorze jest używany. Więc jedna prosta rzecz, jaką umożliwia bezpieczeństwo w czasie wykonywania, to koncentracja na kodzie, który naprawdę działa, a nie na wszystkich nieużywanych bibliotekach i funkcjach, które idą wraz z aplikacją.

Jak porównuje się bezpieczeństwo oparte na instrumentacji z tradycyjnymi podejściami, takimi jak SAST, DAST lub monitorowanie obwodu, pod względem skuteczności i skalowalności?

Tradycyjne narzędzia inferują ryzyko z zewnątrz. Instrumentacja obserwuje rzeczywistość, obserwując rzeczywisty kod podczas jego wykonywania. Instrumentacja może zobaczyć rzeczywiste ścieżki wykonania, zachowanie frameworka, kontekst uwierzytelniania, przepływ danych i powodzenie eksploatacji w czasie rzeczywistym. Eliminuje ogromne kategorie fałszywych pozytywów i ujawnia luki w zabezpieczeniach, których narzędzia obwodu całkowicie pomijają.
W skali ta precyzja staje się krytyczna. Organizacje nie mogą już ręcznie rozwiązywać milionów teoretycznych wyników. Dowody z czasu wykonywania stają się jedynym zrównoważonym filtrem. Czas wykonywania działa w czasie rzeczywistym, więc jest lepszym dopasowaniem do procesów developerskich i CI/CD niż skanowanie i rozwiązywanie. I czas wykonywania jest ciągły, więc nie jesteśmy ograniczeni do punktowego widoku bezpieczeństwa.

Jak systemy AI i autonomiczne aplikacje stają się bardziej powszechne, czy te niewidoczne luki w zabezpieczeniach stają się bardziej niebezpieczne, i jak zespoły powinny się przygotować?

AI sprawia, że niewidoczne luki w zabezpieczeniach stają się bardziej niebezpieczne, ponieważ przyspiesza obie strony problemu. Deweloperzy generują oprogramowanie szybciej, a atakujący znajdują i eksploatują słabości szybciej. Ale większość programów bezpieczeństwa nadal opiera się na procesach z udziałem człowieka, które nie mogą działać z prędkością AI. Zespoły powinny przygotować się na dwa sposoby. Po pierwsze, zbudować silniejsze mechanizmy obronne w czasie wykonywania, które mogą wykryć, zablokować i ograniczyć ataki w produkcji, podczas gdy luki w zabezpieczeniach są naprawiane. To daje organizacjom osłonę. Po drugie, wykorzystać AI i automatykę, aby napisać bardziej bezpieczny kod od samego początku – z lepszym projektem, testowaniem, przeglądem i weryfikacją. W przeciwnym razie tworzymy ryzyko szybciej, niż możemy je zarządzać.

Jakby doradzał nowoczesnemu liderowi Security Operations Center (SOC) dzisiaj, jakie są pierwsze konkretnie kroki, które powinien podjąć, aby zamknąć tę lukę widoczności, zanim doprowadzi do dużego naruszenia?

Po pierwsze, zaakceptuj, że same dane telemetryczne z obwodu są niewystarczające dla nowoczesnego bezpieczeństwa aplikacji. W rzeczywistości jest to niemożliwe, aby zobaczyć lub zatrzymać wiele ataków na aplikacje i API na obwodzie. SOC potrzebuje widoczności wewnątrz działających aplikacji, a nie tylko infrastruktury, która je hostuje. Po drugie, priorytetem powinny być dowody z czasu wykonywania, a nie teoretyczne wyniki. Skoncentruj się na lukach w zabezpieczeniach, które są w aktywnym kodzie, zidentyfikuj aktywne ścieżki ataków i narażone usługi, które są naprawdę wykonywane w produkcji. Wreszcie, zjednocz aplikację bezpieczeństwa i inżynierię wykrywania. Przyszłe SOC nie może traktować aplikacji jako nieprzezroczystych czarnych skrzynek. Aplikacje są teraz podstawową powierzchnią ataku i potrzebują widoczności pierwszej klasy w czasie wykonywania.

Dziękuję za wspaniały wywiad, czytelnicy, którzy chcą dowiedzieć się więcej, powinni odwiedzić OWASP lub Contrast Security.