Shannon McWilliams, hoofd wereldwijde distributie bij Orca Security – interviewreeks

Shannon McWilliams is hoofd wereldwijde distributie bij Orca Security. In die functie houdt hij zich bezig met het partnernetwerk van het bedrijf en de tools die dit ondersteunen. Eerder richtte hij een softwareontwikkelingsbedrijf op; daardoor heeft hij ervaring met het vertalen van zakelijke behoeften naar applicaties. Onlangs gebruikte hij AI-ontwikkelingstools om een eerste versie van Orca’s Partner Success Platform te bouwen. Samen met het beveiligingsteam bracht hij het project van een weekendprototype naar een systeem dat klaar is voor productie.

Orca Security biedt een cloudbeveiligingsplatform waarmee organisaties hun assets kunnen ontdekken, risico’s kunnen identificeren en prioriteren en cloudomgevingen kunnen beveiligen. De mogelijkheden omvatten onder meer kwetsbaarheden, onjuiste configuraties, identiteiten en machtigingen, gevoelige gegevens en AI-beveiliging. In dit interview bespreekt McWilliams hoe AI zakelijke gebruikers in staat stelt software te bouwen, waarom werkende applicaties nog steeds onafhankelijk op hun beveiliging moeten worden gecontroleerd en hoe doorlopende inventarisatie, minimale privileges en menselijk toezicht bedrijven kunnen helpen dit nieuwe ontwikkelmodel te beheersen.

Je kwam bij Orca Security werken als hoofd wereldwijde distributie en bouwde binnen enkele maanden zelf met AI een nieuw partnerplatform. Welk probleem wilde je aanvankelijk oplossen, en wanneer groeide het project uit van een experiment tot iets wat Orca daadwerkelijk in productie kon nemen?

Toen ik bij Orca begon, was een van de zaken waar ik naar moest kijken de algehele partnerervaring. We gebruikten een platform van een derde partij, maar ik zag een kans om iets moderners en gestroomlijnders voor onze partners te maken. Ik had enige ervaring met applicatieontwikkeling, maar was zelf geen ontwikkelaar. Eerder die zomer had ik gewerkt aan consumententoepassingen op een platform van een externe leverancier voor het genereren van apps. Daarom besloot ik te experimenteren met wat ik zelf met behulp van AI kon bouwen.

In één weekend kon ik een eenvoudige eerste versie maken van wat ons Partner Success Platform werd. Deze bood meer functionaliteit dan ik in traditionele partnerportalen zag, waaronder AI-gestuurde mogelijkheden zoals het vinden van ideale klanten en dealbegeleiding. We voegden nog veel meer toepassingen aan het platform toe, zoals het bijhouden van certificeringen en door AI gegenereerde quizzen, en maakten het hele certificeringstraject voor onze partners spelelementenrijk. Daarna begonnen we gegevens te synchroniseren met ons Salesforce-platform. Het keerpunt kwam toen onze CEO de eerste versie zag en het potentieel ervan inzag. Dat was ook het moment waarop we de stap zetten van experimenteren naar de vraag wat er nodig was om zoiets daadwerkelijk veilig en klaar voor productie te maken. Ons beveiligingsteam raakte erbij betrokken en ik ging nauw samenwerken met Dudi Peretz om de omgeving te beveiligen. Uiteindelijk liet ik dat werk onafhankelijk verifiëren door een extern bedrijf.

Je hebt eerder een softwareontwikkelingsbedrijf opgericht en weet dus hoe applicaties traditioneel werden gebouwd. Hoe verhoudt software bouwen met behulp van natuurlijke taal en AI zich tot het aansturen van ontwikkelaars, en op welke momenten was je eigen domeinkennis nog steeds het belangrijkst?

Het grootste verschil was de snelheid. Bij traditionele softwareontwikkeling zijn er doorgaans meerdere stappen tussen het ontstaan van een idee, het vertalen ervan naar technische vereisten, het laten bouwen door ontwikkelaars en het verder verfijnen van het resultaat. Met AI kon ik beschrijven wat ik wilde, zien hoe het vorm kreeg en het vrijwel meteen verder verfijnen. Het iteratieproces duurt minuten in plaats van dagen vol overleg met ontwikkelaars over de gewenste gebruikersinterface en alle databasemapping die nodig is om de functionaliteit te realiseren. Bij AI-ontwikkeling volstaat daarvoor een prompt van 2 zinnen, in plaats van 2 dagen overleg.

