Simon Edwards, administrerende direktør og grunnlegger av SE Labs – intervjuserie

Simon Edwards, administrerende direktør og grunnlegger av SE Labs, er en ekspert på cybersikkerhetstesting med mer enn tre tiår med erfaring som spenner over sikkerhetsforskning, produkttesting, teknisk journalistikk og bransjestandarder. Før han grunnla SE Labs i 2015, ledet Edwards Dennis Technology Labs, hvor han styrte sikkerhetstestinitiativ, og tidligere tilbrakte han mange år som teknologijournalist og redaktør. Han har også hatt seniorlederstillinger i Anti-Malware Testing Standards Organization (AMTSO), inkludert styreleder, direktør og medstyreleder. Edwards har testet sikkerhetsprodukter siden midten av 1990‑årene og var en pioner innen tidlige virkelige anti‑malware‑testmetoder designet for å evaluere hvordan sikkerhetsteknologier presterer mot komplette, internettleverte angrep i stedet for isolerte malware‑prøver.

SE Labs er et uavhengig selskap for cybersikkerhetstesting og rådgivning som evaluerer hvordan sikkerhetsteknologier presterer mot realistiske angrep. Forskerne deres gjenskaper angriperteknikker gjennom hele angrepskjeden for å vurdere produkter som inkluderer endepunktsbeskyttelse, Endpoint Detection and Response (EDR), skytjenestesikkerhet, brannmurer, e‑post‑sikkerhet og nettverksdeteksjonsteknologier. I tillegg til offentlig sammenlignende testing, tilbyr SE Labs sertifisering, avansert sikkerhetstesting, produktvalidering og rådgivningstjenester for virksomheter og leverandører av cybersikkerhetsløsninger. Selskapet publiserer sine testmetodikker og trussel‑emuleringsrammeverk og er sertifisert i henhold til ISO/IEC 27001:2022 og BS EN ISO 9001:2015 for levering av IT‑sikkerhetsproduktesting.

Din karriere spenner over mer enn tre tiår innen teknologijournalistikk, sikkerhetskonsultasjon, uavhengig testing og lederroller i Anti-Malware Testing Standards Organization (AMTSO). Hvordan har den erfaringen påvirket måten du skiller ekte fremskritt innen AI‑drevet cybersikkerhet fra teknologier som primært markedsføres som «AI»?

Journalistikk lærte meg å stille spørsmål ved påstander, mens uavhengig testing lærte meg at det eneste pålitelige svaret kommer fra bevis. Sikkerhetsselskaper har brukt maskinlæring og automatisert beslutningstaking i mange år, så det å legge til «AI» i et produktnavn representerer ikke nødvendigvis en teknisk fremgang.

Tre grunnleggende ting å vurdere: Hva gjør AI-en egentlig? Hvilket målbare sikkerhetsresultat forbedrer den? Og kan en uavhengig tester gjenskape den forbedringen?

Hvis svaret bare er at produktet analyserer en stor mengde data eller automatiserer en eksisterende prosess, kan AI‑merkingen handle mer om posisjonering enn om faktiske evner.

En ekte fremgang presterer godt mot ukjente eller helt nye angrep, forbedrer beskyttelse eller respons, reduserer belastningen på analytikere, og gjør dette uten å innføre uakseptable risikoer. Alt annet er enten ingen forbedring eller en nedgradering!

«AI‑drevet» har blitt et vanlig påstand i cybersikkerhetsprodukter. Hva er de viktigste funksjonene som bør testes uavhengig før en organisasjon godtar at en AI‑drevet sikkerhetsplattform faktisk leverer det leverandøren lover?

Jeg ville ikke starte med å teste om et produkt inneholder AI. Jeg ville starte med å teste sikkerhetspåstandene som gjøres for det. Jeg bryr meg egentlig ikke om hvordan et produkt fungerer, så lenge det fungerer. Dette er det eksakte målet med PIVOT-testprogrammet, som nå får stor oppmerksomhet i bransjen.

Å teste på denne måten innebærer å utsette produktet for komplette angrep og måle hvordan det responderer. Det bør sannsynligvis oppdage aktiviteten og deretter kunne forhindre at angrepet fortsetter. Dette avhenger av hvordan produktet er bygget og konfigurert, samt hvilke markedsføringspåstander leverandøren gjør.

Vi må også undersøke den etterforskningshistorien som presenteres for kunden. Forsto systemet hva som skjedde, koblet de relevante hendelsene og gjorde bevisene synlige for personen som må handle på dem?

Testen bør inkludere ukjente varianter, realistiske kundekonfigurasjoner og normal forretningsaktivitet. Den må også måle falske positiver, ressurskrav og handlinger som kan anses som potensielt usikre. Hvis systemet er autonomt, må vi vite når det handler, hvorfor det handler, hvilke tillatelser det bruker og om beslutningene kan reverseres.

