Warum BCM und IT-Notfallhandbuch notwendig sind und wie das ganze mit ISMS/ISO und Risiko-Management zu verstehen ist

Vorwort

Ganz als erstes: nein, ich gendere nicht! Wem das missfällt darf gern meinen Blog ignorieren.

Als ich vor ~25 Jahren in der IT angefangen hatte gab es da nur diese einzige heilige Kuh: das Warenwirtschaftssystem (auf einer AS400). Alles andere war „Randdeko“, so auch das von mir betreute CAD-Möbelplanungssystem. So richtig wahr haben wollte damals keiner, dass auch dieses System für das Business absolut notwendig war, weil keiner aus der Entscheiderebene so recht wusste, was technisch alles dahintersteckte. Somit bekam das „WaWi-Team“ auch alles genehmigt, was beim Rest der IT-Abteilung oft in ewige Verhandlungsrunden führte.

Seither wuchs die IT immer mehr, neue Systemarten kamen hinzu, andere wurden fusioniert oder bestehen immer noch.

Umso wichtiger wurde es, gerade in den letzten 5-10 Jahren, zu verstehen: wie funktioniert UNSER BUSINESS eigentlich. Anders beschrieben als Frage: wie verdienen wir als Firma eigentlich unser Geld und womit wird es erwirtschaftet? Und wir gerade dabei sind: Was tun, damit dieses Business optimal abgesichert ist und wir möglichst keinen Verdienstausfall erleben müssen? Hier kam der für viele neue Begriff „BCM“ (Business Continuity Management) in die Verwaltungsetagen und somit auch in die IT. Leider für viele gestandene und auch leitende IT’ler immer noch ein Fremdwort. Mitunter wurde häufig das Verständnis für heute gängige Management-Praktiken durch verschiedenste Gründe an der IT vorbei etabliert. Und plötzlich wird dieses Wissen von der IT eingefordert und somit die IT-Mitarbeiter überfordert.

In KRITIS-Umgebungen oder zertifizierten Unternehmen ist ein ISMS der tragende Motor für nahezu jeden Fachbereich. Von daher wird das meiste über diese Wege gesteuert und vorgegeben. Dennoch ist auch dort BCM notwendig, wenn auch deutlich weniger publiziert.

Ein weitere Schlagwort lautet „Risiko-Management“. Und wer ein „Risk-Management“ etabliert hat möchte und muss auch ein sinnvollerweise ein Notfall-Management haben. Und schon sind wir beim eigentlichen Thema angekommen.

 

Was macht das BCM nun eigentlich so sinnvoll und wichtig?

Das BCM ist eigentlich ein eigener Prozess innerhalb des Unternehmens. Er hat Verantwortlichkeiten und wird durch Personenbeteiligung umgesetzt. Der Prozess „BCM“ dient der Suche, Benennung und Erkennung von möglichen Bedrohungen der Geschäftsprozesse.

Nehmen wir ein von mir häufig genutztes fiktives Beispiel zur Erklärung, da ihn komischerweise jeder versteht und begreift: der Prozess „Lohnzahlung“.

Für die Lohnzahlung in einem kleineren Unternehmen benötigen wir:

• Software
• Rechner
• Datenbank
• WAN-Anbindung (für Anbindung zur Bank)
• 2 Personen (Lohnbuchhalter, Manager)

Stellen wir uns vor: die Person (Lohnbuchhalter) fällt komplett aus durch irgendeinen Umstand (Krankheit, Unfall etc.).  Keiner sonst hat die Pin’s für die Bankverbindung. Der Manager kann nur dann das „Go“ geben (Approval), wenn der Lohnbuchhalter die Überweisungen der Mitarbeiterentlohung fertig gemacht hat. Das Geld wird nicht überwiesen, die Mitarbeiter erhalten keinen Lohn. Was passiert (fiktiv):

• Nach 5 Tagen gibt es ein unüberhörbares Murren
• Nach 10 Tagen sind die ersten in Krankschreibung, andere suchen schon neue Arbeitsstellen
• Nach 30 Tagen (1 Monat) kommen einige gar nicht mehr auf Arbeit
• Nach 60 Tagen…das spare ich mir jetzt mal.

Dieses Beispiel ist wie gesagt rein fiktiv, dennoch zeigt es auf: ich sollte mir Gedanken machen, wie ich diese Prozess absichere. Und dazu muss ich jedes notwendige Puzzleteil (Software, Rechner, Datenbank, WAN-Anbindung, Personal) berücksichtigen.

 

Somit sollte also klar sein: BCM ist EIGENTLICH ein wichtiger Baustein im Arbeitsalltag. Und somit auch in der IT. Daher ist die Beschreibung von Prozessen, Services, Anwendungen und Systeme unabdingbar. Warum, dazu auch ein Beispiel.

• Der Server „Server1“ hat MS-SQL-Instanzen laufen.
  • Eine der SQL-Instanzen inkludiert eine Datenbank „Anwendungsdatenbank-X“
  • Die Instanz ist ein Service
