Endpoint Detection and Response (EDR) will erfolgreiche Angriffe auf Endgeräte wie Laptops oder Smartphones bereits im Entstehen erkennen und durch kluge Gegenmaßnahmen verhindern. Mancher Admin mag sich dabei an die gute alte Antivirus-Software erinnert fühlen, doch greift dieser Vergleich zu kurz, denn EDR geht viel weiter, als durch Signaturen bestimmter Dateien Malware zu identifizieren. Das EDR-Prinzip fuß darauf, quasi den gesamten I/O eines Systems, also Netzwerk, Festplattenaktivität und alles dazwischen, minutiös aufzuzeichnen und zu analysieren. Zum Einsatz kommen viel weniger Signaturen einzelner Dateien, sondern komplexe Heuristiken. So soll es gelingen, auch andere Angriffsarten als klassische Malware-Angriffe zu identifizieren und zu unterbinden.

Doch IT-Verantwortliche wissen, dass von einer auf einem Client installierten EDR-Software ein erhebliches Risiko ausgehen kann. Denn wenn diese schlecht programmiert ist, dient sie im blödesten Fall Angreifern als Einfallstor und nicht als effektive Sperre. Manche Unternehmen sind deshalb wenig angetan von der Idee, kommerzielle EDR-Software zu nutzen, deren Quelltext nicht verfügbar ist. Hier kommt Xcitium ins Spiel, eine Firma, die manche möglicherweise noch unter dem alten Namen "Comodo Security Solutions" kennen. Deren Produkt OpenEDR kommt nicht nur mit veröffentlichtem Quelltext daher, sondern preist sich explizit auch als bestes EDR an. Neben der Analyse auf den Endgeräten findet dazu auch eine Untersuchung eingehender Daten in der Cloud auf Servern des Herstellers statt.

So sollen Admins ruhig schlafen können, doch ob die Nachtruhe wirklich ungestört bleibt, soll unser Test klären, indem wir uns die Sicherheitsfunktionen, Datenschutz und Compliance mit Hinblick auf die DSGVO, die Bedienbarkeit, das Thema Performance und die Security von OpenEDR selbst anschauen.

Damit EDR sinnvoll nutzbar ist, sind eine Reihe von verschiedenen technischen Voraussetzungen nötig. Und die haben es in sich: Sie müssen unter anderem direkt auf der Ebene des Betriebssystemkerns ansetzen, weil sie sonst nicht alle Abläufe im System mitbekommen, die potenziellen Schaden anrichten können. Diese Maxime gilt auch für OpenEDR und unter der Haube ist die Software durchaus komplex. Ihr Dreh- und Angelpunkt ist die "Core Library", also die Kernbibliothek, in der alle zentralen OpenEDR-Funktionen implementiert sind. Ihr zur Seite steht im laufenden System ein Service, der verschiedene grundlegende Dienste bietet und beispielsweise auch die Kommunikation mit der Außenwelt, also den KI-Servern von Xcitium, übernimmt (dazu später mehr).

Darüber hinaus teilen sich die zu Open-EDR gehörenden Komponenten vorrangig in zwei Gruppen auf. Eine Gruppe überwacht Systemprozesse, den Netzwerkverkehr und Veränderungen auf Dateisystemen über Schnittstellen unmittelbar über den Betriebssystem-Kernel. Die andere Gruppe schleust sich in die Kommunikation und die Arbeit einzelner Programme über eine unter Windows eingeschobene DLL-Datei ein, die umfangreiche Datenstromanalysen ermöglicht. Damit ist klar, dass sich OpenEDR ausschließlich an Setups mit Microsoft Windows richtet. Weder für macOS noch für Linux steht die Software zur Verfügung, was letztlich darauf zurückzuführen sein dürfte, dass beide Kernel fundamental anders funktionieren als jener von Windows.

