Simon Edwards, CEO i założyciel SE Labs – seria wywiadów

Simon Edwards, CEO i założyciel SE Labs, jest ekspertem ds. testowania bezpieczeństwa cybernetycznego z ponad trzydziestoletnim doświadczeniem obejmującym badania bezpieczeństwa, ocenę produktów, dziennikarstwo techniczne i standardy branżowe. Przed założeniem SE Labs w 2015 r. Edwards prowadził Dennis Technology Labs, gdzie kierował inicjatywami testowania bezpieczeństwa, a wcześniej spędził wiele lat jako dziennikarz i redaktor technologiczny. Pełnił także wysokie stanowiska kierownicze w Anti-Malware Testing Standards Organization (AMTSO), w tym funkcje przewodniczącego, dyrektora i współprzewodniczącego. Edwards testuje produkty bezpieczeństwa od połowy lat 90. i był pionierem wczesnych, rzeczywistych metod testowania antymalware, mających na celu ocenę, jak technologie zabezpieczające radzą sobie w pełnych, dostarczanych przez internet atakach, a nie w izolowanych próbkach złośliwego oprogramowania.

SE Labs jest niezależną firmą zajmującą się testowaniem i doradztwem w dziedzinie cyberbezpieczeństwa, która ocenia, jak technologie zabezpieczające radzą sobie w realistycznych atakach. Jej badacze odtwarzają techniki atakującego na całym łańcuchu ataku, aby ocenić produkty, w tym ochronę punktów końcowych, Endpoint Detection and Response (EDR), usługi bezpieczeństwa chmury, zapory sieciowe, zabezpieczenia poczty elektronicznej oraz technologie wykrywania w sieci. Oprócz publicznych testów porównawczych, SE Labs oferuje certyfikację, zaawansowane testy bezpieczeństwa, walidację produktów oraz usługi doradcze dla przedsiębiorstw i dostawców cyberbezpieczeństwa. Firma publikuje swoje metodologie testowe i ramy emulacji zagrożeń oraz jest certyfikowana zgodnie z ISO/IEC 27001:2022 i BS EN ISO 9001:2015 w zakresie testowania produktów bezpieczeństwa IT.

Twoja kariera obejmuje ponad trzy dekady w dziennikarstwie technologicznym, konsultingu bezpieczeństwa, niezależnym testowaniu oraz rolach przywódczych w Anti-Malware Testing Standards Organization (AMTSO). Jak to doświadczenie ukształtowało sposób, w jaki odróżniasz prawdziwe postępy w cyberbezpieczeństwie opartym na AI od technologii, które głównie są pozycjonowane jako „AI” w celach marketingowych?

Dziennikarstwo nauczyło mnie kwestionować twierdzenia, podczas gdy niezależne testowanie pokazało, że jedyną wiarygodną odpowiedzią są dowody. Firmy z branży cyberbezpieczeństwa od wielu lat wykorzystują uczenie maszynowe i automatyczne podejmowanie decyzji, więc dodanie „AI” do nazwy produktu niekoniecznie oznacza postęp techniczny.

Trzy podstawowe kwestie do rozważenia: Co faktycznie robi AI? Jakie mierzalne rezultaty bezpieczeństwa poprawia? Czy niezależny tester może odtworzyć tę poprawę?

Jeśli odpowiedź brzmi po prostu, że produkt analizuje dużą ilość danych lub automatyzuje istniejący proces, etykieta AI może być bardziej kwestią pozycjonowania niż rzeczywistej zdolności.

Prawdziwy postęp radzi sobie dobrze w obliczu nieznanych lub zupełnie nowych ataków, poprawia ochronę lub reakcję, zmniejsza obciążenie analityków i robi to bez wprowadzania nieakceptowalnych ryzyk. Wszystko inne to albo brak postępu, albo regres!

„AI-driven” stało się powszechnym twierdzeniem wśród produktów cyberbezpieczeństwa. Jakie są najważniejsze możliwości, które powinny być niezależnie przetestowane, zanim organizacja zaakceptuje, że platforma bezpieczeństwa oparta na AI rzeczywiście dostarcza to, co obiecuje dostawca?

Nie zaczynałbym od testowania, czy produkt zawiera AI. Zaczynałbym od testowania twierdzeń bezpieczeństwa, które są wobec niego formułowane. Nie zależy mi tak bardzo na tym, jak produkt działa, o ile działa. To jest dokładny cel programu testowego PIVOT, który obecnie zyskuje dużą popularność w branży.

