Ihr Netzwerk sendet den ganzen Tag Signale: eine MAC-Adresse, die wandert, ein Nachbar, den niemand kennt, eine nachts geänderte Konfiguration, ein Zertifikat kurz vor dem Ablauf, eine CVE, die gerade ausgenutzt wird. Soron, das Alarmierungsmodul von ConnectMyAssets, macht daraus eine Überwachung von Netzwerkereignissen, die Sie steuern: 62 Detektoren, Regeln je Gruppe von Netzwerkgeräten, eine Vorschau vor jeder Aktivierung und eine Konsole, um jeden Alarm zu bestätigen, zuzuweisen und zu beheben. Soron sendet nichts an Ihre Geräte: Es liest, was unsere Erfassungen und Scans bereits speichern.
Demo anfordernUnbekannte LLDP/CDP-Nachbarn, neue MAC-Adressen, verbotene Hersteller, unbekannte Geräte in ARP-Tabellen und Adressen, die ohne Eigentümer antworten: Jedes nicht autorisierte Gerät wird mit dem Switch und dem Port gemeldet, an dem es gesehen wurde, damit es schnell isoliert werden kann.
Eine MAC-Adresse an zwei Access-Ports gleichzeitig, eine Häufung neuer Adressen in einem VLAN, ein Gateway mit unerwarteter MAC-Adresse: Die Anzeichen von Spoofing und Flooding werden zu Alarmen statt zu Hinweisen, die in Tabellen untergehen.
Nicht erreichbare Hosts, ICMP-Latenz und -Verlust, CPU und Arbeitsspeicher, Netzteile, Lüfter und Stacks, verschwundene Geräte: Und wenn ein ganzer Standort ausfällt, ein einziger Alarm „viele Geräte fehlen“ statt Hunderter.
Neue Verbindungen, entfernte Verbindungen, MAC-Adressen, die Port oder Switch wechseln: Sie wissen, wann sich das physische Netzwerk ändert, wo, und ob Redundanz verloren ging.
Eine Konfiguration außerhalb von ConnectMyAssets geändert, eine Softwareversion gewechselt, ein Host-Key ersetzt: Jede Änderung außerhalb Ihres Prozesses fällt bei der nächsten Erfassung auf, mit dem Vorher und Nachher im Konfigurationsverlauf.
Neue kritische CVEs, CISA KEV, Ransomware, EPSS-Schwellen und -Anstiege, überschrittene Behebungsfristen, breite Exposition: Soron macht aus den Schwachstellendaten jedes Geräts eine priorisierte Warteschlange, die sich nach jedem Firmware-Upgrade selbst abbaut.
Compliance-Scores unter Ziel, Rückschritte nach einer Änderung, offene verbotene Ports, abgelaufene Zertifikate: Zu jedem Alarm gibt es eine nur erweiterbare Zeitleiste, wer ihn gesehen und bearbeitet hat und wann, ein nützlicher Nachweis für Audits nach NIS2, ISO 27001 und PCI DSS.
Schreiben Sie Ihre Regeln einmal in der obersten Gruppe und lassen Sie jede Kundengruppe sie erben; sperren Sie die, die nicht abgeschaltet werden dürfen, und lassen Sie jeden Kunden eigene Listen, Schwellenwerte und Ausnahmen ergänzen. Jeder Techniker sieht nur die Alarme der Kunden, die er betreut.
In OT-Netzwerken, in denen sich nichts ändern sollte, ist eine neue MAC-Adresse, ein unbekannter Nachbar oder ein verbotener Hersteller ein Ereignis, das man kennen sollte. Soron liest, was die je Subnetz erlaubten Scans und Erfassungen bereits gesammelt haben, und erzeugt keinen eigenen Datenverkehr.
Pflegen Sie die Liste der zugelassenen und die der verbotenen SSIDs: Jeder Access Point, der ein anderes Netz ausstrahlt oder dessen Clients sich damit verbinden, wird mit diesem Netz benannt.
Fast volle Subnetze, überlappende Subnetze zwischen Standorten, Adressen außerhalb der deklarierten Bereiche, Gruppen ohne Scan, Geräte ohne Erfassung: Die Lücken, die jeden anderen Detektor schwächen, werden täglich aufgelistet.
Nahendes Supportende, Firmware hinter ihrer Zielversion, bald ablaufende Zertifikate: Soron warnt mit der von Ihnen gewählten Vorlaufzeit, damit Erneuerungen geplant statt überstürzt werden.
Jeder Alarm ist eine Regel, die Sie geschrieben oder beibehalten haben, für den gewählten Bereich, mit den Personen, die Sie benachrichtigen möchten.
Eine Regel benennt einen Detektor, seine Parameter, einen Schweregrad und eine Gruppe: Sie gilt für diese Gruppe und alle darunter. Ein Standort kann eine geerbte Regel für seinen Bereich mit Begründung abschalten, sofern sie nicht gesperrt ist, und Untergruppen von seinen eigenen Regeln ausnehmen.
Verfeinern Sie jede Regel mit Bedingungen (alle, eine, nicht, verschachtelt) auf das Gerät, sein Modell und Supportende, seine Gruppe und eigenen Attribute, seine Schwachstellen und Interfaces. Die Regel zeigt ihre Bedingungen in Klartext.
Sehen Sie vor dem Speichern, wie viele Alarme die Regel auslösen würde, wie viele eine Ausnahme bereits abdeckt und welche Treffer zuerst kämen. Passen Sie Bereich, Parameter oder Bedingungen an, bis das Ergebnis stimmt.
Markieren Sie eine MAC-Adresse, einen Herstellerblock, einen Nachbarn, eine SSID, eine Adresse, ein Netz oder ein Gerät als bekannt, mit Begründung und Enddatum. Die Ausnahme erlischt von selbst: Das Rauschen sinkt, ohne einen dauerhaften blinden Fleck zu schaffen. Ausnahmen schwächen nie eine gesperrte Regel.
Weisen Sie einen Alarm einer Person oder einem Team zu, kommentieren Sie, bestätigen Sie, schließen Sie ihn mit einer Notiz oder schalten Sie ihn bis zu einem Datum stumm. Jede Aktion, gesammelt oder einzeln, bleibt in der Zeitleiste des Alarms erhalten, die nie geändert werden kann.
Entfällt die Bedingung, gilt der Alarm als behoben; kehrt sie zurück, wird derselbe Alarm mit seinen Kommentaren, seinem Bearbeiter und seinem Verlauf wieder geöffnet. Ein Alarm je Sachverhalt, nie ein Duplikat.
Benachrichtigungen in der Anwendung, gruppiert je Regel und Gruppe, nie eine pro Gerät; E-Mail je Regel nach Ereignis und Mindestschweregrad; Syslog und HTTPS-Webhook an Ihr SIEM oder Ticketsystem (ServiceNow, Jira, Slack, Microsoft Teams, PagerDuty...) in CEF, LEEF, JSON oder GELF.
Eine integrierte Soron-Übersicht (aktive und kritische Alarme, Fremdgeräte, neue Alarme über 7 Tage, mittlere Zeit bis zur Bestätigung und bis zur Behebung, Alarme nach Detektor, Gruppe und Bearbeiter) und eine Monitoring-Übersicht. Jeder Detektor hat eigene Kennzahlen für jedes Dashboard, und jede Zahl öffnet die zugrunde liegenden Alarme.
Ein Alarm gehört zur Gruppe des Geräts oder Subnetzes, das er betrifft. Benutzer lesen nur die Alarme der Gruppen, die sie sehen dürfen, und Titel nennen nur, was ihre Gruppe lesen darf, auf dem Bildschirm, in Benachrichtigungen und über die API.
Jeder Detektor lässt sich in beliebig vielen Regeln nutzen, für verschiedene Gruppen, mit eigenen Parametern, Schweregraden, Bedingungen und Ausnahmen. Beim ersten Start wird je Detektor eine Standardregel installiert; die, die Ihre Liste (verbotene Hersteller, SSIDs) oder Ihre Bedingungen brauchen, starten deaktiviert.
Ein Gerät meldet einen LLDP- oder CDP-Nachbarn, der nicht in Ihrem Inventar steht: Ein nicht verwalteter Switch, ein Heimrouter oder ein ohne Ticket angeschlossenes Gerät fällt auf, sobald es sich ankündigt.
Zwei bekannte Geräte sind zum ersten Mal miteinander verbunden: Ein zusätzliches Kabel zwischen Switches, ein neuer Uplink oder eine entstehende Schleife wird gemeldet, bevor sie jemanden überrascht.
Eine Verbindung zwischen zwei Geräten fehlt länger als Ihr Schwellenwert, und der Nachbar taucht an keinem anderen Port auf: Ein getrennter Uplink oder ein verlorener redundanter Pfad wird gemeldet, der Alarm schließt sich, sobald die Verbindung zurück ist.
Ein Switch lernt eine MAC-Adresse, die nirgendwo im Netzwerk je gesehen wurde: das erste Zeichen eines neuen Endgeräts, gemeldet mit dem Gerät und dem Port, an dem es erscheint.
Eine MAC-Adresse gehört zu einem Hersteller oder Präfix, den Sie ausgeschlossen haben (Consumer-Hardware, eine per Richtlinie ausgeschlossene Marke): Sie erfahren, wo das Gerät angeschlossen ist, kabelgebunden oder per WLAN.
Eine MAC-Adresse erscheint an einem anderen Port im selben VLAN: So fallen Endgeräte auf, die ohne Change Request umgezogen sind, und das Flapping, das eine Schleife verrät.
Ein Endgerät, das an einem Access-Port saß, hängt jetzt an einem anderen Port oder einem anderen Switch, Uplinks ausgenommen: Verfolgen Sie physische Umzüge auf dem ganzen Standort, mit alter und neuer Position.
Dieselbe MAC-Adresse ist gleichzeitig an Access-Ports zweier Geräte vorhanden, MLAG- und VSX-Paare ausgenommen: das klassische Zeichen einer geklonten oder gefälschten Adresse.
Ein Switch lernt in einem VLAN innerhalb weniger Minuten mehr neue MAC-Adressen als Ihr Schwellenwert: So erkennen Sie MAC-Flooding, einen nicht verwalteten Switch voller Clients oder einen Virtualisierungshost am falschen Port.
Ein Router oder eine Firewall löst eine IP-Adresse auf, die zu keinem bekannten Gerät gehört, und der Alarm nennt den Switch und den Port, an dem sie zuletzt gesehen wurde.
Eine genutzte IP-Adresse liegt in keinem Subnetz Ihres IPAM: Fehler bei statischer Adressierung, vergessene Bereiche und von Hand konfigurierte Geräte kommen ans Licht.
Eine Adresse antwortet per SSH, konnte aber kein verwaltetes Gerät werden (Zugangsdaten abgelehnt, Host-Key geändert, unbekannter Hersteller): Der unbekannte Teil des Netzwerks wird zu einer Liste, die sich abarbeiten lässt.
Eine Adresse antwortet in einem Ihrer Subnetze auf die Scans, ohne dass ein bekanntes Gerät dahintersteht: Das Gerät, das niemand gemeldet hat, findet das Netzwerk selbst.
Ein Access Point sendet eine SSID außerhalb Ihrer Positivliste, oder seine Clients verbinden sich damit: Fremd- und Testnetze werden mit dem Access Point benannt, der sie ausstrahlt.
Eine SSID aus Ihrer Sperrliste wird ausgestrahlt oder genutzt: So fällt das vergessene Gästenetz in einem sensiblen Gebäude ebenso auf wie ein bekannter Evil-Twin-Name.
Ein Gerät meldet eine neue Softwareversion: Jedes Upgrade und jedes Downgrade wird festgehalten, auch die, die niemand angekündigt hat.
Ein Gerät läuft mit einer älteren Version als das Ziel-Image Ihrer Bibliothek: Der Upgrade-Rückstand wird zu einer Liste von Alarmen, die sich mit jedem aktualisierten Gerät von selbst schließen.
Die laufende Konfiguration hat sich geändert, während auf dem Gerät weder eine Bastion-Sitzung noch ein Skript, ein Firmware-Upgrade oder eine ZTP-Bereitstellung von ConnectMyAssets lief: Die Änderung außerhalb Ihres Prozesses fällt bei der nächsten Erfassung auf.
Ein Gerät präsentiert einen anderen SSH-Host-Key als den vertrauenswürdigen: Ein ausgetauschtes Gerät oder ein Abfangversuch wird gestoppt, bis jemand den neuen Schlüssel akzeptiert.
Ein bisher erfasstes Gerät scheitert nun bei jeder Erfassung (ein Passwort, das nicht mehr funktioniert, ein Timeout): Inventar und Backups veralten nicht unbemerkt.
Ein inventarisiertes Gerät mit geplanter Erfassung wurde länger als erlaubt nicht erfasst, mit dem Grund des letzten Versuchs: Ein entferntes, gestohlenes oder abgetrenntes Gerät fällt auf.
Mehr Geräte als Ihr Schwellenwert verschwinden gleichzeitig: ein einziger Alarm für einen Standortausfall, eine WAN-Unterbrechung oder eine Firewall-Änderung statt Hunderter.
Ein Gerät der von Ihnen gewählten Typen fällt unter den festgelegten Compliance-Score: Das Abdriften der Härtung wird vor dem Audit sichtbar.
Ein Gerät verfehlt eine Compliance-Richtlinie, die es kurz zuvor noch erfüllt hat, für die gewählten Schweregrade: Sie wissen, welche Änderung welche Kontrolle gebrochen hat, und wann.
Ein Gerätemodell erreicht innerhalb der festgelegten Anzahl Tage sein End of Support oder End of Life, oder hat es bereits erreicht: Erneuerungen werden geplant, bevor der Support endet.
Ein Gerät hat keinen Hostnamen: eine schnelle Hygieneprüfung, die Logs, Karten und Tickets lesbar hält.
Ein Gerät, eine Gruppe von Netzwerkgeräten oder ein Subnetz erfüllt Bedingungen auf Ihre eigenen Attribute (Verantwortlicher, Vertragsende, Kritikalität, Standortcode), geerbte Werte eingeschlossen.
Eine Gruppe, die kein geplanter Scan abdeckt, ein Subnetz, das jeder Scan ausschließt, ein Gerät, das keine Erfassung erreicht: Die blinden Flecken Ihrer Überwachung werden täglich aufgelistet.
Ein Subnetz erreicht den festgelegten Auslastungsschwellenwert: Erweitern oder bereinigen Sie es, bevor dem DHCP die Adressen ausgehen.
Zwei Standorte oder zwei Kunden deklarieren überlappende Subnetze: Der Adresskonflikt fällt auf, bevor das Routing oder eine Fusion ihn offenlegt.
Ein Gerät wurde an einer Adresse gefunden, die in keinem Subnetz Ihrer Gruppen liegt, und landete deshalb unter „Unassigned“: Sie erfahren, welches Subnetz Sie deklarieren oder welches Gerät Sie zuordnen sollten.
Ein Gerät antwortet nicht mehr auf ICMP: das erste Signal eines Stromausfalls, einer unterbrochenen Verbindung oder eines abgestürzten Geräts, aufgehoben, sobald es wieder antwortet.
Die Round-Trip-Zeit zu einem Gerät überschreitet Ihren Schwellenwert: Überlastete WAN-Verbindungen und Standorte fallen auf, bevor die Anwender anrufen.
Der Paketverlust zu einem Gerät überschreitet Ihren Schwellenwert: So fällt die defekte Verbindung oder Optik auf, die Datenverkehr verwirft, ohne auszufallen.
Die CPU eines Geräts bleibt über Ihrem Schwellenwert: Eine Überlastung der Control Plane, ein Routing-Sturm oder ein hängender Prozess wird gemeldet.
Die Speichernutzung eines Geräts überschreitet Ihren Schwellenwert: Speicherlecks und Tabellen, die der Hardware entwachsen, werden vor dem Neustart erkannt.
Eine beliebige numerische Metrik Ihrer Wahl überschreitet Ihren Schwellenwert (Temperatur, Interface-Fehler, PoE, Clients, Sitzungen, ausgefallene BGP-Peers, Kanalauslastung), je Interface, SSID oder Funkmodul, wo das zutrifft.
Ein Netzteil, ein Lüfter, ein Stack oder ein Hochverfügbarkeitspaar meldet einen Status außerhalb der zulässigen Werte: Hardwareausfälle werden erkannt, solange die Redundanz noch greift.
Ein Port, den Sie als verboten markiert haben (Telnet, SMB, eine Admin-Konsole), ist auf einem Host offen: ein Alarm je Host und Port, geschlossen, sobald der Port schließt.
Ein TLS-Dienst präsentiert ein abgelaufenes Zertifikat: Host, Port und Ablaufdatum werden genannt, damit die Erneuerung beim richtigen Team landet.
Ein Zertifikat läuft innerhalb der festgelegten Anzahl Tage ab: Erneuern Sie es, bevor Integrationen, Anmeldungen und Backups ausfallen.
Ein Dienst nutzt noch ein selbstsigniertes Zertifikat: Drucker, Kameras, USV-Karten und BMCs, die Anwendern beibringen, Browserwarnungen zu ignorieren, werden aufgelistet.
Ein offener Port erfüllt Ihre eigenen Bedingungen an sein Zertifikat oder seinen Dienst (ein anderer Aussteller als Ihre CA, ein RSA-Schlüssel unter 2048 Bit, TLS 1.0 oder 1.1, ein Wildcard-Zertifikat, ein unerwarteter Webserver).
Jedes Gerät, das Ihre Bedingungen auf eines seiner Felder, seine Gruppe und die verknüpften Datensätze erfüllt: „ein Core-Switch ohne Support an einem kritischen Standort“, in wenigen Klicks formuliert.
Jede Schwachstelle, die Ihre Bedingungen auf Befund, CVE und Gerät erfüllt: „EPSS über 20 % und seit mehr als 7 Tagen offen auf einer Firewall“.
Jedes Interface, das Ihre Bedingungen erfüllt: ein Access-Port ohne Beschreibung, ein Uplink mit falscher Geschwindigkeit, ein Interface, das in einem Produktions-VLAN down ist.
Jeder MAC-Tabelleneintrag, der Ihre Bedingungen erfüllt: ein Herstellerblock im falschen VLAN, eine Kamera außerhalb des Videonetzes, eine Adresse an einem Port, den sie nie nutzen sollte.
Jeder ARP-Eintrag, der Ihre Bedingungen erfüllt: ein Adressbereich auf dem falschen Router, ein Gateway, das zu einer unerwarteten MAC-Adresse aufgelöst wird.
Jede Sicherheitsregel von FortiGate oder PAN-OS, die Ihre Bedingungen erfüllt: any/any erlaubt, Logging aus, ein unsicherer Dienst zwischen Zonen, eine Regel außerhalb Ihrer Namenskonvention.
Eine CVE mit einem CVSS-Basiswert von 9.0 oder mehr betrifft neu den Hersteller, das Modell und die Firmware eines Geräts: die Notfälle des Tages, Gerät für Gerät.
Eine CVE, deren CVSS-Wert, ConnectMyAssets-Risikobewertung oder EPSS Ihren Schwellenwert erreicht, betrifft ein Gerät: Sie legen die Grenze fest, je Gruppe von Netzwerkgeräten.
Ein akzeptiertes Risiko, eine Dringlichkeitsmarkierung oder eine Whitelist hat ihr Enddatum erreicht, während die CVE weiterhin zutrifft: Risikoentscheidungen werden neu geprüft, statt ewig zu gelten.
Eine CVE aus dem CISA-Katalog Known Exploited Vulnerabilities betrifft ein Gerät, mit dem Datum der Aufnahme durch die CISA: Was Angreifer bereits nutzen, kommt zuerst.
Die CISA hat gerade eine CVE in ihren Katalog aufgenommen, die eines Ihrer Geräte betrifft: Eine eben aktiv gewordene Bedrohung wird innerhalb der von Ihnen gewählten Tage gemeldet.
Eine bekannt ausgenutzte CVE, die von Ransomware-Kampagnen genutzt wird, betrifft ein Gerät: die Befunde, die einen Notfall-Change rechtfertigen.
Eine CVE, deren EPSS (die von FIRST veröffentlichte Wahrscheinlichkeit einer Ausnutzung in den nächsten 30 Tagen) Ihren Schwellenwert erreicht, betrifft ein Gerät: Priorisieren Sie nach Wahrscheinlichkeit, nicht nur nach Schweregrad.
Der EPSS einer CVE auf einem Ihrer Geräte steigt um die gewählten Punkte innerhalb der gewählten Tage: Eine Schwachstelle, die Angreifer ins Visier nehmen, wird früh erkannt.
Eine CVE bleibt auf einem Gerät länger offen als Ihre Frist für ihre Art (bekannt ausgenutzt, kritisch oder hoch) und wird kritisch, sobald sich die Verzögerung verdoppelt hat: Ihr Patch-SLA wird durchgesetzt.
Eine bekannt ausgenutzte CVE ist auf mindestens der festgelegten Anzahl Geräte offen: ein Alarm je CVE, mit den Geräten jeder Gruppe, damit Sie eine Kampagne statt hundert Tickets fahren.
Nur die bekannt ausgenutzten CVEs, deren Firmwareversion in einem veröffentlichten Bereich liegt, ohne dass etwas zu bestätigen bleibt, mit der korrigierten Version und dem Herstellerhinweis: kein Zweifel, bevor Sie handeln.
Eine CVE, die ein Gerät nur „möglicherweise“ betraf, wird nun durch die Firmwaredaten bestätigt: Die zurückgestellten Befunde verdienen einen zweiten Blick.
Hersteller, Modell und Firmware eines Geräts lassen sich von unserem Schwachstellendienst nicht auflösen: Keine bekannte Schwachstelle heißt nicht keine Schwachstelle, und Sie wissen, wo Sie nachsehen müssen.
Für Netzwerk- und Security-Engineers: woher die Daten kommen, wann Regeln ausgewertet werden und wie Alarme leben.
Jeder Detektor liest, was ConnectMyAssets bereits speichert: SSH-Erfassungen (Konfigurationen, MAC- und ARP-Tabellen, LLDP/CDP, Interfaces, Versionen), Netzwerkscans und geprüfte Ports, Monitoring-Messwerte, Compliance-Ergebnisse und Schwachstellendaten. Keine zusätzliche Sonde, keine zusätzlichen Zugangsdaten.
Regeln laufen nach jeder Erfassung eines Geräts und am Ende jedes Scans, beschränkt auf das gerade Gelesene; alle fünf Minuten für das, was sich allein durch Zeit ändert (ein verschwundenes Gerät, eine entfernte Verbindung); stündlich und täglich über ihren gesamten Bereich; und sofort, wenn eine Regel angelegt oder geändert wird.
Ein Bedingungsdetektor (ein offener Port, ein abgelaufenes Zertifikat) behebt seinen Alarm, wenn die Bedingung entfällt, und öffnet ihn wieder, wenn sie zurückkehrt. Ein Ereignisdetektor (eine gewanderte MAC-Adresse, eine geänderte Konfiguration) zählt jedes neue Auftreten im selben Alarm, den eine Person schließt.
Ereignisregeln starten ab ihrem Erstellungsdatum, abzüglich eines von Ihnen festgelegten Rückblicks (standardmäßig 24 Stunden): Eine heute angelegte Regel meldet keine MAC-Adressen, die im letzten Jahr gelernt wurden, und die erste Erfassung eines Geräts ist sein Inventar, keine Neuigkeit.
Jede Regel wird als eine einzige Abfrage über ihren gesamten Bereich ausgewertet, nie als Schleife über Geräte, und bei großen Hierarchien wird die Arbeit je Gruppe aufgeteilt. Die Aufbewahrung geschlossener Alarme legen Sie fest (standardmäßig 365 Tage).
Alarme, Regeln und Ausnahmen stehen über die REST API (zum Beispiel GET /api/v1/soron/alerts) mit bereichsbezogenen API-Tokens zur Verfügung, und jede Änderung einer Regel oder Ausnahme wird im Audit-Trail festgehalten.
Starten Sie mit einer Standardregel oder wählen Sie einen der Detektoren, und legen Sie dann Parameter, Schweregrad, Bedingungen und Gruppe fest.
Prüfen Sie, was die Regel finden würde, und verfeinern Sie sie vor der Aktivierung.
Erhalten Sie Alarme in der Konsole, per E-Mail, Syslog oder Webhook, ab dem von Ihnen gewählten Schweregrad.
Bestätigen, zuweisen und beheben mit vollständigem Verlauf, und verfolgen Sie Ihre Reaktionszeiten auf einem Dashboard.
Bereiten Sie Ihr Projekt vor und legen Sie Ihren Umfang fest.
Soron umfasst 62 Detektoren in zehn Familien: Topologie und Nachbarn; MAC, ARP und Adressierung; Fremdgeräte und WLAN; Konfiguration, Firmware und Erfassung; Compliance und Lebenszyklus; Abdeckung und IPAM; Monitoring; Ports und Zertifikate; Bedingungen auf beliebige Daten; Schwachstellen. Die vollständige Liste steht auf dieser Seite.
Behalten Sie die Standardregeln für unbekannte LLDP/CDP-Nachbarn, neue MAC-Adressen, unbekannte Geräte in ARP-Tabellen und unbekannte Geräte, die auf Scans antworten, und ergänzen Sie Ihre Liste verbotener Hersteller. Jeder Alarm nennt den Switch und den Port, an dem das Gerät gesehen wurde, und die Liste der Fremdgeräte fasst alle zusammen.
Legen Sie jede Regel auf die richtige Gruppe, ergänzen Sie Bedingungen und prüfen Sie die Vorschau vor der Aktivierung. Ausnahmen mit Ablaufdatum fangen bekannte Fälle ab, Stummschaltungen bringen einen Alarm bis zu einem Datum zum Schweigen, und Benachrichtigungen werden je Regel und Gruppe gebündelt, nie eine pro Gerät.
Ja. Regeln gehören zu Gruppen von Netzwerkgeräten und werden an Untergruppen vererbt; ein Standort oder Kunde kann eine geerbte Regel abschalten, sofern sie nicht gesperrt ist, und eigene Regeln hinzufügen. Alarme respektieren die Berechtigungen jedes Benutzers und folgen dem im Kopfbereich gewählten Bereich.
Soron wertet die Regeln nach jeder Erfassung eines Geräts und am Ende jedes Scans aus, auf Basis des gerade Gelesenen. Da sich Erfassungen und Scans bis zu alle 5 Minuten planen lassen, halten Alarme mit Ihrem Netzwerk Schritt; zeitbasierte Detektoren werden zudem alle fünf Minuten geprüft.
Ja. Alarme gehen an Syslog (RFC 5424 oder RFC 3164, über UDP, TCP oder TLS) und an HTTPS-Webhooks in CEF, LEEF, JSON (ECS) oder GELF, womit Soron mit ServiceNow, Jira, Slack, Microsoft Teams, PagerDuty und Ihrem SIEM kompatibel ist. E-Mail wird je Regel eingestellt.
Ja. Jeder Detektor akzeptiert Bedingungen, und sechs Detektoren lösen einen Alarm für jedes Gerät, jede Schwachstelle, jedes Interface, jeden MAC-Eintrag, jeden ARP-Eintrag oder jede Firewall-Regel aus, die Ihre Bedingungen auf ein beliebiges Feld erfüllen. Die Regel zeigt ihre Bedingungen in Klartext, und die Vorschau zeigt, was sie findet.
Nein. Soron sendet nichts an die Geräte: Es arbeitet mit den Daten, die ConnectMyAssets bereits über SSH und seine Netzwerkscans erfasst. Was es sehen kann, ist das, was Ihr Inventar enthält, weshalb Abdeckungslücken einen eigenen Detektor haben.
Sehen Sie, was ConnectMyAssets für Ihr Team verändern kann. Auf Ihrer Infrastruktur, mit Ihren Anforderungen.
Demo anfordern