Application Security Assessment su cui contare.

Un vulnerability assessment cerca debolezze note, soprattutto con scanner automatici, e ne restituisce l'elenco. Un penetration test fa un passo in più: il tester prova a sfruttare le vulnerabilità che trova, combina tra loro anche quelle che da sole sembrano poco gravi e fa leva sugli errori nella logica dell'applicazione, per mostrare fin dove potrebbe spingersi un attaccante reale. Gli scanner difficilmente rilevano problemi di controllo degli accessi o di business logic, per questo nei nostri assessment sono solo un punto di partenza: ogni vulnerabilità riportata nel report viene verificata manualmente.

Un penetration test cerca quante più vulnerabilità possibile entro un ambito definito, come un'applicazione o una rete. Il red teaming mette alla prova l'organizzazione nel suo insieme: oltre a trovare i punti deboli, mostra se un attacco in corso viene rilevato e fermato. Conviene quando le applicazioni principali sono già state testate e c'è un monitoraggio attivo; prima, un penetration test rende di più a parità di impegno.

Le applicazioni web vengono testate secondo la OWASP Web Security Testing Guide (WSTG), le app mobile secondo la OWASP Mobile Application Security Testing Guide (MASTG). Per le API affianchiamo alla WSTG i requisiti dell'OWASP Application Security Verification Standard (ASVS). Per l'IoT usiamo la OWASP IoT Security Testing Guide; le integrazioni AI e LLM vengono verificate rispetto alla OWASP Top 10 for LLM Applications. Gli assessment di rete seguono la NIST SP 800-115 e il Penetration Testing Execution Standard (PTES). Alla metodologia aggiungiamo test complementari, sia lato client sia lato server, pensati per individuare le tipologie di vulnerabilità più recenti. Quando il client comunica con un back-end, che si tratti di un front-end web, di un'app mobile o di un'applicazione desktop, l'assessment comprende anche le relative API. Il lavoro è svolto manualmente, con strumenti proprietari di BeDefended e di terze parti, open source e commerciali, così il risultato non dipende da ciò che vede un singolo tool.

Per il penetration test il team ha OSCP, OSCP+, eCPPT ed eJPT (reti e infrastrutture), OSWE, GWAPT ed eWPT (applicazioni web), OSWP (reti wireless), CRTO (red teaming) e C-AI/MLPen (sistemi di AI e machine learning). L'elenco completo, che comprende anche cloud e sviluppo sicuro, è nella pagina Chi siamo.

Dipende da cosa vuoi scoprire. Il black box mostra cosa vede un attaccante esterno, senza credenziali. Il gray box, con un account di test per ogni ruolo utente, è l'approccio che di solito consigliamo per le applicazioni, perché molte delle vulnerabilità più gravi si trovano nelle aree accessibili solo dopo il login. Il white box aggiunge il codice sorgente con una secure code review e fa emergere problemi difficili da individuare dall'esterno, come backdoor o codice malevolo.

Un report scritto e approvato dai tester che hanno svolto l'attività. Si apre con un executive summary per il management, poi descrive ogni vulnerabilità verificata con lo scoring CVSS, le evidenze necessarie a riprodurla (un proof of concept funzionante quando è sfruttabile) e indicazioni di remediation concrete. Ripercorriamo i risultati con il tuo team e lo affianchiamo mentre corregge le vulnerabilità. Una volta applicate le correzioni, un retest verifica che ogni problema sia stato risolto.

Durata e costo dipendono dal perimetro: quante applicazioni, ruoli utente, funzionalità ed endpoint API sono coinvolti, e su quali piattaforme. Una piccola applicazione web può richiedere pochi giorni, mentre una piattaforma ampia con app mobile e API richiede più tempo. Dopo una breve call di scoping ti inviamo un preventivo con l'impegno in giornate/uomo e concordiamo con te la finestra di test, così costi e tempi sono chiari prima di iniziare.

Un ambiente di staging che replica la produzione è la scelta più prudente, ma si può testare anche in produzione: concordiamo le finestre temporali, escludiamo i test distruttivi e chiediamo che un referente del tuo team resti reperibile durante il test. Per iniziare ci servono il perimetro (URL, app o range IP), un account di test per ogni ruolo, la documentazione delle API se disponibile e, per le app mobile, le build da testare. Prima di cominciare firmiamo un NDA e un accordo sul trattamento dei dati, e tu ci autorizzi per iscritto a eseguire i test. Se alcuni sistemi sono gestiti da terzi, come un hosting o un SaaS, serve anche il via libera del fornitore, a meno che le sue regole non ammettano già i test: è il caso di AWS, Azure e Google Cloud, entro certi limiti.

Fornisce un'evidenza, ma da solo un report non rende conformi. La NIS2 (articolo 21), recepita in Italia con il D.Lgs. 138/2024 (articolo 24), richiede ai soggetti essenziali e importanti di adottare politiche e procedure per valutare l'efficacia delle proprie misure di gestione dei rischi per la sicurezza informatica e di gestire le vulnerabilità dei sistemi che acquisiscono, sviluppano e mantengono. Il regolamento DORA, all'articolo 25, include il penetration test tra le verifiche che un'entità finanziaria deve prevedere, ove opportuno, nel proprio programma di test di resilienza operativa digitale. Il PCI DSS chiede penetration test interni ed esterni almeno ogni 12 mesi e dopo ogni modifica significativa (requisiti 11.4.2 e 11.4.3). I nostri report sono pensati per essere consegnati a un auditor.