NIS2 · KRITIS · BSI IT-Grundschutz OPS.1.1.4

Endpoint Security: Von AV zu EDR und XDR

Warum signaturbasierter Virenschutz gegen moderne Angriffe nicht ausreicht, welche Technologien den öffentlichen Sektor heute schützen und wie Vergabestellen EPP, EDR und XDR ausschreiben können.

Stand: 29.10.2026


Warum klassisches AV nicht mehr schützt

Klassischer Virenschutz arbeitet signaturbasiert: Er vergleicht Dateien und Prozesse mit einer Datenbank bekannter Schadsoftware-Muster. Trifft ein bekannter Hash oder eine bekannte Bytekombination ein, wird geblockt. Dieses Prinzip funktionierte, als Angreifer ihre Werkzeuge selten veränderten und Schadsoftware in großer Stückzahl identisch verbreitet wurde.

Beides gilt heute nicht mehr. Angreifer nutzen drei Techniken, die signaturbasierte Erkennung systematisch umgehen:

Polymorphe Malware und Zero-Days
Schadsoftware wird bei jeder Auslieferung automatisch verändert, sodass kein bekannter Hash entsteht. Zero-Day-Exploits nutzen Schwachstellen, für die noch keine Signatur existiert. Beide Varianten passieren AV-Scanner ungehindert.
Living-off-the-Land (LOLBas)
Angreifer verzichten auf eigene Schadsoftware und nutzen legitime Systemwerkzeuge: PowerShell, WMI, PsExec, certutil. Diese Werkzeuge sind im Betriebssystem vorhanden und werden von AV nicht blockiert, selbst wenn ein Angreifer sie zur Datenexfiltration missbraucht.
Fileless-Angriffe und Speicher-Exploits
Schadsoftware wird nicht als Datei auf der Festplatte abgelegt, sondern direkt im Arbeitsspeicher ausgeführt. Signaturbasierte Scanner, die Dateisystem-Inhalte prüfen, haben keine Angriffsfläche zur Erkennung.

Der BSI IT-Grundschutz verlangt im Baustein OPS.1.1.4 ein Konzept für den Schutz vor Schadprogrammen und geeignete Schutzprogramme für den Enterprise-Bereich; bei erhöhtem Schutzbedarf soll zusätzlich der Einsatz von Produkten mit erweitertem Schutzumfang gegen gezielte Angriffe geprüft werden (OPS.1.1.4.A1, A3 und A14)[2]. Mit dem NIS-2-Umsetzungsgesetz müssen deutlich mehr Organisationen Risikomanagementmaßnahmen nach dem Stand der Technik umsetzen (§ 30 BSIG): Das BSI rechnet mit rund 29.500 beaufsichtigten Einrichtungen statt bisher etwa 4.500[6].

Ein Trugschluss ist es, aus einem AV, das „noch nie angeschlagen“ hat, zu folgern, dass kein Angriffsversuch stattgefunden hat. Kein Alarm kann bedeuten, dass kein Angriff stattfand, oder dass der Angriff die Erkennung schlicht umgangen hat. EDR schafft die Sichtbarkeit, die AV fehlt.

Begriffe: EPP, EDR, XDR, MDR

Die Endpoint-Security-Branche produziert Akronyme schneller als Vergabestellen sie verarbeiten können. Das ist kein Zufall: Hersteller differenzieren ihre Produkte durch Begriffe, nicht immer durch Funktionen. Wer ein Leistungsverzeichnis schreibt, muss diese Begriffe exakt definieren, sonst sind Angebote nicht vergleichbar.

