Fonctionnalités de NetSenX
Ce que NetSenX fait sur votre réseau, et comment le vérifier
NetSenX observe le comportement des hôtes de votre réseau, déclenche une alerte quand ce comportement ressemble à une attaque et explique chaque alerte en langage clair. Les résultats de détection passent par une couche conforme qui indique la confiance qui les accompagne, et chaque version de modèle est enregistrée. Voici ce que fait chaque fonctionnalité, l'offre qu'elle demande et ce qu'elle ne fait pas.
Détection comportementale
Le comportement, pas les signatures
Le moteur évalue le comportement de chaque hôte sur le réseau : même une nouvelle variante de malware sans signature laisse une trace.
Il guette les étapes qui précèdent une fuite de données : le beaconing C2 (command-and-control), les scans, les mouvements latéraux et les volumes inhabituels de données sortantes.
NetSenX fonctionne aux côtés de votre EDR et de votre SIEM. Il ajoute la vue réseau qui leur manque ; il ne les remplace pas.
L'essentiel
- Beaconing C2 (command-and-control)
- Scans et mouvements latéraux
- Volume inhabituel de données sortantes
Faux positifs bornés
NetSenX Math Guarantee
Une couche split-conformal calcule une borne de faux positifs valable sur échantillon fini pour les alertes remontées par le moteur, au niveau de confiance que vous configurez, à partir du trafic légitime que vos analystes ont étiqueté sur votre propre réseau. La borne découle de la construction, et non d'un seuil ajusté jusqu'à ce que les chiffres soient flatteurs.
Chaque alerte indique sa confiance en termes clairs, avec la version du modèle qui l'a produite, et une alerte dont le score n'est pas calibré est signalée comme préliminaire. Vos auditeurs voient les mêmes preuves que votre équipe.
Votre tableau de bord affiche la borne que vos données de calibration permettent aujourd'hui. Si elles n'en permettent encore aucune, il le dit et indique ce qui manque, au lieu d'afficher un chiffre qu'il ne peut pas justifier.
L'essentiel
- Borne split-conformal à un niveau de confiance déclaré
- Un état clair « pas encore établie » plutôt qu'un chiffre inventé
- Incluse dans toutes les offres, Free compris
Mouvements latéraux
Corrélation à l'échelle du réseau
La détection au niveau du flux voit ce qui se passe sur une connexion. Une attaque s'arrête rarement à un hôte : après la première prise, l'intrus scanne, se connecte à la machine suivante et progresse vers les données.
À partir de l'offre Pro, NetSenX relie les hôtes de votre réseau dans un graphe de qui parle à qui. Les mouvements latéraux et les groupes d'hôtes qui émettent vers la même destination apparaissent ainsi comme une seule histoire plutôt que comme des alertes éparses.
Ces alertes incluent les hôtes et les connexions qui les sous-tendent, prêts pour un rapport d'incident ou une notification à votre autorité.
L'essentiel
- Mouvements latéraux et clusters C2 entre hôtes
- Les hôtes et connexions derrière chaque alerte
- Technique MITRE ATT&CK nommée lorsqu'elle correspond
Trafic chiffré
NetSenX TLS Fingerprint Engine
Les outils d'attaque laissent une signature dans la négociation TLS avant de déplacer la moindre donnée. À partir de l'offre Starter, NetSenX lit les paramètres de la négociation et repère les clients suspects dès ce moment, avant tout échange de contenu. La négociation n'est visible que là où l'agent capture les paquets : sous Linux ou comme sonde sur un port SPAN ou TAP, pas dans le mode de base utilisé sous macOS.
Cela fonctionne sur les connexions chiffrées sans les déchiffrer : aucun proxy d'interception à exploiter, aucun certificat à installer sur vos appareils.
Une seule négociation alimente à la fois le score comportemental de l'hôte et la corrélation à l'échelle du réseau.
L'essentiel
- Identification dès la négociation, avant tout contenu
- Aucun déchiffrement TLS
- Alimente la détection par hôte et à l'échelle du réseau
Tri en langage clair
NetSenX AI Analyst Core
Beaucoup d'alertes NDR arrivent sous forme de champs bruts et repartent en tickets. Une fois l'AI Analyst Core activé, chaque alerte reçoit une note en langage clair : ce qui s'est passé, pourquoi c'est important et quoi faire ensuite.
Les notes sont rédigées par des modèles aux versions figées et à la provenance enregistrée, et structurées pour les déclarations au titre de l'article 14 du CRA et de l'article 21 de NIS2 : les faits dont votre rapport d'incident a besoin sont déjà réunis.
Il fonctionne avec votre propre clé de fournisseur d'IA dans chaque offre payante et reste désactivé tant que vous ne l'avez pas configuré. La détection fonctionne sans lui.
L'essentiel
- Une note en langage clair par alerte
- Structurée pour les déclarations CRA et NIS2
- Version du modèle enregistrée sur chaque note
OT / ICS · à partir de l'offre Pro
Protocoles industriels, observés passivement
Modbus/TCP, DNP3, BACnet/IP, EtherNet/IP et S7comm sont analysés à partir d'une capture passive sur un port SPAN ou TAP.
Les équipements classés OT ne sont jamais sondés activement : aucun risque pour les automates ni pour le SCADA, et rien ne change sur les contrôleurs.
Le trafic OT apparaît dans le même tableau de bord que le réseau IT, avec la même explication en langage clair sur chaque alerte.
L'essentiel
- Modbus/TCP, DNP3, BACnet/IP, EtherNet/IP, S7comm
- Aucun sondage actif des équipements OT
- À partir de l'offre Pro
Shadow AI · à partir de l'offre Pro
Voyez quels services d'IA votre réseau utilise
NetSenX signale le trafic vers des services d'IA externes et vers des environnements de modèles de langage exécutés sur vos propres machines, afin que l'usage non autorisé de l'IA devienne visible avant de devenir un sujet de protection des données.
Vous voyez quel hôte a joint quel service d'IA, quand, et quel volume de données a circulé. Le trafic chiffré n'est jamais déchiffré : le contenu d'un prompt reste illisible.
Commencez par établir ce qui est réellement utilisé, puis rédigez une politique d'IA que vos équipes peuvent suivre.
L'essentiel
- Services d'IA externes et modèles exécutés en local
- Quel hôte, quel service, quel volume
- À partir de l'offre Pro
Preuves incluses
Conformité prête pour l'audit
NetSenX suit chaque incident selon les délais de l'article 23 de NIS2 — alerte précoce sous 24 heures, notification sous 72 heures, rapport final sous un mois — et prépare pour votre DPO une notification de violation au titre de l'article 33 du RGPD. La transmission reste de votre ressort.
Les alertes, les décisions des analystes et les changements de configuration sont inscrits dans un journal d'audit que vous pouvez remettre à votre auditeur, et les preuves sont organisées pour les revues CRA, NIS2, RGPD et AI Act.
SOC 2, ISO/IEC 42001 et ISO/IEC 27001 sont en préparation ; aucun n'est encore obtenu, et nous ne publions une date qu'une fois l'audit planifié.
L'essentiel
- Délais NIS2 suivis pour chaque incident
- Journal d'audit des alertes, décisions et changements
- SOC 2, ISO 42001 et ISO 27001 en préparation
NetSenX Math Guarantee
Une borne de faux positifs que vous pouvez vérifier, pas un chiffre à croire sur parole.
Une couche split-conformal se place après la détection et calcule une borne de faux positifs pour les alertes remontées par le moteur, au niveau de confiance que vous configurez, à partir du trafic légitime étiqueté par vos analystes sur votre propre réseau. Votre tableau de bord affiche la borne que ces données permettent aujourd'hui et, si l'ensemble de calibration est trop petit, le dit au lieu d'afficher un chiffre.
Prédiction split-conformal
Chaque alerte indique sa confiance en termes clairs, et le dit quand son score n'est pas encore calibré. Là où la garantie statistique s'applique, la borne de faux positifs parmi les alertes remontées découle de la construction du prédicteur à un niveau de confiance déclaré ; ce n'est pas un seuil ajusté jusqu'à ce que les chiffres soient flatteurs.
Gouvernance des modèles
Les modèles ont des versions figées et leur provenance est enregistrée. La Math Guarantee relève du système de management de l'IA que nous construisons selon ISO/IEC 42001, pas d'une note de bas de page marketing.
Ce à quoi nous nous engageons
La méthode et les preuves : la borne que vos données de calibration permettent, la taille d'échantillon qui la soutient, et un état clair « pas encore établie » quand elles n'en permettent aucune. Nous ne publions aucun taux de fausses alertes que nous n'avons pas mesuré sur vos données.
Pas encore calibré
Trop peu de trafic légitime étiqueté par les analystes pour établir la moindre borne. Le produit le dit et indique ce qui manque ; il n'affiche pas de zéro.
Actif — borne élargie
Les données de calibration permettent une borne, mais plus large que la cible configurée. Le produit indique qu'il s'en tient à la borne élargie et n'affiche toujours aucun chiffre, car la cible plus stricte n'a jamais été atteinte.
Actif — borne cible
La taille de la calibration permet le niveau de confiance configuré. C'est le seul état qui porte un chiffre, et il n'arrive jamais seul : la borne, le nombre d'échantillons audités et la fenêtre sur laquelle ils ont été mesurés sont affichés ensemble.
En attente de recalibration
La calibration derrière la borne a vieilli, ou le trafic sur lequel elle reposait s'est éloigné de ce que montre le réseau aujourd'hui. La borne est retirée jusqu'à ce qu'une nouvelle calibration la remplace ; un chiffre périmé ne reste pas affiché parce qu'il a été vrai un jour.
Revalidation en cours
Une mise à jour de calibration est vérifiée avant de prendre effet. L'affirmation précédente est retirée pendant ce temps.
Ce sont les états que le produit renvoie réellement : aucun n'affiche une borne que les données de calibration ne permettent pas. Nous ne publions pas de chiffres comparatifs sur d'autres fournisseurs, car nous n'avons pas mené ces tests.
NetSenX AI Analyst Core
Chaque alerte s'accompagne d'une note sur laquelle un analyste peut agir.
Les données brutes de l'alerte sont associées à une note en langage clair : ce qui s'est passé, pourquoi c'est important et la réponse recommandée, structurée pour vos déclarations au titre de l'article 14 du CRA et de l'article 21 de NIS2.
- alert.id
- ALR-2026-0521-04183
- alert.timestamp
- 2026-05-21T09:14:22+02:00
- alert.severity
- high
- alert.layer
- L1 behavioral + L3 graph
- src.host
- finance-srv-04.corp.local
- src.ip
- 10.42.18.27
- dst.fqdn
- delta-cargo-track[.]xyz
- dst.ip
- 185.244.62.117
- dst.tld_registered
- 2026-05-21T03:11:00Z (6h ago)
- protocol
- TLS 1.3 / HTTPS
- bytes.up
- 2.4 KB / 90s
- bytes.down
- 182 B / 90s
- pattern
- low-volume periodic beacon, jitter 5%
- detection.confidence
- 0.94
- conformal.bound
- served at the tenant's calibrated confidence level
Beaconing détecté de finance-srv-04 vers un domaine jamais vu (delta-cargo-track.xyz), enregistré il y a 6 heures. Le trafic sortant est faible, périodique et peu irrégulier : un schéma compatible avec un canal command-and-control après une première compromission.
La couche graphe a aussi observé deux autres hôtes du sous-réseau finance (finance-srv-02, finance-srv-09) interrogeant le DNS pour le même domaine au cours des 90 dernières minutes.
Réponse recommandée
- Isoler finance-srv-04 du VLAN de production.
- Réaliser une image mémoire avant redémarrage, pour l'analyse forensique.
- Rechercher dans le sous-réseau finance d'autres hôtes contactant le même domaine ou la même adresse IP.
- Ouvrir un ticket selon votre procédure de réponse à incident ; l'alerte est déjà structurée pour la consignation des incidents au titre de l'article 14 du CRA.
Voyez-le sur votre propre réseau
Commencez avec l'offre Free pour 3 appareils au maximum : sans limite de durée, sans carte bancaire. Ou réservez une démo de 20 minutes : nous suivrons une vraie alerte de la capture jusqu'à la note d'analyste, avec la piste d'audit visible à chaque étape.