DevSecOps non è più solo una parola di moda. Alcune aziende sono state in grado di inserire da subito la sicurezza in DevOps, in modo trasparente e fluido, come integrazione innata e sistematica ed elemento vitale dei processi. Tuttavia, è bene evidenziare un altro punto di vista: quello delle aziende che si trovano in
una fase ancora prematura del proprio percorso DevOps, in cui la pratica non è semplice come la teoria.
Molte di queste organizzazioni si trovano all’inizio già potenzialmente disallineate. DevOps ha un obiettivo semplice: fornire una funzione di business basata sulla tecnologia, che continua ad evolversi nel tempo. Qui c’è tipicamente il disallineamento: chi si occupa di sicurezza ha la necessità di
comprendere i rischi e prendere decisioni informate. I team DevOps sono focalizzati sul raggiungimento dei risultati,
lavorando a pieno ritmo per anticipare i concorrenti. Per avere successo, questi risultati devono includere la sicurezza.
Una buona analogia è rappresentata da ciò che accadeva nel settore delle telecomunicazioni, in cui generalmente il servizio veniva misurato in base a velocità e uptime. In questo contesto, gli ingegneri
vedrebbero la sicurezza come una potenziale minaccia per i loro obiettivi.
La seconda sfida è rappresentata dalle aspettative delle aziende che pensano che DevOps possa cambiare con la stessa velocità con cui si evolve il progetto stesso. Troppo spesso, i progetti
nascono come idee sperimentali, affidate in prima battuta a esperti consulenti esterni per valutare se possono davvero funzionare per l’azienda. Prima ancora di scoprirlo, il progetto ha successo ed è diventato mainstream. I consulenti ai quali ci si è affidati
non avranno la stessa base di conoscenza dell’azienda, e la volontà di
correre dei rischi in un piccolo progetto pilota non è la medesima quando si tratta di implementarli come servizi di core business.
Analizzando la cronaca, si nota come molti progetti abbiano subìto violazioni dei dati a causa di
credenziali deboli. Progetti proof-of-concept semplici prevedono generalmente password molto facili o salvate in modalità visibile per consentire l’accesso ad altri membri del team.
DevSecOps: elasticità o sicurezza?
Questo conduce alla terza considerazione. DevOps coinvolge solitamente team operativi con differenti funzioni, in grado di essere dinamici. E la dinamicità è l’elemento che porta al successo mediante il coinvolgimento di piccoli gruppi che risolvono sfide mirate. Tuttavia,
questa agilità può incrementare i rischi alla sicurezza. Modificare i team può rendere più difficile avere un cyber-champion nella squadra ed inoltre la definizione di quanto si ritiene essere il “successo cyber” può cambiare.
Ad esempio, un cyber-champion potrebbe stabilire che tutti i processi cloud siano protetti da un firewall. Ma se il firewall è configurato come spesso ci capita di vedere – cioè consente impropriamente qualsiasi comunicazione - i membri dei team potrebbero
ritenere comunque di aver incluso nel progetto un livello di protezione appropriato. Si potrebbe invece correre il rischio di essere colpiti da
attacchi per il mining di criptovalute, attività che potrà avere impatto sulle performance ed esporre l’azienda a rischi legati alla reputazione se l’evento dovesse diventare di cronaca.
La domanda da porsi è: ci si aspetta questo da un cyber-champion all’interno di un team di DevOps? Come si può mantenere la coerenza quando ci sono livelli elevati di cambiamento? E, soprattutto,
quali sono i punti critici in cui è necessaria l’expertise? Come operare in modo da non rallentare il progetto o creare colli di bottiglia se si ha poca esperienza?
La cyber sicurezza fa sempre più affidamento
sull’automazione per consentire un funzionamento dinamico negli ambienti di computing, di conseguenza i problemi tecnici attuali dovrebbero agire da inibitori. Il problema è riconoscere che gli obiettivi aziendali e l’esperienza dei team cambieranno. Quindi, è fondamentale che ognuno
abbia chiari i risultati attesi e dove debba avvenire il passaggio di consegne al team responsabile di sicurezza.
Agilità e velocità non possono, né devono, essere una scusa per non applicare la conoscenza sviluppata in anni di esperienza in ambito sicurezza. Questo significa che sono necessarie
la stessa visibilità e le metriche utilizzate in tutti gli altri aspetti dei processi IT. Tuttavia, la realtà è che DevOps generalmente prevede la collaborazione a ritmi sostenuti tra risorse che
hanno molteplici funzioni. A causa della generale carenza di competenze, è fondamentale sapere
quali skill impartire al team e dove e quando fare affidamento sugli esperti di sicurezza. È importante che condividano un obiettivo comune basato sui risultati aziendali e non individuali.
In realtà, però, ogni azienda ha il proprio livello di maturità. In futuro, saremo in grado di eliminare DevSecOps dalle parole di moda, ma oggi è bene ricordare che
la sicurezza deve essere una componente dei team di sviluppo e operations che consentono una nuova agilità di business. Tra qualche anno potremo definire tutto questo come “Agile IT” o forse qualcosa di completamente diverso.
Greg Day è Chief Security Officer EMEA di Palo Alto Networks