TechnologieAnsatzBlinder Fleck
AVSignaturvergleich bekannter Schadsoftware-Hashes. Geringe Ressourcenlast, schnell zu deployen.Zero-Days, polymorphe Malware, Fileless-Angriffe, LOLBas
NGAVNext-Generation AV: ML-basierte statische Analyse + Verhaltensüberwachung zur Laufzeit. Kein reiner Signaturvergleich.Forensik, Threat Hunting und nachträgliche Untersuchung fehlen. Kein Response-Modul.
EPPEndpoint Protection Platform: Kombination aus NGAV + grundlegendem EDR in einem Produkt. Viele kommerzielle Lösungen bündeln beides.Tiefe Forensik und proaktives Threat Hunting variieren stark je Hersteller.
EDREndpoint Detection and Response: Kontinuierliches Monitoring aller Endpoint-Aktivitäten, Forensik, automatisierter Response, Threat Hunting. Setzt auf Prävention auf.Sichtbarkeit begrenzt auf verwaltete Endpunkte. Netzwerk, Cloud und Identitätsquellen fehlen ohne Erweiterung.
XDRExtended Detection and Response: Korreliert Daten aus Endpunkten, Netzwerk, Cloud, E-Mail und Identitätsquellen in einer zentralen Plattform. Erkennt Angriffsketten über mehrere Systeme.Höherer Integrations- und Konfigurationsaufwand. Hersteller-natives XDR kann Vendor-Lock-in erzeugen.
MDRManaged Detection and Response: Ein Dienstleister übernimmt 24/7-Monitoring, Incident Response und Threat Hunting, meist auf Basis einer bestimmten EDR- oder XDR-Plattform. Hersteller-eigene MDR-Dienste arbeiten vor allem mit der eigenen Plattform.Bei hersteller-eigenem MDR sind Plattform und Betrieb eng verknüpft. Wer den Dienst wechselt, muss dann oft auch das EDR-Produkt austauschen.

Drei Erkennungsmethoden: warum EDR mehr kann

NGAV und EDR unterscheiden sich nicht nur im Namen, sondern fundamental in der Analysetiefe. Drei Methoden bestimmen, was eine Lösung erkennen kann und was nicht:

Statische Analyse Dynamische Analyse Verhaltensanalyse
Ansatz Dateiprüfung vor Ausführung: Vergleich mit Signatur-/Hash-Datenbank Ausführung in Sandbox: Beobachtung des Verhaltens in kontrollierter Umgebung Laufendes Monitoring auf dem Host: Prozesse, Registry-Änderungen, Netzwerkverbindungen, Syscalls
Erkennt Bekannte Hashes, IP-Adressen, Signaturen, Code-Snippets File-Änderungen, Registry-Schreibvorgänge, Memory-Zugriffe CLI-Befehle, Process Spawning, User Actions, Syscall-Ketten
Umgehbar durch Polymorphismus, Verschlüsselung, Obfuskation Sandbox-Erkennung (CPU-Checks, Delays), Ausführungsverzögerung DLL Unhooking, direkte Syscalls (kein Hook), LOLBas-Missbrauch
Abgedeckt von NGAV: vor allem statisch und dynamisch EDR: alle drei Methoden
Fazit: Welche Erkennungsmethoden eine Lösung abdecken muss, gehört als konkrete Funktionsanforderung ins Leistungsverzeichnis. Betreiber kritischer Anlagen müssen zusätzlich Systeme zur Angriffserkennung einsetzen, die Parameter aus dem laufenden Betrieb kontinuierlich und automatisch erfassen und auswerten (§ 31 Abs. 2 BSIG)[8].
MDR vs. SOC: der entscheidende Unterschied
MDR: Plattform und Betrieb als Bundle
Anbieter liefert EDR-Produkt und Monitoring aus einer Hand. Vorteil: schnell einsatzbereit. Nachteil: Tool-Wahl und Betrieb hängen eng zusammen. Bei einem hersteller-eigenen MDR-Dienst stehen die Werkzeuge des Herstellers im Mittelpunkt; ob Werkzeuge anderer Hersteller eingebunden werden, regelt das Angebot.
SOC: freie Tool-Kombination
Ein SOC, intern oder als neutraler Dienstleister, kombiniert Werkzeuge unabhängig vom Hersteller: Microsoft Sentinel als SIEM, CrowdStrike Falcon als EDR, Netzwerk-Telemetrie aus eigener Quelle. Jede Komponente kann separat ausgetauscht werden.
Technisch wichtig ist, dass Detektionsregeln und Playbooks beim Auftraggeber verbleiben, wenn der MDR-Anbieter gewechselt wird; wie das vertraglich geregelt wird, legt Ihre Vergabestelle fest.

Werden EDR und NGAV im Leistungsverzeichnis synonym verwendet, kann ein Bieter, der ein NGAV-Produkt ohne echtes EDR-Modul anbietet, die Anforderung trotzdem als erfüllt markieren. Konkrete Funktionsanforderungen statt Produktkategorien vermeiden dieses Problem.

Von AV zu XDR: 30 Jahre Endpoint Security

