C'è un tipo di problema di sicurezza particolarmente insidioso perché spesso non nasce da una configurazione sbagliata.
Nasce dal fatto che nessuno si ricorda più che quella risorsa esiste.
Un server viene creato per un progetto temporaneo.
Un sottodominio viene utilizzato durante una campagna marketing.
Un'API viene pubblicata per una nuova applicazione.
Un ambiente di test viene lasciato online.
Il progetto finisce.
Ma il server rimane.
Cosa significa "asset dimenticato"?
Un asset dimenticato è una risorsa che continua a essere presente o raggiungibile, ma che non viene più gestita attivamente dall'organizzazione.
Può essere:
- un dominio;
- un sottodominio;
- un indirizzo IP;
- un server;
- un'applicazione web;
- un'API;
- un pannello;
- un servizio cloud;
- un ambiente di staging.
Il problema principale non è necessariamente la risorsa.
È la mancanza di ownership.
Un esempio molto comune
Immaginiamo:
staging.example.com
Era utilizzato dal team di sviluppo.
Il progetto viene completato e il nuovo sito va in produzione.
Tutti iniziano a utilizzare:
www.example.com
e nessuno pensa più allo staging.
Se però:
staging.example.com
continua a essere raggiungibile, abbiamo una risorsa pubblica che potrebbe non essere più sottoposta agli stessi controlli della produzione.
Perché un vecchio asset può essere più interessante di uno nuovo?
Un'applicazione in produzione viene normalmente:
- aggiornata;
- monitorata;
- sottoposta a backup;
- controllata;
- gestita da un team.
Un vecchio ambiente potrebbe invece essere:
vecchio
+
non aggiornato
+
non monitorato
+
senza proprietario
Questa combinazione è molto più interessante dal punto di vista della sicurezza.
Le migrazioni sono un momento critico
Le migrazioni generano spesso asset dimenticati.
Per esempio:
Hosting A
↓
Hosting B
Il sito principale viene trasferito correttamente.
Ma il vecchio server potrebbe rimanere online.
Magari continua ad avere:
old.example.com
oppure un vecchio indirizzo IP direttamente raggiungibile.
L'organizzazione pensa di aver terminato la migrazione.
Dal punto di vista della superficie pubblica, però, il lavoro non è ancora concluso.
Anche i servizi cloud possono essere dimenticati
Il problema non riguarda soltanto i server tradizionali.
Un team può attivare:
- una piattaforma SaaS;
- un ambiente di sviluppo;
- una macchina virtuale;
- un servizio di storage;
- un'applicazione serverless;
- una piattaforma di monitoring.
Quando il progetto termina, il servizio può rimanere attivo.
Se nessuno lo considera parte dell'inventario, può sfuggire ai normali processi di sicurezza.
Come individuare un asset dimenticato?
Non esiste una singola tecnica sufficiente.
È utile combinare diverse fonti:
DNS
+
certificati
+
IP pubblici
+
servizi HTTP/HTTPS
+
inventario interno
Per esempio, se un'organizzazione conosce:
www.example.com
api.example.com
ma dall'esterno compare anche:
old-api.example.com
la differenza merita una verifica.
Non significa automaticamente che sia un problema.
Significa che esiste una domanda a cui bisogna rispondere:
"Perché questo asset è ancora pubblico?"
Il concetto di ownership
Ogni asset pubblico importante dovrebbe avere un proprietario.
Non necessariamente una singola persona.
Può essere:
Team IT
Team Development
Marketing
Operations
Security
L'importante è che qualcuno sappia:
- cosa sia;
- perché esista;
- chi lo gestisca;
- quale sia la sua criticità;
- cosa fare quando deve essere dismesso.
Un asset senza proprietario è molto più difficile da gestire correttamente.
La dismissione dovrebbe essere un processo
Quando un progetto termina, non dovrebbe bastare:
"Abbiamo spento l'applicazione."
Bisognerebbe verificare anche:
Applicazione
↓
Server
↓
DNS
↓
Certificati
↓
Account cloud
↓
Servizi esterni
↓
Monitoraggio
L'obiettivo è assicurarsi che non rimangano componenti pubblici inutilizzati.
Attenzione ai falsi positivi
Anche in questo caso è importante non saltare alle conclusioni.
Un asset apparentemente "vecchio" potrebbe essere:
- ancora necessario;
- utilizzato per compatibilità;
- riservato a un particolare cliente;
- mantenuto come sistema di emergenza;
- protetto da controlli che non sono immediatamente visibili.
Per questo un sistema di sicurezza dovrebbe aiutare a identificare ciò che merita una verifica, non dichiarare automaticamente vulnerabile qualsiasi risorsa sconosciuta.
Una semplice checklist
Per ogni asset pubblico chiediti:
- Sappiamo che esiste?
- Sappiamo a cosa serve?
- È ancora necessario?
- Chi lo gestisce?
- Quando è stato verificato l'ultima volta?
- Utilizza software aggiornato?
- È raggiungibile direttamente da Internet?
- È protetto come gli altri asset?
- Esiste una procedura per dismetterlo?
Se diverse risposte sono "non lo so", vale la pena approfondire.
In sintesi
Gli asset dimenticati sono pericolosi soprattutto perché possono uscire dal normale ciclo di gestione della sicurezza.
Il problema non è semplicemente:
"Questo server è vecchio."
Il problema è:
"Questo server è vecchio e nessuno lo sta controllando."
La differenza è enorme.
La gestione della superficie di attacco serve proprio a ridurre questo tipo di zona grigia, mantenendo una visione aggiornata di ciò che l'organizzazione espone pubblicamente.
MiHakero può aiutare a individuare asset e servizi rilevabili dall'esterno che meritano di essere identificati, verificati e, quando necessario, ricondotti sotto il controllo del team responsabile.