La prima regola della sicurezza informatica potrebbe essere molto semplice:
non puoi proteggere correttamente ciò che non sai di avere.
Eppure, costruire un inventario completo degli asset pubblici può essere più difficile di quanto sembri.
Un'organizzazione può conoscere perfettamente il proprio sito principale ma non ricordare:
- un vecchio sottodominio;
- un server legacy;
- un'API;
- un ambiente di staging;
- un servizio cloud;
- un indirizzo IP;
- un'applicazione pubblicata da un altro team.
Per questo è utile costruire un vero e proprio inventario della superficie di attacco.
Da dove iniziare?
Il primo errore da evitare è partire immediatamente dalle vulnerabilità.
Prima bisogna costruire una lista degli asset.
Un inventario iniziale potrebbe contenere:
Domini
Sottodomini
IP pubblici
Porte
Servizi
Applicazioni web
API
Certificati
Servizi cloud
Solo successivamente si può passare alla valutazione della sicurezza.
1. Partire dai domini
Il dominio principale è generalmente il punto di partenza più semplice.
Per esempio:
example.com
Da qui si possono identificare i sottodomini conosciuti:
www.example.com
api.example.com
mail.example.com
staging.example.com
L'obiettivo non è soltanto raccoglierli.
Bisogna capire cosa rappresenta ciascuno.
2. Aggiungere gli indirizzi IP
Ogni hostname può essere associato a uno o più indirizzi.
Per esempio:
api.example.com
↓
203.0.113.25
L'IP diventa quindi un altro elemento dell'inventario.
È importante considerare anche IPv6 quando presente.
3. Identificare i servizi
Un IP non basta.
Bisogna sapere quali servizi sono effettivamente raggiungibili.
Un esempio potrebbe essere:
203.0.113.25
443 → HTTPS
22 → SSH
A questo punto possiamo iniziare a descrivere l'asset in modo più completo.
4. Identificare le applicazioni
Sapere che esiste HTTPS non significa sapere quale applicazione c'è dietro.
Potremmo avere:
443
↓
Web server
↓
Applicazione
↓
API
L'inventario dovrebbe quindi contenere anche informazioni utili sull'applicazione quando disponibili.
Per esempio:
- tecnologia;
- framework;
- versione;
- ambiente;
- proprietario;
- criticità.
5. Aggiungere i certificati
I certificati TLS possono fornire ulteriori hostname.
Per esempio, un certificato potrebbe essere associato a:
example.com
www.example.com
api.example.com
staging.example.com
Questo può aiutare a trovare differenze tra ciò che l'organizzazione pensa di esporre e ciò che è effettivamente osservabile.
6. Cercare asset non riconosciuti
Questa è una delle parti più importanti.
Supponiamo che l'inventario ufficiale contenga:
www.example.com
api.example.com
ma l'analisi esterna trovi:
dev.example.com
staging.example.com
old.example.com
Non bisogna dichiarare automaticamente questi asset vulnerabili.
Bisogna classificarli:
Conosciuto e necessario
Conosciuto ma da proteggere
Sconosciuto
Obsoleto
Da verificare
7. Assegnare un proprietario
Ogni asset importante dovrebbe avere un responsabile.
Per esempio:
| Asset | Tipo | Proprietario | Criticità | | ----------------------------------------- | ------- | ------------ | ------------- | | www.example.com | Web | Web Team | Alta | | api.example.com | API | Development | Alta | | staging.example.com | Staging | Development | Media | | old.example.com | Legacy | Nessuno | Da verificare |
La colonna "Proprietario" è fondamentale.
Se nessuno sa chi gestisce una risorsa, diventa molto più difficile correggere eventuali problemi.
8. Indicare perché l'asset è pubblico
Un ulteriore campo molto utile è:
"Perché è esposto?"
Per esempio:
www.example.com
→ sito pubblico
api.example.com
→ API per applicazione mobile
vpn.example.com
→ accesso remoto
staging.example.com
→ ambiente di test
Se non esiste una motivazione chiara, vale la pena approfondire.
9. Stabilire una priorità
Non tutti gli asset hanno la stessa importanza.
Un sito istituzionale pubblico potrebbe essere molto meno critico di:
admin.example.com
oppure di:
api.example.com
che gestisce dati importanti.
Una classificazione semplice può essere:
- Critico
- Alto
- Medio
- Basso
- Da verificare
L'obiettivo è evitare di trattare ogni risultato allo stesso modo.
10. Aggiornare l'inventario
Un inventario statico perde rapidamente valore.
La superficie cambia continuamente.
Nuovi:
domini
server
API
servizi cloud
possono comparire.
Altri possono essere rimossi.
Per questo l'inventario dovrebbe essere aggiornato periodicamente.
Una struttura semplice
Anche un foglio di calcolo può essere sufficiente per iniziare:
| Asset | Tipo | IP | Servizio | Proprietario | Pubblico | Stato | | ----------------------------------------- | ------- | ------------ | -------- | ------------ | -------- | ------------- | | example.com | Dominio | — | DNS | IT | Sì | Attivo | | www.example.com | Web | 203.0.113.25 | HTTPS | Web | Sì | Attivo | | api.example.com | API | 203.0.113.26 | HTTPS | Dev | Sì | Attivo | | staging.example.com | Staging | 203.0.113.27 | HTTPS | Dev | Sì | Da verificare |
Non serve necessariamente una piattaforma complessa.
Serve soprattutto continuità nel mantenimento.
Inventario interno e osservazione esterna
Il metodo più efficace consiste nel confrontare due punti di vista:
Ciò che sappiamo di avere
+
Ciò che è possibile osservare dall'esterno
↓
Differenze
↓
Da verificare
Le differenze sono spesso la parte più interessante.
Se l'inventario interno dice:
3 asset pubblici
ma l'osservazione esterna ne individua:
8
abbiamo una domanda importante da risolvere.
L'inventario non serve soltanto alla sicurezza
Un buon inventario può essere utile anche per:
- gestione IT;
- migrazioni;
- dismissioni;
- gestione dei certificati;
- monitoraggio;
- incident response;
- gestione delle vulnerabilità;
- conformità.
Sapere cosa è esposto è una necessità operativa, non soltanto una misura di sicurezza.
In sintesi
Costruire un inventario della superficie di attacco significa passare da:
"Abbiamo un sito."
a:
Abbiamo questi domini,
questi sottodomini,
questi IP,
questi servizi,
queste applicazioni,
questi proprietari
e queste motivazioni per cui sono pubblici.
È una differenza enorme.
Un inventario efficace dovrebbe essere:
- completo;
- aggiornato;
- classificato;
- associato a un proprietario;
- confrontato periodicamente con ciò che è realmente visibile dall'esterno.
Perché la superficie di attacco non è un elenco statico.
Cambia nel tempo.
MiHakero può supportare proprio questo tipo di approccio, aiutando a osservare la superficie pubblicamente rilevabile e a mettere in evidenza gli elementi che richiedono una verifica o una maggiore attenzione.