Weiterbildung

Kein SLA ohne OLA – sonst droht ein GAU

30. Juni 2020

Zertifizierte Kompetenz, um Angriffe abzuwehren und Werte zu schützen auf der Basis von BSI/ISO. Darum geht es in 15 intensiven Tagen unseres Lehrgangs. Neben Risikoanalysen, Security Frameworks und einem Deep Dive in Cybersecurity-Technologien, schreiben unsere Absolventinnen und Absolventen einen Blogbeitrag. Dieser ist von Sascha Maier.

Jede IT-Organisation kennt Service Level Agreements, um die Services externer Dienstleister zu definieren und deren Verfügbarkeit abzusichern. Wie aber stellt man sicher, dass die zum Erbringen der Dienste benötigten internen Kolleginnen und Kollegen auch alle im Bild sind? Die Antwort: OLA.

An sich sollte es kein Service Level Agreement (SLA) ohne Operational Level Agreement (OLA) geben: SLAs sind nach außen gerichtet und schreiben die Services beziehungsweise deren Verfügbarkeit zwischen Kunden und IT-Dienstleistern sowie Hosting- oder Cloud-Providern fest. Die interne IT-Organisation ist in diesem Fall der Service-Nehmer. Gegenüber den internen Kunden, also den Fachabteilungen des eigenen Unternehmens, tritt die IT als Service-Geber auf – und sollten daher per OLA genau regeln, was von wem zu tun ist.

OLAs sind daher unabdingbar, um die in den SLAs festgehaltenen Ziele erreichen und die hierzu notwendigen Systeme implementieren zu können. Die in einem SLA meist allgemeiner gehaltenen Ziele lassen sich per OLA genauer spezifizieren und somit Rollen, Verantwortungen, Aktionen, Abläufe, Richtlinien festschreiben.

Ein Beispiel: Per SLA verpflichtet die Organisation einen externen Sicherheitsspezialisten, binnen einer Stunde auf eine E-Mail zu reagieren, die über den Ausfall einer Firewall informiert. Binnen fünf Stunden muss der Dienstleister im Zweifel vor Ort sein können, inklusive eines vorkonfigurierten Austauschgeräts. Im dazu gehörigen OLA hält die IT-Organisation fest, wer bei einem Ausfall einer Firewall über welchen Kommunikationsweg die notwendigen Mitspieler innerhalb und ausserhalb des Unternehmens informiert und wie lange der Ausfall dauern darf.

Ein OLA hilft Fachabteilungen auch, wenn sie beispielsweise Änderungen an Firewall-Ports wünschen oder eine neue Cloud-Anwendung nutzen wollen. Das Dokument beschreibt nicht nur den hierfür notwendigen Prozess, inklusive Kommunikationsweg. Es sichert auch den Zeitraum zu, innerhalb dessen die Anfrage abgearbeitet werden soll.

Und jetzt alle zusammen
Unabdingbar sind Operational Level Agreements, wenn mehrere Fachabteilungen gleichzeitig ans Werk müssen. Typischerweise ist das bei einem Datenleck aufgrund eines erfolgreichen Angriffs oder anderen Sicherheitsvorfalls nötig. Hier müssen neben den IT-Spezialisten Kolleginnen und Kollegen aus der Unternehmenskommunikation und der Rechtsabteilung aktiv werden. Wahrscheinlich unterstützt von externen Fachleuten für IT-Forensik oder Krisenkommunikation.

Damit die Beteiligten – insbesondere die externen Zuarbeiter – im OLA festgehalten werden können, müssen sie zuvor bekannt sein. Was nach einer Binsenweisheit klingt, ist in der Praxis aber mangels Threat Modelling oftmals Mangelware: Die meisten IT-Organisationen schauen sich beispielsweise erst dann nach einem Anti-DoS-Dienstleister um, wenn das eigene Netzwerk schon unter der Last der Angriffswelle zusammengebrochen ist. Wählt man im Eifer des Gefechts den erstbesten Retter, geraten wichtige Punkte wie DSGVO-Compliance wahrscheinlich unter die Räder. Ausserdem lassen sich in Friedenszeiten bessere Stundensätze mit Anwaltskanzleien und Forensik-Spezialisten aushandeln, als es der Druck durch den laufenden Sicherheitsvorfall zuliesse.

OLA und SLA Hand in Hand
Nutzt eine Organisation ein OLA zur sinnvollen Dokumentation eines Prozesses, ergibt sich hieraus noch ein weiterer Vorteil: Die zugesicherten Ziele lassen sich trotz eventueller Personalwechsel einhalten. Es gibt keine Kopfmonopole in der Organisation und alle Beteiligten können die ihnen zugedachten Aufgaben auf dem gleichen Qualitätsstandard erbringen.

Wie bereits erwähnt, müssen OLA und SLA aneinander angelehnt werden. Ein SLA darf also beispielsweise keinesfalls längere Reaktionszeiten festschreiben als ein nach innen gerichtetes OLA. Umgekehrt gilt es, die SLA zu überarbeiten, wenn auf Wunsch von Fachabteilungen neue Vorgaben in OLAs gegossen wurden. Nur wenn die beiden Vereinbarungen Hand in Hand gehen, lassen sich geplatzte Versprechungen und die daraus resultierenden Probleme vermeiden.

Tipps zum Erstellen eines OLA
Nachdem das Dokument für sich alleine stehen und sprechen muss, sollte es zu Beginn in ein, zwei Absätzen den Zweck des Dokuments umreissen. Nur wenn ein Leser versteht, dass sich das Folgende auf das Szenario „Firewall-Wartung“, den Ablauf „Neue Cloud-Anwendung“ oder „Stopfen eines Datenlecks“ bezieht, kann der Inhalt des OLA verstanden werden.

Ausserdem sollten möglichst zu Beginn sämtliche Service- und Compliance-Ziele aufgelistet werden. Insbesondere letztere können zu Einschränkungen führen – keine unverschlüsselten Bezahlkartendaten in Cloud-Anwendungen, keine beliebig langen Speicherfristen von Kundendaten und so weiter –, so dass Leserinnen und Leser mit diesen Vorgaben vertraut gemacht werden müssen.

Natürlich gilt es, sämtliche am jeweiligen Prozess Beteiligten aufzulisten. Je nach dem für den Prozess ebenfalls festzuschreibenden Kommunikationskanal – Telefon, Instant Messenger, E-Mail, Ticketing-System und so weiter – sollten die jeweiligen Kontaktdaten gleich mit aufgenommen werden. Ausserdem ist sicherzustellen, dass die ausgewählten Kommunikationsmechanismen funktionieren, beziehungsweise bei Schichtbetrieb für die jeweils Schichthabenden auch zugänglich sind.

Zu guter Letzt gilt es, das Dokument allen Beteiligten zugänglich zu machen. Auf einem Fileshare mit entsprechenden Zugriffsrechten, im Intranet oder zur Not auf Papier. Denn die beste Dokumentation ist nutzlos, wenn nur der Verfasser oder die Verfasserin Zugriff hat.

Autor: Sascha Maier