Testowanie w ten sposób oznacza wystawienie produktu na pełne ataki i zmierzenie, jak na nie reaguje. Powinien prawdopodobnie wykrywać aktywność, a potem może zapobiec dalszemu postępowi ataku. To zależy od tego, jak produkt jest zbudowany i skonfigurowany, oraz od twierdzeń marketingowych, które prezentuje jego dostawca.

Musimy również zbadać historię dochodzeniową przedstawioną klientowi. Czy system zrozumiał, co się stało, połączył odpowiednie zdarzenia i uczynił dowody widocznymi dla osoby, która musi podjąć działanie?

Test powinien obejmować nieznane warianty, realistyczne konfiguracje klienta oraz normalną działalność biznesową. Musi także mierzyć fałszywe alarmy, zużycie zasobów oraz działania, które mogą być potencjalnie niebezpieczne. Jeśli system jest autonomiczny, musimy wiedzieć, kiedy działa, dlaczego działa, jakich uprawnień używa i czy jego decyzje można cofnąć.

Widzieliśmy kilka historii w mediach o tym, że zabezpieczenia AI wymykają się spod kontroli i przekraczają swoje granice, a nawet prawo. Ważne pytanie nie brzmi, czy platforma wydaje się inteligentna, lecz czy dostarcza konsekwentnie lepsze i bezpieczniejsze wyniki w zakresie bezpieczeństwa.

Autonomiczne agenty AI mogą potencjalnie przeprowadzać rozpoznanie, eksploatację, ruch lateralny i inne etapy ataku znacznie szybciej niż ludzki atakujący. Jak testowanie cyberbezpieczeństwa powinno się zmienić, gdy ataki zaczynają działać z prędkością maszyny?

Jednostka testowania musi przejść od pojedynczej techniki do całej kampanii działającej pod presją czasu. Mam na myśli to, że zamiast wypróbowywać różne sposoby ataku przez poranek lub tydzień, testowanie określonych środków bezpieczeństwa musi odbywać się szybko. W przeciwnym razie nie jest to realistyczne, a realizm jest bardzo ważny.

Tradycyjne testy mogą pozostawiać wygodne przerwy pomiędzy etapami, aby każde zdarzenie mogło być badane oddzielnie. Autonomiczny atakujący może skompresować rozpoznanie, eksploatację i ruch lateralny do znacznie krótszego okresu. Może to ujawnić słabości, które nie są widoczne w wolniejszych testach, w tym opóźnienia w telemetrii, przeciążone systemy oraz działania obronne, które pojawiają się dopiero po osiągnięciu przez atakowanego celu.

Aby podać bardzo prosty przykład, jeśli włamiemy się do komputera Mac, pobierzemy wszystkie jego pliki i ukradniemy hasła kont, nie będzie to zbyt przydatne, jeśli program antywirusowy wyświetli ostrzeżenie dopiero dzień później.

Testowanie reakcji bezpieczeństwa na atakujących AI wymaga więc instrumentacji o wysokiej rozdzielczości oraz precyzyjnego pomiaru opóźnień wykrywania i reakcji. Powinno badać, czy wydajność pogarsza się wraz ze wzrostem wolumenu i szybkości działań oraz czy obrona może przerwać atak bez oczekiwania na decyzję człowieka na każdym etapie.

Atak może również dostosowywać się do tego, co odkryje. Testy muszą to odzwierciedlać, zachowując jednocześnie prawdziwość danych, dowody i możliwość odtworzenia. Szybkość maszyn nie powinna oznaczać porzucenia kontrolowanej metodologii. Musimy nadal projektować kontrolowane testy, które mogą działać i mierzyć zdarzenia w takiej samej prędkości jak oceniane systemy.

SE Labs wykorzystuje realistyczne scenariusze ataków oparte na taktykach i technikach grup zagrożeń, takich jak Scattered Spider. Jak odtworzyć tych przeciwników w kontrolowanym środowisku, zapewniając jednocześnie, że test odzwierciedla sposób, w jaki rzeczywisty atak się rozwija, a nie jedynie testuje według z góry określonej listy kontrolnej?

Zaczynamy od celów przeciwnika, znanych zachowań i prawdopodobnych decyzji, zamiast traktować jego techniki jak listę zakupów.

