MENU Schließen
Schließen

Release Notes 3.4.0 – 02.09.2021

Intrusion Detection und Prevention: Erweiterter Erkennungsumfang und einfachere Verwaltung | Erweiterte Softwareüberwachung auf Servern und Clients | Mehr Sicherheitslücken (CVE) mit Auth-Providers aufdecken | SSL/TLS: BSI-Checkliste für Endpunkte integriert

Netzwerkpakete überwachen, Cyberattacken erkennen und anschließend blockieren – das Intrusion Detection und Prevention System von Enginsight erlaubt diesen Dreischritt durch die Erkennung von mehr Angriffstypen und eine verbesserte Konfiguration so einfach wie nie. Außerdem neu: Auth-Providers für bessere CVE-Ergebnisse beim automatisierten Penetrationstest hinterlegen, SSL/TLS-Verbindungen mit BSI-Checkliste abgleichen und viele Verbesserungen im Detail.

für SaaS: ab sofort | für On-Premises: ab sofort

Intrusion Detection und Prevention: Erweiterter Erkennungsumfang und einfachere Verwaltung

Das hostbasierte Intrusion Detection und Prevention System von Enginsight ist beim Pulsar-Agent bereits inklusive. Das erlaubt günstig, ohne extra Hardware und mit minimalem Aufwand ein höheres Schutzniveau zu implementieren. Dabei skaliert das IDS/IPS mit der IT-Infrastruktur und ist daher für Unternehmen aller Größen die richtige Wahl.

Mehr Angriffe erkennen für besseren Schutz

Wir haben den Funktionsumfang unseres Intrusion Detection Systems (IDS) deutlich erweitert. Neben der bereits vorhanden Angriffsarten können Enginsight Nutzer zusätzlich die SNORT Community Regeln nutzen, um Ihre Server und Clients vor Hackern zu schützen. Mit den SNORT Community Regeln und der detaillieren Analyse von Netzwerkpaketen erkennt Enginsight auch spezifischere Angriffe auf Ihre IT.

Zum Beispiel:

  • Attacken, die speziell auf den Microsoft IIS oder Exchange Server abzielen
  • Zugriffsversuche auf sensible Daten eines Webservers
  • CGI-Angriffe (z.B. Shellshock)

Einfache und komfortable Bedienung

Trotz der deutlich erweiterten Detection haben wir die Einrichtung und Verwaltung komfortabel und einfach halten können. Um den erweiterten Erkennungsumfang zu nutzen, brauchen Sie nichts weiter tun, als der Lizenz für die Snort Community Rules für die jeweilige Organisation zuzustimmen. Das erledigen Sie in den allgemeinen Einstellungen der Organisation.

Akzeptieren Sie die Lizenz und die neuen IDS-Funktionen sind freigeschaltet. (zum Vergrößern klicken)

Im Anschluss können Sie das IDS nach Ihren Wünschen und Bedürfnissen konfigurieren. Dazu wurden die Snort Regeln von uns nach Performance Impact sortiert.

Sie haben die Wahl zwischen fünf Detection Levels:

  • Level 0: Maximale Performance
    Zugunsten einer maximalen Geräteperformance wird die Erkennungsrate deutlich beschnitten.
  • Level 1: Performance vor Sicherheit
    Die wichtigsten Bedrohungen werden erkannt, wobei der Fokus auf einer guten Geräteperformance liegt. Wir empfehlen dieses Level für Clients und für unter hoher Last stehende Server.
  • Level 2: Ausgewogene Performance und Sicherheit
    Das Level bietet eine Balance zwischen der Erkennung von komplexeren Bedrohungen und der Geräteperformance. Wir empfehlen dieses Level für normal ausgelastete Server.
  • Level 3: Sicherheit vor Performance
    Auch seltene und spezifische Angriffe werden erkannt, Einschränkungen in der Geräteperformance sind aber möglich. Diese Einstellung ist für besonders schützenswerte Geräte oder Netzwerksegmente vorgesehen.
  • Level 4: Maximaler Schutz
    Diese Einstellung bietet die maximale Erkennung von Bedrohungen, kann aber die Geräteperformance wesentlich beeinträchtigen. Daher ist sie nur in Einzelfällen oder für den temporären Einsatz empfehlenswert.
Finden Sie für Ihre Server und Clients das Optimum zwischen Performance und Sicherheit. (zum Vergrößern klicken)

Zur passgenauen Konfiguration des IDS für Ihre Server und Clients nutzen Sie am besten Tags und den Policy Manger. So lassen sich effizient die richtigen Einstellungen für jeden Server und Client wählen. Kategorisieren Sie Ihre Hosts zum Beispiel mit Tags zu Risikolevel und Leistungsreserven und legen Sie anschließend die entsprechenden Policies an.

