Per molto tempo la sicurezza informatica è stata gestita soprattutto guardando "da dentro".
L'azienda conosce i propri server, il reparto IT conosce la propria rete e gli sviluppatori conoscono le applicazioni che hanno pubblicato.
Ma c'è un'altra prospettiva altrettanto importante:
Che cosa vede Internet?
Un dominio può avere sottodomini che nessuno ricorda più, un'API può essere rimasta online dopo una migrazione, un ambiente di staging può essere ancora raggiungibile e un vecchio servizio può continuare a rispondere da un server pubblico.
È proprio qui che entra in gioco l'External Attack Surface Management, o EASM.
Cos'è l'External Attack Surface Management?
Con External Attack Surface Management si indica l'insieme delle attività utilizzate per individuare e monitorare gli asset di un'organizzazione che risultano visibili o raggiungibili dall'esterno.
Detto in modo molto semplice:
EASM significa cercare di vedere l'infrastruttura dal punto di vista di Internet.
Non si parte necessariamente da un inventario interno perfetto.
Si parte da ciò che è osservabile pubblicamente e si cerca di ricostruire la superficie esterna.
Perché serve?
Immaginiamo una piccola azienda.
Nel proprio inventario risultano:
example.com
api.example.com
Durante un'analisi esterna, però, vengono individuati anche:
staging.example.com
dev.example.com
old-api.example.com
Che cosa sono?
Potrebbero essere:
- ambienti ancora utilizzati;
- vecchi progetti;
- sistemi di test;
- servizi gestiti da un altro team;
- asset che non dovrebbero più essere online.
Non possiamo stabilire che siano vulnerabili semplicemente perché li abbiamo trovati.
Ma abbiamo scoperto qualcosa di importante:
l'infrastruttura pubblica è più ampia di quanto risultasse dall'inventario iniziale.
EASM non significa semplicemente "cercare vulnerabilità"
Questa è probabilmente la distinzione più importante.
Un vulnerability scanner parte generalmente da un insieme di asset e cerca vulnerabilità.
EASM si occupa prima di tutto della visibilità della superficie esterna.
Possiamo immaginare il processo così:
Cosa è esposto?
↓
Quali asset sono?
↓
Quali servizi utilizzano?
↓
Quali tecnologie?
↓
Ci sono configurazioni da verificare?
↓
Ci sono vulnerabilità note?
↓
Cosa richiede attenzione?
La ricerca delle vulnerabilità è quindi una parte del processo, non necessariamente il suo unico obiettivo.
EASM e Attack Surface Management
I due termini sono strettamente collegati.
L'Attack Surface Management (ASM) riguarda la gestione della superficie di attacco.
L'External Attack Surface Management (EASM) pone particolare attenzione alla parte della superficie osservabile dall'esterno.
In pratica, EASM risponde soprattutto a una domanda:
"Quali risorse della mia organizzazione sono visibili da Internet?"
Ed è una domanda che può avere risposte molto diverse rispetto a un semplice inventario interno.
Quali asset può individuare un sistema EASM?
Dipende dalla tecnologia utilizzata e dall'ampiezza dell'analisi, ma in generale possono rientrare nella superficie esterna:
- domini;
- sottodomini;
- indirizzi IP;
- porte;
- servizi;
- applicazioni web;
- API;
- pannelli amministrativi;
- ambienti di staging;
- ambienti di sviluppo;
- software;
- framework;
- CMS;
- certificati;
- servizi cloud;
- asset legacy.
L'obiettivo è costruire una rappresentazione il più possibile aggiornata della presenza pubblica dell'organizzazione.
I sottodomini sono un buon esempio
Pensiamo a:
example.com
Nel tempo potrebbero essere stati creati:
api.example.com
app.example.com
admin.example.com
staging.example.com
dev.example.com
test.example.com
Non c'è nulla di strano nel fatto che un'azienda abbia molti sottodomini.
Il problema nasce quando non è più chiaro:
- quali siano ancora necessari;
- chi li gestisca;
- quale software utilizzino;
- se siano aggiornati;
- se debbano essere pubblici.
EASM può aiutare proprio a ridurre questo tipo di zona d'ombra.
Il caso degli ambienti di staging
Gli ambienti di staging sono un esempio particolarmente intuitivo.
Un team di sviluppo può creare:
staging.example.com
per testare una nuova versione dell'applicazione.
Durante lo sviluppo può essere perfettamente normale che sia accessibile al team.
Il problema nasce quando l'ambiente rimane pubblico anche dopo la fine del progetto.
Inoltre, staging e produzione potrebbero non avere la stessa configurazione.
Potremmo quindi trovare:
Produzione
→ software aggiornato
→ configurazione verificata
Staging
→ versione precedente
→ debug attivo
→ configurazione temporanea
Non è detto che lo staging sia vulnerabile.
Ma è sicuramente qualcosa che dovrebbe essere conosciuto.
E le API?
Le API sono un altro componente fondamentale della superficie esterna.
Un'applicazione moderna potrebbe utilizzare:
api.example.com
con endpoint come:
/api/v1/users
/api/v1/products
/api/v2/orders
Quando una nuova versione viene pubblicata, quella precedente non sempre viene eliminata immediatamente.
Potremmo quindi ritrovarci con:
/api/v1
/api/v2
entrambe accessibili.
Questo non significa automaticamente che v1 sia vulnerabile.
Significa però che esiste una superficie che deve essere inventariata e gestita.
EASM e tecnologia
Sapere che un servizio esiste è solo il primo passo.
È utile anche capire cosa c'è dietro.
Per esempio:
api.example.com
↓
HTTPS
↓
Nginx
↓
PHP
↓
Laravel
Oppure:
app.example.com
↓
HTTPS
↓
Node.js
↓
Express
Conoscere le tecnologie permette di collegare gli asset a eventuali advisory e vulnerabilità note.
Da asset discovery a vulnerability assessment
Una possibile pipeline può essere:
Asset Discovery
↓
Service Discovery
↓
Technology Detection
↓
Exposure Analysis
↓
Vulnerability Detection
↓
Risk Context
↓
Prioritization
Il vantaggio di questo approccio è che non si perde completamente il contesto.
Trovare una vulnerabilità è utile.
Sapere su quale asset, quale servizio e quale esposizione la rende rilevante è ancora più utile.
CVE, CVSS e vulnerabilità note
Quando vengono identificati software e versioni, è possibile confrontarli con informazioni pubbliche sulle vulnerabilità.
Uno dei sistemi più conosciuti è quello delle CVE, che identificano specifiche vulnerabilità.
Per descriverne la gravità viene spesso utilizzato il CVSS.
Esistono inoltre cataloghi specifici, come il CISA Known Exploited Vulnerabilities Catalog, che raccolgono vulnerabilità note per essere state sfruttate.
Queste informazioni possono essere utilizzate per aiutare a stabilire le priorità.
Ma è importante evitare una semplificazione:
CVE presente
≠
sistema sicuramente compromesso
La presenza di una vulnerabilità conosciuta è un elemento da valutare insieme al contesto dell'asset e alla sua configurazione.
Perché EASM dovrebbe essere continuo?
La superficie esterna cambia continuamente.
Oggi puoi avere:
example.com
api.example.com
Domani potrebbe comparire:
app.example.com
Tra un mese potrebbe essere dismesso:
api.example.com
e magari rimanere online per errore.
Per questo motivo una scansione singola è una fotografia.
Il monitoraggio periodico permette invece di osservare come cambia quella fotografia nel tempo.
EASM e Shadow IT
Un altro concetto collegato è quello di Shadow IT.
Immaginiamo che un team crei autonomamente un piccolo servizio cloud per un progetto.
Il servizio funziona.
Il progetto viene poi abbandonato.
Il servizio però rimane online.
Dal punto di vista dell'organizzazione potrebbe essere ormai irrilevante.
Dal punto di vista della superficie pubblica, invece, è ancora presente.
EASM può aiutare a far emergere proprio queste discrepanze.
EASM e penetration testing non sono la stessa cosa
È facile confondere questi concetti.
Un penetration test ha generalmente uno scope definito e punta a simulare o verificare scenari di attacco in modo più approfondito.
EASM ha invece come obiettivo principale la visibilità della superficie esterna e dei suoi cambiamenti.
Possiamo semplificare così:
EASM
"Cosa è esposto?"
Vulnerability Assessment
"Cosa potrebbe essere vulnerabile?"
Penetration Test
"Cosa può essere effettivamente sfruttato?"
Sono attività diverse, ma possono lavorare insieme.
Un esempio concreto
Supponiamo che un'azienda gestisca una piattaforma SaaS.
Il team conosce:
app.example.com
api.example.com
Durante un'analisi esterna viene individuato anche:
old-api.example.com
Il team verifica e scopre che si tratta della vecchia API.
La prima domanda è:
Serve ancora?
Se la risposta è no, rimuoverla riduce la superficie di attacco.
Se invece deve rimanere online, si può verificare:
- quale versione utilizza;
- quali endpoint espone;
- quale autenticazione richiede;
- se esistono vulnerabilità note;
- quali utenti possono raggiungerla.
L'analisi non ha quindi semplicemente "trovato una vulnerabilità".
Ha fatto emergere un asset che meritava attenzione.
Cosa dovrebbe produrre un buon sistema EASM?
Una lista infinita di risultati non è necessariamente utile.
Un buon sistema dovrebbe aiutare a rispondere a domande concrete:
Cosa ho esposto?
↓
Cosa riconosco?
↓
Cosa non riconosco?
↓
Cosa richiede una verifica?
↓
Cosa presenta un rischio maggiore?
↓
Da dove conviene iniziare?
Il valore non sta quindi soltanto nella quantità di dati raccolti.
Sta nella capacità di trasformare quei dati in informazioni utilizzabili.
EASM per una piccola azienda
Non bisogna pensare che l'EASM sia utile soltanto a grandi organizzazioni.
Anche una piccola azienda può avere:
1 dominio
3 sottodomini
2 applicazioni
1 API
1 ambiente staging
2 server
Sono già diversi elementi da gestire.
Per uno sviluppatore freelance o una piccola software house la situazione può essere ancora più interessante se vengono gestiti molti progetti e domini differenti.
Una domanda molto semplice
Alla fine, l'intero concetto di EASM può essere riassunto con una domanda:
"Se non avessi accesso alla rete interna e osservassi questa organizzazione soltanto da Internet, cosa riuscirei a trovare?"
La risposta dovrebbe essere conosciuta.
Se invece emergono domini, applicazioni o servizi completamente inattesi, significa che esiste una differenza tra la superficie conosciuta e quella realmente esposta.
Ed è proprio quella differenza che vale la pena approfondire.
Conclusione
L'External Attack Surface Management non consiste semplicemente nel cercare vulnerabilità.
Parte da un problema ancora più fondamentale: sapere cosa è realmente esposto.
Domini, sottodomini, API, applicazioni, server e servizi possono cambiare nel tempo e creare una superficie molto più ampia di quella prevista.
Individuarla, comprenderla e monitorarla permette di affrontare la sicurezza con maggiore consapevolezza.
E quando vengono individuati problemi o vulnerabilità, la fase successiva diventa altrettanto importante:
capire cosa affrontare per primo.
Guarda la tua superficie esterna con MiHakero
MiHakero permette di analizzare domini, applicazioni web, API e servizi pubblicamente raggiungibili per individuare esposizioni inattese, configurazioni da verificare e vulnerabilità note rilevabili dall'esterno.
Invece di limitarsi a dirti che esiste un problema, l'obiettivo è aiutarti a capire che cosa hai esposto e cosa merita la tua attenzione.