Nicht jeder Administrator möchte seine sensiblen IT-Systeme einem Cloudanbieter anvertrauen. Die erste positive Nachricht lautet daher, dass Enginsight-Kunden die Wahl haben, ob sie ihre Systeme mit Enginsight über ein Cloud-Frontend managen oder lieber eine lokale Appliance für die Verwaltung einsetzen.

Für die Softwarekomponenten Watchdog, Hacktor und Observer, auf die wir noch im Detail eingehen, setzt Enginsight dabei auf standardisierte Docker-Container, vorzugsweise unter Linux, aber auch Windows Server ab 2016 mit "Nested Virtualization" kommen infrage. Die Installation kann sowohl auf physischer als auch virtueller Hardware erfolgen. Enginsight liefert auf Wunsch auch vorkonfigurierte Hardware-Appliances aus.

Für den On-Premises-Betrieb von Enginsight sind mindestens drei Instanzen beziehungsweise Appliances notwendig:

- Applikationsserver: Dient zum Betrieb der zentralen API, des User-Interface sowie weiterer Services der Enginsight-Plattform.

- Datenbankserver: Speichert sämtliche Monitoringdaten und kommuniziert ausschließlich mit dem Applikationsserver.

- Observer, Hacktor und Watchdog: Je nach Anforderung und Größe des Netzwerks ist es sinnvoll, für diese Softwarekomponenten jeweils eigene Instanzen zu nutzen. Nach Angaben des Herstellers können diese drei Instanzen für kleinere Netzwerke mit bis etwa 500 zu überwachenden IT-Assets auch gemeinschaftlich auf einem System beziehungsweise einer VM laufen.

Im Cloudbetrieb kommt Enginsight – abgesehen von den Netzwerksensoren – dagegen ohne lokal installierte Hardware oder VM aus, da das gesamte Management-Framework über ein Webinterface in der Cloud abgebildet wird.

Ein SaaS-Test-Account in der Cloud ist in Enginsight schnell aufgesetzt und der Hersteller unterstützt die Einarbeitung neuer Admins unter anderem mit einer Reihe von Tipps, die er in kurzer Folge nach der Anmeldung per E-Mail an neue Kunden verschickt. In der Hilfe steht darüber hinaus auch ein übersichtlicher Start-Guide zur Verfügung.

Doch trotz dieser eigentlich sehr guten Dokumentation fiel es uns im Test zunächst schwer, uns einen Überblick über das Gesamtsystem und über das Zusammenwirken der einzelnen Module zu verschaffen. Das liegt zum einen an der Enginsight-eigenen Terminologie, die Funktionen der Web-GUI mit jenen der Sensoren vermischt. Zum anderen gibt es auch kein Dokument, das den Aufbau und Funktionen des Gesamtsystems übersichtlich beschreibt. Wahl und Anordnung der im Webinterface genutzten Icons sind ebenfalls nicht unbedingt selbsterklärend.

Bevor wir in den Test einsteigen, geben wir aufgrund dieser Komplexität einen kurzen Überblick über die Gesamtfunktion des Enginsight-Ökosystems und stellen die Module kurz vor. Die Grundfunktionen von Enginsight sind:

- Monitoring interner IT-Systeme beziehungsweise Clients und Server.

- Inventarisierung von Netzwerken, Netzwerkgeräten und Software auf Hosts.

- Konfigurations-Checklisten zur sicheren Systemkonfiguration.

- Update- und Patchmanagement inklusive Prüfung auf fehlende Updates.

- Auslesen von System-Events (Logfiles, Netzwerkmitschnitte).

- Automatisierung durch Plug-ins

- Überwachung von Endpunkten wie Webseiten, Domains, URLs, Hostnamen und IP-Adressen, die aus dem Internet erreichbar sind.

- Durchführung von Sicherheitsprüfungen (Penetrationstests).

- Manipulation des Netzwerkverkehrs auf Servern und Clients.

