Offensive security: verificare una difesa attaccandola

Esistono due modi per sapere se le difese di un’azienda funzionano. Il primo è leggere: le configurazioni, le policy, gli inventari, i documenti. Il secondo è provare ad aggirarle.

L’offensive security è il secondo.

Non è una filosofia né un cambio di paradigma. È un metodo di verifica, con una premessa molto concreta: una difesa che non è mai stata messa alla prova è una difesa che nessuno ha verificato. Funziona sulla carta, e sulla carta funzionano quasi tutte.

1. Che cos’è l’offensive security
2. Da dove viene
3. Le attività che la compongono
4. In cosa si distingue dalla sicurezza difensiva
5. Cosa produce davvero
6. Quando serve a un’azienda

Che cos’è l’offensive security

L’offensive security, o sicurezza offensiva, raccoglie le attività che verificano la tenuta di un sistema informatico cercando attivamente il modo di violarlo. Gli analisti usano le stesse tecniche di chi attacca per davvero, entro un perimetro concordato e con un’autorizzazione formale.

La definizione è semplice. Quello che cambia le cose è la conseguenza.

Un audit documentale dice se una misura è prevista. Un’attività offensiva dice se quella misura regge. Sono due informazioni diverse, e nei nostri rilievi la seconda smentisce la prima con una certa regolarità.

Un esempio ricorrente. Un’azienda ha l’autenticazione a più fattori attiva su tutti gli account: la policy lo prevede, il gestionale lo conferma, l’auditor lo spunta. Poi si prova, e si scopre che un protocollo di posta rimasto attivo per compatibilità permette di autenticarsi con la sola password. La misura esiste. Non copre.

Da dove viene

L’approccio non nasce nell’informatica. Nasce in ambito militare, con i gruppi incaricati di attaccare le difese della propria organizzazione per trovarne i punti deboli prima che lo facesse un avversario.

Da lì è passato ai sistemi informatici negli anni Settanta, quando le prime valutazioni di sicurezza su sistemi governativi statunitensi vennero affidate a squadre che dovevano provare a violarli. Il nome che si è consolidato per quelle squadre è red team, in contrapposizione al blue team che difende.

La divisione ha retto fino a oggi e ha prodotto un terzo termine, purple team, che indica il lavoro congiunto: chi attacca condivide in tempo reale cosa ha funzionato, chi difende corregge mentre l’attività è in corso.

Questa storia conta per un motivo pratico. L’offensive security non è un approccio alternativo alla difesa: è il modo in cui la difesa si verifica. Le due cose stanno nella stessa frase, non in competizione.

Le attività che la compongono

Sotto questo termine stanno attività diverse, con obiettivi e profondità diverse. Confonderle è l’errore più comune in fase di acquisto, perché si finisce per comprare qualcosa che risponde a un’altra domanda.

La distinzione fra le prime due è quella che conta di più, e va chiarita perché circola una definizione sbagliata. Si sente dire che il vulnerability assessment sia una scansione automatica e il penetration test un’attività manuale. Non è così, o almeno non dovrebbe esserlo.

Uno strumento di scansione produce un elenco grezzo, che contiene duplicati, segnalazioni non pertinenti e vulnerabilità non applicabili alla configurazione reale. Quell’elenco non è un vulnerability assessment: è la materia prima. L’assessment è quello che viene dopo, quando un analista verifica ogni segnalazione rilevante e stabilisce la priorità nel contesto dell’azienda.

Su questo abbiamo scritto in modo esteso a proposito dei limiti degli assessment automatici, perché è il punto in cui la stessa etichetta copre due servizi molto diversi.

La differenza vera fra assessment e penetration test è un’altra: il primo dice dove sono le porte, il secondo dice cosa c’è dietro.

In cosa si distingue dalla sicurezza difensiva

La sicurezza difensiva costruisce e presidia: firewall, controllo degli accessi, segmentazione, rilevamento, risposta. Lavora per impedire che qualcosa accada e per accorgersene quando accade.

L’offensive security non costruisce niente. Serve a rispondere a una domanda che la difesa non può porsi da sola: questo che ho costruito, tiene?

La differenza operativa sta nel punto di vista. Chi difende ragiona per copertura: ho protetto tutto? Chi attacca ragiona per percorso: mi basta un punto. E un percorso si trova concatenando debolezze che, prese una per una, sembrano irrilevanti.

Questo è anche il motivo per cui l’attività va fatta da qualcuno esterno a chi ha costruito i sistemi. Non per sfiducia: perché chi ha progettato una difesa conosce l’intenzione del progetto, e l’intenzione è precisamente quello che un attaccante non conosce e non rispetta.

C’è poi un aspetto di metodo che merita una precisazione. Le attività offensive si svolgono su un perimetro definito per iscritto, con un’autorizzazione formale e condizioni di arresto concordate. Senza quel quadro non si tratta di offensive security: si tratta di un accesso non autorizzato, e la differenza è giuridica prima che tecnica.

Cosa produce davvero

L’esito di un’attività offensiva è un documento, e vale la pena capire cosa deve contenere perché la qualità dei report varia enormemente.

Un report utile riporta il perimetro su cui si è lavorato, il periodo, le vulnerabilità individuate con la loro gravità, le evidenze raccolte, e il percorso seguito quando si è arrivati da qualche parte. Soprattutto riporta le indicazioni di remediation in un ordine che tenga conto di quanto l’azienda può fare nelle prossime settimane.

Un report che elenca quaranta rilievi tutti urgenti non è un report: è un elenco. Chi lo riceve lo legge, si spaventa alle prime righe e poi lo archivia. Il tema è approfondito nell’articolo su severity e priorità reale.

C’è poi un uso del report che negli ultimi anni è diventato il primo per frequenza, e non riguarda la tecnica. Sempre più spesso quel documento serve a dimostrare qualcosa a qualcun altro: a un cliente che chiede garanzie in fase di qualifica, a un auditor, a un’autorità di controllo.

Per i soggetti che rientrano nella direttiva NIS 2 la verifica periodica della sicurezza è fra le misure di base da avere operative entro il 31 ottobre 2026, e quello che l’ACN verificherà sono le evidenze: documenti con una data, un perimetro e un esito.

Quando serve a un’azienda

Non serve sempre, e non serve tutto. Le situazioni in cui un’attività offensiva produce valore sono ricorrenti.

Quando è cambiato qualcosa di rilevante: un nuovo servizio esposto su internet, una migrazione, l’integrazione di un’infrastruttura acquisita. La configurazione precedente era stata verificata, quella nuova no.

Quando un cliente o un capitolato lo richiede. In quel caso la domanda non è se serva, ma cosa deve contenere il documento per essere accettato.

Quando c’è una scadenza normativa. È il caso più frequente in questo periodo, e ha una data precisa.

E quando si sospetta di avere già subito un accesso non autorizzato. Lì l’attività offensiva serve a capire da dove si entra, che è la domanda preliminare a qualsiasi altra.

Non serve, invece, come primo passo assoluto. Se un’azienda non ha ancora chiaro cosa possiede e cosa è raggiungibile, il punto di partenza è l’inventario degli asset: non si testa quello che non si sa di avere.

Resta un ultimo punto, e riguarda la parte che nessuna attività tecnica copre. La via d’ingresso più usata negli attacchi reali non è una vulnerabilità: è un messaggio che qualcuno apre. Un’attività offensiva la verifica solo se il perimetro concordato comprende anche le persone.