Allgemeine Fragen und Antworten zum Thema Sicherheit

Angesichts der jüngsten Nachrichten über einen weiteren gemeldeten Zero-Day-Exploit und der damit einhergehenden Sicherheitsdiskussionen wollen wir uns mit dem Thema Sicherheitsprüfung (Security Audit) befassen und der Frage nachgehen, wie Enterprise Alert konfiguriert werden kann, um potenzielle Risiken für die Sicherheit des Systems zu vermeiden oder zumindest zu minimieren.

Lassen Sie uns zunächst klären, was wir unter einer Sicherheitsprüfung verstehen. Eine Sicherheitsprüfung ist eine systematische Bewertung der gesamten Enterprise Alert-Umgebung, einschließlich des Betriebssystems des Host-Servers, der Anwendung und der peripheren Komponenten, mit denen sie verbunden ist. Das Ziel einer solchen Prüfung kann niemals sein, einen Server unverwundbar gegen alle Angriffe zu machen. Das einzige realistische Ziel kann nur darin bestehen, Angriffe so schwer wie möglich zu machen und die daraus resultierenden Auswirkungen so weit wie möglich zu reduzieren.

Wir von Derdack, als Anbieter von Enterprise Alert, können eigentlich nur Details zu unserer Anwendung liefern. Das Server Betriebssystem und die Netzwerkkomponente werden üblicherweise von den zuständigen Ingenieuren unserer Kunden gehandhabt, denn nur sie kennen die Besonderheiten der Anforderungen und Probleme ihrer Unternehmen. Wir werden im weiteren Verlauf auf die Abschnitte eingehen, die Enterprise Alert direkt betreffen.

Server OS

In diesem Abschnitt möchte ich kurz einige Punkte ansprechen, die für den reibungslosen Betrieb von Enterprise Alert unerlässlich sind. Bei den üblichen Problemen, die uns gemeldet werden, handelt es sich um kleine Probleme, die technisch gesehen in der Verantwortung des Systemeigentürmers liegen, möchte sie aber dennoch hier kurz ansprechen. Auf die weiteren Systemvariablen werde ich aus den oben genannten Gründen nicht eingehen.

Kann der IIS Startbildschirm (splash screen) deaktiviert werden?
Standardmäßig ist der IIS so konfiguriert, dass der IIS-Startbildschirm angezeigt wird. Dies wird häufig als Problem angesehen, da potenzielle Angreifer daraus schließen könnten, mit welcher Art von Betriebssystem sie es zu tun haben. Dies kann in den IIS-Einstellungen für die Standard-Website einfach deaktiviert werden.

Kann Enterprise Alert so konfiguriert werden, dass kein lokaler System Account verwendet wird?
Standardmäßig werden die Konten NT AUTHORITY\SYSTEM (für alle Dienste) und NT AUTHORITY\NETWORK SERVICE (für den IIS ApplicationPool) als Ausführungskonten festgelegt. Wir empfehlen die Verwendung eines AD-Kontos anstelle der Standardkonten direkt im Rahmen des Erweiterten Setups von Enterprise Alert. Wenn die Anwendung bereits in Betrieb ist, können Sie die jeweiligen Konten ändern, ohne die Up Time des Systems wesentlich zu beeinträchtigen.

Muss der RunAsAccount ein lokaler Administrator mit LogOn Rechten sein?
Enterprise Alert erfordert die Benutzerrolle des lokalen Administrators oder gleichwertige Berechtigungen, um alle Funktionen problemlos bereitzustellen. Dies könnte bei einer Sicherheitsprüfung als problematisch eingestuft werden, da sich dadurch zusätzliche Benutzer bei diesem Server anmelden könnten. In der Regel kann dieses Problem durch die Verweigerung der Anmeldeberechtigung für diesen speziellen Benutzer beseitigt werden.

Netzwerk

In diesem Abschnitt möchte ich auf Punkte eingehen, die bei der Sicherheitsprüfung im Zusammenhang mit dem Netzwerk auftauchen könnten. Dazu gehört im Grunde alles, was mit der Kommunikation von Enterprise Alert mit externen Systemen zu tun hat. Technisch gesehen würde dies auch unsere Datenbankverbindungen einschließen, aber ich halte es für sinnvoller, es unter dem Abschnitt „Anwendung“ zu platzieren.

Welche TLS Versionen werden von Enterprise Alert unterstützt?
Enterprise Alerts unterstützt die TLS-Versionen 1.0 bis 1.2. Die tatsächlich zur Nutzung vorgesehenen Versionen können über die Einstellungen des Betriebssystems kontrolliert und eingeschränkt werden. Enterprise Alert ist auch auf die Einführung von TLS1.3 vorbereitet abhängig von der Verfügbarkeit innerhalb des Betriebssystems.

