Der Terminalserver fällt schon wieder aus: Was ISO 27001 von IT-Dienstleistern verlangt

Dienstagmorgen, kurz nach neun. Der Terminalserver eines Kunden reagiert nicht mehr. Ein Mitarbeiter eröffnet das Incident-Ticket, startet den Server neu, prüft die Anmeldung und meldet dem Kunden: „Läuft wieder.“

Das Ticket kann zu. Der Kunde arbeitet weiter. Alle sind erst einmal zufrieden.

Am Donnerstag passiert genau dasselbe. Und am Montag wieder, sogar zweimal. Inzwischen dauert die Lösung nur noch drei Minuten, weil jeder im Team weiß, welchen Knopf er drücken muss und Andi sogar ein Skript dafür geschrieben hat. Der Betrieb wirkt routiniert. Tatsächlich hat das Unternehmen nur gelernt, dieselbe Störung besonders effizient nicht zu lösen.

Für IT-Dienstleister ist das nicht bloß ein technisches Ärgernis. Wer Kunden-IT betreibt und ein Informationssicherheitsmanagementsystem nach ISO 27001 aufbaut, muss wiederkehrende Abweichungen steuerbar behandeln. Dafür braucht es kein bürokratisches Großprojekt. Aber irgendwann reicht „Neustart und Ticket zu“ eben nicht mehr.

Die kurze Antwort

Ein Neustart darf einen Incident lösen. Der Kunde soll schließlich nicht warten, bis ein Techniker die letzte Speicherzelle persönlich verhört hat. Auch ein Cronjob, der den Terminalserver überwacht und bei Bedarf kontrolliert neu startet, kann ein sinnvoller Workaround sein.

Beides beseitigt jedoch nicht automatisch die Ursache.

Wenn dieselbe Störung immer wieder auftritt, reicht die Wiederherstellung des Dienstes allerdings nicht mehr. Dann muss jemand herausfinden, warum der Server ausfällt, ob andere Kundenumgebungen dasselbe Problem bekommen könnten und ob die dauerhafte Lösung wirklich funktioniert.

Genau diese Denkfolge steckt auch in Abschnitt 10.2 der ISO 27001: erst das akute Problem beherrschen, dann die Ursache untersuchen, vergleichbare Fälle betrachten und die Wirkung der Lösung prüfen. Dafür braucht es keinen Risikoworkshop für jedes Ticket. Es braucht einen Betriebsprozess, der nicht bei der Symptombehandlung aufhört.

Wann der Neustart nicht mehr reicht

Ein einzelner Serverausfall kann schlicht ein einzelner Serverausfall sein. Systeme dürfen Fehler haben, Wartungsfenster dürfen genutzt werden und vereinbarte Verfügbarkeiten enthalten normalerweise keine hundertprozentige Unsterblichkeitsgarantie.

Interessant wird es, wenn aus dem Einzelfall ein Muster wird:

• Derselbe Terminalserver friert regelmäßig ein.
• Mehrere Kunden melden nach demselben Update dieselbe Störung.
• Der vorhandene Workaround stellt den Dienst wieder her, verhindert aber den nächsten Ausfall nicht.
• Die Ausfälle werden häufiger oder dauern länger.
• Das Team kennt den Neustart auswendig, aber niemand kennt die Ursache.
• Der Betrieb erreicht zugesagte Verfügbarkeiten oder eigene Betriebsziele nicht mehr.

Spätestens dann ist das kein Fall mehr für „machen wir beim nächsten Mal wieder genauso“. Der Dienstleister hat ein wiederkehrendes Betriebsproblem. Das Incident-Ticket darf trotzdem geschlossen werden, sobald der Kunde wieder arbeiten kann. Nur die Ursachenuntersuchung darf nicht gemeinsam mit ihm verschwinden.

