Strategie di architettura per i test di sicurezza

Si applica a questa raccomandazione dell'elenco di controllo per la sicurezza di Azure Well-Architected Framework:

Un test rigoroso è la base di una buona progettazione della sicurezza. Il test è anche un modo proattivo per rilevare le vulnerabilità nel sistema.

Stabilire il rigore dei test attraverso la cadenza e la verifica da più prospettive. Includi prospettive inside-out che mettono alla prova la piattaforma e l'infrastruttura e valutazioni outside-in che testano il sistema come farebbe un attaccante esterno.

Le strategie principali di questo articolo si basano sulle procedure di test di base descritte in Strategie di architettura di OE:09 per i test. Esaminare prima l'articolo. Questa guida fornisce raccomandazioni per testare il comportamento di sicurezza del carico di lavoro. Implementare questi metodi di test per migliorare la resistenza del carico di lavoro agli attacchi e mantenere la riservatezza, l'integrità e la disponibilità delle risorse.

Terminologia

Collaborare con esperti di sicurezza per progettare i test

Essere coinvolti nella pianificazione dei test. Spesso, un'organizzazione centralizza questa attività. Assicurarsi che il team sia coinvolto nel processo di progettazione in modo che le garanzie di sicurezza siano allineate alle funzionalità dell'applicazione.

Adotta una mentalità che presuppone una violazione già avvenuta. Progettare i test case presupponendo che il sistema sia sotto attacco e che l'utente malintenzionato opera all'interno dell'ambiente. Simulare i test per riflettere scenari di attacco realistici, ad esempio la convalida del contenimento dello spostamento laterale all'interno di una macchina virtuale dell'applicazione compromessa. In questo modo, è possibile individuare potenziali vulnerabilità e classificare in ordine di priorità i test di conseguenza.

Condividere i diagrammi architetturali, il modello di minaccia e altre documentazione pertinenti per testare significativamente il carico di lavoro.

Classificare in ordine di priorità i test in base alla modellazione delle minacce e ai flussi critici

La modellazione delle minacce è una procedura chiave per identificare potenziali minacce e vulnerabilità nel carico di lavoro. Usare le classificazioni di gravità del modello di minaccia per definire le priorità e definire l'ambito delle attività di test. Le minacce di gravità più elevate contro i flussi più critici meritano la maggior parte della copertura.

Coprire l'intera superficie di attacco del carico di lavoro. Valutare identità, codice dell'applicazione, controlli dell'infrastruttura, componenti di terze parti, librerie e servizi e processi automatizzati e umani, ad esempio flussi di lavoro di approvazione e verifiche di accesso.

Iniziare con i controlli di identità e accesso perché un'identità compromessa ignora la maggior parte delle difese downstream. Convalidare quindi i limiti di rete e infine le difese a livello di applicazione.

Classificare in ordine di priorità i flussi che gestiscono l'autenticazione, i dati sensibili o le transazioni finanziarie. Per ogni flusso critico, identificare le minacce con la classificazione di gravità più elevata nel modello di minaccia. Crea casi di test basati sul rischio che associano ciascuna minaccia al controllo destinato a mitigarla.

Un buon esercizio di modellazione delle minacce punta alle aree chiave per la copertura e la frequenza dei test. Per consigli sulla modellazione delle minacce, vedere Raccomandazioni per la protezione di un ciclo di vita di sviluppo.

Rischio: modelli di minaccia non aggiornati possono portare a sforzi di test disallineati. Aggiornare regolarmente il modello di minaccia per riflettere le modifiche apportate al carico di lavoro e al panorama delle minacce in continua evoluzione.

Sfruttare le competenze di terze parti

I team interni possono avere punti ciechi. Gli esperti esterni e i ricercatori provenienti dal crowdsourcing vedono il tuo carico di lavoro nello stesso modo in cui lo vede un aggressore. Portare esperti specializzati a testare il carico di lavoro dal punto di vista di un avversario e fornire informazioni dettagliate sulle tecniche e le tendenze di attacco più recenti.

Evitare di concedere l'accesso eccessivamente permissivo al carico di lavoro. Concedere ai tester esterni solo l'accesso richiesto dal coinvolgimento specifico. Un test di penetrazione black-box non necessita di codice o accesso interno, mentre una revisione white-box richiede codice sorgente, documenti di progettazione o log.

