Your network produces signals all day: a MAC address that moves, a neighbour nobody knows, a configuration changed at night, a certificate about to expire, a CVE that just became exploited. Soron, the network alerting module of ConnectMyAssets, turns them into network event monitoring you control: 62 detectors, rules set per group of network devices, a preview before anything is enabled, and one console to acknowledge, assign and resolve every alert. Soron sends nothing to your devices: it reads what our collections and scans already store.
Request a demoUnknown LLDP/CDP neighbours, new MAC addresses, forbidden vendors, unknown devices in ARP tables and addresses that answer without an owner: every unauthorised device is reported with the switch and port where it was seen, so it can be isolated quickly.
A MAC address present on two access ports at once, a burst of new addresses in one VLAN, a gateway resolved to an unexpected MAC: the signs of spoofing and flooding become alerts instead of hints buried in tables.
Unreachable hosts, ICMP latency and loss, CPU and memory, power supplies, fans and stacks, devices that disappeared: and when a whole site drops, one “many devices missing” alert instead of hundreds.
New links, removed links, MAC addresses moving port or switch: you know when the physical network changes, where, and whether redundancy was lost.
A configuration changed outside ConnectMyAssets, a software version changed, a host key replaced: every change made outside your process is caught at the next collection, with the before and after in the configuration history.
New critical CVEs, CISA KEV, ransomware, EPSS thresholds and surges, remediation deadlines exceeded, wide exposure: Soron turns the vulnerability data of every device into a prioritised queue that closes itself after each firmware upgrade.
Compliance scores below target, regressions after a change, forbidden ports open, expired certificates: and for each alert, an append-only timeline of who saw it, who handled it and when, a useful piece of evidence for NIS2, ISO 27001 and PCI-DSS audits.
Write your rules once on the top group and let every customer group inherit them; lock the ones that must not be turned off, and let each customer add its own lists, thresholds and exceptions. Each technician only sees the alerts of the customers they serve.
On OT networks, where nothing should change, a new MAC address, an unknown neighbour or a forbidden vendor is an event worth knowing. Soron reads what the scans and collections you allowed per subnet already gathered, and adds no traffic of its own.
Keep the list of allowed SSIDs and the list of forbidden ones: any access point that broadcasts another network, or whose clients join one, is named with the network it carries.
Subnets nearly full, subnets overlapping between sites, addresses outside the declared ranges, groups no scan covers, devices no collection reaches: the gaps that weaken every other detector are listed every day.
End of support approaching, firmware behind its target, certificates about to expire: Soron warns with the lead time you choose, so renewals are planned rather than rushed.
Every alert is a rule you wrote or kept, on the scope you chose, with the people you chose to notify.
A rule names a detector, its parameters, a severity and a group: it applies to that group and every group below. A site can turn off an inherited rule for its scope with a reason, unless the rule is locked, and can exclude sub-groups from its own rules.
Refine any rule with conditions (all, any, not, nested) on the device, its model and end of support, its group and custom attributes, its vulnerabilities and interfaces. The rule shows its conditions in plain words.
Before saving, see how many alerts the rule would raise, how many an exception already covers, and the first matches. Adjust the scope, the parameters or the conditions until the result is the one you want.
Mark a MAC address, a vendor block, a neighbour, an SSID, an address, a network or a device as known, with a reason and an end date. The exception falls by itself: noise goes down without creating a lasting blind spot. Exceptions never weaken a locked rule.
Assign an alert to a person or a team, comment, acknowledge, close with a note or mute it until a date. Each action, in bulk or one by one, is kept on the alert’s timeline, which can never be edited.
When the condition goes, the alert is fixed; when it comes back, the same alert is reopened with its comments, its assignee and its history. One alert per subject, never a duplicate.
In-app notifications grouped per rule and group, never one per device; e-mail per rule by event and minimum severity; syslog and HTTPS webhook to your SIEM or ticketing tool (ServiceNow, Jira, Slack, Microsoft Teams, PagerDuty...) in CEF, LEEF, JSON or GELF.
A built-in Soron overview (active and critical alerts, rogue devices, new alerts over 7 days, mean time to acknowledge and to resolve, alerts by detector, group and assignee) and a monitoring overview. Every detector has its own indicators to add to any dashboard, and each figure opens the alerts behind it.
An alert belongs to the group of the device or subnet it is about. Users only read the alerts of the groups they may see, and titles only name what their group may read, on screen, in notifications and through the API.
Each detector can be used in as many rules as you need, on different groups, with its own parameters, severity, conditions and exceptions. A default rule per detector is installed at the first start; the ones that need your list (forbidden vendors, SSIDs) or your conditions start disabled.
A device reports an LLDP or CDP neighbour that is not in your inventory: an unmanaged switch, a home router or a device plugged in without a ticket shows up the moment it advertises itself.
Two known devices are linked for the first time: a cable added between switches, a new uplink or a loop in the making is reported before it surprises anyone.
A link between two devices has been missing for longer than your threshold and the neighbour is seen on no other port: a cut uplink or a lost redundancy path is flagged, and the alert clears when the link comes back.
A MAC address never seen anywhere on the network is learnt by a switch: the first sign of a new endpoint, reported on the device and port where it appeared.
A MAC address belongs to a vendor or a prefix you banned (consumer hardware, a brand excluded by policy): you learn where it is plugged in, wired or wireless.
A MAC address shows up on another port of the same VLAN: catches endpoints moved without a change request and the flapping that betrays a loop.
An endpoint that stayed on an access port now sits on another port or another switch, uplinks left aside: follow physical moves across the whole site, with the old and the new location.
The same MAC address is present at the same time on access ports of two devices, MLAG and VSX pairs excepted: the classic sign of a cloned or spoofed address.
A switch learns more new MAC addresses in one VLAN than your threshold within a few minutes: spots MAC flooding, an unmanaged switch full of clients or a virtualisation host plugged into the wrong port.
A router or firewall resolves an IP address that belongs to no known device, and the alert says on which switch and port it was last seen.
An IP address in use is held by no subnet declared in your IPAM: static addressing mistakes, forgotten ranges and devices configured by hand come to light.
An address answers over SSH but could not become a managed device (credentials refused, host key changed, unknown vendor): turns the unknown part of the network into a list to work through.
An address answers the scans in one of your subnets while no known device owns it: the device nobody declared is found by the network itself.
An access point broadcasts, or its clients join, an SSID outside your allowed list: rogue and test networks are named with the access point that carries them.
An SSID from your forbidden list is broadcast or joined: catches the guest network left on in a sensitive building or a known evil-twin name.
A device reports a new software version: every upgrade and every downgrade is recorded, including the ones nobody announced.
A device runs an older version than the target image of your library: the upgrade backlog becomes a list of alerts that close themselves as devices are upgraded.
The running configuration changed while no Bastion session, script, firmware upgrade or ZTP provisioning of ConnectMyAssets was open on the device: the change made outside your process is caught at the next collection.
A device presents an SSH host key different from the trusted one: a replaced device, or an interception attempt, is stopped until someone accepts the new key.
A device collected before now fails collection after collection (a password that stopped working, a timeout): your inventory and backups do not go stale in silence.
An inventoried device covered by a scheduled collection has not been collected for longer than you allow, with the reason of the last attempt: a device removed, stolen or cut off is noticed.
More devices than your threshold disappear at once: one alert for a site outage, a WAN cut or a firewall change, instead of hundreds.
A device of the types you choose falls under the compliance score you set: the drift of hardening is visible before the audit.
A device fails a compliance policy it passed just before, for the severities you choose: you know which change broke which control, and when.
A device model reaches its end of support or end of life within the number of days you set, or already did: renewals are planned before support stops.
A device has no host name: a quick hygiene check that keeps logs, maps and tickets readable.
A device, group of network devices or subnet meets conditions on your own custom attributes (owner, contract end, criticality, site code), inherited values included.
A group no scheduled scan covers, a subnet every scan excludes, a device no collection reaches: the blind spots of your monitoring are listed every day.
A subnet reaches the utilisation threshold you set: extend it or clean it up before DHCP runs out of addresses.
Two sites or two customers declare overlapping subnets: catches the addressing conflict before routing or a merger reveals it.
A device was found at an address no subnet of your groups holds, so it landed in Unassigned: tells you which subnet to declare or which device to file.
A device stops answering ICMP: the first signal of a power cut, a broken link or a crashed device, cleared as soon as it answers again.
The round-trip time to a device exceeds your threshold: congested WAN links and overloaded sites stand out before users call.
Packet loss to a device exceeds your threshold: catches the faulty link or optic that drops traffic without going down.
A device’s CPU stays above your threshold: control-plane overload, a routing storm or a stuck process is reported.
A device’s memory use crosses your threshold: memory leaks and tables that outgrow the hardware are found before the reload.
Any numeric metric you pick crosses your threshold (temperature, interface errors, PoE, clients, sessions, BGP peers down, channel utilisation), per interface, SSID or radio when it applies.
A power supply, a fan, a stack or a high-availability pair reports a status outside the accepted values: hardware failures are caught while redundancy still holds.
A port you marked as forbidden (Telnet, SMB, an admin console) is open on a host: one alert per host and port, closed when the port closes.
A TLS service presents an expired certificate: the host, the port and the end date are named so the renewal goes to the right team.
A certificate ends within the number of days you set: renew it before integrations, logins and backups break.
A service still uses a self-signed certificate: printers, cameras, UPS cards and BMCs that teach users to ignore browser warnings are listed.
An open port meets your own conditions on its certificate or service (an issuer other than your CA, an RSA key under 2048 bits, TLS 1.0 or 1.1, a wildcard, an unexpected web server).
Any device that meets your conditions on any of its fields, its group and the records linked to it: “a core switch out of support in a critical site”, written in a few clicks.
Any vulnerability that meets your conditions on the finding, the CVE and the device: “EPSS above 20% and open for more than 7 days on a firewall”.
Any interface that meets your conditions: an access port with no description, an uplink running at the wrong speed, an interface down in a production VLAN.
Any MAC table entry that meets your conditions: a vendor block in the wrong VLAN, a camera outside the video network, an address on a port it should never use.
Any ARP entry that meets your conditions: an address range used on the wrong router, a gateway resolved to an unexpected MAC address.
Any FortiGate or PAN-OS security rule that meets your conditions: any/any allowed, logging off, an insecure service between zones, a rule outside your naming policy.
A CVE with a CVSS base score of 9.0 or more newly applies to a device’s vendor, model and firmware: the emergencies of the day, device by device.
A CVE whose CVSS score, ConnectMyAssets risk score or EPSS reaches your threshold applies to a device: you set the bar, per group of network devices.
An accepted risk, an urgent mark or a whitelist reached its end date while the CVE still applies: risk decisions are revisited instead of lasting for ever.
A CVE of the CISA Known Exploited Vulnerabilities catalogue applies to a device, with the date CISA listed it: what attackers already use comes first.
CISA has just added to its catalogue a CVE that applies to one of your devices: a threat that has just become active is reported within the days you choose.
A known-exploited CVE that ransomware campaigns use applies to a device: the findings that justify an emergency change.
A CVE whose EPSS (the probability of exploitation in the next 30 days published by FIRST) reaches your threshold applies to a device: prioritise by likelihood, not only by severity.
The EPSS of a CVE on one of your devices rises by the points you choose over the days you choose: a vulnerability attackers are starting to target is caught early.
A CVE stays open on a device longer than your deadline for its kind (known-exploited, critical or high), and turns critical once the delay has doubled: your patch SLA is enforced.
A known-exploited CVE is open on at least the number of devices you set: one alert per CVE, with the devices in each group, to run one campaign instead of a hundred tickets.
Only the known-exploited CVEs whose firmware version falls inside a published range, with nothing left to confirm, with the fixed version and the vendor advisory: zero doubt before acting.
A CVE that only “may apply” to a device is now confirmed by the firmware data: the findings you had parked deserve a second look.
The vendor, model and firmware of a device cannot be resolved by our vulnerability service: no known vulnerability is not the same as none, and you know where to look.
For network and security engineers: where the data comes from, when rules are evaluated and how alerts live.
Every detector reads what ConnectMyAssets already stores: SSH collections (configurations, MAC and ARP tables, LLDP/CDP, interfaces, versions), network scans and audited ports, monitoring readings, compliance results and vulnerability data. No extra probe, no extra credential.
Rules run after each collection of a device and at the end of each scan, narrowed to what was just read; every five minutes for what changes with time alone (a device that disappeared, a link removed); every hour and every day over their whole scope; and at once when a rule is created or changed.
A condition detector (a port open, a certificate expired) fixes its alert when the condition goes and reopens it when it comes back. An event detector (a MAC address that moved, a configuration changed) counts each new occurrence on the same alert, which a person closes.
Event rules start from their creation date, less a look-back you set (24 hours by default): a rule created today does not raise the MAC addresses learnt last year, and the first collection of a device is its inventory, not news.
Each rule is evaluated as one query over its whole scope, never as a loop over devices, and the work is split by group for large trees. Retention of closed alerts is yours to set (365 days by default).
Alerts, rules and exceptions are available through the REST API (for example GET /api/v1/soron/alerts) with scoped API tokens, and every change of a rule or exception is written to the audit trail.
Start from a default rule or pick one of the detectors, then set its parameters, severity, conditions and group.
Check what the rule would find and refine it before enabling it.
Receive alerts in the console, by e-mail, syslog or webhook, at the severity you set.
Acknowledge, assign and resolve with the full history, and follow your response times on a dashboard.
Prepare your project and define your scope.
Soron has 62 detectors in ten families: topology and neighbours, MAC, ARP and addressing, rogue devices and wireless, configuration, firmware and collection, compliance and lifecycle, coverage and IPAM, monitoring, ports and certificates, conditions on any data, and vulnerabilities. The full list is on this page.
Keep the default rules for unknown LLDP/CDP neighbours, new MAC addresses, unknown devices in ARP tables and unknown devices answering the scans, and add your list of forbidden vendors. Each alert names the switch and port where the device was seen, and the Rogue devices list gathers them all.
Scope each rule on the right group, add conditions and check the preview before enabling it. Exceptions with an expiry date absorb known cases, mutes silence an alert until a date, and notifications are grouped per rule and group, never one per device.
Yes. Rules belong to groups of network devices and are inherited by sub-groups; a site or a customer can turn off an inherited rule unless it is locked, and add its own rules. Alerts respect each user’s permissions and follow the scope chosen in the header.
Soron evaluates the rules after every collection of a device and at the end of every scan, on what was just read. Since collections and scans can be scheduled as often as every 5 minutes, alerts keep pace with your network; time-based detectors are also checked every five minutes.
Yes. Alerts reach syslog (RFC 5424 or RFC 3164, over UDP, TCP or TLS) and HTTPS webhooks in CEF, LEEF, JSON (ECS) or GELF, which makes Soron compatible with ServiceNow, Jira, Slack, Microsoft Teams, PagerDuty and your SIEM. E-mail is set per rule.
Yes. Every detector accepts conditions, and six detectors raise an alert for any device, vulnerability, interface, MAC entry, ARP entry or firewall rule that meets the conditions you write, on any field. The rule shows its conditions in plain words and the preview shows what it finds.
No. Soron sends nothing to the devices: it works on the data ConnectMyAssets already collects over SSH and through its network scans. What it can see is what your inventory holds, which is why coverage gaps have their own detector.
See what ConnectMyAssets can change for your team. On your infrastructure, with your requirements.
Request a demo