Vi har sett noen få nyhetshistorier om AI‑sikkerhet som har gått amok og overskredet sine grenser og potensielt loven. Det viktige spørsmålet er ikke om plattformen virker intelligent. Det er om den leverer konsekvent bedre og sikrere sikkerhetsresultater.

Autonome AI‑agenter kan potensielt utføre rekognosering, utnyttelse, lateral bevegelse og andre stadier av et angrep langt raskere enn en menneskelig angriper. Hvordan må cybersikkerhetstesting endres når angrep begynner å operere i maskinhastighet?

Testenheten må endres fra den enkelte teknikken til den komplette kampanjen som opererer under tidspress. Det vil si at i stedet for å prøve ulike angrepsmetoder over en morgen eller en uke, må testing av enkelte sikkerhetstiltak gjøres raskt. Ellers er det ikke realistisk, og realisme er svært viktig.

Tradisjonelle tester kan etterlate praktiske hull mellom stadier slik at hver hendelse kan undersøkes separat. En autonom angriper kan komprimere rekognosering, utnyttelse og lateral bevegelse til en mye kortere periode. Det kan avdekke svakheter som ikke er synlige i langsommere tester, inkludert forsinkelser i telemetri, overbelastede systemer og defensive handlinger som kun kommer etter at angrepet har oppnådd sitt mål.

For å gi deg et ekstremt enkelt eksempel: hvis vi hackerer en Mac, laster ned alle filene og stjeler kontopassordene, er det lite nytte hvis antivirusprogrammet melder fra dagen etter med de dårlige nyhetene.

Testing av sikkerhetsrespons på AI‑angripere krever derfor høyoppløselig instrumentering og presis måling av deteksjons‑ og responslatens. Det bør undersøke om ytelsen forverres når volumet og hastigheten på aktiviteten øker, og om forsvaret kan avbryte et angrep uten å vente på en menneskelig beslutning i hvert steg.

Angrepet kan også tilpasse seg det det oppdager. Testingen må reflektere dette samtidig som den bevarer sannhetsgrunnlag, bevis og gjenspillbarhet. Maskinhastighet skal ikke bety at vi gir opp kontrollert metodikk. Vi må fortsette å designe kontrollerte tester som kan operere og måle hendelser i samme hastighet som systemene som evalueres.

SE Labs bruker realistiske angrepsscenarioer basert på taktikker og teknikker fra trusselgrupper som Scattered Spider. Hvordan gjenskaper dere disse motstanderne i et kontrollert miljø samtidig som dere sikrer at testen reflekterer hvordan et ekte angrep ville utspille seg, i stedet for bare å teste mot en forhåndsdefinert sjekkliste?

Vi starter med motstanderens mål, kjente atferdsmønstre og sannsynlige beslutningsprosesser, i stedet for å behandle teknikkene som en handleliste.

Testen følger en realistisk angrepskjede gjennom rekognosering, første tilgang, utførelse, privilegietilgang, post‑kompromitteringsaktivitet og lateral bevegelse. Viktig er at testeren kun kan bruke informasjon som faktisk ble oppdaget under rekognoseringen og angrepet. Vi gir ikke angriperen kunnskap som ikke ville vært tilgjengelig i et ekte oppdrag.

Scenarioet er avgrenset og nøye kontrollert, men det er ikke bare en sekvens av forhåndsbestemte knappetrykk. Hvis én rute er blokkert, kan angriperen forfølge et troverdig alternativ innenfor testens regler. Det gjør at sikkerhetsproduktet kan påvirke hvordan scenarioet utvikler seg.

Samtidig blir hver viktig handling og hvert resultat registrert slik at vi kan forklare utfallet og sammenligne produkter rettferdig. Kontrollert trenger ikke bety stivt manusbasert. Det skal bety trygt, observerbart og støttet av bevis.

Sikkerhetsprodukter har tradisjonelt blitt evaluert tungt på deres evne til å oppdage trusler. Hvorfor bør organisasjoner i økende grad se på beskyttelse, innkapsling og hendelsesrespons når de vurderer AI‑drevne sikkerhetssystemer?

Deteksjon er ikke det samme som forsvar. En plattform kan generere et nøyaktig varsel samtidig som den lar angriperen oppnå målet. Dette er grunnen til at PIVOT‑testprogrammet inkluderer både deteksjon og beskyttelse som både felles og separate deler av den samlede testingen.

Du kan sammenligne cybersikkerhetsdeteksjon med et CCTV‑kamera. Det skal oppdage et innbrudd og gi deg ledetråder om hva som skjedde, men det vil ikke fysisk stoppe en inntrenger. Cybersikkerhetsbeskyttelse er mye mer aktiv. Den kan utvise eller på annen måte nøytralisere en angriper, og dermed forhindre skade.

