I team di sicurezza anelano sempre più a nuove funzionalità di automazione. E, negli ultimi anni, le loro opzioni sono migliorate con l’introduzione del SOAR (Security Orchestration, Automation and Response) e altre soluzioni di sicurezza come il SIEM (Security Information and Event Management), lo IAM (Identity and Access Management), l’EDR (Endpoint Detection and Response), l’XDR (Extended Detection and Response ) e il CDR (Cloud Detection and Response) che offrono automazione in una capacità ridotta.
Con tutte queste diverse opzioni in gioco, capire le somiglianze e le differenze tra SOAR e DevSecOps è essenziale se i team vogliono raggiungere i loro obiettivi. Sebbene ci siano elementi di automazione del flusso di lavoro nel SOAR, ciò che distingue DevSecOps da SOAR è un’esperienza collaborativa tra i team Dev, Sec e Ops; iper-dipendenza dall’open source; la capacità di essere proattivi e reattivi; e un approccio agile.
Cos’è il SOAR?
Gartner® definisce il SOAR come “tecnologie che consentono alle organizzazioni di raccogliere input monitorati dal team di sicurezza”. Gli strumenti SOAR acquisiscono dati dai sistemi SIEM per definire l’analisi degli incidenti e le procedure di risposta in un formato di flusso di lavoro digitale.
Cos’è il DevSecOps?
Il DevSecOps è una moderna metodologia di processo che ha aggiunto al DevOps, ( e cioè lo sviluppo del software unito alle operations), l’elemento sicurezza. Gli obiettivi di DevSecOps sono aumentare la velocità di rilascio, eliminare i muri tra i team, ridurre la frequenza e l’impatto dei bug nelle versioni di produzione e spostare la sicurezza ulteriormente a sinistra nel processo di distribuzione del software. Il DevSecOps va oltre lo sviluppo delle applicazioni man mano che le organizzazioni si modernizzano quando tutto nell’IT diventa codice, noto anche come IT-as-Code.
Gli obiettivi del DevSecOps vengono raggiunti in due modi. Uno, un cambiamento culturale in cui i team lavorano insieme su un’unica piattaforma per creare e reiterare la creazione di soluzioni ripetibili con prodotti e strumenti di più fornitori, che possono essere chiamati una fabbrica di software o DevSecOps. Secondo, l’uso del CI/CD (continuous integration/continuous delivery). Il CI/CD è una categoria di strumenti software che integrano e inviano frequentemente codice per assicurarsi che le nuove versioni di un’applicazione funzionino. Il CI/CD consente il codice creato per testare e automatizzare tutti gli aspetti della pipeline, inclusa la sicurezza, prima che il codice venga inviato alla produzione.
Perché il SOAR è diverso dal DevSecOps
Si potrebbe confondere la meccanica del SOAR con quella del DevSecOps perché i team di sicurezza che utilizzano uno strumento SOAR stanno, in un modo molto alto, abbracciando lo spirito del DevSecOps, che consiste nell’utilizzare un approccio low code per automatizzare il proprio lavoro.
Ma è qui che inizia e finisce la somiglianza. Le tre differenze fondamentali, descritte di seguito, sono ciò che distingue il DevSecOps dal SOAR.
- Il SOAR ha un supporto limitato per l’open source. Gli strumenti SOAR raramente si integrano con strumenti open source perché per natura si integrano principalmente con strumenti di terze parti come Cisco, Exabeam, Okta o Splunk. La mancanza di integrazione open source è un enorme deterrente per i team DevOps che fanno molto affidamento su strumenti open source come Git, Ansible e Terraform per il loro lavoro. Questa situazione di stallo isola i team di sicurezza dalla produzione e allontana i team DevOps dalla collaboration.
- Il SOAR non adotta un approccio agile per fornire automazione. Quando i team di sicurezza che utilizzano gli strumenti SOAR parlano di automazione, è nel contesto dell’acquisizione di dati da SIEM, della gestione di tali dati e dell’automazione dei flussi di lavoro di incident response. Ciò è diverso dall’utilizzo di CI/CD, come in DevSecOps, che consente agli sviluppatori di integrare il nuovo codice sorgente, testarlo, inviarlo e quindi distribuirlo con frequenza alla produzione.
- Il SOAR è stato realizzato come prodotto di punta per gli analisti della sicurezza, non come collaboration. SOAR è un caso d’uso in DevSecOps che può ospitare al suo interno molti casi d’uso, compresi ma non limitati al SOAR, alla conformità, alla sicurezza del cloud, alla sicurezza delle app, all’automazione della rete, all’automazione dell’infrastruttura e alle integrazioni. L’obiettivo del DevSecOps è consentire ai team di creare soluzioni come building blocks e collegarle al CI/CD in cui ogni team può connettersi ai flussi di lavoro esistenti con i prodotti e gli strumenti che desidera utilizzare.
Il CI/CD consente, soprattutto ai team di sicurezza e operativi, di eseguire iterazioni con un approccio agile con vari casi d’uso, di scansionare la codebase o l’applicazione per rilevare vulnerabilità di sicurezza note o eseguire infrastrutture e applicazioni rispetto a benchmark di sicurezza che migliorano sia la sicurezza del prodotto che quella aziendale.
Pertanto, il DevSecOps abbraccia l’open source, adotta un approccio agile all’automazione e consente la collaboration, mentre il SOAR non lo fa su tutti i fronti. L’opzione open source è in realtà l’ideale per i team di sicurezza, che apprezzano il supporto e la responsabilità offerti da una vasta comunità. Allo stesso modo, l’accesso a CI/CD è vantaggioso per i team di sicurezza, che da tempo desideravano lo shift-left. In altre parole, chiedi a Dev di introdurli nelle prime fasi del processo di creazione della pipeline IT-as-Code in modo che possano risolvere i problemi prima che il codice arrivi alla produzione.
Raggiungere l’agilità con il CI/CD, un obiettivo del DevSecOps
SOAR è esclusivamente una piattaforma di sicurezza, mentre DevSecOps risponde in modo olistico alle esigenze di tutti i team abbracciando CI/CD, strumenti open source e collaboration. Il SOAR non può sostituire il DevSecOps, ma DevSecOps risolve i punti deboli del SOAR e lo tratta come un caso d’uso offrendo allo stesso tempo un livello di automazione e user experience che eleva il ruolo e il lavoro della security.
Alcuni team di sicurezza operativi potrebbero essere reticenti ad adottare una soluzione DevSecOps perché il CI/CD è tradizionalmente fortemente orientata al solo sviluppo di applicazioni. Tuttavia, al giorno d’oggi ci sono molte opzioni di piattaforma low-code/no-code che consentono a un’organizzazione di ottenere il DevSecOps. Idealmente, i team dovrebbero procurarsi una piattaforma DevSecOps che sia all-inclusive; ovvero, che contenga un’interfaccia visiva in cui tutti i livelli di utenti possono collaborare ma che presenti anche un potente back di supporto per gli sviluppatori. Inoltre, dovrebbe avere al suo interno i requisiti DevOps come il supporto di strumenti esistenti e il contenuto di automazione nella sua forma nativa, ad es. Configurazioni Terraform, playbook Ansible, script, ecc.
Il panorama delle minacce è in continua evoluzione. Oggi i team di sicurezza operativi devono fare di più nonostante la carenza di talenti, l’automazione deve guadagnare terreno per alleviare le pressioni che aumentano nel loro dominio. I team di sicurezza traggono grande vantaggio dalle pipeline CI/CD, che non solo replicano e accelerano le loro capacità manuali, ma ritagliano anche tempo prezioso necessario alla modernizzazione dei loro processi di lavoro quotidiani. Abbracciando lo spirito e le pratiche del DevSecOps, i team di sicurezza e operativi possono diventare agili con le loro controparti Dev e DevOps attraverso una collaboration che possa soddisfare l’intero spettro di talenti tecnici all’interno di ogni organizzazione.