Come procede il red team durante una verifica?
Supponiamo di dover testare un’app. In una prima fase ci consultiamo con le specialiste e gli specialisti che si occupano di progettarla, gestirla o svilupparla e fissiamo gli obiettivi dei test. Uno di questi obiettivi può essere manipolare una transazione finanziaria in un ambiente di test oppure accedere a informazioni tramite un’interfaccia all’interno dell’app. In seguito definiamo l’approccio che intendiamo seguire, scegliendo tra black box, gray box o white box. Nell’approccio black box, per i test abbiamo accesso all’applicazione senza ulteriori informazioni sulla sua struttura interna. Nell’approccio gray box, molto più diffuso, ci viene offerto qualche aiuto in più, ad es. la possibilità di lavorare con una versione dell’app in cui sono state disattivate determinate misure di sicurezza. In questo abbiamo un vantaggio rispetto a potenziali malintenzionati, che in genere dispongono di più tempo di noi, e possiamo sfruttare il prezioso periodo di test per effettuare verifiche anziché per raggirare le misure di sicurezza. Infine, nell’approccio white box ci si spinge oltre e viene divulgato il codice sorgente per permettere a chi svolge i test di eludere con maggiore facilità le misure di sicurezza. In seguito configuriamo i test e diamo il via alle verifiche. Verifichiamo, ad esempio, che non ci siamo errori di natura logica o divergenze dagli standard nell’autenticazione, nella procedura di login o nel ripristino della password, oppure monitoriamo il comportamento dell’app quando le vengono sottoposte informazioni per cui in origine non era stata progettata. Se, per esempio, un pagamento da un cliente A a un cliente B prevede che in background si svolgano più di dieci fasi, verifichiamo cosa succede se l’ordine o il contenuto di quest’ultime viene modificato. Una volta che abbiamo verificato un numero sufficiente di elementi, traiamo le conclusioni e le documentiamo. Se necessario, prendiamo poi misure per eliminare le falle di sicurezza individuate.