Ist die Verfügbarkeit der Kunden-IT ein Ziel (vielleicht sogar vertraglich fixiert), sollten die Informationssicherheitsziele nach Abschnitt 6.2 messbar mit dem Betrieb verbunden sein. „Kunden sollen möglichst arbeiten können“ ist kein besonders belastbares Ziel.

Der Cronjob ist ein sinnvoller Workaround – aber keine Ursachenbeseitigung

Nehmen wir an, der Terminalserver friert ungefähr zweimal pro Woche ein. Ein Techniker richtet eine Überwachung ein: Antwortet das System nicht, wird es automatisch neu gestartet. Die Ausfallzeit sinkt von 25 auf fünf Minuten.

Das ist keine schlechte Idee. Der Cronjob erkennt die konkrete Störung und stellt den Service schneller wieder her. Als Workaround ist das völlig legitim. Die Folgen für den Kunden werden kleiner.

Nur beantwortet der Cronjob keine dieser Fragen:

• Hat die Terminalserver-Software ein Speicherleck?
• War ein Update fehlerhaft?
• Reicht die Kapazität für die Anzahl der Sitzungen nicht mehr aus?
• Ist eine bestimmte Konfiguration instabil?
• Stört eine andere Anwendung oder ein Sicherheitsagent den Betrieb?

Vielleicht bleibt der automatische Neustart am Ende die wirtschaftlich sinnvollste Lösung. ISO 27001 verlangt keine Ursachenjagd um jeden Preis. Ungeprüft für erledigt erklären darf man die Ursache aber nicht.

Ein guter Workaround kauft Zeit. Er darf nur nicht als Tarnkappe für ein ungelöstes Problem dienen.

Incident lösen, Problem trotzdem weiterbearbeiten

Der unmittelbare Vorgängerartikel erklärt ausführlich, wie IT-Dienstleister einen Service Request, Incident und ein Problem voneinander unterscheiden. Für unseren Terminalserver reicht diese Kurzfassung:

Das Incident-Ticket kann geschlossen werden, sobald der Service wieder nutzbar ist. Das Problem-Ticket bleibt offen, solange Ursache und dauerhafte Behandlung fehlen. Beide Vorgänge bleiben verknüpft, damit die technische Untersuchung nicht von den konkreten Ausfällen abreißt.

Niemand muss dafür denselben Servernamen, dieselbe Zeitlinie und dieselben Logauszüge mehrfach abschreiben. Das Incident-Ticket dokumentiert den konkreten Kundenausfall. Das Problem-Ticket bündelt die technische Untersuchung und verweist auf die betroffenen Incidents.

Incident Management und Problem Management gehören eng zusammen, bearbeiten aber unterschiedliche Aufgaben.

Der Kunde braucht zuerst seinen Dienst zurück. Der Dienstleister braucht anschließend eine Antwort darauf, weshalb der Ausfall passiert ist und wie er sich künftig verhindern oder wenigstens besser beherrschen lässt. Wer beides in dasselbe Ticket kippt, schließt die Ursachenanalyse häufig genau in dem Moment, in dem der Kunde wieder arbeiten kann.

Was ISO 27001 damit zu tun hat

Die ISO 27001 verlangt nicht, dass Sie ITIL einführen oder jedes technische Problem in ein großes ISMS-Verfahren verwandeln. Sie verlangt aber sehr wohl, dass systematische Fehler nicht ausschließlich mit schöner Farbe übermalt werden.

Das ist keine goldrandige Service-Management-Idee, die wir Ihnen zusätzlich zur Zertifizierung aufdrücken möchten. In Abschnitt 10.2 steht nun einmal, dass nicht nur die sichtbare Auswirkung behoben werden soll. Die Ursache, ähnliche Fälle und die Wirksamkeit der Lösung müssen ebenfalls betrachtet werden.

In der Sprache Ihres Betriebs heißt das: Der Neustart darf den Kunden erst einmal retten. Wenn der Terminalserver aber immer wieder ausfällt, muss jemand herausfinden, warum.

