Simon Edwards, VD och grundare av SE Labs – Intervjuserie

Simon Edwards, VD och grundare av SE Labs, är en expert på cybersäkerhetstestning med mer än tre decennier av erfarenhet som sträcker sig över säkerhetsforskning, produktutvärdering, teknisk journalistik och branschstandarder. Innan han grundade SE Labs år 2015 ledde Edwards Dennis Technology Labs, där han styrde säkerhetstestningsinitiativ, och tidigare tillbringade han många år som teknologijournalist och redaktör. Han har också haft ledande befattningar i Anti-Malware Testing Standards Organization (AMTSO), inklusive ordförande, direktör och medordförande. Edwards har testat säkerhetsprodukter sedan mitten av 1990‑talet och var pionjär inom tidiga verkliga anti‑malware‑testmetoder som syftar till att utvärdera hur säkerhetsteknologier presterar mot kompletta, internetlevererade attacker snarare än isolerade malware‑prover.

SE Labs är ett oberoende företag för cybersäkerhetstestning och rådgivning som utvärderar hur säkerhetsteknologier presterar mot realistiska attacker. Dess forskare reproducerar angripartekniker över hela attackkedjan för att bedöma produkter inklusive endpoint‑skydd, Endpoint Detection and Response (EDR), molnsäkerhetstjänster, brandväggar, e‑postsäkerhet och nätverksdetekteringstekniker. Förutom offentliga jämförande tester erbjuder SE Labs certifiering, avancerad säkerhetstestning, produktvalidering och rådgivning för företag och leverantörer av cybersäkerhet. Företaget publicerar sina testmetoder och hotemuleringsramverk och är certifierat enligt ISO/IEC 27001:2022 och BS EN ISO 9001:2015 för leverans av IT‑säkerhetsprodukttestning.

Din karriär sträcker sig över mer än tre decennier inom teknologijournalistik, säkerhetskonsulting, oberoende testning och ledarskapsroller i Anti-Malware Testing Standards Organization (AMTSO). Hur har den erfarenheten format ditt sätt att skilja på verkliga framsteg inom AI‑driven cybersäkerhet och teknologier som främst marknadsförs som “AI” för marknadsföringsändamål?\r\n

Journalistik lärde mig att ifrågasätta påståenden, medan oberoende testning lärde mig att det enda pålitliga svaret kommer från bevis. Företag inom cybersäkerhet har använt maskininlärning och automatiserat beslutsfattande i många år, så att lägga till “AI” i ett produktnamn innebär inte nödvändigtvis en teknisk förbättring.

Tre grundläggande saker att överväga: Vad gör AI:n egentligen? Vilket mätbart säkerhetsresultat förbättrar den? Och kan en oberoende testare reproducera den förbättringen?

Om svaret helt enkelt är att produkten analyserar en stor mängd data eller automatiserar en befintlig process, kan AI‑etiketten handla mer om positionering än om förmåga.

Ett verkligt framsteg presterar väl mot okända eller helt nya attacker, förbättrar skydd eller respons, minskar bördan för analytiker och gör detta utan att introducera oacceptabla risker. Allt annat är antingen ingen förbättring eller en nedgradering!

“AI‑driven” har blivit ett vanligt påstående bland cybersäkerhetsprodukter. Vilka är de viktigaste funktionerna som bör testas oberoende innan en organisation accepterar att en AI‑driven säkerhetsplattform faktiskt levererar det som leverantören lovar?\r\n

Jag skulle inte börja med att testa om en produkt innehåller AI. Jag skulle börja med att testa de säkerhets påståenden som görs för den. Jag bryr mig egentligen inte om hur en produkt fungerar, så länge den fungerar. Detta är det exakta målet med PIVOT-testprogrammet, som just nu får stort genomslag i branschen.

Att testa på detta sätt innebär att utsätta produkten för kompletta attacker och mäta hur den svarar. Den bör troligen upptäcka aktiviteten och sedan eventuellt förhindra att attacken fortskrider. Detta beror på hur produkten är byggd och konfigurerad samt på de marknadsföringspåståenden som leverantören gör.

Vi måste också granska den undersökande berättelsen som presenteras för kunden. Förstod systemet vad som hände, kopplade ihop relevanta händelser och gjorde bevisen synliga för den person som måste agera på dem?

Testet bör inkludera okända varianter, realistiska kundkonfigurationer och normal affärsverksamhet. Det måste också mäta falska positiva, resurskrav och åtgärder som kan anses potentiellt osäkra. Om systemet är autonomt behöver vi veta när det agerar, varför det agerar, vilka behörigheter det använder och om dess beslut kan återkallas.

