Shannon McWilliams, global distribusjonssjef i Orca Security – intervjuserie

Shannon McWilliams er global distribusjonssjef i Orca Security, der arbeidet hans omfatter selskapets partnerøkosystem og verktøyene som støtter det. Han har tidligere grunnlagt et programvareutviklingsselskap og har erfaring med å omsette forretningsbehov til applikasjoner. I det siste brukte han KI-utviklingsverktøy til å bygge en tidlig versjon av Orcas Partner Success Platform. Sammen med sikkerhetsteamet arbeidet han med å videreutvikle prosjektet fra en helgeprototyp til et system som er klart for produksjonssetting.

Orca Security tilbyr en plattform for skysikkerhet som hjelper organisasjoner med å oppdage ressurser, identifisere og prioritere risikoer og beskytte skymiljøer. Plattformens funksjoner dekker blant annet sårbarheter, feilkonfigurasjoner, identiteter og tillatelser, sensitive data og KI-sikkerhet. I dette intervjuet snakker McWilliams om hvordan KI gjør det mulig for forretningsbrukere å bygge programvare, hvorfor applikasjoner som fungerer, fortsatt må gjennomgås uavhengig med tanke på sikkerhet, og hvordan kontinuerlig oppdagelse, minste privilegium og menneskelig tilsyn kan hjelpe virksomheter med å håndtere denne nye utviklingsmodellen.

Du begynte i Orca Security som global distribusjonssjef, og i løpet av bare noen måneder endte du opp med å bygge en ny partnerplattform selv ved hjelp av KI. Hvilket problem prøvde du først å løse, og når utviklet prosjektet seg fra et eksperiment til noe Orca faktisk kunne sette i produksjon?

Da jeg begynte i Orca, var en av oppgavene jeg fikk, å se på den samlede partneropplevelsen. Vi brukte en tredjepartsplattform, men jeg så en mulighet til å lage noe mer moderne og strømlinjeformet for partnerne våre. Jeg hadde noe erfaring med applikasjonsutvikling, men var ikke utvikler selv. Tidligere den sommeren hadde jeg jobbet med forbrukerapplikasjoner på en tredjepartsleverandørs plattform for appgenerering, så jeg bestemte meg for å eksperimentere med hva jeg kunne bygge selv ved hjelp av KI.

I løpet av en helg klarte jeg å lage en enkel førsteversjon av det som ble Partner Success Platform, med funksjoner som gikk lenger enn det jeg hadde sett i tradisjonelle partnerportaler, blant annet KI-drevne funksjoner som matching mot ideelle kunder og veiledning i forbindelse med avtaler. Vi la til mange flere applikasjoner i plattformen, som sporing av sertifiseringer og KI-genererte quizer, og gjorde hele sertifiseringsprosessen mer spillbasert for partnerne våre. Deretter begynte vi å synkronisere data med Salesforce-plattformen vår. Vendepunktet kom da toppsjefen vår så den første versjonen og innså hvilket potensial den hadde. Det var også da vi gikk fra eksperimentering til å spørre oss hva som faktisk skulle til for å gjøre noe slikt sikkert og klart for produksjonssetting. Sikkerhetsteamet vårt ble involvert, og jeg begynte å samarbeide tett med Dudi Peretz om å sikre miljøet, før arbeidet til slutt ble verifisert uavhengig av et eksternt firma.

Du grunnla tidligere et programvareutviklingsselskap og har derfor erfaring med hvordan applikasjoner tradisjonelt ble utviklet. Hvordan var det å bygge programvare ved hjelp av naturlig språk og KI, sammenlignet med å lede utviklere, og hvor var din egen fagkunnskap fortsatt viktigst?

Den største forskjellen var hastigheten. I tradisjonell programvareutvikling er det vanligvis flere trinn fra man får en idé, til den omsettes til tekniske krav, utviklerne bygger løsningen og man deretter videreutvikler resultatet. Med KI kunne jeg beskrive hva jeg ønsket, se det ta form og fortsette å forbedre det nesten umiddelbart. Iterasjonsprosessen tar minutter i stedet for dager med møter med utviklere, der man definerer ønsket brukergrensesnitt og all datatilordning som trengs for å lage funksjonaliteten. Med KI-utvikling krever dette en instruks på 2 setninger, ikke 2 dager med møter.

