Red Team Regeneration

Massimiliano Brolli : 11 Giugno 2020 08:00

Articolo di: Massimiliano Brolli
Data pubblicazione: 11/06/2020

Nel 2019 è stato pubblicato il rapporto annuale “Cost of data breach” sviluppato da Ponemon Istituite in collaborazione con IBM Security, che riporta il costo medio che le aziende sostengono per singolo data-breach.

Ad oggi un data-breach si attesta a 3.9 milioni di dollari dove nel campione italiano analizzato di 11 aziende, la media si aggira a circa 3,1 milioni di euro.

Nel report viene inoltre riportato che il costo non risulta distribuito nel periodo “strettamente successivo” all’incidente di sicurezza, ma viene distribuito anche nei due anni successivi.

Quanto riportato da IBM Security fa comprendere, come il fenomeno data-breach, possa influenzare in modo sensibile il cammino di ogni azienda, oltre a portare perdite ingenti (dirette e indirette) trainate anche da quello che potrebbe essere il “miglioramento delle politiche di sicurezza” e del “sistema controllo interno” a valle dell’incidente informatico.

La visione del NIST sui Security Assessment

Prima di addentrarci a quali potrebbero essere i potenziali miglioramenti, citerei quello che dice il NIST (National Institute of Standards and Technology) ovvero l’ente “supremo” che tutti noi riteniamo punto di “ispirazione” e “autorevolezza” in termini di tecnologia, standard e metodologia.

Nella Special Publication 800-115 denominata, “Technical Guide to Information Security Testing and Assessment” nel capitolo 2.3 riporta:

I Test di sicurezza non forniscono una valutazione completa della sicurezza di un sistema, spesso hanno un ambito ristretto a causa delle risorse e delle limitazioni di tempo. I pirati informatici, d’altra parte, possono prendere tutto il tempo di cui hanno bisogno per sfruttare e penetrare un sistema.

Inoltre, sempre il NIST riporta che i “Security Assessment, seppur possono indicare importanti debolezze tecniche presenti sui sistemi, forniscono chiare indicazioni sulla postura dell’organizzazione rispetto alle politiche di sicurezza informatica adottate”.

Qualche semplice considerazione

Premesso che tutti siamo d’accordo nel dire che i processi di Patching management, di Hardening e di Sviluppo sicuro devono essere garantiti e presidiati da chi disegna, sviluppa, colluda ed esercisce i sistemi, comincerei a porci una domanda che probabilmente alle volte dimentichiamo di farci, in preda all’operatività che regna sovrana tra gli addetti ai lavori della sicurezza informatica.

Qual’è l’obiettivo principale della Sicurezza informatica?

Far in modo che possa essere garantita la Riservatezza, l’Integrità e la Disponibilità dei dati contenuti in un sistema informatico. Ma sintetizziamo meglio… far in modo che si possano evitare gli accessi indebiti ai sistemi … ma facciamo di meglio, in chiave moderna, nel 2019…

Fare in modo che i data-breach non ci siano!

La chiave di volta

Analizzando con attenzione il fenomeno, mi viene spontaneo pensare se risulti corretto il posizionamento delle attività di Red Team nei processi aziendali di oggi o se possa esserci un “modello” alternativo, più efficace che possa anche essere misurato in termini di abbattimento del rischio “economico” e “di impresa” dovuto soprattutto alla rimozione preventiva dei data-breach, prima che questi possano essere sfruttati da un ipotetico “nemico”.

La Data Breach Prevention è una tipologia di Security Assessment che consente di effettuare una analisi del sistema, finalizzata a rilevare, nei punti di esposizione più “critici”, la presenza di vettori di attacco capaci di generare una esfiltrazione di dati sensibili. Generalmente questa attività viene svolta da rete internet in puro ethical-hacking, in quanto la potenziale esfiltrazione viene generata concatenando diversi requisiti e carenze di sicurezza presenti sul sistema, cosa che oggi le macchine (le attività di Vulnerability Assessment nello specifico) non possono fare, se non al limite rilevare il primo strato di vulnertabilità utilizzabile per un vettore di attacco completo.

I principali punti di forza sono:

