Raccomandazioni per i test di sicurezza
Si applica a questa raccomandazione della checklist di sicurezza ben progettata: Power Platform
| SE:09 | Stabilire un regime di test completo che combini approcci per prevenire problemi di sicurezza, convalidare implementazioni di prevenzione delle minacce e testare meccanismi di rilevamento delle minacce. |
|---|
Test rigorosi sono il fondamento di una buona progettazione della sicurezza. Il test è una forma tattica di convalida per garantire che i controlli funzionino come previsto. Il test è anche un modo proattivo per rilevare vulnerabilità nel sistema.
Stabilisci il rigore dei test tramite cadenza e verifica da più prospettive. Devi includere punti di vista interni che testano la piattaforma e l'infrastruttura e valutazioni esterne che testano il sistema come un utente malintenzionato esterno.
Questa guida fornisce raccomandazioni per testare il livello di sicurezza del carico di lavoro. Implementa questi metodi di test per migliorare la resistenza del carico di lavoro agli attacchi e mantenere riservatezza, integrità e disponibilità delle risorse.
Definizioni
| Termine | Definizione |
|---|---|
| Test di sicurezza dell'applicazione | Una tecnica del ciclo di vita dello sviluppo della sicurezza (SDL) che utilizza metodologie di test white-box e black-box per verificare le vulnerabilità di sicurezza nel codice. Microsoft |
| Test black-box | Una metodologia di test che convalida il comportamento dell'applicazione visibile esternamente senza conoscere le parti interne del sistema. |
| Team blu | Un team che si difende dagli attacchi del team rosso in un esercizio di gioco di guerra. |
| Test di penetrazione | Una metodologia di test che utilizza tecniche di hacking etico per convalidare le difese di sicurezza di un sistema. |
| Team rosso | Un team che interpreta il ruolo di un avversario e tenta di hackerare il sistema in un esercizio di gioco di guerra. |
| Ciclo di vita dello sviluppo della sicurezza (SDL) | Un insieme di pratiche fornite da Microsoft che supportano i requisiti di conformità e garanzia della sicurezza. |
| Ciclo di vita dello sviluppo della sicurezza (SDLC) | Un processo sistematico a più fasi per lo sviluppo di sistemi software. |
| Test white-box | Una metodologia di test in cui la struttura del codice è nota all'operatore. |
Strategie di progettazione chiave
Il test è una strategia non negoziabile, soprattutto per la sicurezza. Ti consente di scoprire e affrontare in modo proattivo i problemi di sicurezza prima che possano essere sfruttati e di verificare che i controlli di sicurezza implementati funzionino come previsto.
L'ambito del test deve includere l'applicazione, l'infrastruttura e i processi automatizzati e umani.
Nota
Questa guida fa una distinzione tra test e risposta agli incidenti. Sebbene il test sia un meccanismo di rilevamento che idealmente risolve i problemi prima della produzione, non deve essere confuso con la riparazione o l'indagine eseguita come parte della risposta all'incidente. L'aspetto del ripristino dagli incidenti di sicurezza è descritto in Raccomandazioni per la risposta agli incidenti di sicurezza.
Partecipa alla pianificazione dei test. Il team del carico di lavoro potrebbe non progettare i casi di test. Questa attività è spesso centralizzata all'interno dell'azienda o completato da esperti di sicurezza esterni. Il team del carico di lavoro deve essere coinvolto in quel processo di progettazione per garantire che le garanzie di sicurezza si integrino con le funzionalità dell'applicazione.
Pensa come un utente malintenzionato. Progetta i tuoi casi di test partendo dal presupposto che il sistema è stato attaccato. In tal modo, puoi scoprire le potenziali vulnerabilità e dare la priorità ai test di conseguenza.
Esegui i test in modo strutturato e con un processo ripetibile. Sviluppa il rigore dei test in base a cadenza, tipi di test, fattori trainanti e risultati attesi.
Utilizza lo strumento appropriato per il lavoro. Utilizza strumenti configurati per funzionare con il carico di lavoro. Se non hai uno strumento, acquistalo. Non crearlo. Gli strumenti di sicurezza sono altamente specializzati e la creazione di uno strumento personalizzato potrebbe introdurre rischi. Sfrutta le competenze e gli strumenti offerti dai team SecOps centrali o con mezzi esterni se il team del carico di lavoro non dispone di tali competenze.
Configura ambienti separati. I test possono essere classificati come distruttivi o non distruttivi. I test non distruttivi non sono invasivi. Indicano la presenza di un problema, ma non alterano la funzionalità per risolvere il problema. I test distruttivi sono invasivi e potrebbero danneggiare le funzionalità eliminando dati da un database.
I test negli ambienti di produzione ti forniscono le informazioni migliori ma provocano maggiori interruzioni. Negli ambienti di produzione tendi a eseguire solo test non distruttivi. 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.
Puoi creare un clone isolato del tuo ambiente di produzione utilizzando la funzionalità di copia dell'ambiente. Se hai configurato pipeline di distribuzione, puoi anche distribuire le tue soluzioni in un ambiente di test dedicato.
Valuta sempre i risultati del test. I test sono uno sforzo inutile se i risultati non vengono utilizzati per dare priorità alle azioni e apportare miglioramenti a monte. Documenta le linee guida sulla sicurezza, comprese le procedure consigliate, che scopri. La documentazione con i risultati e i piani di correzione istruisce il team sui vari modi in cui gli utenti malintenzionati potrebbero tentare di violare la sicurezza. Conduci regolarmente corsi di formazione sulla sicurezza per sviluppatori, amministratori e tester.
Quando progetti i tuoi piani di test, prendi in considerazione le domande seguenti:
- Con quale frequenza prevedi che venga eseguito il test e in che modo influisce sul tuo ambiente?
- Quali sono i diversi tipi di test che devi eseguire?
Con quale frequenza prevedi che vengano eseguiti i test?
Testa regolarmente il carico di lavoro per assicurarti che le modifiche non introducano rischi per la sicurezza e che non vi siano regressioni. Il team deve inoltre essere pronto a rispondere alle convalide della sicurezza organizzativa che potrebbero essere condotte in qualsiasi momento. Esistono anche test che puoi eseguire in risposta a un incidente di sicurezza. Le sezioni seguenti forniscono raccomandazioni sulla frequenza dei test.
Test di routine
I test di routine vengono condotti a cadenza regolare, come parte delle procedure operative standard e per soddisfare i requisiti di conformità. Si potrebbero eseguire vari test con cadenze diverse, ma la chiave è che vengano condotti periodicamente e secondo una pianificazione.
Devi integrare questi test nel tuo SDLC perché forniscono una difesa approfondita in ogni fase. Diversifica la suite di test per verificare le garanzie di identità, archiviazione e trasmissione dei dati e canali di comunicazione. Conduci gli stessi test in diversi punti del ciclo di vita per garantire che non vi siano regressioni. I test di routine aiutano a stabilire un benchmark iniziale. Tuttavia quello è solo un punto di partenza. Man mano che scopri nuovi problemi negli stessi punti del ciclo di vita, aggiungi nuovi casi di test. I test migliorano anche con la ripetizione.
In ogni fase, questi test devono convalidare il codice aggiunto o rimosso o le impostazioni di configurazione che sono state modificate per rilevare l'impatto di tali modifiche sulla sicurezza. Devi migliorare l'efficacia dei test con l'automazione, bilanciata con le revisioni paritarie.
Prendi in considerazione l'esecuzione di test di sicurezza come parte di una pipeline automatizzata o di un'esecuzione di test pianificata. Prima scopri i problemi di sicurezza, più facile sarà trovare il codice o la modifica alla configurazione che li causa.
Non fare affidamento solo sui test automatizzati. Utilizza i test manuali per rilevare le vulnerabilità che solo la competenza umana può individuare. I test manuali sono utili per casi d'uso esplorativi e per individuare rischi sconosciuti.
Test improvvisati
I test improvvisati forniscono una convalida puntuale delle difese di sicurezza. Gli avvisi di sicurezza che potrebbero influire sul carico di lavoro in quel momento attivano quei test. I mandati organizzativi potrebbero richiedere un approccio di pausa e test per verificare l’efficacia delle strategie di difesa se l’avviso si trasforma in un’emergenza.
Il vantaggio dei test improvvisati è la preparazione per un incidente reale. Questi test possono essere una funzione coercitiva per eseguire test di accettazione dell'utente (UAT).
Il team di sicurezza potrebbe controllare tutti i carichi di lavoro ed eseguire questi test secondo necessità. In qualità di proprietario del carico di lavoro, devi facilitare il lavoro dei team di sicurezza e collaborare con loro. Negozia un tempo di consegna sufficiente con i team di sicurezza in modo da poterti preparare. Riconosci e comunica al tuo team e agli stakeholder che queste interruzioni sono necessarie.
In altri casi, potrebbe essere richiesto di eseguire test e generare report sullo stato di sicurezza del sistema rispetto alla potenziale minaccia.
Compromesso: poiché i test improvvisati sono eventi dirompenti, aspettatevi di dover ridefinire le priorità delle attività, il che potrebbe ritardare altri lavori pianificati.
Rischio: C'è il rischio dell'ignoto. I test improvvisati potrebbero essere sforzi una tantum senza processi o strumenti consolidati. Tuttavia, il rischio predominante è la potenziale interruzione del ritmo dell'attività. Devi valutare tali rischi rispetto ai benefici.
Test per incidenti di sicurezza
Esistono test che rilevano la causa di un incidente di sicurezza alla fonte. Queste lacune di sicurezza devono essere risolte per garantire che l’incidente non si ripeta.
Gli incidenti migliorano anche i casi di test nel tempo rivelando le lacune esistenti. Il team deve applicare le lezioni apprese in seguito all'incidente e incorporare regolarmente miglioramenti.
Quali sono i diversi tipi di test?
I test possono essere classificati in base a tecnologia e a metodologie di test. Combina tali categorie e approcci in tali categorie per ottenere una copertura completa.
Aggiungendo più test e tipi di test, puoi individuare:
- Lacune nei controlli di sicurezza o nei controlli compensativi.
- Configurazioni errate.
- Lacune nell'osservabilità e nei metodi di rilevamento.
Un buon esercizio di modellazione delle minacce può indicare le aree chiave per garantire la copertura e la frequenza dei test. Per raccomandazioni sulla modellazione delle minacce, vedi Raccomandazioni per proteggere un ciclo di vita di sviluppo.
La maggior parte dei test descritti in queste sezioni può essere eseguita come test di routine. Tuttavia, in alcuni casi, la ripetibilità può comportare costi e causare interruzioni. Considera attentamente questi compromessi.
Test che convalidano lo stack tecnologico
Ecco alcuni esempi di tipologie di test e le relative aree di interesse. Questo elenco non è esaustivo. Testa l'intero stack, incluso lo stack dell'applicazione, il front-end, il back-end, le API, i database ed eventuali integrazioni esterne.
- Sicurezza dei dati: testare l'efficacia della crittografia dei dati e dei controlli di accesso per garantire che i dati siano adeguatamente protetti da accessi non autorizzati e manomissioni.
- Rete e connettività: testa i tuoi firewall per assicurarti che consentano solo il traffico previsto, consentito e sicuro al carico di lavoro.
- Applicazione: testare il codice sorgente tramite tecniche di test di sicurezza delle applicazioni (AST) per assicurarsi di adottare pratiche di codifica sicure e di rilevare errori di runtime come danneggiamento della memoria e problemi di privilegi.
- Identità: valutare se le assegnazioni dei ruoli e i controlli condizionali funzionano come previsto.
Metodologia di test
Le metodologie di test comportano molte prospettive. Consigliamo test che consentano la ricerca di minacce simulando attacchi nel mondo reale. Questi possono identificare potenziali autori di minacce, le loro tecniche e i loro exploit che rappresentano una minaccia per il carico di lavoro. Rendi gli attacchi il più realistici possibile. Utilizza tutti i potenziali vettori di minaccia identificati durante la modellazione delle minacce.
Ecco alcuni vantaggi del test tramite attacchi nel mondo reale:
- Quando inserisci questi attacchi nei test di routine, utilizzi una prospettiva esterna per controllare il carico di lavoro e assicurarti che la difesa possa resistere a un attacco.
- Sulla base delle lezioni apprese, il team migliora le proprie conoscenze e il proprio livello di competenza. Il team migliora la consapevolezza della situazione e può autovalutare la propria preparazione a rispondere agli incidenti.
Alcuni esempi di test simulati includono test black-box e white-box, test di penetrazione ed esercizi di giochi di guerra.
Test black-box e white-box
Questi tipi di test offrono due diverse prospettive. Nei test black-box, le parti interne 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 condurre l'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 conducono test di penetrazione o pentesting. Esaminano il sistema nello stesso modo in cui gli utenti malintenzionati individuano una superficie di attacco. Il loro obiettivo è trovare lacune nella sicurezza raccogliendo informazioni, analizzando le vulnerabilità e generando report sui risultati.
Gli operatori potrebbero aver bisogno di accedere a dati sensibili nell'intera organizzazione. Segui le regole di engagement per garantire che l'accesso non venga utilizzato in modo improprio. Consultare le risorse elencate in Informazioni correlate.
Test che simulano attacchi tramite esercizi di giochi di guerra
In questa metodologia di attacchi simulati, ci sono due team:
- Il team rosso è l'avversario che tenta di modellare attacchi del mondo reale. Se tali attacchi hanno successo, trovi le lacune nella progettazione della sicurezza e valuti il controllo del raggio di azione delle loro violazioni.
- Il team blu è il team del carico di lavoro che lo difende dagli attacchi. Testa la sua capacità di rilevare, rispondere e rimediare agli attacchi. Convalida le difese implementate per proteggere le risorse del carico di lavoro.
Se condotti come test di routine, gli esercizi di giochi di guerra possono fornire visibilità continua e la certezza che le tue difese funzionano come previsto. Gli esercizi di giochi di guerra possono potenzialmente testare livelli diversi nei tuoi carichi di lavoro.
Una scelta popolare per simulare scenari di attacco realistici è il Microsoft Defender for Office 365 Attack simulation training.
Per ulteriori informazioni, vedi Informazioni dettagliate e report per Formazioni alla simulazione di attacchi.
Per informazioni sulla configurazione del team rosso e del team blu, vedere Microsoft Cloud Red Teaming.
Facilitazione di Power Platform
Microsoft La soluzione Sentinel per Microsoft Power Platform consente ai clienti di rilevare varie attività sospette, come:
- Esecuzione Power Apps da aree geografiche non autorizzate
- Distruzione di dati sospetti da parte di Power Apps
- Eliminazione di massa di Power Apps
- Attacchi di phishing tramite Power Apps
- Attività dei flussi Power Automate da parte dei dipendenti in partenza
- Connettori Microsoft Power Platform aggiunti a un ambiente
- Aggiornamento o rimozione dei criteri di prevenzione della perdita dei dati di Microsoft Power Platform
Per ulteriori informazioni, vedere Microsoft Soluzione Sentinel per Microsoft Power Platform panoramica.
Per la documentazione del prodotto, vedere Funzionalità di caccia in Microsoft Sentinel.
Microsoft Defender for Cloud offre la scansione delle vulnerabilità per vari ambiti tecnologici. Per ulteriori informazioni, vedere Abilitare la scansione delle vulnerabilità con Microsoft Defender Vulnerability Management.
La pratica di DevSecOps integra i test di sicurezza come parte di un approccio di miglioramento costante e continuo. Le esercitazioni di war game sono una pratica comune, integrata nel ritmo aziendale presso Microsoft. Per ulteriori informazioni, vedi Sicurezza in DevOps (DevSecOps).
Azure DevOps supporta strumenti di terze parti che possono essere automatizzati come parte delle pipeline di integrazione continua/distribuzione continua (CI/CD). Per ulteriori informazioni, vedi Abilitare DevSecOps con Azure e GitHub.
Informazioni correlate
I test di penetrazione e le valutazioni di sicurezza più recenti sono disponibili sul Service Trust Portal Microsoft .
Microsoft esegue test approfonditi dei servizi Cloud. Microsoft Questi test includono test di penetrazione, con risultati pubblicati nel Service Trust Portal per la tua organizzazione. La tua organizzazione potrebbe eseguire il proprio test di penetrazione sui servizi di Microsoft Power Platform e Microsoft Dynamics 365. Tutti i test di penetrazione devono rispettare le Microsoft regole di ingaggio per i test di penetrazione nel cloud. È importante ricordare che in molti casi il Cloud utilizza un'infrastruttura condivisa per ospitare i tuoi asset e quelli di altri clienti. Microsoft Devi limitare tutti i test di penetrazione alle tue risorse ed evitare conseguenze indesiderate per gli altri clienti intorno a te.
Segui le regole di engagement per assicurarti che l'accesso non venga utilizzato in modo improprio. Per indicazioni sulla pianificazione e sull'esecuzione di attacchi simulati, vedi:
Puoi simulare attacchi Denial of Service (DoS) in Azure. Assicurati di seguire i criteri definiti in Test di simulazione della protezione DDoS di Azure.
Elenco di controllo della sicurezza
Fai riferimento alla serie completa di elementi consigliati.