Bitdefender GravityZone Business Security im Test: Sicherheit für das ganze Unternehmensetz
Der “Hybrid Scan” eignet sich für Rechner mit beschränkten Ressourcen, wie beispielsweise Systeme aus der Zeit von Windows 7. In diesem Modus existieren immer noch lokale Scan Engines, diese kommen aber seltener zum Einsatz, da die Sicherheits-Software Hashes der auf dem Client vorhandenen Dateien an die Cloud sendet und von dieser, sofern die Hashes bekannt sind, Informationen darüber erhält, ob die Files infiziert wurden oder nicht. Deswegen ist es im hybriden Modus nicht erforderlich, alle Dateien lokal zu scannen und es lassen sich laut Bitdefender 30 bis 40 Prozent Ressourcen einsparen.
Der “Central Scan” wurde ursprünglich für virtuelle Maschinen (VMs) entwickelt. Hier werden keine Scan Engines eingespielt, sondern lediglich ein Treiberpaket, das einen Dateisystemtreiber enthält. Dieser Treiber macht es möglich, jede geöffnete Datei auf einem zentralen Scan-Server zu überprüfen. Das führt zu einem minimalen lokalen Ressourcen-Verbrauch. Bitdefender empfiehlt in diesem Zusammenhang, etwa 200 Maschinen von einem Scan-Server absichern zu lassen. Die genannten Server sind übrigens nicht getrennt zu lizenzieren, deswegen kann jede IT-Abteilung frei entscheiden, wie viele davon sie – beispielsweise aus Redundanzgründen – einsetzen möchte.
Wollen die IT-Verantwortlichen den Scan Modus vorgeben, so können sie dies getrennt für Computer, VMs und Amazon EC2-Instanzen machen. Für die beiden letztgenannten Systemtypen gibt es sogar die Möglichkeit, eine Fallback-Option festzulegen, die aktiv wird, wenn der eigentlich vorgegebene Modus nicht funktioniert. Wurde beispielsweise ein Central Scan vorgegeben und es besteht keine Verbindung zu einem Scan-Server, so kann das System bei entsprechender Konfiguration automatisch auf einen lokalen Scan wechseln.
Im Test legten wir drei verschiedene Pakete an. Für Windows Clients aktivierten wir die Malware-Protection, die Advanced Threat Control, den erweiterten Exploit-Schutz, die Firewall, den Netzwerkschutz, das Integrity-Monitoring und den EDR-Sensor. Bei den Windows Servern ließen wir das Firewall-Modul beiseite und für Exchange-Server verwendeten wir die gleiche Konfiguration wie für Windows Server, aber mit aktiviertem Exchange-Modul.
Nach dem Abschluss der Konfiguration der Installationsdateien besteht die Möglichkeit, entweder das komplette Installationspaket für das jeweils gewünschte Betriebssystem herunterzuladen oder lediglich eine Download-Datei zu erzeugen, die auf dem jeweiligen Endpoint ausgeführt wird und dort die Setup-Routine herunterlädt und ausführt. Im Test setzten wir beide Methoden ein, dabei kam es zu keinen Problemen.
Insgesamt spielten wir die Lösung auf einem Server unter Windows Server 2019, der als Domänen-Controller zum Einsatz kam, einer VM unter Windows Server 2019 (ebenfalls ein Domänen-Controller), einer VM unter Windows Server 2016 mit Exchange 2016 CU23 und diversen Clients unter Windows 10 und 11 ein. Diese meldeten sich kurz nach der Installation bei dem Web-Interface und erschienen ohne weiteres Zutun von unserer Seite in der dortigen Netzwerkübersicht. Bei Bedarf gibt es übrigens auch die Möglichkeit, ferngesteuerte Installationen, beispielsweise über das Active Directory, durchzuführen.
Das Aktivieren zusätzlicher Sensoren
Im letzten Schritt der Inbetriebnahme von GravityZone, aktivierten wir noch die genannten beiden Zusatzsensoren, um weitere Informationen über unsere Umgebung einbinden zu können. Zum einen verwendeten wir den Active-Directory-Sensor, um Login-Daten von den Rechnern im Netz zu erfassen, zum anderen nutzten wir den Netzwerk-Sensor, um die Datenübertragungen zwischen den Systemen im Auge zu behalten.
Um den Active-Directory-Sensor zu aktivieren, muss der zuständige Mitarbeiter nach “Konfiguration / Sensorverwaltung” wechseln und den genannten Sensor selektieren. Danach weist das System ihn darauf hin, dass die Endpoint Security Tools auf allen Domänencontrollern in der zu überwachenden Domäne laufen müssen und dass es erforderlich ist, die Gruppenrichtlinien so anzupassen, dass alle Anmeldungsereignisse überprüft werden. Wie das genau funktioniert, wird im Detail in der Dokumentation beschrieben, so dass wir an dieser Stelle nicht weiter darauf eingehen müssen. Anschließend wählen die Administratoren nur noch die Domäne mit den Servern aus, danach geht der Sensor in Betrieb.
Der bereits beschriebene Netzwerksensor sammelt auch Informationen von Systemen, die nicht von GravityZone verwaltet werden, wie Handys oder Druckern. Es lässt sich dann beispielsweise feststellen, von welcher IP-Adresse aus eine Malware ins Netz gelangen konnte. Im Test verwendeten wir eine VM für Vmware, die wir auf einem ESXi-Hypervisor in der Version 8.0a importierten. Dabei traten keine Probleme auf. Bei Bedarf steht auch eine Hyper-V-Version des Sensors zur Verfügung.
Um die Verbindung des Sensors zur Cloud herzustellen, müssen sich die Verantwortlichen nach dem Hochfahren des Systems lediglich mit den Standard-Credentials „root/sve“ auf der Console der VM anmelden und das Passwort ändern. Danach können sie das Skript „/opt/bitdefender/bin/sva_setup.sh“ aufrufen, die Netzwerk- und Proxy-Konfiguration durchführen und auswählen, mit welcher Cloud-Instanz von Gravity-Zone sich der Sensor verbinden soll. Danach ist es nur noch erforderlich, einen „Company hash“ einzutragen, der ich in der Lizenzübersicht des GravityZone-Web-Interfaces findet. Dann nimmt die VM die Verbindung zur Cloud auf und erscheint in der Übersicht der vorhandenen Komponenten. Im Test ergaben sich auch dabei keinerlei Schwierigkeiten. Die VM setzt übrigens auf Ubuntu-Linux 20.04.5 LTS auf.
Die Arbeit im laufenden Betrieb
Nachdem wir die Endpoint Security Tools auf allen unseren Testrechnern installiert und die Zusatzsensoren in Betrieb genommen hatten, erstellten wir zunächst einmal eine Richtlinie für GravityZone. Dieser Schritt ist nicht unbedingt erforderlich, da die Lösung bereits mit einer Standardrichtlinie mit empfohlenen Einstellungen kommt, wir wollten uns aber im Detail mit dem Leistungsumfang des Produkts auseinandersetzen. Dabei legten wir unter anderem fest, wie oft die Lösung nach Updates suchen sollte, ob eine Überprüfung von USB-Speichergeräten und optischen Medien gewünscht war und wie die Regeln für die Firewall aussahen. Darüber hinaus sind die Administratoren bei der Richtlinienkonfiguration auch dazu in der Lage festzulegen, welche Dateien in Scan-Vorgänge eingebunden werden, ob der Netzwerkschutz HTTPS- und RDP-Übertragungen überwacht und wie Patch Management, Verschlüsselung und Integrity Monitoring arbeiten. Sobald eine Richtlinie fertig konfiguriert wurde, lässt sie sich unter “Netzwerk” einem oder mehreren Geräten zuweisen.
Interessant ist in diesem Zusammenhang noch die Funktion “Ransomware Mitigation”, die sich bei den Antimalware-Einstellungen der Richtlinienkonfiguration findet und die in der Standardrichtlinie nicht aktiviert wurde. Diese verhindert Datenverluste durch Ransomware auch dann, wenn die betroffene Malware nicht erkannt wurde. Das funktioniert folgendermaßen: Das System erkennt laufende Verschlüsselungsvorgänge und legt bei suspekten Aktionen automatisch Backup-Kopien von den verschlüsselten Dateien an. Verschlüsselungsvorgänge von legitimen Anwendungen werden dabei nicht beeinträchtigt. Stuft Bitdefender den Vorgang aber als suspekt ein, so blockiert die Lösung die Aktion automatisch nach 20 bis 30 Dateien. Diese lassen sich dann aus dem Backup wieder herstellen.
Nachdem in unserem Netz der erste Scan-Vorgang durchgelaufen war und GravityZone die oben genannten Probleme gefunden und beseitigt hatte, schauten wir uns zunächst einmal im Detail an, was die Bitdefender-Lösung zu bemängeln hatte und welche Maßnahmen ergriffen wurden. Dazu wechselten wir nach “Vorfälle”. Dort gibt es insgesamt drei Reiter. Unter “Gefundene Bedrohungen” sortiert Bitdefender alle Malware-Funde ein. Hierbei ist sich die Lösung sicher, dass es sich wirklich um Malware handelt. Diese Vorfälle können die zuständigen Mitarbeiter zu Analysezwecken unter die Lupe nehmen, sie wurden aber von der Security-Lösung bereits abgeschlossen, so dass keine Gefahr mehr von ihnen ausgeht. Hier sind also von Seiten der Administratoren keine Aktionen erforderlich.
Die Darstellung der Sicherheitsvorfälle hilft bei der Analyse
Interessant ist aber die Art und Weise, wie die einzelnen Vorfälle dargestellt werden. Es gibt – wie erwähnt – sowohl eine grafische Darstellung, die in Diagrammform zeigt, was genau in welcher Reihenfolge ablief, als auch eine Ereignisanzeige in Listenform. Nehmen wir an dieser Stelle als Beispiel einen Virenfund auf dem Testsystem “PC08”. Hier wurde der Prozess “winlogon.exe” als Ursprung des Prozesses erkannt und der Prozess “userinit.exe” als beteiligt markiert. Der nächste Prozess, der mit der Aktion zu tun hatte, war “explorer.exe”. Dieser Prozess interagierte mit einer ganzen Zahl anderer Prozesse, von denen die meisten unproblematisch waren, wie “prtgdesktop.exe”, “nextcloud.exe”, oder auch “onedrive.exe”. Diese Prozesse sind dann auch in dem Diagramm grau oder gelb markiert. Gelb bedeutet lediglich, dass sie als verdächtig markiert wurden, da sie sich in einem verdächtigen Prozessbaum befinden. Blau werden übrigens Einträge gekennzeichnet, die das System für wichtig hält.
