NetSenX: piani e avvio
20 domande su NetSenX: piani e avvio, in linguaggio semplice: cosa verificare, cosa mostra NetSenX e cosa un sensore non vede.
Ogni piano, Free compreso, rileva beaconing, scansioni, movimento laterale e volumi in uscita insoliti, spiega ogni avviso in linguaggio semplice e tiene una mappa di rete; i piani superiori aggiungono report, integrazioni e monitoraggio specializzato. Free costa 0 € per un massimo di 3 dispositivi con 30 giorni di storico avvisi, oltre al monitoraggio delle scadenze NIS2, a un registro di audit e all'accesso a due fattori. Free e Solo coprono i computer su cui è installato l'agente; un sensore di rete su una porta SPAN o TAP è disponibile a partire da Starter. Starter, a 49 € al mese per un massimo di 10 dispositivi, aggiunge report PDF, azioni di risposta manuali, gestione del team e impronta TLS dove l'agente cattura i pacchetti. Solo, a 19 € al mese, offre il rilevamento, i report e le azioni di risposta di Starter per esattamente un computer, quello su cui è installato l'agente, e un utente, senza gestione del team né dispositivi aggiuntivi. Pro, a 99 € per un massimo di 25 dispositivi, aggiunge visibilità sullo Shadow AI, monitoraggio passivo dei protocolli OT, API, Slack e webhook, e l'inventario crittografico NQCI, che richiede la cattura dei pacchetti su Linux o un sensore SPAN o TAP. Business, a 249 € per un massimo di 100 dispositivi, aggiunge l'esportazione verso il SIEM e la simulazione di violazioni e attacchi. Enterprise, da 999 €, aggiunge dispositivi illimitati, politiche di rilevamento personalizzate, white label, installazione on-premise e single sign-on. Prezzi mensili, IVA esclusa. Report: Free: Nessun report (istruzioni per l'uso AI Act incluse). Solo e Starter: Report operativi (incidente NIS2, GDPR, mensile, MITRE); pacchetto audit con fatturazione annuale. Pro, Business ed Enterprise: Tutti i report, compreso il pacchetto audit.
A scelta: un agente collegato a una porta SPAN o TAP sorveglia un intero segmento di rete, oppure si installa l'agente sugli host da monitorare. L'agente funziona come servizio di sistema su Linux e macOS; su Linux il programma di installazione accetta solo un pacchetto firmato con la chiave di rilascio di NetSenX, mentre gli agenti per macOS si configurano insieme al supporto NetSenX. La dashboard è un servizio ospitato nell'UE; un'opzione on-premise è disponibile nel piano Enterprise.
La modalità di distribuzione la sceglie Lei: una singola porta SPAN/TAP sullo switch copre un intero segmento di rete e conta come un dispositivo, oppure installa l'agente NetSenX sugli host che preferisce. Entrambi sono documentati; nessun modulo del kernel. Su Linux il programma di installazione installa solo un pacchetto la cui firma corrisponde alla chiave di rilascio NetSenX e rifiuta tutto il resto; gli agenti per macOS vengono configurati insieme al supporto NetSenX.
L'agente NetSenX funziona su Linux e macOS, e un solo agente su una porta SPAN o TAP osserva ogni dispositivo di quel segmento, qualunque sistema operativo usi. Su Linux l'agente si installa come servizio di sistema con un comando di una riga fornito dalla dashboard, e il programma di installazione accetta solo un pacchetto firmato con la chiave di rilascio di NetSenX. Su macOS si installa da un pacchetto firmato e gira come servizio in background; gli agenti macOS si configurano insieme al supporto NetSenX. Se in azienda ha anche computer con altri sistemi operativi, oppure stampanti, telecamere, telefoni e macchine su cui non può girare alcun agente, metta un agente su un host collegato a una porta mirror: vedrà il loro traffico senza installare nulla su di essi. Di solito è il modo più semplice per coprire un ufficio eterogeneo. L'agente non vede il traffico dei segmenti che non copia né l'attività interna di un computer che non tocca mai la rete.
È progettato per non farlo, e il modo più sicuro per non caricare un server è non installarlo affatto lì: un agente su un host collegato a una porta mirror osserva l'intero segmento senza toccare i server che vi si trovano. Una porta mirror copia il traffico all'interno dello switch, quindi i server monitorati non elaborano nulla in più, e il percorso di rete non cambia: il sensore riceve solo una copia. Se installa l'agente su un server, questo legge i metadati delle connessioni e alcuni campi di protocollo, come orari, volumi, destinazioni, risposte DNS e, dove cattura i pacchetti, l'handshake TLS. Non decifra mai il traffico e non fa da proxy né blocca connessioni. Come per qualsiasi nuovo software su un server molto carico, controlli l'uso delle risorse nei primi giorni e inizi con un pilota su un host meno critico. Prima di installarlo su collegamenti con traffico molto elevato, contatti il supporto NetSenX.
La modalità di base vede connessioni, orari e volumi; la cattura dei pacchetti legge anche i campi non cifrati dell'handshake TLS, che servono ad alcune funzioni. Su macOS l'agente gira in una modalità di base che osserva le connessioni del Mac su cui è installato. Basta per i rilevamenti principali, come beaconing, scansioni, movimento laterale e volumi in uscita insoliti. Cattura dei pacchetti significa che l'agente copia i pacchetti stessi per leggere alcuni campi di protocollo, sempre senza decifrare nulla. È disponibile dove l'agente gira su Linux o come sensore su una porta SPAN o TAP. Due funzioni ne dipendono: l'impronta TLS, dal piano Starter, che riconosce client di malware noti dal loro handshake, e l'inventario crittografico NQCI, attivo dal piano Pro, che mostra lo scambio di chiavi vulnerabile al calcolo quantistico e quello ibrido. Se Le serve una delle due, preveda un agente Linux o un sensore su porta mirror.
NQCI è visibile in ogni piano come anteprima, è attivo dal piano Pro e richiede il sensore di cattura dei pacchetti, disattivato per impostazione predefinita. Servono due cose. Primo, un piano Pro, Business o Enterprise. Secondo, un agente che catturi i pacchetti: un agente Linux con la cattura dei pacchetti attivata, oppure un agente su un host collegato a una porta SPAN o TAP. La modalità di base su macOS non vede gli handshake TLS e quindi non può alimentare l'inventario. Una volta attivo, NQCI mostra quali connessioni che attraversano il segmento monitorato usano uno scambio di chiavi vulnerabile al calcolo quantistico e quali usano già uno scambio ibrido post-quantistico, oltre alle versioni dei server SSH che vede. È ancora in anteprima. Non vede la crittografia dentro le applicazioni o sui dischi, non migra nulla e non svolge al posto Suo il lavoro di conformità; Le dà un primo inventario dalla rete.
Sì, avvisi e inventario dei dispositivi partono appena scorre il traffico, ma i confronti con il comportamento normale di ogni host migliorano man mano che NetSenX impara la Sua rete. Il primo giorno vedrà comparire i dispositivi sulla mappa di rete, e schemi evidenti come scansioni o chiamate regolari verso l'esterno genereranno avvisi. Richiede più tempo ciò che dipende dalla storia: sapere che il server amministrativo non parla mai con un certo host, o che un grosso trasferimento alle 2 è insolito per quella macchina ma normale per il server di backup. Le prime settimane richiedono più attenzione da parte Sua, mentre conferma e contrassegna l'attività normale. Non esiste un modello già pronto che conosca la Sua rete al giorno zero. Il limite dei falsi positivi, parte della NetSenX Math Guarantee, viene mostrato solo quando i Suoi dati etichettati lo sostengono; fino ad allora la dashboard lo dice invece di mostrare un numero.
È un inventario aggiornato dei dispositivi che NetSenX vede nei Suoi segmenti monitorati, con chi parla con chi, ed è incluso in ogni piano, Free compreso. Per ogni dispositivo mostra il nome che annuncia in rete, l'indirizzo, la prima e l'ultima comparsa e le connessioni verso altri dispositivi e verso destinazioni esterne. Le destinazioni cloud e di hosting finiscono in una coda di revisione, così può decidere se un server che parla con una macchina cloud appena noleggiata è previsto. La mappa si costruisce in modo passivo dal traffico: NetSenX non scansiona né interroga mai i dispositivi, il che è sicuro per stampanti, telecamere e apparecchiature industriali. Il rovescio della medaglia: un dispositivo che non invia mai traffico, o che si trova su un segmento che non copia, non compare. Molti clienti usano la mappa nella prima settimana per trovare server dimenticati, dispositivi sconosciuti e apparecchi che non dovrebbero esserci.
In ogni piano gli avvisi compaiono nella dashboard e vengono inviati via e-mail; dal piano Pro possono andare anche su Slack, a un webhook o ai Suoi sistemi tramite API, e dal piano Business al Suo SIEM. L'e-mail si adatta a un piccolo team: invii gli avvisi a una casella condivisa o a due persone, così qualcuno li vede quando l'amministratore è assente. Un webhook permette di inoltrare gli avvisi a un sistema di ticket, a uno strumento di chat o a un servizio di reperibilità che il Suo fornitore IT già usa. L'esportazione verso il SIEM mette i rilevamenti di rete accanto ai dati dei log. Qualunque sia il canale, ogni avviso porta la stessa spiegazione in linguaggio semplice: che cosa è successo, su quale host e perché è stato generato. Decida in anticipo chi legge gli avvisi di notte e nei fine settimana: NetSenX rileva a ogni ora, ma non gestisce un servizio presidiato che La chiama.
Dipende dal piano: il piano Free conserva 30 giorni di storico avvisi, ogni piano superiore più a lungo ed Enterprise senza limiti di tempo; la tabella prezzi indica il periodo esatto per ogni piano. Lo storico degli avvisi conta più di quanto sembri. Quando si scopre un incidente, investigatori e assicuratori chiedono quando è iniziato, e la risposta spesso risale a settimane prima; se il Suo storico è più breve del tempo trascorso dall'attaccante nella rete, le prove sono perse. Il registro di audit, che annota chi ha modificato cosa e che cosa è stato fatto per ogni avviso, è conservato a parte, con un proprio periodo predefinito per piano. Scelga il piano pensando all'incidente, non solo al numero di dispositivi: un'azienda che deve notificare ai sensi della NIS2 o rispondere alle domande di un assicuratore può aver bisogno di più storico di quanto suggeriscano le sue dimensioni. Se disdice un piano a pagamento, l'account prosegue sul piano Free con i suoi periodi di conservazione.
Sì. Gli avvisi di tunneling DNS sono inclusi in ogni piano, anche in Free e Starter. Il tunneling DNS nasconde dati o comandi dentro le query DNS, di solito come nomi lunghi e dall'aspetto casuale inviati a un unico dominio. NetSenX genera avvisi su questo schema. Altri rilevamenti legati al DNS sono ancora in fase di misurazione e non generano ancora avvisi, quindi NetSenX non afferma di rilevare altri tipi di abuso del DNS. Indipendentemente da NetSenX, può ridurre il rischio instradando tutto il DNS sui Suoi resolver, bloccando il DNS diretto verso internet dalle postazioni e conservando i log dei resolver. Ricordi che il DNS cifrato inviato via HTTPS a un fornitore esterno non è visibile come DNS per nessun sensore di rete.
Contrassegni come previsto esattamente quel job, invece di disattivare il rilevamento: il server di backup, la sua destinazione e la sua fascia oraria, niente di più ampio. Un backup notturno sposta molti dati, spesso verso un fornitore di archiviazione esterno, il che per qualsiasi strumento che osserva i volumi sembra un furto di dati. La prima volta che compare l'avviso, verifichi che sia il backup: confronti host, destinazione e orario con il Suo software di backup. Poi contrassegni quell'avviso come falso positivo in NetSenX, così gli avvisi simili di quel job vengono riconosciuti. Lasci attivo il rilevamento per ogni altro host: lo stesso trasferimento da una postazione, o dal server di backup verso una nuova destinazione, deve ancora generare un avviso, perché anche gli attaccanti portano fuori dati di notte. Annoti la decisione e la riveda quando cambia la configurazione dei backup. NetSenX conserva ogni decisione nel registro di audit, così potrà mostrare in seguito perché un avviso è stato chiuso.
È l'affermazione che, tra gli avvisi segnalati dallo strumento, la quota di falsi allarmi resta sotto un livello indicato, con una confidenza indicata, misurata sulla Sua rete. Per un piccolo team risponde alla domanda pratica: quanta parte del mio tempo dedicato agli avvisi andrà sprecata? NetSenX ricava questo limite con un metodo split-conformal dal traffico benigno che il Suo team ha etichettato nel Suo tenant. La riserva è onesta: un limite vale quanto i dati che lo sostengono. Con pochi avvisi etichettati il metodo non può sostenere un limite stretto, quindi la dashboard dice che nessun limite è ancora possibile e che cosa manca, invece di mostrare un numero rassicurante. Man mano che contrassegna gli avvisi nelle prime settimane e nei primi mesi, il limite diventa possibile. È una proprietà dei Suoi dati, non un tasso fisso promesso da NetSenX, ed è incluso in ogni piano come parte della NetSenX Math Guarantee.
È un limite verificabile di falsi positivi tra gli avvisi segnalati dal motore, ricavato con la predizione conforme (split-conformal) dal traffico benigno che i vostri analisti hanno etichettato sulla vostra rete, al livello di confidenza che scegliete. La dashboard mostra il limite solo quando i dati di calibrazione lo sostengono; fino ad allora lo dice invece di mostrare un numero. Descrive un metodo e ciò che i vostri dati sostengono oggi, non un tasso fisso. È inclusa in ogni piano.
Garantisce un metodo, applicato ai Suoi dati, e piena visibilità su ciò che questo metodo attualmente supporta. Un livello split-conformal deriva un limite di falsi positivi per gli alert segnalati dal motore, a un livello di confidenza configurabile, a partire da traffico benigno etichettato dagli analisti nel Suo stesso tenant. Un set di calibrazione finito può risolvere un limite solo fino a una certa precisione, quindi la dashboard mostra il limite che i Suoi dati supportano — e dichiara esplicitamente quando non ne supportano ancora nessuno, indicando cosa servirebbe per colmare il divario, invece di mostrare un valore che non potremmo giustificare. La metodologia è documentata nel nostro Trust Center ed è verificabile in modo indipendente.
No. NetSenX rileva e avvisa a qualsiasi ora, ma è un software: nessuno in NetSenX sorveglia i Suoi avvisi 24 ore su 24 né risponde al posto Suo. La differenza conta quando descrive la Sua sicurezza a un assicuratore, a un revisore o a un cliente. Dire che il rilevamento funziona 24 ore su 24 è vero; dire che qualcuno risponde 24 ore su 24 è vero solo se Lei lo organizza. Soluzioni che funzionano per piccole e medie imprese: inviare gli avvisi via e-mail a due persone anziché a una; usare un webhook, dal piano Pro, per raggiungere un servizio di reperibilità del Suo fornitore IT; concordare con un MSP o un MSSP che riceva gli avvisi e intervenga fuori orario; e tenere a portata di mano il numero di una società di risposta agli incidenti. Se Le servono persone che sorvegliano 24 ore su 24, un fornitore di managed detection and response (MDR) offre questo servizio, e gli avvisi di NetSenX possono essergli inoltrati.
Non blocca il traffico, non decifra le sessioni, non protegge gli endpoint, non filtra la posta, non gestisce le identità, non esegue backup e non fornisce un servizio di sicurezza presidiato da persone. NetSenX osserva il comportamento della rete e spiega gli avvisi. Non legge mai il contenuto delle sessioni cifrate, quindi non può dirLe che cosa c'era in un file caricato né che cosa qualcuno ha scritto in uno strumento di IA. Non vede ciò che accade dentro un computer senza toccare la rete, i dispositivi che restano in silenzio né i segmenti che non copia. Non vede gli accessi a VPN, directory o servizi cloud, quindi una password rubata ma valida, usata normalmente, può sembrare lavoro ordinario. Non decide se un incidente va notificato e non presenta notifiche alle autorità. Per queste lacune servono protezione degli endpoint o EDR, sicurezza della posta, autenticazione a più fattori e log delle identità, backup verificati e persone in grado di rispondere. NetSenX lavora al loro fianco.
I clienti Enterprise ricevono evidenze mappate su SOC 2 Type I (in progress), ISO 42001 (gestione dell'IA) e ISO 27001. Ogni controllo include artefatti con marca temporale, attestazioni dei subresponsabili e una vista esportabile per il revisore, aggiornata in tempo reale.
Sì. L'onboarding Business ed Enterprise include una transizione strutturata: due settimane di funzionamento in parallelo, mappatura della tassonomia degli alert e migrazione dei playbook degli analisti.