Valutare se il team ha la capacità di valutare i report esterni prima di avviare un programma. Stabilire quindi un bug bounty program o un meccanismo che consenta alla comunità di segnalare problemi di sicurezza. Valuta ogni riscontro segnalato, reintegra le vulnerabilità confermate nel tuo modello delle minacce e aggiungi un caso di test per individuare eventuali regressioni.

Testare i controlli di conformità e generare prove pronte per il controllo

La conformità non è una revisione una tantum. Considerare ogni controllo normativo come requisito verificabile in modo da avere sempre nuove prove per i revisori.

Identificare le normative che il carico di lavoro deve soddisfare. Associare ogni controllo normativo a uno specifico caso di test. Programmare l'esecuzione dei test con cadenza ricorrente e prima di ogni messa in produzione. Archiviare l'output del test in una posizione controllabile in modo da poter produrre prove su richiesta.

Svantaggio: I test relativi ai controlli normativi possono rallentare le operazioni. Ad esempio, i test di pre-distribuzione aggiungono latenza della pipeline. È anche previsto un costo aggiuntivo per l'esecuzione di tali operazioni. Assegna priorità ai test per i controlli con il maggiore impatto su audit e rischi.

Rischio: l'evidenza di controllo è di per sé sensibile. Senza la protezione dell'integrità e la registrazione degli accessi, l'archivio delle prove diventa sia un bersaglio di attacco che una potenziale violazione di conformità.

Proteggere gli asset di test

Gli asset di test sono essi stessi una superficie di attacco. Proteggere la riservatezza, l'integrità e la disponibilità in modo che i test non espongano informazioni riservate o aprono nuovi vettori di attacco.

• Usare dati sanificati o sintetici che non contengono informazioni personali (PII) o dati di produzione.
• Conservare i dati di test solo se necessario ed eliminarli in modo sicuro.
• Verificare che le regole di residenza dei dati transfrontaliere vengano applicate negli ambienti di test che si estendono su aree.
• Generare credenziali di test dedicate, chiavi API e certificati. Archiviarle in un'istanza separata dell'insieme di credenziali delle chiavi con criteri di accesso dedicati.
• Configurare ambienti di test isolati che rispecchiano i controlli di sicurezza di produzione, ad esempio i gruppi di sicurezza di rete (NSG), i criteri di controllo degli accessi in base al ruolo, il firewall e le regole di prevenzione della perdita dei dati . Applicare le stesse linee guida di segmentazione usate in produzione. Per altre informazioni, vedere Raccomandazioni per la strategia di segmentazione.

Eseguire analisi regolari delle vulnerabilità sugli asset di test

Analizzare gli asset di test per individuare le vulnerabilità nella stessa frequenza degli asset di produzione, tra cui codice di test, infrastruttura come codice (IaC), immagini di contenitori e vm, repository e pipeline. Usare gli strumenti che si integrano con i flussi di lavoro di sviluppo e distribuzione per automatizzare questi controlli.

Stabilire un ritmo di test continuo per il carico di lavoro

Considerare i test di sicurezza come un'attività continua che mantiene aggiornato il comportamento di sicurezza del carico di lavoro man mano che si evolvono minacce, codice e configurazioni. Eseguire test in base a una pianificazione in modo che le modifiche non introducono rischi o regressioni per la sicurezza. Prepararsi per le convalide della sicurezza dell'organizzazione che possono verificarsi in qualsiasi momento e per i test attivati da un evento imprevisto di sicurezza. Le sezioni seguenti descrivono le cadenze da prevedere.

Test di routine

I test di routine impostano la baseline per il comportamento di sicurezza del carico di lavoro. Eseguirli a cadenza regolare, come parte delle procedure operative standard e per soddisfare i requisiti di conformità. È possibile eseguire vari test a cadenza diversa, ma la chiave è che vengono eseguite periodicamente e in base a una pianificazione.

Diversificare il gruppo di test per verificare le garanzie di identità, archiviazione e trasmissione dei dati e canali di comunicazione. Man mano che vengono rilevati nuovi problemi negli stessi punti del ciclo di vita, aggiungere nuovi test case.

Non fare affidamento solo sui test automatizzati. Usare test manuali per individuare le vulnerabilità che solo l'esperienza umana può intercettare e per il lavoro esplorativo su rischi sconosciuti.

Test improvvisati