Dem beschriebenen OpenEDR-Service, den seine Entwickler "EDR Agent Service" nennen, kommt eine zentrale Bedeutung zu. Sämtliche Komponenten im System, die Metrikdaten aufzeichnen und sammeln, leiten diese letztlich an den Agenten weiter. Der verfährt auf zwei verschiedene Arten und speichert die Daten lokal entweder ab, um späteren Zugriff möglich zu machen, oder er schickt sie an die Xcitium-Cloudserver zur weiteren Analyse.

Grundsätzlich wirkt die Architektur von OpenEDR vernünftig, doch gibt es ein paar Aspekte, die bereits beim Beginn der Arbeit mit der Software unangenehm auffallen. Das fängt bei der Lizenz der Software an, wo der Hersteller zwar von Open Source spricht und doch explizit verbietet, Derivate der Software zu erstellen und kommerziell zu betreiben.

Eine zentrale Anforderung an Open-Source-Software ist damit nicht erfüllt, weil zum Beispiel ein anderes Unternehmen keinen OpenEDR-Fork bauen kann, sollte ihm das ursprüngliche Feature-Set nicht ausreichen. Was wie eine eher akademische Diskussion aussieht, führt konkret zu einem Vendor-Lock-in, denn vergleichbare Software mit kompatiblen Schnittstellen können andere Firmen unter diesen Umständen schlicht nicht anbieten.

Beim Setup der Software scheint es so, dass sich OpenEDR ohne Zugang bei Xcitium gar nicht installieren lässt. Hier ist der gesamte Prozess etwas eigenartig: Zunächst luden wir uns von Xcitium ein Agentenpaket herunter, das jedoch nicht den OpenEDR-Agenten enthielt. Das Paket diente lediglich dazu, den Server im Xcitium-Dashboard der Endpoint Security zu registrieren, konkret in der "Xcitium Enterprise Platform". Vor der eigentlichen OpenEDR-Installation mussten wir uns also zunächst selbst in jener Plattform einen Account anlegen. Dann erfolgte der Download eines Service-Agenten mit vorkonfigurierten Credentials auf dem eigentlichen Zielsystem, mittels dessen sich das System ebenfalls in die Xcitium Enterprise Platform integrierte. Erst dann ließ sich per Mausklick direkt im Webinterface der OpenEDR-Agent auf dem Zielsystem ausrollen. Nach einem erzwungenen Reboot stand er dort bereit und funkte bereits erste Informationen an den Hersteller. Nur wer sich bis ins offizielle Git-Verzeichnis von Xcitium vorkämpft, findet dort sowohl für 32- als auch für 64-Bit-Windows fertige MSI-Pakete zur Installation.

Es ist in OpenEDR also durchaus vorgesehen, die Daten lokal unter der eigenen Kontrolle zu behalten und sie eben nicht gleichzeitig auch Xcitium zur Verfügung zu stellen. Der Anbieter verrät auch, wie er sich das vorstellt, allerdings ist der Vorgang alles andere als gut dokumentiert oder komfortabel. Denn als Data-Crunching-Plattform für OpenEDR schwebt dem Anbieter nicht weniger als eine ausgewachsene Elasticsearch-Plattform vor.

Wer mit Elasticsearch im Kontext von "ELK" (Elasticsearch, Logstash und Kibana) schon einmal das Vergnügen hatte, bekommt nun vermutlich das Grauen, denn diese Sofware ist ein komplexes Monster. Dass der Administrator zum Abtransport der lokalen Daten zusätzlich auch noch Filebeat händisch per PowerShell installieren muss, ist da schon fast ein zu vernachlässigendes Detail. Viel schlimmer ist, wie der Administrator die Tools laut Hersteller im Anschluss konfigurieren soll. Er muss etwa Elasticsearch die Regeln mittels einer Datei im JSON-Format mit auf den Weg geben. Dazu liefert der Anbieter auch ein passendes Beispiel mit nicht weniger als 7715 Zeilen – vollständig unkommentiert und ohne jede Dokumentation.

