--- title: secnostic sensor canonical: https://www.secnostic.com/de/products/sensor language: de dateModified: 2026-08-12 alternate-en: https://www.secnostic.com/en/products/sensor --- # secnostic sensor - URL: https://www.secnostic.com/de/products/sensor - Positioning: Erfassung und Realitätsabgleich secnostic sensor untersucht Ihre Endpunkte und Netzwerke direkt, findet Assets und ihre Verbindungen und meldet, was tatsächlich vorhanden ist. Statt sich auf Listen zu verlassen, prüft secnostic sensor die reale IT- und OT-Umgebung und schließt die Lücken, die niemand mehr von Hand pflegt. **Was wirklich läuft, nicht was auf dem Zettel steht** Tabellen veralten, sobald jemand etwas anschließt oder umbaut. secnostic sensor sieht selbst nach: auf Windows und Linux, im Active Directory, im Netzwerk und schonend lesend in der OT, dazu in Microsoft 365, Intune und Sophos Central. Jeder Fund kommt mit Quelle und Sicherheitsgrad und wird direkt oder über einen Fleet Manager an das secnostic Inventar übergeben. So sehen Sie, was wirklich da ist, was sich seit dem letzten Lauf verändert hat und wo noch ein blinder Fleck bleibt. **Capabilities** - Endpunkte, Netzwerke, Dienste und technische Zustände beobachten - Kommunikationsbeziehungen und unbekannte Systeme sichtbar machen - Inventardaten gegen reale Umgebungen prüfen und Datenqualitätslücken erkennen - Passive oder kontrollierte Erfassung an sensible OT-Umgebungen anpassen **Outcomes** - Aktuelle Asset-Daten, ohne Tabellen von Hand zu pflegen - Klare Sicht darauf, was in IT und OT tatsächlich miteinander kommuniziert - Eine Datenbasis, der Inventar, Security und Audit vertrauen können **Modules of secnostic sensor** - **Dashboard** - Überblick: Zustand des Sensors auf einen Blick, mit Anzahl der Assets, Verbindungen und Funde sowie dem Upload-Status. - **Hosts** - Bestand: Jedes entdeckte Asset mit IP, Hersteller und erkannten Protokollen, aktiv oder passiv gesehen. - **Netzwerkgraph** - Modell (core module): Das Herzstück: wer mit wem spricht, als verbundenes Modell aus Knoten, Kanten und Verkehr mit Identitätshinweisen pro Asset, statt einer flachen Liste. - **Verbindungen** - Wege: Jeder Kommunikationspfad mit Endpunkten, Protokoll, Volumen und Dienst. - **Funde** - Befunde: Erkannte Geräte und Sicherheitsfakten wie eine Siemens-S7-Identität, mit Kategorie und gemeldeter Version. - **Collectors** - Quellen: Spezialisierte Collectors, gruppiert danach, wie schonend sie lesen: passives Netzwerk, lokale Endpunkte, ein begrenzter Active-Directory-Lesezugriff, OT per Opt-in und Cloud. - **Safe by default** - Sicherheit: Read-only, opt-in und für OT nur planend, mit einem Fail-closed-Scheduler und einer Erlaubt-Liste pro Protokoll. **Von vielen Belegen zu einem verlässlichen Inventar** Spezialisierte Collectors sammeln Belege aus IT, OT, Identität und Cloud, gruppiert danach, wie schonend sie gelesen werden. Der Sensor normalisiert jeden Fund mit Quelle und Konfidenz zu einem Strom und übergibt ihn direkt oder in skalierten Umgebungen über einen Fleet Manager an das secnostic Inventar. - Passiv: Netzwerk, Flow-Daten - Lesend: Endpunkte, Active Directory, Aktiv & OT - Cloud: Microsoft 365, Sophos Central **Protokolle, Praxis und sicherer Rahmen** Welche Protokolle der Sensor liest, wie das in der Praxis aussieht und in welchem ausdrücklich freigegebenen Rahmen die aktive Erkennung läuft. - OT & Industrie: Modbus, Siemens S7, PROFINET, EtherNet/IP, OPC UA, BACnet, DNP3, EtherCAT - Netzwerk: TLS, HTTP, DNS, SMB, RDP, SSH, NetFlow, IPFIX - Identität & Cloud: Active Directory, Microsoft 365, Intune, Sophos Central, SNMP _Scope & Sicherheit._ Aktive und OT-Erkennung sind kein freier Scan. Ein ausdrücklicher Fail-closed-Scope und eine Regel je Sonde bestimmen, was überhaupt sondiert wird, schonend und nur lesend. - **Ziel-Scope**: Erlaubt- und Sperrlisten für Hosts, Netze und Bereiche. Ohne Eintrag wird nichts sondiert. - **Zielplanung**: Kandidaten kommen aus erlaubten Bereichen und optional aus passiver Sicht, immer nur innerhalb des Scopes. - **Plan-Only**: Auf Wunsch berechnet die Sonde nur den Plan und sendet kein einziges Paket. Ein echter Trockenlauf. - **Freigabe & Tempo**: Jede Sondenfamilie ist einzeln schaltbar. Nebenläufigkeit, Timeouts und Pausen begrenzen die Last. - **Nur lesend**: Freigegebene Sonden lesen ausschließlich und liefern Identitäts- und Posture-Fakten mit Beleg. In der Praxis: - **Sehen, was im Netz spricht**: Ein Betriebsteam will wissen, welche Geräte im Netz aktiv sind und miteinander reden, ohne den Betrieb anzufassen. (Mithören -> Geräte erkennen -> Beziehungen sehen -> Ohne Eingriff) - **Software und Geräte erfassen**: Ein IT-Team braucht eine aktuelle Liste aller Systeme und der installierten Software, ohne auf jedem Rechner etwas zu installieren. (Quellen lesen -> Software & Versionen -> Lücken sichtbar -> Ins Inventar) - **Daten zusammenführen**: Dasselbe Gerät wird oft mehrfach gesehen. Der Sensor führt diese Belege zu einem verlässlichen Eintrag zusammen. (Viele Quellen -> Sicher zuordnen -> Zusammenführen -> Mit Herkunft) **Einblicke in den Sensor** Dashboard, Hosts, Graph, Verbindungen und Findings sind nach Aufgabe getrennt und teilen denselben Beobachtungsstrom. - Dashboard: Assets, Verbindungen, Findings und Upload-Warteschlange auf einen Blick, dazu Identität, Version und Health des Sensors. - Hosts: jedes erkannte Asset mit IP, Hersteller, Protokollen und Quelle, aktiv oder passiv beobachtet. - Netzwerk-Graph: wer mit wem spricht, mit Knoten, Kanten, Verkehr und Identitätshinweisen je Asset. - Verbindungen: jeder Kommunikationsweg mit Endpunkten, Protokoll, Volumen und Dienst, als Beleg statt Vermutung. - Findings: erkannte Geräte und Fakten, etwa eine Siemens-S7-Identität, mit Kategorie und gemeldeter Version. **FAQ** - Q: Schreibt der Sensor auf die erkannten Geräte? A: Nein. Der Sensor ist eine reine Erfassungssonde. Passive Netzsicht sendet kein Paket, und jede aktive oder OT-Sonde liest ausschließlich, ist opt-in und läuft nur gegen eine ausdrückliche Erlaubt-Liste. Sogar passiv beobachtete Schreibzugriffe anderer Systeme meldet er als Sicherheitsfakt. - Q: Ist der Einsatz in OT-Umgebungen sicher? A: Schonendes Sondieren ist Aufgabe des Sensors. Die Produktionsvorgabe ist Plan-Only, der Zielplaner ist fail-closed, die Nebenläufigkeit lässt sich auf einen Host begrenzen und jede Protokollfamilie wird einzeln freigegeben. Das mitgelieferte Laborprofil muss vor dem ersten Einsatz in einem echten Netz durch die sichere Vorgabe ersetzt werden. - Q: Wohin gehen die Daten, wenn das Inventar nicht erreichbar ist? A: Jeder Lauf wird zuerst lokal gepuffert. Ein einzelner Sensor kann bewusst direkt über HTTPS an die Inventory-API senden; in verteilten oder segmentierten Umgebungen bündelt der optionale Fleet Manager die Änderungen und synchronisiert sie sensorinitiiert über mTLS. Ist inventory nicht erreichbar, bleiben die Daten lokal und die Übertragung wird mit wachsendem Abstand wiederholt. Nichts verlässt den Host, bevor die Synchronisierung eingerichtet ist. - Q: Wie sensibel sind die Daten und wie sind sie geschützt? A: Beobachtungen können Hosts, Benutzer, Dienste, Zertifikate und Kommunikationswege zeigen, daher gelten sie als sensibel. Die Normalisierung ist datensparsam: Benutzernamen, Prinzipale und Geheimnisse werden gehasht statt gespeichert, rohe DNS- und OT-Inhalte verworfen und Roh-Belege sind standardmäßig deaktiviert. Die lokale Diagnose ist nur lesend und nur über Loopback erreichbar. **Getting started.** Wir klären gemeinsam, welche Quellen risikoarm genutzt werden können und welche Beobachtungen für Inventar, Betrieb und Security zuerst zählen.