Gli test improvvisati forniscono la convalida momentanea delle difese di sicurezza. Gli avvisi di sicurezza che potrebbero influire sul carico di lavoro in quel momento attivano questi test. I mandati organizzativi potrebbero richiedere una mentalità di sospensione e verifica per controllare l'efficacia delle strategie di difesa se l'allerta si trasforma in un'emergenza.

Il vantaggio dei test improvvisati è la preparazione per un vero incidente. Questi test possono essere una funzione forzata per eseguire test di accettazione utente (UAT).

Il team di sicurezza potrebbe controllare tutti i carichi di lavoro ed eseguire questi test in base alle esigenze. In qualità di proprietario del carico di lavoro, è necessario facilitare e collaborare con i team di sicurezza. Negoziare un tempo di lead time sufficiente con i team di sicurezza in modo da potersi preparare. Riconoscere e comunicare al team e agli stakeholder che queste interruzioni sono necessarie.

In altri casi, potrebbe essere necessario eseguire test e segnalare lo stato di sicurezza del sistema contro la potenziale minaccia.

Controindicazione: Poiché i test improvvisati sono eventi che interrompono il normale flusso di lavoro, è prevedibile dover ridefinire le priorità delle attività, il che potrebbe ritardare altre attività pianificate.

Rischio: C'è il rischio dell'sconosciuto. I test improvvisati possono essere attività occasionali senza processi o strumenti stabiliti. Ma il rischio predominante è l'interruzione potenziale del ritmo di attività. Valutare tali rischi in relazione ai vantaggi.

Test degli eventi imprevisti di sicurezza

Usa test che rilevano la causa di un incidente di sicurezza alla fonte. Risolvere questi gap di sicurezza per evitare che l'evento imprevisto venga ricorrente.

Gli eventi imprevisti migliorano anche i test case nel tempo individuando lacune esistenti. Il team deve applicare le lezioni apprese dall'evento imprevisto e incorporare regolarmente miglioramenti.

Convalidare i controlli di sicurezza nella superficie di attacco

Usare un'ampia gamma di metodologie di test per ottenere una copertura completa e individuare lacune nei controlli di sicurezza, configurazioni errate e punti deboli nell'osservabilità e nel rilevamento. La maggior parte dei test descritti in questa sezione può essere eseguita come test di routine. Tuttavia, la ripetibilità può comportare costi e causare interruzioni. Considerare attentamente questi compromessi.

Testare i controlli di crittografia. Gli errori di crittografia sono invisibile all'utente. I dati sembrano protetti fino a quando non viene mostrata una violazione.

• Verificare che la crittografia venga applicata, non solo configurata.
• Ripetere il test dopo ogni modifica di rotazione delle chiavi, rinnovo del certificato e infrastruttura.

Testare i controlli di rete. I limiti di rete sono la posizione in cui viene applicata la segmentazione.

• Testarli dopo qualsiasi modifica della topologia di rete.
• Verifica che le regole di blocco predefinito siano rispettate e che i percorsi di traffico consentiti corrispondano all'architettura prevista.

Testare il codice dell'applicazione. Le difese a livello di applicazione sono l'ultimo limite prima che un utente malintenzionato raggiunga i dati.

• Verificare che le applicazioni distribuite resistano ai modelli di attacco comuni anziché analizzare solo il codice sorgente in fase di compilazione.
• Eseguire tecniche di test della sicurezza delle applicazioni (AST) nel codice sorgente per confermare procedure di codifica sicure e rilevare errori di runtime, ad esempio problemi di danneggiamento della memoria e privilegi. Per informazioni dettagliate, vedere Collegamenti della community.

Simulare attacchi basati sull'identità e verificare il rilevamento

Gli attacchi basati sull'identità sono il vettore di attacco iniziale più comune. Simulare questi attacchi per verificare che i controlli di identità funzionino e che il monitoraggio acquisisca gli eventi.

I controlli di accesso sono la prima linea di difesa. Testarli dopo ogni modifica di ruolo o criteri e in base a una pianificazione automatizzata. Simulare modelli di attacco comuni e verificare che i controlli applichino privilegi minimi e resistano ai tentativi di bypass.

Quando si progettano test, prendere in considerazione questi modelli di attacco:

• Aggiramento dell'autorizzazione
• Furto e riutilizzo di token
• Spostamento laterale tra account o servizi
• Escalation dei privilegi

Convalidare entrambi i lati di ogni controllo:

• Casi positivi: gli utenti autorizzati hanno esito positivo.
• Casi negativi: i tentativi non autorizzati vengono bloccati e registrati.

