Shannon McWilliams, responsabile della distribuzione globale presso Orca Security – Serie di interviste

Shannon McWilliams è responsabile della distribuzione globale presso Orca Security, dove si occupa dell’ecosistema di partner dell’azienda e degli strumenti che lo supportano. Avendo fondato in precedenza una società di sviluppo software, ha maturato esperienza nel tradurre le esigenze aziendali in applicazioni. Più di recente, ha utilizzato strumenti di sviluppo basati sull’IA per realizzare una prima versione della Partner Success Platform di Orca, collaborando con il team di sicurezza per trasformare il progetto da prototipo sviluppato in un fine settimana a sistema pronto per la produzione.

Orca Security offre una piattaforma di sicurezza cloud che aiuta le organizzazioni a individuare le risorse, identificare e definire le priorità dei rischi e proteggere gli ambienti cloud. Le sue funzionalità riguardano, tra gli altri ambiti, vulnerabilità, configurazioni errate, identità e autorizzazioni, dati sensibili e sicurezza dell’IA. In questa intervista, McWilliams spiega come l’IA consenta agli utenti aziendali di sviluppare software, perché le applicazioni funzionanti debbano comunque essere sottoposte a verifiche di sicurezza indipendenti e in che modo il rilevamento continuo, il principio del privilegio minimo e la supervisione umana possano aiutare le imprese a gestire questo nuovo modello di sviluppo.

Sei entrato in Orca Security come responsabile della distribuzione globale e, nel giro di pochi mesi, ti sei ritrovato a creare da solo una nuova piattaforma per i partner usando l’IA. Quale problema volevi risolvere inizialmente e quando il progetto si è trasformato da esperimento in qualcosa che Orca potesse effettivamente mettere in produzione?

Quando sono entrato in Orca, tra le cose di cui mi è stato chiesto di occuparmi c’era l’esperienza complessiva dei partner. Utilizzavamo una piattaforma di terze parti, ma ho intravisto l’opportunità di crearne una più moderna e intuitiva per i nostri partner. Avevo una certa esperienza nello sviluppo di applicazioni, ma non lavoravo come sviluppatore. All’inizio di quell’estate avevo lavorato ad applicazioni per i consumatori con un fornitore di piattaforme di terze parti per la generazione di app, così ho deciso di sperimentare e vedere cosa riuscissi a costruire da solo con l’IA.

Nel corso di un fine settimana sono riuscito a creare una prima versione essenziale di quella che è diventata la nostra Partner Success Platform, con funzionalità che andavano oltre quelle che vedevo nei tradizionali portali per i partner, tra cui strumenti basati sull’IA come l’abbinamento con i clienti ideali e il supporto nella gestione delle trattative. Abbiamo aggiunto molte altre applicazioni alla piattaforma, come il monitoraggio delle certificazioni e quiz generati dall’IA, e abbiamo reso ludico l’intero processo di certificazione per i nostri partner; poi abbiamo iniziato a sincronizzare i dati con la nostra piattaforma Salesforce. La svolta è arrivata quando il nostro CEO ha visto la versione iniziale e ne ha riconosciuto il potenziale. È stato anche allora che siamo passati dalla sperimentazione a chiederci cosa sarebbe servito, concretamente, per rendere sicura e pronta per la produzione una soluzione del genere. È stato coinvolto il nostro team di sicurezza e ho iniziato a lavorare a stretto contatto con Dudi Peretz per proteggere l’ambiente, prima di far verificare in modo indipendente il lavoro da una società esterna.

In precedenza hai fondato una società di sviluppo software, quindi conosci i metodi tradizionali di realizzazione delle applicazioni. In che modo sviluppare software attraverso l’IA in linguaggio naturale è stato diverso dal coordinare sviluppatori e in quali aspetti la tua esperienza nel settore è rimasta più importante?

La differenza più grande è stata la velocità. Nello sviluppo software tradizionale, di solito ci sono diversi passaggi tra l’ideazione, la sua traduzione in requisiti tecnici, la realizzazione da parte degli sviluppatori e le successive revisioni. Con l’IA potevo descrivere ciò che volevo, vedere il risultato prendere forma e continuare a perfezionarlo quasi subito. Il processo di revisione richiede minuti, anziché giorni di riunioni con gli sviluppatori per definire l’interfaccia utente desiderata e tutte le mappature del database necessarie a realizzare le funzionalità. Con lo sviluppo basato sull’IA, bastano 2 frasi di prompt, non 2 giorni di riunioni.

