GravityZone Patch Management ist das Patch-Management-Modul, das an den Endpoint-Protection-Agenten von Bitdefender andockt. Es erkennt fehlende Patches in Betriebssystemen und Drittanbieteranwendungen über zeitgesteuerte Scans, verteilt Patches zentral und steuert den Verteilungsprozess über Richtlinien. Ein separater Agent, ein eigener Server oder eine zweite Managementoberfläche sind nicht erforderlich; Inventar, Erkennung und Verteilung laufen in derselben GravityZone-Konsole zusammen.
Am häufigsten falsch verstanden wird die Lizenzierung des Moduls: Patch Management ist in keiner GravityZone-Stufe standardmäßig enthalten. Auf der offiziellen Vergleichsseite von Bitdefender wird es gemeinsam mit Full Disk Encryption, Email Security, Security for Mobile, Integrity Monitoring und Container Security als Add-on geführt (Bitdefender, 2026). Auch die TechZone-Dokumentation von Bitdefender beschreibt das Modul als Add-on-Komponente, die über ein in der GravityZone-Konsole erstelltes Paket auf den Systemen installiert wird (Bitdefender TechZone, 2026).
Dass Patch-Management innerhalb eines Sicherheitsprodukts angesiedelt ist, ist kein Zufall. Im Bericht The Forrester Wave: Endpoint Security, Q4 2023 wurden 13 Anbieter anhand von 25 Kriterien bewertet; Bitdefender wurde als "Leader" positioniert und erhielt in 10 Kriterien die höchstmögliche Punktzahl – darunter Malware-Prävention, Exploit-Prävention, Identitätsschutz, Erkennung von Netzwerkbedrohungen und Patch Remediation (Bitdefender, 2023). Sora Yazılım begleitet als autorisierter Bitdefender-Channel-Partner die Lizenzierung des Add-ons, den Entwurf der Verteilungsringe und die Aufbereitung der Auditberichte; die gesamte Produktfamilie finden Sie auf unserer Seite zu den Bitdefender-Lösungen.
Was genau leistet GravityZone Patch Management?
Kurze Antwort: Es findet fehlende Patches, lässt Sie entscheiden, welcher Patch wann wohin geht, und führt die Verteilung zentral durch. Das Modul beschränkt sich nicht auf Sicherheitspatches; auch nicht sicherheitsrelevante Patches lassen sich einbeziehen. Bitdefender TechZone definiert die Unterscheidung klar: Sicherheitspatches enthalten Schwachstellen- und CVE-Korrekturen, nicht sicherheitsrelevante Patches dagegen Fehlerbehebungen und neue Funktionen in Drittanbieteranwendungen (Bitdefender TechZone, 2026). Diese Unterscheidung ist in der Praxis wichtig: Manche Unternehmen ziehen es vor, nur Sicherheitspatches automatisch auszurollen und funktionale Updates an eine manuelle Freigabe zu binden.
Der Ablauf lässt sich in vier Schritten zusammenfassen. Scan: Über geplante Aufgaben und Wartungsfenster (Maintenance Windows) werden fehlende Patches auf den Endpunkten inventarisiert. Entscheidung: Welche Patches verteilt werden, wird per Richtlinie festgelegt; Patches, die Probleme verursachen oder intern nicht freigegeben sind, werden mit der Aktion Ignore patches (Patch ignorieren) in der Konsole aus Inventar und Verteilungsumfang ausgeschlossen. Verteilung: Die Patches werden in geplanten Fenstern angewendet. Reporting: Welches Gerät auf welchem Patch-Stand ist, wird über die Konsole nachverfolgt. Dieser Zyklus liefert eine messbare Antwort auf die in Audits am häufigsten gestellte Frage: "In welcher Zeit werden kritische Patches geschlossen?"
Auf der Bandbreitenseite nutzt das Modul die Rolle eines Patch-Caching-Servers. Bitdefender TechZone beschreibt diese Komponente als zusätzliche Rolle, die die relevanten Patches vollständig im lokalen Netzwerk vorhält, die Verteilung beschleunigt und die Nutzung der Internetbandbreite reduziert (Bitdefender TechZone, 2026). Patches werden an einen einzigen Punkt heruntergeladen, die Endpunkte beziehen sie von dort; so wird dieselbe Datei nicht hunderte Male aus dem Internet geladen. Ist der Caching-Server nicht erreichbar, laden die Systeme die Patches direkt von den Herstellerseiten – ein Ausfall des Caching-Servers stoppt die Patch-Verteilung also nicht vollständig, erhöht aber den Internetverkehr. In Unternehmen mit verteilter Filialstruktur ist die Platzierung des Caching-Servers eine der konkretesten Kapazitätsentscheidungen des Projekts.
In welchen GravityZone-Paketen ist Patch-Management enthalten?
In keinem. Patch Management ist von Small Business Security bis GravityZone Defense XDR in allen Stufen ein separat lizenziertes Add-on. Die im Internet häufig anzutreffende Aussage "Wenn Sie Premium oder Enterprise kaufen, ist Patch-Management enthalten" ist falsch. Ebenso wenig stimmt die Aussage, Patch-Management lasse sich nur zu den oberen Stufen hinzufügen; das Add-on erscheint in allen drei Vergleichen der offiziellen Vergleichsseite – für kleine Unternehmen, Enterprise und MSP – unter der Überschrift "separat erhältlich" (Bitdefender, 2026).
| Komponente | In der Stufe enthalten? | Anmerkungen |
|---|
| Endpoint Risk Analytics (Risikomanagement) | Standard ab Business Security | Bewertet ungepatchte und fehlkonfigurierte Geräte; verteilt selbst keine Patches |
| Patch Management | In keiner Stufe standardmäßig – Add-on | Scan, Verteilung, Caching-Server und das Ignorieren von Patches kommen mit diesem Add-on |
| Full Disk Encryption | Add-on | Verwaltung der vollständigen Festplattenverschlüsselung über die Konsole |
| Email Security / Extended Email Security | Add-on | Filterung auf der E-Mail-Ebene; native API-Integration für Microsoft 365 |
| Integrity Monitoring | Add-on | Überwachung von Änderungen an der Systemintegrität |
| Container Security | Add-on | Umgebungen mit Docker, Podman, Kubernetes, ECS, EKS, AKS, GKE |
| Extended Detection (XDR-Sensoren) | Add-on | Identity-, Netzwerk- und Productivity-Sensoren sind in der XDR-Stufe als optionale Sensoren enthalten; Cloud- und Atlassian-Sensoren werden auch in der XDR-Stufe separat erworben |
| Datenaufbewahrung (Data Retention) | Add-on | Auf der Vergleichsseite mit Optionen für 90, 180 und 365 Tage geführt; eine Standard-Aufbewahrungsdauer wird nicht angegeben |
Quelle: offizielle Vergleichsseite der Bitdefender-Businessprodukte (Bitdefender, 2026). Besonders oft verwechselt wird die Abgrenzung zwischen Risikoanalytik und Patch-Management: Endpoint Risk Analytics macht einen fehlenden Patch sichtbar, Patch Management schließt ihn. Eine Installation, die nur einen Risikoscore erzeugt, führt im Audit zum Bild "Wir kannten das Risiko, haben es aber nicht geschlossen". Den Umfang der Einstiegsstufe beschreiben wir auf unserer Seite zu GravityZone Business Security, die Ebene der erweiterten Bedrohungsanalyse auf unserer Seite zu Business Security Premium.
Worin unterscheiden sich virtuelles Patching und echtes Patch-Management?
Diese beiden Begriffe werden ständig verwechselt, obwohl der Unterschied eindeutig ist. Echtes Patch-Management wendet die vom Hersteller veröffentlichte Korrektur auf die Software selbst an; die Schwachstelle verschwindet. Virtuelles Patching rührt die Software nicht an; es blockiert den Datenverkehr oder das Anfragemuster, mit dem die Schwachstelle ausgenutzt werden soll, über ein Regelwerk. Die Schwachstelle bleibt im Code bestehen, ist aber nicht mehr ausnutzbar. Genau das ist eine der herausragenden Fähigkeiten von Trend Micro Deep Security: Es setzt virtuelles Patching über hostbasierte Intrusion-Prevention-Regeln (IPS) um. Die Dokumentation von Trend Micro beschreibt dies als das Abschirmen bekannter Schwachstellen mit IPS-Regeln, bis ein Patch eingespielt werden kann, und als Erfüllung einer Kontrolle, die viele Compliance-Vorgaben erwarten (Trend Micro Deep Security Dokumentation, abgerufen 2026).
GravityZone Patch Management ist die Seite, die den echten Patch verteilt; virtuelles Patching leistet es nicht. Auf Bitdefender-Seite stoppen die Ebenen Advanced Anti-Exploit und Network Attack Defense Exploit-Versuche, doch diese arbeiten verhaltens- und angriffstechnikbasiert – sie bieten keinen signaturbasierten Schutzschild, der für eine bestimmte Schwachstelle geschrieben wurde. Die beiden Ansätze sind daher keine Konkurrenten, sondern zwei Ebenen, die unterschiedliche Probleme lösen.
| Dimension | Echter Patch (GravityZone Patch Management) | Virtuelles Patching (z. B. Trend Micro Deep Security IPS) |
|---|
| Wirkung auf die Schwachstelle | Die Schwachstelle wird beseitigt; der Code wird korrigiert | Die Schwachstelle bleibt bestehen, der Ausnutzungsweg wird blockiert |
| Ansatzpunkt | Binärdateien von Betriebssystem und Anwendungen | Ebene der Netzwerk-/Host-Verkehrs- und Anfrageprüfung |
| Neustart | Je nach Patch unterschiedlich; in der Installationsaufgabe lässt sich die Option "Endpunkte bei Bedarf neu starten" definieren | Meist nicht erforderlich, die Regel wird sofort aktiv |
| Geschwindigkeit der Inbetriebnahme | Man wartet, bis der Hersteller den Patch veröffentlicht | Sobald die Regel veröffentlicht ist, sofort anwendbar |
| Risiko für die Anwendungskompatibilität | Verhaltensänderungen nach dem Patch sind möglich; ein Testring ist zwingend | Da die Software unverändert bleibt, ist das Kompatibilitätsrisiko gering; es besteht ein False-Positive-Risiko |
| Systeme ohne Herstellersupport | Veröffentlicht der Hersteller keinen Patch, gibt es keine Lösung | Bietet eine Brücke für nicht patchbare Altsysteme |
| Nachweis im Audit | Erzeugt den Nachweis "Schwachstelle geschlossen" | Wird als kompensierende Kontrolle (compensating control) dokumentiert |
| Dauerhaftigkeit | Dauerhafte Lösung | Vorübergehender Schutz; sobald der Patch verfügbar ist, muss der echte Patch angewendet werden |
Der richtige Aufbau sieht in der Regel so aus: Alles, was gepatcht werden kann, wird gepatcht; Systeme, die nicht gepatcht werden können oder für die sich kein Wartungsfenster findet, werden durch virtuelles Patching geschützt und dieser Zustand als befristete Ausnahme dokumentiert. Können Sie einen alten Windows-Server in der Fertigungslinie nicht neu starten, hält Sie virtuelles Patching am Laufen – das ist aber keine Begründung, den Patch unbefristet aufzuschieben. Das Pendant bei Trend Micro beschreiben wir ausführlich auf unserer Deep-Security-Seite; ergänzend positionieren wir FortiGate-Firewalls, die auf Netzwerkebene mit IPS dieselbe Funktion für Filial- und Zentralverkehr erfüllen.
Welche Betriebssysteme und Anwendungen werden unterstützt?
GravityZone Patch Management unterstützt neben Windows und macOS die Distributionen CentOS, Red Hat Enterprise Linux und SUSE Linux Enterprise (Bitdefender B2B Support, 2026). Der Agent, auf dem das Modul installiert wird – Bitdefender Endpoint Security Tools –, deckt dagegen ein deutlich breiteres Spektrum ab: von Windows 11 25H2 bis zur ersten Version von Windows 10, von Windows Server 2025 bis Windows Server 2016 Core, Red Hat Enterprise Linux 7.x–10.x, Debian 9–13 und Ubuntu 16.04.x–26.04.x sowie macOS-Rechner mit Intel- und Apple-M-Prozessoren (Bitdefender B2B Support, 2026). Diese beiden Listen dürfen nicht verwechselt werden: Nicht jede vom Agenten unterstützte Distribution wird auch vom Patch-Management unterstützt. Die Support-Dokumentation nennt zudem zwei praktische Einschränkungen: Die Listen der unterstützten Hersteller und Produkte werden monatlich aktualisiert und je Betriebssystem als CSV-Datei veröffentlicht; und Bitdefender installiert ausschließlich digital signierte Patches – ein unsignierter Patch muss manuell installiert werden, selbst wenn das Produkt in der Liste erscheint (Bitdefender B2B Support, 2026).
Bei Drittanbieteranwendungen muss man ehrlich sein. Keine der im Internet für Bitdefender Patch Management kursierenden Angaben nach dem Muster "unterstützt so und so viele Anwendungen" findet sich in der offiziellen Herstellerdokumentation. Auf der offiziellen Bitdefender-Seite ist lediglich von einer umfangreichen Liste von Drittanbieteranwendungen die Rede, und die Support-Dokumentation veröffentlicht die unterstützten Hersteller und Produkte als Datei, ohne eine Gesamtzahl zu nennen. Deshalb veröffentlichen auch wir auf dieser Seite keine Anwendungszahl. Der richtige Weg ist, vor dem Projekt Ihr Softwareinventar zu erstellen und mit dieser Liste abzugleichen – eine für ein Unternehmen kritische Anwendung kann fehlen, und diese Lücke sollte von Anfang an bekannt sein.
Auf der Server- und Virtualisierungsseite sollte Patch-Management nicht losgelöst von der Schutzarchitektur gedacht werden. In stark virtualisierten Umgebungen wird die Scan-Last an die Security Virtual Appliance ausgelagert und der Agent bleibt schlank; auch die Patch-Verteilungsfenster werden nach dieser Architektur geplant. Das Design auf der Serverseite behandeln wir auf unserer Seite zu GravityZone Security for Servers. Bei Appliance-Platzierung, Wartungsfenstern und Automatisierung kommen unsere DevOps- und Infrastrukturdienstleistungen ins Spiel.
Wie plant man die Patch-Verteilung, den Testring und den Rollback-Plan?
Das eigentliche Risiko im Patch-Management ist nicht der Patch selbst, sondern eine unkontrollierte Verteilung. Deshalb wird die Verteilung ringweise geplant: zuerst die Geräte des IT-Teams, dann eine Anwendergruppe mit geringem Risiko, anschließend die allgemeine Flotte und zuletzt die kritischen Server. Zwischen den Ringen bleibt ein ausreichendes Beobachtungsfenster. Dieser Ansatz ist keine Neuerfindung, sondern eine gängige Praxis des Änderungsmanagements, die auch in Audits erwartet wird.
Wozu dient es, einen Patch von der Verteilung auszunehmen (Ignore patches)?
Verursacht ein Patch intern Probleme oder ist Ihre Geschäftsanwendung für eine bestimmte Version zertifiziert, darf dieser Patch nicht verteilt werden. GravityZone Patch Management löst das nicht über ein separates "Blacklist"-Modul, sondern über die Aktion Ignore patches (Patch ignorieren) im Patch-Inventar: Die ausgewählten Patches werden aus dem Inventar und dem Verteilungsumfang entfernt (Bitdefender TechZone, 2026). Jedem ignorierten Patch sollten ein Verantwortlicher, eine Begründung und ein Überprüfungsdatum zugeordnet werden – das ist kein Pflichtfeld im Produkt, sondern eine von uns empfohlene Governance-Regel. Andernfalls wird aus der Ignorierliste mit der Zeit eine dauerhafte Schwachstellenliste.
Rollback und Wartungsfenster
Zeigt eine Anwendung nach einem Patch unerwartetes Verhalten, muss der Rückweg vorab definiert sein. Dieser Weg wird nicht allein dem Patch-Werkzeug überlassen; auf Servern werden ein Snapshot- oder Backup-Rückkehrplan und auf Clients ein Szenario zur Neuinstallation über das Standard-Image gemeinsam ausgearbeitet. Bei kritischen Systemen sind Wartungsfenster und Kommunikationsplan ebenso wichtig wie der Patch selbst. In der Installationsaufgabe lässt sich die Option "Endpunkte bei Bedarf neu starten" definieren; da vorab nicht bekannt ist, welcher Patch einen Neustart verlangt, wird die Fensterplanung entsprechend ausgelegt. Ob ein Patch tatsächlich angewendet wurde, unabhängig zu verifizieren, ist wiederum Aufgabe des Reportings.
Ersetzt Patch-Management die Erkennungsebene?
Nein. Ein Patch schließt bekannte Schwachstellen; Zero-Day-Lücken, Anmeldungen mit gestohlenen Zugangsdaten und Social-Engineering-Angriffe lassen sich damit nicht verhindern. Deshalb wird Patch-Management gemeinsam mit einer Erkennungs- und Reaktionsebene konzipiert. Um Angriffsketten zu sehen, die über den Endpunkt hinausgehen, sollte man sich GravityZone XDR ansehen; Unternehmen ohne internes Team für die Überwachung rund um die Uhr sollten Bitdefender MDR prüfen.
Wozu dient Patch-Management in Audits nach KVKK, ISO 27001 und PCI-DSS?
Patch-Management gehört zu den technischen Maßnahmen, für die in Audits am häufigsten Nachweise verlangt werden. Artikel 12 des türkischen Datenschutzgesetzes Nr. 6698 (KVKK) verpflichtet den Verantwortlichen, geeignete technische und organisatorische Maßnahmen zu treffen, um unrechtmäßigen Zugriff auf personenbezogene Daten zu verhindern und deren Aufbewahrung sicherzustellen. Bleibt eine bekannte Schwachstelle lange offen, bereitet das nach einer Verletzung der Bewertung "es wurden keine geeigneten Maßnahmen getroffen" den Boden. Ein zentraler Patch-Bericht ist an dieser Stelle ein konkretes Verteidigungsdokument.
Im Rahmen von ISO 27001 ist das Management technischer Schwachstellen eine eigene Kontrolle, und Auditoren verlangen in der Regel drei Dinge: wie Schwachstellen erkannt werden, in welcher Zeit sie geschlossen wurden und warum nicht geschlossene Schwachstellen offen geblieben sind. Patch Management liefert alle drei – Inventar, Verteilungsnachweis und Begründung für das Ignorieren. In Karteninhaberdatenumgebungen im Geltungsbereich von PCI-DSS wird erwartet, dass kritische Sicherheitspatches innerhalb einer definierten Frist eingespielt und dokumentiert werden; für nicht patchbare Systeme müssen kompensierende Kontrollen schriftlich vorliegen. Virtuelles Patching ist genau an dieser Stelle eine solche kompensierende Kontrolle.
Das Bild, das uns in der Türkei in der Praxis am häufigsten begegnet, sieht so aus: Ein Patch-Management-Werkzeug wurde beschafft, aber weil keine Verteilungsringe definiert wurden, blieb die automatische Verteilung abgeschaltet. Das Produkt steht in der Konsole, im Audit lässt sich jedoch nicht sagen "wir haben einen Patch-Prozess". Unser Leistungsumfang bei Sora Yazılım zielt darauf, genau diese Lücke zu schließen: Erstellung des Softwareinventars, Definition der Verteilungsringe und Wartungsfenster, Aufbau der Governance für die Ignorierliste, Platzierung des Caching-Servers und Aufbereitung auditfähiger Berichte. Die Oberfläche der GravityZone-Konsole ist nicht auf Türkisch verfügbar; Schulung auf Türkisch, Wissenstransfer über die Dokumentation und Support auf Türkisch im Störungsfall stellen wir bereit.
Teilen Sie uns mit, wie viele Endpunkte und Server Sie betreiben, welche kritischen Anwendungen Sie einsetzen und wie Ihr bisheriger Patch-Prozess abläuft; wir ermitteln gemeinsam, wie weit das Add-on GravityZone Patch Management Ihr Inventar abdeckt und für welche Systeme Sie eine kompensierende Kontrolle wie virtuelles Patching benötigen. Für Add-on-Lizenzierung, Verteilungsdesign und Audit-Reporting fordern Sie über unsere Kontaktseite ein Angebot an; wir planen eine Evaluierungsinstallation auf einer Pilotgruppe.
