Shannon McWilliams, chef för global distribution på Orca Security – intervjuserie

Shannon McWilliams är chef för global distribution på Orca Security, där hans arbete omfattar företagets partnernätverk och verktygen som stöder det. Han har tidigare grundat ett programvaruutvecklingsföretag och har erfarenhet av att omvandla verksamhetsbehov till applikationer. På senare tid använde han AI-utvecklingsverktyg för att bygga en tidig version av Orcas Partner Success Platform. Tillsammans med säkerhetsteamet tog han projektet från en prototyp som byggdes under en helg till ett system redo för produktion.

Orca Security tillhandahåller en molnsäkerhetsplattform som hjälper organisationer att upptäcka tillgångar, identifiera och prioritera risker samt skydda molnmiljöer. Plattformens funktioner omfattar bland annat sårbarheter, felkonfigurationer, identiteter och behörigheter, känsliga data och AI-säkerhet. I den här intervjun diskuterar McWilliams hur AI gör det möjligt för verksamhetsanvändare att bygga programvara, varför fungerande applikationer fortfarande behöver granskas oberoende ur säkerhetssynpunkt och hur kontinuerlig upptäckt, minsta möjliga behörighet och mänsklig tillsyn kan hjälpa företag att hantera den här nya utvecklingsmodellen.

Du började på Orca Security som chef för global distribution och byggde bara några månader senare själv en ny plattform för partner med hjälp av AI. Vilket problem försökte du först lösa, och när utvecklades projektet från ett experiment till något som Orca faktiskt kunde ta i drift?

När jag började på Orca fick jag bland annat i uppdrag att se över den övergripande partnerupplevelsen. Vi använde en tredjepartsplattform, men jag såg en möjlighet att skapa något modernare och smidigare för våra partner. Jag hade viss erfarenhet av applikationsutveckling, men arbetade inte själv som utvecklare. Tidigare samma sommar hade jag arbetat med konsumentapplikationer på en tredjepartsleverantörs plattform för appgenerering, så jag bestämde mig för att experimentera med vad jag själv kunde bygga med hjälp av AI.

Under en helg kunde jag skapa en enkel första version av det som blev vår Partner Success Platform, med funktioner som gick längre än det jag hade sett i traditionella partnerportaler. Dit hörde AI-drivna funktioner som matchning med idealkunder och coachning kring affärer. Vi lade till många fler applikationer på plattformen, till exempel certifieringsspårning och AI-genererade frågesporter, och gjorde hela certifieringsprocessen för våra partner spelifierad. Sedan började vi synkronisera data med vår Salesforce-plattform. Vändpunkten kom när vår vd såg den första versionen och insåg dess potential. Det var också då vi gick från experimenterande till att fråga oss vad som faktiskt krävdes för att göra något sådant här säkert och redo för produktion. Vårt säkerhetsteam blev involverat, och jag började arbeta nära Dudi Peretz för att säkra miljön innan arbetet slutligen verifierades oberoende av ett externt företag.

Du grundade tidigare ett programvaruutvecklingsföretag och har därför erfarenhet av hur applikationer traditionellt byggdes. Hur var det att bygga programvara med hjälp av naturligt språk och AI jämfört med att leda utvecklare, och var hade din egen ämneskunskap fortfarande störst betydelse?

Den största skillnaden var hastigheten. Vid traditionell programvaruutveckling är det vanligtvis flera steg mellan att få en idé, omvandla den till tekniska krav, låta utvecklare bygga den och sedan vidareutveckla resultatet. Med AI kunde jag beskriva vad jag ville ha, se hur det tog form och fortsätta finslipa det nästan omedelbart. Itereringen tar minuter i stället för dagar av möten med utvecklare, där man definierar önskat användargränssnitt och all databasmappning som behövs för att skapa funktionaliteten. Med AI-utveckling räcker det med en prompt på två meningar i stället för två dagars möten.

Men det innebär inte att expertis inte längre behövs. Det förändrar var den expertisen behövs. AI kan sänka den tekniska tröskeln för att bygga en applikation avsevärt, men den som leder arbetet måste fortfarande förstå vilket problem hen försöker lösa, hur en användbar upplevelse ser ut och vad applikationen i slutändan behöver åstadkomma för verksamheten. Det som överraskade mig mest var hur snabbt man kunde gå från en idé till något fungerande. Uppgifter som dataanalys, som tidigare kunde ta veckor, kan nu eventuellt utföras på en dag.

Orca har beskrivit den första fungerande versionen av partnerplattformen som något du byggde under en enda helg. Vad kunde AI påskynda dramatiskt, och vilka delar av arbetet med att bygga en applikation redo för produktion förblev svårare än de först verkade?

AI förkortade avståndet mellan en idé och en fungerande applikation dramatiskt. Jag kunde under en helg bygga funktioner som traditionellt skulle ha krävt en mycket längre utvecklingsprocess, och jag kunde fortsätta lägga till och ändra funktioner i mycket hög takt. Den hastigheten är både fantastisk och lite skrämmande.

