Nel corso della sua carriera come ingegnere della sicurezza informatica, Matthew Rosenquist ha dovuto affrontare non poche frustrazioni. C’era l’ CEO , che ha licenziato il proprio team dopo che questo gli aveva segnalato alcune vulnerabilità nel prodotto principale dell’azienda. C'erano ingegneri del software che non avevano esperienza in materia di sicurezza, ma non erano interessati ad acquisirla.
«Nella loro mente, erano programmatori geniali e questo bastava», afferma Rosenquist. «Hanno detto: “Non è un mio problema”.» «Mi limito a programmare il codice in modo che funzioni, e il resto è un problema di qualche addetto alla sicurezza.»
Tale atteggiamento ostile è comprensibile. Gli sviluppatori di software operano in un mondo caratterizzato da progettazione iterativa, rilasci rapidi e “prodotto minimo funzionante”. Per ragioni di tempo e per concentrarsi sul codice, non si occupano di molto altro, compresa la sicurezza. Spesso lo considerano un ostacolo alla tabella di marcia, o addirittura al prodotto stesso.
«Se siete sviluppatori o ingegneri, questo è il vostro progetto», afferma Rosenquist, stratega nel campo della sicurezza informatica e consulente del consiglio di amministrazione, che ha lavorato per 23 anni presso Intel ed è attualmente CISO presso Eclipz.io, un’azienda specializzata nella crittografia del software. «Avete delle scadenze. Verrà valutata la Sua capacità di far funzionare il codice entro i tempi previsti. Ora immaginate un esperto di sicurezza informatica che non conosca il vostro prodotto. «Volete che faccia X, Y e Z?» «Questo mi scombussolerà la tabella di marcia.» Questo attrito si accumula. «L’unica cosa peggiore è non adottare alcuna misura di sicurezza.»
Colmare il divario
L’attrito descritto da Rosenquist non è una novità. Tale situazione è scaturita da una frattura di lunga data all’interno dell’azienda tra i team DevOps e quelli addetti alla sicurezza ed è stata aggravata dalle sfide poste da una crisi sanitaria globale. Con milioni di lavoratori da remoto che accedono a sistemi contenenti dati sensibili tramite decine di milioni di dispositivi finali, tra cui laptop, PC e tablet, le vulnerabilità e le violazioni della sicurezza hanno registrato un’impennata. Secondo un’indagine pubblicata nel 2020 da Tanium , le aziende nordamericane subiscono perdite pari a 700 miliardi di dollari all’anno a causa dei tempi di inattività dei sistemi informatici. La frattura tra le squadre non aiuta.
Ma devono collaborare. Una pratica emergente denominata DevSecOps, ad esempio, mira a gettare un ponte tra questi due ambiti contrapposti, integrando i membri e i processi del team di sicurezza nel ciclo di vita dello sviluppo del software al fine di individuare tempestivamente le vulnerabilità. Ciononostante, profonde questioni culturali, una carenza globale di competenze nel campo della sicurezza e delle strutture organizzative continuano a ostacolare l’armonia tra i team. Mentre i responsabili IT cercano soluzioni per superare questi ostacoli, sono emerse diverse buone pratiche, a cominciare da un sostegno più chiaro da parte dei vertici aziendali e dallo sviluppo di una cultura collaborativa. Ecco come iniziare:
È la dirigenza a dare l’esempio
Dopo che nel 2001 due worm particolarmente dannosi colpirono Microsoft , l’anno successivo Bill Gates inviò un promemoria a tutta l’azienda, annunciando che la sicurezza sarebbe diventata parte integrante della programmazione di tutti i suoi prodotti: «Quando ci troviamo di fronte alla scelta tra l’aggiunta di funzionalità e la risoluzione di problemi di sicurezza», scrisse Gates, «dobbiamo scegliere la sicurezza». … Stiamo formando tutti i nostri sviluppatori sulle più recenti tecniche di programmazione sicura. ... «Il nostro software dovrebbe essere talmente sicuro alla base che i clienti non debbano mai nemmeno preoccuparsene.»
Il risultato è stato il rivoluzionario e ampiamente imitato “” (Ciclo di vita dello sviluppo della sicurezza), un insieme di pratiche che integrano la sicurezza nel prodotto man mano che questo viene sviluppato e perfezionato. Da allora, le aziende del settore tecnologico hanno adottato — e adattato — tali pratiche di sicurezza.
La lezione: l’introduzione di misure di sicurezza nel ciclo di vita dello sviluppo del prodotto potrebbe influire in modo significativo sulle tempistiche. E se i vertici non ne fanno una priorità, sarà molto più complicato convincere i livelli inferiori della gerarchia. «A partire dai vertici, è necessario acquisire una comprensione del business che sia in linea con gli obiettivi aziendali», afferma Rosenquist.
“Partendo dall’alto, è necessario acquisire una comprensione del business che sia in linea con gli obiettivi aziendali”Matthew Rosenquist, responsabile della sicurezza informatica (CISO) presso Eclipz.io Inc
David Hahn ne ha avuto esperienza diretta. In qualità di CISO che ha lavorato nel settore della sicurezza informatica presso la Silicon Valley Bank, il conglomerato mediatico Hearst, Intuit e altre aziende, ha instaurato con successo collaborazioni con i responsabili IT, concordando sul fatto che la sicurezza informatica debba avere voce in capitolo e trasmettendo ai loro team l’importanza di diverse competenze che, in ultima analisi, devono operare in sinergia. «Non si può entrare in scena in un secondo momento e interpretare il ruolo del cattivo», afferma.
Il trasferimento della responsabilità
Un modo per colmare questo divario consiste nel rendere la sicurezza una parte più integrante del processo di sviluppo. Secondo una ricerca condotta da EY, quasi due terzi delle aziende oggi non coinvolgono i team di sicurezza nelle fasi iniziali dei progetti IT.
Secondo gli esperti, un modo per contribuire a colmare tale divario consiste nell’adottare l’approccio “shift left” nel collaudo del software, ovvero dare priorità ai test in una fase molto più precoce del ciclo di sviluppo, anziché aggiungerli a posteriori. Inoltre, incoraggia, se non addirittura richiede, una maggiore collaborazione tra i team di sicurezza e gli sviluppatori.
Questo tipo di pratiche contribuisce ad abbattere i vecchi compartimenti stagni. «Si tratta di creare una nuova squadra», afferma Hahn. «Tutti dovrebbero acquisire competenze in materia di sviluppo, sicurezza e operazioni, ma alcuni avranno una preparazione più approfondita in uno di questi ambiti rispetto ad altri.»
Un modo per aiutarli a raggiungere tale obiettivo è attraverso la formazione. Fornire competenze in materia di sicurezza agli sviluppatori di software rappresenta «un’opportunità di crescita», afferma Hahn. Allo stesso modo, molti analisti della sicurezza trarrebbero vantaggio dall’apprendimento delle nozioni di base di programmazione. «Possono iniziare con un linguaggio di programmazione come Go o Python per comprendere la programmazione procedurale e le complessità dello sviluppo software», afferma Ax Sharma, ricercatore nel campo della sicurezza e ingegnere presso Sonatype, azienda di sviluppo software con sede nel Regno Unito. «Ciò contribuirà a ridurre lo scetticismo riguardo alla capacità del reparto sicurezza di contribuire ai risultati attesi dal team.»
DevSecOps: alla ricerca di nuovi modi di concepire la sicurezza e lo sviluppo
Se nei prossimi anni i team addetti alla sicurezza e allo sviluppo software riusciranno a trovare un nuovo spirito di collaborazione, ciò sarà in parte dovuto al fatto che avranno adottato uno stile di lavoro che si è rivelato estremamente efficace nel sanare un’altra annosa frattura aziendale: quella tra gli sviluppatori di software e i team operativi IT. Nel corso dell’ultimo decennio circa, gli sviluppatori hanno collaborato in modo molto più stretto con il reparto IT per integrare le due funzioni e rilasciare nuovo software in modo più rapido ed efficiente che mai.
Si tratta di una metodologia denominata DevOps, che, secondo GitLab, viene attualmente adottata in una forma o nell’altra da circa 62% delle organizzazioni aziendali. Il DevSecOps si basa sullo stesso concetto, integrando i test di sicurezza nel processo di sviluppo stesso, anziché in una fase successiva.
Il DevSecOps non si limita a coinvolgere i team di sicurezza nelle prime fasi del processo, ma consente all’intero gruppo di valutare la tolleranza al rischio. Agli ingegneri del software che temono che i loro colleghi della sicurezza informatica possano rallentare lo sviluppo, Hahn suggerisce un modo per mettere tutti d’accordo e garantire che lo sviluppo del codice proceda senza intoppi: spiegare loro cosa accadrebbe se le vulnerabilità non venissero individuate tempestivamente. «Introduca un modello di minaccia», afferma. «Quando si inizia a delinearne i contorni, diventa qualcosa di concreto. Si trasforma in una discussione tecnica, anziché in un semplice: «L’opinione di David non era granché, non mi piace».
Un modello di minaccia offre a entrambe le parti un modo per cercare un compromesso. Ad esempio, gli ingegneri del software sono desiderosi di realizzare un MVP o una versione beta di un nuovo prodotto che includa un database completo di dati proprietari. Il reparto sicurezza non vuole che quel database si trovi in alcun modo in prossimità del prodotto finché non sarà stato completato un test completo per individuare eventuali vulnerabilità. Un modello di minaccia potrebbe evidenziare i rischi insiti nel rendere disponibili dati sensibili in un prodotto non ancora completato.
E a quel punto spetta al team di sicurezza far sentire la propria voce. «Devono dire: “Non è necessario correre quel rischio”.» «Potremmo inserire dati fittizi», afferma Hahn. Anche il rapporto di EY rileva che i team addetti alla sicurezza potrebbero comunicare meglio tali rischi.
Nel cercare di avvicinare le due parti, Sharma suggerisce di iniziare con iniziative su piccola scala, quali la verifica dello stato dei processi di sicurezza e dei livelli di minaccia relativi a tutti i prodotti. Ciò consentirà di comprendere meglio in quali punti si verificano le vulnerabilità. A quel punto, i due team potranno avvalersi di strumenti di automazione della sicurezza , quali i software di rilevamento del malware, per individuare le vulnerabilità residue. «Considerate il primo mese dei vostri sforzi come una fase di osservazione, in modo che i team possano constatare gli effetti, collaborare e apportare modifiche per eliminare gli sprechi», afferma Sharma.
Quando le cose vanno a rotoli
A volte le cose andranno per il verso giusto. Altre volte, invece, non lo faranno. Quando le due parti non riescono a collaborare, occorre individuare due cause, afferma Hahn: lo “scope creep”, che fa deragliare un progetto rispetto alle tempistiche e al processo previsti, e l’ego. «Come nel caso di persone che non rispettano i principi che avevano concordato», afferma.
A quel punto, è il momento di sospendere lo sviluppo, anche se ciò comporta il rinvio della data di rilascio. È meglio individuare una vulnerabilità di sicurezza che comporti un ritardo di due mesi nel progetto, afferma Hahn, piuttosto che trovarsi di fronte a una potenziale catastrofe dopo il lancio pubblico.
«Ci sarà sempre un costo», afferma Rosenquist, CISO di Eclipz.io. «Ma in questo modo si riducono le perdite o si garantisce la conformità alle normative.» Unire i team addetti alla sicurezza e quelli informatici, aggiunge, non è vantaggioso solo per i dipendenti. «Può rappresentare un vantaggio competitivo.»