Wie bereits angesprochen, bietet Enginsight seine Plattform in der Cloud und optional auch lokal an. Neben Datenschutzaspekten gilt es bei der Auswahl der Betriebsform aber auch technische Aspekte zu berücksichtigen.

So übertragen die lokal installierten Netzwerksensoren (Watchdog, Hacktor, Observer) sowie die Pulsar-Agenten im SaaS-Betrieb notwendigerweise sämtliche Informationen auf die Enginsight-Plattform im deutschen Rechenzentrum von AWS. Hingegen beschränkt sich diese Kommunikation on-premises vollständig auf das eigene Netzwerk. Neben der eigentlichen Plattform betreibt Enginsight in AWS auch einen eigenen Observer-Dienst. Mit diesem können IT-Verantwortliche sowohl externe Quellen (beispielsweise Webserver beim Hoster) als auch beim Kunden in der DMZ oder lokal installierte Endpunkte überwachen. In letzterem Fall müssen Admins auf ihrer Firewall aber eingehende Verbindungen vom Enginsight Observer auf die entsprechenden Zielsysteme im eigenen Netzwerk gestatten, was wiederum den Einsatz einer Web-Application-Firewall beziehungsweise eines Reverse-Proxy erforderlich macht. Alternativ bietet sich daher ein lokal installierter Observer an.

Über das Enginsight-Webinterface haben Admins zunächst einmal Zugriff auf das Dashboard. Dieses listet neben dem Zustand der Systeme auch sämtliche Aktivitäten auf ("Admin Log"). Außerdem finden sich hier auch Konfigurationsrichtlinien und -listen, die die jeweiligen Vorgaben für verschiedene Betriebssysteme genauer beschreiben. Das Modul "Issues" zeigt durch Alarme ausgelöste Vorfälle und erlaubt weiterhin, Wartungszeiträume zu definieren, um Fehlalarme zu vermeiden. Unter "Hosts" versteht Enginsight Client- und Serversysteme, auf denen ein Pulsar-Agent installiert ist. Dieser sammelt und liefert sowohl Informationen zum Systemzustand, integriert aber auch weitere Zusatzfunktionen wie das Intrusion-Detection-System, Software-Inventarisierung und CVE-Scans.

Das Endpunkte-Modul zeigt Webseiten, IP-Adressen oder Domains. Das Gegenstück zu Endpunkten stellt der Observer dar, der Endpunkte auf Verfügbarkeit (bei Websites auch deren Reaktionszeit und Performance), bestimmte DNS-Einträge oder SSL/TLS-Informationen überwacht. Zusätzlich kann der Observer auch installierte Applikationen wie zum Beispiel WordPress und andere CMS-Systeme erkennen und diese auf Sicherheitslücken, gesetzte HTTP-HEADER und Redirects untersuchen. Ergänzend monitort der Observer mithilfe des integrierten Portscanners auf Endpunkten auch die Verfügbarkeit bestimmter Ports oder meldet neu geöffnete Ports an den Admin. Darüber hinaus stehen noch diese Module bereit:

- Observations: Mithilfe eines lokal installierten "Watchdogs" lassen sich Geräte ohne Installation des Pulsar-Agenten per Ping- und Port-Check (alternativ via SNMP) überwachen.

- Shield: Erlaubt, manuelle und dynamische Regelwerke zu definieren, um Netzwerkverbindungen zu blockieren.

- Penetrationstests: Über ein lokal installiertes Hacktor-Modul lassen sich automatisierte und zeitgesteuerte Penetrationstests ausführen.

- Discoveries: Der lokal installierte Netzwerksensor "Watchdog" scannt das gesamte Netzwerk nach neuen Assets und übernimmt diese in das Inventar.

- Alarme: Für Hosts, Endpunkte und per Observer überwachte Bereiche lassen sich Alarme definieren und individuelle Benachrichtigungen festlegen.