Maar daardoor is expertise niet overbodig. De plek waar die expertise van belang is, verandert. AI kan de technische drempel voor het bouwen van een applicatie aanzienlijk verlagen, maar degene die de AI aanstuurt, moet nog steeds begrijpen welk probleem die probeert op te lossen, hoe een bruikbare ervaring eruitziet en wat de applicatie uiteindelijk voor het bedrijf moet bereiken. Wat me het meest verraste, was hoe snel je van een idee naar iets werkends kunt gaan. Taken zoals gegevens analyseren, die voorheen weken konden kosten, kunnen nu mogelijk in één dag worden uitgevoerd.

Orca heeft de eerste werkende versie van het partnerplatform omschreven als iets wat je in één weekend hebt gebouwd. Welke onderdelen kon AI aanzienlijk versnellen, en welke aspecten van het bouwen van een productieklare applicatie bleven moeilijker dan ze aanvankelijk leken?

AI heeft de afstand tussen een idee en een werkende applicatie aanzienlijk verkleind. Ik kon in één weekend functionaliteit bouwen waarvoor traditioneel een veel langer ontwikkelproces nodig zou zijn geweest, en ik kon functies heel snel blijven toevoegen en aanpassen. Die snelheid is zowel geweldig als een beetje angstaanjagend.

AI nam niet alles weg wat nodig is om een applicatie veilig in productie te nemen. Toen we besloten dat dit iets concreets kon worden, moest ons beveiligingsteam de omgeving beoordelen, beveiligingsproblemen aanpakken en ervoor zorgen dat de applicatie goed was beveiligd. Uiteindelijk schakelden we een extern bedrijf in als extra validatielaag. AI maakte het bouwen dus ongelooflijk snel, maar ‘het werkt’ en ‘het is klaar om veilig binnen een onderneming te worden gebruikt’ blijven twee heel verschillende maatstaven.

De beveiligingstools van het AI-ontwikkelplatform gaven aan dat de applicatie veilig was, maar bij een latere beoordeling door Orca kwamen problemen met machtigingen en gegevenstoegang aan het licht. Wat heeft die ervaring je geleerd over hoeveel vertrouwen zakelijke gebruikers mogen stellen in de beveiligingsgaranties van AI-ontwikkelplatforms?

Dat was waarschijnlijk een van mijn belangrijkste lessen uit deze ervaring. Het platform had eigen mogelijkheden om de beveiliging te scannen, die tijdens het bouwen een nuttige basis vormden. Maar het beoordelingsproces met ons beveiligingsteam liet zien hoe waardevol een extra controleniveau is, vooral op gebieden als machtigingen en gegevenstoegang. Het bevestigde dat ingebouwde beveiligingstools een belangrijk onderdeel zijn van het ontwikkelproces, maar het best werken in combinatie met de diepgaande context en expertise die een gespecialiseerd beveiligingsteam kan bieden.

Dat is vooral belangrijk omdat veel mensen die nu met AI applicaties kunnen bouwen, geen beveiligingsexperts zijn. Ze weten misschien niet welke vragen ze moeten stellen, welke machtigingen te ruim zijn of welke configuraties gegevens kunnen blootstellen. De mededeling van het ontwikkelplatform dat een applicatie veilig is, kan niet het einde van het proces zijn. Voordat een applicatie wordt gepubliceerd of gekoppeld aan gevoelige bedrijfssystemen, is nog steeds een uitgebreide beveiligingsbeoordeling nodig die verder kijkt dan alleen de vraag of de applicatie de eigen controles van het platform doorstaat.

Wanneer het beveiligingsteam kwetsbaarheden vaststelde, kon je die bevindingen vaak terugkoppelen aan de AI-ontwikkelomgeving en binnen enkele minuten oplossingen laten genereren. Kan AI het verhelpen van beveiligingsproblemen fundamenteel veranderen: van een langdurige ontwikkelcyclus naar een doorlopend gesprek tussen bouwers en beveiligingsteams?

Dit is een van de spannendste mogelijkheden. Wanneer Dudi en het beveiligingsteam problemen vaststelden, kon ik hun feedback rechtstreeks in de AI-ontwikkelomgeving invoeren en heel snel oplossingen laten genereren. Daardoor kan een veel kortere feedbacklus ontstaan tussen degene die een applicatie bouwt en het team dat verantwoordelijk is voor de beveiliging ervan.

