Simon Edwards, administrerende direktør og grundlægger af SE Labs – Interviewserie

Simon Edwards, administrerende direktør og grundlægger af SE Labs, er en ekspert i cybersikkerhedstestning med mere end tre årtier erfaring inden for sikkerhedsforskning, produktvurdering, teknisk journalistik og branchestandarder. Før han grundlagde SE Labs i 2015, ledede Edwards Dennis Technology Labs, hvor han stod i spidsen for sikkerhedstestinitiativer, og tidligere tilbragte han mange år som teknologijournalist og redaktør. Han har også haft ledende stillinger i Anti-Malware Testing Standards Organization (AMTSO), herunder formand, direktør og medformand. Edwards har testet sikkerhedsprodukter siden midten af 1990’erne og var pioner inden for tidlige virkelige anti-malware testmetoder, der er designet til at evaluere, hvordan sikkerhedsteknologier klarer sig mod komplette, internetleverede angreb i stedet for isolerede malware‑prøver.

SE Labs er en uafhængig cybersikkerhedstest‑ og rådgivningsvirksomhed, der evaluerer, hvordan sikkerhedsteknologier klarer sig mod realistiske angreb. Dets forskere gengiver angriberteknikker gennem hele angrebskæden for at vurdere produkter, herunder endpoint‑beskyttelse, Endpoint Detection and Response (EDR), cloud‑sikkerhedstjenester, firewalls, e‑mail‑sikkerhed og netværksdetekteringsteknologier. Ud over offentlige komparative tests leverer SE Labs certificering, avanceret sikkerhedstest, produktvalidering og rådgivning til virksomheder og cybersikkerhedsleverandører. Virksomheden offentliggør sine testmetoder og trusselsimuleringrammer og er certificeret i henhold til ISO/IEC 27001:2022 og BS EN ISO 9001:2015 for levering af IT‑sikkerhedsproduktests.

Din karriere spænder over mere end tre årtier inden for teknologijournalistik, sikkerhedsrådgivning, uafhængig testning og ledelsesroller i Anti-Malware Testing Standards Organization (AMTSO). Hvordan har den erfaring formet den måde, du adskiller reelle fremskridt inden for AI-drevet cybersikkerhed fra teknologier, der primært markedsføres som “AI”?\r\n

Journalistik lærte mig at stille spørgsmål ved påstande, mens uafhængig testning lærte mig, at det eneste pålidelige svar kommer fra beviser. Cybersikkerhedsfirmaer har brugt maskinlæring og automatiseret beslutningstagning i mange år, så det at tilføje “AI” til et produktnavn nødvendigvis ikke repræsenterer en teknisk fremgang.

Tre grundlæggende ting at overveje: Hvad gør AI’en egentlig? Hvilket målbare sikkerhedsresultat forbedrer den? Og kan en uafhængig tester reproducere den forbedring?

Hvis svaret blot er, at produktet analyserer en stor mængde data eller automatiserer en eksisterende proces, kan AI‑betegnelsen mere handle om positionering end om faktiske evner.

En ægte fremskridt klarer sig godt mod ukendte eller helt nye angreb, forbedrer beskyttelse eller respons, mindsker belastningen på analytikere og gør det uden at introducere uacceptable risici. Alt andet er enten ingen forbedring eller et tilbagefald!

“AI-drevet” er blevet et almindeligt påstand i cybersikkerhedsprodukter. Hvad er de vigtigste funktioner, der bør testes uafhængigt, før en organisation accepterer, at en AI‑drevet sikkerhedsplatform faktisk leverer, hvad leverandøren lover?\r\n

Jeg ville ikke starte med at teste, om et produkt indeholder AI. Jeg ville starte med at teste de sikkerhedspåstande, der fremsættes for det. Jeg er ligeglad med, hvordan et produkt fungerer, så længe det fungerer. Dette er det præcise mål med PIVOT-testprogrammet, som i øjeblikket får stor opmærksomhed i branchen.

At teste på denne måde betyder at udsætte produktet for komplette angreb og måle, hvordan det reagerer. Det bør sandsynligvis opdage aktiviteten og derefter måske forhindre angrebet i at fortsætte. Dette afhænger af, hvordan produktet er bygget og konfigureret, samt de markedsføringspåstande, leverandøren fremsætter.

Vi skal også undersøge den efterforskningshistorie, der præsenteres for kunden. Forstod systemet, hvad der skete, forbinde de relevante hændelser og gøre beviserne synlige for den person, der skal handle på dem?

Testen bør inkludere ukendte variationer, realistiske kundekonfigurationer og normal forretningsaktivitet. Den skal også måle falske positiver, ressourcekrav og handlinger, der kan betragtes som potentielt usikre. Hvis systemet er autonomt, skal vi vide, hvornår det handler, hvorfor det handler, hvilke tilladelser det bruger, og om dets beslutninger kan omgøres.