Neben den Modulen im Web-GUI stellt Enginsight den Pulsar-Agenten bereit, der System-, Sicherheits- und Konfigurationsinformationen von Clients und Servern sammelt und auswertet. Weiterhin stehen mit Observer, Watchdog und Hacktor drei Netzwerksensoren zur Verfügung, mit denen sich Informationen im Netzwerk einsammeln und ins Webportal übertragen lassen.

Für den Test nutzten wir die SaaS-Plattform des Herstellers. Aus Sicherheitsgründen haben wir unseren Login sofort mit der Zweifaktor-Authentifizierung (2FA) abgesichert. Die Anmeldung fragt dann zusätzlich ein OTP-Code ab, den wir wahlweise per Google-Authenticator-App, SMS oder E-Mail anfordern konnten. Da die Enginsight-Plattform mehrere Benutzer und Rollen unterstützt, ist es natürlich sinnvoll, 2FA auch gleich für sämtliche Teammitglieder zu erzwingen, wenn sich mehrere Admins die Aufgaben teilen.

Nach dem ersten Login startet im Web-Interface ein Wizard, der beim Hinzufügen erster Endpoints und Hosts behilflich ist. Der besseren Übersicht im Test wegen nahmen wir jedoch sämtliche Einstellungen ohne den Wizard vor. In unserem Testnetz befanden sich neben dem LAN noch weitere geroutete Netzwerke, typische Netzwerkgeräte wie Switches und Router sowie diverse Linux- und Windows-Client- und -Serversysteme.

Als zu überwachenden Endpoint entschieden wir uns für einen Linux-Webserver, der auf Basis eines vServers bei einem externen Hoster läuft. Hier setzten wir deshalb den von Enginsight auf der SaaS-Plattform bereitgestellten Observer ein. Für das Monitoring der internen Systeme installierten wir auf den Clients und Servern jeweils den Pulsar-Agenten, die Netzwerksensoren Observer, Watchdog und Hacktor luden wir dagegen auf mehrere Raspberry Pis und positionierten sie jeweils zu einer IP-Adresse im LAN-Segment.

Der Weg zu einem funktionsfähigen Enginsight-System lässt sich in die folgenden vier Schritte unterteilen, die wir im Test in dieser Reihenfolge umsetzten:

- Hosts und Pulsar-Agenten anlegen

- Endpoints erstellen und per Enginsight-Observer überwachen

- Lokale Netzwerksensoren ausrollen und für die Überwachung der jeweiligen Systeme konfigurieren

- Feintuning wie etwa Alarme und IDS-Konfiguration

Der Pulsar-Agent ist die Clientkomponente zur Überwachung individueller Rechner (Clients wie auch Server). Wir legten zunächst in der Web-GUI zwei Client-Hosts und einen Server-Host an und installierten den Agenten auf einem Windows-10- und einem Linux-Client sowie auf einem Server mit Windows 2019. Die Installation erfolgte skriptbasiert per PowerShell- beziehungsweise Bash-Skript. Diese übernahmen wir einfach aus dem Anleitungsfenster in die Zwischenablage und führten sie auf dem jeweiligen System im Interaktiv-Modus aus.

Kurze Zeit später meldeten sich die Systeme dann in der GUI unter "Hosts" und zeigten Statusinformationen zur CPU-, RAM-, SWAP- und Festplattenauslastung sowie Hinweise auf identifizierte Sicherheitslücken, fehlende Updates und nicht gestartete (aber empfohlene) Dienste an. In den Einstellungen der Hosts hinterlegten wir danach zunächst die Hinweise auf den technischen und den fachlich Verantwortlichen und aktivierten den "Netzwerkmitschnitt". Diese Funktion startet das Enginsight-Intrusion-Detection-System auf dem jeweiligen Host und erkennt verschiedene Arten netzwerkbasierter Angriffe. Diese Informationen aus dem Netzwerkmitschnitt dienen außerdem dazu, das Modul "Shield" zu konfigurieren – dazu später mehr.