Kann die E-Mail-Kommunikation verschlüsselt werden?
Da der E-Mail-Kanal über mehrere Einrichtungsmodi verfügt, können Sie SSL entweder für Empfangsprotokolle (POP2, IMAP) und/oder Sendeprotokolle (SMTP-Server-Relay) aktivieren. Für O365 und Exchange ist SSL als Standardeinstellung hinterlegt . Nur „SMTP Direct Delivery“ unterstützt keinen sicheren Kommunikationsmodus und sollte daher vermieden werden.

Kann die VoIP-Kommunikation verschlüsselt werden?
Die VoIP-basierte Kommunikation mit Enterprise Alert wird in vielen Fällen noch über unsichere UDP-Pakete abgewickelt, kann aber leicht auf die Verwendung von TLS umkonfiguriert werden. Diese Konfiguration ermöglicht auch eine sichere Kommunikation mit einem externen VoIP-Anbieter, es sei denn, die Kommunikation mit einem externen Netz selbst wird als Sicherheitsrisiko betrachtet.

Ist die IM-Kommunikation mit MS Teams verschlüsselt?
Die Microsoft Teams-Integration ist standardmäßig über SSL gesichert und sollte bei einer Prüfung nicht auftauchen, es sei denn, die Kommunikation mit einem System in einem öffentlichen Netzwerk wird als Bedrohung angesehen. In diesem Fall ist Microsoft Teams keine Option, da keine lokale Alternative verfügbar ist.

Kann SMS/text-basierte Kommunikation verschlüsselt werden?
GSM-Modems können entweder über einen COM-Port an Enterprise Alert angebunden werden, was als sichere Verbindung angesehen werden kann, da kein externer Zugriff möglich ist, oder über eine Telnet-basierte Verbindung. Zum jetzigen Zeitpunkt kann die Telnet-Verbindung nicht mehr auf der Anwendungsebene gesichert werden und wird daher in einer Sicherheitsprüfung erscheinen.
Die Kommunikation mit einem SMSC-Anbieter über das SMPP- oder UCP-Protokoll kann nicht auf Anwendungsebene gesichert werden. Dies ist jedoch auf Netzwerkebene möglich und wird von SMSC-Anbietern häufig angeboten.

Ist die Kommunikation zwischen der Mobilen App und dem Enterprise Alert backend sicher?
Die Mobile App benötigt Zugang zum Enterprise Alert Backend entweder über einen öffentlichen Zugangspunkt oder über einen VPN-Tunnel (bereitgestellt über eine MDM-Lösung wie BES oder Intune) in Ihr Netzwerk. Wenn Sie ADFS oder Azure AD als Identity-Provider verwenden, stellen Sie sicher, dass sowohl die Enterprise Alert App als auch der Enterprise Alert Server Zugriff auf diese Systeme haben. Standardmäßig ist die gesamte Kommunikation SSL-verschlüsselt. Der Zugriff auf die API wird nur gewährt, wenn die Benutzeranmeldeinformationen und ein zweiter Faktor korrekt an die API übermittelt werden. Für das Senden von Push-Benachrichtigungen ist die gesamte Kommunikation standardmäßig über SSL gesichert.

Ist die Kommunikation für 2-wege Konnektoren verschlüsselt??
Alle unsere Smart-Konnektoren unterstützen die sichere Kommunikation über SSL-Verschlüsselung, so dass etwaige gefundene Probleme in dieser Richtung leicht behoben werden können, indem die URLs so umkonfiguriert werden, dass für den Zugriff auf die externen Systeme SSL-Verschlüsselung verwendet wird.

Welche Standard-APIs können verschlüsselt werden?
Die Standard-APIs wie REST, SOAP, HTTP POST/GET können über einfache SSL Verschlüsselung gesichert werden. Dies gilt auch für OPC U/A, wenn ein Server-Zertifikat bereitgestellt wird.

Welche Standard-APIs können nicht verschlüsselt werden?
Leider gibt es auch einige APIs, die in Enterprise Alert nicht gesichert werden können, wie der SMTP-Server und der SNMP-Trap-Empfänger. Wenn dies gemäß Ihren Sicherheitsrichtlinien ein zu großes Risiko darstellt, können Sie diese Schnittstellen jederzeit deaktivieren.

Anwendung

In diesem Abschnitt möchte ich auf alles eingehen, was mit der Enterprise Alert Software selbst zusammenhängt, einschließlich anwendungsspezifischer Sicherheitselemente und -probleme. So zum Beispiel die Authentifizierung und Passwortverschlüsselung für Benutzer und Konfigurationen.

