Dom Richter, Co-Fondatore di Mondoo – Serie di Interviste

Dom Richter, Co-Fondatore di Mondoo è un esperto di prodotti con una profonda conoscenza dello sviluppo software moderno, del design dei prodotti e della leadership di team. Con una formazione che copre backend, frontend e tecnologie di automazione, ha guidato team di ingegneria ad alte prestazioni attraverso una cultura di fiducia, sperimentazione e innovazione guidata da scopi. Il suo lavoro si interseca con l’intelligenza artificiale, la sicurezza informatica e il DevOps, dove enfatizza la collaborazione, l’apprendimento continuo e la fornitura di valore significativo agli utenti finali.

Mondoo è una piattaforma di automazione della sicurezza e della conformità che consente alle organizzazioni di valutare, monitorare e proteggere continuamente la propria infrastruttura in ambienti cloud, on-premises e ibridi. Sfruttando il codice delle politiche e le informazioni guidate dal machine learning, Mondoo aiuta i team a identificare le vulnerabilità, applicare gli standard di conformità e rafforzare la sicurezza senza rallentare l’innovazione. La piattaforma si integra perfettamente nei flussi di lavoro DevOps moderni, rendendo la conformità continua una realtà raggiungibile per le imprese di tutte le dimensioni.

Cosa ti ha ispirato a co-fondare Mondoo, e come la tua esperienza come hacker e leader di prodotti – insieme alle tue esperienze in Google, Chef e nelle precedenti startup – ha plasmato la missione dell’azienda?

Quando ero nelle trincee a rompere i sistemi come parte del mio lavoro come pentester, ho trovato molte debolezze facilmente prevenibili. Allo stesso tempo, la sicurezza era spesso così focalizzata sul sommergere gli utenti con avvisi che perdeva di vista ciò che contava. Allora pensavo “Ci deve essere un semplice pulsante che posso premere per risolvere queste cose”.

Poi sono passato dall’altra parte e ho iniziato a difendere i sistemi. Ho imparato a operare correttamente a livello di scala, con l’automazione e il codice. Ciò è utile sia che si esegua una piccola rete domestica sia che si operi una grande azienda tecnologica. Le idee sono le stesse. Alla fine, è stata questa combinazione di sicurezza e ingegneria di piattaforma a motivarmi a co-fondare Mondoo. Volevo fare la differenza nello stato della sicurezza, non solo aggiungere un altro scanner che generava altri avvisi. Trovo molto motivante vedere come i nostri clienti sono in grado di migliorare rapidamente la loro posizione con Mondoo, dopo essere stati bloccati per anni. Diversi clienti ci hanno detto che Mondoo ha ridotto le vulnerabilità aperte del 60%, il che è un ottimo risultato. Stiamo cercando di portare quel numero al 100% con la nostra gestione delle vulnerabilità agentiche.

Hai descritto la mitigazione – il processo di correzione effettiva delle vulnerabilità dopo la loro scoperta – come un mito. Perché credi che l’industria continui a investire pesantemente nella scansione e nella segnalazione mentre lascia i team a lottare per eseguire le correzioni?

Ciò è in gran parte il risultato di come i team di sicurezza e piattaforma sono impostati, specialmente nelle grandi organizzazioni. Per il più lungo tempo li abbiamo trattati come entità separate, ognuna con i propri obiettivi, strumenti e priorità. Ma la legge di Conway dimostra cosa succede: si spedisce l’organigramma invece di risolvere il problema. Ho visto entrambi i team puntare il dito l’uno contro l’altro – spesso per ottime ragioni.

Stiamo finalmente sperimentando un cambiamento nell’industria, dove le aziende si rendono conto di voler ottenere di più dalla sicurezza. Non vogliono un blocco commerciale. Vogliono un driver. Grazie ai leader innovativi che stanno emergendo per spingere i confini, stiamo finalmente vedendo un cambiamento nell’industria e nelle soluzioni.

Come possono le organizzazioni superare la frattura culturale tra i team di sicurezza e DevOps che spesso rallenta la correzione?