Jede Generation war eine Antwort auf neue Angriffsmethoden. Wer den Entwicklungspfad kennt, kann Angebote besser einordnen.

1990er
AV
Antivirus
Signatur Hash-Vergleich
Nur bekannte Bedrohungen erkennbar.
✗ Versagt bei Zero-Days
2000er, 2010er
NGAV
Next Generation Antivirus
ML-Analyse Sandbox
Erkennt Malware auch ohne Signatur.
✗ Keine Forensik, kein Response
2013, heute
EDR
Endpoint Detection & Response
Forensik Threat Hunting
Kontinuierliches Monitoring, Forensik und automatisierte Response.
✗ Blind für Netzwerk und Cloud
2019, heute
XDR
Extended Detection & Response
Endpoint + Cloud Multi-Source
Korreliert Netzwerk, Cloud, Identity und Endpunkt in einer Engine.
✓ Sicht über mehrere Datenquellen

EPP = NGAV + EDR in einem Produkt. Viele moderne Endpoint-Produkte sind heute EPP-Lösungen: Sie kombinieren präventiven Schutz (NGAV) mit aktiver Erkennung und Response (EDR). EPP ist damit der Überbegriff für die komplette Endpunktschutz-Plattform.

Erkennungslücken und Angriffstechniken

Das MITRE ATT&CK-Framework katalogisiert reale Angriffstechniken, die staatliche und kriminelle Akteure in der Praxis einsetzen. Die MITRE ATT&CK Evaluations testen Endpoint-Security-Produkte gegen nachgestellte Angriffe realer Gruppen, in einem gemeinsamen Verfahren von MITRE und den teilnehmenden Herstellern. Alle Ergebnisse sind öffentlich[9].

In der MITRE-Evaluation Enterprise 2025 (ER7, Dezember 2025) wurden Angriffsmuster der Gruppen Scattered Spider und Mustang Panda nachgestellt, erstmals auch Angriffe in Cloud-Umgebungen[1], [9]. Beide Gruppen verwenden Techniken, die klassisches AV kaum erkennt:

MITRE-Technik ID AV-Erkennbarkeit EDR-Erkennbarkeit
Credential Dumping (LSASS)T1003GeringHoch
Lateral Movement via SMB/RDPT1021GeringHoch
PowerShell-Ausführung (LOLBas)T1059Sehr geringHoch
Process InjectionT1055GeringHoch
Datenexfiltration via Cloud-DiensteT1567KeineMittel (XDR besser)

MITRE veröffentlicht die Ergebnisse je Hersteller, bildet aber ausdrücklich keine Rangfolge[9]. Angaben einzelner Hersteller zu „100 Prozent“ beziehen sich auf bestimmte Kategorien der Auswertung. An der Runde 2025 nahmen elf Hersteller teil; mehrere große Hersteller hatten ihre Teilnahme abgesagt[7]. Als öffentlich zugänglicher, methodisch beschriebener Test eignet sich die Evaluation trotzdem als Bezugspunkt im Leistungsverzeichnis.

Konsequenz für das Leistungsverzeichnis

Statt „EDR-Lösung liefern“ zum Beispiel: „Der Auftragnehmer weist die Erkennungsleistung der angebotenen Lösung durch Ergebnisse eines unabhängigen, öffentlich dokumentierten Tests nach, etwa der MITRE ATT&CK Evaluations oder eines gleichwertigen Testverfahrens.“ Weil die Teilnahme an den MITRE Evaluations freiwillig ist, hält der Zusatz „oder gleichwertig“ den Kreis möglicher Angebote offen.

MITRE-Ergebnisse beschreiben ein Produkt, nicht das bietende Unternehmen. Im Leistungsverzeichnis gehören sie deshalb zu den Anforderungen an die angebotene Lösung.

Kernpositionen im Leistungsverzeichnis

Ein Leistungsverzeichnis für Endpoint Security sollte fünf Bereiche mit konkreten, prüfbaren Anforderungen abdecken. „EDR-Lösung liefern und betreiben“ ist keine Leistungsbeschreibung, sondern ein Freifahrtschein für unvergleichbare Angebote und spätere Vertragsstreitigkeiten.

Kernbereich 1
Erkennungsleistung