Neben dem Software-Inventar, der Identifikation vorhandener Sicherheitslücken und dem Update-Manager fanden wir vor allem die Konfigurations-Checklisten sehr hilfreich. Diese basieren auf den STIGs (The Security Technical Implementation Guides), den von der Defense Information Systems Agency (DISA) für die Systeme des US-Verteidigungsministeriums erstellten Konfigurationsstandards. STIGs enthalten unter anderem Anleitungen für das Sperren von Diensten, Funktionen und Software auf Betriebssystemen, die Angreifer oder Malware häufig nutzen. Enginsight stellt Konfigurations-Checklisten für Windows und die gängisten Linux-Distributionen zur Verfügung.

Als Endpunkte lassen sich in Enginsight grundsätzlich Webseiten, IP-Adressen oder Domains anlegen. Wir entschieden uns für eine Website, um deren Verfügbarkeit und das installierte CMS (WordPress) auf Sicherheitslücken zu überwachen. Da die Website auf einem von uns betriebenen Linux-vServer läuft, aktivierten wir auch gleich die Funktion "Portscan". Damit lassen sich geöffnete Ports auf Verfügbarkeit und – sofern Enginsight den Dienst und die Versionsnummer zweifelsfrei (etwa über einen Banner-Output) identifizieren kann – auch auf Sicherheitslücken überwachen. Zum Anlegen der Website fügten wir in der Web-GUI zunächst einen neuen Endpunkt unter Verwendung der URL hinzu und aktivierten die Funktionen "Web-Site", "Applications" und "Portscan". Nach dem ersten Analyselauf des Observers tauchte die Website dann mit Verfügbarkeits- und Statusinformationen auf und wies uns unter anderem gleich auf Sicherheitslücken in der verwendeten Wordpress-Version und im SSH-Server hin.

Die Enginsight-Netzwerksensoren haben die Aufgabe, die im Netzwerk vorhandenen Geräte zu inventarisieren (Watchdog), die Verfügbarkeit und Auslastung von Systemen zu überwachen (Observer) und Penetrationstests auf Systeme auszuführen (Hacktor). Die Installation der Sensoren kann dabei auf physischer oder virtueller Hardware erfolgen.

Im Test installierten wir Watchdog auf einem Raspberry Pi. Dieser erkannte nach mehrfachem Scan zuverlässig alle unsere Geräte im Netzwerk und listete sie in der Web-GUI unter "Discoveries" auf. Die Geräte werden in der Inventarliste mit ihrer IP- und MAC-Adresse dargestellt. Sofern von Enginsight erkannt, wird anhand der MAC-Adresse auch ein Hinweis auf den Gerätehersteller ausgegeben, um die Identifikation zu erleichtern. Denn damit der Admin mit der Inventarliste später sinnvoll arbeiten kann, steht zunächst die händische Vergabe von Alias-Namen für die identifizierten Assets an. Neben dem Alias-Namen konnten wir in der Inventar-Ansicht auch eine Beschreibung sowie eigene Tags hinterlegen. In den Feldern "Verantwortlichkeiten" und "Standort" wählten wir die entsprechenden Angaben für technisch beziehungsweise fachlich verantwortliche Personen sowie zum Gerätestandort aus und aktivierten den Schalter "Begutachtet". Derart gekennzeichnete Assets markiert das Enginsight-Inventar mit einem grünen Symbol, um zu dokumentieren, dass das Gerät vom Admin überprüft wurde.