Men det fjerner ikke behovet for fagkunnskap. Det endrer hvor den fagkunnskapen er viktig. KI kan senke den tekniske terskelen for å bygge en applikasjon dramatisk, men personen som styrer arbeidet, må fortsatt forstå problemet som skal løses, hvordan en god brukeropplevelse ser ut, og hva applikasjonen til syvende og sist skal oppnå for virksomheten. Det som overrasket meg mest, var hvor raskt man kunne gå fra en idé til noe funksjonelt. Oppgaver som dataanalyse, som tidligere kunne tatt flere uker, kan nå kanskje utføres på én dag.

Orca har omtalt den første fungerende versjonen av partnerplattformen som noe du bygde på én helg. Hva kunne KI få fart på i særlig stor grad, og hvilke deler av det å bygge en applikasjon som er klar for produksjonssetting, viste seg å være vanskeligere enn de først så ut til?

KI reduserte avstanden mellom en idé og en fungerende applikasjon dramatisk. Jeg kunne bygge funksjonalitet på én helg som tradisjonelt ville krevd en mye lengre utviklingsprosess, og jeg kunne fortsette å legge til og endre funksjoner svært raskt. Den hastigheten er både fantastisk og litt skremmende.

KI fjernet ikke alt som kreves for å gjøre en applikasjon trygg å sette i produksjon. Da vi bestemte oss for at dette kunne bli noe reelt, måtte sikkerhetsteamet vårt vurdere miljøet, håndtere sikkerhetsproblemer og sørge for at applikasjonen var tilstrekkelig sikret. Til slutt hentet vi inn et eksternt firma som et ekstra ledd i valideringen. KI gjorde altså utviklingen utrolig rask, men «det fungerer» og «det er klart til å brukes trygt i en virksomhet» er fortsatt to helt forskjellige terskler.

AI-utviklingsplattformens egne sikkerhetsverktøy viste at applikasjonen var sikker, men Orcas etterfølgende gjennomgang avdekket problemer knyttet til tillatelser og datatilgang. Hva lærte du av denne erfaringen om hvor stor tillit bedriftsbrukere bør ha til sikkerhetsgarantiene fra AI-utviklingsplattformer?

Det var sannsynligvis en av de viktigste lærdommene jeg tok med meg fra erfaringen. Plattformen hadde egne funksjoner for sikkerhetsskanning, som ga et nyttig utgangspunkt mens jeg bygde. Men gjennomgangen sammen med sikkerhetsteamet vårt viste meg verdien av et ekstra lag med kontroll, særlig på områder som tillatelser og datatilgang. Det bekreftet at innebygde sikkerhetsverktøy er en viktig del av utviklingsprosessen, men at de fungerer best sammen med den dypere innsikten og kompetansen et dedikert sikkerhetsteam kan bidra med.

Dette er særlig viktig fordi mange av dem som nå kan bygge applikasjoner med AI, ikke er sikkerhetseksperter. De vet kanskje ikke hvilke spørsmål de bør stille, hvilke tillatelser som er for vidtrekkende, eller hvilke konfigurasjoner som kan eksponere data. At utviklingsplattformen sier at en applikasjon er sikker, kan ikke være siste steg i prosessen. Før en applikasjon publiseres eller kobles til sensitive bedriftssystemer, trenger den fortsatt en grundig sikkerhetsgjennomgang som går lenger enn å kontrollere om applikasjonen bare består plattformens egne tester.

Da sikkerhetsteamet avdekket sårbarheter, kunne du ofte føre funnene tilbake til AI-utviklingsmiljøet og få generert rettelser i løpet av få minutter. Kan AI fundamentalt endre sikkerhetsutbedring fra en langvarig utviklingssyklus til en kontinuerlig dialog mellom dem som bygger applikasjonene, og sikkerhetsteamene?

Dette er en av de mest spennende mulighetene. Da Dudi og sikkerhetsteamet avdekket problemer, kunne jeg ta tilbakemeldingene deres, legge dem direkte inn i AI-utviklingsmiljøet og få generert rettelser svært raskt. Det åpner for en langt tettere tilbakemeldingssløyfe mellom personen som bygger en applikasjon, og teamet som har ansvaret for å sikre den.

