Perché i SecOps devono imparare Jenkins?

Serve un nuovo modello organizzativo per la Security, che unisca velocità e protezione efficace. L’importanza dell’automazione e dei tool di Pipeline Management.

“Non correre, pensa a noi”, possiamo partire citando il magnete che imperversava sulle Fiat 600 degli anni 50 per ricordare che la velocità è forse il nemico numero uno della sicurezza.

Le buzzword sono sempre le stesse, “agile”, “devops”, “microservizi”, “continuos integration” e “continuos delivery” e le applicazioni sono soggette a cicli di rilascio sempre più frenetici in cui, nei casi estremi, si esegue il vero test durante il passaggio in produzione, foss’anche in un contesto di Canary su utenti pilota.

Questo approccio, finalizzato alla massimizzazione dei risultati in termini di offerta all’end user, ha una sua economia ed una sua giustificazione quando si pensa al business, un memento di downtime, un gruppo isolato di utenti insoddisfatti, sono tutte cose facilmente diluite dalla prospettiva di maggior ricavi e maggiore tasso di crescita.

Ma quando si parla di Security, la prospettiva cambia completamente.

Un servizio vulnerabile che viene esposto può portare a conseguenze catastrofiche per un’azienda; un errore nel deploy delle regole di Security non porta all’assordante diffondersi delle proteste da parte di un gruppo di utenti impattati, ma al silenzioso e discreto diffondersi di un lateral movement da parte di gruppi criminali interessati al furto di informazioni od a riscatti.

C’è bisogno, perciò, di un nuovo modello organizzativo per la Security, con dei nuovi processi che consentano di procedere con la stessa velocità di rilascio delle applicazioni senza che la superficie di attacco del sistema aumenti con la velocità.

blank

Su due cose tutti sono d’accordo: le skill sono difficili da trovare e quindi non si può pensare di avere un SecOps all’interno di ogni gruppo verticale di progetto; gli sviluppatori devono fare (bene) il proprio lavoro e, quindi, non si può pretendere che incomincino anche ad essere esperti di Security.

I SecOps devono quindi rimanere una realtà distinta, non isolata. Quello che è consigliabile è, a questo punto, osservare il nuovo modello di lavoro, capirne i pregi e mutuarlo nel nuovo approccio alla Security.

Guardiamo sia i processi e che i tool, la vera integrazione potrebbe proprio partire da questi ultimi.

Molto spesso quando si parla di Shift Left ci si limita all’applicazione della Security Review del Codice e della Vulnerability Analysis delle immagini prima della promozione in produzione: questo è un approccio valido ma ancora statico, dobbiamo pensare di inserire tutta la gestione della Security nel processo.

Un vero approccio Shift Left deve prevedere che le policy runtime siano deployate, contestualizzandole per ambiente, insieme all’applicazione. I cicli di test dell’applicazione e le valutazioni di performance devono prevedere anche le policy di sicurezza in modo che, quando l’applicazione viene promossa in produzione, tutti gli aspetti siano stati verificati ed i livelli di protezione applicati siano quelli richiesti dall’ambiente.

Dicendo questo vorrei riprendere un acronimo ancora poco usato, Security As a Code: è necessario che la Security sia gestita nello stesso modo in cui è gestita un’applicazione. Il mantra è uno solo, comunque: automazione a garanzia della Security.

La prima cosa che i SecOps dovrebbero fare è quella di cominciare ad appoggiare le Policy nel Git aziendale ed introdurre un processo di versioning che si deve accompagnare ad una categorizzazione delle applicazioni e degli ambienti in termini di requisiti di sicurezza.

Andando sul pratico, il punto fondamentale è che i SecOps dovrebbero costruire i template di sicurezza delle applicazioni in termini di manifest e questi devono poi essere iniettati negli Helm utilizzati per il deploy delle applicazioni stesse.

Le Policy di Security devono accompagnare l’applicazione durante tutto il suo ciclo di vita, dallo sviluppo alla produzione con i test, manuali od automatici che siano, che devono includere anche tutta la componente di Security.

L’automazione deve essere la chiave: un commit di una nuova versione delle regole di Security deve a cascata generare una nuova versione delle applicazioni impattate. Il deploy delle nuove versioni deve essere comandato dal Pipeline Manager che è quello che promuove in produzione ed eventualmente esegue anche il rollback se ci fossero sospetti di falsi positivi, di errori di configurazione o di blocchi dei servizi.

Ma la tecnologia è pronta per essere di supporto a questo processo? Il percorso è lungo ma gli esempi convincenti ci sono.

Uno di questi è AppProtect, il porting su NGINX del WAF di F5 Networks.

AppProtect gestisce le Policy di Security all’interno di una CustomResourceDefinition (CRD) in modo da mantenere un approccio dichiarativo e non imperativo alla sicurezza. La CRD, come oggetto Kubernetes, può essere versionata, inserita nel flusso della Pipeline, se ne può fare il deploy ed il rollback, è quindi perfettamente in linea con i pattern di Kubernetes.

A fine di questa lunga riflessione, facendo riferimento al titolo, forse in parte fuorviante, in realtà nessun SecOps deve imparare Jenkins e meno ancora Kubernetes (anche se per quest’ultimo male non fa, è un po’ come il Latino, aiuta a sviluppare la logica).

Quello che dovrebbero fare i SecOps è imparare la logica che sta dietro ad un gestore di Pipeline, farla propria ed utilizzarla come arma per inserire dei guardrail di Security sempre più stretti e sempre più efficaci, delle corsie sicure ad alta velocità dove far correre i DevOps.

Articolo scritto per Aditinet Consulting SpA da Paolo Maggioni, Sales Specialist Aditinet Consulting SpA

Share on facebook
Share on twitter
Share on linkedin
Share on whatsapp
Share on telegram
Share on email
Share on print

Articoli correlati

Non sei ancora iscritto alla nostra newsletter?

Torna su