Hier zieht OpenEDR damit leider eine Niete. Wer nicht sattelfester Linux- wie Windows-Profi ist, wird aller Wahrscheinlichkeit schon daran scheitern, die Software überhaupt in Betrieb zu nehmen, ohne auf die Onlinedienste des Herstellers zurückzugreifen. Eine stringente Dokumentation, was zu tun ist, bis sich für einen Windows-Client die poppigen bunten Dashboards zeigen, die OpenEDR verbreitet, fehlt jedenfalls ebenso wie das gute Gefühl, dass OpenEDR eine professionell gewartete Software sei, der IT-Verantwortliche die Sicherheit ihrer Systeme anvertrauen.

Eigentlich sollte das Thema Datenschutz bei einer EDR-Software klar geregelt sein, denn die gesammelten Daten umfassen allerlei kritische bis kritischste Details. Darunter fällt wie schon beschrieben der gesamte Netzwerkverkehr von Knoten ebenso wie alles, was die jeweiligen Programme auf dem System an Funktionen aufrufen. So einfach ist die Sache im Kontext von OpenEDR aber eben nicht. Der Elastic-Cluster, der laut Hersteller für die lokale Analyse von Daten notwendig ist, lässt sich nicht "mal eben so" hochziehen. Und schon gar nicht im größeren Skalierbarkeitsbereich, der zwangsläufig für die Metrikdaten von Dutzenden oder Hunderten Clients notwendig ist. Wenn EDR nicht zur Performancebremse werden soll, ist gerade auf der Elastic-Seite viel Rechenleistung nötig.

Allerdings liefert Xcitium wenig bis gar keine brauchbare Dokumentation, um ein solches Setup produktiv aufzusetzen. Im Augenblick lässt sich OpenEDR eigentlich nur sinnvoll mit den Fähigkeiten der Xcitium Enterprise Platform nutzen. Und die hostet der Anbieter – eine Firma nach amerikanischem Recht und eigener Infrastruktur in den Vereinigten Staaten. Flugs findet sich hier der Administrator in einer Sicherheits- und Compliance-Hölle wieder: Die DSGVO und der CLOUD-Act der USA vertragen sich bis heute nicht, sodass manchen Firmen eben dieser Datentransfer bereits per Gesetz verboten ist, etwa für Systeme mit Kritis-Einstufung.

Darüber hinaus dürfte auch den meisten anderen Admins mulmig beim Gedanken werden, quasi die gesamte Kommunikation der eigenen Clients per Netz zu einem Anbieter in einem Drittland zu exportieren, auf dass sie dort auf Angriffe hin untersucht wird. Nota bene: Das impliziert nicht, dass Xcitium mit den Daten irgendwas Illegales täte oder sinistre Absichten hätte.

Im Kern bietet OpenEDR ja die Möglichkeit der lokalen Analyse. Aber so, wie sich die Dokumentation aktuell darstellt, und so, wie diese Form der Nutzung seitens des Anbieters beworben wird, wirkt sie eher wie eine Karotte vor der Nase, die dem Administrator Erfolgsaussichten versprechen soll, wo in Wirklichkeit ein langer und steiniger Weg wartet. Die Zahl der Spezialisten, die gleichzeitig Sicherheitsexperten für Windows sind und in der Lage, die für OpenEDR lokal notwendige Infrastruktur zu betreiben, dürfte jedenfalls sehr überschaubar sein.

Bei diesem Kriterium im Test kassiert OpenEDR deshalb eine herbe Klatsche. Eine Software, deren Dokumentation mit allem Drumherum so schlecht ist, dass sie ohne schwerwiegende Verstöße gegen beispielsweise die DSGVO praktisch nicht sinnvoll zu verwenden ist, braucht zumindest hierzulande vermutlich kein Mensch, auch wenn sie im Ansatz noch so umfangreich und gut ist.

