Superficie d’attacco web: inventario e priorità prima degli strumenti

La superficie d’attacco web comprende tutti gli elementi raggiungibili o sfruttabili da un soggetto esterno: siti, sottodomini, API, pannelli, servizi cloud, account, dipendenze e configurazioni. Il rischio non vive soltanto nell’applicazione principale, ma anche negli asset dimenticati.

Proteggere ciò che il team conosce è necessario; scoprire ciò che non è più governato viene prima. Un vecchio ambiente di test, un DNS rimasto attivo o una chiave condivisa possono offrire un ingresso più semplice del sito di produzione.

Che cos’è la superficie d’attacco web

È l’insieme dei punti in cui un sistema può ricevere input, esporre dati o consentire un’azione. Include componenti tecnici e identità: non basta elencare server e pagine.

• domini, sottodomini e record DNS;
• indirizzi IP e servizi esposti;
• siti, web app e pannelli amministrativi;
• API, webhook e endpoint di integrazione;
• storage, CDN e servizi cloud;
• account tecnici, ruoli e credenziali;
• CMS, framework, plugin e librerie;
• fornitori SaaS e script di terze parti;
• ambienti di sviluppo, test e staging.

Perché l’inventario è il primo controllo

Non si può aggiornare o monitorare un asset che nessuno riconosce come proprio. Fusioni, campagne temporanee, prove di fornitori e cambi di agenzia lasciano spesso servizi attivi oltre la loro utilità.

OWASP evidenzia che le applicazioni moderne superano il perimetro tradizionale: API, SaaS, cloud e asset dimenticati ampliano l’esposizione. L’inventario deve quindi rappresentare dipendenze e responsabilità, non soltanto URL.

Costruire una mappa utile

1. Partire dalle fonti interne

Raccogliere contratti, registri domini, account cloud, repository, fatture, password manager aziendale, configurazioni DNS e documentazione dei fornitori. Ogni fonte mostra una porzione diversa.

2. Osservare dall’esterno

La ricognizione autorizzata può individuare sottodomini, certificati, porte e tecnologie visibili pubblicamente. Deve essere svolta da personale competente, su perimetro autorizzato e senza provocare interruzioni.

3. Assegnare un proprietario

Ogni asset deve avere un responsabile operativo e uno scopo. “Gestito dall’agenzia” non sostituisce la responsabilità interna: servono referente, accessi, contratto e procedura di uscita.

4. Collegare asset e dati

Per ogni sistema occorre sapere quali dati tratta, con quali altri servizi comunica e quali credenziali utilizza. La criticità di una landing senza dati non è quella di un portale clienti.

5. Definire lo stato

Produzione, test, dismesso, da verificare. Gli asset non più necessari vanno rimossi in modo controllato; quelli sconosciuti richiedono un’indagine prima di qualsiasi azione.

Campi minimi dell’inventario

• nome e identificativo tecnico;
• dominio, IP o tenant;
• ambiente e stato;
• servizio e dati trattati;
• responsabile interno e fornitore;
• tecnologia e versione, quando rilevabile;
• metodo di autenticazione;
• esposizione pubblica;
• dipendenze principali;
• ultimo controllo e prossima revisione.

Prioritizzare: non tutte le esposizioni sono uguali

Una lista di vulnerabilità senza contesto genera attività dispersive. La priorità può combinare:

• raggiungibilità: accessibile da Internet o limitato?
• impatto: quali dati e processi comprometterebbe?
• probabilità: esiste un difetto noto, una configurazione debole o un abuso frequente?
• privilegio: che cosa può fare un account compromesso?
• dipendenza: quanti sistemi sono collegati?
• rilevabilità: esistono log e allarmi affidabili?
• recuperabilità: backup e ripristino sono stati provati?

Un pannello amministrativo esposto con autenticazione debole può avere priorità maggiore di una vulnerabilità teorica in una pagina statica.