Vroeger kon het bouwen en uitbrengen van software veel langer duren. Nu kan iemand elke dag wijzigingen aanbrengen en publiceren. Beveiliging moet in hetzelfde tempo kunnen werken. De kans ligt erin doorlopende beveiligingsbeoordeling onderdeel te maken van het ontwikkelproces, zodat je een probleem kunt vaststellen, aan de bouwer kunt terugkoppelen, het kunt verhelpen en de applicatie veel sneller opnieuw kunt beoordelen.

Maar een probleem snel verhelpen betekent niet dat we de lat voor validatie lager kunnen leggen. AI kan snel een oplossing genereren; beveiligingsteams moeten nog steeds kunnen nagaan of die oplossing het risico daadwerkelijk heeft weggenomen en geen nieuw risico heeft geïntroduceerd.

Het resulterende Partner Success Platform omvat AI-assistenten, inzicht in de verkooppijplijn, het genereren van campagnes en dealcoaching. Hoe heb je bepaald welke taken AI rechtstreeks moest uitvoeren en welke beslissingen bij de menselijke partner of verkoper moesten blijven?

Voor mij was het doel niet om de mens uit het partner- of verkoopproces te halen. Ik wilde AI inzetten om mensen sneller te laten werken en de beschikbare informatie beter te benutten. Dealcoaching is daar een goed voorbeeld van: AI kan helpen manieren te vinden om een verkoopkans die al een tijd in de pijplijn zit verder te brengen, en iemand extra context of een aanbevolen volgende stap bieden.

Het onderscheid wordt volgens mij belangrijk wanneer AI snel informatie uit verschillende systemen kan ophalen, de relevantie ervan kan analyseren en die vervolgens kan presenteren in een vorm waarmee de gebruiker aan de slag kan. Het platform moet de partner of verkoper effectiever maken, terwijl de mens verantwoordelijk blijft voor beslissingen waarvoor zakelijk inzicht nodig is. Het doel is om via interactie met het platform de tijd tussen het ontdekken van een deal en het sluiten ervan als gewonnen te verkorten.

AI maakt het voor medewerkers in verkoop, marketing, financiën en andere afdelingen mogelijk om zelf applicaties te bouwen zonder tussenkomst van de afdeling engineering. Welke minimale beveiligings- en governancemaatregelen moeten van kracht zijn voordat deze applicaties verbinding mogen maken met klantgegevens, interne systemen of cloudinfrastructuur?

De eerste vereiste is inzicht. Het organisatiebeleid moet dit soort verkenning en innovatie weliswaar aanmoedigen, maar een organisatie kan een applicatie waarvan ze het bestaan niet kent niet beveiligen. Door innovatie aan te moedigen, is de kans groter dat medewerkers hun projecten naar voren brengen in plaats van ze verborgen te houden. Vervolgens moeten organisaties inzicht krijgen in de identiteiten en machtigingen van de applicatie, de gegevens waartoe deze toegang heeft, de systemen van derden waarmee deze communiceert en de vraag of die toegangsrechten echt nodig zijn. Schep ruimte voor innovatie, maar zorg voor een proces dat vernieuwers ondersteunt en aan de beveiligingseisen voldoet.

Minimale toegangsrechten zijn bijzonder belangrijk. Een van de risico’s die we zien, is dat applicaties ruimere toegang krijgen dan ze daadwerkelijk nodig hebben. Bovendien kan beveiliging niet beperkt blijven tot een eenmalige controle vóór de lancering. Als applicaties voortdurend kunnen veranderen, moeten organisaties ze ook doorlopend opnieuw kunnen beoordelen.

Traditioneel softwarebeheer was ingericht op engineeringteams, pull requests, releasecycli en relatief gecontroleerde implementatiepijplijnen. Hoe moet de levenscyclus van softwareontwikkeling binnen bedrijven veranderen nu zakelijke gebruikers applicaties doorlopend kunnen aanpassen en implementeren?

De grootste uitdaging is dat het tempo is veranderd. Traditioneel werd software in de loop der tijd ontwikkeld en uitgebracht volgens relatief vaste processen. Met AI-ontwikkelingstools kan iemand mogelijk elke dag iets nieuws maken en publiceren. Beveiligings- en governanceprocessen die zijn gebaseerd op periodieke controlemomenten zijn in die omgeving niet langer toereikend.