• Ein anderer Server (Server2) hat die Software „Anwendung-X“ installiert, welche alle Daten in die „Anwendungsdatenbank-X“ auf „Server1“ schreibt.
• Damit „Anwendung-X“ funktioniert ist ein weiterer Service „LDAP“ zur Authentifizierung nötig, welcher auf „Server3“ bereitgestellt ist (Active Directory-DC)
• Die „Anwendung-X“ wird zur Umsetzung der täglichen Arbeit in der „Fachabteilung-A“ benötigt
• Ein Kernprozess im Unternehmen ist „Prozess-Vertrieb“, nämlich der Verkauf der Ware
• Die „Fachabteilung-A“ ist die Vertriebsabteilung, welche „Anwendung-X“ zu über 90% Ihrer Arbeit nutzt.

Wir haben also eine Prozesskette, welche vom Prozess aus nach unten über Abteilung, Anwendung und Services einen Host (unser Server 1+2+3) deren Notwendigkeit für das Business festlegt.

Aus dem Beispiel heraus kann man erkennen, wozu also ein BCM wichtig und sinnvoll ist. Und dieses hilft generell beim Verständnis für ein Unternehmen, egal ob neuer Mitarbeiter, externer Dienstleister oder interne Mitarbeiter.

Faktor ISMS/ISO und das Risk-Management

Aufbauend auf dem BCM und in direktem Zusammenspiel mit ISMS/ISO kommt der Faktor Risikomanagement in der Matrix hinzu. Hier geht es aber mehr darum, dass Unternehmensprozesse in Ihrem Risiko bewertet werden und diese dann die Wichtigkeit einer Maschine/eines Services/einer Anwendung benennen.

Wenn wir es mal recht einfach zusammenfassen: in unserem Beispiel oben also heruntergebrochen die „Anwendung-X“, die „Anwendungsdatenbank-X“ und die „Server1+2+3“. Wenn eine oder mehrere dieser Komponenten nicht verfügbar ist, steht der Prozess „Vertrieb“ still. Und wie wichtig der Prozess „Vertrieb“ im Unternehmen ist, muss halt von der Unternehmensleitung festgelegt werden (mit ISMS). Wie man mit dem Risiko des Ausfalles umgeht, regelt dann das Risk-Management.

 

Wozu aber ein IT-Notfallhandbuch

Nutzen wir auch wieder ein praktisches Beispiel anhand unserer obigen Situation.

Vertriebs- „Mitarbeiterin A“ kommt früh an ihren Arbeitsplatz, startet ihre „Anwendung-x“ und diese funktioniert nicht. Sie ruft hektisch und emotional geprägt Admin-A an und informiert über die Situation:

„Hier geht gar nichts, ich kann überhaupt nicht arbeiten!“

Kommt das bekannt vor? Ich denke schon. Problem hierbei: die Emotion der Kollegin. Denn es geht tatsächlich alles andere (Mail, Web etc.), lediglich „Anwendung-X“ ist gestört.

Nun wäre es doch gut, wenn zunächst ein Prozess zur Fehleranalyse und -eingrenzung ablaufen würde:

• Geht es bei alle Kollegen nicht oder nur bei „Mitarbeiterin A“
• Wenn bei allen nicht liegt es an Anwendung, Datenbank oder Server

Erkenntnis: Prozesse zur Fehleranalyse sind in der IT eigentlich Pflicht! Und dann müssen daraus ORGANISATORISCHE Maßnahmen abgeleitet werden. Fragestellung hierbei: „Was tun wenn…“.

Die Tragik dabei: ein IT-Notfallhandbuch ersetzt kein Betriebshandbuch oder eine fachliche Wiederherstellungsanleitung, das wird leider sehr oft verwechselt! Nein, es regelt die organisatorischen Abläufe wie z.B.:

• Wenn Provider-WAN-Leitung nicht verfügbar ist…
  • Wen informiere ich bzw. wen beziehe ich ein
  • Welche Daten brauche ich (Kundenkennwort, Leitungsnummer)
  • Wo rufe ich an
• Wenn Fachanwendung gestört ist und ich als IT-Mitarbeiter mich in der Software nicht auskenne…
  • Wer ist der primäre interne Ansprechpartner
  • Wer bietet Support

Weiterhin führt das IT-Notfallhandbuch Dinge gelistet auf:

• Primäre IT-Systeme und deren Wartungslevel (USV, phsische Server)
• Notfallausrüstung (Medien, Unterlagen, Listen, Kabel)
• Zuständigkeiten für Prozesse, Services und Anwendungen
• Primärmaßnahmen für festgelegte Ereignisse
• Bewertungslisten:
  • Was ist eine Störung
  • Was ist ein Notfall / eine Krisensituation

Zum Abschluss einfach und salopp formuliert: wenn das Ereignis „Stromausfall im Serverraum“ eintritt, ruft man ja nicht Feuerwehr und Putzfrau an, sondern die passenden Leute!

DAS ist es, was in ein IT-Notfallhandbuch gehört. Alle anderen Dinge gehören in z.B.

• „Neuinstallation eines Hypervisors“ = Betriebsdokumentation.
• „Server1“ wird als 3tes System angeschaltet = Wiederherstellungsplanung.

 

 

Ich hoffe mein Beitrag hilft in der Bewertung und dem Verständnis für die Komplexität dieser Dinge. Danke für’s lesen!