Come costruire una cultura della sicurezza secondo AWS

A cura di Mark Schwartz – Enterprise Strategist in Amazon Web Services

Lasciare la sicurezza in mano a un team di specialisti che monitora i rischi per l’azienda e li controlla attraverso policy restrittive non è più sufficiente. Non basta controllare i confini del network aziendale tramite firewall, o semplicemente implementare set di controllo specifici in un framework di conformità. La sicurezza non è più un ingrediente segreto aggiunto al piatto poco prima di servirlo. Al contrario, è diventata un problema di tutti, un atto di preparazione degli ingredienti prima di aggiungerli al piatto. La sua gestione è diventata una questione strategica per l’azienda. E la strada per andare avanti è quella di costruire una cultura della sicurezza, una consapevolezza dei rischi e del loro controllo, un insieme di norme e pratiche in linea con l’obiettivo di mantenere l’azienda sicura. È importante quindi creare una vera e propria cultura, invece di rispondere in modo reattivo a minacce specifiche man mano che le si incontra.

I sistemi IT sono posti costantemente sotto attacco da strumenti malevoli che cercano un modo facile di entrare. Per non parlare delle minacce persistenti di talentuosi hacker di professione, disposti a investire tempo e denaro per fare breccia negli obiettivi che hanno selezionato. Eppure, le minacce non arrivano solo da qui: i sistemi IT possono anche essere ostacolati da dati sbagliati, picchi di utilizzo improvvisi, casi limite non testati che spesso coinvolgono operazioni concorrenti, failure a cascata e problemi di velocità che si moltiplicano. Inoltre, per garantire performance sicure i sistemi devono essere scalabili, resilienti, disponibili, testati, performanti e devono poter tollerare input inaspettati.

La sicurezza è un tipo di qualità. Ed è meno dispendioso implementarla fin da subito piuttosto che pagare le conseguenze di doverla aggiungere dopo.

Così come la qualità non è sinonimo di velocità, non lo è neanche la sicurezza. Allo stesso modo, la maggior parte degli exploit potrebbe essere fermata da semplici norme di sicurezza: esiste infatti una serie molto piccola di punti deboli che portano alla stragrande maggioranza delle intrusioni. Molti software ne incorporano altri di terze parti, soprattutto open source, ma usano versioni vecchie di cui si conoscono le vulnerabilità. In questo caso non ci sono scuse: sono infatti disponibili tool per identificare tali problematiche ed esistono suite di regressione automatica per gli aggiornamenti.

Se si chiede a qualsiasi CISO qual è la sua più grande paura, probabilmente le risposte saranno due: credenziali compromesse e impossibilità di fare gli aggiornamenti abbastanza spesso. Se a queste si aggiungono le principali vulnerabilità delle applicazioni, si ottiene la maggior parte delle intrusioni. Tuttavia, oggi esistono buone abitudini che forniscono modi non dispendiosi di evitare tali problemi senza rallentare l’intero processo o appesantire gli utenti: la sicurezza non è solo “roba da nerd”.

Il miglior modello di approccio alla sicurezza orientato alla cultura è quello del movimento Rugged (Solido) Software, o Rugged DevOps, che consiglia di costruire un software sicuro e resiliente semplicemente perché è la cosa giusta da fare.

I loro principi si riferiscono allo sviluppo di codici e software, ma si possono applicare all’intera azienda. Un’organizzazione che guardi alle minacce alla sicurezza e alla resilienza come a un costo extra, a un peso, a qualcosa di superfluo, di cui solo gli specialisti si devono preoccupare, o che non ci pensi affatto non potrà mai essere solida. Una simile azienda compie un’ingiustizia nei confronti dei suoi clienti (i cui dati sono a rischio), di sé stessa (che dovrà affrontare costi in più e danni alla propria reputazione) e degli investitori (i cui investimenti perderanno valore). E se si parla di agenzie governative, i danni potrebbero coinvolgere la nazione e i suoi cittadini.

In cosa dovrebbe consistere la cultura della sicurezza?

Ecco i principi di un’organizzazione solida, secondo The Rugged Handbook [1]:

• Obiettivo. L’azienda comprende di essere costantemente sotto attacco (siano essi attacchi voluti o accidentali) e lo prende in considerazione in ogni cosa che fa.
• Educazione alla sicurezza. L’azienda dà valore alla sicurezza (dal punto di vista tecnico o non, a seconda dei ruoli) e si tiene aggiornata sull’evoluzione delle minacce, ascolta i consigli degli specialisti e cerca di comprendere le regole e le policy di sicurezza.
• Norme comportamentali. Mettere in pratica e promuovere buone norme comportamentali fa parte del voler fare le cose nel modo giusto. Non si condividono le password, gli account degli utenti, né si lasciano informazioni sensibili sulla scrivania quando si torna a casa la sera.
• Miglioramento continuo. Nel caso accada che vengano lasciate informazioni sensibili sulla scrivania la sera, è bene ascoltare chi lo fa notare per non farlo più.
• Approccio zero-difetti. Quando si parla di sicurezza, non si accettano vulnerabilità: se si scopre un problema, lo si risolve immediatamente senza sottovalutarne nessuno.
• Strumenti riutilizzabili. Tenere un approccio strategico alla sicurezza significa organizzare i sistemi IT e impostare strumenti e processi condivisibili e ripetibili.
• Team Unificati. Tutte le divisioni dell’azienda collaborano per rendere la sicurezza forte e i sistemi resilienti.
• Test. I sistemi vengono testati rigorosamente (principalmente con test automatici) non solo mentre vengono sviluppati, ma anche quando sono in produzione. È necessario testare scenari di failure e la capacità di farvi fronte.
• Modellare le minacce. È necessario pensare come un hacker, prevedere possibili strade che potrebbero intraprendere per sconfiggere i controlli e condurre test per essere sicuri che poi non ci riescano.
• Revisioni paritarie. Ogni specialista dovrebbe pensare non solo a possibili difetti nel suo lavoro, ma anche a possibili vulnerabilità alla sicurezza. Il codice dovrebbe essere sempre rivisto da un collega, il quale dovrebbe anche lui cercare possibili vulnerabilità.

[1] The Rugged Handbook, https://www.ruggedsoftware.org/wp-content/uploads/2013/11/Rugged-Handbook-v7.pdf.