I cambiamenti a ritmo sostenuto nei modelli di business, la concorrenza divenuta globale e pressante, e l’assunzione di un atteggiamento sempre più esigente da parte dei clienti, hanno portato le imprese cambiare le strategie di sviluppo (oltre che di acquisito) di nuove applicazioni in tale contesto emerge il concetto di DevSecOps.
L’esigenza di accrescere il loro ruolo come leve competitive nell’era della digitalizzazione del business sta conducendo sempre più aziende ad adottare il classico modello a due velocità: da una parte si procede con gradualità alla sostituzione delle applicazioni critiche, in quanto reggono processi core le cui esigenze non cambiano molto da un anno all’altro; da un’altra parte, invece, c’è sempre più l’esigenza di adottare, sperimentare, modificare, dispiegare sul larga scala o dismettere, applicazioni e piattaforme innovative in grado di creare velocemente vantaggi competitivi e nuovi flussi di valore a favore dell’azienda e dei suoi clienti. In genere, queste tecnologie ricadono nella categoria dei System of Engagement (SoE), la cui implementazione scavalca i confini dell’IT on-premise.
DevOps, perché si sta imponendo
È per ottimizzare la velocità del rilascio di nuove applicazioni e sistemi IT che è nato, e si sta sempre più imponendo nelle aziende, il DevOps. Come noto questo paradigma prevede l’abbattimento dei tradizionali silos in cui si trovavano le attività di development (sviluppo) e delle IT operation (gestione delle infrastrutture e della sicurezza). Prima del DevOps, i developer attendevano di aver completato lo sviluppo e l’integrazione di tutti i moduli del software e poi rilasciavano ai responsabili delle operazioni il “package” completo affinché venisse testato e messo in produzione. Fra i mondi degli sviluppatori e degli Ops professional non mancavano (e tuttora non mancano) frizioni dovute al fatto che i developer considerano come priorità la rispondenza delle applicazioni alle esigenze di business, mentre i responsabili delle operazioni sono preoccupati della sicurezza, delle performance e dei costi di esercizio delle infrastrutture.
Il DevOps ha il vantaggio di portare gli esperti dello sviluppo di applicazioni e soluzioni (inclusa anche l’integrazione di moduli non sviluppati “in casa”, ma disponibili nelle community open source o presso terze parti affidabili produttrici di software chiuso) e gli esperti delle infrastrutture e della sicurezza a condividere sempre di più le metriche adottate nelle metodologie di loro pertinenza e adottare, così, obiettivi comuni e un senso di corresponsabilità globale.
L’altro vantaggio fondamentale del DevOps è che, invece di attendere i lunghi cicli separati di sviluppo e di messa in produzione del software (e spesso quelli legati alla necessità di correzioni di difetti scoperti ex post), con l’utilizzo di pipeline CI/CD (Continuous Integration/Continuous Delivery), le applicazioni vengono progettate e realizzate un pezzo alla volta (o più in parallelo), per poi assemblarle come fossero costruzioni fatte con il Lego. In questo modo, lavorando fianco a fianco, gli sviluppatori possono tenere in considerazione le esigenze delle operation (inclusa la sicurezza) e i responsabili delle operazioni possono dare i loro consigli, testare anticipatamente il codice, mettere in produzione tutto ciò che è già implementabile senza dover attendere, ongi volta, un package completo.
Sicurezza by design delle applicazioni e perché si parla di DevSecOps
Con la crescita delle minacce cibernetiche (che mirano a sfruttare qualsiasi vulnerabilità per attentare alla privacy delle informazioni e al buon funzionamento dei sistemi IT) e con l’aumento delle normative di cyber sicurezza rispetto alle quali si deve garantire la compliance, è divenuta necessario tenere in considerazione le esigenze della sicurezza dall’inizio alla fine dei cicli di DevOps. È per questo motivo che oggi si parla sempre di più di DevSecOps, una delle metodologie che permette di rilasciare applicazioni sicure by design.
Secondo una visione efficace, dal momento che la sicurezza deve essere ormai prevista “by design” sia nel codice sia nelle piattaforme e nei sistemi IT, si può dire che l’elemento Sec deve abbracciare quelli Dev e Ops. O in altre parole Dev e Ops devono essere avvolte (wrapped) dalla Sec.
Un approccio “by design” e “by default” per la sicurezza nello sviluppo del software è oggi l’unico percorribile per garantire l’integrità del business digitale e per essere compliant con le normative, come il GDPR. Il framework DevSecOps consiste non solo nell’integrazione della sicurezza delle applicazioni e dell’infrastruttura fin dall’inizio del ciclo di sviluppo, ma anche automatizzare alcune attività di controllo della sicurezza per evitare che rallentino il flusso di lavoro DevOps. Questo significa adottare strumenti che consentano di integrare la sicurezza in modo costante, ma l’adozione id nuovi strumenti non è sufficiente perché il DevOps, e a maggior ragione il DevSecOps, richiede cambiamenti di tipo culturale, metodologico e tecnologico. Quello culturale prevede, fra altre cose, che si consideri la sicurezza non più come qualcosa da aggiungere a una soluzione o a un costo.
Da un punto di vista metodologico diventa necessario adottare un’architettura di riferimento per la sicurezza cibernetica, ossia una Cyber Reference Architecture (CRA), che includa al livello più alto tutti gli aspetti strategici (leadership, risk and compliance management, empowerment nella sicurezza di tutti gli addetti, etc.). Al di sotto, quindi, troviamo un livello tattico (strumenti e servizi di cyber defence ben orchestrati) e quindi un livello tecnologico. È in quest’ultimo che si colloca, fra altre metodologie per la sicurezza (come la gestione dell’identificazione e dell’autenticazione degli accessi, o IDAM, l’endpoint security e la sicurezza fisica), l’application security.
Consigli per la creazione di applicazioni sicure
L’application security, come già detto, deve prevedere che più esigenze possibili di sicurezza siano affrontate e soddisfatte nei processi del ciclo di vita del software. Lo sviluppo dovrebbe essere effettuato utilizzando tecnologie standard, affidabili, con cui realizzare possibilmente microservizi, che limitano la portata degli attacchi e ha hanno il vantaggio di poter essere riutilizzati, con un conseguente risparmio nel costo delle attività di sviluppo e messa in produzione. Nelle attività di application quality assurance si consiglia di fare ampio uso di strumenti di test automatizzati, sempre più spesso basati sull’AI (artificial intelligence) e il LM (machine learning). Questi tool possono essere utilizzati come plug-in delle piattaforme di sviluppo, in modo da controllare i moduli del software ma mano che vengono sviluppati, e come soluzioni di testing finale statico e dinamico (mentre i software sono già in produzione) dei package rilasciati. Altro capitolo importante per l’application security è il tracking del codice sviluppato, includendo fra i dati anche le destinazioni d’uso, in modo da poter re-implementare, laddove necessario, nuove versioni delle applicazioni con correzioni di difetti e vulnerabilità.