Vi har sett några nyhetshistorier om AI‑säkerhet som gått löst och överskridit sina gränser och potentiellt lagen. Den viktiga frågan är inte om plattformen verkar intelligent. Det är om den levererar konsekvent bättre och säkrare säkerhetsresultat.

Autonoma AI‑agenter kan potentiellt utföra rekognosering, exploatering, lateral förflyttning och andra steg i en attack mycket snabbare än en mänsklig angripare. Hur måste cybersäkerhetstestning förändras när attacker börjar operera i maskinhastighet?\r\n

Testenheten måste förändras från enskilda tekniker till hela kampanjen som opererar under tidspress. Med det menar jag att istället för att prova olika attackmetoder under en morgon eller en vecka, måste testning av vissa säkerhetsåtgärder ske snabbt. Annars är det inte realistiskt, och realism är mycket viktigt.

Traditionella tester kan lämna praktiska luckor mellan faser så att varje händelse kan granskas separat. En autonom angripare kan komprimera spaning, exploatering och lateral rörelse till en mycket kortare period. Det kan avslöja svagheter som inte syns i långsammare tester, inklusive fördröjningar i telemetri, överbelastade system och försvarsåtgärder som bara kommer efter att attacken har nått sitt mål.

För att ge ett extremt enkelt exempel: om vi hackar in i en Mac, laddar ner alla dess filer och stjäl kontolösenorden, är det inte mycket nytta om antivirusprogrammet dyker upp en dag senare med de dåliga nyheterna.

Att testa säkerhetsrespons mot AI‑angripare kräver därför högupplöst instrumentering och exakt mätning av upptäckts‑ och svarslatens. Det bör undersöka om prestandan försämras när volymen och hastigheten på aktiviteten ökar, och om försvaret kan avbryta en attack utan att vänta på ett mänskligt beslut i varje steg.

Attacken kan också anpassa sig efter vad den upptäcker. Testerna måste återspegla detta samtidigt som de bevarar sanningsgrund, bevis och återuppspelningsmöjlighet. Maskinhastigheten får inte innebära att man överger kontrollerad metodik. Vi måste fortsätta att utforma kontrollerade tester som kan operera och mäta händelser i samma hastighet som de system som utvärderas.

SE Labs använder realistiska attackscenarier baserade på taktik och tekniker från hotgrupper som Scattered Spider. Hur återskapar du dessa motståndare i en kontrollerad miljö samtidigt som du säkerställer att testet speglar hur en verklig attack skulle utvecklas snarare än att bara testa mot en fördefinierad checklista?

Vi börjar med motståndarens mål, kända beteenden och sannolika beslutsfattande, snarare än att behandla dess tekniker som en inköpslista.

Testet följer en realistisk attackkedja genom spaning, initial åtkomst, exekvering, privilegiehöjning, post‑kompromiss‑aktivitet och lateral rörelse. Viktigt är att testaren endast får använda information som faktiskt upptäckts under spaningen och attacken. Vi ger inte angriparen kunskap som inte skulle vara tillgänglig i ett verkligt uppdrag.

Scenariot är avgränsat och noggrant kontrollerat, men det är inte bara en sekvens av förutbestämda knapptryckningar. Om en väg blockeras kan angriparen följa ett trovärdigt alternativ inom testets regler. Det gör att säkerhetsprodukten kan påverka hur scenariot utvecklas.

Samtidigt registreras varje viktig handling och resultat så att vi kan förklara utfallet och jämföra produkter rättvist. Kontrollerat betyder inte nödvändigtvis strikt skriptat. Det bör innebära säkert, observerbart och understött av bevis.

Cybersäkerhetsprodukter har traditionellt utvärderats starkt på sin förmåga att upptäcka hot. Varför bör organisationer i allt högre grad titta på skydd, isolering och incidentrespons när de utvärderar AI‑drivna säkerhetssystem?

Upptäckt är inte detsamma som försvar. En plattform kan generera en korrekt varning samtidigt som angriparen fortfarande kan nå sitt mål. Detta är anledningen till att PIVOT‑testprogrammet inkluderar både upptäckt och skydd som gemensamma och separata delar av den övergripande testningen.

Du kan jämföra cybersäkerhetsupptäckt med en CCTV‑kamera. Den bör märka en intrång och ge dig ledtrådar om vad som hänt, men den stoppar inte en inkräktare fysiskt. Cybersäkerhetsskydd är mycket mer aktivt. Det kan avvisa eller på annat sätt neutralisera en angripare och förhindra skada.