Enginsight integriert darüber hinaus auch SNMP-fähige Geräte. Voraussetzung dafür ist die Angabe der korrekten MIB (Management Information Base), für die Enginsight bereits eine große Anzahl mitliefert. Alternativ kann der Admin aber auch eigene beziehungsweise Hersteller- oder gerätespezifische MIBs hochladen und nutzen. Die Watchdog-Einstellungen lassen sich selbstverständlich auch nach dessen Installation noch ändern. Für jedes gefundene Asset in der Inventarliste waren wir in der Lage, einen Ping- oder Port-Check direkt aus der Liste heraus zu aktivieren. Enginsight beginnt dann sofort mit der Überwachung der so hinzugefügten Systeme und führt den Systemzustand fortan unter "Health-Checks" auf.

Der Observer steht für den "Blick von außen" und untersucht, welche Informationen sich alleine durch die Beobachtung der Endpunkte von außen gewinnen lassen, ohne internen Zugang zu den Systemen zu haben. Der Betrieb des Observer-Sensors ist zwar auch im eigenen Netzwerk möglich, die Nutzung im SaaS-Betrieb ist aber besonders für extern betriebene Systeme deutlich komfortabler. Für den SaaS-basierten Observer darf die Kommunikation zu den Enginsight-IP-Adressen allerdings nicht durch Firewall-Regeln eingeschränkt werden. Enginsight stellt in der Hilfe eine Liste der IP-Adressen (AWS-Regionen "eu-central-frankfurt" und "us-east-virginia") zur Verfügung, alternativ konnten wir aber auch einfach die Kommunikation zu sämtlichen A-Records der Domain "observers. enginsight.com" erlauben.

Ein interner Observer ist aber ebenfalls schnell aufgesetzt: Dabei ist zu beachten, dass die Installation derzeit nur für Linux-Systeme zur Verfügung steht. Das erforderliche Bash-Skript findet sich etwas versteckt unter "Endpunkte / Observers / Observer hinzufügen". Nachdem wir dieses ebenfalls auf einem Raspberry Pi mit Raspbian-Betriebssystem ausgeführt haben, tauchte der zusätzliche Observer nach kurzer Zeit in der Web-GUI auf.

Mithilfe eines lokal installierten Hacktor kann Enginsight beliebige Systeme innerhalb und außerhalb des eigenen Netzwerks einem Penetrationstest unterziehen. Wie schon beim Observer, steht auch Hacktor derzeit ausschließlich für die Installation auf Linux-Systemen zur Verfügung. Die Installation per Bash-Skript auf einem weiteren Raspberry Pi verlief problemlos, sodass Hacktor bereits nach kurzer Zeit einsatzbereit war.

In den Hacktor-Einstellungen lassen sich optional die genutzten Port-Ranges einstellen, für unseren Test übernahmen wir die sinnvollen Voreinstellungen des Herstellers. Danach legten wir unter "Penetrationstests / Zielsysteme" die Systeme an, die wir per Pentest untersuchen wollten. Erforderliche Angaben sind hier die IP-Adresse des Zielsystems sowie die Auswahl des entsprechenden Hacktors auf dem Karteireiter "Watchdogs". Im nächsten Schritt legten wir unter "Vorlagen" zwei Vorlagen (eine für die internen, eine für die externen Zielsysteme) an, verbanden auch diese mit dem lokal installierten Hacktor und wählten die zugehörigen Zielsysteme aus der Liste aus. Nachdem wir den Scan über die Schaltfläche "Pentest starten" initiiert hatten, konnten wir Verlauf und Fortschritt des Scans im Web-GUI unter "Audits" mitverfolgen.

Nachdem die Systemagenten und Netzwerksensoren ausgerollt und in Betrieb genommen waren, legten wir in der Web-GUI entsprechende Alarme an, um uns im Fehlerfall informieren zu lassen. Alarme stehen für Hosts, Endpunkte und Inventar-Assets zur Verfügung, sofern der Admin für diese zuvor einen Ping- oder Port-Check konfiguriert hat.