Tidligere kunne det ta mye lengre tid å utvikle og lansere programvare. Nå kan noen gjøre endringer og publisere dem hver dag. Sikkerhetsarbeidet må holde samme tempo. Muligheten ligger i å gjøre kontinuerlig sikkerhetsvurdering til en del av utviklingsprosessen, slik at man raskere kan oppdage et problem, formidle det til den som bygger applikasjonen, utbedre det og vurdere applikasjonen på nytt.

Men raskere utbedring betyr ikke at vi kan senke kravene til validering. AI kan raskt generere en rettelse, men sikkerhetsteamene trenger fortsatt en måte å kontrollere at rettelsen faktisk håndterte risikoen og ikke introduserte en ny.

Den resulterende Partner Success Platform omfatter AI-assistenter, innsikt i salgspipelinen, kampanjegenerering og salgsveiledning. Hvordan avgjorde du hvilke oppgaver AI skulle håndtere direkte, og hvilke beslutninger partneren eller selgeren burde ta selv?

For meg var ikke målet å fjerne mennesket fra partner- eller salgsprosessen. Målet var å bruke AI til å hjelpe folk med å jobbe raskere og utnytte informasjonen de allerede har tilgang til, bedre. Salgsveiledning er et godt eksempel: AI kan bidra til å identifisere måter å bringe videre en salgsmulighet som har blitt liggende i salgspipelinen, og gi noen mer kontekst eller anbefale et neste steg.

Etter min mening blir skillet viktig når AI raskt kan hente informasjon fra ulike systemer, vurdere hvor relevant den er og presentere den slik at brukeren kan handle ut fra den. Plattformen bør gjøre partneren eller selgeren mer effektiv, samtidig som mennesket fortsatt står til ansvar for beslutninger som krever forretningsmessig skjønn. Målet er å korte ned tiden fra en salgsmulighet oppdages til avtalen er vunnet, gjennom bruk av plattformen.

AI gjør det mulig for ansatte innen salg, markedsføring, økonomi og andre avdelinger å bygge egne applikasjoner uten å gå veien om utviklingsavdelingen. Hvilke grunnleggende sikkerhets- og styringstiltak bør være på plass før disse applikasjonene får koble seg til kundedata, interne systemer eller skyinfrastruktur?

Det første kravet er oversikt. Retningslinjene i organisasjonen bør oppmuntre til denne typen utforsking og innovasjon, men en organisasjon kan ikke sikre en applikasjon den ikke vet finnes. Oppmuntring til innovasjon gjør det derfor mer sannsynlig at ansatte legger fram prosjektene sine, i stedet for å holde dem skjult. Deretter må organisasjoner forstå hvilke identiteter og tillatelser applikasjonen har, hvilke data den har tilgang til, hvilke tredjepartssystemer den kommuniserer med, og om disse rettighetene faktisk er nødvendige. Legg til rette for at innovasjonen kan blomstre, men sørg for å ha en prosess som støtter dem som innoverer, og som oppfyller sikkerhetskravene.

Prinsippet om minste privilegium blir særlig viktig. En av risikoene vi ser, er at applikasjoner får bredere tilgang enn de faktisk trenger. Sikkerhet kan heller ikke være en engangskontroll før lansering. Når applikasjoner kan endres kontinuerlig, må organisasjoner også kunne vurdere dem på nytt kontinuerlig.

Tradisjonell styring av programvareutvikling var utformet med tanke på utviklingsteam, pull requests, utgivelsessykluser og relativt kontrollerte utrullingsløp. Hvis forretningsbrukere nå kan endre og distribuere applikasjoner kontinuerlig, hvordan må livssyklusen for utvikling av virksomhetsprogramvare endres?

Den grunnleggende utfordringen er at utviklingstakten har endret seg. Tradisjonelt ble programvare utviklet og lansert over tid gjennom relativt etablerte prosesser. Med AI-utviklingsverktøy kan noen potensielt lage og publisere noe nytt hver eneste dag. Sikkerhets- og styringsprosesser som bygger på periodiske kontrollpunkter, vil ikke være tilstrekkelige i en slik situasjon.