Organisationer behöver veta om produkten förhindrade den initiala aktiviteten, avbröt attackkedjan, begränsade lateral rörelse, skyddade viktiga tillgångar och stödde återhämtning. Om en attack lyckas är nästa frågor hur snabbt den kunde isoleras och om kunden fick tillräckligt pålitlig information för att kunna svara effektivt.

Detta blir särskilt viktigt med AI‑drivna system eftersom de, även om de kan producera mycket övertygande sammanfattningar av vad som hänt, inte kan ersätta skydd med en övertygande förklaring. Förklaringen måste understödas av bevis och leda till en lämplig åtgärd.

Vi mäter därför upptäckt och skydd separat. Vi undersöker också om den påstådda upptäckten verkligen var synlig och användbar för kunden. I slutändan ligger värdet av ett säkerhetssystem i att förändra utfallet av en attack, inte bara i att observera den.

När säkerhetsplattformar introducerar autonoma agenter som kan undersöka varningar och vidta åtgärder, hur bör oberoende laboratorier testa hela människ‑och‑AI‑arbetsflödet snarare än att enbart utvärdera den underliggande upptäckningstekniken i isolering?

Testet bör följa hela processen från den första skadliga aktiviteten till det slutgiltiga säkerhetsutfallet, vilket kan vara att attacken stoppas eller lyckas helt – eller någonstans däremellan.

Vi måste undersöka vad agenten observerade, vad den drog för slutsats, vad den rekommenderade eller gjorde, vad den mänskliga operatören visades och hur operatören svarade (eller vilka alternativ som presenterades). Det inkluderar kvaliteten på bevisen, tydligheten i överlämnandet, den tid som krävdes, antalet ingripanden och om människan kunde förstå, ifrågasätta eller återkalla agentens beslut.

Olika driftlägen spelar också roll. En agent som föreslår en åtgärd för godkännande innebär en annan risk än en som automatiskt kan isolera system, inaktivera konton eller ändra säkerhetskontroller.

Ett system har inte lyckats bara för att dess underliggande detektor identifierade attacken. Om det skapar en obegriplig kö, döljer viktig bevisning, föreslår fel svar eller utför en störande åtgärd har hela arbetsflödet misslyckats. Oberoende tester bör mäta den kombinerade prestandan hos tekniken, dess autonoma komponenter och de personer som förväntas använda dem.

Ett riskmoment med standardiserade säkerhetsbenchmarkar är att leverantörer kan optimera produkter specifikt för testet. Hur kan oberoende testning förbli reproducerbar och rättvis samtidigt som den introducerar tillräckligt med oförutsägbarhet för att avslöja hur produkter presterar mot okända attacker?

Reproducerbarhet kräver inte att deltagarna får tentamensfrågorna i förväg.

Ett trovärdigt test bör publicera sin metodik, miljö, poängprinciper, produktkonfiguration och evidenskrav. Leverantörer bör förstå reglerna och ha en rättvis möjlighet att verifiera att deras produkter fungerar korrekt. Den exakta attackkampanjen, payloads och vissa attackvägar bör dock förbli okända tills testet genomförs.

Till exempel avslöjar vi i PIVOT inte vilka attackgrupper vi kommer att replikera förrän efter att testningen är slutförd. Riktiga mål får ingen förvarning innan en attack startar!

Vi kan kombinera en standardkärna, som möjliggör jämförelse över tid, med okända variationer som testar generell förmåga. Baslinjering och en dold tyst period kan fastställa hur produkten beter sig före attacken. Konfigurationen bör sedan styras, loggar bevaras och eventuella påståenden kontrolleras mot testarens egna bevis.

Rättvisa innebär att samma regler och evidensstandarder tillämpas på alla deltagare. Det betyder inte att en attack upprepas så förutsägbart att en leverantör kan känna igen benchmarken istället för hotet.

Dessutom hjälper radikal transparens leverantörer att reproducera attacker, vilket är viktigt om de vill åtgärda problem de stöter på, såsom att misslyckas med att upptäcka eller skydda mot ett hot. SE Labs tränar i princip sina kunder när de stöter på problem.

Autonoma säkerhetsagenter introducerar en annan riskkategori eftersom ett felaktigt beslut kan utlösa en onödig eller till och med störande åtgärd. Hur bör testning mäta falska positiva, felaktigt resonemang och potentiellt skadliga autonoma handlingar tillsammans med traditionell detekteringsnoggrannhet?

Traditionell testning av falska positiva är bara det första lagret. Med en autonom agent måste vi skilja på ett falskt larm, en utan stöd för slutsats och en felaktig handling. Var och en har en annan potentiell påverkan.