Messbare Anforderungen an die Detektionsqualität, nicht an Produktfunktionen.

  • Testnachweis: Ergebnisse unabhängiger Tests, z. B. MITRE ATT&CK Evaluations oder gleichwertig
  • Mean Time to Detect (MTTD): maximale Erkennungszeit nach Kompromittierung
  • False-Positive-Rate: maximaler Anteil ungültiger Alarme pro Tag
  • Erkennungstiefe: welche MITRE-Taktiken mindestens abgedeckt sein müssen
Kernbereich 2
Deployment-Architektur

Technische Grundbedingungen für die Integration in die Bestandsinfrastruktur.

  • Agent-basiert oder agentless: beides mit konkreten Szenarien beschreiben
  • Betriebsmodell: Cloud-native, On-Premises oder Hybrid
  • Betriebssystem-Abdeckung: Windows, Linux, macOS, mobile Systeme
  • Datenhaltung: Telemetriedaten ausschließlich in Deutschland/EU
Kernbereich 3
Scope-Definition

Welche Systeme sind abzudecken, einschließlich expliziter Aussagen zu Ausschlüssen.

  • Verwaltete Endpunkte: Laptops, Workstations, Server
  • Nicht verwaltete Endpunkte: Drucker, IoT, OT/ICS/SCADA
  • Cloud-Workloads: VMs, Container, Serverless
  • Mobile Devices: MDM-Schnittstelle oder eigener Agent
Kernbereich 4
Service Level und Response

Vertraglich bindende Reaktionszeiten und Eskalationspfade.

  • Verfügbarkeit: 24/7-Monitoring oder Betriebszeiten mit Rufbereitschaft
  • Mean Time to Respond (MTTR): maximale Zeit bis zur Eindämmung
  • Eskalationspfade: wer wird wie benachrichtigt, Unterstützung bei Meldungen nach § 32 BSIG
  • Incident-Response-Umfang: Containment, Eradication, Recovery
Kernbereich 5
Datensouveränität und Compliance

Besonders relevant für öffentliche Auftraggeber und KRITIS-Betreiber.

  • BSI C5-Testat des Anbieters oder gleichwertiger Nachweis
  • Datenhaltung ausschließlich in Deutschland oder EU
  • Auftragsverarbeitung nach Art. 28 DSGVO
  • Keine Weitergabe von Telemetriedaten an Dritte ohne Einwilligung
  • Exportierbarkeit aller Detektionsregeln und Playbooks
  • Exit-Klausel: vollständige Datenlöschung nach Vertragsende
Vorlage
Muster-LV EDR und XDR
Technische Leistungspositionen als Excel-Vorlage (EDR mehr als 40, XDR mehr als 45 Positionen).
Muster-LV EDR → Muster-LV XDR →

Technische Angebote vergleichbar machen

Die technische Auswertung von Endpoint-Security-Angeboten wird schwierig, wenn keine produktneutralen Maßstäbe definiert sind. Hersteller liefern eigene Leistungsdaten, die sich nicht vergleichen lassen. Externe Quellen geben Orientierung, ersetzen aber keine eigenen Anforderungen.

Gartner und Forrester als Orientierung

Gartner Magic Quadrant EPP und Forrester Wave XDR bewerten Anbieter nach Produktfähigkeiten und Marktpositionierung. Sie sind nützlich für die Marktübersicht, eignen sich aber nicht als Anforderung oder Zuschlagskriterium: Eine Anforderung „Gartner Leaders-Quadrant“ würde den Wettbewerb auf wenige Anbieter beschränken, die Leistungsbeschreibung soll aber allen Unternehmen den gleichen Zugang zum Verfahren gewähren (§ 31 Abs. 1 VgV)[8]. Stattdessen: die Bewertungsdimensionen aus diesen Berichten als Anforderungsquelle nutzen, nicht die Berichte selbst als Filter.

MITRE ATT&CK Evaluations

Die MITRE Evaluations sind ein öffentlich zugängliches, methodisch dokumentiertes Testverfahren für EDR- und XDR-Produkte. Getestet wird gegen nachgestellte Angriffe realer Gruppen, 2025 einer kriminellen Gruppe (Scattered Spider) und einer staatlich unterstützten Spionagegruppe (Mustang Panda)[9]. Alle Ergebnisse sind unter evals.mitre.org abrufbar. Vergabestellen können im LV Ergebnisse aus einer der letzten Runden verlangen. Weil nicht jeder Hersteller an jeder Runde teilnimmt, sollte die Anforderung gleichwertige unabhängige Testnachweise zulassen[7].

