Update-Strategie fürs ERP: Wie oft, wann, mit welchem Test?

Ob ein ERP-Update diese Woche eingespielt wird oder erst im Quartalsfenster, entscheidet sich an drei Fragen: Betrifft die Änderung eine Funktion, die Sie nutzen? Wie schwer wiegt die Lücke? Und wie viel Test kann sich Ihr Betrieb zeitlich leisten? Der BSI IT-Grundschutz verlangt, dass Sie jeden Patch nach der Veröffentlichung bewerten, priorisieren und über das Einspielen entscheiden, statt die Fragen zu übergehen (OPS.1.1.3.A15). Der Kalender weiter unten hält für jeden Fall ein Zeitfenster und eine Testtiefe bereit.

Was der Grundschutz verlangt und was er offen lässt

Der IT-Grundschutz des Bundesamts für Sicherheit in der Informationstechnik (BSI) ist ein Standard, kein Gesetz. Seine Anforderungen binden einen Betrieb, wenn ein Gesetz oder ein Vertrag auf sie verweist, etwa eine Vereinbarung mit einem Kunden, der IT-Grundschutz verlangt. Als Prüfmaßstab taugt der Baustein dennoch: Wer nicht sagen kann, welche Fassung sein ERP hat, wann zuletzt ein Sicherheitsupdate eingespielt wurde und wie der Rückweg aussieht, kann seine Update-Entscheidung nicht belegen.

Der Baustein OPS.1.1.3 setzt dafür den Rahmen. Ein Konzept muss vorgeben, wie Patches und Änderungen geplant, genehmigt und dokumentiert werden, und wie der Rückweg aussieht, wenn eine Änderung im Betrieb scheitert (A1). Zuständige sind für alle Organisationsbereiche festzulegen (A2); für Zweifelsfälle über Priorität und Terminplanung sieht A7 eine Eskalationsebene aus der Leitungsebene vor (Standard-Anforderung).

Die Edition 2023 des Kompendiums gilt seit dem 1. Februar 2023; eine Vorgabe, wann ein Patch spätestens eingespielt sein muss, enthält der Baustein nicht.

Warum schnelles Einspielen und gründliches Testen gegeneinander abgewogen werden müssen

NIST SP 800-40r4 (April 2022) beschreibt den Zielkonflikt offen: Ein schnell eingespielter Patch verkleinert das Zeitfenster für Angreifende, erhöht aber das Risiko einer Betriebsstörung; ein ausführlicher Test vor dem Einspielen senkt das Betriebsrisiko, verlängert aber genau dieses Zeitfenster. Der Leitfaden löst das nicht mit einer Frist, sondern mit Szenarien: Routine-Patching, Notfall-Patch, Notfall-Maßnahme ohne Patch und Systeme, die sich nicht patchen lassen. Für jedes Szenario gehört ein eigener Wartungsplan mit Zeitfenstern in die Unterlagen.

Die nationalen Stellen mahnen zur Eile, ohne eine Frist zu nennen. Das Bundesamt für Cybersicherheit hält für Schweizer Unternehmen fest, jede installierte Software sei unverzüglich zu aktualisieren, sobald Sicherheits-Updates vorliegen. Das österreichische IKT-Sicherheitsportal (Bundeskanzleramt und A-SIT) empfiehlt in seinem Beitrag vom 14. Oktober 2024, Updates rasch nach der Veröffentlichung zu installieren, weil Angreifende spätestens mit der Veröffentlichung eines Updates von der Sicherheitslücke erfahren.

Drei Release-Klassen mit eigenen Entscheidungskriterien

Für den Kalender ist eine Einteilung nach dem Umfang der Änderung brauchbar. Eine Sicherheitskorrektur ändert Verhalten nicht grundsätzlich, ein kleineres Release bringt Funktionen innerhalb derselben Datenstruktur, ein Versionswechsel berührt Datenmodell, Schnittstellen oder Anpassungen.

Klasse	Auslöser	Entscheidungskriterien	Testtiefe	Rückweg
Sicherheitskorrektur	Sicherheitsupdate des Herstellers für eine Komponente, die Sie einsetzen	Fragen zur Lücke: ist eine genutzte Funktion betroffen, ist sie aus dem Netz oder über Schnittstellen erreichbar, wird sie aktiv ausgenutzt (NIST SP 800-40r4)? Schweregrad nach CVSS v4.0	Kernabläufe und die betroffene Funktion, dazu Kontrolle der Sicherheitseinstellungen (OPS.1.1.6.A12)	Rückfall vor dem Einspielen prüfen (OPS.1.1.3.A1)
Kleineres Release	Release im regulären Zyklus des Herstellers	Enthaltene Funktionen, Ihre Anpassungen, Änderungen an Schnittstellen und Berichten	Regressionstest über die Kernprozesse, dazu nichtfunktionale Anforderungen (OPS.1.1.6.A5)	Wiederherstellungspunkt oder Vorversion, Fenster außerhalb der Stoßzeit
Versionswechsel	Wechsel auf eine Hauptversion oder ein neues Datenmodell	Release-Politik und Supportdauer des Herstellers, Aufwand für Anpassungen und Schulung	Abnahmeplan mit Freigabekriterien (OPS.1.1.6.A10), vollständiger Regressionstest, Schnittstellen	Gemessener Wiederherstellungsweg, Umstellung in einem geplanten Fenster