Vi må gå over til sikkerhet som fungerer kontinuerlig, og som kan holde tritt med denne utviklingssyklusen. Det innebærer å finne ut hva som utvikles, forstå hvordan det er konfigurert og tilkoblet, skanne det etter hvert som det endres, og gi utviklerne konkrete tilbakemeldinger som de raskt kan ta i bruk. Løsningen kan ikke være å hindre ansatte i å bruke disse verktøyene; produktivitetsgevinsten er altfor stor. Utfordringen er å etablere rammer som gjør det mulig å innovere på en trygg måte.

Du har sammenlignet fremveksten av AI-bygde applikasjoner med en enda mer krevende versjon av «skygge-IT». Hva gjør denne generasjonen av skyggeprogramvare potensielt mer utfordrende, og hvordan kan organisasjoner oppdage applikasjoner som sikkerhets- eller IT-teamene kanskje ikke engang vet eksisterer?

Tradisjonell skygge-IT handlet ofte om at ansatte tok i bruk en SaaS-applikasjon som IT-avdelingen ikke hadde godkjent. Det som er annerledes nå, er at ansatte kan lage applikasjonen selv, og det kan de gjøre utrolig raskt. Noen kan bygge en applikasjon via en personlig konto, integrere den med tredjepartssystemer og potensielt koble den til virksomhetens data før sikkerhetsavdelingen i det hele tatt vet at den finnes.

Det er dette som gjør situasjonen særlig utfordrende: Det har blitt så enkelt å bygge at antallet applikasjoner og tempoet de endres i, raskt kan overgå tradisjonell styring. Sikkerhetsdirektører står overfor det samme grunnleggende spørsmålet: Hvordan sikrer man noe når man kanskje ikke engang vet hva som er bygget, eller hvordan det er konfigurert?

Oppdagelse må derfor bli en sentral del av sikkerhetsstrategien. En god måte å få oversikt på er å støtte innovatørene, oppmuntre dem til å utforske og samtidig be dem registrere prosjektene sine. Organisasjoner trenger innsyn ikke bare i koden, men også i applikasjonene som kjører i miljøet deres, identitetene og tillatelsene som er knyttet til dem, dataene de får tilgang til, og de eksterne systemene de kommuniserer med.

Hvis vi ser flere år fram i tid, tror du at de fleste kunnskapsarbeidere vil bli en eller annen form for programvareutvikler ved hjelp av AI? Hvis det er tilfelle, hvordan endrer det rollene til profesjonelle utviklere, sikkerhetsteam og bedriftsledere i virksomheten?

Vi beveger oss mot en verden der begrepet «programvareutvikler» får en langt bredere betydning. AI gjør det mulig for folk som forstår et forretningsproblem, men ikke er tradisjonelle utviklere, å gjøre en idé om til en fungerende applikasjon utrolig raskt. Det har jeg selv erfart.

Jeg tror ikke det gjør profesjonelle utviklere eller sikkerhetsteam mindre viktige. Det endrer hvor ekspertisen deres trengs. Forretningsbrukere kan i stadig større grad utvikle løsninger selv, mens utviklere kan konsentrere seg om mer komplekse tekniske problemer, og sikkerhetsteam må sørge for den synligheten og de rammene som gjør det mulig for denne nye generasjonen utviklere å innovere på en trygg måte. Applikasjonsstøtte og -vedlikehold får også et nytt perspektiv. «Utviklere» er ikke alltid de beste «vedlikeholderne». De bidrar med visjonen og forretningsbehovet, men langsiktig støtte til en applikasjon er fortsatt en oppgave som egner seg best for IT- og applikasjonsorganisasjonene. For bedriftsledere gir dette enorme muligheter, men også et nytt ansvar. Hvis teamene deres kan utvikle programvare, må dere ta programvarerisiko med i betraktningen som en del av virksomheten – ikke se på den som noe som bare hører hjemme i utviklingsavdelingen.

Takk for et flott intervju. Lesere som ønsker å lære mer om skysikkerhet, AI-bygde applikasjoner og sikring av virksomhetsmiljøer, bør besøke Orca Security.