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, entreranno... accettalo." Quello che diciamo ai clienti è: numero uno, sei in gioco, che tu lo pensassi o meno. Numero due, quasi certamente siete penetrati." - Michael Hayden, ex direttore della NSA e della 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 non ritenere che il team sia in grado di affrontare il problema e che qualsiasi investimento speciale sarebbe una distrazione inutile dalle funzionalità di rilascio. 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.

Aspettatevi che gli scettici portino alcuni argomenti comuni, ad esempio:

• Quanto è reale la minaccia? I team spesso non apprezzano il reale valore dei servizi e dei dati di cui sono responsabili per la protezione.
• Il nostro team è buono, giusto? Una discussione sulla sicurezza può essere percepita come dubbio nella capacità del team di creare un sistema sicuro.
• Non credo che sia possibile. Questo è un argomento comune degli ingegneri junior. Quelli con esperienza di solito sanno meglio.
• Non siamo mai stati violati. Ma come fai a saperlo? Come vorresti sapere?
• Discussioni infinite sul valore. DevSecOps è un impegno serio che può essere percepito come una distrazione dal lavoro principale delle funzionalità. Anche se l'investimento di sicurezza deve essere bilanciato con altre esigenze, non può essere ignorato.

Il cambiamento di mentalità

La cultura DevSecOps richiede un cambiamento importante nella mentalità. Non solo è necessario prevenire violazioni, ma assumere anche che si verifichino.

Componenti della strategia di sicurezza

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

Prevenzione delle violazioni	Supponendo violazioni
Modelli di minaccia	Esercizi di gioco di guerra
Revisioni del codice	Monitoraggi di sicurezza centralizzati
Test di sicurezza	Test di penetrazione del sito web online
Ciclo di vita dello sviluppo della sicurezza (SDL)

Ogni team dovrebbe già avere almeno alcune procedure per prevenire le violazioni. La scrittura di codice sicuro è diventata più predefinita e sono disponibili molti strumenti gratuiti e commerciali per facilitare 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. Ammettere di essere stati violati può essere difficile, soprattutto quando si devono affrontare conversazioni complicate con la dirigenza, ma questa supposizione può aiutare a rispondere a domande sulla sicurezza con maggiore autonomia. Non vuoi capire tutto durante una vera e propria emergenza di sicurezza.

Le domande comuni da considerare includono:

• Come si rileva un attacco?
• Come risponderete se c'è un attacco o una penetrazione?
• Come si esegue il ripristino da un attacco, ad esempio quando i dati sono stati persi o manomessi?

Pratiche 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 ideale fermare gli utenti malintenzionati prima che raggiungano questo punto, una politica di presunzione di violazioni spinge i team a ridurre al minimo l'esposizione da parte di un utente malintenzionato che è già penetrato.

Infine, eseguire valutazioni periodiche delle pratiche e degli ambienti in seguito a violazioni. 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 dovuti a problemi nelle dipendenze, ad esempio sistemi operativi e librerie, quindi mantenerli up-to-date è critico. Altri sono dovuti a bug nel codice di sistema che richiedono un'attenta analisi per trovare e correggere. La cattiva gestione dei segreti è la causa di molte violazioni, come è l'ingegneria sociale. È consigliabile considerare i diversi tipi di buchi di sicurezza e cosa significano per il sistema.

Vettori di attacco

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

Privilegio	Attacco
Possono inviare messaggi di posta elettronica?	Colleghi che praticano il phishing
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 caveaux protetti
• Rimuovere gli account degli amministratori locali
• Limitare SAMR
• Credential Guard (Protezione delle Credenziali)
• Rimuovere i server a doppia connessione
• Sottoscrizioni separate
• Autenticazione a più fattori
• Workstation ad accesso privilegiato
• Rilevare minacce con Microsoft Defender e Advanced Threat Protection (ATP) per Cloud

Gestione dei segreti

Tutti i segreti devono essere archiviati in un caveau protetto. I segreti includono:

• Password, chiavi e token
• Chiavi dell'account di archiviazione
• Certificates
• Le credenziali vengono utilizzate anche in ambienti condivisi non di produzione.

È 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 for 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 gioco di guerra

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 attaccante. Tentano di modellare attacchi reali per trovare lacune nella sicurezza. Se possono sfruttare qualsiasi vulnerabilità, dimostrano anche il potenziale impatto delle loro 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 potrebbe essere demoralizzata all'inizio, poiché verranno sopraffatti 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 dovrebbe essere composto da ingegneri orientati alle operazioni che abbiano una conoscenza approfondita dei sistemi e dei log 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 round successivo fino a quando tutti sono sicuri che il round precedente sia stato estratto per tutto il suo valore.

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. Ormai, la squadra blu dovrebbe non solo avere una piattaforma rinforzata da difendere, ma utilizzerà anche registri completi e centralizzati per l'analisi forense post-violazione.

I difensori pensano per elenchi. Gli attaccanti pensano in grafi. Finché questo è vero, gli attaccanti 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.

Guidelines

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 condotta

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. Proteggere credenziali, vulnerabilità e altre informazioni critiche ottenute.

Risultati finali

Eventuali rischi per la sicurezza o lezioni apprese devono essere documentati in un backlog degli elementi di correzione. 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 entro 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 superare mai i regni di fiducia. La produzione non dovrebbe mai fidarsi di nulla in fase di test.

Passaggi successivi

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