1. Rilevare i data-breach potenziali prima che questi vengano utilizzati;
2. Rimuovere in tempi brevi il primo “Gate” di innesco del vettore di attacco e quindi mitigare velocemente il rischio;
3. Analizzare le architetture perimetrali, facendo implementare (qualora non presenti), Security Gateway e Intrusion Prevention System (IpS e Waf) aumentando la postura aziendale nella rilevazione degli eventi anomali in transito da parte del Blue Team.

Ricordiamoci però che la rilevazione dei data-breach potenziali, risulta direttamente proporzionale alla capacità di sperimentazione dell’hacker etico. Inoltre, minore sarà la complessità nei processi da agire, maggiore sarà la sua concentrazione nel vincere la partita (la parte a lui più congeniale per natura) ovvero violare il sistema e fornire le risultanze del vettore di attacco rilevato essendo consapevole di aver vinto la sua sfida.

Questo perché il “White Hat Hacker” (il tester di sicurezza) non sta facendo altro che simulare un’attività di attacco. L’unica cosa che differisce è “l’ampiezza temporale”, in quanto tale ampiezza risulterà “definita” e non potenzialmente “infinita” come nel caso dei “Black Hat Hacker” e come riportato giustamente dal NIST,

Qualora il Red Team avesse il mandato di svolgere attività di Data Breach Prevention con continuità, dandogli modo di sperimentare e analizzare al meglio le superfici di attacco (evitando di imbrigliarlo in processi documentali e formalismi che potrebbero non essere attuali), potrà essere misurato attraverso il:

• Numero di data-breach potenziali rilevati rispetto al numero di penetration test effettuati;
• Ritorno economico in termini di spesa del Red Team stesso (risparmio sotteso in termini di data-breach potenziali abbattuti);
• Numero di Architetture perimetrali di intrusion prevention revisionate e richieste di messa a norma.

Oltretutto, tutto questo potrebbe consentire di migliorare anche l’indotto e quindi:

• Definire particolari contratti (in caso di utilizzo di fornitori) ad “incentivo” in forma “variabile” a valle della rilevazione dei data-breach potenziali, come stimolo per i pen-tester arruolati nel Red Team stesso.
• Incrementare l’effort del Red Team fino a raggiungere il giusto compromesso tra il suo costo diretto e il risparmio sotteso in termini di data-breach abbattuti.

Conclusioni

La sicurezza informatica ha sempre insegnato che le migliori idee e strategie, sono sempre state avviate dopo un grande fallimento, anche se su questo occorrerebbe una riflessione da parte di tutti.

Il Red Team può svolgere una attività di “carotaggio” importante, anche se per un tempo limitato, fornendo grandi benefici in termine di abbattimento del rischio, ma per fare questa scelta occorre abbandonare le convinzioni e i retaggi del passato in termini di gestione delle attività di controllo e vedere il tutto da una angolazione differente, anche rispetto alla tradizionale cybersecurity spesso concentrata sugli aspetti “formali” che “sotanziali”.

Occorre infatti entrare nell’ordine di idee che la Security da sola non può evitare che i data-breach ci siano, perchè sarebbe come sostenere che se esista una funzione Legale in azienda, non ci saranno più cause intentate ai danni della stessa.

La sicurezza informatica, infatti, è una Responsabilità condivisa; solo se tutte le organizzazioni avranno la giusta “consapevolezza al rischio” e garantiranno l’adozione delle politiche di sicurezza con rigorosa costanza ed attenzione, gli incidenti di sicurezza potranno essere evitati.

Risulta quindi necessaria una completa “rigenerazione” (non parlo di miglioramento) di questa attività, dando modo ai tester di dedicarsi a simulare un attacco reale, facendo in modo di garantirgli in quel “tempo limitato”, di mettere in campo tutto il loro bagaglio culturale di Tecnica, sperimentazione, genio e passione.

Massimiliano Brolli
Responsabile del RED Team di TIM S.p.a. e dei laboratori di sicurezza informatica in ambito 4G/5G. Ha rivestito incarichi manageriali in Telecom Italia che vanno dal ICT Risk Management all’ingegneria del software alla docenza.