La metodologia OSSTMM spiegata

I test di sicurezza senza un linguaggio condiviso su come si misura il rischio producono report che sembrano approfonditi e lasciano comunque i team nell’incertezza. L’Open Source Security Testing Methodology Manual (OSSTMM) è stato creato per risolvere questo problema: un approccio scientifico e basato su metriche al testing della sicurezza operativa, che privilegia ciò che si può verificare, non ciò che si assume.

Questo articolo spiega cos’è OSSTMM, come funzionano i suoi concetti chiave e come i team di sicurezza possono usarlo insieme al monitoraggio continuo moderno e ad altre metodologie.

Cos’è OSSTMM e perché conta

OSSTMM è una metodologia peer-reviewed gestita dall’Institute for Security and Open Methodologies (ISECOM). A differenza degli audit basati su checklist che valutano i controlli come “presenti” o “assenti”, OSSTMM si concentra sulla sicurezza operativa: come i canali di interazione (persone, processi, tecnologia, accesso fisico, wireless e così via) si comportano realmente sotto test.

Il suo valore per i professionisti è triplice:

• Ripetibilità. I test seguono un processo definito, così i risultati possono essere confrontati nel tempo.
• Misurabilità. OSSTMM introduce concetti quantitativi (in particolare i RAV — Risk Assessment Values) affinché i finding non siano solo narrazioni qualitative.
• Chiarezza di scope. Obbliga a definire cosa viene testato, attraverso quali canali e sotto quali regole di engagement prima di iniziare.

Per le organizzazioni che trattano ancora il penetration test come uno snapshot annuale, OSSTMM è un utile richiamo: la postura di sicurezza cambia continuamente—e un singolo esercizio puntuale è solo un dato in un quadro operativo più lungo.

Framework centrale: canali, controlli e fiducia

Canali di sicurezza

OSSTMM organizza i test intorno ai canali—percorsi attraverso i quali esiste interazione (e quindi superficie di attacco). I raggruppamenti classici di canale includono:

| Focus del canale | Esempi di cosa si testa | |---|---| | Umano | Social engineering, aderenza ai processi, awareness | | Fisico | Facility, badge, accessi ambientali | | Wireless | RF, Wi‑Fi, Bluetooth, segnali correlati | | Telecomunicazioni | Voce, PSTN, circuiti correlati | | Reti dati | Reti IP, applicazioni, servizi | | Altri definiti in scope | Cloud, API, terze parti (come da scope) |

Definire i canali in anticipo evita il fallimento comune di “abbiamo scansionato la rete” ignorando i percorsi umani o fisici che aggirano quei controlli.

Controlli e limitazioni

OSSTMM classifica i controlli (autenticazione, non ripudio, riservatezza, privacy, integrità, allarme, autorizzazione e concetti correlati) e tratta le limitazioni—vincoli che riducono l’efficacia di quei controlli—come elementi di prim’ordine. Un controllo che esiste sulla carta ma è limitato da misconfigurazione, copertura incompleta o scorciatoie operative non è lo stesso di un controllo che funziona in condizioni operative.

Fiducia e verifica

Un’idea centrale di OSSTMM è che la fiducia deve essere verificata. Le assunzioni su chi o cosa è affidabile—utenti interni, reti partner, zone “sicure”—diventano target di test espliciti. Quella mentalità si allinea bene a Zero Trust moderno e ai programmi di esposizione continua: non assumere; misura.

Il processo OSSTMM in pratica

Sebbene i team adattino il manuale al proprio ambiente, un engagement allineato a OSSTMM in genere include:

1. Definire scope e canali. Asset, interazioni e confini del test.
2. Stabilire le regole di engagement. Cosa è consentito, quando e con quali vincoli di sicurezza.
3. Eseguire test operativi. Interagire con il target attraverso i canali definiti; verificare controlli e limitazioni.
4. Misurare e calcolare. Catturare i finding in una forma che supporti la quantificazione in stile RAV quando la metodologia è applicata plenamente.
5. Reportare in modo operativo. Descrivere cosa è stato verificato, cosa è fallito sotto test e il rischio operativo residuo—non solo un dump di CVE.

La metodologia è intenzionalmente rigorosa. Il calcolo RAV completo non è sempre richiesto in ogni engagement commerciale, ma la disciplina di definizione dei canali, verifica dei controlli e sfida alla fiducia resta utile anche quando si adatta la profondità a tempo e budget.

OSSTMM rispetto ad altre metodologie

I team di sicurezza chiedono spesso come OSSTMM si relazioni a PTES, alle guide OWASP o a MITRE ATT&CK.

• PTES enfatizza un chiaro ciclo di esecuzione per i penetration test (dalla raccolta di intelligence al reporting). OSSTMM enfatizza la misurazione scientifica della sicurezza operativa.
• OWASP (e guide app-sec correlate) approfondiscono classi di debolezza di applicazioni e API. OSSTMM è più ampio tra i canali, inclusi umano e fisico.
• MITRE ATT&CK mappa comportamenti e tecniche dell’avversario. OSSTMM aiuta a strutturare come si testa e si misura; ATT&CK aiuta a descrivere cosa fanno gli attaccanti.

Nella pratica, i programmi maturi li combinano: ATT&CK per realismo avversariale, PTES per il flusso dell’engagement, OSSTMM per disciplina di verifica e metriche operative.

Takeaway pratici per i team di sicurezza

1. Scrivi i canali nel SOW. Se lo statement of work dice solo “pentest esterno”, non hai fatto scoping in stile OSSTMM. Nomina canali di rete, app, identity, umani e fisici dove applicabile.
2. Testa i controlli in condizioni operative. Una regola WAF che esiste non è la stessa di una regola WAF che blocca il percorso di attacco che ti interessa.
3. Tratta i confini di fiducia come oggetti di test. VPN partner, tenancy condivisa e ruoli privilegiati meritano verifica esplicita.
4. Preferisci i trend agli score una tantum. Che tu usi RAV o modelli di severità più semplici, confronta i risultati tra engagement. Monitoraggio continuo e test ricorrenti battono un singolo snapshot annuale.
5. Allinea il reporting alle decisioni. Gli executive hanno bisogno di rischio operativo residuo e remediation prioritizzata; gli engineer hanno bisogno di passi riproducibili e impatto verificato.

Concetti correlati

• Rules of engagement (RoE) — guardrail legali e operativi per i test.
• RAV (Risk Assessment Values) — approccio di scoring quantitativo di OSSTMM.
• Attack surface / exposure management — discovery continua di ciò con cui si può interagire, complementare ai test periodici guidati da metodologia.
• Metodologie di penetration testing — PTES, OWASP Testing Guide, NIST SP 800-115 e altre usate insieme a OSSTMM.

Conclusione

OSSTMM resta una delle metodologie aperte più rigorose per il testing della sicurezza operativa perché insiste su canali, controlli verificati e outcome misurabili. Usala per alzare la qualità di scoping e verifica—anche quando la combini con PTES per il processo o ATT&CK per il contesto avversariale. L’obiettivo non è la purezza metodologica; è evidenza ripetibile che le tue difese funzionano come pensi che funzionino, in modo continuo—non solo nel giorno in cui è stato preso lo snapshot.