Raccomandazioni 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 è una forma tattica di convalida per assicurarsi che i controlli funzionino come previsto. 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. È necessario includere punti di vista interni che testano la piattaforma e l'infrastruttura e le valutazioni esterne che testano il sistema come un utente malintenzionato esterno.

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.

Definizioni

Strategie di progettazione chiave

Il test è una strategia non negoziabile, soprattutto per la sicurezza. Consente di individuare e risolvere in modo proattivo i problemi di sicurezza prima che possano essere sfruttati e verificare che i controlli di sicurezza implementati funzionino come previsto.

L'ambito dei test deve includere l'applicazione, l'infrastruttura e i processi automatizzati e umani.

SDL include diversi tipi di test che rilevano vulnerabilità nel codice, verificano i componenti di runtime e usano hacking etico per testare la resilienza della sicurezza del sistema. SDL è un'attività maiuscole/sinistra chiave. È consigliabile eseguire test come l'analisi statica del codice e l'analisi automatizzata dell'infrastruttura come codice (IaC) appena possibile nel processo di sviluppo.

Essere coinvolti nella pianificazione dei test. Il team del carico di lavoro potrebbe non progettare i test case. Questa attività è spesso centralizzata nell'azienda o completata da esperti di sicurezza esterni. Il team del carico di lavoro deve essere coinvolto in tale processo di progettazione per garantire l'integrazione delle garanzie di sicurezza con le funzionalità dell'applicazione.

Pensa come un utente malintenzionato. Progettare i test case presupponendo che il sistema sia stato attaccato. In questo modo, è possibile individuare le potenziali vulnerabilità e classificare in ordine di priorità i test di conseguenza.

Eseguire test in modo strutturato e con un processo ripetibile. Creare il rigore dei test intorno alla cadenza, ai tipi di test, ai fattori di guida e ai risultati previsti.

Usare lo strumento corretto per il processo. Usare gli strumenti configurati per l'uso del carico di lavoro. Se non hai uno strumento, acquista lo strumento. Non compilarlo. Gli strumenti di sicurezza sono altamente specializzati e la creazione di uno strumento personalizzato potrebbe comportare rischi. Sfruttare le competenze e gli strumenti offerti dai team centrali SecOps o da mezzi esterni se il team del carico di lavoro non ha tale esperienza.

Configurare ambienti separati. I test possono essere classificati come distruttivi o non distruttivi. I test non distruttivi non sono invasivi. Indicano che si è verificato un problema, ma non modificano la funzionalità per risolvere il problema. I test distruttivi sono invasivi e possono danneggiare la funzionalità eliminando i dati da un database.

I test negli ambienti di produzione offrono le informazioni migliori, ma causano la maggior parte delle interruzioni. Si tende a eseguire solo test non distruttivi negli ambienti di produzione. I test in ambienti non di produzione sono in genere meno problematici, ma potrebbero non rappresentare accuratamente la configurazione dell'ambiente di produzione in modi importanti per la sicurezza.

Se si esegue la distribuzione con IaC e automazione, valutare se è possibile creare un clone isolato dell'ambiente di produzione per i test. Se si dispone di un processo continuo per i test di routine, è consigliabile usare un ambiente dedicato.

Valutare sempre i risultati del test. Il test è uno sforzo sprecato se i risultati non vengono usati per classificare in ordine di priorità le azioni e apportare miglioramenti a monte. Documentare le linee guida per la sicurezza, incluse le procedure consigliate, che si scopre. Documentazione che acquisisce i risultati e i piani di correzione informa il team sui vari modi in cui gli utenti malintenzionati potrebbero tentare di violare la sicurezza. Eseguire regolari corsi di formazione sulla sicurezza per sviluppatori, amministratori e tester.

Quando si progettano i piani di test, considerare le domande seguenti:

• Con quale frequenza si prevede che il test venga eseguito e come influisce sull'ambiente?

• Quali sono i diversi tipi di test da eseguire?

Testare regolarmente il carico di lavoro

Testare regolarmente il carico di lavoro per assicurarsi che le modifiche non introducono rischi per la sicurezza e che non ci siano regressioni. Il team deve anche essere pronto per rispondere alle convalide di sicurezza dell'organizzazione che possono essere eseguite in qualsiasi momento. Sono inoltre disponibili test che è possibile eseguire in risposta a un evento imprevisto di sicurezza. Le sezioni seguenti forniscono raccomandazioni sulla frequenza dei test.

Test di routine

I test di routine vengono eseguiti a cadenza regolare, come parte delle procedure operative standard e per soddisfare i requisiti di conformità. Vari test possono essere eseguiti a cadenza diversa, ma la chiave è che vengono eseguiti periodicamente e in base a una pianificazione.