Organisasjoner må vite om produktet hindret den innledende aktiviteten, avbrøt angrepskjeden, begrenset lateral bevegelse, beskyttet viktige eiendeler og støttet gjenoppretting. Hvis et angrep lykkes, er de neste spørsmålene hvor raskt det ble innkapslet og om kunden fikk nok pålitelig informasjon til å svare effektivt.

Dette blir spesielt viktig med AI‑drevne systemer fordi, selv om de kan produsere svært overbevisende sammendrag av hva som skjedde, er en overbevisende forklaring ingen erstatning for beskyttelse. Forklaringen må støttes av bevis og må lede til en passende handling.

Vi må derfor måle deteksjon og beskyttelse separat. Vi undersøker også om den påståtte deteksjonen faktisk var synlig og nyttig for kunden. Til syvende og sist ligger verdien av et sikkerhetssystem i å endre utfallet av et angrep, ikke bare i å observere det.

Når sikkerhetsplattformer introduserer autonome agenter som kan undersøke varsler og utføre avhjelpende tiltak, hvordan bør uavhengige laboratorier teste hele menneske‑og‑AI‑arbeidsflyten i stedet for kun å evaluere den underliggende deteksjonsteknologien isolert?

Testen bør følge hele prosessen fra den første ondsinnede aktiviteten til det endelige sikkerhetsutfallet, som kan være at angrepet blir stoppet eller lykkes helt – eller noe imellom.

Vi må undersøke hva agenten observerte, hva den konkluderte med, hva den anbefalte eller gjorde, hva den menneskelige operatøren ble vist, og hvordan operatøren responderte (eller hvilke alternativer som ble presentert). Det inkluderer kvaliteten på bevisene, klarheten i overleveringen, tiden som kreves, antall intervensjoner og om mennesket kunne forstå, utfordre eller reversere agentens beslutning.

Ulike driftsmoduser spiller også inn. En agent som anbefaler en handling for godkjenning medfører en annen risiko enn en som automatisk kan isolere systemer, deaktivere kontoer eller endre sikkerhetskontroller.

Et system har ikke lykkes bare fordi den underliggende detektoren identifiserte angrepet. Hvis det skaper en uforståelig kø, skjuler viktig bevis, anbefaler feil respons eller utfører en forstyrrende handling, har hele arbeidsflyten feilet. Uavhengig testing bør måle den samlede ytelsen til teknologien, dens autonome komponenter og menneskene som forventes å bruke dem.

En risiko ved standardiserte sikkerhetsbenchmarker er at leverandører kan optimalisere produkter spesifikt for testen. Hvordan kan uavhengig testing forbli reproduserbar og rettferdig samtidig som den introduserer nok uforutsigbarhet til å avdekke hvordan produkter presterer mot ukjente angrep?

Reproduserbarhet krever ikke at deltakerne får eksamensspørsmålene på forhånd.

En troverdig test bør publisere sin metodikk, miljø, poenggivningsprinsipper, produktkonfigurasjon og beviskrav. Leverandører bør forstå reglene og ha en rettferdig mulighet til å verifisere at produktene deres fungerer korrekt. Imidlertid bør den nøyaktige angrepskampanjen, nyttelastene og noen av angrepsveiene forbli ukjente frem til testen gjennomføres.

For eksempel, i PIVOT avslører vi ikke hvilke angrepsgrupper vi skal replikere før testen er fullført. Reelle mål får ingen varsel før et angrep starter!

Vi kan kombinere en standard kjerne, som støtter sammenligning over tid, med ukjente varianter som tester generell kapasitet. Baseline‑setting og en skjult rolig periode kan fastslå hvordan produktet oppfører seg før angrepet. Konfigurasjonen bør deretter kontrolleres, logger bevares og eventuelle påstander sjekkes mot testernes egne bevis.

Rettferdighet betyr å anvende de samme reglene og bevisstandardene på alle deltakere. Det betyr ikke å gjenta et angrep så forutsigbart at en leverandør kan gjenkjenne benchmarken i stedet for trusselen.

I tillegg hjelper radikal åpenhet leverandører med å reprodusere angrep, noe som er viktig hvis de vil rette opp problemer de møter, som å ikke oppdage eller beskytte mot en trussel. SE Labs trener i hovedsak sine kunder når de støter på problemer.

Autonome sikkerhetsagenter introduserer en annen risikokategori fordi en feil beslutning kan utløse en unødvendig eller til og med forstyrrende remediationshandling. Hvordan bør testing måle falske positiver, feilsluttning og potensielt skadelige autonome handlinger sammen med tradisjonell deteksjonsnøyaktighet?

