Den technischen Reifegrad der IT-Sicherheit einfach ermitteln – mit den neuen Zusammenfassungen der Penetrationstests gelangen Sie jetzt noch schneller zu diesem Ziel. Außerdem neu: Whitelists für das Intrusion Detections System und verbesserte White Label Optionen für On-Premises-Installationen.
für SaaS: ab sofort | für On-Premises: ab sofort
Automatisierte Penetrationstests
Mit Enginsight können Sie einzelne Systeme oder ganze IT-Infrastrukturen mit einem automatisierten Pentest aus Hackerperspektive einem Security-Check unterziehen.
Neue Ansicht: Zusammenfassung
Die neue Benutzeroberfläche der Audit Reports erleichtert Ihnen die Auswertung der Penetrationstests. In einer neuen Zusammenfassung erhalten Sie eine zielsystemübergreifende Ansicht und eine statistische Auswertung des gesamten Pentests.
Die neue Ansicht benötigt die aktuelle Version des Softwaremoduls Hacktor (Version 4.9.21). Aktualisieren Sie daher Ihre Hacktor-Installationen vor dem nächsten Pentest, um in den Genuss der neuen Ansicht zu kommen.
In der Zusammenfassung werden nur nicht-bestandene Checks angezeigt die Ergebnisse sind nach Dringlichkeit sortiert. Der rechten Spalte können Sie entnehmen, wie viele Ziele betroffen sind. Um weiterführende Informationen zum einzelnen Check zu erhalten, klicken Sie auf Details anzeigen. Den Details können Sie die betroffenen Zielsysteme und Ports sowie die expliziten Ergebnisse des Checks entnehmen. Die Zusammenfassung steht Ihnen selbstverständlich auch als PDF-Bericht zu Verfügung.
Die gewohnte Auflistung aller durchgeführten Checks, differenziert nach den einzelnen Zielsystemen, steht Ihnen weiterhin zu Verfügung. Klicken Sie dazu oben rechts auf „Zu den Details“. Alternativ können Sie auch aus den Details des einzelnen Checks heraus in die Detailansicht navigieren („Zum Zielsystem“).
Empfehlungen
Um Ihnen den Schritt von der Analyse in die Handlung zu vereinfachen, sind in der Zusammenfassung wichtige Findings mit Empfehlungen angereichert. Den Empfehlungen können Sie entnehmen, wie Sie mit dem nicht-bestandenen Check umzugehen haben oder welche Einstellungen wir aus Sicherheitsaspekten empfehlen.
Validitäts-Ampel für CVEs im Audit Report
Die von Hosts und Endpunkten bekannte Validitäts-Ampel ist jetzt auch in den Audit Reports enthalten. Sie gibt abhängig von Softwaretypus und Metainformationen eine Abschätzung, ob die Sicherheitslücke vorhanden ist. Abhängig von der Schwere der Sicherheitslücke und der Validität ergibt sich die von Enginsight vergebene Dringlichkeit.
Mehr Informationen zur Validierung von Sicherheitslücken erhalten Sie in unserem Blogbeitrag: Sicherheitslücken (CVE) über Meta-Informationen oder Exploits validieren?
Custom Scripts ausführen
Dank Custom Scripts können fortgeschrittene Nutzer der Pentest-Komponente Hacktor individuelle Checks mitgeben, die für die zu testenden Systeme relevant sind. Denkbare Anwendungsszenarien für benutzerdefinierte Pentest-Skripte sind unzählig und abhängig von Ihren individuellen Anforderungen. Zum Beispiel können Sie Checks für ungewöhnliche Systeme hinterlegen, die für Ihre Infrastruktur von großer Bedeutung sind oder nach unerwünschten oder veralteten Konfigurationen suchen.
Die Skripte für die benutzerdefinierten Checks hinterlegen Sie direkt auf dem Linux-System, auf dem Sie Hacktor installiert haben. Eine ausführliche Schrit-für-Schritt-Anleitung erhalten Sie in der Dokumentation.
Bedenken Sie, dass invasive Tests die Verfügbarkeit Ihrer Systeme beeinträchtigen können. Nutzen Sie Custom Scripts daher erst nach ausgiebiger Kontrolle und wenn Sie genau wissen, welche Folgen das Skript nach sich ziehen kann.
Neue Checks hinzugefügt
Um den Funktionsumfang unserer automatisierten Pentests zu erweitern, ganz ohne dass Sie eigene Skripte hinterlegen müssen, haben wir neue Checks für gleich mehrere Services hinzugefügt.
HTTP: Stack Traces, Login- und Defaultseiten
Als Administrator nutzen Sie http auch, um Ihre Systeme zu warten und auf das Backend zuzugreifen. Nicht alle Informationen und Zugänge, die Sie dazu benötigen, sollten jedoch über einen gewöhnlichen Zugriff möglich sein. Hacktor überprüft daher jetzt auf die Ausgabe von Stack Traces (Fehlermeldungen) über HTML, erreichbare Loginmasken kritischer Systeme und Defaultseiten von Anwendungen.
| Ermöglicht Zugriff auf stack traces | Zu Diagnosezwecke erstellte Fehlermeldungen (stack traces) werden über die HTML-Seite ausgegeben oder lassen sich provozieren (zum Beispiel durch invalide Eingaben). Stack traces können sensible Informationen beinhalten, aus denen sich Angriffsvektoren ergeben. |
| Ermöglicht Zugriff auf Loginseite kritischer Systeme | Die über HTTP erreichbare Seite beinhaltet die Loginmaske eines kritischen Systems. |
| Defaultseite wird angezeigt | Die Defaultseite einer Anwendung ist über HTTP erreichbar. Dies deutet darauf hin, dass eine Fehlkonfiguration vorliegt und möglicherweise sensible Bereiche für Unbefugte zugänglich sind. |
SMTP
Zum Versenden von E-Mails ist seit gefühlter Ewigkeit das Protokoll SMTP der absolute Standard. Bei einer fehlerhaften Konfiguration lässt sich das SMTP-Protokoll allerdings missbrauchen, um Usernamen und E-Mail-Adressen auszuspähen oder den Mailserver gar für Spamnachrichten zu missbrauchen.
| Ermöglicht anonymen E-Mail-Relay | Nicht authentifizierten Nutzern wird erlaubt, über den Mail-Relay Nachrichten zu versenden. Der Mailserver lässt sich daher für Spamnachrichten missbrauchen. |
| Ermöglicht Benutzerenumeration mittels EXPN | Der Befehl SMTP EXPN gibt eine Liste von Alias Adressen mit dazugehörigen Zielen aus. Er kann missbraucht werden, um valide Usernamen auszuspähen oder E-Mail-Adressen für Spam zu sammeln. |
| Ermöglicht Benutzerenumeration mittels VRFY | Der Befehl SMTP VRFY ermöglicht zu überprüfen, ob eine E-Mail-Adresse vorhanden ist. Er kann missbraucht werden, um valide Usernamen auszuspähen oder E-Mail-Adressen für Spam zu sammeln. |
SSL/TLS
Der umfangreichen Überprüfung der SSL/TLS-Verschlüsselung durch Hacktor haben wir einen weiteren Check hinzugefügt.
| Fehlender Common Name in Subject Alternative Names | Der Common Name ist nicht in den Subjekt Alternative Names enthalten, weshalb die Validierung des Zertifikats blockiert wird. |
LDAP
Das Lightweight Directory Access Protocol (LDAP) ist für eine Vielzahl von Anwendungen von Bedeutung, unter anderem den Verzeichnisdienst Microsoft Active Directory (AD). Hacktor überprüft die sichere Authentifizierung.
| Erlaubt Unauthenticated Bind | Schlägt die Authentifizierung als Nutzer fehl (weil versehentlich ein leeres Passwort angegeben wurde), wird keine Warnung ausgegeben und anonymer Zugang gewährt. In der Folge besteht die Gefahr, sensible Daten öffentlich zugänglich hochzuladen. |
| Erlaubt ungesichertes Simple Bind | Die Übertragung von Passwörtern im Klartext darf nur über vertrauliche Verbindungen erfolgen. Erhält der Server ein Passwort im Klartext über eine unverschlüsselte Verbindung, muss er confidentialityRequired als Fehlercode zurückgeben, unabhängig davon ob das Passwort korrekt ist. |
Hosts
Durch die Installation des Pulsar-Agents ermöglicht Enginsight Ihnen eine Überwachung Ihrer Server und Clients von innen, inklusive eines hostbasierten Intrusion Detection Systems.
Whitelists für Intrusion Detection System pflegen
Mit dem Intrusion Detection System von Enginsight haben wir uns zum Ziel gesetzt, dass Sie als Anwender ausschließlich mit relevanten Warnungen versorgt werden, anstatt in einer Alarmflut zu versinken. Die Implementierung der Angriffserkennung und der hostbasierte Ansatz haben uns diesem Ziel bereits nähergebracht.
Mit der Whitelist geben wir Ihnen eine weitere Möglichkeit an die Hand, um das IDS mit Blick auf Ihre spezifische IT-Infrastruktur zu optimieren. Überprüfen Sie dazu alle Einträge, die Sie unter Netzwerkanomalien aufgelistet bekommen und entscheiden Sie, ob Sie das Risiko akzeptieren möchten. Das heißt, Sie legen fest, dass es sich um keine Cyberattacke oder keine ernst zu nehmende Bedrohung handelt.
Den Whitelist-Eintrag, den Sie so erstellen, können Sie entweder einem einzelnen Host zuordnen oder Sie greifen auf Ihre Tags zurück. Letzteres ist in der Regel die elegantere Lösung, um effektiv und zielgenau Whitelist-Einträge zu erstellen.
Um die IP-Adresse des vermeintlichen Angreifers zu definieren, nutzen Sie die CIDR-Schreibweise. So lässt sich sehr effizient das Subnetz definieren, für das die Ausnahmeregel gelten soll. Wollen Sie lediglich eine IP-Adresse zuordnen, wählen Sie die Präfixlänge /32 für IPv4-Adressen bzw. /128 für IPv6-Adressen.
Um die Ausnahmeregel genauer zu spezifizieren, nutzen Sie das Feld Regex. Hier können Sie mit den detektierten Details des IDS arbeiten. So können Sie beispielsweise den Whitelist-Eintrag auf einen speziellen Dienst beschränken, der für Fehlalarme verantwortlich ist.
Beachten Sie: Haben Sie auf Ihren Hosts auch das dynamische Blocken des Shield-Moduls aktiv, gelten die erstellten Whitelist-Einträge auch für Ihr Intrusion Prevention System. Schließlich lassen sich nicht detektierte Netzwerkattacken auch nicht mehr blocken. Nutzen Sie Shield, steht Ihnen mit manuellen Regelwerken außerdem eine zweite Möglichkeit zu Verfügung, Ausnahmen hinzuzufügen. Während IDS-Whitelists sich auf Angriffstypen beziehen, lassen sich mit manuellen Regelwerken IP-Adressen oder ganze Subnetze komplett ignorieren.
Service für Verbindungen wählen
Für offene Ports detektiert Enginsight unter Verbindungen in der Regel automatisch, um welchen Service es sich handelt. Die Information wird genutzt, um mit dem Intrusion Detection System gezielt und ressourcenschonend nach Cyberattacken zu scannen.
Sollte die automatische Erkennung eines Service nicht möglich sein, können Sie den Service jetzt in der Übersicht der Verbindungen des Hosts manuell nachtragen. So lässt sich die Performance des IDS optimieren.
Geräteinformationen abrufen
Mit Enginsight erhalten Sie jetzt Systeminformationen, die das Mainboard bereitstellt, ohne auf das System selbst zugreifen zu müssen. Die Informationen dienen Ihnen zur besseren Identifikation des Hosts, zum Beispiel über die Modell-Bezeichnung oder die Seriennummer des Mainboards. Die Informationen sind beispielsweise hilfreich, um einfach korrekte Treiber für Ihre Server und Clients zu suchen und Ihre Inventarisierung zu optimieren.
Assets im Inventar als begutachtet markieren
Im Inventar der Discovery finden Sie alle Assets, die der Watchdog durch die permanente Überwachung in Ihrem Netzwerk gefunden hat. Um das Inventar mit Informationen anzureichen, stehen Ihnen mehrere Felder zu Verfügung: Kategorisieren Sie Ihre Assets, vergeben Sie einen Alias und passende Tags, bestimmen Sie die Verantwortlichkeiten und hinterlegen Sie den Standort.
Haben Sie das Asset überprüft und entsprechend dokumentiert, können Sie das Asset jetzt als „begutachet“ markieren. Das heißt, Sie haben sich um das Asset gekümmert. Im Inventar erscheint dann ein grünes Symbol vor dem Asset. So können Sie Ihr gesamtes Inventar durcharbeiten, bis Sie alle Assets ausreichend erfasst und als überprüft markiert haben. Die neue Option hilft dabei, effektiv der Entstehung von Schatten-IT entgegenzuarbeiten.
On-Premises
Neben der Nutzung von Enginsight in der Cloud bieten wir die Installation eigener On-Premises-Instanzen an, um die Engnsight Applikation auf eigenen Servern zu betreiben. Das verbesserte white labeling und eine Kontingentverwaltung verbessern insbesondere die Nutzererfahrung für unsere Partner, die Enginsight als Managed Security Service anbieten.
White Label und Corporate Identity
Um Ihre Enginsight-Installation an Ihre eigene Corporate Identity anzupassen und ein White Labeling vorzunehmen, stehen Ihnen alle wichtigen Optionen zu Verfügung.
Sie können:
- ein eigenes Logo einbinden,
- eine eigene Akzentfarbe festlegen,
- die Login-Seite an Corporate Identity anpassen,
- einen eigenen Seitentitel und eigenes Favicon festlegen,
- eine eigene Supportadresse hinterlegen und
- die Links zu AGB, Datenschutzerklärung, Impressum und Auftragsverarbeitungsvertrag anpassen.
Auch alle E-Mails, die Ihre Enginsight-Instanz verschickt, sind in der Folge ohne direkten Bezug auf Enginsight versehen. Eine genaue Anleitung zur Umsetzung eines White Labeling erhalten Sie in der Dokumentation.
Kontingentverwaltung
Bisher standen die Lizenzkontingente im On-Premises-Bereich allen Unterorganisationen gleichermaßen zu Verfügung. Die neue Kontingentverwaltung ermöglicht das Zuweisen manueller Kontingente. Standardmäßig haben Unterorganisationen weiterhin Zugriff auf alle das gesamte Kontingent der eingespielten Lizenz.
Wollen Sie den Zugriff beschränken, aktivieren Sie die Option „Kontingente manuell festlegen“. Im Anschluss können Sie Kontingente für Server, Clients und Endpunkte freigeben. Die Kontingentverwaltung dient Ihnen auch als Übersicht, wie viele Lizenzen Ihre jeweiligen Unterorganisationen nutzen und wie viele Lizenzen insgesamt verfügbar sind.
