Votre réseau produit des signaux en permanence : une adresse MAC qui se déplace, un voisin que personne ne connaît, une configuration modifiée en pleine nuit, un certificat sur le point d’expirer, une CVE qui vient d’être exploitée. Soron, le module d’alertes réseau de ConnectMyAssets, en fait une supervision des événements réseau que vous maîtrisez : 62 détecteurs, des règles définies par groupe d’équipements réseau, une prévisualisation avant toute activation et une console unique pour accuser réception, assigner et résoudre chaque alerte. Soron n’envoie rien à vos équipements : il exploite ce que nos collectes et nos scans enregistrent déjà.
Demander une démoVoisins LLDP/CDP inconnus, nouvelles adresses MAC, constructeurs interdits, équipements inconnus dans les tables ARP et adresses qui répondent sans propriétaire : chaque équipement non autorisé est signalé avec le switch et le port où il a été vu, pour l’isoler rapidement.
Une adresse MAC présente sur deux ports d’accès à la fois, une rafale de nouvelles adresses dans un VLAN, une passerelle résolue vers une MAC inattendue : les signes d’usurpation et d’inondation deviennent des alertes au lieu d’indices enfouis dans les tables.
Hôtes injoignables, latence et perte ICMP, CPU et mémoire, alimentations, ventilateurs et piles, équipements disparus : et quand un site entier tombe, une seule alerte « nombreux équipements manquants » au lieu de centaines.
Nouveaux liens, liens disparus, adresses MAC qui changent de port ou de switch : vous savez quand le réseau physique change, où, et si une redondance a été perdue.
Une configuration modifiée hors de ConnectMyAssets, une version logicielle changée, une clé d’hôte remplacée : chaque modification faite hors de votre processus est repérée à la collecte suivante, avec l’avant et l’après dans l’historique des configurations.
Nouvelles CVE critiques, CISA KEV, rançongiciels, seuils et hausses d’EPSS, délais de correction dépassés, exposition étendue : Soron transforme les données de vulnérabilité de chaque équipement en file priorisée qui se vide d’elle-même après chaque mise à jour firmware.
Scores de conformité sous l’objectif, régressions après une modification, ports interdits ouverts, certificats expirés : et pour chaque alerte, une chronologie non modifiable de qui l’a vue, qui l’a traitée et quand, une preuve utile pour les audits NIS2, ISO 27001 et PCI-DSS.
Écrivez vos règles une fois sur le groupe de tête et laissez chaque groupe client en hériter ; verrouillez celles qui ne doivent pas être désactivées, et laissez chaque client ajouter ses listes, seuils et exceptions. Chaque technicien ne voit que les alertes des clients qu’il gère.
Sur les réseaux OT, où rien ne devrait changer, une nouvelle adresse MAC, un voisin inconnu ou un constructeur interdit est un événement à connaître. Soron exploite ce que les scans et les collectes autorisés sous-réseau par sous-réseau ont déjà recueilli, sans ajouter de trafic.
Tenez la liste des SSID autorisés et celle des SSID interdits : tout point d’accès qui diffuse un autre réseau, ou dont les clients en rejoignent un, est nommé avec le réseau qu’il porte.
Sous-réseaux presque pleins, sous-réseaux qui se chevauchent entre sites, adresses hors des plages déclarées, groupes qu’aucun scan ne couvre, équipements qu’aucune collecte n’atteint : les lacunes qui affaiblissent tous les autres détecteurs sont listées chaque jour.
Fin de support proche, firmware en retard sur sa cible, certificats sur le point d’expirer : Soron prévient avec le délai que vous choisissez, pour que les renouvellements soient planifiés plutôt que précipités.
Chaque alerte vient d’une règle que vous avez écrite ou conservée, sur le périmètre choisi, avec les personnes que vous avez choisi de prévenir.
Une règle désigne un détecteur, ses paramètres, une sévérité et un groupe : elle s’applique à ce groupe et à tous ceux qui sont en dessous. Un site peut désactiver une règle héritée pour son périmètre, avec une raison, sauf si elle est verrouillée, et peut exclure des sous-groupes de ses propres règles.
Affinez chaque règle avec des conditions (toutes, au moins une, négation, imbrication) sur l’équipement, son modèle et sa fin de support, son groupe et ses attributs personnalisés, ses vulnérabilités et ses interfaces. La règle affiche ses conditions en toutes lettres.
Avant d’enregistrer, voyez combien d’alertes la règle lèverait, combien sont déjà couvertes par une exception et les premiers résultats. Ajustez le périmètre, les paramètres ou les conditions jusqu’à obtenir le résultat voulu.
Déclarez connus une adresse MAC, un bloc constructeur, un voisin, un SSID, une adresse, un réseau ou un équipement, avec une raison et une date de fin. L’exception tombe d’elle-même : le bruit baisse sans créer d’angle mort durable. Une exception n’affaiblit jamais une règle verrouillée.
Assignez une alerte à une personne ou une équipe, commentez, accusez réception, fermez avec une note ou mettez en sourdine jusqu’à une date. Chaque action, en masse ou une par une, est conservée dans la chronologie de l’alerte, qui ne peut jamais être modifiée.
Quand la condition disparaît, l’alerte est corrigée ; quand elle revient, la même alerte est rouverte avec ses commentaires, son assignation et son historique. Une alerte par sujet, jamais de doublon.
Notifications dans l’application regroupées par règle et par groupe, jamais une par équipement ; e-mail par règle selon l’événement et la sévérité minimale ; syslog et webhook HTTPS vers votre SIEM ou votre outil de ticketing (ServiceNow, Jira, Slack, Microsoft Teams, PagerDuty...) aux formats CEF, LEEF, JSON ou GELF.
Une vue d’ensemble Soron intégrée (alertes actives et critiques, équipements non autorisés, nouvelles alertes sur 7 jours, temps moyen d’accusé de réception et de résolution, alertes par détecteur, groupe et assigné) et une vue d’ensemble de la supervision. Chaque détecteur a ses propres indicateurs à ajouter à n’importe quel tableau de bord, et chaque chiffre ouvre les alertes correspondantes.
Une alerte appartient au groupe de l’équipement ou du sous-réseau qu’elle concerne. Chaque utilisateur ne lit que les alertes des groupes qu’il peut voir, et les titres ne nomment que ce que son groupe peut lire, à l’écran, dans les notifications et par l’API.
Chaque détecteur peut servir dans autant de règles que nécessaire, sur des groupes différents, avec ses propres paramètres, sévérité, conditions et exceptions. Une règle par défaut par détecteur est installée au premier démarrage ; celles qui demandent votre liste (constructeurs interdits, SSID) ou vos conditions démarrent désactivées.
Un équipement annonce un voisin LLDP ou CDP absent de votre inventaire : un switch non géré, une box ou un équipement branché sans ticket apparaît dès qu’il s’annonce.
Deux équipements connus sont reliés pour la première fois : un câble ajouté entre deux switchs, une nouvelle liaison montante ou une boucle en préparation est signalé avant de surprendre qui que ce soit.
Un lien entre deux équipements manque depuis plus longtemps que votre seuil et le voisin n’apparaît sur aucun autre port : une liaison montante coupée ou une redondance perdue est signalée, et l’alerte se ferme au retour du lien.
Une adresse MAC jamais vue sur le réseau est apprise par un switch : le premier signe d’un nouvel équipement, signalé sur l’équipement et le port où il est apparu.
Une adresse MAC appartient à un constructeur ou à un préfixe que vous avez interdit (matériel grand public, marque exclue par votre politique) : vous savez où il est branché, en filaire ou en Wi-Fi.
Une adresse MAC apparaît sur un autre port du même VLAN : repère les postes déplacés sans demande de changement et les oscillations qui trahissent une boucle.
Un poste resté sur un port d’accès se trouve désormais sur un autre port ou un autre switch, liaisons montantes exclues : suivez les déplacements physiques sur tout le site, avec l’ancien et le nouvel emplacement.
La même adresse MAC est présente au même moment sur des ports d’accès de deux équipements, hors paires MLAG et VSX : le signe classique d’une adresse clonée ou usurpée.
Un switch apprend en quelques minutes plus de nouvelles adresses MAC que votre seuil dans un VLAN : repère une inondation MAC, un switch non géré chargé de clients ou un hôte de virtualisation branché sur le mauvais port.
Un routeur ou un pare-feu résout une adresse IP qui n’appartient à aucun équipement connu, et l’alerte indique sur quel switch et quel port elle a été vue en dernier.
Une adresse IP utilisée n’appartient à aucun sous-réseau déclaré dans votre IPAM : erreurs d’adressage statique, plages oubliées et équipements configurés à la main apparaissent.
Une adresse répond en SSH mais n’a pas pu devenir un équipement géré (identifiants refusés, clé d’hôte modifiée, constructeur inconnu) : la part inconnue du réseau devient une liste à traiter.
Une adresse répond aux scans dans l’un de vos sous-réseaux alors qu’aucun équipement connu ne la porte : l’équipement que personne n’a déclaré est trouvé par le réseau lui-même.
Un point d’accès diffuse, ou ses clients rejoignent, un SSID absent de votre liste autorisée : réseaux pirates et réseaux de test sont nommés avec le point d’accès qui les porte.
Un SSID de votre liste interdite est diffusé ou rejoint : repère le réseau invité resté actif dans un bâtiment sensible ou un nom connu d’usurpation.
Un équipement annonce une nouvelle version logicielle : chaque mise à jour et chaque retour arrière est enregistré, y compris ceux que personne n’a annoncés.
Un équipement exécute une version plus ancienne que l’image cible de votre bibliothèque : le retard de mise à jour devient une liste d’alertes qui se ferment d’elles-mêmes au fil des mises à jour.
La configuration active a changé alors qu’aucune session Bastion, aucun script, aucune mise à jour firmware ni aucun provisionnement ZTP de ConnectMyAssets n’était ouvert sur l’équipement : la modification faite hors de votre processus est repérée à la collecte suivante.
Un équipement présente une clé d’hôte SSH différente de celle approuvée : un équipement remplacé, ou une tentative d’interception, est bloqué jusqu’à ce que quelqu’un accepte la nouvelle clé.
Un équipement déjà collecté échoue collecte après collecte (un mot de passe qui ne fonctionne plus, un délai dépassé) : votre inventaire et vos sauvegardes ne vieillissent pas en silence.
Un équipement inventorié, couvert par une collecte planifiée, n’a pas été collecté depuis plus longtemps que vous ne l’acceptez, avec la raison du dernier échec : un équipement retiré, volé ou isolé est remarqué.
Plus d’équipements que votre seuil disparaissent en même temps : une seule alerte pour une panne de site, une coupure WAN ou une modification de pare-feu, au lieu de centaines.
Un équipement des types choisis passe sous le score de conformité que vous fixez : la dérive du durcissement est visible avant l’audit.
Un équipement échoue à une politique de conformité qu’il respectait juste avant, pour les sévérités choisies : vous savez quelle modification a cassé quel contrôle, et quand.
Le modèle d’un équipement atteint sa fin de support ou sa fin de vie dans le nombre de jours fixé, ou l’a déjà atteinte : les renouvellements se préparent avant l’arrêt du support.
Un équipement n’a pas de nom d’hôte : un contrôle d’hygiène simple qui garde journaux, cartes et tickets lisibles.
Un équipement, un groupe d’équipements réseau ou un sous-réseau répond à des conditions sur vos propres attributs personnalisés (responsable, fin de contrat, criticité, code site), valeurs héritées comprises.
Un groupe qu’aucun scan planifié ne couvre, un sous-réseau que tous les scans excluent, un équipement qu’aucune collecte n’atteint : les angles morts de votre supervision sont listés chaque jour.
Un sous-réseau atteint le seuil d’utilisation que vous fixez : agrandissez-le ou faites le ménage avant que le DHCP ne manque d’adresses.
Deux sites ou deux clients déclarent des sous-réseaux qui se chevauchent : repère le conflit d’adressage avant que le routage ou une fusion ne le révèle.
Un équipement a été trouvé à une adresse qu’aucun sous-réseau de vos groupes ne contient, il est donc classé dans Non affecté : vous savez quel sous-réseau déclarer ou quel équipement classer.
Un équipement ne répond plus en ICMP : le premier signal d’une coupure électrique, d’un lien rompu ou d’un équipement planté, levé dès qu’il répond de nouveau.
Le temps d’aller-retour vers un équipement dépasse votre seuil : les liens WAN saturés et les sites surchargés ressortent avant les appels des utilisateurs.
La perte de paquets vers un équipement dépasse votre seuil : repère le lien ou l’optique défaillant qui perd du trafic sans tomber.
Le CPU d’un équipement dépasse votre seuil : surcharge du plan de contrôle, tempête de routage ou processus bloqué est signalé.
L’utilisation mémoire d’un équipement dépasse votre seuil : fuites mémoire et tables qui dépassent le matériel sont repérées avant le redémarrage.
N’importe quelle métrique numérique choisie dépasse votre seuil (température, erreurs d’interface, PoE, clients, sessions, pairs BGP tombés, occupation du canal), par interface, SSID ou radio quand c’est pertinent.
Une alimentation, un ventilateur, une pile ou une paire haute disponibilité remonte un état hors des valeurs acceptées : les pannes matérielles sont repérées tant que la redondance tient encore.
Un port que vous avez marqué comme interdit (Telnet, SMB, une console d’administration) est ouvert sur un hôte : une alerte par hôte et par port, fermée quand le port se ferme.
Un service TLS présente un certificat expiré : l’hôte, le port et la date de fin sont nommés pour que le renouvellement parte vers la bonne équipe.
Un certificat arrive à échéance dans le nombre de jours fixé : renouvelez-le avant que les intégrations, les connexions et les sauvegardes ne cassent.
Un service utilise encore un certificat auto-signé : imprimantes, caméras, cartes d’onduleurs et BMC qui habituent les utilisateurs à ignorer les avertissements sont listés.
Un port ouvert répond à vos propres conditions sur son certificat ou son service (émetteur autre que votre autorité, clé RSA de moins de 2048 bits, TLS 1.0 ou 1.1, wildcard, serveur web inattendu).
Tout équipement qui répond à vos conditions sur n’importe lequel de ses champs, son groupe et les données liées : « un switch de cœur hors support sur un site critique », écrit en quelques clics.
Toute vulnérabilité qui répond à vos conditions sur la détection, la CVE et l’équipement : « EPSS supérieur à 20 % et ouverte depuis plus de 7 jours sur un pare-feu ».
Toute interface qui répond à vos conditions : port d’accès sans description, liaison montante à la mauvaise vitesse, interface tombée dans un VLAN de production.
Toute entrée de table MAC qui répond à vos conditions : bloc constructeur dans le mauvais VLAN, caméra hors du réseau vidéo, adresse sur un port qu’elle ne devrait jamais utiliser.
Toute entrée ARP qui répond à vos conditions : plage d’adresses utilisée sur le mauvais routeur, passerelle résolue vers une adresse MAC inattendue.
Toute règle de sécurité FortiGate ou PAN-OS qui répond à vos conditions : any/any autorisé, journalisation désactivée, service non sécurisé entre zones, règle hors de votre convention de nommage.
Une CVE de score CVSS de base 9.0 ou plus s’applique désormais au constructeur, au modèle et au firmware d’un équipement : les urgences du jour, équipement par équipement.
Une CVE dont le score CVSS, le score de risque ConnectMyAssets ou l’EPSS atteint votre seuil s’applique à un équipement : vous placez la barre, par groupe d’équipements réseau.
Un risque accepté, un marquage urgent ou une liste blanche a atteint sa date de fin alors que la CVE s’applique toujours : les décisions de risque sont revues au lieu de durer indéfiniment.
Une CVE du catalogue CISA Known Exploited Vulnerabilities s’applique à un équipement, avec la date d’inscription par la CISA : ce que les attaquants utilisent déjà passe en premier.
La CISA vient d’ajouter à son catalogue une CVE qui s’applique à l’un de vos équipements : une menace qui vient de devenir active est signalée dans les jours que vous choisissez.
Une CVE exploitée connue, utilisée par des campagnes de rançongiciels, s’applique à un équipement : les détections qui justifient un changement en urgence.
Une CVE dont l’EPSS (la probabilité d’exploitation dans les 30 prochains jours publiée par le FIRST) atteint votre seuil s’applique à un équipement : priorisez selon la probabilité, pas seulement la sévérité.
L’EPSS d’une CVE présente sur l’un de vos équipements augmente du nombre de points choisi sur la période choisie : une vulnérabilité que les attaquants commencent à cibler est repérée tôt.
Une CVE reste ouverte sur un équipement plus longtemps que votre délai pour sa catégorie (exploitée connue, critique ou élevée), et devient critique une fois le délai doublé : votre engagement de correction est tenu.
Une CVE exploitée connue est ouverte sur au moins le nombre d’équipements fixé : une alerte par CVE, avec les équipements de chaque groupe, pour mener une seule campagne au lieu de cent tickets.
Uniquement les CVE exploitées connues dont la version de firmware entre dans une plage publiée, sans rien à confirmer, avec la version corrigée et l’avis du constructeur : aucun doute avant d’agir.
Une CVE qui « pouvait s’appliquer » à un équipement est désormais confirmée par les données du firmware : les détections que vous aviez mises de côté méritent un nouvel examen.
Le constructeur, le modèle et le firmware d’un équipement ne peuvent pas être résolus par notre service de vulnérabilités : aucune vulnérabilité connue ne veut pas dire aucune vulnérabilité, et vous savez où regarder.
Pour les ingénieurs réseau et sécurité : d’où viennent les données, quand les règles sont évaluées et comment vivent les alertes.
Chaque détecteur exploite ce que ConnectMyAssets enregistre déjà : collectes SSH (configurations, tables MAC et ARP, LLDP/CDP, interfaces, versions), scans réseau et ports audités, mesures de supervision, résultats de conformité et données de vulnérabilité. Aucune sonde ni aucun identifiant supplémentaire.
Les règles s’exécutent après chaque collecte d’un équipement et à la fin de chaque scan, sur ce qui vient d’être lu ; toutes les cinq minutes pour ce qui change avec le seul passage du temps (un équipement disparu, un lien perdu) ; toutes les heures et chaque jour sur tout leur périmètre ; et immédiatement quand une règle est créée ou modifiée.
Un détecteur de condition (un port ouvert, un certificat expiré) corrige son alerte quand la condition disparaît et la rouvre quand elle revient. Un détecteur d’événement (une adresse MAC déplacée, une configuration modifiée) compte chaque nouvelle occurrence sur la même alerte, qu’une personne ferme.
Les règles d’événement partent de leur date de création, moins une période de recul que vous fixez (24 heures par défaut) : une règle créée aujourd’hui ne remonte pas les adresses MAC apprises l’an dernier, et la première collecte d’un équipement constitue son inventaire, pas une nouveauté.
Chaque règle est évaluée en une requête sur tout son périmètre, jamais en boucle sur les équipements, et le travail est découpé par groupe pour les grandes arborescences. La conservation des alertes fermées se règle (365 jours par défaut).
Alertes, règles et exceptions sont disponibles par l’API REST (par exemple GET /api/v1/soron/alerts) avec des jetons d’API à portée limitée, et chaque modification d’une règle ou d’une exception est inscrite au journal d’audit.
Partez d’une règle par défaut ou choisissez l’un des détecteurs, puis réglez ses paramètres, sa sévérité, ses conditions et son groupe.
Vérifiez ce que la règle trouverait et affinez-la avant de l’activer.
Recevez les alertes dans la console, par e-mail, syslog ou webhook, à la sévérité choisie.
Accusez réception, assignez et résolvez avec tout l’historique, et suivez vos délais de traitement sur un tableau de bord.
Pour préparer votre projet et préciser votre périmètre.
Soron compte 62 détecteurs répartis en dix familles : topologie et voisins ; MAC, ARP et adressage ; équipements non autorisés et Wi-Fi ; configuration, firmware et collecte ; conformité et cycle de vie ; couverture et IPAM ; supervision ; ports et certificats ; conditions sur toutes les données ; vulnérabilités. La liste complète figure sur cette page.
Conservez les règles par défaut sur les voisins LLDP/CDP inconnus, les nouvelles adresses MAC, les équipements inconnus des tables ARP et les équipements inconnus qui répondent aux scans, puis ajoutez votre liste de constructeurs interdits. Chaque alerte nomme le switch et le port où l’équipement a été vu, et la liste des équipements non autorisés les rassemble toutes.
Cadrez chaque règle sur le bon groupe, ajoutez des conditions et vérifiez la prévisualisation avant de l’activer. Les exceptions avec date d’expiration absorbent les cas connus, la mise en sourdine fait taire une alerte jusqu’à une date, et les notifications sont regroupées par règle et par groupe, jamais une par équipement.
Oui. Les règles appartiennent à des groupes d’équipements réseau et sont héritées par les sous-groupes ; un site ou un client peut désactiver une règle héritée sauf si elle est verrouillée, et ajouter ses propres règles. Les alertes respectent les droits de chaque utilisateur et suivent le périmètre choisi dans l’en-tête.
Soron évalue les règles après chaque collecte d’un équipement et à la fin de chaque scan, sur ce qui vient d’être lu. Comme collectes et scans peuvent être planifiés jusqu’à toutes les 5 minutes, les alertes suivent le rythme de votre réseau ; les détecteurs qui dépendent du temps sont aussi contrôlés toutes les cinq minutes.
Oui. Les alertes partent vers syslog (RFC 5424 ou RFC 3164, en UDP, TCP ou TLS) et vers des webhooks HTTPS aux formats CEF, LEEF, JSON (ECS) ou GELF, ce qui rend Soron compatible avec ServiceNow, Jira, Slack, Microsoft Teams, PagerDuty et votre SIEM. L’e-mail se règle par règle.
Oui. Chaque détecteur accepte des conditions, et six détecteurs lèvent une alerte pour tout équipement, vulnérabilité, interface, entrée MAC, entrée ARP ou règle de pare-feu qui répond aux conditions que vous écrivez, sur n’importe quel champ. La règle affiche ses conditions en toutes lettres et la prévisualisation montre ce qu’elle trouve.
Non. Soron n’envoie rien aux équipements : il travaille sur les données que ConnectMyAssets collecte déjà en SSH et par ses scans réseau. Ce qu’il voit est ce que contient votre inventaire, c’est pourquoi les angles morts de couverture ont leur propre détecteur.
Découvrez ce que ConnectMyAssets peut changer pour votre équipe. Sur votre infrastructure, avec vos contraintes.
Organiser une démonstration