Abschnitt 10.2 lässt sich für den Terminalserver in ziemlich normales Betriebsdeutsch übersetzen:

Die Tiefe muss zum Fall passen. Bei einem einfachen Konfigurationsfehler genügen vielleicht Problem-Ticket, Change und eine Auswertung nach vier Wochen. Bei mehreren betroffenen Kunden braucht es entsprechend mehr.

Entscheidend ist die nachvollziehbare Kette: Ausfall, Sofortreaktion, Ursache, ähnliche Fälle, dauerhafte Maßnahme und Wirksamkeit. Wie viel davon dokumentiert sein muss, erklären wir im Überblick zu den wirklich notwendigen ISO 27001-Dokumenten. Ein neues Formular pro Denkschritt verlangt die Norm jedenfalls nicht.

Wer hat dieselbe Software noch im Einsatz?

Die interessanteste Frage aus Abschnitt 10.2 lautet oft nicht „Ist dieser eine Server wieder oben?“, sondern: „Wo könnte derselbe Fehler noch auftreten?“

Angenommen, die Ursache ist ein Update der Terminalserver-Software. Dann sollte der Dienstleister feststellen können:

• welche Kunden dieselbe Software einsetzen;
• welche Systeme auf derselben Version laufen;
• wo dieselbe problematische Konfiguration verwendet wird;
• wo das Update bereits installiert wurde;
• bei welchen Kunden der Rollout für die nächste Woche geplant ist.

So wird aus der Ursachenanalyse echte Prävention. Statt am Dienstag Kunde A neu zu starten und am Donnerstag überrascht zu erfahren, dass Kunde B jetzt ganz neu dasselbe Problem hat, stoppt der Dienstleister den nächsten Rollout, prüft die betroffenen Systeme und spielt gegebenenfalls direkt den korrigierten Patch ein.

Dafür braucht er auffindbare Informationen über Systeme, Versionen und Abhängigkeiten. Das ist die Brücke zum Asset Management nach ISO 27001. In der ITIL-Fachsprache geht die Betrachtung bei solchen Konfigurationsinformationen in Richtung Configuration Items und Configuration Management. Gemeint ist aber das Gleiche.

Sie brauchen keine CMDB mit dem Beziehungswissen eines Familienromans. Liegt die Antwort auf „Welche Kunden haben diese Version?“ aber nur in Uwes Kopf und Uwe hat Urlaub, endet die Prüfung ziemlich schnell.

Umsetzung ohne Prozessmonster

Niemand muss jeden Incident durch Risikoanalyse, Geschäftsführungspräsentation und feierliche Genehmigung schleusen. Das verlangt Abschnitt 10.2 nicht und kein Service Desk könnte so arbeiten.

Sinnvoller sind klare Schwellen. Ein Problem wird beispielsweise eröffnet, wenn keine bekannte Lösung vorhanden ist, ein Incident wiederkehrt, mehrere Kunden betroffen sein könnten oder ein zugesagtes Betriebsziel nicht mehr erreicht wird.

Technisch kann das sehr schlank aussehen:

1. Das Incident-Ticket dokumentiert Störung, Auswirkungen, Wiederherstellung und Kundenkommunikation.
2. Das verknüpfte Problem-Ticket steuert technische Ursachenanalyse, Workaround, ähnliche Systeme und dauerhafte Änderung.
3. Ein festgelegter Prüftermin sorgt dafür, dass die Maßnahme nicht nur umgesetzt, sondern später auch auf ihre Wirkung kontrolliert wird.

Diese Logik lässt sich in einem vorhandenen Ticketsystem umsetzen. ISO 27001 verlangt weder ITIL noch ein bestimmtes Werkzeug. Problem Management ist einfach etablierte Praxis, die tatsächliche und mögliche Ursachen von Incidents behandelt, um Wahrscheinlichkeit und Auswirkungen weiterer Incidents zu reduzieren. Das ist nützliche Industriesprache, kein Verkaufsauftrag für ein neues Prozessuniversum.