Le aree di rischio da controllare

Accessi e autorizzazioni

Account condivisi, utenti di ex collaboratori, ruoli eccessivi e assenza di autenticazione forte aumentano l’impatto. Broken Access Control resta una categoria centrale nei riferimenti OWASP.

Configurazioni

Directory pubbliche, bucket aperti, header assenti, servizi di debug e pannelli non limitati possono esporre informazioni o funzioni. La configurazione sicura deve essere ripetibile tra ambienti.

Catena di fornitura software

Plugin, pacchetti, immagini container, script esterni e pipeline possono introdurre codice non controllato. Inventario delle dipendenze, versioni, fonti e processi di aggiornamento riducono l’incertezza.

API e integrazioni

Token troppo potenti, endpoint non documentati e webhook senza verifica ampliano la superficie. Ogni integrazione dovrebbe applicare minimo privilegio, rotazione e logging.

Logging e allerta

Un evento non osservato prolunga il tempo di permanenza dell’attaccante. I log devono essere raccolti, protetti, correlabili e collegati a una procedura di risposta.

Un ciclo mensile per una PMI

1. esportare inventario di domini, cloud e account;
2. confrontare nuovi asset e variazioni;
3. controllare scadenze, versioni e accessi privilegiati;
4. verificare criticità aperte e tempi di correzione;
5. riesaminare fornitori e script esterni;
6. testare un allarme o un ripristino;
7. chiudere gli asset non più necessari.

Il controllo più profondo può essere trimestrale o legato a cambi significativi. L’importante è evitare che l’inventario diventi un file compilato una volta e mai più aggiornato.

KPI utili

• percentuale di asset con proprietario;
• asset pubblici non riconosciuti;
• tempo medio tra scoperta e classificazione;
• percentuale di servizi con autenticazione forte;
• vulnerabilità critiche oltre la scadenza;
• account privilegiati non riesaminati;
• backup con ripristino verificato;
• tempo tra variazione esterna e rilevamento.

Cosa fare quando emerge un asset sconosciuto

Non modificarlo o spegnerlo impulsivamente. Documentare dominio, IP, certificato, provider e segnali osservati; verificare proprietà e dipendenze; coinvolgere responsabili tecnici e, se necessario, legali o privacy. Solo dopo si decide se isolare, migrare o dismettere.

Se esistono indizi di compromissione, preservare log ed evidenze e attivare la procedura di risposta. La bonifica non deve cancellare le informazioni necessarie a capire causa e impatto.

Errori frequenti

• limitare l’inventario al sito principale;
• dimenticare staging, API e account SaaS;
• scansionare sistemi senza autorizzazione;
• ordinare le vulnerabilità solo per punteggio tecnico;
• non assegnare proprietari e scadenze;
• mantenere account di fornitori dopo la chiusura;
• confondere backup esistente con ripristino verificato.

Domande frequenti

La superficie d’attacco coincide con le vulnerabilità?

No. La superficie descrive punti e asset esposti; la vulnerabilità è una debolezza specifica. Ridurre la superficie può eliminare rischi anche prima di correggere singoli difetti.

Serve un software dedicato?

Non necessariamente per iniziare. Un inventario controllato e revisioni regolari sono già utili. Strumenti automatici diventano importanti quando asset e cambi superano la capacità manuale.

Chi deve possedere l’inventario?

Serve una responsabilità interna, anche quando l’operatività è affidata a un fornitore. IT, sviluppo, sicurezza, marketing e acquisti possono contribuire con fonti diverse.

Fonti

Contenuto verificato rispetto alle informazioni disponibili entro il 14 ottobre 2025. Riferimenti: OWASP Attack Surface Management Top 10, OWASP Top Ten e Agenzia per la Cybersicurezza Nazionale.

Vuoi mappare domini, servizi, accessi e dipendenze prima di decidere le priorità? Richiedi una valutazione tecnica del progetto digitale.