Aggiungere la sicurezza a una soluzione nelle fasi avanzate del ciclo di vita di progettazione e sviluppo spesso comporta costose rilavorazioni e compromessi in termini di facilità d'utilizzo, con un impatto negativo sulle funzionalità della soluzione e sull’esperienza dell'utente. Progettare soluzioni sicure fin dall'inizio aiuta a garantire un giusto equilibrio tra facilità d'uso, interoperabilità, resilienza e sicurezza della soluzione finale.

Secure by design è il principio secondo cui le pratiche di progettazione, sviluppo e distribuzione di un progetto devono includere misure di sicurezza e conformità, implementate da un team competente ed esperto. I principi di progettazione della sicurezza, come quelli riportati di seguito, guidano le pratiche di pensiero architetturale.

Il processo di progettazione deve iniziare con l'uso del design thinking aziendale per concentrarsi sui risultati desiderati dagli utenti a livello di rischio, conformità e sicurezza, sia per gli stakeholder interni, sia per quelli esterni all’organizzazione. Gli stakeholder esterni includono clienti, governi e autorità normative. Gli stakeholder interni includono coloro che gestiscono il rischio, la conformità e la sicurezza.

Il processo di progettazione prosegue con il pensiero architetturale per definire le caratteristiche dell’architettura, le decisioni architetturali, l’architettura funzionale e il modello di distribuzione nel cloud. Si procede quindi con la definizione delle caratteristiche dei servizi di sicurezza, come resilienza, prestazioni e scalabilità.

Dopo la definizione dei requisiti e dell'architettura, si procede con l’ingegnerizzazione delle funzionalità e dell’infrastruttura di sicurezza, seguendo anche il principio del Secure by default.

IBM adotta da molti anni un approccio di sicurezza e privacy by design, utilizzato nello sviluppo dei prodotti. Si consiglia la lettura del Redpaper di IBM Security in Development: The IBM Secure Engineering Framework.

Quando gli utenti o i software di un sistema dispongono di privilegi eccessivi, esiste il rischio di uso improprio, sia accidentale che deliberato. I criminali informatici possono compromettere gli account privilegiati degli utenti interni e utilizzare i diritti per attraversare la rete e i sistemi.

Il privilegio minimo è il principio secondo cui il sistema dovrebbe fornire agli utenti o al software le funzionalità minime necessarie per svolgere l'attività desiderata. Il sistema deve implementare questo approccio dal livello più alto di un'applicazione fino alla singola connessione tra due componenti software.

Per implementare il principio del privilegio minimo, è necessario comprendere gli asset nel proprio ambiente IT dinamico. L’accesso privilegiato non riguarda solo gli utenti, poiché è fondamentale conoscere quali applicazioni possono accedere a quali dati. Il processo di scoperta, classificazione e valutazione del rischio è continuo. Aggregando i dati di rischio dagli asset digitali si possono scoprire nuovi insight sui rischi aziendali che aiutano a definire le policy corrette.

Un utente o un software possono avere un contesto sicuro al momento dell’identificazione e autenticazione iniziale di una sessione, ma un criminale informatico potrebbe compromettere la sessione attiva e utilizzarla per compromettere ulteriormente il sistema.

La verifica continua è il principio secondo cui un utente o un software devono essere costantemente verificati per valutare se hanno ancora un contesto sicuro. L'intento della verifica continua è quello di individuare i problemi e le vulnerabilità di sicurezza il prima possibile e, idealmente, prima che lo facciano gli attori delle minacce.

La verifica continua conferma che le entità siano chi o cosa dichiarano di essere, utilizzando pratiche come l’autenticazione a due fattori. Un workload potrebbe richiedere un aggiornamento per supportare la verifica continua di utenti e software attraverso soluzioni che utilizzano una Zero Trust Network Architecture (ZTNA). Le organizzazioni impegnate a garantire esperienze utente di alto livello evitano di disturbare l’utente con richieste non necessarie; tuttavia, questo livello di garanzia dell’identità è fondamentale per lo zero-trust.

Un attore delle minacce potrebbe aver già violato un'organizzazione. Se un'organizzazione cerca solo minacce al boundary esterno e non minacce che hanno utilizzato un meccanismo valido per bypassare il controllo del boundary, potrebbe non scoprire una violazione per molto tempo. La supposizione di una violazione è il principio secondo cui un'organizzazione presume che una violazione sia stata commessa da un attore delle minacce.