Tradisjonell testing av falske positiver er bare det første laget. Med en autonom agent må vi skille mellom en falsk alarm, en uunderbygget konklusjon og en feil handling. Hver av dem har ulik potensiell påvirkning.

Tester bør utsette systemet for legitim aktivitet som ligner ondsinnet atferd, samt ufullstendig, tvetydig eller misvisende bevis. Hvis agenten konsumerer upålitelig innhold, bør testen også undersøke om dette innholdet kan påvirke beslutningene på en upassende måte.

Resonnementet bør vurderes ut fra om konklusjonen er støttet av tilgjengelige bevis, ikke ut fra hvor plausibel eller selvsikker forklaringen virker. For autonome handlinger bør vi måle omfang, proporsjonalitet, bruk av tillatelser, godkjenningskontroller, sporbarhet og reverserbarhet.

Poengsettingen må reflektere konsekvensene. En unødvendig alarm er irriterende; å deaktivere en viktig konto eller isolere et kritisk system kan forstyrre organisasjonen. En nyttig sikkerhetstiltak må derfor ta hensyn både til hyppigheten av feil og skaden hver feil kan forårsake.

Alt dette sagt, noen ganger velger kunden en policy som forårsaker problemer. Dette er ikke nødvendigvis leverandørens skyld.

Generativ AI og stadig mer kapable åpen‑kilde‑modeller senker terskelen for å automatisere deler av angrepsprosessen. Forventer du at AI gjør cyberangrep fundamentalt mer sofistikerte, eller er den større faren at angripere ganske enkelt vil kunne operere i dramatisk større skala og hastighet?

Min forventning er at den mest umiddelbare faren er skala, hastighet og reduserte kostnader.

AI kan hjelpe angripere med å samle informasjon, personalisere sosial manipulering, endre kode og koordinere deler av en kampanje. Noen angrep vil bli mer sofistikerte som følge av dette, spesielt når AI hjelper til med å koble eksisterende teknikker eller tilpasse dem til et bestemt mål. Men AI fjerner ikke behovet for tilgang, legitimasjon, utnyttbare svakheter eller feil fra forsvarere.

AI er heller ikke særlig god til å produsere pålitelige exploits, noe som allerede er vanskelig nok for en dyktig menneskelig angriper å oppnå. Så det reduserer sannsynligheten for fundamentalt mer sofistikerte angrep, etter min sterke mening.

Den større endringen er at aktiviteter som tidligere krevde tid, ferdigheter eller et team av personer nå kan forsøkes raskere og på mange flere mål. AI kan heve kompetansen til relativt vanlige angripere samtidig som den gjør det mulig for dyktige angripere å kjøre flere operasjoner parallelt.

Det er betydningsfullt selv om de underliggende angrepsteknikkene ikke er revolusjonerende. Faren er ikke nødvendigvis en helt ny form for cyberangrep. Det er kjente angrep som blir raskere, billigere, mer personaliserte og mye mer tallrike.

Etter hvert som defensive og offensive AI‑agenter blir mer autonome, hvordan må et troverdig cybersikkerhetstestmiljø se ut for å holde tritt? Kan vi en dag nå et punkt hvor sikkerhetsprodukter må utfordres kontinuerlig av adaptive AI‑motstandere i stedet for hovedsakelig å bli evaluert gjennom periodiske sikkerhetstester?

Et troverdig miljø må ligne en levende organisasjon snarere enn en samling av isolerte mål. Det bør inkludere endepunkter, identitetssystemer, e‑post, nettverk, skytjenester, realistiske brukere og normal forretningsaktivitet. Det må også tilby full instrumentering slik at hver beslutning og konsekvens kan rekonstrueres.

Adaptive motstandere kan få mål og grenser, og så få lov til å velge ruter basert på hva de oppdager og hvordan det defensive produktet responderer. Testen vil fortsatt trenge kontrollerte startbetingelser, en pålitelig beskrivelse av hva som faktisk skjedde, og muligheten til å gjenskape viktige hendelser. Uten disse elementene kan adaptiv testing bli imponerende å se på, men vitenskapelig svak.

Jeg forventer at testing blir mer kontinuerlig, spesielt når produkter, modeller og retningslinjer kan endres ofte. Kontinuerlig utfordring bør imidlertid komplementere snarere enn erstatte periodisk komparativ testing. Organisasjoner trenger begge: kontrollerte referanser som PIVOT som støtter ansvarlighet og sammenligning, og pågående adaptiv evaluering som viser hvordan systemer oppfører seg når truslene og produktene selv endres.

Jeg mener vi bør bekymre oss mer for at relativt ukvalifiserte mennesker kan bryte seg inn i systemer og nettverk, enn for robotene som skaper neste generasjon av cyberangrepsteknologi.

Takk for det flotte intervjuet, lesere som ønsker å lære mer bør besøke SE Labs.