DevSecOps è un buon inizio; è necessario avvicinare gli sviluppatori e la sicurezza. È possibile assumere ruoli cross-funzionali che possono aiutare a colmare il divario, come ingegneri SecOps o esperti di piattaforma con una formazione in sicurezza. Inoltre, riunire fisicamente i team aiuta. È cruciale che la leadership incoraggi e partecipi a questo processo. Stabilire obiettivi e metriche condivise e monitorarle.

Per supportare i team, è poi necessario riunire strumenti e tecnologie. Non sto parlando solo di scaricare biglietti di sicurezza in sistemi di gestione dei biglietti. È necessario stabilire un modello condiviso che dia a entrambi i team ciò di cui hanno bisogno. Ad esempio, abbiamo scoperto che l’automazione delle correzioni delle vulnerabilità, fornendo ai team di piattaforma abbastanza contesto e, soprattutto, la correzione specifica da applicare, li aiuta a eseguire molto più velocemente le richieste. Quanto più si combina questo con l’automazione e si creano richieste di modifica nei sistemi di automazione (come Terraform e Ansible), tanto più facile è. È anche necessario avere un percorso di comunicazione di ritorno, ad esempio rendere facile per i team di piattaforma obiettare, ottenere eccezioni e segnalare problemi sistemici. Tutto ciò incoraggia la collaborazione e colma il divario.

Nella tua opinione, quale ruolo dovrebbe svolgere la leadership nella creazione di responsabilità e collaborazione per la correzione dei problemi di sicurezza?

Come leader, abbiamo due grandi contributori alla capacità dei nostri team di eseguire: ciò che comunichiamo e ciò che misuriamo. Se i leader parlano solo di raccolta di riscontri e puntano il dito contro altri team come collo di bottiglia, allora i loro team tratteranno la questione nello stesso modo. Se misurano il numero di problemi di sicurezza e non la loro qualità e le azioni intraprese, allora i team ottimizzeranno per questo.

Creiamo le condizioni giuste lavorando con altri leader attraverso i confini, riconoscendo la natura condivisa di questa area e concentrandoci su risultati condivisi piuttosto che su metriche isolate. Una volta dopo l’altra, vediamo che quando i leader affrontano il problema condiviso insieme, raggiungono di più per i loro team individuali e per l’azienda, perché guidano i risultati che contano.

I punteggi di rischio sono ampiamente utilizzati, ma spesso mancano di contesto, e la fatica degli avvisi sommerge molti team. Come dovrebbero le organizzazioni ripensare la priorità in modo che vengano corretti i problemi giusti?

Per una priorità efficace, è necessario avere il contesto aziendale e il contesto tecnico. Il contesto aziendale include la conoscenza degli asset digitali che mantengono accesa la luce nella vostra azienda e che devono essere protetti per mantenere la vostra buona reputazione. Ad esempio, il database che contiene le foto private degli utenti o i gateway che elaborano tutto il traffico del sito web sono di priorità più alta rispetto ai sistemi di test che non sono connessi a Internet. Quando guardiamo ai riscontri di sicurezza, dobbiamo conoscere il contesto aziendale. Se mostri “critico” su un riscontro a bassa priorità, i team si desensibilizzeranno e non lo prenderanno seriamente. Se un problema è veramente critico, è necessario mostrare chiaramente perché.

Il prossimo è il contesto tecnico. Ciò significa conoscere il sistema, la sua configurazione, la posizione, i tag, le app, i pacchetti e gli utenti. Ma non è tutto. È necessario elevare il livello della propria visione. È necessario capire come un problema di sicurezza possa esporre i sistemi critici, come sono connessi e integrati, non guardando solo uno o due sistemi individuali, ma guardandoli come un cluster. Abbiamo anche bisogno di sapere come questi sistemi sono automatizzati e costruiti per poter dire rapidamente alle persone dove guardare e come risolvere il problema alla radice.

Man mano che gli attaccanti utilizzano sempre più l’intelligenza artificiale, come possono i difensori utilizzare l’intelligenza artificiale in modo responsabile per rimanere avanti senza creare nuovi rischi?