L'approccio richiede che la gestione delle minacce aggiunga il rilevamento interno proattivo, la ricerca di segnali di allarme precoce, il rilevamento delle minacce e l'uso di runbook comprovati. Rilevamento e risposta devono essere strettamente integrati con i livelli di insight ed enforcement, condividendo il contesto e adattando dinamicamente le policy di controllo degli accessi in risposta alle minacce identificate.

Un sistema informativo presenta vulnerabilità a livello di software, firmware e hardware. Via via che configurazioni e software cambiano, emergono nuove vulnerabilità. Se un livello di difesa è vulnerabile, il sistema deve comunque rimanere sicuro.

La protezione multilivello è il principio secondo cui un sistema possiede più livelli di difesa così che, se un livello fallisce, un altro rimanga attivo per proteggere i dati sensibili del sistema. Applicare un approccio multilivello a una strategia di sicurezza garantisce che un'organizzazione possa fermare un aggressore a un livello successivo quando uno dei livelli di difesa viene violato.

La strategia e l'architettura di sicurezza aziendale devono includere misure che offrano protezione attraverso i successivi livelli del modello di rete informatica tradizionale. In generale, un'organizzazione deve pianificare la sicurezza dal livello più elementare (sicurezza a livello di sistema) a quello più complesso (sicurezza a livello di trasmissione).

La superficie di attacco di un'organizzazione è la somma delle vulnerabilità, dei percorsi o dei metodi (talvolta chiamati vettori di attacco) che i criminali informatici possono utilizzare per ottenere l'accesso non autorizzato alla rete o ai dati sensibili, oppure per lanciare un attacco informatico. Poiché le organizzazioni adottano sempre più servizi cloud e modelli di lavoro ibridi (on-premise/lavoro da casa), le loro reti e le superfici di attacco associate diventano ogni giorno più grandi e complesse.

Ridurre al minimo la superficie di attacco è il principio secondo cui un sistema dovrebbe ridurre l’ambito dei vettori di attacco, limitando così i possibili modi in cui criminale informatico può ottenere l'accesso. Gli esperti di sicurezza dividono la superficie di attacco in tre categorie secondarie: superficie di attacco digitale, superficie di attacco fisica e superficie di attacco di social engineering.

1. La superficie di attacco digitale espone potenzialmente il cloud e l'infrastruttura on-premise dell'organizzazione a qualsiasi malintenzionato con una connessione internet. I vettori di attacco più comuni includono accesso alla rete, vulnerabilità del software, uso di risorse inutilizzate, shadow IT e software obsoleto.

2. La superficie di attacco fisica espone asset e informazioni generalmente accessibili solo agli utenti con accesso autorizzato all'ufficio fisico o ai dispositivi endpoint dell'organizzazione. Questo include attacchi da parte di insider malevoli, furto di dispositivi e il "baiting", ovvero un attacco in cui i criminali informatici lasciano unità USB infette da malware in luoghi pubblici nella speranza di indurre gli utenti a collegarle ai propri computer e scaricare involontariamente del malware.

3. La superficie di attacco di social engineering manipola le persone inducendole a condividere informazioni che non dovrebbero condividere, a scaricare software che non dovrebbero scaricare, a visitare siti web che non dovrebbero visitare, a inviare denaro ai criminali o a commettere altri errori che compromettono i loro asset personali o quelli dell’organizzazione.

Un’organizzazione dovrebbe valutare il rischio relativo ai dati sensibili elaborati dal sistema, esaminando ciascuna di queste superfici di attacco.

Gli utenti potrebbero avere accesso a dati altamente sensibili che consentono di oltrepassare i controlli, come le chiavi di crittografia, oppure avere il diritto di eseguire azioni altamente privilegiate, come trasferire ingenti somme di denaro. Anche quando un sistema monitora gli utenti, questi possono abusare dei loro diritti, con conseguenze catastrofiche per l'azienda.

La separazione dei compiti è il principio secondo il quale, per gli utenti con accesso privilegiato a dati o azioni, sia necessario il coinvolgimento di più utenti per completare l’operazione. Offre all'organizzazione la possibilità di suddividere le funzioni amministrative tra le persone senza sovrapporre le responsabilità, in modo che un utente non detenga un'autorità illimitata.

Per attività come la gestione delle chiavi crittografiche, l’organizzazione richiederà che gli amministratori delle chiavi gestiscano parti diverse di una chiave, in modo che nessun singolo amministratore conosca l’intera chiave. Per le transazioni commerciali, l'applicazione può richiedere che la persona che richiede una transazione necessiti di uno o più approvatori per completarla.