AI eliminerade inte allt som krävs för att göra en applikation säker att använda i produktion. När vi väl hade bestämt oss för att det här kunde bli något verkligt behövde vårt säkerhetsteam bedöma miljön, åtgärda säkerhetsproblem och se till att applikationen hade tillräckligt skydd. Till slut anlitade vi ett externt företag för ytterligare en oberoende kontroll. AI gjorde alltså utvecklingen otroligt snabb, men ”det fungerar” och ”det är redo att användas säkert i ett företag” är fortfarande två helt olika trösklar.

AI-utvecklingsplattformens egna säkerhetsverktyg visade att applikationen var säker, men Orcas efterföljande granskning upptäckte problem med behörigheter och dataåtkomst. Vad lärde den erfarenheten dig om hur mycket förtroende företagsanvändare bör ha för de säkerhetsgarantier som AI-utvecklingsplattformar ger?

Det var förmodligen en av de viktigaste lärdomarna jag drog av erfarenheten. Plattformen hade egna funktioner för säkerhetsskanning, vilket gav mig en bra grund när jag byggde applikationen. Men granskningen tillsammans med vårt säkerhetsteam visade värdet av ytterligare ett granskningslager, särskilt när det gäller områden som behörigheter och dataåtkomst. Det blev tydligt att inbyggda säkerhetsverktyg är en viktig del av utvecklingsprocessen, men att de fungerar bäst tillsammans med den djupare förståelse och expertis som ett dedikerat säkerhetsteam kan bidra med.

Det är särskilt viktigt eftersom många av dem som nu kan bygga applikationer med AI inte är säkerhetsexperter. De kanske inte vet vilka frågor de ska ställa, vilka behörigheter som är för omfattande eller vilka konfigurationer som kan exponera data. Att utvecklingsplattformen säger att en applikation är säker kan inte vara processens sista steg. Innan en applikation publiceras eller ansluts till känsliga företagssystem behöver den fortfarande genomgå en omfattande säkerhetsgranskning som går längre än att kontrollera om applikationen klarar plattformens egna kontroller.

När säkerhetsteamet identifierade sårbarheter kunde du ofta föra tillbaka resultaten till AI-utvecklingsmiljön och generera korrigeringar på några minuter. Kan AI i grunden förändra säkerhetsåtgärderna, från en lång utvecklingscykel till en fortlöpande dialog mellan utvecklare och säkerhetsteam?

Det här är en av de mest spännande möjligheterna. När Dudi och säkerhetsteamet upptäckte problem kunde jag ta deras återkoppling, föra in den direkt i AI-utvecklingsmiljön och få korrigeringar framtagna mycket snabbt. Det öppnar för en betydligt tätare återkopplingsloop mellan den som bygger en applikation och teamet som ansvarar för att säkra den.

Historiskt sett kunde det ta betydligt längre tid att bygga och lansera programvara. Nu kan någon göra och publicera ändringar varje dag. Säkerhetsarbetet måste hålla samma tempo. Möjligheten ligger i att göra fortlöpande säkerhetsbedömningar till en del av utvecklingsprocessen, så att man kan identifiera ett problem, meddela utvecklaren, åtgärda det och ompröva applikationen betydligt snabbare.

Men snabbare åtgärder betyder inte att vi kan sänka kraven på validering. AI kan snabbt ta fram en korrigering, men säkerhetsteamen behöver fortfarande kunna verifiera att korrigeringen faktiskt har åtgärdat risken och inte skapat en ny.

Den resulterande Partner Success Platform innehåller AI-assistenter, pipelineanalys, kampanjgenerering och affärscoachning. Hur avgjorde ni vilka uppgifter AI skulle hantera direkt och vilka beslut som skulle ligga kvar hos den mänskliga partnern eller säljaren?

För mig var målet inte att ta bort människan ur partner- eller säljprocessen. Målet var att använda AI för att hjälpa människor att arbeta snabbare och dra bättre nytta av den information som redan finns tillgänglig. Affärscoachning är ett bra exempel: AI kan hjälpa till att hitta sätt att föra vidare en affärsmöjlighet som har blivit liggande i säljprocessen och ge någon ytterligare sammanhang eller rekommendera ett nästa steg.

Jag tycker att den viktiga skillnaden handlar om att AI snabbt kan hämta information från olika system, analysera hur relevant den är och sedan presentera den i en form som användaren kan agera utifrån. Plattformen bör göra partnern eller säljaren mer effektiv, samtidigt som människan fortsatt ansvarar för beslut som kräver affärsmässigt omdöme. Målet är att korta tiden från att en affärsmöjlighet upptäcks tills affären avslutas som vunnen, genom engagemang på plattformen.

AI gör det möjligt för anställda inom försäljning, marknadsföring, ekonomi och andra avdelningar att bygga egna applikationer utan att gå via utvecklingsavdelningen. Vilka grundläggande säkerhets- och styrningskontroller bör finnas på plats innan sådana applikationer får ansluta till kunddata, interna system eller molninfrastruktur?