Ma questo non elimina la necessità di competenze specifiche: cambia il modo in cui sono importanti. L’IA può abbassare drasticamente la barriera tecnica per realizzare un’applicazione, ma chi la guida deve comunque capire quale problema intende risolvere, che cosa rende efficace l’esperienza d’uso e quale obiettivo aziendale l’applicazione deve raggiungere. Ciò che mi ha sorpreso di più è stata la rapidità con cui si può passare da un’idea a qualcosa di funzionante. Attività come l’analisi dei dati, che prima potevano richiedere settimane, ora potrebbero essere completate in un giorno.

Orca ha descritto la prima versione funzionante della piattaforma per i partner come un progetto che hai realizzato in un solo fine settimana. Quali aspetti l’IA ha accelerato drasticamente e quali fasi della creazione di un’applicazione pronta per la produzione si sono rivelate più difficili del previsto?

L’IA ha ridotto drasticamente la distanza tra un’idea e un’applicazione funzionante. In un fine settimana ho potuto creare funzionalità che, con i metodi tradizionali, avrebbero richiesto un processo di sviluppo molto più lungo, e ho potuto continuare ad aggiungere e modificare funzionalità a una velocità straordinaria. Questa rapidità è al tempo stesso incredibile e un po’ spaventosa.

L’IA non ha eliminato tutto ciò che serve per rendere un’applicazione sicura per la produzione. Quando abbiamo deciso che poteva diventare una soluzione concreta, il nostro team di sicurezza ha dovuto valutare l’ambiente, affrontare i problemi di sicurezza e assicurarsi che l’applicazione fosse protetta adeguatamente. Alla fine abbiamo coinvolto una società esterna come ulteriore livello di verifica. Quindi l’IA ha reso lo sviluppo incredibilmente rapido, ma «funziona» ed «è pronta per operare in sicurezza in un’azienda» sono ancora due traguardi molto diversi.

Gli strumenti di sicurezza integrati nella piattaforma di sviluppo IA indicavano che l’applicazione era sicura, eppure la successiva revisione di Orca ha rivelato problemi relativi alle autorizzazioni e all’accesso ai dati. Cosa ti ha insegnato questa esperienza sul grado di fiducia che gli utenti aziendali dovrebbero riporre nelle garanzie di sicurezza offerte dalle piattaforme di sviluppo IA?

Probabilmente è stata una delle lezioni più importanti che ho tratto da questa esperienza. La piattaforma disponeva di funzionalità proprie per l’analisi della sicurezza, che durante lo sviluppo mi hanno fornito un utile punto di partenza. Tuttavia, il processo di revisione con il nostro team di sicurezza mi ha mostrato il valore di aggiungere un ulteriore livello di controllo, soprattutto in ambiti come le autorizzazioni e l’accesso ai dati. Mi ha confermato che gli strumenti di sicurezza integrati sono una parte importante del processo di sviluppo, ma funzionano al meglio se affiancati dal contesto più approfondito e dalle competenze che può apportare un team di sicurezza dedicato.

È particolarmente importante perché oggi molte delle persone in grado di creare applicazioni con l’IA non sono esperte di sicurezza. Potrebbero non sapere quali domande porsi, quali autorizzazioni siano troppo ampie o quali configurazioni possano esporre i dati. Il fatto che la piattaforma di sviluppo dichiari sicura un’applicazione non può segnare la fine del processo. Prima di essere pubblicata o collegata a sistemi aziendali sensibili, l’applicazione deve comunque essere sottoposta a una revisione completa della sicurezza, che vada oltre la semplice verifica del superamento dei controlli interni della piattaforma.

Quando il team di sicurezza individuava delle vulnerabilità, spesso riuscivi a inserire i risultati dell’analisi nell’ambiente di sviluppo IA e a generare correzioni in pochi minuti. L’IA può trasformare radicalmente la correzione delle vulnerabilità, passando da un lungo ciclo di sviluppo a un confronto continuo tra chi crea le applicazioni e i team di sicurezza?