Test podąża za realistycznym łańcuchem ataku, obejmującym rozpoznanie, początkowy dostęp, wykonanie, eskalację przywilejów, działania po przejęciu oraz ruch lateralny. Co ważne, tester może korzystać wyłącznie z informacji faktycznie odkrytych podczas rozpoznania i ataku. Nie przekazujemy atakującemu wiedzy, której nie miałby w rzeczywistym scenariuszu.

Scenariusz jest ograniczony i starannie kontrolowany, ale nie jest jedynie sekwencją z góry ustalonych przycisków. Jeśli jedna ścieżka zostanie zablokowana, atakujący może podjąć wiarygodną alternatywę w ramach zasad testu. To pozwala produktowi bezpieczeństwa wpływać na przebieg scenariusza.

Jednocześnie każda ważna akcja i wynik są rejestrowane, abyśmy mogli wyjaśnić rezultat i uczciwie porównać produkty. Kontrola nie musi oznaczać sztywno scenariuszowego podejścia. Powinna oznaczać bezpieczeństwo, obserwowalność i poparcie dowodami.

Produkty cyberbezpieczeństwa tradycyjnie były oceniane głównie pod kątem ich zdolności do wykrywania zagrożeń. Dlaczego organizacje powinny coraz częściej brać pod uwagę ochronę, izolację i reagowanie na incydenty przy ocenie systemów bezpieczeństwa opartych na AI?

Wykrywanie nie jest tym samym co obrona. Platforma może generować precyzyjne powiadomienie, a jednocześnie pozwalać atakującemu osiągnąć cel. Dlatego program testowy PIVOT obejmuje zarówno wykrywanie, jak i ochronę jako wspólne i oddzielne elementy całościowego testowania.

Wykrywanie w cyberbezpieczeństwie można porównać do kamery CCTV. Powinna zauważyć włamanie i dostarczyć wskazówek, co się stało, ale nie zatrzyma fizycznie intruza. Ochrona w cyberbezpieczeństwie jest znacznie bardziej aktywna. Może wyrzucić lub w inny sposób zneutralizować atakującego, zapobiegając szkodom.

Organizacje muszą wiedzieć, czy produkt zapobiegł początkowej aktywności, przerwał łańcuch ataku, ograniczył ruch lateralny, chronił ważne zasoby i wspierał odzyskiwanie. Jeśli atak się powiedzie, kolejne pytania brzmią, jak szybko został opanowany oraz czy klient otrzymał wystarczająco wiarygodne informacje, aby skutecznie zareagować.

Staje się to szczególnie ważne w przypadku systemów opartych na AI, ponieważ choć mogą one generować bardzo przekonujące podsumowania tego, co się wydarzyło, przekonujące wyjaśnienie nie zastępuje ochrony. Wyjaśnienie musi być poparte dowodami i prowadzić do odpowiedniego działania.

Dlatego mierzymy wykrywanie i ochronę osobno. Badamy także, czy deklarowane wykrycie było rzeczywiście widoczne i użyteczne dla klienta. Ostatecznie wartość systemu bezpieczeństwa polega na zmianie wyniku ataku, a nie jedynie na jego obserwacji.

Gdy platformy bezpieczeństwa wprowadzają autonomiczne agenty zdolne do badania alertów i podejmowania działań naprawczych, w jaki sposób niezależne laboratoria powinny testować cały przepływ pracy człowiek‑AI, a nie oceniać jedynie podstawową technologię wykrywania w izolacji?

Test powinien śledzić cały proces od pierwszej złośliwej aktywności aż do ostatecznego wyniku bezpieczeństwa, którym może być zatrzymanie ataku, jego całkowite powodzenie lub coś pośredniego.

Musimy zbadać, co agent zaobserwował, do czego doszedł, co zalecił lub zrobił, co został pokazany operatorowi i jak operator zareagował (lub jakie opcje mu zaproponowano). Obejmuje to jakość dowodów, klarowność przekazania, wymaganą czas, liczbę interwencji oraz to, czy człowiek mógł zrozumieć, zakwestionować lub odwrócić decyzję agenta.

Różne tryby pracy również mają znaczenie. Agent, który rekomenduje działanie do zatwierdzenia, stwarza inny rodzaj ryzyka niż ten, który może automatycznie izolować systemy, wyłączać konta lub zmieniać kontrolki bezpieczeństwa.

