Quante cose della tua organizzazione sono realmente raggiungibili o identificabili da Internet?
La risposta potrebbe essere molto diversa da quella che immagini.
Un'azienda potrebbe pensare di avere semplicemente:
example.com
In realtà, osservando ciò che è pubblicamente rilevabile, potrebbero comparire:
www.example.com
api.example.com
mail.example.com
vpn.example.com
staging.example.com
203.0.113.10
203.0.113.20
E magari anche servizi di terze parti, vecchi sottodomini o applicazioni che nessuno ricorda più.
È qui che entra in gioco l'Attack Surface Management, spesso abbreviato in ASM.
Cos'è l'attack surface?
L'attack surface è, in parole semplici, l'insieme degli elementi di un'organizzazione che possono essere raggiunti, identificati o osservati dall'esterno e che potrebbero quindi rappresentare un punto di ingresso o una fonte di informazioni.
Può comprendere:
- domini;
- sottodomini;
- indirizzi IP pubblici;
- porte e servizi;
- applicazioni web;
- API;
- pannelli amministrativi;
- certificati;
- servizi cloud;
- infrastrutture di terze parti.
Non significa che ogni elemento sia vulnerabile.
Significa che ogni elemento fa parte del quadro che bisogna conoscere.
Il problema dell'inventario incompleto
Uno dei problemi più comuni nella sicurezza informatica è proprio questo:
l'organizzazione non sa esattamente cosa possiede.
Un server può essere stato creato anni fa.
Un sottodominio può essere rimasto dopo una migrazione.
Un'API può essere stata pubblicata per un progetto temporaneo.
Un servizio cloud può essere stato attivato da un team senza coinvolgere il reparto IT.
Nel frattempo, tutti questi elementi possono continuare a essere pubblicamente accessibili.
Attack Surface Management non significa semplicemente "scansionare"
Questo è un punto importante.
Un sistema ASM non dovrebbe limitarsi a trovare porte aperte o vulnerabilità.
Prima ancora bisogna rispondere a domande più semplici:
Cosa esiste?
Dove si trova?
A cosa serve?
Chi lo gestisce?
Dovrebbe essere pubblico?
È ancora necessario?
Solo dopo ha senso chiedersi:
È configurato correttamente?
Utilizza software aggiornato?
Presenta vulnerabilità note?
Espone informazioni sensibili?
Un esempio pratico
Immaginiamo un'organizzazione con:
example.com
api.example.com
staging.example.com
Il team IT sa perfettamente cosa sono i primi due.
staging.example.com, invece, era stato creato per un vecchio progetto.
Il server è ancora online.
Il software non viene aggiornato da mesi.
Il servizio non viene più utilizzato.
Dal punto di vista dell'attack surface, questo asset è particolarmente interessante.
Non perché il suo nome contenga "staging".
Ma perché rappresenta una risorsa pubblica che potrebbe non avere più un proprietario.
La superficie cambia continuamente
Un altro problema è che l'attack surface non è statica.
Ogni volta che un'organizzazione:
- acquista un dominio;
- crea un sottodominio;
- pubblica un'API;
- apre un nuovo servizio;
- migra un'applicazione;
- attiva un cloud provider;
- dismette un server;
la superficie può cambiare.
Per questo un inventario aggiornato una volta all'anno non è sufficiente.
Attack Surface Management e vulnerabilità
L'ASM e il vulnerability management sono collegati, ma non sono la stessa cosa.
Possiamo semplificare così:
Attack Surface Management
↓
Cosa è esposto?
↓
Asset identificati
↓
Vulnerability Management
↓
Cosa è vulnerabile?
↓
Priorità di intervento
Se non conosci un asset, potresti non controllarne nemmeno le vulnerabilità.
Perché gli asset sconosciuti sono pericolosi?
Immaginiamo di avere:
api.example.com
e di sapere che utilizza una determinata tecnologia.
Possiamo quindi controllare aggiornamenti, configurazioni e vulnerabilità.
Ma se esiste:
old-api.example.com
e nessuno sa che esiste, probabilmente nessuno lo sta controllando.
È proprio questo il problema degli unknown assets.
Non necessariamente sono vulnerabili.
Potrebbero semplicemente essere fuori dal processo di sicurezza.
Una buona strategia
Un processo ASM efficace dovrebbe includere almeno:
1. Discovery
Individuare ciò che è pubblicamente associato all'organizzazione.
2. Inventario
Organizzare gli asset trovati.
3. Identificazione
Capire cosa rappresenta ogni asset.
4. Verifica
Controllare se è effettivamente attivo e accessibile.
5. Valutazione
Cercare configurazioni problematiche e vulnerabilità rilevanti.
6. Prioritizzazione
Stabilire cosa richiede maggiore attenzione.
7. Monitoraggio
Ripetere il processo nel tempo.
L'obiettivo non è avere zero asset
Un'azienda non dovrebbe cercare di ridurre la propria superficie a zero.
Un sito deve essere online.
Un'API pubblica deve essere raggiungibile.
Un servizio email deve essere esposto.
L'obiettivo è invece avere una superficie:
conosciuta, necessaria e controllata.
In sintesi
L'Attack Surface Management parte da una domanda molto semplice:
"Cosa può essere visto o raggiunto dall'esterno?"
Ma la risposta richiede un processo continuo.
Bisogna sapere:
- quali asset esistono;
- quali sono pubblici;
- chi li gestisce;
- perché sono pubblici;
- quali tecnologie utilizzano;
- quali problemi presentano;
- quali richiedono attenzione immediata.
È questo il passaggio da una sicurezza basata sul singolo sito a una visione più completa dell'infrastruttura.
MiHakero nasce proprio con questo approccio: osservare la superficie pubblicamente rilevabile, identificare gli elementi che meritano attenzione e aiutare a stabilire da dove iniziare.