Das eben angesprochene Problem zieht sich wie ein roter Faden durch die gesamte Bewertung der Software, auch beim Thema Benutzung. Xcitium bewirbt OpenEDR mit vielen bunten Screenshots, die Analysegrafiken zeigen, Bedrohungsdiagramme malen und umfangreiche Analysevorgänge von Systemevents auf Windows-Systemen demonstrieren. Auf all diese Funktionalität erhält der Administrator aber nur Zugriff, wenn er sich auf Xcitiums Enterprise Platform einmietet und die dortigen, vordefinierten Regeln und Dashboards nutzt.

Und die sind gleich ein weiterer schmerzhafter Punkt, denn sämtliche Screenshots, die OpenEDR vermarktet, stammen von der Xcitium Enterprise Platform und nicht etwa von einer lokalen Implementierung. Selbst wenn es dem Admin also gelingt, einen Elasticsearch-Cluster aufzusetzen und sinnvoll zu betreiben und mit den Regeln zu betanken, die OpenEDR als Beispiel zur Verfügung stellt, müsste er die grafische Aufbereitung für Kibana im Anschluss noch immer ebenfalls händisch konfigurieren. Vor dem Hintergrund der Komplexität der Software scheint das aber praktisch ausgeschlossen, wenn der Nutzer sich nicht über Wochen mit dem Code beschäftigt oder diesen in weiten Teilen auswendig kennt.

Das wirkt sich auf den Faktor Usabilty natürlich unmittelbar aus. Aus den von Xcitium veröffentlichten Screenshots sprudeln nach der Installation alle Daten heraus, die notwendig sind, um auf Basis von Heuristik Angriffe zu erkennen. Und das von Xcitium zur Verfügung gestellte Enterprise-Dash-board wertet diese Informationen auch in einer Art und Weise aus, die für den Administrator sehr hilfreich ist. Aber dann ergibt sich eben das schon beschriebene Problem in Sachen Datenschutz und Compliance.

Will der Administrator sich ein EDR-Setup stattdessen selbst lokal bauen und dafür Elasticsearch und Kibana nutzen, sieht er nach der initialen Einrichtung von OpenEDR auf den Zielsystemen in Kombination mit FileBeat für den Abtransport der Logdateien mit den Metrikdaten erst einmal gar nichts. Die Aufgabe, sich eigene grafische Übersichten zu bauen oder aus den eingehenden Daten Rückschlüsse zu ziehen, obliegt also weitgehend ihm. Das ist ein zusätzlicher und mit erheblichem Aufwand verbundener Arbeitsschritt auf dem Weg zu einer sinnvoll funktionierenden, produktiven EDR-Implementierung.

Ein bisschen wird hier erkennbar, dass Xcitium mit OpenEDR dann eben doch nicht (nur) der gute Samariter ist, der zu sein das Unternehmen durch die Freigabe des Software-Quelltexts vorgab. Was im Ansatz auch nicht verwerflich ist, denn der Betrieb einer EDR-Lösung braucht Zeit, aber die korrekte Reaktion auf Ereignisse, die ein EDR-System findet, benötigt vor allem viel Arbeitskraft.

 Die Idee, ein EDR-System nur zu betreiben und dann mit den dort gefundenen Erkenntnissen nichts Sinnvolles anzustellen, ist Quatsch. Längst nicht jedes Unternehmen aber kann sich ein Threat-Reponse-Team leisten, das den ganzen Tag nichts anderes macht, als EDR-Ereignisse auszuwerten. Entsprechend möchte Xctitium diese Aufgaben dem Kunden offenbar als jenen Mehrwert verkaufen, bei dem der Anbieter am Ende selbst Daten mitschneidet. Das aber bedeutet für die Version ohne Hersteller-Dashboard leider, dass sie praktisch unbenutzbar ist.

