Risposta agli incidenti

60 domande su Risposta agli incidenti, in linguaggio semplice: cosa verificare, cosa mostra NetSenX e cosa un sensore non vede.

  • Connessioni regolari di una postazione verso un nuovo server esterno, un host che scansiona gli intervalli interni alla ricerca di porte SMB, RDP o di database, nuove sessioni di amministrazione verso molti server e un grande caricamento verso il cloud da un server che di solito invia poco. Di norma arrivano in quest'ordine, prima che venga cifrato qualsiasi file.

  • Spesso sì, perché le fasi che precedono la cifratura attraversano la rete: connessioni di comando e controllo, scansioni, movimento laterale e furto di dati. È la finestra in cui un attacco si può ancora fermare. Non tutti gli attacchi mostrano tutte queste fasi, e uno confinato a una sola macchina lascia poco da vedere alla rete.

  • No. NetSenX segnala il comportamento di rete che di solito precede il ransomware, così il Suo team può agire finché c'è tempo. Isolare gli host, allontanare l'attaccante e ripristinare i dati restano compiti del Suo team, della protezione degli endpoint e dei backup.

  • Scollegare dalla rete gli host coinvolti, conservarne i log, reimpostare le credenziali usate su di essi e chiamare il Suo fornitore di incident response. Se la Sua organizzazione rientra nella NIS2, il termine di 24 ore per il preallarme decorre da quando viene a conoscenza di un incidente significativo.

  • Scolleghi dalla rete le macchine colpite, sullo switch oppure staccando il cavo e spegnendo il Wi-Fi. Se può, le lasci accese, perché la memoria contiene prove, a meno che non possa isolarle in altro modo. Non contatti gli attaccanti e non paghi nulla prima di essersi consultato. Chiami il Suo fornitore di risposta agli incidenti, la linea di assistenza della Sua assicurazione cyber se ce l'ha, oppure il CSIRT nazionale. Cambi le password di amministratore da un dispositivo pulito, verifichi che i backup siano integri e scollegati e inizi un registro scritto, con gli orari, di ciò che vede e fa. Se è soggetto a NIS2, il termine di 24 ore per il preallarme decorre dal momento in cui viene a conoscenza di un incidente significativo, quindi coinvolga fin dall'inizio chi si occupa delle notifiche.

  • Più o meno in quest'ordine, adattato alla Sua situazione. Uno: isoli dalla rete le macchine colpite senza spegnerle e fermi la diffusione sugli switch o sul firewall. Due: chiami il Suo fornitore di risposta agli incidenti, la linea di assistenza dell'assicuratore e, se serve, un legale, e inizi un registro dell'incidente. Tre: metta al sicuro le prove e verifichi se i backup sono integri e offline. Quattro: scopra come sono entrati gli attaccanti, quali sistemi hanno raggiunto e se sono usciti dati, e valuti gli obblighi di notifica previsti da NIS2 e GDPR, con le relative scadenze. Cinque: decida che cosa dire a personale, clienti e partner. Sei: elimini l'attaccante, reimposti le credenziali e chiuda la via d'ingresso. Sette: ricostruisca e ripristini in ordine di priorità da backup puliti. Otto: sorvegli da vicino per settimane e tenga una revisione delle lezioni apprese. NetSenX aiuta nei passi quattro e otto, con prove di rete e rilevamento continuo.

  • È una decisione aziendale e legale, e le forze dell'ordine sconsigliano di pagare: finanzia gli attaccanti, non garantisce che i file tornino né che i dati rubati vengano cancellati, e pagare un gruppo sottoposto a sanzioni può essere illegale. Decida con il Suo fornitore di incident response, l'assicuratore e i legali, e denunci l'incidente alla polizia e, dove previsto, al CSIRT. NetSenX non tratta e non ripristina dati; aiuta a vedere prima che cosa hanno fatto gli attaccanti in rete.

  • Pagare non annulla il furto. Pagherebbe dei criminali per la promessa di cancellare dati che hanno ogni motivo di tenersi, e le forze dell'ordine, tra cui Europol e le polizie nazionali, sconsigliano di pagare; sono stati riportati casi di dati pubblicati o venduti dopo il pagamento. Pagare una persona o un gruppo sottoposto a sanzioni può inoltre essere illegale. La decisione spetta alla direzione, con il fornitore di risposta agli incidenti, l'assicuratore e i legali. Prima di decidere, accerti i fatti: che cosa è davvero uscito, se contiene dati personali, quali notifiche sono dovute a prescindere dal pagamento e che cosa dirà alle persone interessate. Ai sensi del GDPR, una violazione dei dati personali si valuta in base a ciò che è accaduto, non al fatto che sia stato pagato un riscatto. NetSenX non negozia; aiuta con i fatti, tramite alert che mostrano quali host hanno inviato volumi insoliti e quando.

  • Un negoziatore ransomware è uno specialista, spesso fornito da una società di risposta agli incidenti o tramite la lista dell'assicuratore, che comunica con gli attaccanti per conto della vittima. Il suo compito è guadagnare tempo, ottenere prove di ciò che è stato preso, verificare se uno strumento di decifratura funziona e, se l'azienda decide di pagare, controllare le liste delle sanzioni e gestire le condizioni. Ricorrervi non significa aver deciso di pagare: dialogare può far guadagnare giorni per ripristinare dai backup. Non apra da solo la chat degli attaccanti e non risponda alle loro e-mail prima di essersi consultato, perché ciò che scrive può indebolire la Sua posizione. Chieda prima all'assicuratore, perché le polizze impongono spesso la società da lui scelta, e conservi ogni messaggio come prova. NetSenX non ha alcun ruolo nella negoziazione; i suoi alert aiutano a stabilire che cosa ha davvero lasciato la rete, il che conta quando si verificano le affermazioni degli attaccanti.

  • Guardi che cosa ha lasciato la rete e quando: log del firewall e del proxy, log di audit degli archivi cloud e log delle macchine coinvolte. Il segnale abituale sono grandi caricamenti verso un archivio cloud o verso un indirizzo sconosciuto nei giorni precedenti la cifratura. Chieda al Suo fornitore di risposta agli incidenti di confrontare i volumi con ciò che contiene ogni server e conservi i log prima che vengano sovrascritti. Se gli attaccanti pubblicano un campione su un sito di leak, dice qualcosa su ciò che hanno preso, ma raramente tutto, e le loro affermazioni non provano nulla né in un senso né nell'altro. NetSenX conserva i suoi alert sui volumi di dati in uscita insoliti per host, con orario, destinazione e volume, il che aiuta a stimare un trasferimento. Non vede i nomi dei file nelle sessioni cifrate.

  • Cerchi il trasferimento, non la dichiarazione. Gli attaccanti a volte esagerano per aumentare la pressione, e a volte hanno davvero preso tutto ciò che dicono. Controlli nei log del firewall e del proxy i grandi trasferimenti in uscita nei giorni precedenti la cifratura, soprattutto verso archivi cloud o indirizzi che nessun altro usa, e annoti quali host interni li hanno inviati. Confronti il volume con ciò che contengono quei server. Chieda un campione di prova solo tramite il Suo fornitore di risposta e guardi che cosa contiene. I log di audit degli archivi cloud e dei servizi SaaS possono mostrare download massivi. Se le prove non mostrano un trasferimento in uscita significativo, ciò aiuta la decisione e un'eventuale notifica, ma l'assenza di prove su una via non dimostra che nulla sia uscito da un'altra. NetSenX conserva gli alert sui volumi di dati in uscita insoliti per host, con orario, destinazione e volume; non vede i nomi dei file nei trasferimenti cifrati.

  • Spesso sì, se i log di quel periodo esistono ancora. I file pubblicati danno indizi: la loro data di modifica più recente fissa il momento più precoce possibile del furto, e le cartelle da cui provengono indicano i server coinvolti. Poi cerchi nei log del firewall, del proxy e di audit del cloud grandi trasferimenti in uscita da quei server in quel periodo, e il primo contatto regolare con un server esterno sconosciuto, che spesso segna l'inizio dell'intrusione. Lo faccia fare al Suo fornitore di risposta agli incidenti e non scarichi da solo i dati pubblicati: coinvolga il fornitore e il legale, perché maneggiare dati rubati comporta rischi propri. Denunci la pubblicazione alla polizia. NetSenX conserva, per la cronologia degli alert del Suo piano, gli alert sui volumi in uscita insoliti per host con orario e destinazione, il che può restringere molto la finestra.

  • No. NetSenX analizza i metadati dei flussi e alcuni campi dei protocolli, e non decifra mai il traffico. Quando i dati escono da una connessione cifrata, cioè quasi sempre, vede quale host ha inviato quanto, verso quale destinazione e quando, ma non i nomi né il contenuto dei file. È comunque utile: Le dice quale server esaminare, quanto era grande il trasferimento e quando è avvenuto, il che spesso basta a restringere che cosa poteva contenere. Per sapere quali file sono stati presi, lo combini con fonti che vedono i file: log di audit di file server e archivi cloud, telemetria di endpoint detection and response (EDR), strumenti di prevenzione della perdita di dati o un esame forense del server. Se gli attaccanti pubblicano campioni, anche questi indicano quali cartelle erano coinvolte.

  • Ci provano, se si sono lasciati una via: password rubate, uno strumento di accesso remoto dimenticato, un nuovo account, un'attività pianificata o una VPN mai aggiornata. Alcuni criminali vendono o cedono anche l'accesso, quindi un secondo attacco può arrivare da qualcun altro attraverso la stessa porta. Dopo un incidente, reimposti tutte le credenziali che potrebbero essere state esposte, compresi gli account di servizio, rimuova gli strumenti di accesso remoto non approvati, chiuda la via d'ingresso, ricostruisca le macchine colpite da immagini sicure e sorvegli la rete da vicino per settimane. Nuove connessioni verso i server dell'attaccante sono un segnale tipico; NetSenX rileva il beaconing C2 in ogni piano, Free compreso, e gli indicatori del Suo rapporto sull'incidente si possono cercare nei log del firewall e dei DNS.

  • La risposta agli incidenti è il modo organizzato con cui un'azienda rileva un incidente di sicurezza, lo contiene, si riprende e ne trae insegnamento. Comprende il lavoro tecnico, come isolare le macchine, eliminare l'attaccante e ripristinare i sistemi, e le decisioni che lo accompagnano: chi guida, chi viene informato, quando chiamare aiuto esterno, che cosa notificare ad autorità, assicuratori e clienti. Una piccola azienda non ha bisogno di un team di sicurezza per farlo bene. Ha bisogno di un breve piano scritto, di numeri di telefono che funzionano quando la posta elettronica non funziona, di qualcuno autorizzato a decidere di notte e di prove che mostrino che cosa è successo. NetSenX aiuta con le prove e con i tempi: rileva comportamenti di rete che spesso indicano un'intrusione, spiega ogni alert e segue per ogni incidente le scadenze dell'articolo 23 della NIS2. Non elimina gli attaccanti e non ripristina i sistemi.

  • Il modello più noto ne ha sei: preparazione, identificazione, contenimento, eradicazione, ripristino e lezioni apprese, dal manuale SANS per chi gestisce gli incidenti. La precedente guida del NIST, SP 800-61 Revision 2, raggruppava lo stesso lavoro in quattro fasi. Nell'aprile 2025 il NIST l'ha sostituita con la SP 800-61 Revision 3, che collega la risposta agli incidenti alle sei funzioni del suo Cybersecurity Framework 2.0: governare, identificare, proteggere, rilevare, rispondere e ripristinare. Tutti dicono la stessa cosa: la maggior parte del lavoro avviene prima dell'incidente, nella preparazione, e dopo, nel miglioramento. Per una piccola azienda l'ordine pratico è semplice: accorgersene, limitare i danni, eliminare la causa, tornare al lavoro in sicurezza e cambiare ciò che ha reso possibile l'incidente. Mettere per iscritto questa sequenza per i propri sistemi è il primo passo più utile.

  • Decidendo adesso ciò che altrimenti dovrebbe improvvisare nel cuore della notte. Scriva un piano di una pagina: chi guida, chi può spegnere i sistemi, chi parla con clienti, assicuratori e autorità. Tenga i numeri di telefono su carta e in un secondo canale, perché posta e chat possono essere fuori uso o compromesse. Conosca i Suoi tre o quattro sistemi più importanti e l'ordine in cui li ripristinerebbe, e provi un ripristino dal backup. Concordi le condizioni con un fornitore di risposta agli incidenti prima di averne bisogno e verifichi chi la Sua polizza cyber richiede di chiamare per primo. Si assicuri che i log necessari esistano e siano conservati abbastanza a lungo: firewall, VPN, directory e cronologia di rete. NetSenX fornisce la cronologia di rete e alert spiegati, e i report PDF dal piano Starter rendono più semplice consegnare un fascicolo di prove.

  • Meno di quanto suggerisca la maggior parte dei modelli, purché funzioni sotto pressione. L'essenziale sta in due o tre pagine: chi guida e chi lo sostituisce, i numeri di telefono delle persone e dei fornitori da chiamare, quando isolare un sistema o staccare l'azienda da internet, dove sono i backup e come ripristinare i sistemi più importanti, e chi decide le notifiche al CSIRT, all'autorità per la protezione dei dati, agli assicuratori e ai clienti, con le relative scadenze. Aggiunga una breve checklist per la prima ora e un modello di registro dell'incidente. Lo stampi, perché il file server che lo contiene potrebbe essere proprio quello cifrato. Lo riveda dopo ogni incidente e almeno una volta l'anno. NetSenX segue per ogni incidente le scadenze dell'articolo 23 della NIS2 e tiene un log di audit di alert e decisioni degli analisti, a supporto della parte del piano dedicata alle notifiche.

  • Meno persone di quanto pensi, ma con ruoli chiari. Una persona guida e decide, di solito l'amministratore o chi viene da lui designato, con un sostituto indicato per nome. Una persona svolge o coordina il lavoro tecnico: il Suo amministratore IT, il Suo fornitore di servizi gestiti o una società esterna di risposta agli incidenti. Una persona gestisce la comunicazione con personale, clienti e fornitori, e una segue gli aspetti legali e le notifiche, spesso con il responsabile della protezione dei dati e un legale. In un'azienda di 30 persone possono essere tre persone con più ruoli. Ciò che conta è che ogni ruolo sia scritto, che chi guida possa decidere di notte senza attendere una riunione e che i numeri esterni siano concordati in anticipo. Dal piano Starter, che include la gestione del team, NetSenX dà a ciascuno un account proprio, così motivazioni degli alert e decisioni sono visibili all'intero team.

  • Un retainer è un accordo con una società di risposta agli incidenti, firmato prima che accada qualcosa, che Le garantisce un intervento entro un tempo concordato e fissa prezzo e condizioni. Senza di esso, si ritrova a cercare un fornitore, negoziare un contratto e concedere accessi mentre l'attaccante è ancora attivo. Molte assicurazioni cyber hanno una propria lista di società di intervento e si aspettano che le chiami per prime, quindi verifichi la polizza prima di firmare qualcosa a parte. Una piccola azienda può non aver bisogno di un retainer a pagamento se la linea di assistenza dell'assicuratore copre questo aspetto, ma deve sapere chi chiamare, di che cosa avrà bisogno quella società il primo giorno e come raggiungerà i Suoi sistemi. NetSenX non è una società di risposta agli incidenti. Fornisce alla società che chiamerà alert spiegati e una cronologia di rete precedente all'incidente, di solito la prova più difficile da ricostruire a posteriori.

  • Un'esercitazione tabletop è una riunione in cui le persone che gestirebbero un incidente ripercorrono passo per passo uno scenario realistico, senza toccare alcun sistema. Un facilitatore presenta la situazione a tappe: un alert a tarda sera, una richiesta di riscatto il lunedì mattina, la telefonata di un giornalista, un backup che risulta cifrato anch'esso. A ogni tappa il team dice che cosa farebbe, chi deciderebbe e chi chiamerebbe. Bastano novanta minuti con la direzione, l'IT, la comunicazione e chi segue gli aspetti legali. Il valore sta nelle lacune che emergono: un numero di telefono che nessuno ha, una decisione che nessuno può prendere, un log che nessuno tiene. Le annoti, le corregga e ripeta l'esercitazione una o due volte l'anno. Uno scenario basato su un alert reale o su un incidente passato insegna più di uno generico.

  • Sono pioli di una stessa scala. Un evento è qualunque cosa accada e possa essere registrata: un accesso, una connessione, la modifica di un file. Un alert è un evento, o un insieme di eventi, che uno strumento segnala perché potrebbe contare, come una postazione che contatta un nuovo server esterno ogni pochi minuti. Un incidente è ciò che dichiara dopo aver esaminato uno o più alert e aver concluso che la sicurezza è stata, o è in corso di essere, effettivamente compromessa: un attaccante è dentro, dei dati sono stati rubati, un servizio è stato interrotto. La differenza conta perché gli obblighi riguardano gli incidenti, non gli alert: le scadenze di notifica della NIS2 decorrono da quando viene a conoscenza di un incidente significativo, non da quando uno strumento genera un alert. NetSenX produce alert con una motivazione in linguaggio semplice; stabilire se costituiscono un incidente resta una Sua valutazione, e la decisione viene registrata nel log di audit.

  • Confrontando l'alert con ciò che sa, rapidamente e ogni volta nello stesso ordine. Si ponga quattro domande: il dispositivo e il suo titolare sono noti, c'è un motivo di lavoro per questo comportamento, la destinazione o l'account sono familiari, ed è successo qualcos'altro di insolito sullo stesso host o nello stesso momento? Un backup, un aggiornamento software o un amministratore che lavora fino a tardi spiegano molti alert in pochi minuti. Ciò che nessuno sa spiegare, che riguarda più host o che segue un altro alert merita un'escalation. Annoti che cosa ha verificato, anche quando era innocuo, così la persona successiva non riparte da zero. NetSenX spiega in ogni alert quali caratteristiche del traffico lo hanno determinato, indica la tecnica MITRE ATT&CK quando ce n'è una e Le permette di segnare un falso positivo, con la decisione conservata nel log di audit.

  • In base all'effetto sull'attività, non a quanto appare allarmante. Basta una scala semplice: bassa quando è colpito un solo dispositivo ed è contenuto, media quando sono coinvolti un account o più dispositivi, alta quando sono a rischio sistemi importanti o dati personali, critica quando l'attività si ferma o i dati hanno lasciato l'azienda. Si chieda che cosa è colpito, quanti sistemi e quante persone, se sono coinvolti dati personali o dei clienti, se si sta diffondendo e se sono interrotti servizi che fornisce ad altri. La risposta decide chi viene chiamato, con quale rapidità e se possono applicarsi obblighi di notifica: la NIS2 ragiona in termini di incidente significativo e il GDPR di violazione dei dati personali, ciascuno con criteri propri. Concordi la scala in anticipo e la scriva nel piano. NetSenX mostra in ogni alert che cosa è stato visto e su quali host, un punto di partenza per questa valutazione e non un suo sostituto.

  • Una persona indicata per nome, con un sostituto altrettanto indicato e l'autorità di agire senza convocare riunioni. Le decisioni in un incidente sono urgenti e scomode: staccare l'azienda da internet, fermare un sistema di produzione, chiamare la polizia, informare i clienti. Se nessuno è chiaramente autorizzato a prenderle, si perdono ore ad aspettare un accordo. Nella maggior parte delle piccole aziende decide l'amministratore, consigliato dall'IT e da un soggetto esterno di risposta agli incidenti; in quelle più grandi un incident manager agisce per conto del vertice entro limiti concordati. Metta per iscritto quali decisioni questa persona può prendere da sola e quali richiedono il vertice, e si assicuri che il sostituto sia raggiungibile quando il responsabile è in viaggio. La NIS2 rende inoltre gli organi di gestione dei soggetti interessati responsabili di approvare le misure di gestione dei rischi di cibersicurezza e di sorvegliarne l'attuazione, quindi il vertice dovrebbe conoscere il piano prima che serva.

  • Di solito cinque cose. Se isolare sistemi o l'intera sede, accettando l'interruzione che ne deriva. Chi coinvolgere: una società di risposta agli incidenti, la linea di assistenza dell'assicuratore, un legale. Se l'incidente può essere soggetto a notifica, al CSIRT nazionale ai sensi della NIS2 o all'autorità per la protezione dei dati ai sensi del GDPR, e chi prepara la notifica. Che cosa dire a personale, clienti e partner, e quando, senza promettere ciò che non si sa ancora. E come mandare avanti l'attività: processi manuali, comunicazione alternativa, quali clienti chiamare per primi. Nessuna di queste decisioni è tecnica, ed è per questo che un team tecnico non può prenderle da solo. Le prepari come opzioni nel piano. NetSenX dà alla direzione un punto di partenza fattuale: quali host hanno mostrato quale comportamento e quando, e le scadenze dell'articolo 23 della NIS2 seguite per l'incidente.

  • Sposti le discussioni sull'incidente su un canale che l'attaccante non può leggere prima di dire qualsiasi cosa sui Suoi piani. Gli attaccanti che controllano una casella di posta o la directory leggono spesso i messaggi del team di risposta e si adattano. Concordi in anticipo un canale alternativo: telefonate, un gruppo di messaggistica su dispositivi senza account aziendali o uno spazio di collaborazione separato con credenziali proprie. Tenga un elenco dei contatti stampato, perché la rubrica potrebbe non essere disponibile. Chieda ad assicuratore, banca e clienti principali di confermare per telefono ogni richiesta che arriva da Lei, perché a volte i criminali inviano messaggi falsi nel pieno di un incidente. Quando directory e posta sono state ricostruite e le credenziali reimpostate, torni ai canali abituali. Gli alert di NetSenX stanno in una dashboard propria, che può aprire da un dispositivo pulito, quindi il quadro della rete non dipende dalla posta aziendale.

  • Perché sotto stress la memoria cede e dopo tutti chiederanno che cosa è successo e quando. Un registro semplice annota l'ora, che cosa si è osservato, che cosa si è deciso, da chi e perché, e che cosa si è fatto. Permette a una seconda persona di subentrare di notte senza ricominciare, dimostra all'assicuratore e all'autorità che si è agito con rapidità e ponderazione ed è la base della cronologia in una notifica NIS2 o GDPR. Protegge anche chi decide: una scelta che a posteriori sembra sbagliata era spesso ragionevole con ciò che si sapeva allora, e il registro lo dimostra. Lo tenga fuori dai sistemi colpiti, su carta o in un documento condiviso raggiungibile da un dispositivo pulito, e annoti tutti gli orari nello stesso fuso. NetSenX contribuisce con alert dotati di marca temporale e con un log di audit delle decisioni degli analisti, che può allegare al Suo registro.

  • Tagli la rete, non la corrente, e copi prima di ripulire. Isolare una macchina colpita sulla porta dello switch, sul firewall o tramite lo strumento di protezione degli endpoint impedisce all'attaccante di usarla, mentre memoria, processi in esecuzione e connessioni aperte restano intatti per l'indagine. Prima di reinstallare macchine, cancellare file o rimuovere account, esporti i log rilevanti, annoti account e file sospetti e, se gli specialisti lo consigliano, esegua un'acquisizione della memoria e un'immagine del disco. Blocchi le destinazioni dell'attaccante sul firewall, ma annoti quali e quando. Se deve scegliere tra rapidità e prove, per esempio perché la cifratura si sta diffondendo, vince la rapidità: prima fermi il danno. Le prove di rete sono le più facili da perdere, perché molti dispositivi conservano solo una breve cronologia; NetSenX conserva i suoi alert con orario, host e destinazioni per la durata della cronologia del Suo piano.

  • Lo scolleghi dalla rete, ma lo lasci acceso, salvo che abbia un motivo per non farlo. Staccare il cavo e spegnere il Wi-Fi toglie il controllo all'attaccante e ferma la diffusione, mentre la memoria conserva prove che spariscono allo spegnimento: programmi in esecuzione, connessioni di rete, a volte chiavi di cifratura utili al recupero. Spegnere è la scelta giusta quando non può isolare la macchina in altro modo e il danno si diffonde rapidamente, oppure quando lo chiedono gli specialisti. Non acceda come amministratore per curiosare, non avvii strumenti di pulizia e non riavvii prima di essersi consultato, perché ogni passo modifica le prove. Annoti l'ora e che cosa ha fatto. Se la macchina è un server da cui dipendono altri, lo isoli sullo switch o sul firewall invece di staccare cavi a caso. Un sensore di rete come NetSenX conserva la traccia di ciò che la macchina ha fatto prima che la scollegasse.

  • Ecco un breve elenco di errori frequenti. Non cancelli né reinstalli le macchine prima di aver salvato le prove, altrimenti perde il modo di capire come è entrato l'attaccante. Non reimposti le password una alla volta mentre l'attaccante osserva ancora; pianifichi il contenimento e lo esegua in un colpo solo. Non discuta l'incidente via posta o chat che potrebbero essere compromesse. Non contatti né paghi gli attaccanti senza il parere del Suo fornitore di risposta, dell'assicuratore e del legale. Non ripristini dai backup prima di sapere che sono anteriori all'intrusione. Non annunci pubblicamente ciò che non sa ancora e non prometta ai clienti che nessun dato è stato colpito prima di averlo verificato. Non perda le scadenze: un preallarme NIS2 o una notifica GDPR possono essere inviati con informazioni incomplete e completati in seguito. E non smetta di sorvegliare la rete quando i sistemi tornano a funzionare.

  • Proceda a ritroso da ciò che sa, aiutandosi con le marche temporali. Parta dalla macchina su cui è stato notato l'incidente, si chieda quale altro host vi si è collegato per primo in modo insolito e ripeta per quell'host. I log degli endpoint mostrano accessi e nuovi programmi, quelli della directory quale account è stato usato da quale computer, quelli di firewall e VPN le prime connessioni verso l'esterno. I primi contatti regolari con un server dell'attaccante indicano spesso la prima macchina infetta. Il paziente zero conta perché rivela come è entrato l'attaccante, via che va chiusa prima del ripristino. Tenga presente che la prima macchina trovata spesso non è la prima infettata. Gli alert di NetSenX riportano orari, host e destinazioni, e dal piano Pro la correlazione sull'intera rete collega scansioni, nuove sessioni e beaconing tra host in un'unica storia, accorciando questa ricerca.

  • Un'immagine forense è una copia esatta e verificata di un disco o della memoria di un computer, realizzata perché gli investigatori possano esaminarla senza modificare l'originale. Si ottiene con strumenti dedicati, viene contrassegnata con un hash come SHA-256 perché ogni modifica successiva sia rilevabile e viene conservata con la traccia di chi l'ha maneggiata. Serve quando l'incidente può sfociare in una controversia legale, una richiesta di indennizzo, una denuncia o domande di un'autorità, e quando vuole sapere come è entrato l'attaccante prima di ricostruire la macchina. I normali backup non la sostituiscono, perché tralasciano file cancellati, memoria e aree di sistema. Se può, la affidi a uno specialista. Le prove di rete la completano: NetSenX registra ciò che è passato in rete, cosa che l'immagine del disco di una singola macchina non può mostrare.

  • La catena di custodia è la registrazione scritta di chi ha raccolto una prova, quando e come, e di chi l'ha avuta da allora. Per un'immagine del disco, un'esportazione di log o una cattura di rete significa annotare la fonte, data e ora, il metodo o lo strumento usato, un valore hash che dimostra che la copia non è cambiata, il luogo di conservazione e ogni persona che vi ha avuto accesso. Senza questa registrazione, un tribunale, un assicuratore o un'autorità possono dubitare che la prova sia ciò che dichiara. Una piccola azienda può tenerla in modo semplice: una scheda per elemento, copie su supporti a scrittura singola o ad accesso controllato e nessun lavoro sugli originali. NetSenX tiene un log di audit di alert, decisioni degli analisti e modifiche di configurazione e, dal piano Starter, un proof trail, a sostegno di questa registrazione per la parte di rete di un incidente.

  • Li esporti non appena sospetta un incidente, prima di modificare qualsiasi altra cosa. Molti dispositivi conservano i log solo per pochi giorni o fino a un limite di dimensione: firewall, gateway VPN, switch e alcuni servizi cloud sovrascrivono per prime le voci più vecchie, e un attaccante attivo può tentare di cancellarle. Prepari in anticipo un elenco dei log importanti, di solito firewall, VPN, directory e autenticazione, posta, console degli endpoint e DNS, con il modo di esportare ciascuno. Durante l'incidente li copi su un archivio esterno ai sistemi colpiti, annoti l'ora e l'hash di ogni file e, se può, aumenti la conservazione sui dispositivi. Chieda ai Suoi fornitori cloud fin dove arrivano i loro log di audit. NetSenX conserva i suoi alert nel proprio servizio per la cronologia degli alert del Suo piano, 30 giorni con Free e di più con i piani a pagamento, qualunque cosa accada ai Suoi dispositivi.

  • L'eradicazione consiste nel rimuovere completamente la presenza dell'attaccante prima di riportare in servizio i sistemi. Comprende la cancellazione di malware e strumenti, la chiusura della via d'ingresso, la rimozione di account, attività pianificate e software di accesso remoto creati dall'attaccante, la reimpostazione di tutte le credenziali che potrebbero essere state esposte e l'aggiornamento delle vulnerabilità sfruttate. In pratica, ricostruire le macchine colpite da immagini pulite è spesso più affidabile che ripulirle, perché è difficile dimostrare di aver trovato ogni modifica. L'eradicazione fallisce quando è parziale: un attaccante che conserva un appiglio ritorna, a volte dopo settimane. Va pianificata sulla base delle prove dell'indagine, non a intuito. Sorvegliare la rete dopo serve a verificare se ha funzionato: NetSenX rileva un nuovo beaconing verso server esterni noti o nuovi e nuove sessioni laterali, in ogni piano.

  • Da un dispositivo pulito, in un ordine pianificato ed entro un'unica breve finestra. Parta dagli account che controllano tutto: amministratori del dominio e del cloud, sistema di backup, accesso remoto e account di servizio con diritti ampi. In Active Directory l'account che firma i ticket Kerberos (krbtgt) si reimposta due volte, lasciando il tempo della replica nel mezzo, così che i ticket contraffatti smettano di funzionare. Poi reimposti gli utenti ordinari, revochi sessioni e token attivi nei servizi cloud e richieda l'autenticazione a più fattori (MFA) ovunque manchi. Non invii le nuove password via una posta che potrebbe essere compromessa. Se reimposta troppo presto, quando l'attaccante ha ancora un appiglio, catturerà semplicemente le nuove password: prima contenga. Le modifiche di identità sfuggono a un sensore di rete; NetSenX mostra se in seguito le macchine dell'attaccante continuano a contattare l'esterno.

  • Non può saperlo con certezza, ma può costruirsi una ragionevole fiducia. Verifichi di aver capito come è entrato e che quella via sia chiusa, che ogni account e strumento da lui creato sia stato rimosso e che le credenziali siano state reimpostate. Poi cerchi l'assenza di attività: nessuna connessione verso i suoi server noti, nessun nuovo account amministratore, nessun accesso inspiegato, nessuna scansione tra host. Cerchi nei log e sugli endpoint gli indicatori emersi dall'indagine, come indirizzi IP, domini e hash di file. Mantenga una vigilanza accresciuta per almeno diverse settimane, perché alcuni attaccanti aspettano. Una compromise assessment svolta da una società esterna offre uno sguardo indipendente. NetSenX sostiene questo test di assenza dal lato della rete: beaconing, scansioni, movimento laterale e volumi in uscita insoliti vengono rilevati in ogni piano, Free compreso, quindi il silenzio sui segmenti monitorati significa qualcosa.

  • L'hardware di solito sì, l'installazione no. Il ransomware e gli strumenti che lo accompagnano modificano il sistema operativo, aggiungono account e lasciano meccanismi di persistenza difficili da trovare, quindi l'approccio affidabile è cancellare e reinstallare le macchine colpite da immagini sicure, poi ripristinare i dati da un backup precedente all'intrusione. Prima di riutilizzare le macchine che servono all'indagine, ne conservi i dischi o le immagini. Le infezioni a livello di firmware esistono ma sono rare; il Suo fornitore di risposta Le dirà se c'è motivo di sostituire l'hardware. Anche le macchine non colpite vanno controllate, perché gli attaccanti toccano spesso più sistemi di quanti ne cifrino. Prima di ricollegare le macchine ricostruite, si assicuri che la via d'ingresso sia chiusa. La mappa di rete di NetSenX mostra quali host hanno comunicato con quelli colpiti durante l'incidente, il che aiuta a decidere che cos'altro controllare.

  • In un ordine controllato, su basi pulite e tenendo gli occhi aperti. Prima si assicuri che la via d'ingresso dell'attaccante sia chiusa e che i suoi account e strumenti siano spariti. Ricostruisca prima il nucleo: directory, account amministratore, sistema di backup e firewall, con nuove credenziali. Poi ripristini i sistemi in ordine di priorità aziendale, da backup che ha verificato essere anteriori all'intrusione e che sono stati analizzati prima dell'uso. Riporti ogni sistema in servizio su un segmento di rete monitorato prima di dare accesso a tutti, e mantenga gli utenti su nuove password con autenticazione a più fattori (MFA). Dica al personale che cosa segnalare se qualcosa sembra strano e metta in conto che il ripristino duri più dell'attacco. Sorvegli la rete da vicino per settimane; NetSenX rileva nuovo beaconing, scansioni e movimento laterale in ogni piano, ed è spesso così che emerge una pulizia incompleta.

  • Spesso in parte, se lo ha pianificato. Stabilisca in anticipo quali processi sono critici e come funzionano per qualche giorno senza IT: moduli d'ordine cartacei, elenchi telefonici di clienti e fornitori, bolle di consegna manuali, un portatile di riserva mai collegato alla rete aziendale. Isolare i sistemi colpiti può consentire agli altri di continuare, ed è per questo che una buona segmentazione ripaga durante l'incidente, non solo prima. Attenzione alle scorciatoie: collegare dispositivi personali o un portatile di casa alla rete danneggiata può diffondere il problema o distruggere le prove. Comunichi con il personale tramite un canale esterno ai sistemi colpiti e dica chiaramente che cosa non fare. Assicuratori e clienti apprezzano un'azienda che ha continuato a servirli. NetSenX mostra quali segmenti e host sono coinvolti, il che aiuta a decidere che cosa può restare online in sicurezza.

  • Almeno diverse settimane, e più a lungo dopo un'intrusione grave. Gli attaccanti che hanno mantenuto un appiglio aspettano spesso che il team di risposta abbassi la guardia, e un accesso venduto ad altri può essere usato molto più tardi. In questo periodo esamini gli alert ogni giorno, cerchi connessioni verso gli indicatori emersi dall'indagine, controlli la comparsa di nuovi account amministratore e strumenti di accesso remoto e verifichi che i backup continuino a funzionare senza essere toccati da host insoliti. Tratti ogni ripetizione dello schema originale come un nuovo incidente, non come rumore. Stabilisca in anticipo chi esamina che cosa e quando termina la vigilanza rafforzata. NetSenX rileva beaconing, scansioni, movimento laterale e volumi in uscita insoliti in ogni piano, Free compreso, e la sua cronologia degli alert, 30 giorni con Free e di più con i piani a pagamento, consente di confrontare le settimane dopo l'incidente con quelle precedenti.

  • È una riunione, tenuta entro qualche settimana dall'incidente, in cui tutti i coinvolti ripercorrono che cosa è successo e che cosa cambiare. Ricostruisca la cronologia dal registro dell'incidente, poi si ponga quattro domande: che cosa è andato bene, che cosa è andato male, che cosa non sapevamo o non avevamo, e che cosa cambieremo, con un responsabile e una data per ogni modifica. Senza cercare colpevoli: lo scopo è sistemare sistemi e procedure, non punire qualcuno, altrimenti la volta successiva gli errori verranno nascosti. Risultati tipici sono un accesso remoto chiuso, l'MFA dove mancava, un backup ora offline, un elenco telefonico che funziona, un log conservato più a lungo. Riporti i risultati nel piano e nella prossima esercitazione tabletop. Gli alert di NetSenX e il log di audit danno alla revisione una cronologia fattuale per la parte di rete.

  • Stabilisca la regola in anticipo, perché una piccola azienda ha di rado un turno di notte. Annoti quali alert giustificano svegliare qualcuno, chi è quella persona e che cosa può fare da sola: per esempio isolare una postazione, ma non spegnere il server dell'ERP. Tutto il resto aspetta il mattino, con un controllo a un orario fisso. Se esternalizza il monitoraggio, concordi per iscritto le stesse regole con il fornitore. Renda i primi passi abbastanza semplici per un non specialista: scollegare il dispositivo dalla rete, annotare l'ora, chiamare il numero indicato. Provi una volta la catena di chiamate. NetSenX invia alert con una motivazione in linguaggio semplice e gli host coinvolti, così chi viene svegliato capisce in fretta se si tratta di un backup o di una postazione che contatta un nuovo server esterno nelle ore piccole. Non Le fornisce un turno di notte.

  • Spesso sì, perché la cifratura è l'ultimo passo di una sequenza più lunga. Prima, gli attaccanti di solito devono entrare, contattare il proprio server, guardarsi intorno, raggiungere file server e backup e, nella maggior parte degli attacchi odierni, copiare dati all'esterno. Questi passi durano spesso giorni e attraversano la rete: una postazione che chiama a intervalli regolari un nuovo server esterno, un host che scansiona intervalli interni, nuove sessioni di amministrazione verso i server, un grande caricamento di notte. Gli attaccanti scelgono weekend e festivi perché nessuno guarda, non perché i passi precedenti fossero invisibili. La domanda utile è se qualcosa ha registrato quei segnali e se qualcuno avrebbe visto l'alert. NetSenX rileva beaconing, scansioni, movimento laterale e volumi in uscita insoliti in ogni piano, Free compreso; che un alert del venerdì sera venga gestito prima del lunedì dipende dalla Sua catena di allerta.

  • Troppo variabile perché un unico numero sia utile: da poche ore, quando un gruppo automatizzato sfrutta un sistema esposto, a settimane, quando l'accesso viene comprato da altri o gli attaccanti si prendono il tempo di trovare i backup e copiare i dati. Costante è la sequenza: accesso, contatto con il server dell'attaccante, ricognizione, spostamento verso i server, furto di dati e solo allora cifratura. Ogni fase è un'occasione per accorgersene. Pianifichi come se avesse poco tempo: tenga backup offline perché sopravvivano, si assicuri che l'accesso remoto richieda l'autenticazione a più fattori (MFA) e decida in anticipo chi isola un host di notte. Tratti come urgente ogni segnale delle prime fasi, come una postazione che scansiona intervalli interni. NetSenX segnala il comportamento di rete di queste fasi in ogni piano, ed è da lì che nasce il tempo per agire.

  • In due modi. Un supporto può trasportare il malware stesso, che si avvia quando qualcuno apre un file camuffato, e alcuni malware si copiano su ogni supporto che trovano per spostarsi tra computer e sedi. Inoltre, un disco collegato quando inizia la cifratura viene semplicemente cifrato con tutto il resto, ed è per questo che un backup su un disco USB sempre collegato non La protegge dal ransomware. Disattivi l'esecuzione automatica dai supporti rimovibili, analizzi i supporti sconosciuti su un computer dedicato, consenta dove possibile solo dispositivi forniti dall'azienda e scolleghi i dischi di backup dopo ogni esecuzione. Lo spagnolo INCIBE ha pubblicato un caso reale in cui un ransomware si è diffuso man mano che venivano collegati dispositivi infetti. Un trasferimento via USB non attraversa la rete, quindi un sensore di rete non lo vede; NetSenX vede ciò che il computer infetto fa dopo, come scansioni o contatti con un server esterno.

  • Conservi senza alterarlo tutto ciò che mostra che cosa è successo, quando e che cosa ha fatto. Cioè il registro dell'incidente con orari e decisioni; le esportazioni dei log di firewall, VPN, directory, posta ed endpoint; la richiesta di riscatto e ogni messaggio degli attaccanti; schermate di ciò che hanno visto gli utenti; le immagini forensi, se gli specialisti le hanno realizzate; e la documentazione dei costi sostenuti. Annoti per ogni file un hash, il luogo di conservazione e chi lo ha maneggiato. L'assicuratore di solito ha bisogno della cronologia e delle prove dei costi; la polizia dei messaggi degli attaccanti, delle richieste di pagamento e degli indicatori; l'autorità vuole sapere quali dati sono stati colpiti e come ha risposto. Chieda presto a ciascuno di che cosa ha bisogno e tenga copie fuori dai sistemi colpiti. Gli alert di NetSenX, con orari, host e destinazioni, e il suo log di audit possono far parte di questo fascicolo, con i report PDF dal piano Starter.

  • Per la cronologia degli alert del Suo piano: 30 giorni con Free e di più con ogni piano a pagamento, con i periodi esatti indicati nella pagina dei prezzi. Gli alert sono conservati con orario, host coinvolti, destinazioni, volumi e motivazioni che li hanno generati, insieme alle decisioni degli analisti nel log di audit. Se un incidente può portare a una richiesta di indennizzo, a domande di un'autorità o a una causa, non si affidi solo alla conservazione: esporti ciò che conta finché l'incidente è recente, con i report PDF dal piano Starter, e tenga l'esportazione con le altre prove. Pensi prima che accada al periodo di cui avrà bisogno: i tempi di permanenza possono essere di settimane, quindi una cronologia breve può finire prima dell'inizio dell'intrusione. I log di firewall, VPN e directory hanno una conservazione propria, spesso più breve, che conviene verificare oggi piuttosto che durante un incidente.

  • Gestisca da solo la prima ora e chiami una società per tutto ciò che va oltre un singolo dispositivo contenuto. Il Suo team conosce i sistemi, quindi deve isolare le macchine, iniziare il registro e conservare le prove. Una società esterna porta ciò che un piccolo team raramente ha: strumenti ed esperienza forense, conoscenza delle abitudini degli attaccanti, contatti con le forze dell'ordine e credibilità presso assicuratori e autorità. La chiami quando un attaccante potrebbe essere ancora attivo, quando sono colpiti server o molti dispositivi, quando dei dati potrebbero essere usciti, o quando l'incidente potrebbe essere da notificare o portare a una richiesta di indennizzo. Verifichi prima se la Sua polizza cyber indica una società, perché sceglierne un'altra può incidere sulla copertura, e concordi in anticipo quali accessi le serviranno. NetSenX non è una società di risposta agli incidenti; gli alert spiegati e la cronologia di rete che conserva sono ciò che quella società Le chiederà il primo giorno.

  • Con onestà, in modo concreto e solo con ciò che sa, poi aggiornandoli. Dica che cosa è successo e quando, quali categorie dei loro dati sono coinvolte, che cosa ha fatto, che cosa sta ancora verificando, che cosa dovrebbero fare, per esempio diffidare di phishing che usa i loro dati, e chi contattare. Eviti di dire che nessun dato è stato colpito prima che l'indagine lo confermi; una rettifica costa più fiducia di un primo messaggio prudente. Concordi il testo con il legale e con il responsabile della protezione dei dati, perché comunicarlo alle persone può essere un obbligo di legge con contenuti propri, e con l'assicuratore. Lo invii da un canale non compromesso e avverta i clienti che potrebbero circolare falsi messaggi di follow-up. Le prove rendono preciso il messaggio: gli alert di NetSenX mostrano quali host hanno inviato volumi insoliti e quando, il che aiuta a dire quali sistemi, e quindi quali clienti, sono interessati.

  • In parte. Le registrazioni di rete possono mostrare che un determinato server, quello con i dati di quel cliente, non ha inviato volumi insoliti nel periodo e che nessuna nuova destinazione esterna ha ricevuto dati da esso. È una prova significativa, soprattutto se il server di norma invia poco. Da sola però non è risolutiva: i dati potrebbero essere stati copiati prima su un'altra macchina interna e inviati da lì, spediti in piccole quantità sotto soglie evidenti o presi attraverso un canale che il sensore non osserva, come un servizio cloud usato direttamente o un segmento non monitorato. La presenti al cliente per quello che è: una prova di assenza sui percorsi monitorati, affiancata dai log del server e del cloud. NetSenX conserva alert per host sui volumi in uscita insoliti, e la sua mappa di rete mostra quali host hanno comunicato con quel server.

  • Nella maggior parte dei paesi dell'UE il CSIRT nazionale o l'agenzia per la cibersicurezza è la prima chiamata gratuita, e diversi offrono servizi per le piccole imprese. La Spagna ha la linea gratuita 017 di INCIBE; la Polonia ha CERT Polska, che riceve le segnalazioni di incidenti; la Germania ha il BSI e le unità di cybercrime delle polizie dei Länder; la Francia ha la piattaforma nazionale Cybermalveillance per le imprese e l'ANSSI per i soggetti regolamentati; l'Italia ha lo CSIRT Italia presso l'ACN; i Paesi Bassi hanno il Digital Trust Center per le imprese e l'NCSC per i settori vitali. Possono dare indicazioni, a volte indicatori e contatti, ma di solito non svolgono il lavoro di ripristino al posto Suo. La linea di assistenza della Sua assicurazione cyber, se ce l'ha, è l'altra chiamata da fare subito, e i reati vanno denunciati alla polizia. NetSenX non fornisce servizi di risposta agli incidenti, ma i suoi alert danno a chiunque chiami un punto di partenza fattuale.

  • Sì, nella maggior parte dei casi. Ransomware, estorsione, frode e furto di dati sono reati, e una denuncia aiuta gli investigatori a collegare i casi, a volte porta a chiavi di decifratura ottenute in operazioni delle forze dell'ordine ed è spesso richiesta dall'assicuratore per un sinistro. La denuncia è distinta da qualsiasi notifica regolamentare al CSIRT o all'autorità per la protezione dei dati; potrebbe doverne fare più d'una. Molti paesi hanno unità specializzate nel cybercrime o la denuncia online per le imprese, e il CSIRT nazionale può dirLe a chi rivolgersi. Porti i fatti: cronologia, richiesta di riscatto e messaggi, richieste di pagamento, indicatori come indirizzi IP e domini, e i costi sostenuti finora. Denunciare non significa perdere il controllo del ripristino e di solito non rende pubblico l'incidente. Gli alert di NetSenX, con orari, host e destinazioni, possono far parte di ciò che consegna.

  • A volte, dagli effetti collaterali più che dall'intenzione. Lo spagnolo INCIBE ha pubblicato un caso reale in cui un dipendente ha introdotto codice malevolo e rubato un milione di euro. Casi del genere si basano su accessi che la persona ha già, quindi la prevenzione sta nei processi: separazione dei compiti per i pagamenti, approvazione di una seconda persona, revisione del codice per le modifiche ai sistemi finanziari e rapida revoca degli accessi quando cambiano i ruoli. Segnali tecnici possono comunque comparire: una postazione che contatta un server esterno sconosciuto, nuove connessioni al sistema dei pagamenti o all'ERP da una macchina che non li aveva mai usati, invii insoliti. NetSenX osserva dispositivi e connessioni, mai persone: può segnalare quel comportamento in rete, in ogni piano, ma non giudica l'intenzione e non vede ciò che accade dentro un'applicazione. Indagare su una persona spetta alle risorse umane e ai legali, e alle rappresentanze dei lavoratori dove esistono.

  • Controlli prima le cause ordinarie, poi cerchi i segni di un attacco. Molti blocchi dipendono da un certificato o un dominio scaduti, da un disco pieno, da un aggiornamento fallito o da un problema del provider di hosting. Chieda al provider e guardi la sua pagina di stato, poi i log del server web: un'improvvisa ondata di richieste da molti indirizzi indica un attacco di negazione del servizio; pagine modificate, nuovi account amministratore o file sconosciuti una compromissione del sito stesso; un record DNS cambiato un attacco alla registrazione del dominio. Conservi i log prima di riavviare qualsiasi cosa. Se il sito contiene dati dei clienti o incassa pagamenti, tratti una compromissione come una possibile violazione dei dati. NetSenX non protegge siti pubblici ospitati fuori dalla Sua rete; se il server web è nella Sua rete, mostra le connessioni in uscita e i volumi insoliti che ne partono.

  • No, e la differenza sta in dove agisce ciascuno. Un attacco di negazione del servizio distribuito (DDoS) inonda il Suo sito, la VPN o la linea internet di traffico proveniente da molte macchine finché non rispondono più. Fermarlo richiede capacità a monte: presso il provider internet, in una rete di distribuzione dei contenuti (CDN) o in un servizio di scrubbing che assorbe e filtra l'ondata prima che raggiunga la Sua linea. Il rilevamento di rete in azienda, come NetSenX, osserva il comportamento dei Suoi host per trovare intrusi, beaconing, scansioni, movimento laterale e dati in uscita; non blocca il traffico e non ha la banda per assorbire un'ondata. Chieda al provider quale protezione DDoS ha oggi la Sua linea e, per i servizi pubblici, valuti un hosting protetto. Alcuni attacchi DDoS servono da diversivo, quindi verifichi che all'interno non stia succedendo nient'altro durante il blocco.

  • Prove e tempi, non braccia in più. Durante un incidente NetSenX Le fornisce alert su beaconing, scansioni, movimento laterale e volumi di dati in uscita insoliti, in ogni piano, ciascuno con una motivazione in linguaggio semplice, gli host coinvolti, destinazioni, volumi e orari, e la tecnica MITRE ATT&CK quando ce n'è una; la mappa di rete di chi parla con chi; un log di audit di alert e decisioni degli analisti; e il monitoraggio delle scadenze dell'articolo 23 della NIS2, con una notifica ai sensi dell'articolo 33 del GDPR preparata per il responsabile della protezione dei dati, mentre l'invio resta a Lei. Dal piano Starter si aggiungono i report PDF e le raccomandazioni di risposta, dal piano Pro la correlazione degli host in un'unica storia. Non elimina gli attaccanti, non ripristina i dati e non negozia, e non vede dentro le sessioni cifrate né sui segmenti che non monitora. Di questo si occupano il fornitore di risposta, gli strumenti degli endpoint e i backup.

  • Prima gli chiuda la porta, poi faccia domande. Sospenda gli account del fornitore, il suo accesso VPN e gli strumenti di assistenza remota sui Suoi sistemi finché non conferma che cosa è stato colpito, e cambi le credenziali condivise o le chiavi API. Gli chieda per iscritto che cosa è successo e quando, quali suoi sistemi erano coinvolti, se i Suoi dati o le Sue credenziali di accesso sono stati esposti e quali indicatori di compromissione possiede, poi li cerchi nei Suoi log. Verifichi che cosa poteva raggiungere il suo accesso: quali server, quali dati. Tratti con cautela le sue e-mail relative ai pagamenti, perché i thread di posta rubati vengono riutilizzati per le frodi sulle fatture. Se i Suoi dati sono stati esposti tramite lui, potrebbe avere obblighi di notifica propri. Rilegga il contratto per le clausole di sicurezza e di notifica. NetSenX rileva beaconing e sessioni insolite dagli host usati dal fornitore, e la sua mappa di rete mostra con che cosa quegli host hanno davvero comunicato.

  • Perché la bonifica è diversa. Un account compromesso significa che qualcuno ha la password o la sessione di un utente, utilizzabili da qualsiasi luogo: la soluzione è reimpostare le credenziali, revocare le sessioni, controllare le regole della casella di posta e imporre l'autenticazione a più fattori (MFA), e le prove stanno nei log di identità e dei servizi. Un dispositivo compromesso significa che qualcuno controlla la macchina stessa, spesso con un malware: la soluzione è isolarla e ricostruirla, e le prove stanno sull'endpoint e nel suo traffico di rete. Molti incidenti coinvolgono entrambi, come password rubate da un portatile infetto o un account usato per installare strumenti su un server. Capisca quale dei due ha prima di scegliere le azioni, altrimenti reimposterà le password su un dispositivo che cattura quelle nuove. NetSenX vede il lato dispositivo sulla rete: una macchina che chiama un server esterno, scansiona o apre nuove sessioni. L'abuso di un account dall'esterno della rete riguarda i log di identità.

← Tutti i temi