Vi har set nogle få historier i nyhederne om, at AI‑sikkerhed går amok og overskrider sine grænser og potentielt loven. Det vigtige spørgsmål er ikke, om platformen virker intelligent. Det er, om den leverer konsekvent bedre og sikrere sikkerhedsresultater.

Autonome AI‑agenter kan potentielt udføre rekognoscering, udnyttelse, lateral bevægelse og andre faser af et angreb langt hurtigere end en menneskelig angriber. Hvordan skal cybersikkerhedstestning ændres, når angreb begynder at operere med maskinhastighed?\r\n

Testenheden skal skifte fra den enkelte teknik til den komplette kampagne, der opererer under tidspres. Det vil sige, i stedet for at afprøve forskellige angrebsteknikker over en morgen eller en uge, skal test af visse sikkerhedsforanstaltninger ske hurtigt. Ellers er det ikke realistisk, og realisme er meget vigtigt.

Traditionelle tests kan efterlade bekvemme huller mellem faser, så hver hændelse kan undersøges separat. En autonom angriber kan komprimere rekognoscering, udnyttelse og lateral bevægelse til en meget kortere periode. Det kan afsløre svagheder, som ikke er synlige i langsommere tests, herunder forsinkelser i telemetri, overbelastede systemer og defensive handlinger, der først kommer efter angrebet har nået sit mål.

For at give dig et ekstremt simpelt eksempel: hvis vi hacker os ind i en Mac, downloader alle dens filer og stjæler kontoadgangskoderne, er det ikke meget brugbart, hvis antivirusprogrammet melder dårlige nyheder en dag senere.

Test af sikkerhedsrespons på AI‑angribere kræver derfor højopløsningsinstrumentering og præcis måling af detekterings‑ og responslatens. Det bør undersøge, om ydeevnen forværres, når mængden og hastigheden af aktivitet stiger, og om forsvaret kan afbryde et angreb uden at vente på en menneskelig beslutning på hvert trin.

Angrebet kan også tilpasse sig det, det opdager. Testen skal afspejle dette, samtidig med at grundsandheden, beviserne og genafspilningsmuligheden bevares. Maskinhastighed bør ikke betyde, at man opgiver kontrolleret metodik. Vi skal fortsat designe kontrollerede tests, der kan operere og måle hændelser med samme hastighed som de systemer, der evalueres.

SE Labs bruger realistiske angrebsscenarier baseret på taktik og teknikker fra trusselsgrupper som Scattered Spider. Hvordan genskaber I disse modstandere i et kontrolleret miljø, mens I sikrer, at testen afspejler, hvordan et rigtigt angreb ville udfolde sig, i stedet for blot at teste mod en foruddefineret tjekliste?

Vi starter med modstanderens mål, kendte adfærdsmønstre og sandsynlige beslutningsprocesser i stedet for at behandle deres teknikker som en indkøbsliste.

Testen følger en realistisk angrebskæde gennem rekognoscering, første adgang, udførelse, privilegieforhøjelse, post‑kompromitteringsaktivitet og lateral bevægelse. Vigtigt er, at testeren kun kan bruge information, der faktisk er opdaget under rekognosceringen og angrebet. Vi giver ikke angriberen viden, som ikke ville være tilgængelig i en reel engagement.

Scenariet er afgrænset og omhyggeligt kontrolleret, men det er ikke blot en sekvens af forudbestemte knaptryk. Hvis én rute er blokeret, kan angriberen forfølge et troværdigt alternativ inden for testens regler. Det giver sikkerhedsproduktet mulighed for at påvirke, hvordan scenariet udfolder sig.

Samtidig registreres hver vigtig handling og resultat, så vi kan forklare udfaldet og sammenligne produkter retfærdigt. Kontrolleret behøver ikke betyde stift manuskript. Det skal betyde sikkert, observerbart og understøttet af beviser.

Cybersikkerhedsprodukter er traditionelt blevet evalueret kraftigt på deres evne til at opdage trusler. Hvorfor bør organisationer i stigende grad se på beskyttelse, indespærring og hændelsesrespons, når de evaluerer AI‑drevne sikkerhedssystemer?

Detektion er ikke det samme som forsvar. En platform kan generere en præcis alarm, mens den stadig tillader angriberen at nå sit mål. Det er derfor, PIVOT‑testprogrammet inkluderer både detektion og beskyttelse som fælles og separate dele af den samlede test.

Du kan sammenligne cybersikkerhedsdetektion med et CCTV‑kamera. Det skal bemærke en indtrængen og give dig spor om, hvad der skete, men det vil ikke fysisk stoppe en indtrængende. Cybersikkerhedsbeskyttelse er meget mere aktiv. Den kan udvise eller på anden måde neutralisere en angriber og forhindre skade.