Und das ist durchaus bedauerlich. Denn die Effektivität von OpenEDR steht nicht infrage, auch wenn es uns im Rahmen des Tests nicht möglich war, einen riesigen Feldversuch mit zahlreichen Clients zu starten. Das haben aber durchaus seriöse andere Institutionen bereits getan. Das SANS-Institut etwa hat 2021 im Eigenversuch eine ganze Werkzeugkiste voller Einbruchstools gegen OpenEDR ins Rennen geschickt und von zwölf verschleierten Angriffen hat die Software jeden einzelnen zuverlässig erkannt. Leider findet sich auch hier der Hinweis, dass die Enterprise-Plattform von Xcitium zum Einsatz gekommen ist, weil das Setup einer lokalen Umgebung von Anfang an nicht Gegenstand der Untersuchung war.

Manche EDR-Systeme richten mehr Schaden an, als sie nutzen. Eingangs war bereits das Thema Security beispielhaft hierfür, aber auch das Thema Performance spielt bei EDR eine große Rolle. Denn ein schlechtes EDR sorgtim schlimmsten Falle dafür, dass ein System praktisch nicht mehr zu benutzen ist.

OpenEDR hat hier den Vorteil, dass es gar nicht erst versucht, auf den lokalen Systemen selbst Analysearbeiten durchzuführen. Für die ist wie beschrieben entweder das Xcitium-Dashboard oder die selbst gehäkelte lokale Elasticsearch-Instanz zuständig. Entsprechend klein ist der Performance-Overhead, den Open-EDR auslöst. Vor allem im Netz ist zu beobachten, dass durch den kontinuierlichen Stream von Metrikdaten hin zu Xcitium oder Elastic mehr Last als zuvor gegeben ist. Das aber nicht in einem Ausmaß, das moderne NICs mit 25 GBit/s oder mehr ernsthaft in Bedrängnis bringen sollte.

Ein EDR-System ist selbst ein valides Angriffsziel, wenn Ganoven sich Zugang zur Infrastruktur verschaffen wollen. Bekannt von Rootkits unter Linux, die zum Teil Programme direkt im System austauschen, um die eigene Anwesenheit zu verschleiern. Für EDR-Werkzeuge wie Open-EDR gelten ähnliche Herausforderungen. Denn gelingt es einem Angreifer, das EDR auf einem System außer Gefecht zu setzen, kann er dort theoretisch tun und lassen, was er will.

Bei diesem Testkriterium gibt OpenEDR sich aber keine Blöße: Dessen Komponenten sind tief mit den Zielsystemen integriert und lassen sich nicht ohne weiteres entfernen. Ohne die Rechte des Systemadministrators ist es praktisch unmöglich, einem OpenEDR-Client den Garaus zu machen. Darüber hinaus schützen die Komponenten sich durch Signaturen und gegenseitige Kontrolle etwa bei der Überwachung von Datenströmen davor, "verloren" zu gehen.

Und selbst wenn es einem Angreifer gelingen sollte, das lokale OpenEDR eines Systems auszutricksen, wäre das nur die halbe Miete. Denn die laufende Elastic-search-Instanz oder das Xcitium-Dashboard würden relativ schnell mitbekommen, dass von einem System keine Daten mehr ankommen. Praktisch müssten Angreifer also OpenEDR so manipulieren, dass es noch immer valide Metrikdaten versendet, die Angreifer selbst dabei allerdings verschleiert. Was technisch nicht unmöglich ist, aber zumindest kein Allerwelts-Bedrohungsszenario darstellt.

OpenEDR macht vieles richtig, aber weil es produktiv im Grunde nur mit den Werkzeugen des Herstellers nutzbar ist, bleibt ein schaler Beigeschmack. Da hilft auch der Charakter als Pseudo-Open-Source-Software nicht weiter. Um wirklich nützlich zu sein, müsste Xcitium aus OpenEDR ein fertiges Produkt bauen, das – möglicherweise in Container-Form – benötigte Komponenten wie Elastic-

search, Filebeat & Co. gleich passend konfiguriert im Gepäck hat. Solange Admins aber erstmal viel Zeit investieren müssen, um eine lokale Instanz von OpenEDR mit sinnvoller Funktionalität zu erhalten, dürfte sich der Nutzen des Werkzeugs in engen Grenzen halten.