Sicurezza Web

Lavoro su standard pubblici e verificabili, non su una metodologia proprietaria. Il riferimento è la OWASP Web Security Testing Guide per la conduzione dei test, l'Application Security Verification Standard per i requisiti di sicurezza applicativa e la OWASP Top 10 come base di classificazione delle categorie di rischio.

Il vantaggio pratico è che il perimetro di quello che è stato verificato è dichiarabile e confrontabile: puoi sapere quali controlli sono stati eseguiti e quali no, invece di ricevere un giudizio complessivo non tracciabile.

I test si svolgono in modalità black box, senza informazioni preliminari, grey box, con credenziali e conoscenza parziale del sistema, oppure white box, con accesso al codice sorgente. La modalità cambia sensibilmente ciò che è possibile trovare a parità di tempo speso: il black box riproduce il punto di vista dell'attaccante esterno, il white box trova molto di più ma richiede che tu apra il repository.

Il perimetro coperto comprende applicazioni web, API REST e GraphQL, applicazioni mobile e infrastruttura esposta su internet.

Sull'analisi statica del codice uso SonarQube e Trivy, quest'ultimo anche per la scansione delle immagini container e delle dipendenze. Per il secret scanning uso gitleaks, che è il modo più diretto per scoprire credenziali finite nella storia del repository e mai rimosse davvero.

Sull'analisi dinamica uso OWASP ZAP contro l'applicazione in esecuzione. Gli strumenti automatici sono il punto di partenza, non il risultato: servono a coprire in fretta il terreno noto e a liberare tempo per la verifica manuale, che è dove si trovano i problemi di logica applicativa.

Il deliverable è la parte su cui i clienti decidono, e per questo è definito in modo esplicito. Ricevi un executive summary non tecnico, leggibile da chi deve autorizzare la spesa delle remediation senza conoscere il dettaglio implementativo.

Accanto a questo c'è il report tecnico, dove ogni finding è accompagnato da una proof of concept riproducibile, dalla classificazione CWE e dal punteggio CVSS. Una vulnerabilità che non si riesce a riprodurre non è una vulnerabilità dimostrata, ed è per questo che le PoC sono parte del report e non un allegato opzionale.

Segue un piano di remediation prioritizzato, perché l'ordine in cui si sistemano le cose conta quanto la lista stessa. E infine il retest dopo le fix è incluso: verificare che la correzione abbia davvero chiuso il problema, e che non ne abbia aperto un altro, fa parte del lavoro e non è un secondo intervento da acquistare.

Sul GDPR mi occupo esclusivamente degli aspetti tecnici: cifratura, controllo degli accessi, gestione e conservazione dei dati, tracciamento delle operazioni.

La parte documentale e legale, dal registro dei trattamenti alle informative, non rientra nel servizio. Anche qui vale il principio di dichiararlo prima: è una competenza legale, e va affidata a chi la esercita.