Sicurezza in DevOps (DevSecOps)

La sicurezza è una parte fondamentale di DevOps. Ma come fa un team a sapere se un sistema è sicuro? È davvero possibile fornire un servizio completamente sicuro?

Purtroppo, la risposta è no. DevSecOps è un impegno continuo e continuativo che richiede l'attenzione di tutti gli utenti nelle operazioni di sviluppo e IT. Anche se il lavoro non viene mai fatto veramente, le procedure che i team usano per prevenire e gestire le violazioni possono aiutare a produrre sistemi il più sicuri e resilienti possibile.

"Fondamentalmente, se qualcuno vuole entrare, stanno entrare... accettare questo. Quello che diciamo ai clienti è: numero uno, sei nella lotta, se pensavi che fossi o no. Numero due, quasi certamente sono penetrati." - Michael Hayden, ex direttore di NSA e CIA

Conversazione di sicurezza

I team che non hanno una strategia DevSecOps formale sono invitati a iniziare a pianificare il prima possibile. All'inizio potrebbe esserci resistenza da parte dei membri del team che non apprezzano appieno le minacce esistenti. Altri potrebbero ritenere che il team non sia attrezzato in modo adeguato per affrontare il problema e che qualsiasi investimento speciale potrebbe costituire una distrazione superflua dalla distribuzione di funzionalità. Tuttavia, è necessario iniziare la conversazione per creare il consenso sulla natura dei rischi, sul modo in cui il team può attenuarli e se il team ha bisogno di risorse che non hanno attualmente.

È bene aspettarsi alcune obiezioni comuni da parte dei più scettici, ad esempio:

• Quanto è reale la minaccia? I team spesso non riconoscono il potenziale valore dei servizi e dei dati per la cui protezione vengono loro addebitati costi.
• Il team è già efficiente. Una discussione sulla sicurezza può essere percepita come dubbio nella capacità del team di creare un sistema sicuro.
• Il rischio non sembra reale. Questo è un argomento comune dei tecnici junior. Le figure con maggiore esperienza di solito hanno un quadro migliore della situazione.
• L'azienda non è mai stata violata prima. Ma come esserne certi? Sarebbe impossibile.
• Infinite discussioni sul valore. DevSecOps è un impegno serio che può essere percepito come una distrazione dalle attività principali relative alle funzionalità. Anche se l'investimento nella sicurezza deve essere bilanciato con altre esigenze, non può essere ignorato.

Il cambiamento di mentalità

Le impostazioni cultura di DevSecOps richiedono un importante cambiamento di mentalità. Non solo è necessario prevenire violazioni, ma presupporre anche loro.

Componenti della strategia di sicurezza

Esistono molte tecniche che possono essere applicate nella ricerca di sistemi più sicuri.

Prevenzione delle violazioni	Presunzione di violazione
Modelli di rischio	Esercizi di simulazione di attacchi
Revisioni del codice	Monitor di sicurezza centrali
Test di sicurezza	Test di penetrazione del sito live
Security Development Lifecycle (SDL)

Ogni team dovrebbe già avere almeno alcune procedure per prevenire le violazioni. La scrittura di codice sicuro è diventata una prassi più che assodata e sono disponibili numerosi strumenti gratuiti e commerciali per supportare l'analisi statica e altre funzionalità di test di sicurezza.

Tuttavia, molti team non dispongono di una strategia che presuppone violazioni del sistema sono inevitabili. Supponendo che l'utente sia stato violato può essere difficile da ammettere, soprattutto quando si verificano conversazioni difficili con la gestione, ma questo presupposto può aiutare a rispondere a domande sulla sicurezza nel proprio tempo. Non vuoi capire tutto durante una vera e propria emergenza di sicurezza.

Le domande comuni da considerare includono:

• Come si rileva un attacco?
• Come si risponde in caso di attacco o penetrazione?
• Come si esegue il ripristino da un attacco, ad esempio quando i dati sono stati persi o manomessi?

Procedure devSecOps chiave

Esistono diverse procedure devSecOps comuni che si applicano praticamente a qualsiasi team.

