[ Walkthrough ]
Durchsuchbare Observability für OT und IT: Netzwerkgeräte, Linux-Server und Container an einem Ort. Die Logging-Pflicht erfüllt, ohne SIEM-Projekt.
Wenn ein Incident eintritt, steckt die Antwort in den Ereignissen: der Link, der geflappt hat, die Konfiguration, die sich geändert hat, der fehlgeschlagene Login. Das Schwierige ist, sie zu behalten: lange genug, an einem Ort, bereit zum Durchsuchen.
Compliance sicherstellen und Security-, Netzwerk- und OT-Probleme schneller analysieren.
Rekonstruieren Sie, was um 02:00 geschah: die genaue Abfolge der Ereignisse, in Sekunden, statt sich auf zehn Geräte einzuloggen.
Aufbewahrte, durchsuchbare Logs und ein Audit-Trail: die Logging-Pflicht erfüllt, ohne ein grosses Design- und Infrastrukturprojekt.
Link-Flaps, STP-Topologieänderungen, Controller-Fehler und Interface-Fehler, sichtbar, sobald sie passieren.
Logins, Sitzungsaktivität und Änderungsereignisse: wer auf welchem Gerät agiert hat, und wann. Mit narrowin Explorer sehen Sie zudem die Konfigurationsänderungen selbst: was sich geändert hat, wann und durch wen.
Filtern Sie das ganze Netzwerk nach Host, App, Severity oder Hersteller und finden Sie das Ursprungsereignis, bevor der Anruf eskaliert.
Fehlgeschlagene Logins, unerwartete Quellen und Anomalien: die Ereignisse, die ein Security-Review braucht, bereits gesammelt.
Die Ereignisse hereinholen, die Antwort finden, dann im Blick behalten, worauf es ankommt.
Log Analytics läuft im selben narrowin-Controller wie der Explorer und die Diode: das Netzwerk, das Sie sehen, segmentieren und jetzt durchsuchen können.
Richten Sie Ihre Geräte, Server und Container darauf, und die Ereignisse treffen ein. Schnell und einfach.
Switches, Firewalls und Controller per Syslog. Debian- und andere Linux-Hosts über rsyslog oder journald. Docker-Container über den syslog-Log-Driver oder einen Log-Collector.
Meldungen werden automatisch erfasst, geparst und normalisiert. Kein Schema zu definieren, egal welche Quelle.
Die Query-Sprache oder eine einfache Suche, das Severity-Histogramm und Facetten: die Antwort in Sekunden.
Heften Sie Watch-Queries ans Dashboard, legen Sie die nötige Aufbewahrung fest, exportieren Sie fürs Audit.
| Erfassung | Syslog über UDP / TCP (RFC 3164 & RFC 5424): ein Endpoint für alle Quellen |
|---|---|
| Quellen | Switches, Router, Firewalls, Controller · Linux-/Debian-Hosts über rsyslog oder journald · Docker-Container über den syslog-Log-Driver · Anwendungs- und Datei-Logs über einen gängigen Log-Collector |
| Query | Eine feldsensitive Query-Sprache, mit einem Volltext-Suchmodus |
| Severity-Modell | Vollständige achtstufige Syslog-Skala: emerg bis debug |
| Zeitfenster | 15 Minuten bis 30 Tage, plus eigene Bereiche |
| Ansichten | Dashboard, Explore, Drill-down pro Gerät |
| Speicher | Hochkomprimierter Log-Speicher: Aufbewahrung, die Sie festlegen, kein Sampling |
| Export | CSV; gespeicherte Queries; angeheftete Watch-Queries |
| Bereitstellung | Teil des narrowin-Controllers, Cloud oder On-Premises |
| Authentifizierung | Lokale Benutzer, SAML SSO (Keycloak, Entra ID, Okta, ADFS) sowie LDAP / Active Directory |
| Daten | Ihre Ereignisse bleiben auf Ihrer Infrastruktur |
| Dokumentation | /docs/loganalytics (Login) → |
Ein SIEM ist eine Plattform und ein Programm: Korrelationsregeln, Tuning, ein Team zum Betreiben. Log Analytics ist richtig dimensioniert: Ereignisse erfassen, aufbewahren und durchsuchen, damit ein mittelgrosser OT-Betreiber seine Pflicht ohne das Projekt erfüllt.
Ja. Alles, was Syslog senden kann, landet im selben Speicher und im selben Schema. Netzwerkgeräte senden direkt. Debian- und andere Linux-Hosts leiten ihre System-Logs über rsyslog oder systemd-journal-upload weiter. Docker-Container nutzen den syslog-Log-Driver, oder Sie stellen einen schlanken Log-Collector davor, wenn Sie Container- und Datei-Logs vorher parsen, anreichern oder filtern wollen. Ein Endpoint, ein Suchfeld über OT, IT und Container.
Auf Netzwerkgeräten nicht: die sprechen bereits Syslog, Sie richten sie auf den narrowin-Controller und die Ereignisse treffen ein. Auf Servern nutzen Sie, was ohnehin installiert ist, rsyslog oder journald. Nur wenn Sie Container- oder Applikations-Logs vorher aufbereiten wollen, kommt ein schlanker Log-Collector dazu. Gängige Open-Source-Collectors funktionieren; welcher davon, entscheiden Sie.
Eine schnelle, feldsensitive Query-Sprache mit Autovervollständigung, flott selbst über Millionen Ereignisse. Ein Volltext-Suchmodus deckt den schnellen Blick ab, wenn Sie keine Präzision brauchen.
So lange Sie wollen. Ein hochkomprimierter Speicher bewahrt Ereignisse über Monate auf, bei bescheidenem Speicherbedarf; die Aufbewahrung ist eine Einstellung, abgestimmt auf Ihre Pflicht.
Ja. NIS2 und die KRITIS-Vorgaben erwarten aufbewahrte, prüfbare Logs. Log Analytics liefert die Aufbewahrung, die Suche und den Export, die ein Audit verlangt.
Auf Ihrer Infrastruktur. Log Analytics läuft als Teil des narrowin-Controllers, Cloud oder On-Premises. Ihre Ereignisse verlassen ihn nicht.
Eine zentrale Monitoring- und Logging-Infrastruktur ist ein wesentlicher Baustein für unsere Security- und Auditing-Richtlinien.
NIS2 und die KRITIS-Vorgaben erwarten von Betreibern kritischer Infrastruktur, dass sie ihre Logs aufbewahren und prüfen. Log Analytics ist diese Pflicht, mit Augenmass erfüllt, ohne die Kosten und Personalstärke eines vollwertigen SIEM.
OT- und IT-Ereignisse an einem durchsuchbaren Ort zusammenführen, für Security und fürs Audit.
Lesen →
Eine Layer-2-Schleife diagnostizieren, indem man den Fehler durch die Ereignisse zurückverfolgt: den Flap, die Ursache, die Wiederherstellung.
Lesen →
Wie schlanke Tools auf den Schweizer IKT-Minimalstandard abbilden, inklusive Logging und Prüfung.
Lesen →
Bereits vorhandene Hardware in Intrusion Detection verwandeln, ganz ohne zusätzliche Sensoren.
Lesen →Fangen Sie jetzt an, sie zu behalten: durchsuchbar, aufbewahrt und bereit, sobald Sie sie brauchen.
Sprechen wir über Ihr Logging