Per alcuni settori, un organismo di regolamentazione può richiedere la separazione dei compiti per funzioni critiche quale parte delle linee guida normative. La separazione dei compiti aiuta le aziende a rispettare le normative governative e semplifica la gestione delle autorizzazioni.

I prodotti o i servizi contengono molti punti di configurazione e c’è l’esigenza di renderli il più semplici possibile da usare. Di conseguenza, il prodotto presenta una configurazione di sicurezza non sicura, ad esempio con porte di rete aperte o password facili da ricordare.

Secure by default è il principio secondo cui un'organizzazione riceve, fin da subito, prodotti o servizi già configurati in uno stato sicuro. I prodotti sono configurati per proteggere dalle minacce e vulnerabilità più diffuse senza richiedere interventi aggiuntivi da parte degli utenti.

Un sistema può essere configurato in modo sicuro all’inizio, ma successivamente uno sviluppatore può apportare modifiche che ne alterano la configurazione oppure un criminale informatico può approfittare di una vulnerabilità, compromettendo il sistema.

La conformità continua è il principio secondo cui la configurazione di sicurezza del sistema viene costantemente controllata, a partire dallo sviluppo fino al funzionamento continuo del sistema stesso. L'intento della conformità continua è quello di individuare i problemi e le vulnerabilità di sicurezza prima che lo facciano i criminali informatici.

Idealmente, i controlli di conformità sono completamente automatizzati e coprono tutte le configurazioni di sicurezza, tra cui la piattaforma cloud, la piattaforma dei container, il middleware e le immagini di calcolo, come server virtuali e container. Con le immagini di calcolo, un approccio migliore potrebbe essere quello di utilizzare l'Infrastructure as Code (IaC) per sostituire regolarmente l'intera immagine.

Le responsabilità condivise per la gestione di sicurezza e conformità in un ambiente hybrid cloud dipendono dai modelli di servizio, dalle piattaforme di calcolo e dai fornitori di cloud service utilizzati dal workload o dall’applicazione. Un security architect deve documentare e comunicare le responsabilità che riguardano la progettazione, costruzione e gestione operativa dei servizi di sicurezza. Senza chiarezza, potrebbero esserci delle lacune nella sicurezza della soluzione.

Ogni dimensione ha un impatto diverso sulle responsabilità condivise:

• Modello di cloud service: la definizione NIST di cloud computing prevede i diversi ambiti di responsabilità a seconda del modello di cloud service, come IaaS, PaaS, SaaS o cloud distribuito. I servizi di sicurezza fanno parte delle responsabilità condivise. Ad esempio, le responsabilità condivise di IBM Cloud includono la gestione delle identità e degli accessi, nonché la conformità alla sicurezza e alle normative. Le responsabilità condivise per queste categorie variano a seconda del modello di cloud service.
   

• Piattaforma di calcolo: l'hosting di un workload può essere costituito da una o più piattaforme di calcolo, come bare metal server, server virtuali, piattaforme di container e serverless. Ogni piattaforma di calcolo ha una serie diversa di responsabilità condivise. Ad esempio, i server bare metal richiedono che il proprietario del workload sia responsabile di tutti i controlli di sicurezza sulla piattaforma, a eccezione dell'hardware fisico e dell'integrazione di rete.
   

• Provider di cloud service: le responsabilità cambiano anche a seconda del provider di cloud service. Ad esempio, la piattaforma Kubernetes di ciascun fornitore di servizi cloud è diversa (a meno che non si stia usando Red Hat OpenShift), poiché ognuna consiste in un insieme diverso di pacchetti open source selezionati.

Perché allora un security architect dovrebbe preoccuparsi delle differenze nella proprietà dei servizi? Il team addetto alle operazioni di sicurezza potrebbe disporre di servizi di sicurezza predefiniti per supportare l'esecuzione del servizio. I servizi di sicurezza possono far parte della piattaforma cloud oppure essere on-premise, richiedendo un'Integrazione estesa.

Ad esempio, un team interno delle operazioni di sicurezza può utilizzare una tecnologia diversa da quella di un systems integrator globale (GSI) come IBM Consulting. Per il team di sicurezza interna, il control plane che ospita i servizi di sicurezza può essere on-premise, mentre il GSI può utilizzare servizi cloud forniti da un altro provider di cloud service.

