Quando si parla di sicurezza di un sito web o di un'infrastruttura, la prima cosa che viene in mente è spesso una vulnerabilità: una password debole, un software non aggiornato, un'API esposta o una configurazione sbagliata.
Ma prima di cercare una vulnerabilità c'è una domanda ancora più semplice da porsi:
Che cosa è effettivamente esposto su Internet?
È da qui che nasce il concetto di Attack Surface, cioè la superficie di attacco.
In parole semplici, è l'insieme di tutto ciò che un'organizzazione espone verso l'esterno e che, in qualche modo, può essere raggiunto, osservato o analizzato da Internet.
E spesso è molto più grande di quanto si pensi.
Cos'è esattamente una Attack Surface?
Immaginiamo di avere un'azienda con il dominio:
example.com
A prima vista potremmo avere semplicemente un sito web.
Ma dietro quel dominio potrebbero esserci anche:
www.example.com
api.example.com
app.example.com
admin.example.com
staging.example.com
dev.example.com
E magari alcuni di questi host puntano a server diversi, espongono porte differenti o utilizzano applicazioni completamente diverse.
Tutti questi elementi possono fare parte della superficie di attacco esterna.
La cosa importante da capire è che essere esposti non significa automaticamente essere vulnerabili.
Un'API pubblica, ad esempio, può essere perfettamente normale. Se serve all'applicazione e richiede correttamente autenticazione e autorizzazione, la sua presenza su Internet non rappresenta necessariamente un problema.
Il punto è sapere che esiste, capire a cosa serve e verificare che sia configurata nel modo previsto.
Attack Surface e vulnerabilità sono due cose diverse
Questa distinzione è importante soprattutto quando si parla di strumenti di sicurezza.
Supponiamo che un server esponga:
443/tcp → HTTPS
La porta 443 aperta non è una vulnerabilità. È semplicemente il modo attraverso cui il sito web viene reso disponibile agli utenti.
Se invece quel servizio utilizza una versione software vulnerabile, allora abbiamo un problema diverso.
Possiamo quindi immaginare il processo in questo modo:
Asset
↓
Servizio esposto
↓
Tecnologia utilizzata
↓
Configurazione
↓
Vulnerabilità
La superficie di attacco viene prima della vulnerabilità.
Ed è proprio per questo che conoscerla è così importante.
Cosa può far parte della superficie di attacco?
Non esiste un unico elenco valido per tutte le organizzazioni.
In generale, però, possiamo trovare:
- domini;
- sottodomini;
- indirizzi IP;
- porte aperte;
- servizi di rete;
- applicazioni web;
- API;
- pannelli amministrativi;
- server cloud;
- ambienti di sviluppo;
- ambienti di staging;
- software e framework;
- servizi legacy;
- certificati;
- endpoint pubblici.
Anche un semplice sito WordPress può avere una superficie più ampia di quanto sembri.
Potrebbero esserci, per esempio:
example.com
www.example.com
api.example.com
staging.example.com
mail.example.com
Il sito principale è soltanto uno degli elementi.
Il problema degli asset dimenticati
Uno degli aspetti più interessanti della Attack Surface è rappresentato dagli asset dimenticati.
Capita abbastanza facilmente.
Un team crea un ambiente di test per un nuovo progetto:
staging.example.com
Il progetto viene completato, ma l'ambiente rimane online.
Dopo qualche mese potrebbe non esserci più nessuno che lo utilizza.
Dal punto di vista dell'azienda, quel sistema potrebbe essere considerato "vecchio".
Dal punto di vista di Internet, invece, continua semplicemente a essere raggiungibile.
E magari nel frattempo non riceve più aggiornamenti.
Questo non significa che staging.example.com sia necessariamente vulnerabile. Significa che esiste un asset pubblico che qualcuno dovrebbe conoscere e gestire.
La superficie di attacco cambia continuamente
Un altro aspetto da non sottovalutare è che la Attack Surface non è qualcosa che si definisce una volta e poi rimane uguale per sempre.
Ogni nuova applicazione, migrazione, server o servizio cloud può modificarla.
Anche operazioni apparentemente normali possono avere conseguenze:
Nuovo progetto
↓
Nuovo sottodominio
↓
Nuovo server
↓
Nuova API
↓
Nuova superficie esposta
Lo stesso vale al contrario.
Quando un servizio viene dismesso, dovrebbe essere rimosso anche dalla superficie pubblica.
Nella pratica, però, non sempre succede.
Perché è difficile sapere cosa è realmente esposto?
In un ambiente piccolo può essere relativamente semplice tenere tutto sotto controllo.
In un'organizzazione più grande la situazione cambia rapidamente.
Potrebbero esserci:
- diversi team di sviluppo;
- più fornitori;
- infrastrutture cloud;
- vecchie applicazioni;
- domini acquistati anni prima;
- ambienti temporanei;
- servizi creati per un singolo progetto.
Inoltre, l'inventario interno e ciò che è realmente visibile dall'esterno non sono necessariamente identici.
È proprio questa differenza a rendere interessante l'analisi della superficie di attacco esterna.
Cosa significa guardare l'infrastruttura "da Internet"?
Immaginiamo di avere internamente questo inventario:
example.com
api.example.com
Ma osservando l'infrastruttura dall'esterno vengono individuati:
example.com
api.example.com
staging.example.com
old-api.example.com
dev.example.com
Non significa che gli ultimi tre siano automaticamente vulnerabili.
Potrebbero essere servizi perfettamente legittimi.
La domanda diventa però:
Perché sono pubblici? Sono ancora necessari? Chi li gestisce? Sono aggiornati?
Questa è la prospettiva dell'External Attack Surface Management.
Attack Surface Management
Quando la superficie di attacco viene osservata e gestita in modo continuativo si parla di Attack Surface Management, o ASM.
L'obiettivo non è semplicemente trovare una vulnerabilità.
Prima ancora bisogna mantenere una certa visibilità su ciò che è esposto.
Un processo può quindi partire da:
Discovery
↓
Inventario
↓
Identificazione dei servizi
↓
Analisi delle configurazioni
↓
Ricerca delle vulnerabilità
↓
Prioritizzazione
Questo permette di affrontare un problema spesso sottovalutato: non puoi mettere in sicurezza qualcosa che non sai di avere.
Quindi avere una grande Attack Surface è sempre un problema?
No.
Un'azienda che offre un servizio online deve necessariamente avere una parte della propria infrastruttura esposta.
Un e-commerce avrà un sito web.
Una SaaS avrà probabilmente API e applicazioni.
Un provider di posta avrà servizi di posta.
L'obiettivo non è portare la superficie di attacco a zero.
L'obiettivo è sapere:
- cosa è pubblico;
- perché è pubblico;
- chi lo gestisce;
- quale tecnologia utilizza;
- se è aggiornato;
- se presenta problemi di sicurezza;
- se l'esposizione è realmente necessaria.
Una superficie ampia ma ben conosciuta e gestita può essere preferibile a una superficie più piccola ma completamente sconosciuta.
Una piccola checklist
Se gestisci un sito, un'applicazione o un'infrastruttura, puoi iniziare da alcune domande molto semplici:
[ ] Quali domini abbiamo?
[ ] Quali sottodomini esistono?
[ ] Quali IP sono associati?
[ ] Quali porte sono esposte?
[ ] Quali servizi rispondono?
[ ] Quali applicazioni sono pubbliche?
[ ] Quali API sono raggiungibili?
[ ] Esistono ambienti di staging?
[ ] Esistono vecchi servizi ancora online?
[ ] Quali tecnologie vengono utilizzate?
[ ] Ci sono configurazioni da verificare?
[ ] Sono presenti vulnerabilità note?
Già rispondere a queste domande può far emergere situazioni che non erano state considerate.
La Attack Surface è il punto di partenza
Una vulnerabilità è importante, ma prima ancora è necessario sapere dove cercarla.
Per questo la Attack Surface può essere considerata il punto di partenza di molte attività di sicurezza.
Conoscere ciò che è esposto permette di passare da una gestione basata sulle supposizioni a una gestione basata su informazioni concrete.
E soprattutto permette di porsi una domanda molto semplice:
"Se qualcuno osservasse la mia infrastruttura da Internet, cosa vedrebbe?"
La risposta dovrebbe essere qualcosa che conosci già.
Se invece non sei sicuro della risposta, probabilmente vale la pena iniziare proprio da lì.
Analizza la tua superficie di attacco con MiHakero
MiHakero analizza domini, applicazioni web, API e servizi pubblicamente raggiungibili per individuare esposizioni inattese, configurazioni da verificare e vulnerabilità note rilevabili dall'esterno.
L'obiettivo è aiutarti a capire cosa è esposto e cosa merita attenzione, prima ancora di trasformare ogni risultato in un problema.