In breve: quando un attacco riguarda più di un singolo sito web, serve un fornitore di incident response che gestisca l'incidente in modo strutturato. Ci occupiamo del quadro della situazione, del contenimento, della bonifica e del ripristino sicuro, con ruoli chiari e documentazione senza lacune. Le decisioni restano a Lei, la base tecnica la forniamo noi.
Che cosa significa incident response negli attacchi ai server
L'incident response è la gestione ordinata di un incidente di sicurezza. Invece di azioni isolate e concitate, il lavoro segue fasi precise: riconoscere e inquadrare, contenere, eliminare, ripristinare, analizzare a posteriori. Ogni misura viene annotata con data e motivazione.
Proprio per i web server è importante. Un server con applicazioni PHP contiene spesso credenziali per database, fornitori di pagamento, server di posta e interfacce. Chi vi è entrato può spostarsi ulteriormente. La situazione dopo PHP2Shell mostra con quale rapidità possa crearsi un simile scenario: esecuzione di codice non autenticata, più di 22,6 milioni di istanze esposte secondo Unit 42 e nessun Indicator of Compromise pubblicato e confermato.
Quando serve un fornitore di incident response
- sono coinvolti, o potrebbero esserlo, più server o applicazioni
- c'è il sospetto che siano fuoriusciti dati personali o dati di pagamento
- un aggressore è forse ancora attivo, ad esempio tramite connessioni in corso o nuovi account
- c'è un'estorsione o un annuncio pubblico dell'attacco
- assicurazione, autorità o partner commerciali si aspettano una procedura documentata
Per un singolo sito web infetto spesso basta l'assistenza urgente per sito web hackerato. Il passaggio alla gestione completa dell'incidente lo discutiamo con Lei non appena si profila una portata maggiore.
Come aiuta concretamente PHP SOS?
- Triage e quadro della situazione: chiariamo che cosa è stato osservato, quali sistemi e dati possono essere coinvolti e chi va coinvolto internamente. Il risultato è un primo quadro scritto della situazione con le domande aperte.
- Salvare le tracce e contenere: log, file system e database vengono salvati prima che interveniamo. Poi isoliamo i sistemi coinvolti, blocchiamo gli accessi compromessi e interrompiamo le connessioni riconoscibili dell'aggressore.
- Eliminare: chiudiamo il punto d'ingresso, ad esempio applicando la patch alle versioni PHP corrette e riavviando tutti i worker, rimuoviamo le backdoor e sostituiamo i segreti. Per l'analisi di dettaglio coinvolgiamo, se necessario, partner specializzati in analisi forense IT.
- Ripristinare: i sistemi tornano in esercizio in modo controllato, possibilmente da fonti pulite o su server reinstallati. Dopo li monitoriamo con maggiore attenzione per rilevare nuove anomalie.
- Analisi a posteriori: riceve un rapporto finale con linea temporale, cause, misure e raccomandazioni. Insieme annotiamo che cosa dovrà andare più in fretta la prossima volta.
Conservi i log del server e non modifichi alcun sistema prima che sia stato effettuato il salvataggio. Per PHP2Shell il BSI (l'Ufficio federale tedesco per la sicurezza informatica) raccomanda di scollegare temporaneamente dalla rete i web server non aggiornabili subito.
Ruoli e comunicazione durante l'incidente
Un incidente richiede responsabilità chiare. Si è rivelato efficace un piccolo gruppo composto da una persona con potere decisionale, un referente tecnico da parte Sua e noi come direzione tecnica. Le riunioni sulla situazione si tengono a intervalli fissi, i risultati vengono messi per iscritto.
In parallelo si svolgono compiti che non assumiamo, ma per i quali forniamo i fatti: la verifica di un obbligo di notifica GDPR entro 72 ore, l'informazione dell'assicuratore, un'eventuale denuncia e la comunicazione di crisi verso clienti e partner.
Che cosa ci serve da Lei e che cosa riceve
Ci servono accessi amministrativi ai sistemi coinvolti, una panoramica dell'infrastruttura e dei fornitori, una persona con potere decisionale e la disponibilità a spegnere temporaneamente i sistemi, se necessario. Sono utili piani di emergenza esistenti, schemi di rete e backup con data.
Riceve un verbale continuo dell'incidente, quadri della situazione regolari in un linguaggio comprensibile, un rapporto finale per la direzione, i responsabili della protezione dei dati e l'assicuratore, nonché un elenco prioritizzato di miglioramenti. Come prepararsi meglio per il prossimo incidente è descritto alla pagina Creare un piano di emergenza IT per i web server.
Errori tipici nelle prime ore
Molti incidenti si aggravano perché, nella concitazione, passi fatti in buona fede avvengono nell'ordine sbagliato. Questi sono gli schemi che vediamo più spesso:
- Reinstallare subito: il server viene cancellato e reinstallato prima che sia stato effettuato il salvataggio. Dopo non è più possibile chiarire se i dati siano usciti.
- Cambiare le password dal sistema infetto: se l'aggressore ha ancora accesso, vede anche le nuove password.
- Cancellare solo il file visibile: la web shell non c'è più, la seconda backdoor nel cronjob rimane.
- Patch senza riavvio: i nuovi file PHP sono sul disco, i vecchi worker continuano a girare in memoria.
- Nessuno tiene un verbale: dopo nessuno sa più chi ha modificato che cosa e quando. Questo complica le conversazioni con assicuratore e autorità.
Una procedura concordata previene questi errori senza ritardare il contenimento.
Che cosa non promettiamo
Non promettiamo che ogni incidente venga chiarito per intero; senza tracce restano domande aperte, e lo scriviamo così anche nel rapporto. Non forniamo consulenza legale né dichiarazioni su responsabilità o copertura assicurativa. Il nostro obiettivo è una chiusura chiara: lavoriamo sull'incidente finché non è concluso e documentato.
Domande frequenti
Qual è la differenza tra incident response e analisi forense IT?
L'incident response ha l'obiettivo di contenere l'incidente e di ripristinare l'operatività in sicurezza. L'analisi forense IT chiarisce nel dettaglio e con valore probatorio che cosa è accaduto. Nella pratica le due attività si intrecciano, e la parte forense spesso salva le tracce in parallelo.
Quando dovrei coinvolgere un fornitore di incident response?
Non appena sorge il sospetto che un aggressore abbia avuto accesso ai sistemi e Lei non riesca a valutare con certezza l'entità. Quanto prima inizia la conservazione delle tracce, tanto più si potrà dimostrare in seguito.
Chi decide durante l'incidente?
Le decisioni le prende Lei, ad esempio su spegnimenti, comunicazione o notifiche. Noi prepariamo le basi tecniche, mostriamo le opzioni con le loro conseguenze e attuiamo le decisioni.
Devo coinvolgere la polizia?
In molti casi una denuncia è sensata ed è rilevante per alcune assicurazioni. Se ne occupano le Zentrale Ansprechstellen Cybercrime della polizia tedesca (punti di contatto centrali per il cybercrime). Se e quando presentare denuncia lo decide Lei insieme al Suo avvocato.