Enginsight unterscheidet mit "Warnung", "Information" und "Kritischer Zustand" drei Kategorien von Alarmen und bietet darüber hinaus für den Alarmfall sehr umfangreiche Benachrichtigungsoptionen. Neben dem Versand einer E-Mail kann die Software den oder die verantwortlichen Personen auch per SMS, Slack, Mattermost oder Microsoft Teams benachrichtigen.

Seine volle Stärke spielt das Enginsight-System aus, wenn der Admin auch die Automatisierung via Plug-ins nutzt. Das System triggert dann bei Alarmen die Ausführung eines Plug-ins auf dem betreffenden System. Da diese Plug-ins Bash-, PowerShell- oder Python-3-Skripte sind, können sie praktisch alle Aufgaben übernehmen, die auf dem System mit der gewählten Skriptsprache realisierbar sind.

Das Shield-Modul erlaubt eine umfangreiche Manipulation des Netzwerkverkehrs für alle Server und Clients, auf denen der Pulsar-Agent installiert ist. Voraussetzung für die Nutzung von Shield ist weiterhin, dass in der Konfiguration des Pulsar-Agenten zuvor die Option "Netzwerkmitschnitt" aktiviert wurde. Shield unterscheidet dynamische und manuelle Regelwerke. Dynamische Regelwerke blockieren den betreffenden Netzwerkverkehr automatisch, sofern der Administrator eines oder mehrere der folgenden Ereignisse im dynamischen Regelwerk ausgewählt hat: Portscan, Bruteforce-Angriff, SYN-Flooding, DNS- und ARP-Spoofing, SSL/TLS (Cipher Enumeration und Protocol Scan) oder Angriffe auf Webapplikationen.

Mit manuellen Regelwerken legt der Admin dagegen abhängig von IP-Adresse, Protokoll und Port sehr individuell fest, ob bestimmter Netzwerkverkehr geblockt werden soll. Mit Shield und manuellen Regelwerken sind IT-Verantwortliche so in der Lage, beispielsweise bestimmte Systeme unabhängig von Netzwerksegmenten zu isolieren. Dies bietet sich beispielsweise an, wenn für diese keine Sicherheitsupdates mehr ausgeliefert werden.

Manuelle Regelwerke eignen sich aber auch hervorragend, um eine Mikrosegmentierung des gesamten Netzwerks umzusetzen. Auf diese Weise lässt sich mit Shield auch ein Zero-Trust-Ansatz nach dem Whitelist-Prinzip realisieren und zunächst sämtlicher Netzwerkverkehr verbieten und danach nur die erwünschten Verbindungen explizit erlauben.

Enginsight kommt dem eigenen Anspruch, "die einfachste All-in-One Cybersecurity-Lösung für den Mittelstand" zu sein, schon recht nahe. Viele Funktionen wie die Checklisten zur sicheren Konfiguration von Systemen oder die Automatisierung von Aufgaben per Shell-Skript als Plug-ins finden sich in vergleichbaren Lösungen kaum. Und auch die Inbetriebnahme – insbesondere im SaaS-Modell – ist tatsächlich sehr einfach. Schon aufgrund der Vielzahl der mitgelieferten Module dürfte Enginsight derzeit eine der vollständigsten IT-Monitoringanwendungen mit konsequentem Fokus auf IT-Sicherheit sein.

Während des Tests sind uns allerdings auch einige Punkte aufgefallen, die Enginsight in künftigen Versionen besser lösen könnte: So ist die Web-GUI derzeit relativ unübersichtlich, weil viele Funktionen – insbesondere jene der Netzwerksensoren – in den verschachtelten Menüs versteckt sind. Längere Bildschirmausgaben wie etwa die Assets bei den Discoveries teilt die Software auf mehrere Seiten auf und es ist sehr leicht zu übersehen, dass noch weitere Seiten folgen. Weiterhin stellt Enginsight derzeit noch keine mobile App zur Verfügung. Die Beschränkung der Bedienung auf das Webinterface dürfte auf Dauer aber nicht alle Kunden zufriedenstellen.