Pagina 1 di 2
Incident response è la disciplina che si attiva quando le difese hanno già fallito: un ransomware, un data breach, un sito compromesso, un account amministrativo rubato. La qualità della reazione nei primi minuti e nelle prime ore determina la dimensione del danno. Lavoro con PMI che hanno subito incidenti di sicurezza, aiutandole a contenere, analizzare e ricostruire.
In questa categoria scrivo di procedure di incident response: contenimento iniziale, isolamento dei sistemi compromessi, raccolta delle evidenze (senza distruggerle), analisi forense di base, eradicazione della minaccia, ripristino controllato, lessons learned strutturate. Parlo anche di cosa andrebbe fatto prima: runbook, comunicazioni predefinite, catena di comando chiara.
Se la tua azienda ha subito o sospetta di aver subito un incidente di sicurezza, contattami subito. Se invece vuoi prepararti in anticipo — che è la scelta saggia — scopri come lavoro sui piani di risposta.
Nell'incident response la prima vittima è spesso la lucidità. Il secondo livello di difesa di un'azienda è avere al tavolo qualcuno che l'ha già vissuto.
Ho simulato uno scenario ransomware per un cliente manifatturiero con 60 dipendenti: ho mappato tutti i sistemi critici, calcolato il costo orario del downtime e testato i backup. I risultati erano scomodi: 18 ore per ripristinare i sistemi principali, 40 ore per i secondari, backup di tre settimane fa. Ecco cosa abbiamo fatto. Continua a leggere
Dopo la compromissione di un'applicazione Laravel, il cliente voleva sapere come erano entrati e cosa avevano preso. Ho ricostruito la kill chain completa dai log di Nginx, PHP, MySQL e dal filesystem: webshell caricata tramite IDOR + unrestricted upload, backdoor persistente in un file di configurazione. Vi mostro il metodo. Continua a leggere
Alle 2 di notte, un cliente mi chiama: il suo VPS ha comportamenti anomali. Nei successivi 30 minuti, ho fatto un elenco di azioni in ordine preciso. Quell'ordine è importante: sbagliarlo significa perdere prove forensi o dare tempo all'attaccante. Vi scrivo il runbook che tengo sempre pronto. Continua a leggere
NIS2 non è solo un problema del CISO o del DPO - riguarda chi scrive codice e chi gestisce server. Ho mappato gli articoli tecnici della direttiva su azioni concrete: quali log conservare, come strutturare l'incident response, cosa documentare per dimostrare conformità. Con esempi da un cliente manifatturiero già adeguato. Continua a leggere
Un e-commerce Laravel compromesso tramite una dipendenza Composer con backdoor: dati di 4.200 clienti potenzialmente esposti e obbligo di notifica GDPR in 72 ore. Ho gestito contenimento, forensics, ripristino e comunicazione seguendo la timeline NIS2 24-72-30. Il playbook operativo che uso per ogni incidente su applicazioni PHP. Continua a leggere
Un e-commerce Laravel su Hetzner fermo da 3 ore: schermata bianca, nessun log visibile, PHP-FPM che si riavvia in loop. La causa era un segfault in OPcache innescato dall'aggiornamento a PHP 8.2.21. Diagnosi con dmesg e strace, fix con disabilitazione JIT, e il protocollo che uso per ogni emergenza PHP su VPS unmanaged. Continua a leggere
VPS Hetzner compromesso: CPU al 100%, login SSH da IP ucraini, cryptominer nascosto in /dev/shm. Contenimento in 15 minuti, forensics, eradicazione, ripristino e hardening post-incidente seguendo il framework NIST SP 800-61. Il caso reale di una PMI piemontese e le cinque fasi operative che ho applicato. Continua a leggere
Un e-commerce Laravel era irraggiungibile da 6 ore - il server Hetzner era online, Nginx rispondeva, MySQL funzionava. Il problema: il dominio era stato trasferito a un nuovo registrar la sera prima, e il record NS ancora puntava ai nameserver del vecchio provider che aveva già cancellato la zona DNS. Diagnosi in 10 minuti con dig e whois, fix con TTL basso e propagazione controllata, e le 5 misconfigurazioni DNS che trovo più spesso su VPS di PMI. Continua a leggere
Un portale B2B Laravel su VPS OVH andava in 502 Bad Gateway ogni giorno tra le 10 e le 11 del mattino - l'ora di punta degli ordini. PHP-FPM veniva ucciso dall'OOM killer del kernel perché pm.max_children era impostato a 200 su un server con 8 GB di RAM e worker da 80 MB ciascuno. La matematica non tornava: 200 × 80 MB = 16 GB, il doppio della RAM disponibile. Diagnosi con dmesg, tuning di pm.max_children, auto-restart con systemd e prevenzione. Continua a leggere
Un VPS Hetzner con Redis 6 esposto su 0.0.0.0:6379 senza password. Un attaccante ha usato il motore Lua integrato per scrivere un crontab che scaricava un cryptominer Monero. CPU al 100%, Laravel a 12 secondi di response time, e nessuno sapeva perché. Il caso reale di un SaaS piemontese del luglio 2025, la diagnosi in 40 minuti, l'eradicazione e l'hardening di Redis per impedire che succeda di nuovo. Continua a leggere