È consigliabile integrare questi test in SDLC perché forniscono una difesa approfondita in ogni fase. Diversificare il gruppo di test per verificare le garanzie di identità, archiviazione e trasmissione dei dati e canali di comunicazione. Eseguire gli stessi test in punti diversi del ciclo di vita per assicurarsi che non siano presenti regressioni. I test di routine consentono di stabilire un benchmark iniziale. Tuttavia, questo è solo un punto di partenza. Man mano che vengono rilevati nuovi problemi negli stessi punti del ciclo di vita, si aggiungono nuovi test case. I test migliorano anche con la ripetizione.

In ogni fase, questi test devono convalidare il codice aggiunto o rimosso o le impostazioni di configurazione modificate per rilevare l'impatto sulla sicurezza di tali modifiche. È consigliabile migliorare l'efficacia dei test con l'automazione, bilanciata con le verifiche peer.

Prendere in considerazione l'esecuzione di test di sicurezza come parte di una pipeline automatizzata o di un'esecuzione di test pianificata. Prima si individuano problemi di sicurezza, più facile è trovare il codice o la modifica della configurazione che li causa.

Non basarsi solo sui test automatizzati. Usare test manuali per rilevare le vulnerabilità che possono intercettare solo le competenze umane. I test manuali sono validi per i casi d'uso esplorativi e per individuare rischi sconosciuti.

Test improvvisati

I test improvvisati forniscono la convalida temporizzata delle difese di sicurezza. Gli avvisi di sicurezza che potrebbero interessare il carico di lavoro in quel momento attivano questi test. I mandati dell'organizzazione potrebbero richiedere la capacità di fermarsi ed eseguire i test per verificare l'efficacia delle strategie di difesa se l'avviso diventa 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.

Compromesso: poiché i test improvvisati sono eventi di interruzione, prevedere di riscrivere le attività, che potrebbero ritardare altri lavori pianificati.

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à. È necessario valutare questi rischi in relazione ai vantaggi.

Test degli eventi imprevisti di sicurezza

Esistono test che rilevano la causa di un evento imprevisto di sicurezza all'origine. Questi gap di sicurezza devono essere risolti per assicurarsi che l'evento imprevisto non venga ripetuto.

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.

Usare un'ampia gamma di test

I test possono essere classificati in base alla tecnologia e testando le metodologie. Combinare tali categorie e approcci all'interno di tali categorie per ottenere una copertura completa.

Aggiungendo più test e tipi di test, è possibile scoprire:

• Lacune nei controlli di sicurezza o nei controlli di compensazione.

• Configurazioni errate.

• Lacune nei metodi di osservabilità e rilevamento.

Un buon esercizio di modellazione delle minacce può puntare alle aree chiave per garantire 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.

La maggior parte dei test descritti in queste sezioni può essere eseguita come test di routine. Tuttavia, la ripetibilità può comportare costi in alcuni casi e causare interruzioni. Considerare attentamente questi compromessi.

Test che convalidano lo stack di tecnologie

Ecco alcuni esempi di tipi di test e delle relative aree di interesse. Questo elenco non è esaustivo. Testare l'intero stack, incluso lo stack di applicazioni, il front-end, il back-end, le API, i database e tutte le integrazioni esterne.

• Sicurezza dei dati: testare l'efficacia della crittografia dei dati e dei controlli di accesso per garantire che i dati siano protetti correttamente da accessi non autorizzati e manomissioni.

• Rete e connettività: testare i firewall per assicurarsi che consentano solo il traffico previsto, consentito e sicuro per il carico di lavoro.

• Applicazione: testare il codice sorgente tramite tecniche di test di sicurezza delle applicazioni (AST) per assicurarsi di seguire procedure di codifica sicure e rilevare errori di runtime come problemi di danneggiamento della memoria e privilegi. Per informazioni dettagliate, vedere questi collegamenti alla community.

• Identità: valutare se le assegnazioni di ruolo e i controlli condizionali funzionano come previsto.

Metodologia di test

Esistono molte prospettive sulle metodologie di test. È consigliabile testare che consentano la ricerca delle minacce simulando attacchi reali. Possono identificare potenziali attori di 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. Potrebbero verificarsi problemi di continuità aziendale se i test distruttivi eliminano o danneggiano i dati. Vi sono anche rischi associati all'esposizione delle informazioni; assicurarsi di 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 in scatola nera e casella 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 white-box possono essere costosi in termini di tempo impiegato per comprendere il sistema. In alcuni casi, il test white-box richiede l'acquisto di 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 degli investimenti nel 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 attori malintenzionati hanno come ambito 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 regole di impegno 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, esistono due team:

• La squadra rossa è l'avversario che 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 implementate per proteggere le risorse del carico di lavoro.

Se vengono eseguiti come test di routine, 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 è la Microsoft Defender per Office 365 Formazione con simulazione degli attacchi.

Per altre informazioni, vedere Informazioni dettagliate e report per Formazione con 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, con 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 possono essere automatizzati 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 engagement per assicurarsi 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 ingaggio per i 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.

Lo standard PTES (Penetration Testing Execution Standard) fornisce linee guida sugli scenari comuni e sulle attività necessarie per stabilire una baseline.

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 relativo alla sicurezza

Fare riferimento al set completo di raccomandazioni.