Betreibermodell-Entscheidung: In-house SOC vs. MDR

Kriterium In-house SOC Managed MDR
Kontrolle über DatenVollständigAbhängig von Vertrag
BetriebskostenHoch (Personal, Tools)Planbar (Festpreis möglich)
Expertenverfügbarkeit 24/7Schwer skalierbarJe nach Vertrag inklusive
HerstellerunabhängigkeitHoch (eigene Tool-Wahl)Variiert: hersteller-nativ vs. neutral
AufbauzeitLang (Personal, Prozesse, Werkzeuge)Kürzer, abhängig vom Onboarding
Vendor-Lock-in-RisikoGeringBei hersteller-nativem MDR: hoch

Für den langfristigen Betrieb zählen neben Testergebnissen vor allem Nachweise zur Datenhaltung (z. B. BSI C5) und die Regelungen zum Ausstieg. Produktfunktionen helfen wenig, wenn die Bedingungen für einen Wechsel nach drei Jahren nicht vertraglich geregelt sind.

Typische Fehler bei EP-Ausschreibungen

Ob Endpoint-Security-Angebote vergleichbar werden, entscheidet die Formulierung des Leistungsverzeichnisses. Fünf Fehler, die das verhindern:

01 Produktname statt Leistungsanforderung ▼

Das LV nennt konkrete Produktnamen wie „CrowdStrike Falcon“, „Microsoft Defender for Endpoint“ oder „SentinelOne Singularity“. Nach § 31 Abs. 6 VgV darf die Leistungsbeschreibung nicht auf bestimmte Produkte, Typen oder Hersteller verweisen, wenn dadurch Unternehmen oder Produkte begünstigt oder ausgeschlossen werden, es sei denn, der Auftragsgegenstand rechtfertigt das. Ausnahmsweise zulässig ist ein Verweis, wenn sich der Gegenstand sonst nicht hinreichend genau beschreiben lässt, und dann nur mit dem Zusatz „oder gleichwertig“[8]. Eine Endpoint-Security-Lösung lässt sich in der Regel über Funktionen beschreiben.

Besser: Anforderungen auf Basis messbarer Funktionen formulieren: Ergebnisse unabhängiger Tests, MTTD, False-Positive-Rate, BSI C5-Testat. Kein Produktname, kein Hersteller im LV.
02 Scope nicht vollständig definiert ▼

Das LV deckt verwaltete Laptops und Server ab, schweigt aber zu OT-Systemen, IoT-Geräten, nicht verwalteten Endpunkten und Cloud-Workloads. Nach Zuschlag stellt sich heraus, dass SCADA-Systeme, medizinische Geräte oder Industriesteuerungen nicht im Scope waren. Diese Lücken sind teuer zu schließen, wenn kein Vertragsrahmen dafür existiert.

Besser: Scope-Tabelle ins LV aufnehmen: je Systemkategorie festlegen, ob sie im Scope, explizit ausgeschlossen oder in Phase 2 zu berücksichtigen ist. Offene Punkte dokumentieren, nicht schweigen.
03 Kein MTTD/MTTR im Vertrag ▼

Ohne vereinbarte Mean Time to Detect und Mean Time to Respond fehlt ein messbarer Maßstab dafür, ob Alarme rechtzeitig bearbeitet wurden, und damit die Grundlage für Eskalationen oder vertragliche Folgen. Bei einem Ransomware-Vorfall, der stundenlang unbemerkt bleibt, fehlt dann die Handhabe.

Besser: MTTD und MTTR als SLA-Positionen ins LV aufnehmen, getrennt nach Kritikalität. Die Zielwerte legt der Auftraggeber nach seinem Schutzbedarf fest, die vertraglichen Folgen bei Überschreitung die Vergabestelle.
04 Datensouveränität nicht gefordert ▼

EDR-Systeme sammeln umfangreiche Telemetriedaten, darunter Prozessdaten, Netzwerkverbindungen und Nutzerverhalten. Werden diese Daten in Drittländern wie den USA gespeichert oder an Hersteller weitergegeben, stellen sich Fragen des Datenschutzes (Übermittlung in Drittländer, Art. 44 ff. DSGVO) und der Informationssicherheit. Für KRITIS-Betreiber und Behörden wiegt das besonders schwer.

