Bundesamt für Sicherheit in der Informationstechnik

M 2.425 Geeignete Auswahl von Werkzeugen für das Patch- und Änderungsmanagement

Verantwortlich für Initiierung: Änderungsmanager, IT-Sicherheitsbeauftragter, Leiter IT

Verantwortlich für Umsetzung: Leiter IT, Änderungsmanager

Der Patch- und Änderungsmanagementprozess kann mit verschiedenen Produkten oder Produktkombinationen unterstützt werden. Es kann vielfältige Gründe geben, ein Werkzeug zur Umsetzung und Durchführung des Patch- und Änderungsprozesses einzusetzen. Häufig sind heterogene IT-Infrastrukturen und die effektivere Ausnutzung von Ressourcen bestimmend.

Vor der Beschaffung eines Werkzeugs für das Patch- und Änderungsmanagement sollten die Anforderungen und Rahmenbedingungen ermittelt werden, um ein für die jeweilige Institution geeignetes Werkzeug zu finden. Das Vorgehen für die Evaluation eines Produktes ist stets ähnlich und orientiert sich an der gültigen Patch-Strategie der Institution, unabhängig davon, ob ein Patch- und Änderungsmanagement als Werkzeug für ein Betriebssystem, für die Produktpalette eines Herstellers oder für ein großes heterogenes IT-Szenario benötigt wird.

Nachfolgend ist eine Auswahl der wichtigsten Ausstattungsmerkmale zu finden, welche bei der Produktwahl beachtet werden sollten und die die Basis für die Formulierung der Anforderungen an das Softwarewerkzeug sind.

  • Plattformunterstützung:
    Unter diesem Begriff rangieren grundsätzlich zwei Aspekte. Einerseits wird hier betrachtet, welche Plattformen bezüglich Umsetzung des Patch- und Änderungsprozesses unterstützt werden und andererseits, auf welcher Plattform das Werkzeug lauffähig ist. Besonders der erste Aspekt sollte sehr detailliert betrachtet werden, da beispielsweise im Server-Client-Bereich die meisten Werkzeug-Hersteller Änderungsvorgänge bei Microsoft-Produkten unterstützen. Dies heißt jedoch nicht, dass auch die gesamte in der Institution vorhandene IT-Produktpalette von Desktop- und Server-Betriebssystem über Applikationsserver bis hin zu Einzelprodukten abgedeckt wird.
  • Patchanalyse:
    Einige Hersteller konzentrieren sich auf die mit dem Verteilungsprozess verbundene Menge der Updates und ihrer raschen Verteilung sowie dem Reporting des "Auslieferungsstatus". Einige liefern mehr Informationen zu den Hintergründen bzw. Gründen eines Patches, teilweise mit Listen betroffener Dateien, genauer Beschreibung der Schwachstellen und eigenen Testberichten. Insbesondere für die Verwendung von Sicherheitspatches, welche in der Regel rasch verteilt werden sollten, können die Detailinformationen einen unverzichtbaren Hinweis für die interne Einstufung der Hard- oder Software-Änderung enthalten.
  • Patchverifikation:
    Die meisten Hersteller liefern Hash-Summen, Fingerprints oder Signaturen mit den Patches und Änderungen, um deren Echtheit und Integrität zu bestätigen, jedoch prüfen nur wenige Werkzeuge diese Nachweise auch. Auf Grund dessen besteht die Gefahr, dass unerwünschte Software massenhaft in der Institution verteilt und erheblicher Schaden verursacht wird. Aus Sicherheitsgründen sollten daher keine Änderungswerkzeuge eingesetzt werden, bei denen diese Funktionalität fehlt.
  • Patchstrategie:
    Das Werkzeug muss eine flexible Konfiguration ermöglichen, um möglichst viele Schritte der gewählten Patchstrategie automatisieren zu können. Diese kann, auf Grund unterschiedlicher Plattformen, stark differieren. Die abgearbeiteten Schritte des Änderungsprozesses sollten vom Tool nachvollziehbar, je nach Bedarf sogar revisionssicher, dokumentiert werden. Spätere Änderungen im Prozess müssen in das Werkzeug einfließen können.
  • Verteilung:
    Nicht jeder Patch sollte auf jedes System ausgebracht werden. Das Werkzeug sollte die Gruppierung von Systemen und Applikationen nach frei definierbaren Attributen wie z. B. Schutzbedarf, Standort und Organisationseinheit ermöglichen. Aus diesen Attributen können IT-Systemprofile, entsprechend den standardisierten Systemtypen in der Institution, werden.
  • Rollback:
    Keine Software ist perfekt. Deshalb kann trotz aller Vortests die Notwendigkeit entstehen, einen Patch-Prozess umzukehren. Die Automatisierung dieses Vorgangs spart im Fehlerfall Zeit und Geld! Wenn sich fehlerhafte Änderungen nicht zeitnah und mit geringem Aufwand zurücknehmen lassen, kann dies die Institution erheblich schädigen.
  • Statusbewertung:
    Es muss ein Automatismus existieren, um die geänderte Hard- oder Software auf allen Systemen korrekt zu verteilen. Es könnten, wie bei Softwareverteilung im Allgemeinen, Probleme mit der Verbindung oder Verfügbarkeit eines Systems auftreten. Ein Patch kann dann vom System auf Grund anderer Systemzustände abgelehnt werden. Wichtig ist daher die Möglichkeit, dass das Änderungswerkzeug den Patch-Status aller Systeme erfasst. Je nach Strategie sollte das Werkzeug bei aufgetretenen Problemen den technischen Patch-Prozess bei den restlichen IT-Systemen fortsetzen oder bestimmte Systemgruppen überspringen oder den Patch-Prozess beenden.

Prüffragen:

  • Sind die Anforderungen und Rahmenbedingungen für die Auswahl eines Werkzeugs für das Patch- und Änderungsmanagement bestimmt?

Stand: 13. EL Stand 2013

Hinweis zur Verwendung von Cookies

Um unsere Webseite für Sie optimal zu gestalten und fortlaufend verbessern zu können, verwenden wir Cookies. Durch die weitere Nutzung der Webseite stimmen Sie der Verwendung von Cookies zu. Weitere Informationen hierzu erhalten Sie in unserer Datenschutzerklärung.

OK