NetSenX: Pläne und Einrichtung
20 Fragen zu NetSenX: Pläne und Einrichtung, verständlich beantwortet: was zu prüfen ist, was NetSenX zeigt und was ein Sensor nicht sieht.
Jeder Plan, auch der Free-Plan, erkennt Beaconing, Scans, laterale Bewegung und ungewöhnliches ausgehendes Volumen, erklärt jeden Alarm verständlich und führt eine Netzwerkkarte; höhere Pläne fügen Berichte, Integrationen und spezialisierte Überwachung hinzu. Free kostet 0 € für bis zu 3 Geräte mit 30 Tagen Alarmhistorie, dazu Nachverfolgung der NIS2-Fristen, ein Audit-Log und Zwei-Faktor-Anmeldung. Free und Solo umfassen die Computer, auf denen der Agent installiert ist; ein Netzwerksensor an einem SPAN- oder TAP-Port ist ab Starter verfügbar. Starter für 49 € pro Monat und bis zu 10 Geräte ergänzt PDF-Berichte, manuelle Reaktionsmaßnahmen, Teamverwaltung und TLS-Fingerprinting dort, wo der Agent Pakete erfasst. Solo bietet für 19 € pro Monat die Erkennung, Berichte und Reaktionsmaßnahmen von Starter für genau einen Computer, den, auf dem der Agent installiert ist, und einen Benutzer, ohne Teamverwaltung und ohne zusätzliche Geräte. Pro für 99 € und bis zu 25 Geräte ergänzt Shadow-AI-Sichtbarkeit, passive Überwachung von OT-Protokollen, die API, Slack und Webhooks sowie das Krypto-Inventar NQCI, das Paketerfassung unter Linux oder einen SPAN- bzw. TAP-Sensor braucht. Business für 249 € und bis zu 100 Geräte ergänzt SIEM-Export und Breach and Attack Simulation. Enterprise ab 999 € bringt unbegrenzt viele Geräte, eigene Erkennungsrichtlinien, White Label, On-Premises-Betrieb und Single Sign-on. Die Preise gelten pro Monat ohne Mehrwertsteuer. Berichte: Free: Keine Berichte (Gebrauchsanweisung nach KI-Verordnung enthalten). Solo und Starter: Betriebsberichte (NIS2-Vorfall, DSGVO, monatlich, MITRE); Audit-Paket bei jährlicher Abrechnung. Pro, Business und Enterprise: Alle Berichte einschließlich Audit-Paket.
Sie haben die Wahl: ein Agent an einem SPAN- oder TAP-Port überwacht ein ganzes Netzwerksegment, oder Sie installieren den Agenten auf den Hosts, die Sie überwachen möchten. Der Agent läuft als Systemdienst unter Linux und macOS; unter Linux akzeptiert das Installationsprogramm nur ein mit dem NetSenX-Release-Schlüssel signiertes Paket, Agenten für macOS werden gemeinsam mit dem NetSenX-Support eingerichtet. Das Dashboard ist ein in der EU gehosteter Dienst; eine On-Premises-Variante gibt es im Enterprise-Plan.
Sie wählen die Bereitstellung: Ein einzelner SPAN-/TAP-Port an Ihrem Switch deckt ein ganzes Netzwerksegment ab und zählt als ein Gerät, oder Sie installieren den NetSenX-Agenten auf den von Ihnen gewählten Hosts. Beides ist dokumentiert; keine Kernel-Module. Unter Linux installiert das Installationsprogramm nur ein Paket, dessen Signatur zum NetSenX-Release-Schlüssel passt, und lehnt alles andere ab; Agenten für macOS richten wir gemeinsam mit dem NetSenX-Support ein.
Der NetSenX-Agent läuft unter Linux und macOS, und ein einziger Agent an einem SPAN- oder TAP-Port beobachtet jedes Gerät in diesem Segment, ganz gleich, welches Betriebssystem es nutzt. Unter Linux wird der Agent mit einem einzeiligen Befehl aus dem Dashboard als Systemdienst installiert, und das Installationsprogramm akzeptiert nur ein mit dem NetSenX-Release-Schlüssel signiertes Paket. Unter macOS wird er aus einem signierten Paket installiert und läuft als Hintergrunddienst; macOS-Agenten werden gemeinsam mit dem NetSenX-Support eingerichtet. Hat Ihr Unternehmen auch Rechner mit anderen Betriebssystemen oder Drucker, Kameras, Telefone und Maschinen, auf denen kein Agent läuft, setzen Sie einen Agenten auf einen Host an einem Spiegelport: Er sieht deren Verkehr, ohne dass auf ihnen etwas installiert wird. Das ist meist der einfachste Weg, ein gemischtes Büro abzudecken. Nicht sehen kann der Agent Verkehr in Segmenten, die Sie nicht spiegeln, und Vorgänge in einem Rechner, die das Netz nie berühren.
Er ist so gebaut, dass er das nicht tut, und der sicherste Weg, einen Server gar nicht zu belasten, ist, ihn dort nicht zu installieren: Ein Agent auf einem Host an einem Spiegelport beobachtet das ganze Segment, ohne die Server darin zu berühren. Ein Spiegelport kopiert den Verkehr im Switch, die überwachten Server verarbeiten also nichts zusätzlich, und der Netzwerkpfad selbst ändert sich nicht: Der Sensor erhält nur eine Kopie. Installieren Sie den Agenten doch auf einem Server, liest er Verbindungsmetadaten und einige Protokollfelder wie Zeitpunkt, Volumen, Ziele, DNS-Antworten und, wo Pakete erfasst werden, den TLS-Handshake. Er entschlüsselt nie Verkehr und leitet keine Verbindungen um oder blockiert sie. Wie bei jeder neuen Software auf einem ausgelasteten Server sollten Sie den Ressourcenverbrauch in den ersten Tagen beobachten und zuerst auf einem weniger kritischen Host testen. Fragen Sie vor dem Einsatz an Leitungen mit sehr hohem Verkehr den NetSenX-Support.
Der Basismodus sieht Verbindungen, Zeitpunkte und Volumen; die Paketerfassung liest zusätzlich die unverschlüsselten Felder des TLS-Handshakes, die einige Funktionen brauchen. Unter macOS läuft der Agent in einem Basismodus, der die Verbindungen des Mac beobachtet, auf dem er installiert ist. Das genügt für die zentralen Erkennungen wie Beaconing, Scans, laterale Bewegung und ungewöhnliches ausgehendes Volumen. Paketerfassung bedeutet, dass der Agent die Pakete selbst kopiert, um einige Protokollfelder zu lesen, weiterhin ohne etwas zu entschlüsseln. Sie ist verfügbar, wo der Agent unter Linux läuft oder als Sensor an einem SPAN- oder TAP-Port. Zwei Funktionen hängen davon ab: TLS-Fingerprinting ab dem Starter-Plan, das bekannte Schadsoftware-Clients an ihrem Handshake erkennt, und das Krypto-Inventar NQCI, aktiv ab dem Pro-Plan, das quantenanfälligen und hybriden Schlüsselaustausch zeigt. Brauchen Sie eine davon, planen Sie einen Linux-Agenten oder einen Sensor am Spiegelport ein.
NQCI ist in jedem Plan als Vorschau sichtbar, ab dem Pro-Plan aktiv und braucht den Paketerfassungs-Sensor, der standardmäßig ausgeschaltet ist. Sie brauchen zwei Dinge. Erstens einen Pro-, Business- oder Enterprise-Plan. Zweitens einen Agenten, der Pakete erfasst: entweder einen Linux-Agenten mit eingeschalteter Paketerfassung oder einen Agenten auf einem Host an einem SPAN- oder TAP-Port. Der Basismodus unter macOS sieht keine TLS-Handshakes und kann das Inventar daher nicht speisen. Sobald es läuft, zeigt NQCI, welche Verbindungen durch das überwachte Segment quantenanfälligen Schlüsselaustausch nutzen und welche bereits hybriden Post-Quanten-Schlüsselaustausch, dazu die SSH-Serverversionen, die es sieht. Es befindet sich weiterhin in der Vorschau. Kryptografie in Anwendungen oder auf Datenträgern sieht es nicht, es migriert nichts und erledigt Ihre Compliance-Arbeit nicht für Sie; es liefert ein erstes Inventar aus dem Netzwerk.
Ja, Alarme und Geräteinventar beginnen, sobald Verkehr fließt, doch die Vergleiche mit dem normalen Verhalten jedes Hosts werden besser, während NetSenX Ihr Netz kennenlernt. Am ersten Tag sehen Sie Geräte auf der Netzwerkkarte erscheinen, und eindeutige Muster wie Scans oder regelmäßige Verbindungen nach außen lösen Alarme aus. Länger dauert alles, was von der Historie abhängt: zu wissen, dass der Finanzserver nie mit einem bestimmten Host spricht, oder dass eine große Übertragung um 2 Uhr für diese Maschine ungewöhnlich, für den Backup-Server aber normal ist. Rechnen Sie damit, dass die ersten Wochen mehr Aufmerksamkeit brauchen, weil Sie normale Aktivität bestätigen und markieren. Ein fertiges Modell, das Ihr Netz am Tag null kennt, gibt es nicht. Die Fehlalarmgrenze, Teil der NetSenX Math Guarantee, wird erst angezeigt, wenn Ihre eigenen markierten Daten sie tragen; bis dahin sagt das Dashboard genau das, statt eine Zahl zu zeigen.
Sie ist ein laufend aktualisiertes Inventar der Geräte, die NetSenX in Ihren überwachten Segmenten sieht, samt der Frage, wer mit wem spricht, und sie ist in jedem Plan enthalten, auch im Free-Plan. Für jedes Gerät zeigt sie den Namen, den es im Netz ankündigt, seine Adresse, erstes und letztes Auftreten und seine Verbindungen zu anderen Geräten und externen Zielen. Cloud- und Hosting-Ziele landen in einer Prüfliste, damit Sie entscheiden können, ob ein Server, der mit einer frisch gemieteten Cloud-Maschine spricht, erwartet ist. Die Karte entsteht passiv aus dem Verkehr: NetSenX scannt oder befragt Geräte nie, was für Drucker, Kameras und Industrieanlagen schonend ist. Die Kehrseite: Ein Gerät, das nie Verkehr sendet oder in einem nicht gespiegelten Segment steht, erscheint nicht. Viele Kunden nutzen die Karte in der ersten Woche, um vergessene Server, unbekannte Geräte und Technik zu finden, die dort nicht hingehört.
In jedem Plan erscheinen Alarme im Dashboard und werden per E-Mail versendet; ab dem Pro-Plan können sie zusätzlich an Slack, einen Webhook oder über die API an Ihre eigenen Systeme gehen, ab dem Business-Plan an Ihr SIEM. E-Mail passt zu einem kleinen Team: Schicken Sie Alarme an ein gemeinsames Postfach oder an zwei Personen, damit jemand sie sieht, wenn der Administrator abwesend ist. Ein Webhook leitet Alarme an ein Ticketsystem, ein Chat-Werkzeug oder einen Bereitschaftsdienst weiter, den Ihr IT-Dienstleister bereits nutzt. Der SIEM-Export stellt Netzwerkerkennungen neben Ihre Log-Daten. Auf jedem Kanal trägt jeder Alarm dieselbe verständliche Erklärung, was geschah, auf welchem Host und warum er ausgelöst wurde. Legen Sie vorab fest, wer nachts und am Wochenende die Alarme liest: NetSenX erkennt zu jeder Stunde, betreibt aber keinen besetzten Dienst, der Sie anruft.
Das hängt vom Plan ab: Der Free-Plan bewahrt 30 Tage Alarmhistorie auf, jeder höhere Plan länger, und Enterprise ohne Zeitlimit; die genaue Dauer je Plan steht in der Preistabelle. Die Alarmhistorie ist wichtiger, als sie scheint. Wird ein Vorfall entdeckt, fragen Ermittler und Versicherer, wann er begann, und die Antwort liegt oft Wochen zurück; ist Ihre Historie kürzer als die Zeit, die der Angreifer im Netz war, sind die Belege verloren. Das Audit-Log, das festhält, wer was geändert hat und was mit jedem Alarm geschah, wird getrennt mit einer eigenen Standarddauer je Plan aufbewahrt. Wählen Sie den Plan mit Blick auf den Ernstfall, nicht nur nach der Geräteanzahl: Ein Unternehmen, das nach NIS2 melden oder Fragen eines Versicherers beantworten muss, braucht womöglich mehr Historie, als seine Größe nahelegt. Kündigen Sie einen bezahlten Plan, läuft das Konto im Free-Plan mit dessen Aufbewahrungsfristen weiter.
Ja. Alarme für DNS-Tunneling sind in jedem Plan enthalten, auch in Free und Starter. DNS-Tunneling versteckt Daten oder Befehle in DNS-Abfragen, meist als lange, zufällig wirkende Namen an eine einzige Domain. NetSenX alarmiert bei diesem Muster. Andere DNS-bezogene Erkennungen werden noch gemessen und lösen noch keine Alarme aus; NetSenX behauptet daher nicht, weitere Arten von DNS-Missbrauch zu erkennen. Unabhängig von NetSenX senken Sie das Risiko, indem Sie den gesamten DNS-Verkehr über eigene Resolver leiten, direktes DNS ins Internet für Arbeitsplatzrechner sperren und Resolver-Logs aufbewahren. Bedenken Sie: Verschlüsseltes DNS, das per HTTPS an einen externen Anbieter geht, ist für keinen Netzwerksensor als DNS sichtbar.
Markieren Sie genau diesen Job als erwartet, statt die Erkennung abzuschalten: den Backup-Server, sein Ziel und sein Zeitfenster, nichts darüber hinaus. Ein nächtliches Backup bewegt viele Daten, oft zu einem externen Speicheranbieter, was für jedes Werkzeug, das Volumen beobachtet, wie Datendiebstahl aussieht. Beim ersten Alarm bestätigen Sie, dass es das Backup ist: Gleichen Sie Host, Ziel und Zeitplan mit Ihrer Backup-Software ab. Markieren Sie den Alarm dann in NetSenX als Fehlalarm, damit ähnliche Alarme dieses Jobs erkannt werden. Lassen Sie die Erkennung für jeden anderen Host aktiv: Dieselbe Übertragung von einem Arbeitsplatzrechner oder vom Backup-Server zu einem neuen Ziel sollte weiterhin einen Alarm auslösen, denn auch Angreifer ziehen nachts Daten ab. Halten Sie die Entscheidung fest und überprüfen Sie sie, wenn sich die Backup-Einrichtung ändert. NetSenX hält jede Entscheidung im Audit-Log fest, sodass Sie später zeigen können, warum ein Alarm geschlossen wurde.
Sie ist die Aussage, dass unter den Alarmen, die das Werkzeug meldet, der Anteil der Fehlalarme unter einem angegebenen Wert bleibt, mit einer angegebenen Sicherheit und gemessen in Ihrem eigenen Netz. Für ein kleines Team beantwortet sie die praktische Frage: Wie viel meiner Zeit für Alarme ist verschwendet? NetSenX leitet eine solche Grenze mit einem Split-Conformal-Verfahren aus harmlosem Verkehr ab, den Ihr Team in Ihrem eigenen Mandanten markiert hat. Der Haken ist ehrlich: Eine Grenze ist nur so gut wie die Daten dahinter. Mit wenigen markierten Alarmen trägt das Verfahren keine enge Grenze, also sagt das Dashboard, dass noch keine Grenze gestützt ist und was fehlt, statt eine beruhigende Zahl zu zeigen. Während Sie in den ersten Wochen und Monaten Alarme markieren, wird die Grenze möglich. Sie ist eine Eigenschaft Ihrer Daten, keine feste Rate, die NetSenX verspricht, und als Teil der NetSenX Math Guarantee in jedem Plan enthalten.
Sie ist eine verifizierbare Falsch-Positiv-Schranke unter den vom System gemeldeten Alarmen, ermittelt per Split-Conformal-Prediction aus gutartigem Verkehr, den Ihre Analysten in Ihrem eigenen Netzwerk gelabelt haben, bei einem von Ihnen gewählten Konfidenzniveau. Das Dashboard zeigt die Schranke erst, wenn Ihre Kalibrierungsdaten sie tragen; bis dahin sagt es das, statt eine Zahl anzuzeigen. Sie beschreibt eine Methode und das, was Ihre Daten aktuell belegen — keine feste Rate. Sie ist in jedem Plan enthalten.
Sie garantiert eine auf Ihre Daten angewandte Methode und vollständige Transparenz darüber, was diese Methode derzeit belegt. Eine Split-Conformal-Schicht leitet aus von Analysten als gutartig gekennzeichnetem Traffic in Ihrem eigenen Tenant eine Falsch-Positiv-Grenze für die vom System gemeldeten Alarme her, auf einem konfigurierbaren Konfidenzniveau. Eine endliche Kalibrierungsmenge kann eine Grenze nur bis zu einer gewissen Schärfe auflösen; daher zeigt das Dashboard die Grenze, die Ihre Daten stützen — und weist explizit aus, wenn noch keine gestützt wird, zusammen mit dem, was zum Schließen der Lücke fehlt, statt eine Zahl anzuzeigen, die wir nicht belegen können. Die Methodik ist in unserem Trust Center dokumentiert und unabhängig überprüfbar.
Nein. NetSenX erkennt und alarmiert zu jeder Stunde, ist aber Software: Niemand bei NetSenX beobachtet Ihre Alarme rund um die Uhr oder reagiert für Sie. Der Unterschied zählt, wenn Sie Ihre Sicherheit einem Versicherer, einem Prüfer oder einem Kunden beschreiben. Zu sagen, dass die Erkennung rund um die Uhr läuft, ist wahr; zu sagen, dass jemand rund um die Uhr reagiert, ist nur wahr, wenn Sie es organisieren. Möglichkeiten, die für kleine und mittlere Unternehmen funktionieren: Alarme per E-Mail an zwei Personen statt an eine senden; ab dem Pro-Plan per Webhook einen Bereitschaftsdienst Ihres IT-Dienstleisters erreichen; mit einem MSP oder MSSP vereinbaren, dass er Alarme außerhalb der Bürozeiten entgegennimmt und handelt; und die Nummer einer Incident-Response-Firma bereithalten. Brauchen Sie Menschen, die rund um die Uhr wachen, bietet das ein Anbieter für Managed Detection and Response (MDR), und NetSenX-Alarme lassen sich an ihn weitergeben.
Es blockiert keinen Verkehr, entschlüsselt keine Sitzungen, schützt keine Endpunkte, filtert keine E-Mails, verwaltet keine Identitäten, sichert keine Daten und betreibt keinen besetzten Sicherheitsdienst. NetSenX beobachtet Netzwerkverhalten und erklärt Alarme. Den Inhalt verschlüsselter Sitzungen liest es nie, es kann Ihnen also nicht sagen, was in einer hochgeladenen Datei stand oder was jemand in ein KI-Werkzeug getippt hat. Es sieht nicht, was in einem Rechner geschieht, ohne das Netz zu berühren, keine Geräte, die schweigen, und keine Segmente, die Sie nicht spiegeln. Anmeldungen in Ihrem VPN, Verzeichnisdienst oder Ihren Cloud-Diensten sieht es nicht, sodass ein gestohlenes, gültiges Passwort bei normaler Nutzung wie normale Arbeit aussehen kann. Es entscheidet nicht, ob ein Vorfall meldepflichtig ist, und reicht keine Meldungen bei Behörden ein. Für diese Lücken brauchen Sie Endpunktschutz oder EDR, E-Mail-Sicherheit, Mehrfaktor-Authentifizierung und Identitätslogs, getestete Backups und Menschen, die reagieren. NetSenX arbeitet neben ihnen.
Enterprise-Kunden erhalten Nachweise, die SOC 2 Type I (in progress), ISO 42001 (KI-Management) und ISO 27001 zugeordnet sind. Jede Kontrolle umfasst zeitgestempelte Artefakte, Bestätigungen der Subunternehmer und eine exportierbare Auditor-Ansicht, die in Echtzeit aktualisiert wird.
Ja. Das Onboarding für Business und Enterprise umfasst eine strukturierte Umstellung: zwei Wochen Parallelbetrieb, Zuordnung der Alarm-Taxonomie und Migration der Analysten-Playbooks.