IDS-Whitelists anpassen

Haben Sie bereits die Möglichkeit genutzt, Whitelists für das Intrusion Detection System anzulegen, bedürfen die Einträge einer Anpassung an das neue System. Das gilt unabhängig davon, ob Sie die Snort Community Rules aktiviert haben oder nicht.

Die Bezeichnung für den Angriff muss an die neuen Bezeichnungen angepasst werden. In der Dokumentation haben wir für Sie eine Liste hinterlegt, der Sie die neuen Bezeichnungen entnehmen können. Auch Einträge, die für alle Angriffe galten (ALL) müssen angepasst werden. Fügen Sie stattdessen ein * ein.

Neu ist die Möglichkeit bei der Angriffsdefinition mit Wildcards (*) zu arbeiten. Zum Beispiel für:

  • Angriffe einer bestimmten Kategorie: SERVER-WEBAPP*
  • Angriffe eines bestimmten Protokolls: *RDP*
  • Angriffe eines bestimmten Typs: *bruteforce*

Die bereits bekannten Whitelist-Funktionen bleiben erhalten: Im Feld Regex können Sie die Ausnahmeregel genauer spezifizieren. Dazu können Sie mit den detektierten Details des IDS arbeiten. So können Sie beispielsweise den Whitelist-Eintrag auf einen speziellen Dienst beschränken. Nutzen Sie bei Whitelisteinträgen Tags für die Host-Zuordnung, um die Ausnahmeregel einer Gruppe von Servern und Clients zuzuordnen.

Aktualisiertes Intrusion Prevention System

Auch die Konfiguration des Intrusion Prevention Systems haben wir dem neuen Umfang an Angriffsszenarien, die erkannt und damit geblockt werden können, angepasst. Treffen Sie eine Abwägung zwischen maximaler Sicherheit und Verfügbarkeit des Systems.

Für dynamische Regelwerke stehen Ihnen fünf Level zur Verfügung:

  • Level 0: Sehr hohe Eingriffsschwelle
    Zugunsten einer maximalen Verfügbarkeit werden nur wenige Bedrohungen geblockt.
  • Level 1: Verfügbarkeit vor Sicherheit
    Die wichtigsten Bedrohungen werden geblockt, wobei der Fokus auf einer guten Verfügbarkeit liegt.
  • Level 2: Ausgewogene Verfügbarkeit und Sicherheit
    Diese Einstellung wird von uns empfohlen. Sie bietet eine ideale Balance zwischen dem Blocking komplexer Bedrohungen und der Verfügbarkeit des Geräts.
  • Level 3: Sicherheit vor Verfügbarkeit
    Auch seltene und spezifische Angriffe werden geblockt, ungewollte Einschränkungen in der Verfügbarkeit sind aber möglich. Diese Einstellung ist für besonders schützenswerte Geräte oder Netzwerksegmente vorgesehen.
  • Level 4: Maximaler Schutz
    Diese Einstellung bietet die maximale Sicherheitsstufe, verursacht aber häufig Verfügbarkeitsprobleme. Daher ist sie nur in Einzelfällen oder für den temporären Einsatz empfehlenswert.

Um die Einstellungen weiter zu spezifizieren, können Sie den Timeout, den Scope und die Dringlichkeit, ab der geblockt werden soll, anpassen. Der Timeout bestimmt die Dauer der Blockings. Mit dem Scope legen Sie fest, welche Netzwerkpakete des Angreifers geblockt werden sollen: Host (alle Pakete) oder nur die des betroffenen Service bzw. Ports. Mit der Option „Empfehlungen überschreiben“ können Sie außerdem die im Datensatz hinterlegten Empfehlungen, ob eine Verbindung geblockt werden soll, überschreiben.

Richten Sie sich das IPS nach Ihren individuellen Bedürfnissen ein. (zum Vergrößern klicken)

Überprüfen Sie gegebenenfalls vorhandene dynamische Regelwerke nochmals, ob die neuen Einstellungen den eigenen Anforderungen entsprechen. Auch für das IPS empfiehlt es sich, die mit dem Pulsar-Agent überwachten Server und Clients mit Tags zu gruppieren, um im Anschluss die dynamischen Regelwerke zuzuordnen.

Shield für SMB-Protokoll richtig konfigurieren

Das Server Message Block-Protokoll (SMB) wird auf Windows Servern und Clients genutzt, um Dateien über das Netzwerk freizugeben, zum Beispiel gegenüber einem Drucker oder NAS. In Einzelfällen kann die Performance der Windows Server und Clients unzureichend sein, um die Shield-Funktionalitäten für das Protokoll zu unterstützen. Überprüfen Sie daher, ob bei Ihnen hier der Bedarf zu einer Anpassung der Shield-Konfiguration nötig ist. Eine detaillierte Anleitung, wie Sie Shield für SMB deaktivieren, erhalten Sie in der Dokumentation.