Testare il rilevamento e gli avvisi delle minacce

Il rilevamento che non attiva un avviso fornisce un valore minimo. Testare il monitoraggio e gli avvisi come parte di ogni convalida del controllo di sicurezza e verificare che i meccanismi progettati per rilevare gli attacchi funzionino come previsto.

Eseguite simulazioni complete degli attacchi, quindi confermate ogni fase della pipeline di rilevamento:

• Verificare che gli eventi di sicurezza, ad esempio i tentativi di accesso, le modifiche alle autorizzazioni e le operazioni dei token, vengano registrati con dettagli sufficienti.
• Verificare che la piattaforma SIEM (Security Information and Event Management) o il dashboard delle operazioni di sicurezza correla gli eventi correlati.
• Stabilire un accordo sul livello di servizio (SLA) per gli avvisi e verificare che consentano di intervenire e siano segnalati entro i tempi previsti.
• Verificare che i log non possano essere manomessi o eliminati da account non amministrativi.
• Verificare che il meccanismo di rilevamento di ciascun attacco simulato si attivi. Ad esempio, se si simula un attacco DDoS (Distributed Denial of Service) con modelli di traffico validi, verificare che la limitazione della frequenza rilevi e la attenua.

Per i carichi di lavoro consolidati, convalidare i vincoli di governance come parte dei test di routine. Introdurre intenzionalmente configurazioni non sicure e verificare che la pipeline rilevi e risponda. Verificare che i vincoli Criteri di Azure o di zona di destinazione applichino le protezioni previste. La piattaforma o il team di sicurezza esegue in genere questo test, non il team del carico di lavoro.

Rafforzare le difese con test basati sulle tattiche degli avversari

Usare test che consentono la ricerca delle minacce simulando attacchi reali. Questi test possono identificare potenziali attori delle minacce, le relative tecniche e i relativi exploit che rappresentano una minaccia per il carico di lavoro. Rendere gli attacchi il più realistico possibile. Usare tutti i potenziali vettori di minaccia identificati durante la modellazione delle minacce.

Ecco alcuni vantaggi del test tramite attacchi reali:

• Quando si effettuano questi attacchi come parte del test di routine, si usa una prospettiva esterna per controllare il carico di lavoro e assicurarsi che la difesa possa resistere a un attacco.
• In base alle lezioni apprese, il team aggiorna le proprie conoscenze e il livello di competenza. Il team migliora la consapevolezza della situazione e può autovalutare la propria idoneità a rispondere agli eventi imprevisti.

Rischio: i test in generale possono influire sulle prestazioni. I test distruttivi possono eliminare o danneggiare i dati e causare problemi di continuità aziendale. Esistono anche rischi associati all'esposizione delle informazioni. Mantenere la riservatezza dei dati. Assicurarsi l'integrità dei dati dopo aver completato il test.

Alcuni esempi di test simulati includono test black box e white-box, test di penetrazione ed esercizi di gioco di guerra.

Test a scatola nera e scatola bianca

Questi tipi di test offrono due prospettive diverse. Nei test black-box, gli interni del sistema non sono visibili. Nei test white-box, il tester ha una buona conoscenza dell'applicazione e ha anche accesso a codice, log, topologia delle risorse e configurazioni per l'esecuzione dell'esperimento.

Rischio: la differenza tra i due tipi è il costo iniziale. I test di tipo white-box possono essere costosi in termini di tempo necessario per comprendere il sistema. In alcuni casi, il test della scatola bianca ti richiede di acquistare strumenti specializzati. Il test black-box non richiede tempi di avvio, ma potrebbe non essere efficace. Potrebbe essere necessario impegnarsi in modo aggiuntivo per individuare i problemi. È un compromesso sull'investimento di tempo.

Test che simulano gli attacchi tramite test di penetrazione

Gli esperti di sicurezza che non fanno parte dei team IT o applicativi dell'organizzazione eseguono test di penetrazione o pentesting. Esaminano il sistema nel modo in cui gli agenti malevoli analizzano una superficie di attacco. L'obiettivo è individuare le lacune di sicurezza raccogliendo informazioni, analizzando le vulnerabilità e segnalando i risultati.

Compromesso: i test di penetrazione sono improvvisati e possono essere costosi in termini di interruzioni e investimenti monetari perché il pentesting è in genere un'offerta pagata da professionisti di terze parti.