In primo luogo, concentrarsi sul miglioramento del tempo medio per il rilevamento e il tempo medio per il ripristino. Queste metriche indicano il tempo necessario per rilevare una violazione e il tempo necessario per il ripristino, rispettivamente. Possono essere monitorati tramite test in tempo reale in corso dei piani di risposta alla sicurezza. Quando si valutano i potenziali criteri, il miglioramento di queste metriche deve essere una considerazione importante.

Praticare la difesa in profondità. Quando si verifica una violazione, gli utenti malintenzionati possono accedere alle reti interne e a tutti gli elementi all'interno di essi. Anche se sarebbe l'ideale per fermare gli utenti malintenzionati prima di raggiungere questo punto, un criterio di assunzione di violazioni spinge i team a ridurre al minimo l'esposizione da parte di un utente malintenzionato che ha già ottenuto.

Infine, eseguire valutazioni periodiche post-violazione delle procedure e degli ambienti. Dopo aver risolto una violazione, il team deve valutare le prestazioni dei criteri, nonché la loro conformità. I criteri sono più efficaci quando i team li seguono effettivamente. Ogni violazione, sia reale che praticata, dovrebbe essere vista come un'opportunità per migliorare.

Strategie per mitigare le minacce

Ci sono troppe minacce per enumerarle tutte. Alcuni problemi di sicurezza sono correlati alle dipendenze, ad esempio per sistemi operativi e librerie, che è quindi fondamentale mantenere aggiornati. Altri sono dovuti a bug nel codice di sistema che richiedono un'attenta analisi per l'individuazione e la correzione. Una gestione poco attenta dei segreti è la causa di molte violazioni, come pure l'ingegneria sociale. È consigliabile considerare i diversi tipi di buchi di sicurezza e cosa significano per il sistema.

Attack vectors (Vettori di attacco)

Si consideri uno scenario in cui un utente malintenzionato ha ottenuto l'accesso alle credenziali di uno sviluppatore. Cosa possono fare?

Privilege	Attacco
Possono inviare messaggi di posta elettronica?	Colleghi phish
Possono accedere ad altri computer?	Accedi, mimikatz, ripeti
Possono modificare l'origine	Inserire il codice
Possono modificare il processo di compilazione/rilascio?	Inserire codice, eseguire script
Possono accedere a un ambiente di test?	Se un ambiente di produzione dipende dall'ambiente di test, sfruttarlo
Possono accedere all'ambiente di produzione?	Tante opzioni...

In che modo il team può difendersi da questi vettori?

• Archiviare segreti in insiemi di credenziali protette
• Rimuovere gli account amministratore locale
• Limitare SAMR
• Credential Guard
• Rimuovere i server dual homed
• Sottoscrizioni separate
• Autenticazione a più fattori
• Workstation con accesso con privilegi
• Rilevare con ATP e Microsoft Defender per il cloud

Gestione dei segreti

Tutti i segreti devono essere archiviati in un insieme di credenziali protetto. I segreti includono:

• Password, chiavi e token
• Chiavi dell'account di archiviazione
• Certificati
• Anche le credenziali usate negli ambienti non di produzione condivisi

È consigliabile usare una gerarchia di insiemi di credenziali per eliminare la duplicazione dei segreti. Considerare anche come e quando si accede ai segreti. Alcuni vengono usati in fase di distribuzione durante la compilazione delle configurazioni dell'ambiente, mentre altri sono accessibili in fase di esecuzione. I segreti in fase di distribuzione richiedono in genere una nuova distribuzione per selezionare nuove impostazioni, mentre i segreti di runtime vengono accessibili quando necessario e possono essere aggiornati in qualsiasi momento.

Le piattaforme hanno funzionalità di archiviazione sicure per la gestione dei segreti nelle pipeline CI/CD e negli ambienti cloud, ad esempio Azure Key Vault e GitHub Actions.

Strumenti utili

