Superficie d'attacco (informatico)
La "superficie d'attacco" è l'insieme dei possibili punti di un software/sistema/infrastruttura che sono più o meno accessibili da un eventuale attaccante. E' fondamentale quindi conoscere e gestire la superficie d'attacco della nostra infrastruttura informatica.
La prima azione da fare è quella di individuare i servizi disponibili dal sistema che stiamo studiando. Questo ovviamente va fatto verificando quelli che sono veramente attivi sul sistema. Inoltre, vanno considerati tutti quei servizi che non sono in ascolto diretto (come potrebbe fare, ad esempio, un server web su una porta TCP), ma anche quei servizi che si connettono verso l'esterno del sistema o che comunque interagiscono in qualche modo in base al traffico che transita sulla scheda di rete (ad esempio, se abbiamo sistemi che passivamente monitorizzano la scheda di rete per statistiche sui flussi, dobbiamo considerare anche quei servizi). Se il sistema è dotato di firewall, IDS o IPS, anche questi vanno considerati come servizi.
Per ognuno di questi servizi, dobbiamo individuare i possibili flussi dati, individuando ogni dispositivo (router, firewall hardware/software, etc) che si pone tra l'eventuale attaccante ed il nostro sistema. Poiché gli attacchi possono arrivare da più punti (internet, altri server, client aziendali, etc) è necessario quindi dividere l'esame in più sezioni, ognuna con la specifica della porzione di superficie esposta. Questo ci permette di individuare correttamente quali servizi sono esposti rispetto a quale "area" esterna al nostro sistema (è possibile infatti che un servizio non sia esposto perché un firewall è configurato per bloccarlo).
A questo punto, per ogni servizio, dobbiamo individuare le possibilità che offre ad un attaccante in termini di:
- Information disclosure: dobbiamo valutare quante informazioni il servizio espone (con o senza richieste dirette da parte del client); ad esempio, un server web potrebbe esporre la versione e le librerie compilate (esempio da una pagina di errore di un sito internet):
Apache/2.2.9 (Debian) PHP/5.2.6-1+lenny16 with Suhosin-Patch mod_ssl/2.2.9 OpenSSL/0.9.8g Server at www.website.it Port 443
Ovviamente tali informazioni sono eccessive: un attaccante può determinare le vulnerabilità molto più facilmente.
- Authentication bypass: valutare quanto il sistema è robusto in termini di controllo di autenticazione (per questo ci possono essere utili le CVE presentate sotto)
- Denial of service (DoS): quali sono le opzioni lasciate ad un attaccante nel momento in cui il servizio è non disponibile (ad esempio, se al fallimento di un servizio viene aperta una porta o viene lanciato un automatismo che aumenta o cambia la superficie d'attacco, ad esempio lanciando un altro software)
- Remote code execution (RCE): in caso di RCE, quali sono le possibilità che ha un attaccante di eseguire delle azioni utilizzando, come "ponte", il servizio: se il suddetto servizio gira con un utente, ogni cosa che può fare quell'utente (eliminare/creare file, aprire connessioni, etc) fa parte della superficie d'attacco in caso di RCE
- CVEs: sono bollettini per la sicurezza. E' fondamentale controllare se le versioni dei software utilizzate nei sistemi hanno vulnerabilità già note. Le vulnerabilità note cambiano notevolmente il "peso" di una singola componente del sistema nella superficie di attacco, poiché la documentazione sulla vulnerabilità ora è disponibile al pubblico.
Infine, individuata l'ampiezza della superficie e gli attori in essa, dobbiamo stabilire:
- Le regole corrette in base a quelle che sono le reali necessità (ad esempio, eliminare la possibilità di accesso ad un servizio da una zona che non ne ha bisogno) usando il principio di least privilege: consentire solo i servizi necessari (bloccando il resto) al minimo livello di accesso possibile.
- Le regole per limitare il "danno" causato da uno dei punti appena visti (RCE, DoS, etc.), posizionando firewall applicativi, sistemi di contenimento, etc.
La complessità di tutto questo può sembrare eccessiva per lo status quo in una azienda, ma la regola d'oro è sempre di considerare questo "costo" (anche in termini di tempo) un investimento rispetto al costo della perdita catastrofica dei dati e dei sistemi (causata da un attaccante). In altre parole, dobbiamo investire in sicurezza tanto quanto siamo disposti a pagare per riavere indietro tutti i dati (e l'infrastruttura) qualora venisse presa in ostaggio da un malvivente.