We moeten toe naar beveiliging die doorlopend werkt en gelijke tred kan houden met die ontwikkelcyclus. Dat betekent in kaart brengen wat er wordt gebouwd, begrijpen hoe het is geconfigureerd en gekoppeld, het scannen wanneer het verandert en bouwers bruikbare feedback geven waarmee ze snel aan de slag kunnen. Medewerkers verbieden deze tools te gebruiken, is geen oplossing; de kansen om de productiviteit te verhogen zijn daarvoor te groot. De uitdaging is om waarborgen te creëren die innovatie veilig mogelijk maken.

Je hebt de opkomst van met AI gebouwde applicaties vergeleken met een nog lastigere vorm van ‘schaduw-IT’. Wat maakt deze nieuwe generatie schaduwsoftware mogelijk uitdagender, en hoe kunnen organisaties applicaties opsporen waarvan beveiligings- of IT-teams niet eens weten dat ze bestaan?

Bij traditionele schaduw-IT ging het vaak om medewerkers die een SaaS-applicatie in gebruik namen zonder goedkeuring van de IT-afdeling. Het verschil is nu dat medewerkers de applicatie zelf kunnen maken, en dat ongelooflijk snel kunnen doen. Iemand kan met een persoonlijk account een applicatie bouwen, die integreren met systemen van derden en mogelijk koppelen aan bedrijfsgegevens voordat de beveiligingsafdeling überhaupt weet dat de applicatie bestaat.

Dat maakt dit bijzonder uitdagend: applicaties bouwen is zo eenvoudig geworden dat het aantal applicaties en de snelheid waarmee ze veranderen de traditionele governance al snel kunnen overstijgen. CISO’s staan voor dezelfde fundamentele vraag: hoe beveilig je iets als je misschien niet eens weet wat er is gebouwd of hoe het is geconfigureerd?

Opsporing moet daarom een kernonderdeel van de beveiligingsstrategie worden. Innovators ondersteunen en hen aanmoedigen om op onderzoek uit te gaan, maar wel hun projecten te laten registreren, is een uitstekende manier om applicaties in kaart te brengen. Organisaties moeten niet alleen inzicht hebben in de code, maar ook in de applicaties die in hun omgeving draaien, de identiteiten en toegangsrechten die eraan zijn gekoppeld, de gegevens waartoe ze toegang hebben en de externe systemen waarmee ze communiceren.

Verwacht je dat de meeste kenniswerkers over een paar jaar met behulp van AI op een of andere manier softwarebouwers zullen zijn? Zo ja, hoe verandert dat de rol van professionele ontwikkelaars, beveiligingsteams en bedrijfsleiders binnen organisaties?

We bewegen naar een wereld waarin de definitie van een ‘softwarebouwer’ veel breder wordt. Dankzij AI kunnen mensen die een zakelijk probleem begrijpen, maar geen traditionele ontwikkelaars zijn, ongelooflijk snel een idee omzetten in een werkende applicatie. Dat heb ik zelf ervaren.

Ik denk niet dat professionele ontwikkelaars of beveiligingsteams daardoor minder belangrijk worden. Hun expertise is alleen op andere gebieden nodig. Zakelijke gebruikers kunnen steeds vaker zelf oplossingen bouwen, terwijl ontwikkelaars zich kunnen richten op complexere technische problemen en beveiligingsteams moeten zorgen voor het inzicht en de waarborgen waarmee deze nieuwe generatie bouwers veilig kan innoveren. Ook de ondersteuning en het onderhoud van applicaties krijgen een nieuw perspectief. ‘Bouwers’ zijn niet altijd de beste ‘beheerders’. Zij brengen de visie en de zakelijke behoefte mee, maar applicaties op de lange termijn ondersteunen blijft een taak die het best past bij IT- en applicatieorganisaties. Voor bedrijfsleiders biedt dit enorme kansen, maar brengt het ook nieuwe verantwoordelijkheden met zich mee. Als je teams software kunnen maken, moet je softwaregerelateerde risico’s beschouwen als onderdeel van de bedrijfsvoering — niet als iets dat alleen bij engineering hoort.

Bedankt voor het boeiende interview. Lezers die meer willen weten over cloudbeveiliging, met AI gebouwde applicaties en het beveiligen van bedrijfsomgevingen, kunnen terecht bij Orca Security.