• Microsoft Defender per il cloud è ideale per gli avvisi dell'infrastruttura generica, ad esempio per malware, processi sospetti e così via.
• Strumenti di analisi del codice sorgente per i test di sicurezza delle applicazioni statici (SAST).
• Sicurezza avanzata di GitHub per l'analisi e il monitoraggio dei repository.
• mimikatz estrae password, chiavi, codici pin, ticket e altro ancora dalla memoria di lsass.exe, il servizio sottosistema autorità di sicurezza locale in Windows. Richiede solo l'accesso amministrativo al computer o un account con il privilegio di debug abilitato.
• BloodHound crea un grafico delle relazioni all'interno di un ambiente Active Directory. Può essere usato il red team per identificare facilmente i vettori di attacco difficili da identificare rapidamente.

Esercizi di simulazione di attacchi

Una pratica comune di Microsoft consiste nell'impegnarsi in esercizi di gioco di guerra. Si tratta di eventi di test di sicurezza in cui due team hanno il compito di testare la sicurezza e i criteri di un sistema.

La squadra rossa assume il ruolo di un utente malintenzionato. Tentano di modellare attacchi reali per trovare lacune nella sicurezza. Se possono sfruttare qualsiasi oggetto, dimostrano anche il potenziale impatto delle violazioni.

Il team blu assume il ruolo del team DevOps. Provano la loro capacità di rilevare e rispondere agli attacchi della squadra rossa. Ciò consente di migliorare la consapevolezza della situazione e misurare l'idoneità e l'efficacia della strategia DevSecOps.

Evolvere una strategia di giochi di guerra

I giochi di guerra sono efficaci per rafforzare la sicurezza perché motivano la squadra rossa a trovare e sfruttare i problemi. Probabilmente sarà molto più facile del previsto in anticipo. I team che non hanno tentato attivamente di attaccare i propri sistemi non sono generalmente a conoscenza delle dimensioni e della quantità di falle di sicurezza disponibili per gli utenti malintenzionati. La squadra blu può essere demoralizzata in un primo momento perché verranno eseguiti ripetutamente. Fortunatamente, il sistema e le procedure dovrebbero evolversi nel tempo in modo che la squadra blu vince costantemente.

Prepararsi ai giochi di guerra

Prima di iniziare i giochi di guerra, il team dovrebbe occuparsi di eventuali problemi che possono trovare attraverso un passaggio di sicurezza. Si tratta di un ottimo esercizio da eseguire prima di tentare un attacco perché fornirà un'esperienza di base per tutti gli utenti da confrontare dopo che il primo exploit viene trovato in un secondo momento. Iniziare identificando le vulnerabilità tramite una revisione manuale del codice e strumenti di analisi statici.

Organizzare i team

Le squadre rosse e blu devono essere organizzate per specialità. L'obiettivo è quello di creare i team più capaci per ogni lato al fine di eseguire il più efficacemente possibile.

Il red team dovrebbe includere alcuni tecnici e sviluppatori esperti della sicurezza che hanno familiarità con il codice. È anche utile aumentare il team con uno specialista di test di penetrazione, se possibile. Se non ci sono specialisti in-house, molte aziende forniscono questo servizio insieme al mentoring.

Il team blu deve essere costituito da tecnici esperti che hanno una conoscenza approfondita dei sistemi e della registrazione disponibili. Hanno la migliore possibilità di rilevare e affrontare comportamenti sospetti.

Eseguire giochi di guerra precoce

Aspettatevi che la squadra rossa sia efficace nei primi giochi di guerra. Dovrebbero essere in grado di riuscire attraverso attacchi abbastanza semplici, ad esempio trovando segreti non protetti correttamente, SQL injection e campagne di phishing riuscite. Dedicare molto tempo tra i round per applicare correzioni e feedback sui criteri. Questo può variare in base all'organizzazione, ma non si vuole iniziare il turno successivo fino a quando tutti sono sicuri che il round precedente sia stato estratto per tutto ciò che vale la pena.

Giochi di guerra in corso