Für ISO 27001 ist entscheidend, dass die notwendigen Betriebsprozesse geplant, umgesetzt und gesteuert werden. Wie Abschnitt 8.1 dabei praktisch funktioniert, behandelt unser Artikel zum Planen und Steuern von ISO 27001-Prozessen. Wer neue Mitarbeiter einstellt, hat nebenbei einen schönen Vorteil: Sie erkennen Begriffe wie Incident, Problem und Workaround wieder und finden sich ratzfatz zurecht.

Typische Fehler

Der Neustart gilt als Ursachenanalyse

Der Server antwortet wieder. Das beweist, dass der Neustart funktioniert hat. Es beweist nicht, weshalb der Server eingefroren ist.

Das Problem wird mit dem Incident geschlossen

Der Kunde kann weiterarbeiten, also wird auch die Ursachenuntersuchung beendet. Beim nächsten Ausfall beginnt dieselbe Suche erneut – oder niemand sucht mehr, weil der Neustart inzwischen so hübsch automatisiert ist.

Jede Kleinigkeit bekommt eine Ursachenanalyse

Damit produziert der Dienstleister eine Flut aus Formalvorgängen und verliert den Blick für echte Wiederholungsmuster. Ein einmaliger Druckerhänger braucht kein zweitägiges Ursachenanalyse-Retreat. Ein Terminalserver, der jeden Montag ausfällt, verdient dagegen mehr als den nächsten Neustart.

Das Problem-Ticket wird zum universellen Sammelbehälter

Dann landen technische Ursachenanalyse, Kundenkommunikation, Change-Freigabe und jede beliebige Verbesserung in einem endlosen Vorgang. Verknüpfte Tickets dürfen unterschiedliche Aufgaben behalten. Der Zusammenhang muss sichtbar sein; alles in ein Feld zu kippen macht ihn nicht klarer.

Ähnliche Systeme werden nicht geprüft

Kunde A bekommt den Patch. Kunde B fällt drei Tage später mit derselben Version aus. Die Organisation hat den Einzelfall repariert, aber nicht aus ihm gelernt.

Die Wirksamkeit wird angenommen

Ein Change wurde durchgeführt und das Ticket sofort als wirksam geschlossen. Ob der Terminalserver zwei Wochen später erneut einfriert, schaut niemand nach. Dabei gehört die Messung der Wirksamkeit von Sicherheitsmaßnahmen zur normalen Managementsystemlogik.

So starten IT-Dienstleister pragmatisch

Nehmen Sie nicht alle Incidents der letzten zehn Jahre. Schauen Sie auf die wiederkehrenden Störungen der vergangenen Wochen und wählen Sie einen saftigen Fall.

1. Benennen Sie den betroffenen Service und das erwartete Betriebsverhalten.
2. Verknüpfen Sie die bisherigen Incident-Tickets.
3. Halten Sie den aktuellen Workaround fest.
4. Eröffnen Sie ein Problem und untersuchen Sie die Ursache.
5. Prüfen Sie, welche ähnlichen Systeme oder Kundenumgebungen betroffen sein könnten.
6. Setzen Sie die notwendige technische oder organisatorische Maßnahme um.
7. Legen Sie fest, woran und wann Sie deren Wirksamkeit erkennen.

Damit entsteht kein Prozessmonster. Es entsteht ein Betrieb, der nicht nur schneller auf bekannte Störungen reagiert, sondern dauerhaft weniger davon produziert. Genau das ist die Art prozessualer Struktur, die ISO 27001 für IT-Dienstleister deutlich einfacher macht.

Interesse geweckt?

Sie betreiben IT für Kunden und möchten wiederkehrende Störungen so behandeln, dass Betrieb und ISMS zusammenpassen? Sprechen Sie mit uns.