È una delle possibilità più entusiasmanti. Quando Dudi e il team di sicurezza individuavano dei problemi, potevo raccogliere il loro riscontro, inserirlo direttamente nell’ambiente di sviluppo IA e far generare correzioni in tempi brevissimi. Questo può creare le condizioni per un ciclo di riscontro molto più rapido tra chi sviluppa un’applicazione e il team responsabile della sua sicurezza.

In passato, lo sviluppo e il rilascio del software potevano richiedere molto più tempo. Oggi, qualcuno può apportare e pubblicare modifiche ogni giorno. La sicurezza deve operare alla stessa velocità. L’opportunità consiste nell’integrare la valutazione continua della sicurezza nel processo di sviluppo, così da poter individuare un problema, comunicarlo a chi sviluppa l’applicazione, correggerlo e rivalutare l’applicazione molto più rapidamente.

Ma la rapidità delle correzioni non significa che possiamo abbassare il livello di rigore della convalida. L’IA può generare rapidamente una correzione; i team di sicurezza devono comunque poter verificare che abbia davvero risolto il rischio e non ne abbia introdotto un altro.

La Partner Success Platform risultante integra assistenti IA, analisi della pipeline, generazione di campagne e supporto nella gestione delle trattative. Come avete stabilito quali attività dovesse svolgere direttamente l’IA e quali decisioni dovessero restare di competenza del partner o del venditore?

Per me, l’obiettivo non era estromettere le persone dai processi di partnership o di vendita. Volevo usare l’IA per aiutarle a lavorare più velocemente e a sfruttare meglio le informazioni già a loro disposizione. Il supporto nella gestione delle trattative ne è un buon esempio: l’IA può aiutare a individuare come far avanzare un’opportunità che da tempo è ferma nella pipeline e fornire ulteriori informazioni o suggerire il passo successivo.

A mio avviso, la distinzione diventa importante quando si tratta della capacità dell’IA di recuperare rapidamente informazioni da sistemi diversi, analizzarne la pertinenza e presentarle in una forma che consenta all’utente di agire. La piattaforma dovrebbe rendere più efficace il partner o il venditore, mentre la persona resta responsabile delle decisioni che richiedono una valutazione commerciale. L’obiettivo è ridurre il tempo che intercorre tra l’individuazione di una trattativa e la sua conclusione con esito positivo, grazie all’interazione con la piattaforma.

L’IA permette a dipendenti delle vendite, del marketing, della finanza e di altri reparti di creare applicazioni in autonomia, senza coinvolgere il team di ingegneria. Quali controlli minimi di sicurezza e governance dovrebbero essere attivi prima di consentire a queste applicazioni di collegarsi ai dati dei clienti, ai sistemi interni o all’infrastruttura cloud?

Il primo requisito è la visibilità. Le politiche aziendali dovrebbero incoraggiare questo tipo di esplorazione e innovazione, ma non è possibile proteggere un’applicazione di cui non si conosce l’esistenza. Incoraggiare l’innovazione rende più probabile che i dipendenti presentino i propri progetti, invece di tenerli nascosti. A quel punto, le organizzazioni devono capire quali identità e autorizzazioni abbia l’applicazione, a quali dati possa accedere, con quali sistemi di terze parti comunichi e se tali privilegi siano davvero necessari. Creare le condizioni perché l’innovazione possa svilupparsi, adottando al tempo stesso un processo che sostenga chi innova e soddisfi i requisiti di sicurezza.

Il principio del privilegio minimo è particolarmente importante. Uno dei rischi che osserviamo è che le applicazioni ottengano un accesso più ampio di quello di cui hanno effettivamente bisogno. Inoltre, la sicurezza non può limitarsi a un controllo una tantum prima del lancio. Se le applicazioni possono cambiare continuamente, le organizzazioni devono poterle rivalutare con la stessa continuità.

La governance del software tradizionale era stata concepita per i team di sviluppo, le richieste di integrazione del codice, i cicli di rilascio e le pipeline di distribuzione relativamente controllate. Se oggi gli utenti aziendali possono modificare e distribuire applicazioni in modo continuativo, come deve cambiare il ciclo di vita dello sviluppo del software aziendale?

La sfida fondamentale è che il ritmo è cambiato. Tradizionalmente, il software veniva sviluppato e rilasciato nel tempo, seguendo processi relativamente consolidati. Con gli strumenti di sviluppo basati sull’IA, è possibile realizzare e pubblicare qualcosa di nuovo potenzialmente ogni giorno. In questo contesto, i processi di sicurezza e governance basati su verifiche periodiche non saranno sufficienti.