Die Entscheidung ist nicht beliebig. OPS.1.1.3.A15 staffelt die Verbindlichkeit aber: Bewertung und Priorisierung eines Patches sowie die Entscheidung über das Einspielen und die Dokumentation eines Verzichts formuliert er mit MUSS. Für die Prüfung, ob es zu einem Patch bekannte Schwachstellen gibt, und für die Kontrolle nach dem Einspielen verwendet er dagegen SOLLTE. Für die Bewertung sollten Sie deshalb prüfen, ob bekannte Schwachstellen vorliegen; entschieden werden muss, ob der Patch eingespielt wird. Wird er eingespielt, sollte kontrolliert werden, ob er auf allen relevanten Systemen zeitnah erfolgreich angekommen ist; wird er nicht eingespielt, sind Entscheidung und Gründe dafür zu dokumentieren (OPS.1.1.3.A15). Produkte ohne Herstellersupport dürfen nur weiterlaufen, wenn geprüft ist, dass ein sicherer Betrieb möglich ist.

Der Update-Kalender: Fenster, Auslöser, Beispielaufwand

Der folgende Kalender ist ein Vorschlag der Redaktion, keine Vorgabe von BSI oder NIST. Er setzt ein ERP mit 25 Arbeitsplätzen, eigenem Testsystem und ohne Schnittstellenwechsel im Betrachtungsjahr voraus.

Fenster	Klasse	Auslöser im Kalender	Testtiefe	Beispielaufwand
Laufend, ein fester Blick pro Woche auf Herstellermeldungen (OPS.1.1.1.A20, Standard-Anforderung: regelmäßige Prüfung auf Schwachstellen)	Sicherheitskorrektur	Meldung, aktiv ausgenutzte Lücke oder Freigabe des Herstellers	Kernabläufe und betroffene Funktion, Kontrolle der Einstellungen	3 Stunden je Korrektur
Erstes Wochenende im Quartal (Januar, April, Juli, Oktober)	Kleineres Release	Release des Herstellers	Regressionstest über die Kernprozesse	10 Stunden je Release
Sommerfenster Juli und August	Versionswechsel	Supportende der Vorfassung oder neue Hauptversion	Abnahmeplan, vollständiger Regressionstest, Schnittstellentest	48 Stunden je Wechsel

Die Beispielrechnung für ein Jahr: vier Sicherheitskorrekturen zu je 3 Stunden ergeben 12 Stunden, vier kleinere Releases zu je 10 Stunden ergeben 40 Stunden, ein Versionswechsel mit 40 Stunden Test und 8 Stunden Umstiegszeit ergibt 48 Stunden. Das sind zusammen 100 Stunden, bei acht Stunden je Arbeitstag 12,5 Arbeitstage. Nicht enthalten sind Schulungen, beauftragte Anpassungen und der Ausfall während des Umstiegs.

Im Cloud-ERP gehört der Kalender an eine andere Stelle

Ist der Anbieter Betreiber (Cloud-Dienst oder Hosting), liegt das Einspielen in seiner Hand; NIST SP 800-40r4 führt die verwaltende Stelle als eines der Merkmale, die zu jeder Komponente zu erfassen sind (IT-Abteilung, Dritte, Anwender, Hersteller). Ihre Kalenderzeilen verschieben sich damit auf Prüfen der Release-Hinweise, Testen im bereitgestellten Testsystem, Information der Key-User und Vorbereitung des Rückwegs. Klären Sie vor der Installation, wie oft der Anbieter Sicherheitsupdates liefert, wie viele Jahre er Fehler überhaupt behebt, ob Aktualisierungen nach Plan oder nach Bedarf kommen, ob er einen Rückweg anbietet und ob ein Neustart nötig wird (Fragenkatalog in NIST SP 800-40r4, Abschnitt 3.7). Beim eigenen Server kommt hinzu, wie Sie mit eingebauten automatischen Update-Mechanismen umgehen und wie diese abgesichert sind (OPS.1.1.3.A3).