Tester bör utsätta systemet för legitim aktivitet som liknar skadligt beteende, samt ofullständig, tvetydig eller vilseledande bevisning. Om agenten konsumerar opålitligt innehåll bör testning också undersöka om det innehållet kan påverka dess beslut på ett otillbörligt sätt.

Resonemanget bör bedömas utifrån om slutsatsen stöds av den tillgängliga bevisningen, inte hur sannolikt eller självsäkert förklaringen låter. För autonoma handlingar bör vi mäta omfattning, proportionalitet, användning av behörigheter, godkännandekontroller, auditabilitet och reverserbarhet.

Betygsättningen måste återspegla konsekvenserna. Ett onödigt larm är besvärligt; att inaktivera ett viktigt konto eller isolera ett kritiskt system kan störa organisationen. En användbar säkerhetsåtgärd måste därför beakta både felens frekvens och skadan varje fel kan orsaka.

Allt detta sagt, ibland väljer kunden en policy som orsakar problem. Det är inte nödvändigtvis leverantörens fel.

Generativ AI och alltmer kapabla öppen källkod-modeller sänker tröskeln för att automatisera delar av attackprocessen. Förväntar du dig att AI gör cyberattacker fundamentalt mer sofistikerade, eller är den större faran att angripare helt enkelt kan operera i dramatiskt större skala och hastighet?

Min förväntning är att den mer omedelbara faran är skala, hastighet och minskade kostnader.

AI kan hjälpa angripare att samla information, personifiera social ingenjörskonst, modifiera kod och samordna delar av en kampanj. Vissa attacker blir mer sofistikerade som ett resultat, särskilt när AI hjälper till att koppla ihop befintliga tekniker eller anpassa dem till ett specifikt mål. Men AI eliminerar inte behovet av åtkomst, autentiseringsuppgifter, utnyttjbara svagheter eller misstag från försvarare.

AI är dessutom inte särskilt bra på att producera pålitliga exploateringar, vilket redan är svårt för en skicklig människa att åstadkomma. Så det minskar sannolikheten för fundamentalt mer sofistikerade attacker, enligt min starka uppfattning.

Den större förändringen är att aktiviteter som tidigare krävde tid, kompetens eller ett team kan utföras snabbare och mot många fler mål. AI kan höja kompetensen hos relativt vanliga angripare samtidigt som den gör det möjligt för skickliga angripare att köra fler operationer parallellt.

Det är betydande även om de underliggande attackteknikerna inte är revolutionerande. Risken är inte nödvändigtvis en helt ny form av cyberattack. Det är välbekanta attacker som blir snabbare, billigare, mer personliga och mycket fler.

När defensiva och offensiva AI‑agenter blir mer autonoma, hur ska en trovärdig cybersäkerhetstestmiljö se ut för att hålla jämna steg? Kan vi så småningom nå en punkt där säkerhetsprodukter måste utmanas kontinuerligt av adaptiva AI‑motståndare snarare än att främst utvärderas genom periodiska säkerhetstester?

En trovärdig miljö måste likna en levande organisation snarare än en samling isolerade mål. Den bör omfatta slutpunkter, identitetssystem, e‑post, nätverk, molntjänster, realistiska användare och normal affärsverksamhet. Den måste också tillhandahålla fullständig instrumentering så att varje beslut och konsekvens kan rekonstrueras.

Adaptiva motståndare kan ges mål och gränser och sedan låtas välja vägar baserat på vad de upptäcker och hur den defensiva produkten svarar. Testet skulle fortfarande behöva kontrollerade startförhållanden, en pålitlig beskrivning av vad som faktiskt hände och möjlighet att återspela viktiga händelser. Utan dessa saker kan adaptiv testning bli imponerande men vetenskapligt svag.

Jag förväntar mig att testning blir mer kontinuerlig, särskilt när produkter, modeller och policyer kan förändras ofta. Däremot bör kontinuerlig utmaning komplettera snarare än ersätta periodisk jämförande testning. Organisationer behöver båda: kontrollerade benchmarkar som PIVOT som stödjer ansvarsskyldighet och jämförelse, samt pågående adaptiv utvärdering som visar hur system beter sig när hoten och produkterna själva förändras.

Jag tror vi bör oroa oss mer för att relativt okunniga människor kan bryta sig in i system och nätverk, snarare än för robotarna som skapar nästa generation av cyberattackteknik.

Tack för den fantastiska intervjun, läsare som vill lära sig mer bör besöka SE Labs.