Dobbiamo orientarci verso una sicurezza che operi in modo continuativo e riesca a tenere il passo con questo ciclo di sviluppo. Ciò significa individuare cosa viene realizzato, capire come è configurato e connesso, sottoporlo a scansione man mano che cambia e fornire agli sviluppatori indicazioni concrete che possano applicare rapidamente. Impedire ai dipendenti di usare questi strumenti non può essere la soluzione: l’opportunità di aumentare la produttività è troppo significativa. La sfida consiste nel creare misure di protezione che consentano all’innovazione di svilupparsi in sicurezza.

Hai paragonato la diffusione delle applicazioni realizzate con l’IA a una versione ancora più difficile della «shadow IT». Cosa rende questa nuova generazione di software ombra potenzialmente più problematica e come possono le organizzazioni individuare applicazioni di cui i team di sicurezza o IT potrebbero non conoscere nemmeno l’esistenza?

In passato, la shadow IT consisteva spesso nell’adozione da parte dei dipendenti di un’applicazione SaaS non approvata dall’IT. La differenza, oggi, è che i dipendenti possono creare direttamente l’applicazione, e farlo con una rapidità straordinaria. Qualcuno può realizzare un’applicazione usando un account personale, integrarla con sistemi di terze parti e persino collegarla ai dati aziendali prima che il team di sicurezza si accorga della sua esistenza.

È questo a rendere la situazione particolarmente impegnativa: creare applicazioni è diventato così facile che il loro numero e la velocità con cui cambiano possono rapidamente superare i limiti dei tradizionali processi di governance. I CISO si trovano ad affrontare la stessa domanda fondamentale: come si può proteggere qualcosa se non si sa nemmeno cosa è stato realizzato o come è stato configurato?

La capacità di individuare le applicazioni deve quindi diventare un elemento centrale della strategia di sicurezza. Un ottimo modo per riuscirci è sostenere gli innovatori e incoraggiarli a esplorare, chiedendo però loro di registrare i propri progetti. Le organizzazioni devono poter vedere non solo il codice, ma anche le applicazioni in esecuzione nel proprio ambiente, le identità e le autorizzazioni a esse associate, i dati a cui accedono e i sistemi esterni con cui comunicano.

Guardando ai prossimi anni, pensi che la maggior parte dei lavoratori della conoscenza finirà per diventare, in qualche forma, sviluppatore di software grazie all’IA? In tal caso, come cambieranno i ruoli degli sviluppatori professionisti, dei team di sicurezza e dei dirigenti aziendali all’interno delle imprese?

Ci stiamo avviando verso un mondo in cui la definizione di «sviluppatore di software» si farà molto più ampia. L’IA permette a chi comprende un problema aziendale, ma non è uno sviluppatore tradizionale, di trasformare un’idea in un’applicazione funzionante in tempi brevissimi. L’ho sperimentato in prima persona.

Non credo che questo renda meno importanti gli sviluppatori professionisti o i team di sicurezza. Cambia il modo in cui è necessaria la loro competenza. Gli utenti aziendali possono sempre più spesso realizzare soluzioni in autonomia, mentre gli sviluppatori possono concentrarsi su problemi tecnici più complessi e i team di sicurezza devono creare la visibilità e le misure di protezione che consentano a questa nuova generazione di sviluppatori di innovare in sicurezza. Anche il supporto e la manutenzione delle applicazioni assumono una nuova prospettiva. Chi le «realizza» non è sempre la persona più adatta a «mantenerle». Porta con sé la visione e la necessità aziendale, ma il supporto a lungo termine di un’applicazione resta un compito più adatto ai reparti IT e a quelli che si occupano delle applicazioni. Per i dirigenti aziendali, tutto questo offre enormi opportunità, ma comporta anche nuove responsabilità. Se i vostri team possono creare software, dovete considerare i rischi legati al software come parte dell’attività aziendale, non come una questione che riguarda soltanto il reparto sviluppo.

Grazie per la splendida intervista. I lettori che desiderano saperne di più sulla sicurezza cloud, sulle applicazioni realizzate con l’IA e sulla protezione degli ambienti aziendali possono visitare Orca Security.