Perché pagare per essere attaccati non è un controsenso
Un'applicazione in produzione — un sito che raccoglie contatti, un gestionale, un portale dove i clienti accedono con una password — è esposta a chiunque, in ogni momento. La domanda non è se qualcuno proverà a trovarne i difetti: è se lo scoprirete prima voi o prima loro. Un test di sicurezza autorizzato è il modo di arrivare primi. Pagate qualcuno perché faccia, con il vostro permesso e senza fare danni, esattamente ciò che un estraneo farebbe senza permesso e senza riguardo.
Cosa trova uno strumento automatico, e cosa no
Esistono strumenti che analizzano un'applicazione da soli e segnalano i problemi. Sono utili, li usiamo, e una parte del lavoro comincia da lì. Ma vedono una sola categoria di difetti: quelli già catalogati. Una libreria con una falla pubblicata, una configurazione lasciata aperta, una porta che non doveva restare accessibile. Tutte cose reali, tutte importanti — e tutte che chi vi attacca conosce già, perché legge lo stesso elenco pubblico.
| Cosa trova lo strumento | Cosa trova solo una persona |
|---|---|
| Una libreria non aggiornata con falla nota | Uno sconto che si può applicare due volte |
| Una configurazione del server sbagliata | Un ordine modificabile dopo il pagamento |
| Una password di default mai cambiata | Un cliente che, cambiando un numero nell'indirizzo, apre i documenti di un altro cliente |
| Un certificato scaduto | Un utente normale che raggiunge una funzione da amministratore |
La colonna di destra non contiene difetti tecnici: contiene difetti di significato. Nessuno strumento li trova, perché per accorgersene bisogna sapere cosa quell'applicazione dovrebbe fare — e quindi averne costruite di simili.
È qui che sta la ragione per cui questo lavoro lo facciamo noi con una certa serenità: costruiamo gestionali, portali clienti ed e-commerce con listini diversi per ogni cliente. Sono esattamente i sistemi in cui i difetti della colonna di destra sono più frequenti e più costosi. Non guardiamo la vostra applicazione come un enigma da forzare, ma come un tipo di software di cui conosciamo già i punti in cui di solito è sbagliato.
Il motivo per cui non è più rimandabile: lo dice la legge
Molte aziende trattano il test di sicurezza come una spesa da fare «quando ci sarà tempo». Chi tratta dati personali in un'applicazione — cioè chiunque abbia anche solo un modulo contatti o un'area con login — ha in realtà un obbligo di legge che raramente conosce.
Fra le misure adeguate a garantire la sicurezza rientra «una procedura per testare, verificare e valutare regolarmente l'efficacia delle misure tecniche e organizzative al fine di garantire la sicurezza del trattamento».
Regolamento UE 2016/679 (GDPR), art. 32, par. 1, lett. d
La parola che conta è «regolarmente». Il regolamento non chiede di avere un firewall: chiede una procedura ripetuta nel tempo per verificare che le difese funzionino davvero. Un test di sicurezza è il modo più diretto di soddisfare questa richiesta, ed è documentabile: la relazione finale è la prova, davanti a un cliente o a un'autorità, che la verifica è stata fatta.
La sola cosa che separa un test da un reato
Entrare in un sistema informatico senza il permesso di chi lo possiede è un reato, previsto dall'art. 615-ter del codice penale, e lo è a prescindere dalle intenzioni e dal fatto che si sia fatto o no un danno. Un test di sicurezza fa le stesse cose, ma è legale per una ragione sola: l'autorizzazione scritta di chi possiede il sistema. Non è un cavillo burocratico, è il confine.
Cosa deve esistere prima che chiunque tocchi la vostra applicazione
- Un'autorizzazione scritta di chi ha titolo a concederla per la vostra azienda.
- Il perimetro esatto: quali indirizzi e quali sistemi sono compresi, e quali no.
- La finestra temporale in cui il test può avvenire.
- Un contatto raggiungibile durante il test, per fermare tutto se qualcosa va storto.
- L'avviso al fornitore del server o del cloud, che nel suo contratto lo richiede a prescindere dal vostro.
Se un fornitore vi propone di «dare un'occhiata» senza mettere per iscritto queste cose, sta proponendovi di fare insieme qualcosa di irregolare. Un fornitore serio insiste per avere l'autorizzazione prima di voi.
Le quattro prove diverse, per quattro paure diverse
«Testare la sicurezza» significa cose diverse a seconda di cosa vi tiene svegli. Vale la pena sapere quali sono, perché chi ne compra una sola spesso compra quella sbagliata.
- 01
Qualcuno entra dove non deve
È il test di sicurezza applicativo: si prova a entrare, a vedere dati altrui, a fare cose che il proprio ruolo non permette. Risponde alla domanda «la mia app è sicura?».
- 02
Troppa gente arriva insieme e il sito cade
È il test di carico: si simula un numero crescente di utenti fino a trovare il punto in cui il sistema cede. Risponde alla domanda «quanto traffico regge?».
- 03
L'assistente AI dice quello che non deve
È il test degli assistenti conversazionali: si prova a fargli rivelare istruzioni o dati che dovrebbe tenere per sé. Una famiglia di problemi nuova, che gli strumenti classici non coprono.
- 04
Un cliente grande vi manda il suo questionario di sicurezza
È l'assessment di postura: si mettono in ordine le risposte da dare, e si interviene dove oggi non si potrebbero dare vere. Nasce da una scadenza esterna, non da una curiosità.
Dove il fai da te arriva, e dove si ferma
Alcune verifiche potete e dovreste farle da soli: costano solo tempo e dicono molto. Su questo sito trovate le istruzioni passo per passo per controllare se un cliente può vedere i dati di un altro e per misurare quanto traffico regge il vostro sito, entrambe eseguibili sul vostro sistema in un pomeriggio. Servono a due cose: a trovare i problemi più comuni, e a capire se avete davanti qualcuno che sa di cosa parla.