Raccomandazioni per i test di sicurezza
Si applica a questa raccomandazione dell'elenco di controllo per la sicurezza di Azure Well-Architected Framework:
| SE:11 | Stabilire un regime di test completo che combina gli approcci per prevenire i problemi di sicurezza, convalidare le implementazioni di prevenzione delle minacce e testare i meccanismi di rilevamento delle minacce. |
|---|
Test rigorosi è 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 consigli 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
| Termine | Definizione |
|---|---|
| Test di sicurezza delle applicazioni (AST) | Tecnica sdl (Security Development Lifecycle) di Microsoft che usa metodologie di test white box e black box per verificare la presenza di vulnerabilità di sicurezza nel codice. |
| Test in scatola nera | Metodologia di test che convalida il comportamento dell'applicazione visibile esternamente senza conoscere gli elementi interni del sistema. |
| Squadra blu | Una squadra che si difende contro gli attacchi della squadra rossa in un esercizio di guerra. |
| Test di penetrazione | Metodologia di test che usa tecniche di hacking etico per convalidare le difese di sicurezza di un sistema. |
| Squadra rossa | Una squadra che svolge il ruolo di un avversario e tenta di hackerare il sistema in un esercizio di gioco di guerra. |
| Security Development Lifecycle (SDL) | Un set di procedure fornite da Microsoft che supporta i requisiti di sicurezza e conformità. |
| Ciclo di vita dello sviluppo software (SDLC) | Un processo sistematico e multistage per lo sviluppo di sistemi software. |
| Test casella bianca | Metodologia di test in cui la struttura del codice è nota al professionista. |
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 di verificare che i controlli di sicurezza implementati funzionino come progettato.
L'ambito dei test deve includere l'applicazione, l'infrastruttura e i processi automatizzati e umani.
Nota
Questa guida distingue tra test e risposta agli eventi imprevisti. Anche se il test è un meccanismo di rilevamento che risolve idealmente i problemi prima della produzione, non deve essere confuso con la correzione o l'indagine eseguita come parte della risposta agli eventi imprevisti. L'aspetto del ripristino dagli eventi imprevisti di sicurezza è descritto in Raccomandazioni sulla risposta agli eventi imprevisti.
SDL include diversi tipi di test che rilevano le vulnerabilità nel codice, verificano i componenti di runtime e usano l'hacking etico per testare la resilienza della sicurezza del sistema. SDL è un'attività di spostamento a sinistra fondamentale. È consigliabile eseguire test come l'analisi statica del codice e l'analisi automatizzata dell'infrastruttura come codice (IaC) il prima possibile nel processo di sviluppo.
Essere coinvolti nella pianificazione dei test. Il team del carico di lavoro potrebbe non progettare i test case. Tale attività è spesso centralizzata nell'azienda o completata da esperti di sicurezza esterni. Il team del carico di lavoro deve essere coinvolto nel processo di progettazione per garantire che le garanzie di sicurezza si integrano 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 appropriato 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 usando IaC e l'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. I test sono 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 sulla sicurezza, incluse le procedure consigliate, rilevate. La 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 una formazione regolare 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?
Con quale frequenza si prevede che i test vengano eseguiti?
Testare regolarmente il carico di lavoro per assicurarsi che le modifiche non introducono rischi per la sicurezza e che non vi siano regressioni. Il team deve anche essere pronto per rispondere alle convalide di sicurezza dell'organizzazione che potrebbero 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à. È possibile eseguire vari test a cadenza diverse, ma la chiave è che vengono condotti periodicamente e in base a una pianificazione.
È consigliabile integrare questi test in SDLC perché forniscono una difesa approfondita in ogni fase. Diversificazione del 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. Quando si individuano 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 di individuare i problemi di sicurezza, è più semplice trovare il codice o la modifica della configurazione che li causa.
Non fare affidamento solo su 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 temporizzato delle difese di sicurezza. Avvisi di sicurezza che potrebbero influire sul carico di lavoro in quel momento attivano questi test. I mandati dell'organizzazione potrebbero richiedere una mentalità di sospensione e test per verificare l'efficacia delle strategie di difesa se l'avviso si estende a un'emergenza.
Il vantaggio dei test improvvisati è la preparazione per un evento imprevisto reale. 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. Come 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 poter 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 dirompenti, aspettarsi di riscrivere le attività, che potrebbero ritardare altri lavori pianificati.
Rischio: c'è rischio dell'sconosciuto. I test improvvisati possono essere sforzi unisto senza processi o strumenti stabiliti. Ma il rischio principale è l'interruzione potenziale del ritmo aziendale. È necessario valutare tali rischi relativi ai vantaggi.
Test degli eventi imprevisti di sicurezza
Esistono test che rilevano la causa di un evento imprevisto di sicurezza all'origine. Queste lacune di sicurezza devono essere risolte per assicurarsi che l'evento imprevisto non sia 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.
Quali sono i diversi tipi 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 individuare:
Lacune nei controlli di sicurezza o nei controlli di compensazione.
Configurazioni non configurate.
Lacune nei metodi di osservazione e rilevamento.
Un buon esercizio di modellazione delle minacce può puntare alle aree chiave per garantire copertura e frequenza di test. Per raccomandazioni sulla modellazione delle minacce, vedere Raccomandazioni per la protezione di un ciclo di vita dello 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. Prendere in considerazione questi compromessi con attenzione.
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 dei controlli di crittografia dei dati e di accesso per garantire che i dati siano protetti correttamente dall'accesso non autorizzato e dalla manomissione.
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 le tecniche di test di sicurezza dell'applicazione (AST) per assicurarsi di seguire le procedure di codifica sicure e di rilevare errori di runtime come il danneggiamento della memoria e i problemi relativi ai 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 la ricerca delle minacce simulando attacchi reali. Possono identificare potenziali attori delle minacce, le loro tecniche e i loro exploit che rappresentano una minaccia per il carico di lavoro. Rendere gli attacchi il più realistici possibile. Usare tutti i potenziali vettori di minaccia identificati durante la modellazione delle minacce.
Ecco alcuni vantaggi dei test tramite attacchi reali:
Quando si apportano questi attacchi una 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ò valutare autonomamente la loro idoneità a rispondere agli eventi imprevisti.
Alcuni esempi di test simulati includono test black-box e white-box, test di penetrazione e esercizi di gioco di guerra.
Test black-box e white-box
Questi tipi di test offrono due prospettive diverse. Nei test black-box i interni del sistema non sono visibili. Nei test in white box, il tester ha una buona conoscenza dell'applicazione e ha anche accesso al codice, ai log, alla topologia delle risorse e alle configurazioni per l'esecuzione dell'esperimento.
Test che simulano attacchi tramite test di penetrazione
Gli esperti di sicurezza che non fanno parte dei team IT o dell'applicazione dell'organizzazione eseguono test di penetrazione o pentesting. Esaminano il sistema nel modo in cui gli attori malintenzionati mettono in ambito una superficie di attacco. L'obiettivo è trovare lacune nella sicurezza raccogliendo informazioni, analizzando le vulnerabilità e segnalando i risultati.
I professionisti potrebbero dover accedere ai dati sensibili nell'intera organizzazione. Seguire le regole di coinvolgimento per assicurarsi che l'accesso non venga usato in modo improprio. Vedere le risorse elencate nei collegamenti correlati.
Test che simulano attacchi tramite esercizi di gioco di guerra
In questa metodologia di attacchi simulati sono presenti due team:
Il team rosso è l'avversario che tenta di modellare attacchi reali al mondo. Se hanno esito positivo, si trovano lacune nella progettazione della sicurezza e valutano 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 condotti come test di routine, gli esercizi di gioco di guerra possono fornire visibilità continua e garantire 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 popolare 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 del team rosso e del team blu, vedere Microsoft Cloud Red Teaming.
Facilitazione di Azure
Microsoft Sentinel è un controllo nativo che combina funzionalità di gestione degli eventi di sicurezza (SIEM) e di orchestrazione automatica della sicurezza . 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 analisi intelligenti e query, è possibile cercare in modo proattivo 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 for Cloud offre l'analisi delle vulnerabilità per varie aree tecnologiche. Per informazioni dettagliate, vedere Abilitare l'analisi della vulnerabilità con Gestione delle vulnerabilità di Microsoft Defender - Microsoft Defender for Cloud.
La pratica di DevSecOps integra i test di sicurezza come parte di una mentalità continua e di miglioramento continuo. Gli esercizi di gioco di guerra sono una pratica comune integrata nel ritmo di business in Microsoft. Per altre informazioni, vedere Sicurezza in DevOps (DevSecOps).
Azure DevOps supporta strumenti di terze parti che possono essere automatizzati come parte delle pipeline di distribuzione continua/integrazione continua. Per informazioni dettagliate, vedere Abilitare DevSecOps con Azure e GitHub - Azure DevOps.
Collegamenti correlati
Seguire le regole di impegno 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:
È 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 - Risorse GitHub 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.
Commenti e suggerimenti
Presto disponibile: Nel corso del 2024 verranno gradualmente disattivati i problemi di GitHub come meccanismo di feedback per il contenuto e ciò verrà sostituito con un nuovo sistema di feedback. Per altre informazioni, vedere https://aka.ms/ContentUserFeedback.
Invia e visualizza il feedback per