Sicurezza del software gestionale: cosa significa davvero

Tutte le software house possono dire che il loro software è sicuro. Noi preferiamo non farlo. "Sicuro" è un’affermazione assoluta che, nel software, ha poco senso: possiamo invece spiegare quali rischi consideriamo, quali barriere costruiamo, come manteniamo i sistemi nel tempo e cosa facciamo quando un test esterno ci dimostra che qualcosa può essere migliorato.

"Software sicuro" non significa invulnerabile

La sicurezza è gestione del rischio, non uno stato che si raggiunge una volta per tutte. Cambia con i dati trattati, con gli utenti che accedono, con l’esposizione su Internet, con la criticità del processo e con l’infrastruttura su cui il sistema gira. Un’applicazione sicura oggi non resta automaticamente sicura tra cinque o dieci anni: patching, manutenzione e aggiornamento sono parte della sicurezza tanto quanto la progettazione iniziale. Per questo il livello di protezione necessario va definito già nell’analisi dei requisiti, non aggiunto alla fine del progetto.

La sicurezza è un processo che non termina mai.

La prima domanda non è "quale firewall usate?"

Prima di progettare qualunque controllo tecnico, la nostra analisi dei requisiti cerca di capire alcuni elementi concreti: quali dati vengono trattati, chi vi accede e con quali ruoli, cosa deve essere raggiungibile da Internet e cosa no, quali integrazioni con sistemi esterni sono necessarie, quanto costa un fermo per quel processo specifico, chi amministra infrastruttura e applicazione, e quali obblighi contrattuali o normativi esistono. Non è un processo formale di threat modeling con una metodologia dedicata: fa parte, in modo strutturato, della normale analisi dei requisiti che precede ogni progetto.

Ridurre la superficie d’attacco

Uno degli insegnamenti più concreti che arrivano dai penetration test è che meno cose sono esposte, meno cose possono essere attaccate. I principi che seguiamo sono semplici da enunciare, meno semplici da applicare con costanza: esporre solo ciò che deve davvero essere raggiungibile da Internet, tenere i servizi interni interni, limitare gli ingressi applicativi, centralizzare i controlli di accesso, limitare filesystem e privilegi dell’application server ai soli permessi necessari, ridurre al minimo servizi e porte attivi. Quando un’applicazione non deve essere pubblica, la teniamo dietro VPN o intranet, non semplicemente "protetta da password".

L’identità è spesso più fragile del codice

Negli anni, tra gli episodi più frequenti che abbiamo incontrato non ci sono exploit sofisticati: sono credenziali condivise tra colleghi, password riutilizzate su più servizi, accessi mai revocati quando una persona cambia ruolo o lascia l’azienda, resistenza pratica all’autenticazione a più fattori, computer lasciati sbloccati, account amministrativi usati per operazioni quotidiane che non ne avrebbero bisogno, documenti scambiati fuori dai sistemi aziendali.

Sul lato applicativo lavoriamo su autenticazione solida, ruoli e autorizzazioni verificate lato server — mai fidandoci di controlli lato client — e sul principio del privilegio minimo: ogni utente vede e può fare solo ciò che gli serve davvero. L’architettura supporta l’autenticazione a più fattori dove appropriato o richiesto dal progetto; se e come attivarla dipende dalle esigenze specifiche del cliente. Ma anche il sistema più solido si affida a un presupposto: che le persone che lo usano proteggano le proprie credenziali. È una responsabilità che appartiene anche all’organizzazione, non solo al software.

Defense in depth

Il principio guida è che una singola barriera può fallire, e l’architettura deve limitare cosa succede dopo. Nella pratica questo significa combinare più livelli: un web application firewall come ulteriore filtro — non come soluzione alla vulnerabilità del codice — isolamento del database dal resto dell’infrastruttura, sandboxing applicativo, privilegio minimo su ogni componente, gestione centralizzata dei segreti, controlli sempre verificati lato server, logging delle operazioni rilevanti, scansione antivirus sui file caricati dagli utenti, backup e procedure di ripristino, patching regolare.

Siamo sviluppatori di software, non pretendiamo di essere una società specializzata in cybersecurity: per questo preferiamo affidarci a strumenti specialistici già maturi sul mercato, invece di provare a ricostruirli internamente.

Una storia reale: quando un penetration test ha trovato una vulnerabilità

Uno dei progetti più esigenti che abbiamo seguito è stato sottoposto a un assessment esterno molto rigoroso, comprensivo di penetration test. Il test ha rilevato vulnerabilità reali. Non le dettagliamo qui — pubblicare come sono state sfruttate non aiuterebbe nessuno, tranne chi volesse provarci altrove — ma il punto più importante non è la vulnerabilità in sé: alcuni dei problemi individuati non erano isolati al singolo progetto, erano sedimentati nel framework che usiamo su più clienti. Abbiamo passato oltre sei mesi a ripensare e aggiornare parti dell’architettura, non solo a correggere il finding puntuale. Le correzioni migliori vengono poi propagate progressivamente agli altri progetti che condividono lo stesso framework.

Quando un finding riguarda l’architettura, correggere il framework è più importante che correggere soltanto il singolo caso.