Besser: BSI C5-Testat oder gleichwertigen Nachweis als Mindestanforderung ins LV aufnehmen. Datenhaltung ausschließlich in Deutschland oder EU fordern. AVV und Löschpflichten nach Vertragsende explizit regeln.
05 Betreibermodell nicht spezifiziert ▼

Das LV fordert „EDR einführen und betreiben“, ohne festzulegen, ob 24/7-Monitoring durch den Auftragnehmer, durch den Auftraggeber oder als hybrides Modell erfolgen soll. Anbieter interpretieren das unterschiedlich: ein Anbieter liefert eine Softwarelizenz ohne Betrieb, ein anderer ein vollständiges MDR-Paket. Die Angebote sind nicht vergleichbar, und nach Zuschlag gibt es keinen Vertragsrahmen für den Betrieb.

Besser: Betriebsmodell im LV explizit festlegen: Softwarelizenz und Eigenverantwortung vs. Managed Service mit definierten Service Levels. Beides ist legitim, aber beide Varianten brauchen unterschiedliche LV-Positionen.

Produkte zum Thema

Muster-LVs
LV-Vorlagen

Muster-LVs für EDR und XDR als Excel-Vorlage.

Muster-LVs ansehen →
Vergabe-Archiv
Vergleichbare Verfahren

Vergabeunterlagen anderer Auftraggeber, direkt durchsuchbar.

Archiv öffnen →
Quellen
  1. MITRE: „ATT&CK Evaluations: Enterprise 2025 (ER7), Scattered Spider & Mustang Panda“, Dezember 2025, evals.mitre.org.
  2. Bundesamt für Sicherheit in der Informationstechnik: „OPS.1.1.4 Schutz vor Schadprogrammen“, IT-Grundschutz-Kompendium Edition 2023, bsi.bund.de.
  3. European Union Agency for Cybersecurity (ENISA): „ENISA Threat Landscape 2024“, Oktober 2024, enisa.europa.eu.
  4. Bundesamt für Sicherheit in der Informationstechnik: „Die Lage der IT-Sicherheit in Deutschland 2024“, bsi.bund.de.
  5. Forrester Research: „The Forrester Wave: Extended Detection and Response Platforms, Q2 2024“, Juni 2024, forrester.com.
  6. Bundesamt für Sicherheit in der Informationstechnik: „Cybersicherheitsrecht: NIS-2-Umsetzungsgesetz ab morgen in Kraft“, 05.12.2025, bsi.bund.de.
  7. SecurityWeek: „MITRE Posts Results of 2025 ATT&CK Enterprise Evaluations“, Dezember 2025, securityweek.com.
  8. Gesetze im Internet: § 30, § 31 und § 32 BSIG; § 31 VgV, gesetze-im-internet.de.
  9. MITRE: „MITRE ATT&CK Evaluations Advance Cloud Security and Counter-Espionage Capabilities in Latest Round“, 10.12.2025, mitre.org.

Bereit für Ihre Endpoint-Security-Ausschreibung?

Muster-LVs für EDR und XDR als Excel-Vorlage, dazu vergleichbare Verfahren im Vergabe-Archiv.

Inhalt
Auf dieser Seite
Warum AV versagt Begriffe: EPP, EDR, XDR Von AV zu XDR Erkennungslücken LV-Anforderungen Angebote vergleichbar machen Typische Fehler
Weiterlesen
Systeme zur Angriffserkennung ausschreiben: BSI-Anforderungen und Vergabepraxis
Weiterlesen →
SAP S/4HANA ausschreiben: Der Praxis-Guide für öffentliche Auftraggeber
Weiterlesen →
Security Awareness: warum Pflichtschulungen kein Verhalten ändern
Weiterlesen →
Ruben Zimmer
Ihr Ansprechpartner
Ruben Zimmer
IT-Leistungsverzeichnisse.DE

Sie haben eine konkrete Beschaffung vor sich und wollen sehen, wie andere sie aufgesetzt haben? Das Vergabe-Archiv zeigt vergleichbare Verfahren. Bei Fragen zu den Produkten melden Sie sich gern.

Termin buchen → ruben.zimmer@it-lv.de +49 6124 6059217 LinkedIn