Typische Fehler

1. Der Kalender kennt nur Termine, keine Ausnahmen: Eine aktiv ausgenutzte Lücke wartet dann bis zum Quartalsfenster. NIST SP 800-40r4 trennt deshalb Routine und Notfall und sieht für den Notfall einen beschleunigten Ablauf vor.
2. Nach dem Einspielen wird nicht kontrolliert: OPS.1.1.3.A15 sieht vor, dass bei einem eingespielten Patch kontrolliert werden sollte, ob er auf allen relevanten Systemen zeitnah erfolgreich eingespielt wurde (SOLLTE). OPS.1.1.3.A14 sieht für Systeme mit erhöhtem Schutzbedarf Mechanismen vor, damit auch zeitweise oder längerfristig nicht erreichbare Geräte die Patches und Änderungen erhalten (SOLLTE).
3. Der Verzicht wird nicht begründet: Die Entscheidung gegen einen Patch und die Gründe dafür sind zu dokumentieren (OPS.1.1.3.A15). Ohne Notiz ist die Entscheidung später nicht mehr belegbar.
4. Getestet wird im Produktivsystem: Software-Tests sind so durchzuführen, dass sie den Produktivbetrieb nicht beeinflussen (OPS.1.1.6.A2); dafür sollte die Testumgebung vom Produktivsystem getrennt betrieben werden (OPS.1.1.6.A13, Standard-Anforderung).
5. Der Rückweg ist nur behauptet: Eine Rückfall-Lösung ist Pflicht (OPS.1.1.3.A1), und NIST SP 800-40r4 erinnert daran, dass eine Installation Einstellungen zur Sicherheit verändern kann und im Fehlerfall Deinstallation, Rücksetzen auf die Vorversion oder eine Rücksicherung nötig wird.

So gehen Sie vor

1. Halten Sie schriftlich fest, wer Ihr ERP aktualisiert: eigener Server, gehostete Instanz oder Cloud-Dienst. Legen Sie je Weg die Zuständigkeit fest und bilden Sie sie im Berechtigungskonzept ab (OPS.1.1.3.A2).
2. Führen Sie eine Liste Ihrer Komponenten mit Version, Update-Mechanismus, Schutzbedarf und Ausfalltoleranz. Daraus entstehen Gruppen mit gleichem Wartungsbedarf (NIST SP 800-40r4, Abschnitt 3.4). Die Reihenfolge der Basismaßnahmen steht unter IT-Sicherheit rund ums ERP.
3. Legen Sie die drei Klassen mit Auslöser, Kriterien, Testtiefe, Zeitfenster und Abbruchkriterium fest und nehmen Sie sie ins Konzept auf (OPS.1.1.3.A1). Für Testabdeckung, -tiefe und -methode je Komponente sollten Sie eine Festlegung treffen (OPS.1.1.1.A20, Standard-Anforderung).
4. Bestimmen Sie, wer die Freigabe erteilt: Die fachlich zuständige Stelle gibt die Software frei, und die Freigabe wird als Freigabeerklärung dokumentiert (OPS.1.1.6.A4). Beziehen Sie Update-Pakete nur aus vertrauenswürdigen Quellen und prüfen Sie, wo vorhanden, Prüfsumme oder Signatur vor der Installation (OPS.1.1.3.A10, Standard-Anforderung).
5. Fragen Sie die Release-Politik des Anbieters ab: Zyklus, Supportdauer, Rückweg, Verhalten bei Sicherheitslücken (Fragenkatalog in NIST SP 800-40r4, Abschnitt 3.7). Wie Sie die Testfälle aus Ihren Kernprozessen ableiten, steht unter Update im Testsystem prüfen.
6. Dokumentieren Sie alle Phasen des Prozesses (OPS.1.1.3.A11, Standard-Anforderung) und kontrollieren Sie nach dem Einspielen, ob der Patch auf allen relevanten Systemen zeitnah erfolgreich angekommen ist (OPS.1.1.3.A15, SOLLTE). Für Systeme mit erhöhtem Schutzbedarf sieht OPS.1.1.3.A13 Nachtests an Referenzsystemen vor. Dasselbe gilt für Ihre Erweiterungen, siehe Anpassungen updatefähig halten.
7. Prüfen Sie vor einem Versionswechsel, wie lange Sie ohne ERP arbeiten können und wie lange die Rücksicherung dauert, siehe Backup-Konzept fürs ERP und Release-Wechsel. Betrifft die Änderung eine Funktion, die Sie für die Buchhaltung nutzen, klären Sie mit Ihrer Steuerberatung, was in Ihrer Dokumentation festgehalten werden muss.