NetProbe è oggi in sviluppo e validazione in ST-LINE su simulatore di rete proprietario. Non ci sono ancora deployment esterni; il primo pilota è previsto nel terzo trimestre 2026. Questo post non è materiale di vendita — è un aggiornamento sullo stato del prodotto e sulle scelte architetturali che lo hanno definito.
Da insieme di tool a prodotto
NetProbe non è nato da un’analisi di mercato. È nato dal raggruppamento di strumenti proprietari che usavamo internamente per audit di sicurezza sulle reti dei nostri clienti. Discovery di asset, scan vulnerabilità, parsing log firewall, audit TLS: ognuno era uno script o un piccolo tool dedicato. La frizione era nell’assemblarli e produrre evidenze coerenti per un audit ISO 27001 o NIS2 ogni volta che un cliente lo chiedeva.
Sui clienti PMI italiani che assistevamo, abbiamo notato sempre lo stesso pattern. Asset inventory in fogli Excel sempre obsoleti. Log firewall che generano grandi volumi di eventi che nessuno analizza. Incidenti rilevati tardi. Strumenti enterprise — Darktrace, Vectra, Claroty — valutati ma fuori scala per budget e per team. La PMI italiana non ha un SOC, ha un IT manager che fa anche altre quattro cose.
Consolidare quei tool in un prodotto integrato significava risolvere il problema una volta sola invece che ogni volta. È diventato NetProbe.
Perché passive
La scelta architetturale fondante è che il piano di osservazione di NetProbe è passivo. Riceve traffico in copia da una mirror port, o telemetria già esistente come NetFlow e syslog firewall. Non si autentica su nessun apparato, non scrive su nulla, non blocca traffico.
Va detto subito, perché altrimenti la parola «passiva» copre più di quanto dovrebbe: fra le funzioni sviluppate c’è anche un port scan con CVE matching, e un port scan è probing attivo. I due piani sono distinti e vanno trattati come tali — osservazione passiva sempre disponibile, assessment attivo disattivato per default e da abilitare solo su autorizzazione esplicita, con una finestra concordata. Presentare l’insieme come «sonda passiva» sarebbe scorretto verso chi deve dare quell’autorizzazione.
Due motivi concreti. Il primo è operativo: l’approval del cliente è più rapido. Una sonda che si limita a osservare ha un profilo di rischio operativo molto più semplice da valutare — non nullo, perché restano il carico sulla mirror port, la gestione dell’apparato e il trattamento dei dati raccolti, ma le discussioni con IT e security team sono più brevi. Una sonda attiva o agent-based richiede settimane di valutazione, test in staging, approvazione formale. La differenza fra “installazione in giorni” e “deployment in mesi” sta quasi tutta lì.
Il secondo motivo è la copertura. Negli ambienti misti IT/OT — manifatturiero, sanità, energia — molti dispositivi non accettano agent. PLC, HMI, telecamere IP, broker MQTT, dispositivi BACnet: sistemi legacy o industriali dove un agent non è un’opzione tecnica. Una sonda passiva li vede tutti dallo stesso punto di osservazione, senza dover toccare nessuno.
Perché on-premise (e AI locale)
NetProbe gira interamente in casa del cliente: cattura, analisi, AI, archiviazione, reportistica. Cloud opzionale, mai obbligatorio.
In settori regolamentati questa è una posizione di vincolo, non una preferenza. Trasferire dati di rete a un fornitore cloud apre un capitolo che le PMI italiane non hanno il tempo di affrontare: trasferimenti extra-UE, sub-responsabili, registri Art. 30 GDPR. Se l’analisi gira sull’appliance del cliente, il capitolo dei trasferimenti non si apre. Attenzione a non estenderlo troppo: restare on-premise elimina il trasferimento, non gli obblighi. Il registro dell’art. 30 riguarda le attività di trattamento, non il fatto che i dati escano dall’azienda — e un’appliance che cattura traffico di rete tratta dati personali comunque, con la sua base giuridica, la sua informativa e i suoi tempi di conservazione. Funziona anche in ambienti air-gap, dove ci sono clienti industriali e sanitari per cui è condizione di accettazione.
L’AI locale segue lo stesso vincolo. NetProbe usa modelli open-weight Llama eseguiti localmente; provider cloud (Claude, Gemini, OpenAI) sono opzionali e richiedono pseudonimizzazione di IP, MAC e hostname prima di qualsiasi invio. La pseudonimizzazione è un’invariante architetturale e non un’impostazione: sta nel percorso dati, non in una casella da spuntare.
Detto questo, due precisazioni che contano piu’ della formula. La prima è giuridica: pseudonimizzare IP, MAC e hostname non anonimizza. Se la re-identificazione è possibile con informazioni aggiuntive — e in una rete censita lo è, perché la mappa inversa è l’inventario stesso — il dato resta personale ai sensi del GDPR, con tutto ciò che ne segue. La pseudonimizzazione è una misura di sicurezza, non un’uscita dal perimetro. La seconda è di metodo: «non aggirabile» è un’affermazione di sicurezza, e come tale va sostenuta con test e revisione del codice pubblicabili, non con un’asserzione. Finché quel materiale non c’è, la formulazione corretta è che il percorso è progettato perché non sia aggirabile.
Calibrato sulla PMI italiana significa anche cose concrete: parser syslog per i firewall effettivamente diffusi qui (WatchGuard, Sophos, Fortinet, pfSense, OPNsense), supporto a Windows Event Log di Active Directory on-premise, interfaccia e report in italiano di default. NIS2 italiana, GDPR italiano, auditor italiano.
Cosa NetProbe deliberatamente non fa
NetProbe non sostituisce un firewall, un EDR, un SIEM o un SOC. Non blocca traffico, non scrive su apparati. Non garantisce zero falsi positivi — sarebbe matematicamente falso, e l’auditor lo sa. Non rende un’organizzazione conforme al 100% a nessun framework: la conformità è un attributo dell’organizzazione, non di uno strumento installato in rete.
Quello che fa, lo fa con riscontri verificabili: rileva pattern noti su una rete che il cliente non vedeva prima, raccoglie automaticamente evidenze per gli audit di conformità, fornisce un dossier tecnico utilizzabile senza doverlo riscrivere. La lista delle cose che non fa è centrale: chi compra un prodotto promettendo che risolve tutto ha già perso il cliente al primo confronto con la realtà.
Stato attuale
In laboratorio interno sono sviluppate e provate sui nostri casi — non ancora validate su un pilota cliente, e senza un pacchetto di evidenza pubblicabile: cattura passiva con riconoscimento protocollare, asset inventory live, port scan con CVE matching contro NVD, audit SSL/TLS offline, engine di correlazione con baseline statistica e mapping MITRE ATT&CK, AI conversazionale Llama locale, pseudonimizzazione invariante, audit log immutabile, ROPA, IoT/OT analyzer, esportazione SIEM, report multi-formato con narrativa AI.
In delivery per il 2026: AI Watcher proattivo, detection plane unificato fra regole e AI, modelli locali fine-tuned, esperienza utente semplificata. Primo pilota su cliente reale: terzo trimestre 2026.
Che cosa un tool può e non può fare
L’AI locale non è una feature, è la condizione di ingresso. In settori regolamentati, se l’AI gira in cloud, non c’è prodotto da vendere — c’è solo un capitolo nuovo del registro dei trattamenti che il cliente deve scrivere. Le PMI italiane non hanno il tempo di scrivere quel capitolo, e i loro auditor non hanno la pazienza di leggerlo. NetProbe parte da questa restrizione e ne fa la fondazione architetturale, non un compromesso.
NetProbe è in sviluppo. Se lavori in una PMI italiana soggetta a NIS2, ISO 27001 o IEC 62443, o sei un consulente che gestisce audit periodici sui propri clienti, e vuoi essere fra le prime organizzazioni di pilota nel 2026, scrivici.