Erweiterte Softwareüberwachung auf Servern und Clients

Die Inventarisierung aller Software, die sich im Einsatz befindet, ist eine wichtige Aufgabe der IT-Administration. Da ein Softwareinventar auch die Grundlage für den Scan nach Sicherheitslücken (CVE) bildet, ist es auch aus Sicherheitsaspekten gar nicht hoch genug zu bewerten. Die Installation eines Pulsar-Agents auf Ihren Servern und Clients ermöglicht Ihnen, die potenziell zeitraubende Aufgabe der Softwareinventarisierung zu automatisieren.

Neu ist die Möglichkeit, die Dateien des Servers oder Clients aktiv nach Software zu scannen. So lässt sich auch jene Software inventarisieren, die nicht mit einem regulären Installationsprogramm installiert ist. Das können beispielsweise in andere Applikationen eingebettet Programme oder Portable Apps sein.

Wollen Sie die erweiterte Softwareüberwachung aktivieren, gehen Sie in die Einstellungen des entsprechenden Hosts oder nutzen Sie den Policy Manager, um die Einstellung auf mehreren Hosts gemeinsam zu verwalten.

AutoUpdates im Policy Manager verwalten

Wie Sie es bereits von anderen Einstellungen gewöhnt sind, können Sie jetzt auch die automatischen Updates auf Ihren Servern und Clients im Policy Manager verwalten. Das heißt, Sie brauchen nicht in die Einstellungen des einzelnen Hosts zu gehen, sondern können Tags nutzen, um die Einstellungen mehrer Hosts gleichzeitig anzupassen.

Verwalten Sie Ihre automatischen Updates mit dem Policy Manager. (zum Vergrößern klicken)

Auch hier besteht die Möglichkeit, automatische Updates auf sicherheitsrelevante Aktualisierungen zu beschränken, einen Neustart zu forcieren sowie einen gewünschten Zeitpunkt via Cron-Ausdruck festzulegen.

Automatisierte Penetrationstests

Führen Sie mit den Penetrationstests von Enginsight einen automatisierten Sicherheitsaudit aus Hackerperspektive durch. Entweder auf einzelne Webseiten und Server oder aber auf die gesamte IT-Infrastruktur.

Mehr Sicherheitslücken (CVE) mit Auth-Providers aufdecken

Mit einem Auth-Provider können Sie Zugangsdaten von Zielsystemen hinterlegen, um mehr Informationen abrufen zu können. Der Zugriff auf das Zielsystem ermöglicht den Abruf des Betriebssystems und installierter Software. Deshalb kann Hacktor mehr Sicherheitslücken (CVEs) detektieren und validieren, als wenn ihm nur die öffentlich erreichbaren Informationen zur Verfügung stehen.

Hinterlegen Sie Zugangsdaten und erhalten Sie bessere Informationen zu Sicherheitslücken. (zum Vergrößern klicken)

Zugangsdaten können für die folgenden Services hinterlegt werden:

  • SSH (Secure Shell): Protokoll zur Fernwartung und Administration von Servern und Clients, die hauptsächlich für Linux Server und Clients zum Einsatz kommt.
  • WMI (Windows Management Instrumentation): Service zur Fernwartung und Administration von Windows Servern und Clients.
  • SNMP v1/v2/v3 (Simple Network Management Protocol): Protokoll zur Überwachung und Steuerung von Netzwerkgeräten, das vor allem für Drucker, Switches oder Industrieanalagen zum Einsatz kommt.

Für Server und Clients, auf denen eine Version von Windows oder Linux zum Einsatz kommt, empfehlen wir weiterhin die Installation eines Enginsight Pulsar-Agents, um Sicherheitslücken von innen zu überwachen. Umfang und Validität der Ergebnisse des CVE-Scans von innen sind auch bei hinterlegtem Auth-Provider dem Hacktorscan überlegen. Darüber hinaus erlaubt der CVE-Scan mit installiertem Pulsar-Agent eine komfortablere Verwaltung und ist aus Sicherheitsaspekten zu bevorzugen, da keine Zugangsdaten hinterlegt bzw. Zugriffe freigeschaltet werden müssen.

Gerade für Netzwerkgeräte, auf denen kein Pulsar-Agent installiert werden kann, eröffnen die Auth-Providers aber eine wichtige Ergänzung für den ganzheitlichen Scan von Sicherheitslücken. Hier spielt insbesondere das SNMP-Protokoll seine Stärke aus.

Neuer Check für Remote Desktop Protocol

