Mainframe-Sicherheit: Ein blinder Fleck beim IWS?

Fragt man ein Mainframe-Sicherheitsteam nach seinen größten Herausforderungen, fallen häufig dieselben Themen: unübersichtliche RACF-Regelwerke, inaktive Benutzerkennungen mit weitreichenden Rechten oder die nächste Schwachstelle in einem TN3270-Emulator. Der Workload Scheduler, der im Hintergrund die Verarbeitung steuert, wird dagegen selten genannt.

Dabei koordiniert und startet der IWS Prozessausführungen, deren Zahl oft in die Millionen geht. Dazu gehören Gehaltsabrechnungen, Zahlungsabwicklungen und zahlreiche weitere Batch-Jobs, die über Nacht den Geschäftsbetrieb für den nächsten Tag sichern.

Die Integrität der Scheduling-Definitionen muss deshalb ein fester Bestandteil des Cybersicherheitskonzepts sein. Entscheidend ist die Frage: Was passiert, wenn jemand die Ablaufsteuerung selbst verändert?

Ein großer Teil der Sicherheitsinvestitionen fließt in Maßnahmen, die unbefugten Zugriff verhindern: Zugriffskontrollen, Verschlüsselung oder Angriffserkennung. Gegen externe Angreifer ist dieser Ansatz unverzichtbar. Für Personen, die bereits über berechtigten administrativen Zugriff auf den Scheduler verfügen, greift er jedoch zu kurz.

Ein kompromittiertes privilegiertes Konto muss keine weitere Schutzmaßnahme überwinden. Dasselbe gilt für einen Administrator, dem unter Zeitdruck ein Fehler unterläuft. Es genügt, eine Applikationsbeschreibung zu bearbeiten, eine spezielle Ressource zu löschen, einen Run Cycle anzupassen oder eine Abhängigkeit zu verändern. Solche Eingriffe wirken zunächst wie reguläre administrative Tätigkeiten. Trotzdem können sie kritische Prozesse beeinträchtigen.

Für IT-Teams beginnt dann häufig eine aufwendige Fehlersuche: Sie müssen ermitteln, was geändert wurde und wie sich der vorherige Zustand sicher wiederherstellen lässt.

Unabhängig von der Ursache stehen bei der Bearbeitung des Vorfalls dieselben Fragen im Mittelpunkt:

1. Was wurde geändert?

2. Wie sah der vorherige Zustand aus?

3. Wie lässt er sich sicher wiederherstellen?

IWS verfügt über eigene Funktionen zum Schutz vor unberechtigtem Zugriff. Sie klären jedoch nur, ob eine Person eine Änderung vornehmen durfte. Welche Folgen diese Änderung hat, bleibt offen. Scheduling-Definitionen sind eng miteinander verknüpft. Schon eine kleine, autorisierte Anpassung kann weitreichende Auswirkungen haben, die erst später sichtbar werden.

Viele Unternehmen können Änderungen am Scheduler zumindest teilweise nachvollziehen, etwa über ein Track Log oder eine JES-Ausgabe. Die eigentliche Herausforderung liegt jedoch in der Wiederherstellung. Der Hinweis, dass ein Objekt um 02:14 Uhr geändert wurde, hilft nur begrenzt, wenn es inzwischen vollständig gelöscht wurde und keine Vergleichsversion mehr existiert. Dasselbe gilt, wenn konkret nachgewiesen werden muss, was geändert wurde, oder wenn die nachweislich funktionierende Version der Vorwoche sofort wieder produktiv benötigt wird.

Genau hier liegt der Unterschied zwischen Protokollierung und wirksamer Kontrolle. Protokolle dokumentieren einen Vorfall im Nachhinein. Wirksame Kontrolle schafft die Grundlage, um schnell und gezielt zu reagieren.

IWS/Audit wurde entwickelt, um diese Lücke zu schließen. Als Teil der IWS Tools von Beta Systems erfasst die Lösung sämtliche Versionsstände bei Änderungen an den IWS-Definitionsdatenbanken, am Current Plan (CP), am Long Term Plan (LTP) und an der JCL (JS). Diese Informationen stehen für Analysen und Berichte zur Verfügung.

Damit zeigt IWS/Audit nicht nur, dass eine Änderung stattgefunden hat, sondern auch den vollständigen vorherigen Zustand des Objekts. Auf dieser Grundlage lässt sich eine frühere Version wiederherstellen – selbst dann, wenn das Objekt bereits gelöscht wurde.

Die Versionshistorie bleibt auch nach dem Löschen erhalten. Das ist besonders relevant, wenn durch das Löschen eines Objekts zugleich wichtige Spuren verloren gehen – ob absichtlich oder unbeabsichtigt. IWS/Audit bewahrt die Historie unabhängig vom Fortbestand des produktiven Objekts auf. Für die Wiederherstellung einer gelöschten Definition kann die Lösung die erforderlichen Batchloader-Anweisungen und IWS/BatchAD-Steuerkarten erzeugen.

Allerdings ist die Rückkehr zu einer früheren Version nicht automatisch risikofrei. Scheduler steuern miteinander verknüpfte Prozesse. Wer eine alte Definition wiederherstellt, ohne ihre Beziehungen zu prüfen, kann damit neue Störungen verursachen. Deshalb müssen Versionshistorie, Versionsvergleich und Auswirkungsanalyse zusammenspielen. So lässt sich nachvollziehen, was geändert wurde, welche Prozesse betroffen sind und wie die Wiederherstellung gezielt erfolgen kann.

Wenn in kritischen Systemen etwas schiefläuft, müssen Unternehmen vier Fragen beantworten können:

1. Was wurde geändert?

2. Wer hat die Änderung vorgenommen?

3. Welcher war der letzte verlässliche Zustand?

4. Wie schnell lässt sich dieser Zustand wiederherstellen?*

Die ersten beiden Fragen schaffen Nachvollziehbarkeit und klären Verantwortlichkeiten. Die letzten beiden stärken die Resilienz. Ob ein kompromittiertes Konto, ein Insider oder ein menschlicher Fehler die Ursache war: Das zuständige Team muss den Scheduler unter Zeitdruck wieder in einen verlässlichen Zustand versetzen.

Ohne Versionshistorie müssen Definitionen häufig manuell rekonstruiert werden. Mit einer vollständigen Historie wird eine kontrollierte Wiederherstellung möglich.

*Der Aufwand für die Wiederherstellung und die Auswirkungsanalyse hängt von mehreren Faktoren ab: Wie viele Applikationen wurden geändert? Sind auch Vorgänger oder Nachfolger betroffen? Wie viel Zeit ist seit der fehlerhaften oder manipulativen Änderung vergangen? Je nach Ausgangslage lässt sich der korrekte Datenstand schnell wiederherstellen oder erfordert eine umfangreichere Analyse.