Mit dem neuen Shield Modul entwickelt sich Enginsight vom integrierten und hostbasierten Intrusion Detection System (IDS) zum Intrusion Prevention System (IPS) weiter. Shield bietet darüber hinaus neue Möglichkeiten eines flexiblen und hostbasierten Managements des Netzwerkverkehrs. Unser Update ist daher der nächste große Schritt, Enginsight zur zentralen Einheit für Ihr IT-Security-Management zu entwickeln.
Das neue Shield-Modul
Mit dem Shield-Modul erhalten Sie ein Werkzeug, um hostbasiert und unabhängig von Netzsegmenten den Netzwerkverkehr zu managen. Sie können ganz einfach ein dynamisches Blocking detektierter Hackingattacken konfigurieren sowie manuell sämtliche denkbaren Regeln definieren. Nutzen Sie Shield, um sehr detaillierte Vorgaben für einzelne Systeme oder Gruppen von Systemen festzulegen. So können Sie mit Enginsight eine Zero Trust Umgebung realisieren oder eine Mikrosegmentierung vornehmen.
Mit Enginsight Shield eröffnen sich neue Perspektiven für ein flexibles Management Ihrer IT-Infrastruktur und der Abwehr von Hackingangriffen. Verhindern Sie die Ausbreitung von Cyberattacken, welche mit der Firewall die erste Hürde überwunden und sich im internen Netz festgesetzt haben. Mit wenigen Klicks können Sie dafür sorgen, dass betroffene Systeme automatisch im Netzwerk isoliert werden. Und zwar nicht erst an der Schwelle zum nächsten Netzwerksegment, sondern bereits innerhalb der einzelnen Subnetze.
Wie führen Sie Shield bei sich ein?
Mit dem Pulsar-Agent auf Ihren Servern und Clients haben Sie bereits die technische Basis für das neue Feature in Ihre IT-Infrastruktur implementiert. Bevor Sie mit der Erstellung dynamischer und manueller Regelwerke beginnen, brauchen Sie lediglich die Shield-Funktionalitäten für die gewünschten Hosts über den Policy Manager zu aktivieren. Achten Sie zudem darauf, dass Sie Ihren Pulsar-Agent auf dem aktuellen Stand haben. Führen Sie ansonsten zunächst ein Update durch.
Achtung: Das aktuelle Pulsar-Agent Update führt zu kurzzeitiger Unterbrechung des Netzwerkverkehrs, da wir den Treiber zur Analyse des Netzwerkverkehrs erneuern. Wählen Sie den Zeitpunkt für die Updates entsprechend aus, damit es zu keinen Komplikationen kommt. Auf älteren Systemen kann es gegebenenfalls zu einem Abbruch der Netzwerkverbindung kommen, der sich nur durch einen Neustart beheben lässt.
Für den Einsatz von Shield unter Linux empfehlen wir eine Kernel-Version >4.19.
Dynamisches Regelwerk: Cyberattacken blockieren
Ein guter Startpunkt das Shield-Modul kennenzulernen, ist das Blocken detektierter Angriffe. Auf Grundlage der Analyse des Netzwerkverkehrs erkennt Enginsight für Angriffsvektoren übliche Anomalien. Mit dem Shield Modul können Sie diese nun einfach blockieren. So wird Enginsight zum Intrusion Prevention System (IPS).
Erstellen Sie ein dynamisches Regelwerk und definieren Sie über Tags oder für einzelne Hosts, dass die Regel angewandt werden soll. Im Anschluss können Sie Kategorien wählen, für die das Blocking aktiv sein soll.
Ihnen steht zur Auswahl:
- PortScan: Mit Portscans werden IT-Systeme von außen untersucht. Sie stellen oft die erste Instanz eines Eindringversuchs dar und können insbesondere im internen Netz auf einen erfolgreichen Angriff hindeuten.
- TCP
- Bruteforce: Durch das massenhafte Ausprobieren von Nutzer-/Passwortkombinationen wird versucht, die Authentifizierung auszuhebeln.
- SSH
- MySQL
- MongoDB
- HTTP Basic Authentication
- FTP
- RDP
- VNC
- SMB
- Flooding: Mit massenhaft versendeten Datenpaketen und Anfragen sollen IT-Systeme lahmgelegt werden.
- SYN-Flooding
- Spoofing: Die Verschleierung der eigenen Identität dient dazu, Authentifizierungs- und Identifikationsverfahren zu untergraben.
- ARP-Spoofing
- DNS-Spoofing
- SSL/TLS: Der Scan aller verfügbaren SSL/TLS-Protokolle und Chiffren dient dazu, Schwachstellen zu erkennen, um sie im Anschluss auszunutzen.
- SSL/TLS Cipher Enumeration
- SSL/TLS Protocol Scan
- Web: Webbasierte Attacken versuchen durch die Manipulation der Webanwendung Schadsoftware zu platzieren, Nutzer zu täuschen oder an sensible Daten zu gelangen.
- SQL Injection
- Path Traversal
- Remote Code Execution
Für falsch positive Ergebnisse anfällige Angriffsvektoren haben wir bereits entfernt, um die Funktionalität Ihrer IT-Infrastruktur nicht zu gefährden. Wir empfehlen daher, das Blocking für alle Kategorien zu aktivieren.
Als Blocking-Aktion steht Ihnen das Verwerfen (Drop) sowie Ablehnen (Reject) der Netzwerkpakete zur Auswahl. Für das Blocking von Cyberattacken empfehlen wir das Verwerfen der Pakete, da dem Angreifer dadurch keine Informationen zum Einsatz von Security-Software zugespielt werden.
Manuelles Regelwerk
Mit manuellen Regelwerken können Sie abhängig von IP, Protokoll und Port definieren, ob Shield Netzwerkverkehr blockieren oder erlauben soll. Die Anwendungsszenarien, die Ihnen dadurch eröffnet werden, sind vielfältig und stark abhängig von der Konzeption Ihrer IT-Umgebung. Die Möglichkeiten sind enorm.
Damit ein manuelles Regelwerk wirksam wird, müssen Sie mit Zuordnungen die dazugehörigen Hosts bestimmen. Dabei können Sie entweder Hosts und Regeln direkt miteinander verknüpfen oder mit Tags arbeiten. Wir empfehlen Ihnen grundsätzlich mit Tags zu arbeiten, um die Flexibilität zu erhöhen.
In vielen Fällen ist es ein sinnvolles Vorgehen, zunächst Netzwerkverkehr zu blockieren und im Anschluss mit Whitelisten bestimmten Netzwerkverkehr freizugeben. Regelwerke, die Netzwerkverkehr akzeptieren, überschreiben stets diejenigen Regelwerke, die Verkehr verwerfen oder ablehnen. Sollten mehrere Blocking-Regeln gleichzeitig greifen, entscheidet die von Ihnen zugeteilte Priorität, welche Regel aktiv wird und Sie in den Logs angezeigt bekommen.
Beispiel: Systeme isolieren
Um ein System im Netzwerk zu isolieren, erstellen Sie ein manuelles Regelwerk für den gewünschten Host. Aktivieren Sie ein bidirektionales Blocking und geben Sie als Ziel die gesamte IP-Range der Systeme an, von denen der Host isoliert werden soll. Anschließend verknüpfen Sie das Regelwerk via Zuordnung mit dem gewünschten Host.
Sie können auch den gegenteiligen Weg gehen: Verbieten Sie via Tag allen anderen Hosts mit dem zu isolierenden System zu kommunizieren. In der Regel ist der erste Weg zu empfehlen. Sollten Sie aber auf dem zu isolierenden System beispielsweise keinen Pulsar-Agent installieren können, bietet diese Alternative eine Möglichkeit, dennoch Enginsight Shield einzusetzen.
Beispiel: Whitelisten erstellen
Mit Whitelisten können Sie via Shield isolierten Systemen bestimmten Netzwerkverkehr erlauben. Zum Beispiel zu ausgewählten IP-Adressen für einzelne Protokolle und Ports. Haben Sie etwa einen Server, den Sie nicht patchen können, der aber dennoch eine wichtige Funktion übernimmt, können Sie so das Risiko minimieren. Erlauben Sie dem entsprechenden Asset lediglich mit einzelnen IPs, mit dem benötigten Protokoll und auf den entsprechenden Ports zu kommunizieren.
Mit Regelwerken, die Netzwerkverkehr akzeptieren, können Sie auch sicherstellen, dass Security-Software nicht vom dynamischen Blocking behindert wird. So sollten Sie beispielsweise dem Enginsight Hacktor stets eine Whitelist zuordnen.
Shield Logs: Übersicht aller Blocking-Aktivitäten
Ob Shield aktiv geworden ist, können Sie in den Logs nachvollziehen. Hier sehen sie aufgelistet, welche Netzwerkverbindung aufgrund welchen Regelwerks geblockt wurde. Direkt aus den Logs heraus können Sie Ausnahmen definieren, damit die entsprechende Verbindung in Zukunft akzeptiert wird. Klicken Sie dazu auf den Ausnahme-Button.
Validitäts-Ampel: Volle Transparenz bei CVE-Scans
Mit Enginsight können Sie Ihre IT aus drei Perspektiven einem CVE-Scan unterziehen: Der Pulsar-Agent scannt Ihre Server und Clients von innen, mit dem Hacktor können Sie netzwerkbasiert gesamte Netzwerke untersuchen und mit dem Observer Webanwendungen von außen überwachen.
Um die Sicherheitslücken zu validieren, bezieht Enginsight Meta-Daten in die Analyse ein. So schaffen wir es, die Rate an False Positives zu minimieren. Je mehr Meta-Informationen Enginsight zur Verfügung stehen, desto valider wird das Ergebnis.
In der Benutzeroberfläche verdeutlichen wir die Validität mit einer Ampel:
- grün: hohe Validität
- gelb: mittlere Validität
- rot: geringe Validität
Zwei Beispiele
- Die Sicherheitslücke eines Content Management Systems lässt sich sehr viel einfacher validieren als eine CVE einer Programmiersprache. Ob die CVE der Programmiersprache wirksam wird, hängt von vielen Faktoren ab, insbesondere der genauen Version des Betriebssystems. Eine Sicherheitslücke eines CMS wird in der Regel immer wirksam.
- Lässt sich für Hacktor oder Observer das Betriebssystem herausfinden, ist das eine wichtige Information und die Validität profitiert davon bereits deutlich. Können die Softwarekomponenten darüber hinaus die konkrete Version detektieren, hat die Validität ein hohes Level erreicht.
Validität, Risikoscore und Dringlichkeit
Die Validität der Sicherheitslücke beeinflusst den Risikoscore, den Enginsight vergibt. Vom Risikoscore hängt die Dringlichkeit (low, medium, high, ciritical) ab, mit der die Sicherheitslücke versehen wird. Grundlage des Risikoscores ist der CVSS-Score, den wir modifizieren und mit der Validität verrechnen.
Vernachlässigen Sie nicht grundsätzlich Sicherheitslücken mit geringer Validität. Sie können für den sicheren Betrieb dennoch sehr kritisch sein. Überprüfen Sie insbesondere Schwachstellen mit hohem CVSS-Score manuell. Nutzen Sie dafür die verlinkten Informationen in der NIST-Datenbank.
Virtual Desktop Infrastructure (VDI) überwachen
Virtual Desktop Infrastructures (VDI) erlauben eine Virtualisierung der Desktop-Umgebung im Unternehmensnetzwerk. Ein zentraler Server stellt den PC-Service bereit, der von den Clients abgerufen wird. Während die Bedienung lokal auf dem Client erfolgt, wird die Software auf dem Server ausgeführt.
Mit Enginsight 3.0.0 haben wir die Überwachung von VDI-Umgebungen realisiert. So können Sie die Benutzer der VDI-Infrastruktur als Client Hosts hinzufügen und dauerhaft überwachen. Die einzelnen Benutzer werden in der Host-Übersicht angezeigt, wie Sie es von anderen Servern und Clients auch gewöhnt sind. So ermöglichen Enginsight auch in VDI-Umgebungen eine vollständige Live-Überwachung, unter anderem ein dezentrales und hostbasiertes Intrusion Detection System (IDS).
Pentest: Audit Reports automatisch per E-Mail versenden
In der Vorlage für Penetrationstests steht Ihnen die Option zu Verfügung, eine wiederkehrende Durchführung zu definieren. Legen Sie beispielsweise fest, dass der automatisierte Pentest von Enginsight einmal wöchentlich oder zum Anfang des Monats durchgeführt wird. So erhalten Sie vergleichbare Ergebnisse zur Entwicklung Ihres Sicherheitsniveaus.
Die Ergebnisse der Pentests können Sie sich jetzt automatisch als PDF-Bericht per E-Mail zusenden lassen. Aktivieren Sie die entsprechende Option und legen Sie fest, welche Teammitglieder eine E-Mail erhalten sollen. Wir empfehlen, die sensiblen Daten stets verschlüsselt und mit einem Passwort geschützt zu versenden. Vergeben Sie daher in der Enginsight Plattform ein sicheres Passwort.
Für IT-Dienstleister, die Enginsight als Managed Service anbieten, optimiert die neue Möglichkeit erneut den Prozess der Kundenbetreuung.
Tags in der Host-Übersicht bearbeiten
Tags sind eine wichtige Funktion in Enginsight, um Assets zu gruppieren und effektiv zu managen. Sie können Tags beispielsweise nutzen, um Alarme und Plugins zuzuordnen sowie im Policy Manager Einstellungen zu verwalten. Außerdem, um im neuen Shield-Modul manuelle und dynamische Blocking-Regeln zuzuordnen.
Um die richtigen Tags schneller den entsprechenden Hosts zuzuordnen, können Sie die Tags jetzt direkt in der Host-Übersicht bearbeiten. Klicken Sie dazu einfach auf das Bearbeiten-Icon hinter den Tags.
Hacktor: SMB Checks, SNMP Discovery RDP Bruteforce hinzugefügt
Weiter ausgebaut haben wir den Funktionsumfang unseres automatisierten Pentests. Die Pentest-Komponente Hacktor beherrscht jetzt weitere Services in der Bruteforce- wie Discovery-Phase
Server Message Block (SMB): SMB ist ein Protokoll zur Freigabe von Daten in Netzwerken. Hacktor überprüft SMB mit einer Bruteforce-Attacke auf eine sichere Authentifizierung die Konfigurationen in der Service Discovery-Phase. Es wird Netbios-SSN und Microsoft-DS unterstützt. Netbios-SSN wird momentan lediglich für Linux und nicht für Windows unterstützt.
| Bruteforce | Für SMB werden eine oder mehrere unsichere Benutzer-Passwort-Kombinationen verwendet oder ein Gastzugriff ist möglich. |
| Vorhandene Open Network Shares | Es existiert eine Freigabe, die nicht unter die Standard-Freigaben fällt. |
| Erlaubt Gastzugriff | Bei fehlerhaftem Login wird automatisch ein Gastzugriff erteilt, der möglicherweise Zugriffsrechte besitzt. |
| Erlaubt Lesezugriff | Ein Lesezugriff auf freigegebene Ordner ist via SMB möglich. |
| Erlaubt Schreibzugriff | Ein Schreibzugriff auf freigegebene Ordner, die nicht standardmäßig eingestellt sind, ist via SMB möglich. |
Simple Network Management Protocol (SNMP): SNMP erlaubt eine zentrale Überwachung und Steuerung von Elementen im Netzwerk. In der Discovery-Phase wird SNMP v1 und v2 jetzt auf Authentifizierung und Privilegien überprüft. SNMPv3 wird demnächst verfügbar sein.
| Verwendet gewöhnlichen Community String | Für SNMP werden eine oder mehrere Community Strings zur Nutzerauthentifizierung verwendet, die häufig verwendet werden und daher besonders unsicher sind. |
| Erlaubt Lesezugriff | Ein Lesezugriff auf Object Identifier (OID) ist via SNMP möglich. |
| Erlaubt Schreibzugriff | Ein Schreibzugriff auf Object Identifier (OID) ist via SNMP möglich. |
RDP Bruteforce: Das Remote Desktop Protocol ist ein Netzwerkprotokoll von Microsoft für den Fernzugriff auf Computer. Hacktor überprüft nun auch RDP auf sichere Kombinationen von Benutzern und Passwörtern.
Eine Auflistung aller Checks, die Hacktor durchführt, finden Sie in der Dokumentation.
Alarm auf Anmeldeversuche spezifizieren
Die Analyse der Log-Dateien des Pulsar-Agents auf Ihren Servern und Clients ermöglicht es Ihnen fehlgeschlagene und erfolgreiche Anmeldeversuche zu überwachen. Erstens erhalten Sie unter Systemevents eine Übersicht aller Login-Versuche. Zweitens können Sie einen Alarm schalten.
Wann ein Alarm ausgelöst werden soll, können Sie jetzt genauer spezifizieren. Geben Sie einen Grenzwert ein, ab dem der Alarm ausgelöst werden soll, zum Beispiel mehr als fünf Versuche in fünf Minuten. Der Alarm wird dann erst ausgelöst, wenn in dem entsprechenden Zeitraum die angegebene Anzahl an Logins überschritten wurde.
Ausnahmeliste für Festplatten
Die in Enginsight 2.17.0 eingeführten Ausnahmelisten beim Monitoring der Server und Clients haben wir erweitert. Nun lassen sich auch Festplatten aus der Überwachung ausschließen. Nutzen Sie die Option, um die korrekte Benachrichtigung bei neu erkannten Datenträgern sicherzustellen.
Advanced Hardening des Pulsar-Agent
Die Softwarekonzeption von Enginsight folgt höchsten Sicherheitsstandards. In einem Audit unserer API hat uns das der TÜV Süd im vergangenen Jahr bestätigt. In Ausnahmefällen kann es jedoch sinnvoll sein, das Security-Level des Pulsar-Agents zu erhöhen, indem bestimmte Funktionen grundsätzlich deaktiviert werden.
Die Ausführung von Plugins haben wir bereits standardmäßig deaktiviert. Sie muss vor der Nutzung im UI aktiviert werden. Unabhängig von der Benutzeroberfläche können Sie die Ausführung aber auch in den Einstellungen der lokalen Konfigurationsdatei des Pulsar-Agents deaktivieren. Plugins lassen sich dann nicht mehr über die Enginsight-Applikation aktiveren. Seien Sie daher vorsichtig mit dieser Option. Eine Anleitung finden Sie in der Dokumentation.