Rischio: un esercizio di pentesting potrebbe influire sull'ambiente di runtime e potrebbe compromettere la disponibilità per il normale traffico.

I professionisti potrebbero dover accedere ai dati sensibili nell'intera organizzazione. Seguire le norme operative per assicurarsi che l'accesso non venga usato in modo improprio. Vedere le risorse elencate in Collegamenti correlati.

Test che simulano gli attacchi tramite esercizi di gioco di guerra

In questa metodologia di attacchi simulati, due team partecipano:

• La squadra rossa agisce come avversario e tenta di modellare gli attacchi reali. Se hanno esito positivo, si riscontrano lacune nella progettazione della sicurezza e si valuta il contenimento del raggio di esplosione delle violazioni.

• La squadra blu è la squadra del carico di lavoro che difende contro gli attacchi. Testano la loro capacità di rilevare, rispondere e correggere gli attacchi. Convalidano le difese che proteggono le risorse del carico di lavoro.

Se si eseguono regolarmente questi test, gli esercizi di gioco di guerra possono fornire visibilità e garanzia continui che le difese funzionino come progettato. Gli esercizi di gioco di guerra possono potenzialmente testare i livelli all'interno dei carichi di lavoro.

Una scelta comune per simulare scenari di attacco realistici è il training di simulazione degli attacchi di Microsoft Defender per Office 365.

Per altre informazioni, vedere Informazioni dettagliate e report per il training di simulazione degli attacchi.

Per informazioni sulla configurazione red-team e blue-team, vedere Microsoft Cloud Red Teaming.

Facilitazione di Azure

Microsoft Sentinel è un controllo nativo che combina le funzionalità SIEM (Security Information Event Management) e soAR (Security Orchestration Automated Response). Analizza eventi e log da varie origini connesse. In base alle origini dati e ai relativi avvisi, Microsoft Sentinel crea eventi imprevisti ed esegue l'analisi delle minacce per il rilevamento anticipato. Tramite l'analisi intelligente e le query, è possibile cercare in modo proattivo i problemi di sicurezza. Se si verifica un evento imprevisto, è possibile automatizzare i flussi di lavoro. Inoltre, usando i modelli di cartella di lavoro, è possibile ottenere rapidamente informazioni dettagliate tramite la visualizzazione.

Per la documentazione del prodotto, vedere Funzionalità di ricerca in Microsoft Sentinel.

Microsoft Defender per il cloud offre l'analisi delle vulnerabilità per varie aree tecnologiche. Per informazioni dettagliate, vedere Abilitare l'analisi delle vulnerabilità con Gestione delle vulnerabilità di Microsoft Defender - Microsoft Defender per il cloud.

La pratica di DevSecOps integra i test di sicurezza come parte di una mentalità di miglioramento continuo e continuo. Gli esercizi di gioco di guerra sono una pratica comune integrata nel ritmo di business presso Microsoft. Per altre informazioni, vedere Security in DevOps (DevSecOps).For more information, see Security in DevOps (DevSecOps).

Azure DevOps supporta strumenti di terze parti che è possibile automatizzare come parte delle pipeline di integrazione continua/distribuzione continua. Per informazioni dettagliate, vedere Abilitare DevSecOps con Azure e GitHub - Azure DevOps.

Collegamenti correlati

Seguire le regole di coinvolgimento per garantire che l'accesso non venga usato in modo improprio. Per indicazioni sulla pianificazione e l'esecuzione di attacchi simulati, vedere gli articoli seguenti:

• Regole di coinvolgimento nei test di penetrazione

• Test di penetrazione

È possibile simulare attacchi Denial of Service (DoS) in Azure. Assicurarsi di seguire i criteri descritti nei test di simulazione di Protezione DDoS di Azure.

Collegamenti della community

Test di sicurezza delle applicazioni: strumenti, tipi e procedure consigliate- GitHub Resources descrive i tipi di metodologie di test che possono testare le difese in fase di compilazione e runtime dell'applicazione.

Standard di Esecuzione dei Test di Penetrazione (PTES) fornisce linee guida degli scenari comuni e delle attività necessarie per stabilire un punto di riferimento.

OWASP Top Ten | OWASP Foundation offre procedure consigliate per la sicurezza per le applicazioni e i test case che coprono le minacce comuni.

Elenco di controllo per la sicurezza

Fare riferimento al set completo di raccomandazioni.