System nie odniósł sukcesu jedynie dlatego, że jego podstawowy detektor zidentyfikował atak. Jeśli tworzy nieczytelny kolejkę, ukrywa ważne dowody, rekomenduje niewłaściwą reakcję lub podejmuje działanie zakłócające, cały przepływ pracy zawiódł. Niezależne testy powinny mierzyć łączną wydajność technologii, jej autonomicznych komponentów oraz osób, które mają z nich korzystać.

Jednym z ryzyk związanych ze standardowymi benchmarkami bezpieczeństwa jest to, że dostawcy mogą optymalizować produkty specjalnie pod kątem testu. Jak niezależne testy mogą pozostać odtwarzalne i uczciwe, a jednocześnie wprowadzić wystarczającą nieprzewidywalność, aby ujawnić, jak produkty radzą sobie z nieznanymi atakami?

Odtwarzalność nie wymaga udostępniania uczestnikom pytań egzaminacyjnych z wyprzedzeniem.

Wiarygodny test powinien opublikować swoją metodologię, środowisko, zasady punktacji, konfigurację produktu oraz wymagania dowodowe. Dostawcy powinni rozumieć zasady i mieć uczciwą szansę zweryfikować, że ich produkty działają prawidłowo. Jednak dokładna kampania ataku, ładunki i niektóre ścieżki ataku powinny pozostać nieznane aż do momentu przeprowadzenia testu.

Na przykład w PIVOT nie ujawniamy, które grupy atakujące zamierzamy odtworzyć, dopóki test nie zostanie zakończony. Prawdziwe cele nie dostają ostrzeżenia przed rozpoczęciem ataku!

Możemy połączyć standardowe rdzenie, które umożliwiają porównania w czasie, z nieznanymi wariantami testującymi ogólne możliwości. Ustalenie bazowego poziomu i ukrytego cichego okresu może pokazać, jak produkt zachowuje się przed atakiem. Następnie konfiguracja powinna być kontrolowana, logi zachowane, a wszelkie roszczenia sprawdzone w oparciu o własne dowody testera.

Sprawiedliwość oznacza stosowanie tych samych zasad i standardów dowodowych wobec każdego uczestnika. Nie oznacza to powtarzania ataku w tak przewidywalny sposób, aby dostawca mógł rozpoznać benchmark zamiast rozpoznać zagrożenie.

Ponadto radykalna przejrzystość pomaga dostawcom odtwarzać ataki, co jest ważne, jeśli chcą naprawić napotkane problemy, takie jak nieudane wykrycie lub ochrona przed zagrożeniem. SE Labs zasadniczo szkoli swoich klientów, gdy napotykają problemy.

Autonomiczne agenty bezpieczeństwa wprowadzają inny rodzaj ryzyka, ponieważ błędna decyzja może wywołać niepotrzebne lub nawet zakłócające działanie naprawcze. Jak testy powinny mierzyć fałszywe alarmy, niepoprawne wnioskowanie i potencjalnie szkodliwe autonomiczne działania obok tradycyjnej dokładności wykrywania?

Tradycyjne testowanie fałszywych alarmów to tylko pierwsza warstwa. W przypadku autonomicznego agenta musimy rozróżnić fałszywe powiadomienie, nieuzasadniony wniosek i nieprawidłowe działanie. Każde z nich ma inny potencjalny wpływ.

Testy powinny wystawiać system na legalną aktywność przypominającą złośliwe zachowanie, a także na niekompletne, niejednoznaczne lub wprowadzające w błąd dowody. Jeśli agent przetwarza niezweryfikowane treści, testy powinny również sprawdzić, czy te treści mogą niewłaściwie wpływać na jego decyzje.

Rozumowanie powinno być oceniane pod kątem tego, czy wniosek jest poparty dostępnymi dowodami, a nie pod kątem tego, jak wiarygodne lub pewne brzmi wyjaśnienie. W przypadku autonomicznych działań powinniśmy mierzyć zakres, proporcjonalność, wykorzystanie uprawnień, kontrolę zatwierdzeń, możliwość audytu i odwracalność.

Ocena musi odzwierciedlać konsekwencje. Niepotrzebny alarm jest uciążliwy; wyłączenie ważnego konta lub izolacja krytycznego systemu może zakłócić działanie organizacji. Użyteczna miara bezpieczeństwa musi więc uwzględniać zarówno częstotliwość błędów, jak i szkody, jakie każdy błąd może spowodować.