Wie werden Datenbank-Verbindungsstrings in Enterprise Alert gespeichert?
Die Datenbank-Verbindungsstrings werden sowohl in der Logman.xml als auch in der web.config-Datei für das EAPortal im Klartext gespeichert. Um zu verhindern, dass Unbefugte auf die SQL-Anmeldeinformationen zugreifen können, empfehlen wir die Verwendung einer Trusted Connection anstelle einer SQL-Authentifizierung als Verbindungsmodus.

Wie werden die Passwörter für den Zugang zu den Systemen von Drittanbietern (3rd-Party-Konnektoren) gespeichert?
Alle 3rd-Party-Konnektoren speichern Passwörter als verschlüsselte Werte. Es werden keine Passwörter in Klartext gespeichert und außerhalb der Anwendung weitergegeben.

Wie werden Passwörter von Nutzern in Enterprise Alert gesichert?
Nutzerdaten werden nur in der Enterprise Alert-DB gespeichert und sind ähnlich wie andere Daten in Enterprise Alert verschlüsselt. Das Überschreiben oder Ändern des in der DB gespeicherten Schlüssels führt dazu, dass der Benutzer sich nicht mehr anmelden kann. Enterprise Alert speichert keine AD Benutzerpasswörter, wenn die Integration mit Active Directory (AD) aktiviert ist – siehe unten.

Bietet Enterprise Alert eine automatisierte Nutzerverwaltung an?
Ja. Durch die Möglichkeit der Synchronisierung von Benutzern mit einem Active Directory, bietet Enterprise Alert eine automatisierte Benutzerverwaltung. Es kann eine manuelle Synchronisation oder vollautomatische Aktualisierung der Benutzerdaten in frei einstellbaren Intervallen konfiguriert werden. Enterprise Alert synchronisiert dabei aber keine Passwörter aus dem Active Directory.

Wie können sich Nutzer in Enterprise Alert autorisieren?
Enterprise Alerts bietet Autorisierung über den eigenen Identitätsserver, SSO, ADFS und Azure AD. Alle Authentifizierungsmethoden können mit Active Directory synchronisierten Benutzern kombiniert werden. Nur für die Autorisierung durch den eingebauten Identitätsserver werden lokal gespeicherte Passwörter benötigt, die in der Enterprise Alert DB hinterlegt werden. Einzelheiten zu den verschiedenen Authentifizierungsmethoden können über das Derdack Support Team angefragt werden.

Unterstützt Enterprise Alert das Prinzip der minimalen Rechte?
Ja. Enterprise Alert bietet standardmäßig 7 verschiedene Benutzerrollen, die die häufigsten Anwendungsfälle abdecken. Sollten diese Standardrollen nicht ausreichen, bietet Enterprise Alert die Möglichkeit, Benutzerrollen zu ändern oder neue zu erstellen, dies erlaubt ihnen den Zugriff auf die Anwendung und ihre Funktionen genau zu steuern und zu beschränken. Die Möglichkeit der Erstellung und Anpassung von Benutzerrollen ist eine Zusatzfunktion und nicht in jedem Plan oder jeder Edition verfügbar.

Welche Berechtigungen benötigt die Anwendung auf die SQL-Datenbank?
Für die Einrichtung, d.h. die Erstellung der Hauptdatenbank, von Enterprise Alert sind SA auf dem SQL-Server erforderlich. Wenn dies nicht möglich ist, kann die Enterprise Alert-Datenbank manuell von einem DBA erstellt werden. Für den reibungslosen Betrieb von Enterprise Alert benötigt das Konto, entweder ein SQL-Konto (nicht empfohlen) oder ein AD-Konto, welches von den Enterprise Alert Services und ApplicationPool verwendet wird, DBowner oder gleichwertige Berechtigungen.

Gibt es eine vollständige Liste aller von Enterprise Alert verwendeten Ports?
Unser Support Team kann Ihnen entsprechende Dokumente zu den am häufigsten verwendeten Ports zur Verfügung stellen. Bitte beachten Sie, dass die verwendeten Ports je nach den Einstellungen der Anwendung eines Drittanbieters variieren können, z. B. SQL DB-Ports oder Webservices der entsprechenden Anwendung.

Zusammenfassung

Ihre Sicherheitsprüfung wird höchstwahrscheinlich viel mehr offene Punkte enthalten und viel detaillierter sein als die Fragen und Antworten in diesem Blog. Wir setzen uns gerne mit Ihnen zusammen und gehen die verschiedenen Punkte durch und geben ihnen dann genaue Lösungen an die Hand. Enterprise Alert wurde mit Blick auf Sicherheit und Zuverlässigkeit entwickelt, so dass alle gefundenen Punkte mit vertretbarem Aufwand behoben werden können.