Dopo alcuni round, il red team dovrà affidarsi a tecniche più sofisticate, ad esempio xsS (cross-site scripting), exploit di deserializzazione e vulnerabilità del sistema di progettazione. L'uso di esperti di sicurezza esterni in aree come Active Directory può essere utile per attaccare exploit più oscuri. In questo momento, la squadra blu non deve solo avere una piattaforma avanzata da difendere, ma farà anche uso di registrazione completa e centralizzata per la post-violazione forense.

"I difensori pensano negli elenchi. Gli utenti malintenzionati pensano nei grafici. Finché questo è vero, gli utenti malintenzionati vincono." - John Lambert (MSTIC)

Nel corso del tempo, la squadra rossa richiederà molto più tempo per raggiungere gli obiettivi. Quando lo fanno, spesso richiede l'individuazione e il concatenamento di più vulnerabilità per avere un impatto limitato. Tramite l'uso di strumenti di monitoraggio in tempo reale, il team blu deve iniziare a intercettare i tentativi in tempo reale.

Linee guida

I giochi di guerra non dovrebbero essere un free-for-all. È importante riconoscere che l'obiettivo è quello di produrre un sistema più efficace gestito da un team più efficace.

Codice di comportamento

Di seguito è riportato un codice di esempio di comportamento usato da Microsoft:

1. Sia le squadre rosse che blu non faranno alcun danno. Se il potenziale di causare danni è significativo, deve essere documentato e risolto.
2. Il team rosso non deve compromettere più del necessario per acquisire gli asset di destinazione.
3. Le regole di buon senso si applicano agli attacchi fisici. Mentre il red team è incoraggiato ad essere creativo con attacchi non tecnici, come l'ingegneria sociale, non dovrebbero stampare badge falsi, molestare persone, ecc.
4. Se un attacco di ingegneria sociale ha esito positivo, non divulgare il nome della persona compromessa. La lezione può essere condivisa senza alienare o imbarazzare un membro del team che tutti devono continuare a lavorare con.

Regole di coinvolgimento

Di seguito sono riportate le regole di esempio di engagement usate da Microsoft:

1. Non influire sulla disponibilità di alcun sistema.
2. Non accedere ai dati dei clienti esterni.
3. Non indebolire in modo significativo le protezioni di sicurezza sul posto in qualsiasi servizio.
4. Non eseguire intenzionalmente azioni distruttive su alcuna risorsa.
5. Cassaforte guard credenziali, vulnerabilità e altre informazioni critiche ottenute.

Risultati finali

Eventuali rischi o lezioni di sicurezza appresi devono essere documentati in un backlog degli elementi di ripristino. Teams deve definire un contratto di servizio per quanto rapidamente verranno affrontati i rischi per la sicurezza. I rischi gravi devono essere affrontati il prima possibile, mentre i problemi minori possono avere una scadenza a due sprint.

Un report deve essere presentato all'intera organizzazione con lezioni apprese e vulnerabilità rilevate. È un'opportunità di apprendimento per tutti, quindi sfruttare al meglio.

Lezioni apprese in Microsoft

Microsoft pratica regolarmente i giochi di guerra e ha imparato molte lezioni lungo la strada.

• I giochi di guerra sono un modo efficace per cambiare la cultura di DevSecOps e mantenere la sicurezza top-of-mind.
• Gli attacchi di phishing sono molto efficaci per gli utenti malintenzionati e non devono essere sottovalutati. L'impatto può essere contenuto limitando l'accesso di produzione e richiedendo l'autenticazione a due fattori.
• Il controllo del sistema di progettazione porta al controllo di tutto. Assicurarsi di controllare rigorosamente l'accesso all'agente di compilazione/rilascio, alla coda, al pool e alla definizione.
• Praticare la difesa in profondità per rendere più difficile per gli utenti malintenzionati. Ogni limite che devono violare li rallenta e offre un'altra opportunità per catturarli.
• Non mai cross trust realms. L'ambiente di produzione non deve mai considerare attendibile nulla in fase di test.

Passaggi successivi

Altre informazioni sul ciclo di vita di sviluppo della sicurezza e DevSecOps in Azure.