Cosa ci ha insegnato un assessment nel settore finanziario

Su un progetto inserito nella catena di fornitura del settore bancario abbiamo affrontato un penetration test e un assessment della supply chain che hanno riguardato applicazione, infrastruttura, stack tecnologico, hardening, documentazione, processi interni, formazione e affidabilità organizzativa del fornitore. È stata un’esperienza che ci ha mostrato con chiarezza qualcosa che nel software B2B si tende a sottovalutare: la sicurezza non è solo codice, è anche maturità organizzativa — processi documentati, formazione delle persone, capacità di rispondere in modo strutturato quando qualcosa viene richiesto.

La business logic si abusa anche senza bucare il codice

Abbiamo sviluppato diversi sistemi per concorsi a premio: registrazione utenti, codici prodotto, giochi, punteggi, verifica di eleggibilità, estrazioni. In questi contesti gli utenti hanno un incentivo economico concreto a manipolare il funzionamento del sistema per ottenere un vantaggio — non necessariamente attaccando il codice, ma sfruttando regole applicative non sufficientemente robuste: un controllo di eleggibilità aggirabile, una sequenza di azioni non prevista, un punteggio calcolato in modo manipolabile. È una lezione che ci portiamo dietro in ogni progetto: non si progetta assumendo che l’utente seguirà sempre il percorso previsto.

Un sistema può non essere tecnicamente compromesso e tuttavia essere manipolato sfruttando regole applicative non sufficientemente robuste.

Secret management

Le credenziali e le chiavi che un’applicazione usa per comunicare con altri sistemi non devono mai essere scritte direttamente nel codice. Dove appropriato, le gestiamo tramite servizi dedicati: sulle infrastrutture AWS utilizziamo strumenti come AWS Secrets Manager, con protezione tramite AWS KMS.

Upload sicuri

Quando un’applicazione accetta file caricati dagli utenti, definiamo i formati ammessi in base al caso d’uso specifico, gestiamo l’upload in un’area controllata separata dall’applicazione principale, e sottoponiamo i file a scansione antivirus prima di qualunque elaborazione successiva. Nessuna di queste misure, da sola, è una garanzia assoluta: sono livelli di controllo che si sommano.

Logging non è monitoring

Registriamo le operazioni rilevanti in modo da poter ricostruire modifiche e attività, e in alcuni sistemi rendiamo l’audit consultabile direttamente dagli amministratori del cliente. È utile per analizzare anomalie e per il debugging. Ma logging non significa monitoring: non disponiamo oggi di un sistema generalizzato di rilevamento comportamentale delle anomalie o di un SIEM integrato nel framework. È una distinzione che vale la pena fare esplicitamente, perché spesso viene data per scontata.

Chi è responsabile di cosa

La sicurezza di un sistema aziendale è quasi sempre una responsabilità condivisa tra soggetti diversi: applicazione, infrastruttura e organizzazione possono essere gestite da chi la sviluppa, dal cliente, o da terzi. Normalmente ci occupiamo noi dell’applicazione; su infrastrutture on-premises la gestione di server, firewall e sistema operativo è spesso in capo al cliente o al suo fornitore IT; su infrastrutture cloud gestite possiamo occuparcene direttamente. In ogni caso, prima di iniziare un progetto è importante definire chiaramente chi presidia cosa — non per scaricare responsabilità, ma perché una zona grigia su questo punto è essa stessa un rischio.

Non tutte le applicazioni hanno lo stesso livello di rischio

Quando ragioniamo sulla sicurezza di un progetto distinguiamo tre livelli, che si sommano l’uno all’altro:

1. 1

   Baseline applicativa

   Le buone pratiche condivise dal nostro framework e dalla nostra architettura, presenti per default su ogni progetto.

2. 2

   Hardening aggiuntivo

   Controlli proporzionati ai dati trattati, all’esposizione, al rischio specifico e a eventuali requisiti normativi del settore.

3. 3

   Livello di servizio

   Infrastruttura dedicata, ridondanza, backup e disaster recovery, tempi di intervento concordati.

Sono elementi che si discutono progetto per progetto, in base a cosa serve davvero — non un pacchetto standard uguale per tutti.

I limiti che dichiariamo

La sicurezza richiesta a una piattaforma per una PMI non è necessariamente la stessa richiesta a un’infrastruttura finanziaria critica. Il nostro compito è capire il livello necessario e verificare se siamo organizzativamente e tecnicamente in grado di presidiarlo. Se un progetto richiede un livello di sicurezza superiore alle nostre capacità organizzative, preferiamo dichiararlo apertamente — e, quando serve, non assumere il progetto — piuttosto che promettere qualcosa che non possiamo garantire fino in fondo.

Perché ve lo raccontiamo così

Non vi diremo mai che un software è sicuro in assoluto. Possiamo dirvi quali rischi consideriamo, come li riduciamo, e cosa facciamo quando un test esterno ci dimostra che qualcosa può essere migliorato. È lo stesso approccio con cui manteniamo software aziendale reale da oltre vent’anni: la sicurezza non è una casella da spuntare all’inizio del progetto, è una responsabilità che si accompagna nel tempo, insieme al software stesso.