Con il modello di servizio cloud Software-as-a-Service (SaaS), l’utilizzatore del servizio cloud dispone solo dell’amministrazione della sicurezza dell’applicazione. La sicurezza è normalmente integrata nell'applicazione come parte del servizio, con un ambito limitato per controllare la configurazione di sicurezza. In questo caso, il fornitore SaaS si occupa della maggior parte delle responsabilità delle operazioni di sicurezza.

Senza responsabilità documentate, potrebbe non esserci un proprietario assegnato per progettare, costruire e gestire i componenti di sicurezza necessari al funzionamento del workload. Comprendere le responsabilità condivise per i servizi di sicurezza permette all'architettura della soluzione di soddisfare le esigenze operative ed evita la rielaborazione della soluzione in una fase successiva del progetto.

I servizi di sicurezza in un'architettura hybrid cloud utilizzano diversi modelli di cloud service, piattaforme di calcolo e fornitori di servizi cloud. Questi servizi necessitano di un'architettura concordata del control plane per garantire una gestione e una supervisione coerenti della sicurezza e della conformità.

In un'azienda che dispone di workload per data center on-site, il control plane può risiedere in un data center locale per garantire resilienza in caso di guasto di un provider di cloud service. Tuttavia, un servizio di sicurezza on-premise non sarà necessariamente in grado di gestire completamente la piattaforma cloud. Pertanto, è necessario progettare un’architettura del control plane in grado di segnalare lo stato della sicurezza e identificare i rischi dei diversi provider di cloud service.

Nelle organizzazioni nate nel cloud, l'hosting del control plane può risiedere in un altro cloud, essere ospitato in un point of presence (POP) oppure in un data center di co-location. Il control plane potrebbe dover essere disponibile, anche se si è verificato un guasto in un cloud service.

Per un security architect è fondamentale documentare e concordare le decisioni architetturali, per garantire l'allineamento con l'architettura del control plane in tutta l'organizzazione. Questa decisione deve essere presa all'inizio del progetto, per garantire che la soluzione rispetti la strategia dell'organizzazione.

La sicurezza non consiste solo nell'implementazione di funzionalità di sicurezza, bensì nella protezione dei dati e dei processi aziendali dalle minacce. Il consiglio è quello di utilizzare un approccio sistematico per tracciare i flussi di dati attraverso il sistema, al fine di identificare i controlli di sicurezza necessari a proteggere i dati in transito, a riposo e in uso.

Gli architetti devono identificare i dati sensibili da proteggere partendo da un diagramma contestuale di sistema per definire i confini del sistema e le interazioni esterne che avviano i flussi di dati attraverso il sistema. I flussi di dati interni dell'applicazione vengono poi esaminati utilizzando un diagramma per descrivere i componenti funzionali, come un diagramma dei componenti.

Via via che gli architetti si avvicinano all'implementazione, esaminano i flussi di dati tra i componenti distribuiti nell’infrastruttura cloud utilizzando un diagramma dell'architettura cloud. IBM ha creato un linguaggio di progettazione di diagrammi tecnici che consente di realizzare design indipendenti dal provider di cloud service.

Per identificare le minacce a questi flussi di dati, si può utilizzare la modellazione delle minacce sia per i componenti funzionali del workload, sia per l’infrastruttura del workload.

Insieme, queste tecniche e questi componenti offrono un approccio ripetibile e coerente al pensiero architetturale per la sicurezza e la conformità.

Quando si elaborano i dati più sensibili, è opportuno prendere in considerazione un ulteriore livello di protezione, utilizzando il confidential computing e la crittografia omomorfica.

Un sistema deve soddisfare numerosi requisiti di controllo, che possono accumularsi rendendo complessa la gestione. Invece di lavorare con molti requisiti individuali, è consigliabile lavorare con processi, servizi o funzionalità che raggruppano i requisiti in capacità operative. Ad esempio, la gestione del ciclo di vita dell'identità o il rilevamento di componenti non autorizzati sono potenziali capacità operative.

Questi passaggi consentono di gestire la conformità in modo più efficace:

1. Creare un unico framework di conformità, con la possibilità di risalire alle fonti originarie.
2. Mappare i requisiti del framework a una serie di funzionalità
3. Garantire funzionalità conformi in tutte le fasi di progettazione, sviluppo, test e operatività.
4. Continuare a soddisfare i requisiti in produzione.

Il security architect deve assicurarsi che le funzionalità di sicurezza siano accompagnate da Service Level Objective (SLO), responsabilità assegnate e così via.

