Patch Management definiert einen gemanagten Prozess, der Änderungen (Changes) an Systemen beschreibt und nach Möglichkeit die Änderungen vor dem „Ausrollen“ testet bzw. prüft.
Ein klassischer Change würde das Change Management erfordern und die Freigabe der jeweiligen Verantwortlichen. Da Patchs aber regelmäßig kommen, sollten diese als „Standard Change“ gelten und sind, nach der erfolgreichen Testung, genehmigt.
Das Patch Management gehört in das Change Enablement aus dem ITILv4, in das Change Management aus der ISO 27001 oder in den Baustein OPS: Betrieb aus dem IT-Grundschutz. In diesen Frameworks wird generisch oder als „best practices“ beschrieben, wie man mit dieser Art Änderungen in seiner IT-Infrastruktur umgehen kann.
Ein Patch ist zum Beispiel eine Fehlerbehebung in einer Software oder einem Betriebssystem. Ein „Flicken“, der eine Lücke oder einen Fehler im System behebt oder Funktionen verbessert. Grundsätzlich wird zwischen einem Security Patch, also der Behebung einer Sicherheitslücke zur Vorbeugung von Cyberangriffen, einem Bug Fix, der Fehler Behebung und dem Feature Update, der Funktionserweiterung, unterschieden.
Ein häufiges Problem beim Patch- und beim Change Management sind unzureichende Ressourcen, um diesen Prozess wirklich wirkungsvoll zu betreiben. Wenn Patch Management softwaregestützt zentral automatisiert ist, um Kosten und Zeit zu sparen, sollte trotzdem vorher die Kompatibilität mit den vorhandenen Systemen getestet werden. Leider treten auch bei Patchs vereinzelt Fehler auf, die bei einem ungetesteten Ausrollen eventuell mehr Probleme im IT-Systemverbund verursachen als beheben.
Damit das IT-Sicherheitslevel so hoch wie möglich ist und das Risiko für den Informationsverbund gering bleibt, ist es wichtig, vor dem Testen, die Patchs zu priorisieren. Zuerst sollten Sicherheitslücken und Schwachstellen geschlossen und die Fehler erst im Anschluss behoben und neue Funktionen freigeschaltet werden. Nur so ist ein wirkungsvolles Patch Management zu gewährleisten.
Natürlich soll kein Administrator zu jedem System einzeln gehen und die uneingeschränkte Funktion testen. Vielmehr eignet sich ein separater und getrennter Testbereich, der dem IT-Verbund sehr ähnlich ist, um die Komptabilität der Systeme manuell zu testen. So können die Patchs nach einem erfolgreichen Test vollautomatisiert und zeitnah an alle betroffenen Systeme ausgerollt werden. Einem erfolgreichen Patch Management steht dann nichts mehr im Weg. Für die Windowssysteme wird meistens der Microsoft eigene Windows Server Update Service genutzt, in dem man mehrere Bereiche einrichten kann und somit die Freigabe der Patchs für die jeweiligen Bereiche steuern kann. Es gibt noch unzählige andere Anbieter, die auch Drittanbieter Softwares mit überwachen, welche genauso von Sicherheitslücken betroffen seien können.
Im Fehlerfall, der hoffentlich im Zuge des Patch Managements auftritt, muss das Patch zurückgehalten werden und ein passender Workaround bei Sicherheitspatchs und mögliche Fehlerbehebungen gefunden werden. Natürlich muss der Testverbund wiederhergestellt und der Workaround auch überprüft werden.
Im Zuge des Patch Management sollten diese vor Verteilung getestet werden, damit sie keine Fehler im Systemverbund hervorrufen. Das Testen sollte in einem eigenen Bereich geschehen, der separat gesichert ist, um das Gesamtsystem nicht zu gefährden. Das finale Ausrollen an die betroffenen Systeme sollte danach automatisiert und softwaregestützt, zeitnah durchgeführt werden. Natürlich sollte das Ergebnis soweit möglich auch überprüft werden, um im Fehlerfall doch noch ein Backup für das Patch Management einspielen zu können.
