Microsoft versorgt Windows 7 und XP nicht mehr mit Sicherheitsupdates. Trotzdem sind diese noch auf vielen Computern und auch auf eingebetteten Systemen aktiv. Kaspersky Embedded Systems Security adressiert den sicheren Betrieb und Schutz solcher Systeme.
Mit seinen frei verfügbaren Statistiken informiert der Dienst Statcounter nicht nur über die Marktanteile von Browsern, sondern auch über die Nutzung von Betriebssystemen. Ein Blick auf die Verteilung der verschiedenen Windows-Versionen offenbart Dramatisches: Mitte 2021 sind demnach weltweit noch mehr als 15 Prozent aller Windows-Clients mit Windows 7 unterwegs, während Windows XP noch 0,58 Prozent ausmacht. Bei aller Unschärfe, mit der solche Zahlen behaftet sind, bedeuten sie doch, dass global noch Millionen Computer mit Betriebssystemen bestückt sind, für die ihr Hersteller schon lange keine Sicherheitsupdates mehr ausliefert. Eine Betrachtung des deutschen Markts verschiebt Anteile deutlich von Windows 7 zu 10, doch auch hier ist XP weiterhin mit 0,55 Prozent vertreten und somit noch auf tausenden von Systemen aktiv.
Problemfall Embedded Systems
Die Gründe hierfür sind vielfältig: Wo ein älteres Windows-System in Verbindung mit spezieller Hardware zum Einsatz kommt, etwa als Leitrechner für eine industrielle Anlage, scheitert ein Wechsel auf Windows 10 oftmals an fehlender Kompatibilität und Innovationszyklen solcher Anlagen, die in Jahrzehnten bemessen sind.
Gleiches gilt für die Embedded-Varianten von Windows XP, 7 sowie 8.x. Diese treiben diverse Systeme an, die auf den ersten Blick nicht als Computer im herkömmlichen Sinn zu erkennen sind, unter der Haube aber auf der x86-Plattform aufsetzen. Das betrifft Kassen ebenso wie Geldautomaten, Laborgeräte und zahlreiche weitere Anwendungsfälle des geschäftlichen Alltags. Solche Geräte stattet in der Regel ihr Hersteller als Erstausrüster ab Werk mit einem Betriebssystem aus.
Mit seinen frei verfügbaren Statistiken informiert der Dienst Statcounter nicht nur über die Marktanteile von Browsern, sondern auch über die Nutzung von Betriebssystemen. Ein Blick auf die Verteilung der verschiedenen Windows-Versionen offenbart Dramatisches: Mitte 2021 sind demnach weltweit noch mehr als 15 Prozent aller Windows-Clients mit Windows 7 unterwegs, während Windows XP noch 0,58 Prozent ausmacht. Bei aller Unschärfe, mit der solche Zahlen behaftet sind, bedeuten sie doch, dass global noch Millionen Computer mit Betriebssystemen bestückt sind, für die ihr Hersteller schon lange keine Sicherheitsupdates mehr ausliefert. Eine Betrachtung des deutschen Markts verschiebt Anteile deutlich von Windows 7 zu 10, doch auch hier ist XP weiterhin mit 0,55 Prozent vertreten und somit noch auf tausenden von Systemen aktiv.
Problemfall Embedded Systems
Die Gründe hierfür sind vielfältig: Wo ein älteres Windows-System in Verbindung mit spezieller Hardware zum Einsatz kommt, etwa als Leitrechner für eine industrielle Anlage, scheitert ein Wechsel auf Windows 10 oftmals an fehlender Kompatibilität und Innovationszyklen solcher Anlagen, die in Jahrzehnten bemessen sind.
Gleiches gilt für die Embedded-Varianten von Windows XP, 7 sowie 8.x. Diese treiben diverse Systeme an, die auf den ersten Blick nicht als Computer im herkömmlichen Sinn zu erkennen sind, unter der Haube aber auf der x86-Plattform aufsetzen. Das betrifft Kassen ebenso wie Geldautomaten, Laborgeräte und zahlreiche weitere Anwendungsfälle des geschäftlichen Alltags. Solche Geräte stattet in der Regel ihr Hersteller als Erstausrüster ab Werk mit einem Betriebssystem aus.
Windows XP Embedded und seine Nachfahren sind entsprechend nicht in Form von generischen ISO-Abbildern in Umlauf gelangt, sondern als modulare Baukästen. Hersteller konnten so genau die für ihren Anwendungsfall passenden Elemente auswählen und ein Windows-Betriebssystem auch für spartanische Hardwareausstattungen maßschneidern. Ein Upgrade ist in den wenigsten Fällen direkt möglich und mit einem Austausch des Systems verbunden.
Umfassender Schutz für veraltete Clients
Hier setzt die Kaspersky Embedded Systems Security (KESS) an. Die Lösung unterstützt ausdrücklich auch ältere Client-Betriebssysteme für die x86/x64-Plattform ab Windows XP Professional SP2 aufwärts. Neben den herkömmlichen Endgeräten kümmert sich KESS zudem um die exotischeren Varianten Windows XP Embedded, Windows Embedded POSReady 2009 sowie diverse Varianten von Windows Embedded 7 und 8.x. Den Embedded-Ausgaben folgte "Windows 10 IoT Enterprise" für x86/x64-Systeme, das sich ebenfalls auf der Kompatibilitätsliste von KESS findet. Windows 10 IoT Enterprise ist allerdings nicht zu verwechseln mit "Windows 10 IoT Mobile Enterprise" und "Windows IoT Core", die sich beide mit ARM-Prozessoren, jedoch nicht mit KESS vertragen.
Im Vergleich zur Kaspersky Endpoint Security, dem Schutz für aktuelle Ausgaben von Windows 10, begnügt sich KESS mit leistungsschwacher Hardware und läuft auch auf Systemen ab lediglich 512 MByte RAM oder mit eingeschränkter Funktionalität sogar weniger. KESS verteidigt Clients gegen Datei- sowie Netzwerk-basierte Bedrohungen. Die Software setzt dazu auf klassische Malware-Signaturen, Heuristiken sowie maschinelles Lernen, um auch bislang unbekannte Angriffe anhand typischer Ansatzpunkte für Exploits zu erkennen. Dazu nutzt die Software auf Wunsch auch Informationen aus dem Kaspersky Security Network (KSN), der Cloudinfrastruktur des Herstellers. KESS wacht weiterhin darüber, dass die Win-dows-eigene Firewall aktiv und möglichst restriktiv konfiguriert ist.
Zum Funktionsumfang gehört die Kontrolle von Applikationen, die analog zu Microsofts Software Restriction Policies und AppLocker die Ausführung von Anwendungen einschränkt, sowie eine Kontrolle externer Geräte, die Datenabfluss oder eine Malware-Infektion über Wechseldatenträger verhindert. Anders als die Kaspersky Endpoint Security für neuere Clients verfügt KESS nicht über einen Firmware-Scanner und muss auch auf Funktionen zur Abwehr von Bedrohungen durch E-Mails sowie die Kontrolle von Webressourcen verzichten. Für E-Mails und Web-Browsing sollten veraltete Clients aber ohnehin nicht mehr zum Einsatz kommen.
Kaspersky Embedded Systems Security 3.0
Produkt
Software zur Absicherung von eingebetteten Systemen und älteren Windows-Versionen
Für eine Umgebung mit 500 zu verwaltenden Computern kostet KESS 3.0 22 Euro pro Jahr und Client. Individuelle Projektpreise können abweichen und sind auf Anfrage erhältlich.
Systemanforderungen
Unterstützte Clients: Microsoft Windows ab XP Professional SP2 aufwärts sowie diverse Windows-Embedded- und -IoT-Varianten.
Managementserver: Microsoft Windows ab 7 Professional SP1, Windows Server ab 2008 R2 SP1; Microsoft SQL Server ab 2012 Express, MySQL 5.7 oder MariaDB-Server 10.3
Der KESS-Client und die Konsole zu seiner Konfiguration eignen sich zur eigenständigen Installation auf einem zu schützenden Endpunkt. Alternativ kümmert sich das Kaspersky Security Center (KSC) um die zentrale Installation und Verwaltung mehrerer Clients. Das KSC läuft auf einem Windows-Client oder -Server und benötigt eine Datenbank. Dabei kann es sich um MySQL, MariaDB Server oder Microsoft SQL Server handeln. In letzterem Fall eignet sich auch die kostenfreie Express-Variante, die laut Kaspersky bis zu 3000 Endpunkte verwaltet. Ausgewachsene Editionen des SQL Servers versorgen je nach Hardware-Ausstattung bis zu 100.000 Clients. Im Falle größerer oder geografisch verteilter Infrastruktur skalieren mehrere KSC-Installationen mit separaten Datenbanken hierarchisch, wobei ein übergeordneter KSC-Server als zentrale Instanz fungiert. Der Hersteller lizenziert KESS pro zu verwaltendem Client. Für die Verwendung des KSC fallen darüber hinaus keine weiteren Kosten an.
Auch wenn KESS das Schutzniveau veralteter Clients deutlich anhebt, sollten diese trotzdem mit möglichst wenig Kontakt zu anderen Systemen und zur Außenwelt in einem separaten Netzbereich abgeschottet laufen. Hierbei hilft das KSC, indem es als Proxy und Cache für Software- und Signaturupdates fungiert sowie die Anbindung ans KSN herstellt, sodass die Clients selbst keinen direkten Kontakt zum Internet benötigen. Weiterhin kümmert sich das KSC um die Integration mit einem übergeordneten Security Information and Event Management (SIEM).
KSC schnell installiert
Das KSC besteht aus einer zentralen Managementoberfläche auf Basis der Microsoft Management Console (MMC) mit einem Serverdienst und Agenten auf den Clients. Parallel dazu bietet der Hersteller ein HTML5-Webfrontend an, das einen schlanken Webserver auf Basis von Node.js mitbringt.
Als Basis für das KSC hatten wir in unserer Testumgebung einen Windows Server 2019 mit Standard-Installation des Microsoft SQL Server 2017 in der Express Edition vorbereitet und zudem Maschinen mit Windows XP Professional SP3 sowie Windows 7 SP1 reanimiert. Von der Webseite des Herstellers luden wir das vollständige Installationspaket für das KSC 13 herunter, starteten die Setup-Routine und entschieden uns für eine benutzerdefinierte Installation. In deren Verlauf konnten wir wählen, ob wir beide Konsolen – MMC und HTML5 – oder nur eine von beiden einrichten wollten.
Der Assistent fragte weiterhin nach der Größe unserer Umgebung. Diese Auswahl beeinflusst die Installationseinstellungen und die Darstellung der Programmoberfläche. In kleineren Umgebungen blendet die Managementkonsole Einstellungen, die für sekundäre und virtuelle Administrationsserver relevant sind, aus. Dies gilt zusätzlich für den Abschnitt "Sicherheit" im Eigenschaftenfenster des Administrationsservers und für die Administrationsgruppen. Für den Zugriff auf sämtliche Optionen wählten wir ein typisches Setup für 1001 bis 5000 Geräte im Netzwerk. Die Installation erkannte unsere SQL-Server-Instanz selbsttätig. Der Assistent erzeugte automatisch einen Funktionsbenutzer für den Dienst und eine Dateifreigabe zur Bereitstellung von Installationspaketen und Updates für die Clients.
Standardmäßig nutzt das KSC serverseitig den TCP-Port 14000 für eine unverschlüsselte Kommunikation mit den Agenten sowie den TCP-Port 13000 für SSL-gesicherte Verbindungen. Für Rückmeldungen über sicherheitsrelevante Ereignisse kommt bei den Agenten clientseitig der UDP-Port 15000 zum Einsatz. Hinzu kommen weitere in der Onlinehilfe des KSC dokumentierte Ports unter anderem zur Verteilung von Software und der Kommunikation mit dem KSN-Proxyserver. Abschließend startete automatisch eine separate Installation für die Webkonsole, die den TCP-Port 8080 in Verbindung mit einem selbstsignierten Zertifikat verwendet. Alternativ hätten wir bereits während der Installation ein eigenes Zertifikat einbinden können.
Einfache Organisation in Gruppen
Wir konfigurierten unsere Infrastruktur zunächst mittels der MMC-basierten Oberfläche. Diese erwies sich als übersichtlich gestaltet und gibt Windows-Administratoren keine Rätsel auf. In einer links angeordneten Baumstruktur fanden wir die Konfiguration in logische Bereiche unterteilt. Unter dem Punkt "Verwaltete Geräte" konnten wir eine hierarchische Ordnerstruktur aufbauen, um unsere Clients etwa nach geografischen oder logischen Aspekten zu sortieren. Hier legten wir Unterordner für Systeme unter Windows XP und Windows 7 an.
Pro Ordner zeigt das Hauptfenster drei Registerkarten, eine für sämtliche Geräte im Ordner, eine für Aufgaben und eine weitere für Richtlinien. Diese drei Bereiche eignen sich für vollautomatischen Rollout und Konfiguration von KESS (Bild 1). So kümmern sich Aufgaben um die Remote-Installation von Programmen und Richtlinien konfigurieren diese. Ähnlich den Gruppenrichtlinien im Active Directory erben Unterordner Aufgaben und Richtlinien von übergeordneten Instanzen, solange wir die Vererbung nicht explizit unterbrechen.
Bild 1: Das Kaspersky Security Center verteilt, aktualisiert und konfiguriert die nötigen Clientkomponenten zentral.
Clients erfassen und einsortieren
Im ersten Schritt fügten wir im Knoten "Lizenzen für Kaspersky-Software" die Datei der Testlizenz ein, die wir vorab vom Hersteller erhalten hatten. Unter "Erweitert / Gerätesuche" konnten wir unsere Clients ermitteln. Das KSC liest diese aus dem Active Directory und findet zudem Windows-Clients in Arbeitsgruppen, die nicht der AD-Domäne angehören. Alternativ dazu konnten wir benutzerdefinierte IP-Bereiche scannen.
Bei der Suche nach Clients durften wir Regeln für das Verschieben von Geräten in die Administrationsgruppen festlegen. Das zugehörige Regelwerk entfaltet seine Wirkung allerdings erst vollends, sobald der Kaspersky-Managementagent auf den Clients läuft. Ohne Agenten sortiert das KSC Clients etwa anhand eines Teilstrings im Namen, des IP-Bereichs oder ihrer Organisationseinheit im AD in Gruppen ein. Sobald der Agent vorhanden ist, kann eine Regel auch auf die Version des Betriebssystems und Zertifikate zugreifen. Weiterhin darf als Kriterium dienen, ob ein Client als VM in einer lokalen Virtualisierungsinfrastruktur oder in einem Cloudsegment eines der großen Hyperscaler Amazon, Google oder Microsoft läuft. Aktuell noch ohne Agenten, gruppierten wir unsere Clients zunächst anhand ihres Namens und begaben uns dann an die Verteilung sowie Konfiguration der Software.
Problemlose Verteilung des Agenten
Im Bereich "Erweitert / Remote-Installation / Installationspakete" brachte das KSC ein Paket für den Administrationsagenten bereits mit. Die Installationsdateien für KESS 3.0 hatten wir von der Webseite des Herstellers heruntergeladen und lokal auf unserem KSC-Server extrahiert. Daraufhin erzeugten wir in der Konsole ein neues Installationspaket. Hierzu wählten wir die Option "Installationspaket für ein Programm von Kaspersky erstellen" und fügten die Datei "ess.kud" aus dem entpackten Download hinzu. Dieses Paket kümmerte sich um die Installation der eigentlichen Scan-Komponente und des Plug-ins für deren Remote-Administration. In den Eigenschaften des Pakets wählten wir den kompletten Funktionsumfang mitsamt der Firewall-Verwaltung.
Zusätzlich wollten wir die optionale lokale Verwaltungskonsole für KESS an die Clients verteilen. Die lieferte Kaspersky allerdings nicht als Konfigurationsdatei im KUD-Format, sondern als generische "setup.exe" mit. Da das KSC auch beliebige ausführbare Dateien integriert und wir die passenden Parameter zur unbeaufsichtigten Installation in der Onlinehilfe fanden, konnten wir die Konsole ohne Probleme in ein Paket schnüren.
Nun erzeugten wir im Bereich "Verwaltete Geräte" passende Aufgaben vom Typ "Remote-Installation eines Programms". Im ersten Schritt wollten wir den Agenten ausbringen, was Kaspersky per RPC erledigte. Entsprechend mussten wir dazu einmalig einen Account mit Admin-Rechten auf dem Ziel hinterlegen. Im Fall unseres Windows-7-Clients funktionierte die Remote-Installation komplikationslos. Nur das XP-System wollte den Agenten im ersten Anlauf nicht installieren, was aber nicht Kaspersky anzulasten war. Die XP-Installation war schlichtweg so alt, dass sie mangels Unterstützung für neuere Versionen des SMB-Protokolls das Installationspaket nicht abrufen konnte. Als Workaround behalfen wir uns damit, im KSC ein autonomes Installationspaket zu erstellen. Der Server veröffentlichte das Paket per HTTP, sodass wir es auf dem Client manuell laden und installieren konnten.
Flexible Remote-Installation
Sobald der Agent auf unseren Clients vorhanden war, mussten wir zur Installation der weiteren Pakete kein separates Benutzerkonto mehr hinterlegen. Nachdem unsere Clients auch über KESS sowie deren lokale Verwaltungskonsole verfügten, konfigurierten wir zu guter Letzt noch eine regelmäßige Aufgabe zum Download von Updates auf den KSC-Server sowie Update-Aufgaben für die Programm-Datenbanken und -Module auf den Clients.
Dabei durften wir wählen, ob die Clients die Updates von unserem lokalen KSC-Administrationsserver, vom Kaspersky-Update-Server im Internet oder von einer anderen Netzwerkressource beziehen sollen. Beim Zeitplan für die Verteilung zeigte sich das KSC flexibel. Der Server verteilt Updates wahlweise, sobald er sie heruntergeladen hat, alternativ in definierten Intervallen von Stunden, Tagen oder wöchentlich.
Echtzeitschutz mit Unterstützung aus der Cloud
Für unsere Verwaltungsgruppen erstellten wir sodann eine Richtlinie zur Konfiguration von KESS. Dabei unterstützte uns ein Assistent mit sinnvollen Voreinstellungen, wobei ein Vorhängeschloss signalisierte, dass die Richtlinie eine bestimmte Option sperrt und diese verpflichtend für den Client umsetzt. Wir akzeptierten zunächst die Grundkonfiguration und legten anschließend in den Eigenschaften der neuen Richtlinie die Details fest.
Die zentralen Einstellungen für den Betrieb von KESS fanden wir im Bereich "Echtzeitschutz für Computer". Der Assistent hatte hier den "Echtzeitschutz für Dateien" beim Öffnen und Ändern für den gesamten Arbeitsplatz aktiviert, also für lokale Festplatten, Wechseldatenträger sowie auch die Netzwerkumgebung. Wir beließen es bei den Voreinstellungen der mittleren von drei Stufen für die heuristische Analyse sowie der Nutzung des KSN.
Dazu mussten wir allerdings im Bereich "Verwendung des KSN" der Datenschutzerklärung zustimmen, da die KSN-Datenverarbeitung in der Cloud stattfindet. Dabei durften wir deaktivieren, dass das KSC Informationen über untersuchte Dateien sowie Nutzungsstatistiken an den Hersteller übermittelt. In den Einstellungen konnten wir zudem wählen, ob KESS Objekte, die laut KSN nicht vertrauenswürdig sind, nur protokollieren oder komplett löschen soll. Letzteres war die Voreinstellung. Ebenso hatte der Assistent aktiviert, dass das KSC als Proxy zum KSN agiert und die Clients somit keinen direkten Internetzugang benötigen.
Zuverlässiger Schutz gegen typische Exploits
Im Bereich der "Exploit-Prävention" standen wir ebenfalls vor der Wahl, ob KESS Prozesse beim Versuch der Ausnutzung einer Schwachstelle sofort beendet oder das Ereignis nur protokolliert. Wir beließen es beim Standard, im Falle eines Exploits den Prozess zu terminieren. Auf der Registerkarte "Geschützte Prozesse" fanden wir eine vorgefertigte Liste von Anwendungen, die KESS typischerweise schützt, darunter verbreitete Software, wie Adobe Reader, Mozilla Firefox oder Oracle Java. Hier konnten wir weitere Prozesse ergänzen und pro Eintrag definieren, welche Verfahren zur Exploit-Prävention zum Einsatz kommen sollen (Bild 2).
Bild 2: KESS erkennt typische Exploit-Techniken und unterbindet diese, bevor Schaden entsteht.
KESS erkennt die typischen Angriffsvektoren, wie etwa das Ausnutzen von Buffer Overflows oder Heapspray, und wehrt diese ab. Davon konnten wir uns auf unseren Clients mittels der EICAR-Anti-Virus-Testdatei überzeugen. Weiterhin verwendeten wir mehrere der ungefährlichen WICAR-Payloads zur Simulation von Exploits. In allen Fällen schritt KESS wie erwartet ein, verhinderte die Ausführung und präsentierte stattdessen eine Warnmeldung.
Umfangreiche Protokollierung
Im KSC konnten wir diese verhinderte Ausführung auf oberster Ebene des Administrationsservers auf der Registerkarte "Ereignisse" nachvollziehen. Kaspersky sammelt hier umfangreiche Protokolldaten zum Zustand des Servers und aller Clients. Die Ereignisse ließen sich flexibel durchsuchen und filtern sowie – zurück in unserer Richtlinie im Abschnitt "Konfiguration von Ereignissen" – detailliert regeln. Dort legten wir fest, welche Informationen protokolliert und wie lange diese aufbewahrt werden sollen. Standardmäßig bewahrt das KSC Ereignisse 30 Tage auf, was sich jedoch granular pro Event anpassen lässt. Weiterhin durften wir pro Ereignis bestimmen, ob das KSC die Informationen per Syslog an ein SIEM-System exportieren, per E-Mail, SMS oder SNMP weiterleiten sowie auch eine bestimmte Datei oder ein benutzerdefiniertes Skript ausführen soll (Bild 3).
Bild 3: Das KSC sammelt Ereignisse und informiert auf diversen Kanälen darüber.
All diese Optionen definieren, wie der zentrale Administrationsserver mit Ereignissen verfahren soll. Zusätzlich konnten wir im Konfigurationsbereich "Berichte und Benachrichtigungen" einstellen, dass Clients ohne Umweg über das KSC direkt über Ereignisse informieren. Das ist praktisch für alleinstehende Systeme ohne dauerhaften Kontakt zum KSC.
Kontrolle über Dateien und Geräte
Die weiteren Funktionen von KESS konfigurierten wir wiederum über unsere Richtlinie. Neben dem Echtzeitschutz ist hier insbesondere der Bereich "Überwachung der Desktop-Aktivitäten" von
Interesse. Hier konnten wir, unterteilt in zwei Unterbereiche, sowohl Starts von ausführbaren Dateien als auch die Verwendung von Geräten kontrollieren. Einmal gestartet, protokollieren die entsprechenden Aufgaben im Modus "Nur Statistik" zunächst hinsichtlich ausführbarer Dateien und Geräte. Im Modus "Aktiv" verhindern sie jegliche Zugriffe, die wir anschließend mittels individueller Regellisten wieder freigeben konnten.
Ausführbare Dateien erlaubt KESS wahlweise anhand eines digitalen Zertifikats, SHA256-Hashes oder des Pfads, wobei Letzterer lediglich einen schwachen Schutz darstellt und nicht die Manipulation der Datei verhindert. Wesentlich sicherer ist es, erwünschte Dateien mittels Hashes zu identifizieren. Beim Ermitteln der nötigen Informationen half uns das KSC. Wir konfigurierten dazu eine Aufgabe vom Typ "Automatisches Erstellen von Regeln für die Kontrolle des Programmstarts". Dieser übergaben wir einen oder mehrere Zielpfade auf unseren Clients, in denen KESS nach ausführbaren Dateien, MSI-Paketen und Skripten suchte und Informationen zu den gefundenen Dateien – soweit vorhanden deren digitale Signatur, alternativ Hash-Wert oder Pfad – pro Client in eine XML-Datei exportierte. Die konnten wir dann innerhalb unserer Richtlinie im KSC in das Regelwerk importieren und so gezielt Dateien zur Ausführung freigeben. Die Handhabung der Gerätekontrolle funktionierte analog dazu.
In der Sektion "Netzwerküberwachung" sorgte die "Firewall-Verwaltung" dafür, dass KESS auf den Endpunkten die Windows-eigene Firewall aktiviert und auf Wunsch zentral mit Regeln versorgt. Im Bereich der "System-Diagnose" prüft die "Überwachung der Datei-Integrität" definierte Ordner oder einzelne Dateien anhand von Hash-Werten auf unerwünschte Veränderungen. Die "Protokollanalyse" wacht über das Ereignisprotokoll und schlägt beim Auftreten wählbarer Event-IDs Alarm. Kaspersky bringt dazu vorgefertigte Regeln mit, die auf verdächtige Aktionen wie beispielsweise eine Brute-Force-Attacke schließen lassen. Zusätzlich durften wir selbst beliebige Events zur Überwachung vorsehen.
So urteilt IT-Administrator
Bewertung
Unterstützung für alte Systeme
8
Exploit-Abwehr
7
Datei- und Gerätekontrolle
8
Verwaltung mittels KSC
8
Ereignisprotokollierung
7
Dieses Produkt eignet sich
optimal
für Unternehmen, die ältere Windows-Clients oder eingebettete Systeme weiterbetreiben müssen.
bedingt
für verteilte Clients ohne Möglichkeit zur zentralen Verwaltung, da das KSC seine Stärken dann nicht ausspielen kann.
nicht
für Unternehmen, die ausschließlich aktuelle von Microsoft unterstützte Windows-Systeme betreiben.
Fazit
KESS bringt aktuelle Werkzeuge zur Abwehr von Malware und Exploits auf alte Systeme, die ansonsten weitestgehend schutzlos wären. Dabei konnten neben dem klassischen Virenscanner und der Erkennung von Exploit-Techniken auch die erweiterten Funktionen überzeugen, insbesondere die Datei- und Gerätekontrolle. Das KSC, dessen umfangreiche Möglichkeiten wir nur oberflächlich beschreiben konnten, vereinfacht die zentrale Verwaltung sehr. Doch all dies darf nicht zu Leichtmut verleiten – alte Clients ohne Updates bleiben ein Risiko und sollten schnellstmöglich ausgetauscht werden. Bis dahin erhöht KESS jedoch die Sicherheit deutlich.