Den Funktionsumfang des Penetrationstests erweitern und optimieren wir stetig. Mit der neuen Enginsight Version wird das RDP-Protokoll genauer untersucht.

Das Remote Desktop Protocol von Microsoft ermöglicht einen Fernzugriff auf den gesamten grafischen Bildschirminhalt. Eine besondere Absicherung ist daher notwendig. Die Authentifizierung sollte bereits auf Netzwerkebene erfolgen.

Fehlende RDP Network Level AuthenticationDer Anmeldebildschirm ist erreichbar, ohne dass auf Netzwerkebene eine Authentifizierung notwendig ist. Er sollte mit Hilfe der Authentifizierung auf Netzwerkebene abgesichert sein, um eine sichere Authentifizierungsmethode zu gewährleisten.

Penetrationstest in Vorlage genauer spezifizieren

In der Vorlage definieren Sie die Bedingungen, unter denen der Penetrationstest durchgeführt wird. Sie legen unter anderem fest, welcher Hacktor welche Zielsysteme auditieren soll, aber können auch weitere Details an Ihre Bedürfnisse anpassen.

Definieren Sie, wie der Pentest ablaufen soll. (zum Vergrößern klicken)

Die Einstellungsmöglichkeiten in der Vorlage haben wir erweitert. Sie können:

  • Drucker ausschließen: Legen Sie fest, ob der Penetrationstest auch auf Drucker/Scanner ausgeführt werden soll. Ein Penetrationstest auf einen Drucker kann zu Konfigurationsänderungen oder unbeabsichtigtem Drucken führen.
  • Zertifikatsvalidierung überspringen: Bestimmen Sie, ob SSL/TLS-Zertifikate überprüft werden sollen. Beim Scan interner Netze führt die Zertifikatsvalidierung potenziell zu Warnungen, die in diesem Fall irrelevant sind.
  • BSI-Check überspringen: Legen Sie fest, ob die SSL/TLS-Verschlüsselung auf Basis der BSI-Checkliste TR-03116-4 überprüft werden soll.

Weiterhin können Sie definieren:

  • Bruteforce: Wiederholtes, automatisiertes ausprobieren von Passwörtern, um sich Zugriff auf Benutzerkonten zu verschaffen und im authentifizierten Kontext nach weiteren Schwachstellen zu suchen.
  • Custom Scripts: Legen Sie fest, ob Custom Scripts ausgeführt werden sollen, sofern Sie im Hacktor hinterlegt wurden.
  • Ausschließlich eigene Passwortliste verwenden: Beschränken Sie die Bruteforce-Attacken auf Ihre eigene Passwortliste und ignorieren Sie unsere Standardliste.

SSL/TLS: BSI-Checkliste für Endpunkte integriert

In der Technischen Richtlinie BSI TR-03116-4 gibt das Bundesamt für Sicherheit in der Informationstechnik (BSI) Vorgaben und Empfehlungen zur sicheren SSL/TLS-Konfiguration. In dem umfangreichen Katalog sind Anforderungen an die verwendeten Versionen, Schlüssel, Algorithmen und Zertifikate sowie weitere Vorgaben definiert. Erfüllt eine Webseite den gesamten Anforderungskatalog des BSI, kann auf eine sichere SSL/TLS-Konfiguration geschlossen werden. Deutliche Abweichungen hingegen sind ein Zeichen für grobe Fehler und daraus resultierende Sicherheitsmängel.

Überprüfen Sie, ob Ihre Webseite den Empfehlungen des BSI entspricht. (zum Vergrößern klicken)

Weil die Richtline BSI TR-03116-4 ein guter Indikator zur Bewertung der SSL/TLS-Konfiguration darstellt, haben wir die Checkliste in unser Webseiten-Monitoring integriert. Für jeden hinzugefügten Endpunkt ermittelt Enginsight automatisch den Anteil der Anforderungen und Empfehlungen, die umgesetzt sind. Ab einem Anteil von 85% gehen wir von einer guten SSL/TLS-Konfiguration aus. Sind weniger als 70% umgesetzt, definieren wir die Konfiguration als kritisch.

Als Leitfaden zur Verbesserung der SSL/TLS-Verschlüsselung dient die Übersicht, der Sie entnehmen können, welche Punkte der Checkliste noch nicht umgesetzt werden. Indem Sie die bemängelten Punkte nach und nach abarbeiten, erhöhen Sie einfach und effektiv das Sicherheitsniveau der Webanwendung.

Überprüfen Sie Ihre bereits überwachten Endpunkte auf die Übereinstimmung mit der Checkliste des BSI oder fügen Sie neue Webseiten hinzu, um Ihre SSL/TLS-Verbindungen weiter zu optimieren.

Weitere Beiträge im Enginsight Blog
Enginsight Logo