Organisationer skal vide, om produktet forhindrede den indledende aktivitet, afbrød angrebskæden, begrænsede lateral bevægelse, beskyttede vigtige aktiver og understøttede genopretning. Hvis et angreb lykkes, er de næste spørgsmål, hvor hurtigt det blev inddæmmet, og om kunden modtog tilstrækkelig pålidelig information til at reagere effektivt.

Dette bliver særligt vigtigt med AI‑drevne systemer, fordi de måske leverer meget overbevisende opsummeringer af, hvad der skete, men en overbevisende forklaring er ikke en erstatning for beskyttelse. Forklaringen skal understøttes af beviser og føre til en passende handling.

Vi måler derfor detektion og beskyttelse separat. Vi undersøger også, om den påståede detektion virkelig var synlig og nyttig for kunden. I sidste ende ligger værdien af et sikkerhedssystem i at ændre udfaldet af et angreb, ikke blot at observere det.

Efterhånden som sikkerhedsplatforme introducerer autonome agenter, der kan undersøge alarmer og udføre afhjælpningshandlinger, hvordan bør uafhængige laboratorier teste hele menneske‑og‑AI‑arbejdsgangen i stedet for kun at evaluere den underliggende detektionsteknologi isoleret?

Testen bør følge hele processen fra den første ondsindede aktivitet til det endelige sikkerhedsresultat, som kan være, at angrebet stoppes eller lykkes fuldstændigt – eller et sted midt imellem.

Vi skal undersøge, hvad agenten observerede, hvad den konkluderede, hvad den anbefalede eller gjorde, hvad den menneskelige operatør blev vist, og hvordan operatøren reagerede (eller hvilke muligheder der blev præsenteret). Det inkluderer kvaliteten af beviserne, klarheden i overdragelsen, den nødvendige tid, antallet af indgreb og om den menneskelige bruger kunne forstå, udfordre eller omstøde agentens beslutning.

Forskellige driftsformer betyder også noget. En agent, der anbefaler en handling til godkendelse, udgør en anden risiko end en, der automatisk kan isolere systemer, deaktivere konti eller ændre sikkerhedskontroller.

Et system har ikke haft succes blot fordi den underliggende detektor identificerede angrebet. Hvis det skaber en uforståelig kø, skjuler vigtig evidens, anbefaler den forkerte respons eller udfører en forstyrrende handling, er den samlede arbejdsproces mislykket. Uafhængig test bør måle den samlede præstation af teknologien, dens autonome komponenter og de personer, der forventes at bruge dem.

En risiko ved standardiserede sikkerhedsbenchmark er, at leverandører kan optimere produkter specifikt til testen. Hvordan kan uafhængig test forblive reproducerbar og retfærdig, samtidig med at den introducerer nok uforudsigelighed til at afsløre, hvordan produkter klarer sig mod ukendte angreb?

Reproducerbarhed kræver ikke, at deltagerne får eksamensspørgsmålene på forhånd.

En troværdig test bør offentliggøre sin metodik, miljø, scoringsprincipper, produktkonfiguration og evidenskrav. Leverandører skal forstå reglerne og have en fair mulighed for at verificere, at deres produkter fungerer korrekt. Den præcise angrebskampagne, payloads og nogle af angrebsstierne bør dog forblive ukendte, indtil testen er gennemført.

For eksempel afslører vi i PIVOT ikke, hvilke angrebsgrupper vi vil replikere, før testen er afsluttet. Rigtige mål får ingen forvarsel, før et angreb starter!

Vi kan kombinere en standardkerne, som understøtter sammenligning over tid, med ukendte variationer, der tester generel kapacitet. Baseline‑måling og en skjult rolig periode kan fastslå, hvordan produktet opfører sig før angrebet. Konfigurationen bør derefter kontrolleres, logge bevares, og eventuelle påstande kontrolleres mod testpersonens egen evidens.

Retfærdighed betyder, at de samme regler og evidensstandarder anvendes på alle deltagere. Det betyder ikke, at et angreb gentages så forudsigeligt, at en leverandør kan genkende benchmarken i stedet for truslen.

Derudover hjælper radikal gennemsigtighed leverandører med at reproducere angreb, hvilket er vigtigt, hvis de vil rette de problemer, de støder på, såsom at undlade at opdage eller beskytte mod en trussel. SE Labs træner i bund og grund sine kunder, når de løber ind i problemer.

Autonome sikkerhedsagenter introducerer en anden risikokategori, fordi en falsk beslutning kan udløse en unødvendig eller endda forstyrrende afhjælpningshandling. Hvordan skal test måle falske positiver, forkert ræsonnement og potentielt skadelige autonome handlinger sammen med traditionel detektionsnøjagtighed?