Spesso è necessario garantire che i dati di un cliente, di una linea di business o di un ambiente non vengano divulgati ad altri. La separazione deve avvenire sia durante l’esecuzione del workload sia nello storage dei dati. Può essere semplice come usare una tabella diversa in un database o server fisici separati.

L'hybrid cloud offre molte opzioni per garantire la separazione nell’elaborazione dei dati. La separazione deve avvenire tra:

1. Workload o applicazioni, ad esempio contabilità e risorse umane
2. Ambienti, ad esempio sviluppo, test e produzione
3. Clienti, ad esempio, cliente A e cliente B
4. Luogo, ad esempio, Regno Unito e Stati Uniti

Esistono opzioni diverse per la segregazione all'interno di un ambiente hybrid cloud, con funzionalità e garanzie differenti:

1. Account enterprise
2. Account cloud
3. Gruppo di risorse
4. Cloud privato virtuale
5. Dominio di esecuzione, ad esempio un'immagine container o server
6. Progetto
7. Dominio di gestione delle chiavi
8. Dispositivi fisici

Le policy aziendali devono definire quale tipo di separazione sia adeguato per il workload che elabora i dati. Ad esempio, la policy può richiedere che l'hosting dati di produzione dei clienti avvenga solo in un ambiente di produzione. Il livello minimo di separazione necessario è un account cloud diverso, poiché è lì che avviene la gestione delle identità e degli accessi.

Collegato al tema della separazione dei dati è quello della sovranità dei dati. Alcuni paesi stanno imponendo vincoli sui luoghi in cui è possibile elaborare e accedere ai dati. Il post sul blog "Indirizzare le normative e promuovere l'innovazione con il cloud sovrano" offre una discussione su una gerarchia delle esigenze di sovranità dei dati.

La modellazione delle minacce è spesso considerata una tecnica per identificare e convalidare i controlli di sicurezza dei dati che fluiscono attraverso un sistema.

Tuttavia, la modellazione delle minacce ha un secondo scopo: identificare le minacce da monitorare in un sistema di monitoraggio delle minacce. Il security architect deve identificare un elenco prioritario delle minacce. Deve quindi definire i casi d'uso richiesti per la funzionalità di rilevamento delle minacce. In seguito, deve implementare e testare i casi d'uso del rilevamento con i runbook di risposta agli incidenti, per consentire una risposta efficace alle minacce.

Per finire, deve garantire la tracciabilità documentata tra le minacce, i casi d’uso di rilevamento delle minacce e i runbook di risposta agli incidenti, per assicurare una progettazione e una delivery complete del progetto.

Nei data center on-premise del passato, i team delle operazioni di sicurezza completavano le attività in pochi giorni o ore e non richiedevano livelli di servizio rigorosi. Con l'automazione Infrastructure as Code (IaC), la perdita di un servizio di sicurezza centralizzato, come segreti o gestione dei certificati, ha un impatto immediato sulla disponibilità di un'applicazione. Pertanto, i servizi di sicurezza richiedono livelli di servizio e un’architettura in grado di soddisfare i requisiti di disponibilità.

Per ogni funzionalità o servizio di sicurezza è necessario definire:

1. Orari del servizio
2. Tempi di risposta a incidenti, problemi e modifiche
3. Competenze ed esperienza del personale operativo
4. Procedure dettagliate e testate per soddisfare i requisiti del servizio
5. Automazione per soddisfare i requisiti del servizio

Se il team interno delle operazioni di sicurezza non è in grado di soddisfare le esigenze di un workload cloud-native, è necessario valutare se sia il caso di rivolgersi a un provider di servizi di sicurezza gestiti.

Di fatto, molti servizi di sicurezza devono attualmente garantire resilienza e livelli di servizio almeno equivalenti a quelli dei workload che supportano.

Le vecchie modalità di lavoro prevedevano che la sicurezza fosse un aspetto secondario, rendendo difficile completare la configurazione e l’applicazione delle patch, poiché non integrata all'inizio del ciclo di vita dello sviluppo. Con l'approccio DevOps, gli standard per le build di sicurezza devono essere:

1. Inclusi negli ambienti di sviluppo e test.
2. Coerenti dallo sviluppo iniziale alla produzione completa.
3. Sottoposti a continui test di conformità.

I processi di build devono prevenire la distribuzione non sicura di un workload in tutte le fasi di sviluppo e operatività, per garantire che la sicurezza non sia un aspetto secondario.