Finché si scriverà codice, le vulnerabilità software continueranno a esistere. Tuttavia, tenere conto di queste vulnerabilità non significa per forza dover applicare una patch a ognuna di esse. Anche se fosse possibile raggiungere un livello di sicurezza del 100%, è necessario bilanciare questa esigenza con le richieste di innovazione e flessibilità, fondamentali per il successo.
Nell’articolo che vi proponiamo oggi, Chris Jenkins, Principal Chief Architect, Cybersecurity Strategy & Adoption, Red Hat , spiega a quali aspetti di protezione le aziende devono dare priorità e dove invece dare spazio ai team per concentrarsi sul core business.
Sicurezza, come bilanciare innovazione e gestione del rischio
Con il mondo della cybersecurity in costante fermento, è cresciuta l’attenzione sui possibili approcci a “rischio zero”, in cui l’IT si concentra fortemente sulla risoluzione di tutte le vulnerabilità, grandi o piccole che siano. Un’architettura a rischio zero mira a eliminare qualsiasi possibilità di guasto o perdita di dati all’interno di un sistema, ma è il caso di chiedersi se questo andrà a scapito della capacità di innovazione dell’IT. L’organizzazione potrebbe perdere vantaggio competitivo? Un’elevata avversione al rischio da parte dell’IT, ad esempio, potrebbe limitare lo spazio per sperimentare nuove tecnologie mirate ad aumentare l’efficienza aziendale, con la possibilità che anche lo sviluppo di nuovi prodotti e servizi venga ritardato. Anche a livello di partnership, l’avversione al rischio potrebbe limitare l’appeal della propria organizzazione.
Per affrontare in modo efficace le vulnerabilità del software e mantenere la competitività, i team IT dovrebbero affrontare una reale politica di gestione del rischio, piuttosto che la sua pura e semplice prevenzione.
La gestione del rischio richiede trasparenza
Adottare un approccio basato sul rischio significa analizzare accuratamente gli obiettivi aziendali ed allineare le misure di sicurezza alle minacce e ai rischi effettivi. E questo richiede un’analisi approfondita per poterne valutare impatto, probabilità, minaccia, costo potenziale e necessità concreta di misure di sicurezza in termini di valore aggiunto.
Può essere utile pensare ai rischi concreti derivanti da elementi non controllati. Vanno risolte anche le vulnerabilità a basso rischio? Un percorso di rete che collega un servizio poco utilizzato può essere davvero rischioso? Spesso è meglio concentrare l’attenzione sulle vulnerabilità maggiori, che espongono le componenti critiche dell’infrastruttura agli attacchi. Comprendere appieno la superficie d’attacco ed eseguire una bonifica proattiva in base alle priorità identificate aiuterà a garantire che il valore aziendale non venga compromesso dall’applicazione di misure di sicurezza superflue.
Questa valutazione del rischio richiede un certo livello di trasparenza. In altre parole, deve essere chiaro quali vulnerabilità sono presenti nella catena di fornitura del software e per quali è necessario un intervento correttivo da parte dei fornitori. Migliorare la sicurezza della catena di fornitura del software significa adottare pratiche DevSecOps, consumare codice e dipendenze di terze parti in modo sicuro e integrare la sicurezza nel ciclo di vita dello sviluppo del software. Esistono soluzioni sul mercato che uniscono servizi cloud affidabili e flussi di lavoro prescrittivi per contribuire a salvaguardare i sistemi.
I vantaggi dell’open source per la sicurezza
È qui che il software open source eccelle, poiché i suoi progetti hanno in genere canali di comunicazione più aperti e log dettagliati che forniscono un quadro più completo della sicurezza complessiva del sistema.
L’89% dei dirigenti aziendali concorda sul fatto che il software open source sia altrettanto o più sicuro di quello proprietario. Il vantaggio principale citato dagli intervistati è che “il team può utilizzare codice open source ben testato per le applicazioni interne”. Vengono apprezzati anche il fatto che le patch di sicurezza sono ben documentate e possono essere analizzate, così come la disponibilità tempestiva da parte dei vendor di patch di vulnerabilità in ambito open source enterprise.
È importante assicurarsi che il proprio fornitore di software open source aziendale disponga di funzionalità di sicurezza stratificate attorno alle pipeline di sviluppo e delivery del codice e, inoltre, che possa integrare la sicurezza nei workflow di sviluppo del cliente. Tecniche semplici come la definizione di un software bill of materials (SBOM) possono aiutare ad attestare la sicurezza dei componenti e di qualsiasi dipendenza transitoria.
La cultura aziendale apre la strada verso una gestione responsabile dei rischi
Un buon equilibrio tra sicurezza, normative e considerazioni commerciali è fondamentale. Ma non è per forza facile da raggiungere, perché richiede un vero e proprio cambiamento culturale all’interno dell’azienda. Sono necessarie una comunicazione aperta, una collaborazione e un’interazione personale tra i team per promuovere la fiducia e un supporto efficace, in modo che priorità di sicurezza e obiettivi siano allineati.
Per realizzare questo cambiamento culturale, servono istruzione e formazione continua. In particolare, formare i team sulle best practice, le minacce emergenti e le nuove tecnologie rimane più importante che mai. Man mano che le organizzazioni migrano verso nuove tecnologie e abbracciano uno sviluppo cloud-native, queste conoscenze sono indispensabili per garantire una transizione di successo senza compromettere la sicurezza.
Se le vulnerabilità del software sono inevitabili, le organizzazioni possono ridurre al minimo i rischi allineando le misure di sicurezza ai rischi reali. Trasparenza, collaborazione e adattamento continuo sono elementi essenziali in questo processo. Promuovendo una cultura di formazione e di comunicazione aperta, le aziende possono affrontare efficacemente le vulnerabilità e stare al passo con minacce e tecnologie in continua evoluzione. In breve, la sicurezza dovrebbe essere trattata come una delle tante componenti costanti per una trasformazione di successo, non come un ostacolo o come elemento da considerare solo in caso di crisi.
di Chris Jenkins, Principal Chief Architect, Cybersecurity Strategy & Adoption, Red Hat