Traditionel test af falske positiver er kun det første lag. Med en autonom agent skal vi skelne mellem en falsk alarm, en uunderbygget konklusion og en forkert handling. Hver har en forskellig potentiel påvirkning.

Test bør udsætte systemet for legitim aktivitet, der ligner ondsindet adfærd, såvel som ufuldstændig, tvetydig eller vildledende evidens. Hvis agenten indtager upålideligt indhold, bør testen også undersøge, om dette indhold kan påvirke dens beslutninger på en upassende måde.

Ræsonnementet bør bedømmes ud fra, om konklusionen understøttes af den tilgængelige evidens, ikke ud fra hvor plausibel eller selvsikker forklaringen lyder. For autonome handlinger bør vi måle omfang, proportionalitet, brug af tilladelser, godkendelseskontroller, auditabilitet og reversibilitet.

Scoringen skal afspejle konsekvenserne. En unødvendig alarm er besværlig; deaktivering af en vigtig konto eller isolering af et kritisk system kan forstyrre organisationen. En nyttig sikkerhedsforanstaltning skal derfor tage højde for både hyppigheden af fejl og den skade, hver fejl kan forårsage.

Alt dette sagt, vælger kunden nogle gange en politik, der forårsager problemer. Det er ikke nødvendigvis sikkerhedsleverandørens skyld.

Generativ AI og stadig mere kapable open‑source‑modeller sænker barrieren for at automatisere dele af angrebsprocessen. Forventer du, at AI gør cyberangreb fundamentalt mere sofistikerede, eller er den større fare, at angribere blot vil kunne operere i dramatisk større skala og hastighed?

Min forventning er, at den mest umiddelbare fare er skala, hastighed og reducerede omkostninger.

AI kan hjælpe angribere med at indsamle information, personalisere social engineering, modificere kode og koordinere dele af en kampagne. Nogle angreb vil blive mere sofistikerede som følge heraf, især når AI hjælper med at forbinde eksisterende teknikker eller tilpasse dem til et specifikt mål. Men AI fjerner ikke behovet for adgang, legitimationsoplysninger, udnyttelige svagheder eller fejl fra forsvarere.

AI er heller ikke særlig god til at producere pålidelige exploits, hvilket allerede er svært for en dygtig menneskelig angriber at opnå. Så det mindsker sandsynligheden for fundamentalt mere sofistikerede angreb, efter min stærke mening.

Den større forandring er, at aktiviteter, som tidligere krævede tid, færdigheder eller et hold af personer, nu kan forsøges hurtigere og på mange flere mål. AI kan hæve kompetencen hos relativt almindelige angribere, mens den giver dygtige angribere mulighed for at køre flere operationer samtidigt.

Det er betydningsfuldt, selvom de underliggende angrebsteknikker ikke er revolutionerende. Faren er ikke nødvendigvis en helt ny form for cyberangreb. Det er velkendte angreb, der bliver hurtigere, billigere, mere personlige og meget flere.

Efterhånden som defensive og offensive AI‑agenter bliver mere autonome, hvordan skal et troværdigt cybersikkerhedstestmiljø så se ud for at følge med? Kan vi på et tidspunkt nå, at sikkerhedsprodukter skal udfordres kontinuerligt af adaptive AI‑modstandere i stedet for primært at blive evalueret gennem periodiske sikkerhedstest?

Et troværdigt miljø skal ligne en levende organisation snarere end en samling af isolerede mål. Det bør omfatte slutpunkter, identitetssystemer, e‑mail, netværk, cloud‑tjenester, realistiske brugere og normal forretningsaktivitet. Det skal også levere fuldstændig instrumentering, så hver beslutning og konsekvens kan rekonstrueres.

Adaptive modstandere kan få tildelt mål og grænser og derefter få lov til at vælge ruter baseret på, hvad de opdager, og hvordan det defensive produkt reagerer. Testen vil stadig kræve kontrollerede startbetingelser, en pålidelig beskrivelse af, hvad der faktisk skete, samt muligheden for at genafspille vigtige begivenheder. Uden disse elementer kan adaptiv testning fremstå imponerende, men være videnskabeligt svag.

Jeg forventer, at testning bliver mere kontinuerlig, især når produkter, modeller og politikker kan ændre sig hyppigt. Kontinuerlig udfordring bør dog supplere snarere end erstatte periodisk komparativ testning. Organisationer har brug for begge dele: kontrollerede benchmarks som PIVOT, der understøtter ansvarlighed og sammenligning, samt løbende adaptiv evaluering, der afslører, hvordan systemer opfører sig, efterhånden som truslerne og produkterne selv ændrer sig.

Jeg mener, vi bør bekymre os mere om, at relativt ukvalificerede mennesker kan bryde ind i systemer og netværk, end om robotterne, der skaber næste generation af cyberangrebsteknologi.

Tak for det gode interview, læsere der ønsker at lære mere, bør besøge SE Labs.