L’utilizzo dell’intelligenza artificiale moltiplica notevolmente la capacità di correggere le vulnerabilità e farlo alla velocità della macchina. Tuttavia, se i sistemi di intelligenza artificiale non sono sicuri, possono potenzialmente introdurre nuovi rischi nell’ambiente. Quando si distribuiscono sistemi alimentati da intelligenza artificiale, è importante assicurarsi che utilizzino un’architettura sicura e trasparente e consentano un’esaustiva registrazione e monitoraggio degli eventi. Ristrutturando le autorizzazioni degli agenti per limitarle solo a quanto necessario per completare i compiti assegnati, i rischi possono essere mantenuti al minimo. Ulteriori sistemi di sicurezza, come consentire agli utenti di interrompere o disattivare i sistemi di intelligenza artificiale agente quando necessario e condurre audit regolari sugli agenti e sulle loro azioni, è qualcosa che raccomanderei vivamente.

Quali sistemi di sicurezza ritieni essenziali quando si concede all’automazione la capacità di correggere in ambienti di produzione?

Per ogni azione che un’automazione può eseguire, è necessario avere sistemi di sicurezza in atto per assicurarsi che agisca all’interno del suo ambito previsto. Se si crea un agente di intelligenza artificiale e gli si concede l’accesso libero a tutta l’infrastruttura, alla fine romperà le cose.

Per fortuna, comprendiamo bene i sistemi di sicurezza grazie al lavoro indefesso svolto nell’automazione delle piattaforme negli ultimi due decenni. I sistemi di automazione moderni hanno restrizioni in atto che controllano le azioni che possono essere eseguite. In Mondoo, combiniamo le correzioni guidate dall’intelligenza artificiale con framework di politiche avversarie che verificano le loro azioni. Ogni correzione viene creata in codice, può essere testata, verificata e, soprattutto, limitata quando necessario.

Come vedi l’evoluzione dell’equilibrio tra correzione guidata dall’uomo e correzione guidata dalla macchina nei prossimi cinque anni?

Simile alle auto a guida autonoma, vedremo i team adottare l’automazione guidata dalla macchina in aree sempre più numerose, un passo alla volta. Inizieranno concentrandosi su un subset dell’ambito di sicurezza, come ad esempio sistemi a bassa priorità, e introducendo l’automazione agente per esso, creando metriche e obiettivi, e poi implementandolo gradualmente. Una volta che questo sarà automatizzato, si potrà espandere ad altre aree.

Alla fine, la focalizzazione dell’automazione dovrebbe essere su aree che sono grandi in scala con molte somiglianze. Queste aree traggono il massimo beneficio dalla coerenza che l’automazione porta. Credo che in cinque anni tutte le principali azioni di correzione saranno guidate dalla macchina e i sistemi saranno strettamente integrati tra sicurezza e operazioni di piattaforma.

Qual è la tua visione a lungo termine per come la gestione delle vulnerabilità dovrebbe apparire alla fine di questo decennio?

Entro la fine del decennio, la gestione delle vulnerabilità avrà una forte focalizzazione sull’automazione e sulla correzione. Il nostro lavoro come specialisti di sicurezza sarà più concentrato sull’evoluzione di questa automazione, lavorando con i team di piattaforma sulla sicurezza dei loro ambienti IT in evoluzione. Questi sistemi saranno più strettamente integrati, utilizzando l’automazione della piattaforma e l’intelligenza artificiale agente per eseguire azioni su larga scala mentre saranno sicuri e prevedibili.

Per i team di sicurezza più piccoli con risorse limitate, quali passi pratici possono intraprendere per migliorare la correzione e la resilienza?

Inizia con l’automazione delle patch. Introduci l’automazione presto – soprattutto quando hai risorse limitate – e integra la sicurezza fin dall’inizio. Questo è il passaggio più semplice che già riduce notevolmente l’esposizione alle scansioni automatizzate che gli attaccanti utilizzano.

Grazie per la grande intervista, i lettori che desiderano saperne di più possono visitare Mondoo.