Red Team e Penetration Test: differenze e obiettivi
Una buona definizione del termine Red Team ci è fornita da Joe Vest e James Tubberville nel loro libro Red Team Development and Operations:
“Red Teaming is the process of using tactics, techniques and procedures (TTPs) to emulate a real-world threat, with the goal of measuring the effectiveness of the people, processes and technologies used to defend an environment.”
Nonostante questa definizione possa rimandare all’idea di Penetration Test, ci sono diversi punti chiave che tracciano una netta linea di demarcazione fra i due approcci, benché entrambi mantengano diversi punti in comune, come gli attori coinvolti nel processo e alcune fra le tecniche utilizzate. Purtroppo, sulla rete, la distinzione fra i due metodi non è sempre chiara e spesso si viene a creare una certa confusione che porta ad usare impropriamente questi termini.
Red Team: processo e metodologia
Per comprendere cosa sia un Red Team è quindi necessario specificare prima cosa sia un Penetration Test: un Penetration Test si compone di una serie di metodologie e tecniche informatiche atte ad individuare il maggior numero possibile di vulnerabilità in una rete, dimostrare come esse possano essere sfruttate ed i rischi che corre un’organizzazione a non applicare un adeguato piano di Vulnerability Patching and Management. Un Penetration Test potrebbe anche essere la diretta conseguenza di un Vulnerability Assessment, o potrebbe essere necessario per supportare un Audit. Infine, un report derivato da un’attività di Penetration Testing, generalmente, si compone di una serie di vulnerabilità, misconfiguration ed un relativo Remediation Plan. Tuttavia, è completamente assente un elemento fondamentale che al giorno d’oggi, a nostro avviso, è diventato cruciale: la capacità dell’organizzazione nell’individuare e reagire tempestivamente ad un attacco mirato.
Gli attori della simulazione: Red Team, Blue Team e Purple Team
È proprio a questo punto che entra in gioco il Red Team, il cui scopo non è più quello di individuare il maggior numero di vulnerabilità, ma di compromettere e/o accedere ad una particolare risorsa aziendale concordata precedentemente con l’organizzazione che sta richiedendo l’attività. La risorsa oggetto della simulazione potrebbe essere un server, una casella e-mail, un database o addirittura un singolo file, ed è molto importante che il contenuto in essa sia considerato critico.
Un Red Team, il cui obiettivo sarà proprio questa risorsa, emulerà uno scenario d’attacco reale, avanzato da attori altamente qualificati e per un periodo di tempo maggiore rispetto ad un tipico Penetration Test. Un’altra differenza chiave sono le metodologie con cui viene condotta l’intera simulazione, che si focalizzeranno sul creare un attacco il più trasparente possibile, senza generare rumore o indicatori di un Data Breach in corso. Queste caratteristiche sono realizzabili grazie a strumenti e tecniche altamente avanzate e professionali, le quali richiedono un livello di impegno e studio che esulano dallo skillset di un normale Penetration-Tester.
Per simulare correttamente tutte queste operazioni, e valutare quindi le capacità di risposta dell’organizzazione, un Red Team dovrà completare il proprio obiettivo senza essere individuato dal Blue Team “avversario”, ovvero da coloro il cui compito è quello di difendere l’organizzazione dagli attacchi informatici.
Ancora una volta, una buona definizione di questo processo ci viene fornita da Red Team Development and Operations di Joe Vest e James Tubberville:
“Red Teams are used to measure the effectiveness of the people, processes, and technology used to defend a network, train or measure a Blue Team (defensive security operations), and test and understand specific threats or threat scenarios.”
Negli ultimi anni si è delineata inoltre un’ulteriore figura, denominata Purple Team. Il ruolo principale di questa “squadra” è quello di supervisionare l’operato dei due Team, al fine di ottimizzarne i risultati. Questo non implica solo un ruolo di mediatore fra la “squadra rossa” e la “squadra blu”, ma garantisce una visione d’insieme da un punto di vista diverso sia da quello dell’attaccante che da quello del difensore. Grazie a questa metodologia meno conosciuta, ma non per questo meno importante, l’organizzazione è in grado di avere una prospettiva molto più chiara della sua esposizione ad un eventuale attacco mirato e di come reagire nei suoi confronti.
Infine, il seguente diagramma mostra la copertura IPDRR (Identify, Protect, Detect, Respond, Recover) a seconda della tipologia di engagement che l’organizzazione ha scelto di mettere in atto.
(Red Team Development and Operations di Joe Vest e James Tubberville)
È importante specificare che nessuna di queste tre metodologie è migliore o superiore alle altre. Infatti, è necessario valutare, di caso in caso, l’approccio ottimale da seguire a seconda delle esigenze e delle disponibilità del cliente.
Una nuova evoluzione: il software penetration test
Pikered, grazie alla soluzione software ZAIUX® Evo, ha deciso di rendere disponibile uno strumento guidato dall’intelligenza artificiale in grado di effettuare Internal Penetration Test automatizzati, consentendo di validare tramite un approccio continuativo le vulnerabilità nelle infrastrutture IT. Le modalità di esecuzione di ZAIUX® Evo sono comparabili a quelle di un Penetration Test manuale, rendendo quindi superflua la parte di verifica manuale delle vulnerabilità necessaria dopo un Vulnerability Assessment. Le tecniche messe in atto da ZAIUX® Evo tendono ad emulare quanto più possibile uno scenario reale, il tutto guidato e pianificato da un motore intelligente in grado di ottimizzare tempistiche e risorse. ZAIUX® Evo si pone l’obiettivo di affiancare i Penetration Tester e gli amministratori di sistema nell’individuare quelle vulnerabilità che spesso passano inosservate sia agli occhi di un Vulnerability Assessment che di un Penetration Tester umano. Oltre a questo, la soluzione è stata ideata per essere un follow-up ad attività manuali, siano esse Penetration Test o Red-Team, per una continua validazione della resilienza interna di un’infrastruttura informatica.