Mimo to czasami klient wybiera politykę, która powoduje problemy. Nie jest to koniecznie wina dostawcy zabezpieczeń.

Sztuczna inteligencja generatywna i coraz bardziej zaawansowane modele open‑source obniżają barierę automatyzacji części procesu ataku. Czy spodziewasz się, że AI sprawi, że cyberataki staną się zasadniczo bardziej wyrafinowane, czy większym zagrożeniem jest to, że atakujący będą po prostu mogli działać na znacznie większą skalę i z większą prędkością?

Moim oczekiwaniem jest, że bardziej bezpośrednie niebezpieczeństwo to skala, prędkość i obniżony koszt.

AI może pomagać atakującym w gromadzeniu informacji, personalizacji inżynierii społecznej, modyfikacji kodu i koordynacji elementów kampanii. Niektóre ataki staną się w wyniku tego bardziej wyrafinowane, szczególnie gdy AI pomaga połączyć istniejące techniki lub dostosować je do konkretnego celu. Jednak AI nie eliminuje potrzeby dostępu, poświadczeń, podatnych słabości ani błędów obrońców.

AI nie jest również zbyt dobra w tworzeniu niezawodnych exploitów, co i tak jest trudne nawet dla wykwalifikowanego człowieka. Dlatego, moim mocnym przekonaniem, zmniejsza to prawdopodobieństwo powstania zasadniczo bardziej wyrafinowanych ataków.

Większa zmiana polega na tym, że działania, które wcześniej wymagały czasu, umiejętności lub zespołu ludzi, mogą być podejmowane szybciej i wobec znacznie większej liczby celów. AI może podnieść kompetencje stosunkowo zwykłych atakujących, jednocześnie pozwalając zdolnym atakującym prowadzić więcej operacji równocześnie.

Jest to istotne, nawet jeśli podstawowe techniki ataku nie są rewolucyjne. Niebezpieczeństwo nie polega koniecznie na całkowicie nowej formie cyberataku. Są to znane ataki stające się szybsze, tańsze, bardziej spersonalizowane i znacznie liczniejsze.

W miarę jak defensywne i ofensywne agenty AI stają się bardziej autonomiczne, jak powinno wyglądać wiarygodne środowisko testowania cyberbezpieczeństwa, aby nadążać? Czy w końcu możemy dojść do punktu, w którym produkty bezpieczeństwa będą musiały być nieustannie poddawane wyzwaniom przez adaptacyjne AI‑przeciwniki, zamiast być oceniane głównie w ramach okresowych testów bezpieczeństwa?

Wiarygodne środowisko będzie musiało przypominać działającą organizację, a nie zbiór odizolowanych celów. Powinno obejmować punkty końcowe, systemy tożsamości, pocztę elektroniczną, sieci, usługi chmurowe, realistycznych użytkowników oraz normalną działalność biznesową. Musi także zapewniać pełną instrumentację, aby każda decyzja i konsekwencja mogły zostać odtworzone.

Adaptacyjnym przeciwnikom można przydzielić cele i granice, a następnie pozwolić im wybierać ścieżki w zależności od tego, co odkryją i jak reaguje produkt obronny. Test nadal wymagałby kontrolowanych warunków początkowych, rzetelnego opisu tego, co faktycznie się wydarzyło, oraz możliwości odtworzenia istotnych zdarzeń. Bez tych elementów testowanie adaptacyjne może wyglądać imponująco, ale będzie naukowo słabe.

Spodziewam się, że testowanie stanie się bardziej ciągłe, szczególnie gdy produkty, modele i polityki mogą się często zmieniać. Jednak ciągłe wyzwania powinny uzupełniać, a nie wyeliminować okresowe testy porównawcze. Organizacje potrzebują obu: kontrolowanych benchmarków, takich jak PIVOT, które wspierają rozliczalność i porównania, oraz bieżącej oceny adaptacyjnej, która ujawnia, jak systemy zachowują się w miarę zmiany zagrożeń i samych produktów.

Uważam, że powinniśmy bardziej martwić się faktem, że stosunkowo niewykwalifikowani ludzie mogą włamać się do systemów i sieci, niż robotami tworzącymi kolejną generację technologii cyberataków.

Dziękujemy za wspaniały wywiad, czytelnicy, którzy chcą dowiedzieć się więcej, powinni odwiedzić SE Labs.