Det första kravet är insyn. Organisationens policyer bör uppmuntra den här typen av utforskande och innovation, men det går inte att säkra en applikation man inte känner till. Genom att uppmuntra innovation ökar därför sannolikheten att anställda lyfter fram sina projekt i stället för att hålla dem dolda. Därefter behöver organisationer förstå vilka identiteter och behörigheter applikationen har, vilka data den kan komma åt, vilka tredjepartssystem den kommunicerar med och om dessa åtkomster verkligen behövs. Bana väg för innovation, men ha en process som stöder innovatörerna och uppfyller säkerhetskraven.

Principen om minsta möjliga behörighet blir särskilt viktig. En risk vi ser är att applikationer får mer omfattande åtkomst än de faktiskt behöver. Säkerhet kan inte heller vara en engångskontroll före lansering. När applikationer kan förändras fortlöpande måste organisationer också kunna ompröva dem fortlöpande.

Traditionell styrning av programvaruutveckling utformades för utvecklingsteam, pull requests, utgivningscykler och relativt kontrollerade driftsättningsflöden. Om verksamhetsanvändare nu kan ändra och driftsätta program kontinuerligt, hur behöver då företagens livscykel för programvaruutveckling förändras?

Den grundläggande utmaningen är att takten har förändrats. Traditionellt har programvara utvecklats och lanserats över tid genom relativt etablerade processer. Med AI-verktyg för utveckling kan någon potentiellt skapa och publicera något nytt varje dag. Säkerhets- och styrningsprocesser som bygger på återkommande kontrollpunkter kommer inte att räcka i en sådan miljö.

Vi behöver gå mot ett säkerhetsarbete som bedrivs kontinuerligt och kan hålla jämna steg med utvecklingscykeln. Det innebär att upptäcka vad som byggs, förstå hur det konfigureras och kopplas samman, granska det i takt med att det förändras och ge utvecklarna konkreta synpunkter som de snabbt kan omsätta i praktiken. Lösningen kan inte vara att hindra medarbetarna från att använda de här verktygen; produktivitetsmöjligheterna är alltför stora. Utmaningen är att skapa skyddsräcken som gör det möjligt att innovera på ett säkert sätt.

Du har jämfört framväxten av AI-byggda applikationer med en ännu mer svårhanterlig form av ”skugg-IT”. Vad gör den här generationen av skuggprogramvara potentiellt mer utmanande, och hur kan organisationer upptäcka applikationer som säkerhets- eller IT-team kanske inte ens känner till?

Traditionell skugg-IT handlade ofta om att medarbetare började använda en SaaS-applikation som IT inte hade godkänt. Det som är annorlunda nu är att medarbetarna själva kan skapa applikationen, och det kan gå otroligt snabbt. Någon kan bygga en applikation med ett personligt konto, integrera den med tredjepartssystem och eventuellt koppla den till företagsdata innan säkerhetsavdelningen ens vet att den finns.

Det är det som gör detta särskilt utmanande: det har blivit så enkelt att bygga att antalet applikationer och takten de förändras i snabbt kan överstiga vad traditionell styrning klarar av. CISO:er ställs inför samma grundläggande fråga: hur skyddar man något när man kanske inte ens vet vad som har byggts eller hur det är konfigurerat?

Upptäckt måste därför bli en central del av säkerhetsstrategin. Ett bra sätt att åstadkomma detta är att stödja innovatörerna och uppmuntra dem att utforska, men samtidigt registrera deras projekt. Organisationer behöver insyn inte bara i koden, utan också i vilka applikationer som körs i deras miljö, vilka identiteter och behörigheter som hör till dem, vilka data de kommer åt och vilka externa system de kommunicerar med.

Om du blickar flera år framåt, tror du att de flesta kunskapsarbetare kommer att bli någon form av programvarubyggare med hjälp av AI? Hur förändrar det i så fall rollerna för professionella utvecklare, säkerhetsteam och företagsledare?

Vi rör oss mot en värld där definitionen av en ”programvarubyggare” blir mycket bredare. AI gör det möjligt för personer som förstår ett verksamhetsproblem, men inte är traditionella utvecklare, att förvandla en idé till en fungerande applikation otroligt snabbt. Jag har själv upplevt det.

Jag tror inte att det gör professionella utvecklare eller säkerhetsteam mindre viktiga. Det förändrar var deras expertis behövs. Verksamhetsanvändare kan i allt högre grad bygga lösningar själva, medan utvecklare kan fokusera på mer komplexa tekniska problem och säkerhetsteam behöver skapa den insyn och de skyddsräcken som gör det möjligt för den här nya generationen av byggare att innovera på ett säkert sätt. Support och underhåll av applikationer får också en ny innebörd. ”Byggarna” är inte alltid de bästa ”förvaltarna”. De bidrar med visionen och förstår verksamhetens behov, men att stödja en applikation på lång sikt är fortfarande en uppgift som bäst hanteras av IT- och applikationsorganisationerna. För företagsledare innebär detta stora möjligheter, men också ett nytt ansvar. Om era team kan skapa programvara behöver ni se programvarurisk som en del av verksamheten – inte som något som enbart hör till utvecklingsavdelningen.

Tack för en fantastisk intervju. Läsare som vill veta mer om molnsäkerhet, AI-byggda applikationer och hur man skyddar företagsmiljöer bör besöka Orca Security.