Funktionen von NetSenX
Was NetSenX in Ihrem Netzwerk tut und wie Sie es prüfen können
NetSenX beobachtet, wie sich die Hosts in Ihrem Netzwerk verhalten, löst einen Alarm aus, wenn dieses Verhalten nach einem Angriff aussieht, und erklärt jeden Alarm in verständlicher Sprache. Die Erkennungsergebnisse durchlaufen eine konforme Schicht, die angibt, mit welcher Sicherheit sie gelten, und jede Modellversion wird festgehalten. Unten steht, was jede Funktion leistet, welchen Plan sie voraussetzt und was sie nicht leistet.
Verhaltensbasierte Erkennung
Verhalten statt Signaturen
Die Engine bewertet, wie sich jeder Host im Netzwerk verhält. So hinterlässt auch eine neue Malware-Variante ohne Signatur eine Spur.
Sie achtet auf die Schritte, die einem Datenabfluss vorausgehen: C2-Beaconing (Command-and-Control), Scans, laterale Bewegung und ungewöhnliches ausgehendes Datenvolumen.
NetSenX arbeitet neben Ihrem EDR und SIEM. Es ergänzt die Netzwerksicht, die diesen fehlt, und ersetzt sie nicht.
Auf einen Blick
- C2-Beaconing (Command-and-Control)
- Scans und laterale Bewegung
- Ungewöhnliches ausgehendes Datenvolumen
Begrenzte Fehlalarme
NetSenX Math Guarantee
Eine Split-Conformal-Schicht leitet für die von der Engine gemeldeten Alarme eine Fehlalarm-Obergrenze für endliche Stichproben ab, auf einem von Ihnen eingestellten Konfidenzniveau und aus harmlosem Verkehr, den Ihre Analysten im eigenen Netzwerk markiert haben. Die Obergrenze folgt aus der Konstruktion, nicht aus einem Schwellenwert, der so lange justiert wurde, bis die Zahlen gut aussahen.
Jeder Alarm nennt seine Sicherheit in verständlichen Worten, zusammen mit der Modellversion, die ihn erzeugt hat, und ein Alarm mit nicht kalibrierter Bewertung ist als vorläufig gekennzeichnet. Ihre Prüfer sehen dieselben Belege wie Ihr Team.
Ihr Dashboard zeigt die Obergrenze, die Ihre Kalibrierungsdaten derzeit stützen. Stützen sie noch keine, sagt das Dashboard genau das und nennt, was fehlt, statt eine Zahl zu zeigen, die es nicht belegen kann.
Auf einen Blick
- Split-Conformal-Obergrenze auf einem angegebenen Konfidenzniveau
- Ein klarer Status „noch nicht gestützt“ statt einer erfundenen Zahl
- In jedem Plan enthalten, auch im Free-Plan
Laterale Bewegung
Korrelation über das ganze Netzwerk
Erkennung auf Flow-Ebene sieht, was in einer einzelnen Verbindung geschieht. Angriffe bleiben selten bei einem Host: Nach dem ersten Fuß in der Tür scannt ein Eindringling, meldet sich an der nächsten Maschine an und arbeitet sich zu den Daten vor.
Ab dem Pro-Plan verknüpft NetSenX die Hosts Ihres Netzwerks zu einem Graphen, wer mit wem kommuniziert. So erscheinen laterale Bewegung und Gruppen von Hosts, die dasselbe Ziel anfunken, als eine zusammenhängende Geschichte statt als verstreute Alarme.
Diese Alarme enthalten die Hosts und Verbindungen dahinter als Beleg, bereit für einen Vorfallsbericht oder eine Meldung an Ihre Behörde.
Auf einen Blick
- Laterale Bewegung und C2-Cluster über Hosts hinweg
- Die Hosts und Verbindungen hinter jedem Alarm
- Benannte MITRE-ATT&CK-Technik, wo eine passt
Verschlüsselter Verkehr
NetSenX TLS Fingerprint Engine
Angriffswerkzeuge hinterlassen im TLS-Handshake eine Signatur, bevor sie Daten bewegen. Ab dem Starter-Plan liest NetSenX die Handshake-Parameter und erkennt verdächtige Clients schon beim Handshake, bevor Nutzdaten ausgetauscht werden. Der Handshake ist nur sichtbar, wo der Agent Pakete mitschneidet: unter Linux oder als Sensor an einem SPAN- oder TAP-Port, nicht im Basismodus unter macOS.
Das funktioniert bei verschlüsselten Verbindungen, ohne sie zu entschlüsseln: kein Abfang-Proxy, kein Zertifikat auf Ihren Geräten.
Ein einziger Handshake speist sowohl die Verhaltensbewertung des Hosts als auch die netzwerkweite Korrelation.
Auf einen Blick
- Erkennung beim Handshake, vor jeder Nutzlast
- Keine TLS-Entschlüsselung
- Speist Host- und netzwerkweite Erkennung
Triage in Klartext
NetSenX AI Analyst Core
Viele NDR-Alarme kommen als Rohdatenfelder an und gehen als Tickets weiter. Ist der AI Analyst Core eingeschaltet, erhält jeder Alarm eine Notiz in verständlicher Sprache: was passiert ist, warum es wichtig ist und was als Nächstes zu tun ist.
Die Notizen schreiben Modelle in festgeschriebenen Versionen mit dokumentierter Herkunft, gegliedert für die Meldungen nach Art. 14 CRA und Art. 21 NIS2. Die Fakten für Ihren Vorfallsbericht liegen damit schon an einem Ort.
Er läuft mit Ihrem eigenen Schlüssel eines KI-Anbieters in jedem kostenpflichtigen Plan und bleibt aus, bis Sie ihn einrichten. Die Erkennung funktioniert auch ohne ihn.
Auf einen Blick
- Eine Notiz in Klartext pro Alarm
- Gegliedert für CRA- und NIS2-Meldungen
- Modellversion bei jeder Notiz festgehalten
OT / ICS · ab dem Pro-Plan
Industrieprotokolle, passiv beobachtet
Modbus/TCP, DNP3, BACnet/IP, EtherNet/IP und S7comm werden aus der passiven Erfassung an einem SPAN- oder TAP-Port gelesen.
Als OT eingestufte Geräte werden nie aktiv abgefragt. Es gibt kein Risiko für SPS oder SCADA, und an den Steuerungen ändert sich nichts.
OT-Verkehr erscheint im selben Dashboard wie das IT-Netzwerk, mit derselben verständlichen Erklärung bei jedem Alarm.
Auf einen Blick
- Modbus/TCP, DNP3, BACnet/IP, EtherNet/IP, S7comm
- Keine aktive Abfrage von OT-Geräten
- Ab dem Pro-Plan
Shadow AI · ab dem Pro-Plan
Sehen, welche KI-Dienste Ihr Netzwerk nutzt
NetSenX markiert Verkehr zu externen KI-Diensten und zu Sprachmodell-Laufzeiten, die auf Ihren eigenen Rechnern laufen. So wird nicht freigegebene KI-Nutzung sichtbar, bevor sie zum Datenschutzthema wird.
Sie sehen, welcher Host wann welchen KI-Dienst erreicht hat und wie viele Daten geflossen sind. Verschlüsselter Verkehr wird nie entschlüsselt; der Inhalt eines Prompts bleibt ungelesen.
Klären Sie zuerst, was tatsächlich genutzt wird, und schreiben Sie dann eine KI-Richtlinie, an die sich Ihre Mitarbeitenden halten können.
Auf einen Blick
- Externe KI-Dienste und lokale Modell-Laufzeiten
- Welcher Host, welcher Dienst, wie viele Daten
- Ab dem Pro-Plan
Belege inklusive
Prüfbereite Compliance
NetSenX verfolgt jeden Vorfall entlang der Fristen aus Art. 23 NIS2 — Frühwarnung binnen 24 Stunden, Meldung binnen 72 Stunden, Abschlussbericht binnen eines Monats — und bereitet für Ihren Datenschutzbeauftragten eine Meldung nach Art. 33 DSGVO vor. Das Einreichen bleibt bei Ihnen.
Alarme, Entscheidungen der Analysten und Konfigurationsänderungen landen in einem Audit-Log, das Sie Ihrem Prüfer übergeben können, und die Belege sind für CRA-, NIS2-, DSGVO- und KI-Verordnungs-Prüfungen geordnet.
SOC 2, ISO/IEC 42001 und ISO/IEC 27001 sind in Vorbereitung; keines ist bisher erteilt, und ein Datum nennen wir erst, wenn ein Audit gebucht ist.
Auf einen Blick
- NIS2-Fristen je Vorfall verfolgt
- Audit-Log für Alarme, Entscheidungen und Änderungen
- SOC 2, ISO 42001 und ISO 27001 in Vorbereitung
NetSenX Math Guarantee
Eine Fehlalarm-Obergrenze, die Sie prüfen können, keine Zahl, die Sie glauben müssen.
Hinter der Erkennung sitzt eine Split-Conformal-Schicht. Sie leitet für die von der Engine gemeldeten Alarme eine Fehlalarm-Obergrenze ab, auf einem von Ihnen eingestellten Konfidenzniveau und aus harmlosem Verkehr, den Ihre Analysten im eigenen Netzwerk markiert haben. Ihr Dashboard zeigt die Obergrenze, die diese Daten derzeit stützen, und sagt bei zu kleiner Kalibrierungsmenge genau das, statt eine Zahl zu zeigen.
Split-Conformal Prediction
Jeder Alarm nennt seine Sicherheit in verständlichen Worten und sagt es, wenn seine Bewertung noch nicht kalibriert ist. Wo die statistische Garantie greift, folgt die Fehlalarm-Obergrenze unter den gemeldeten Alarmen aus der Konstruktion des Prädiktors auf einem angegebenen Konfidenzniveau; sie ist kein Schwellenwert, der so lange justiert wurde, bis die Zahlen gut aussahen.
Modell-Governance
Modelle haben festgeschriebene Versionen, ihre Herkunft wird dokumentiert. Die Math Guarantee gehört zum KI-Managementsystem, das wir nach ISO/IEC 42001 aufbauen, nicht in eine Marketing-Fußnote.
Wozu wir uns verpflichten
Zur Methode und zu den Belegen: die Obergrenze, die Ihre Kalibrierungsdaten stützen, die Stichprobengröße dahinter und ein klarer Status „noch nicht gestützt“, wenn sie keine stützen. Eine Fehlalarmquote, die wir nicht auf Ihren Daten gemessen haben, veröffentlichen wir nicht.
Noch nicht kalibriert
Zu wenig von Analysten markierter harmloser Verkehr, um irgendeine Obergrenze zu stützen. Das Produkt sagt genau das und nennt, was fehlt; es zeigt keine Null.
Aktiv — weitere Obergrenze
Die Kalibrierungsdaten stützen eine Obergrenze, aber eine lockerere als das eingestellte Ziel. Das Produkt sagt, dass es hinter der weiteren Obergrenze steht, und zeigt trotzdem keine Zahl, weil das engere Ziel nie erreicht wurde.
Aktiv — Ziel-Obergrenze
Der Kalibrierungsumfang stützt das eingestellte Konfidenzniveau. Das ist der einzige Zustand mit einer Zahl, und sie kommt nie allein: Obergrenze, Anzahl der geprüften Stichproben und das Zeitfenster ihrer Messung erscheinen zusammen.
Wartet auf Neukalibrierung
Die Kalibrierung hinter der Obergrenze ist veraltet, oder der Verkehr, auf dem sie beruht, hat sich vom heutigen Netzwerk entfernt. Die Obergrenze wird zurückgezogen, bis eine frische Kalibrierung sie ersetzt; eine veraltete Zahl bleibt nicht stehen, nur weil sie einmal stimmte.
Wird erneut geprüft
Ein Kalibrierungs-Update wird geprüft, bevor es wirksam wird. Solange das läuft, ist die vorherige Aussage zurückgezogen.
Das sind die Zustände, die das Produkt tatsächlich liefert: Keiner zeigt eine Obergrenze, die die Kalibrierungsdaten nicht stützen. Vergleichszahlen anderer Anbieter veröffentlichen wir nicht, weil wir solche Tests nicht durchgeführt haben.
NetSenX AI Analyst Core
Zu jedem Alarm eine Notiz, mit der ein Analyst arbeiten kann.
Rohe Alarmdaten stehen neben einer Notiz in verständlicher Sprache: was passiert ist, warum es wichtig ist und welche Reaktion empfohlen wird, gegliedert für Ihre Meldungen nach Art. 14 CRA und Art. 21 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 von finance-srv-04 zu einer bisher nie gesehenen Domain (delta-cargo-track.xyz) erkannt, die vor 6 Stunden registriert wurde. Der ausgehende Verkehr ist klein, periodisch und mit geringem Jitter: ein Muster, das zu Command-and-Control nach einer ersten Kompromittierung passt.
Die Graph-Schicht hat außerdem beobachtet, dass zwei weitere Hosts im Finanz-Subnetz (finance-srv-02, finance-srv-09) dieselbe Domain in den letzten 90 Minuten per DNS abgefragt haben.
Empfohlene Reaktion
- finance-srv-04 vom produktiven VLAN isolieren.
- Vor dem Neustart ein Speicherabbild für die forensische Analyse sichern.
- Das Finanz-Subnetz auf weitere Hosts prüfen, die dieselbe Domain oder IP-Adresse kontaktieren.
- Ein Ticket nach Ihrem Incident-Response-Runbook eröffnen; der Alarm ist bereits für die Vorfallserfassung nach Art. 14 CRA gegliedert.
Sehen Sie es in Ihrem eigenen Netzwerk
Starten Sie mit dem Free-Plan für bis zu 3 Geräte: ohne Zeitlimit, ohne Kreditkarte. Oder buchen Sie eine 20-minütige Demo, in der wir einen echten Alarm von der Erfassung bis zur Analysten-Notiz durchgehen, mit dem Audit-Trail in jedem Schritt.