Grüße von der langen Bank – Dauerbaustellen der Security (11) : Und die Moral von der Geschicht? : Wie man Security-Projekte in Gang bringt und hält

Von Bettina Weßelmann und Johannes Wiele, München

Die erste Folge der „Lange-Bank“-Serie ist schon Mitte 2016 erschienen – da muss selbst das Autorenteam ins Archiv schauen, um sich die konkrete Liste der behandelten Dauerbaustellen wieder zu vergegenwärtigen:

• Aufbau und unternehmensinterne Verankerung eines Security-Operations-Centers (SOC – <kes> 2016#3, S. 50)
• Erhebung von Kontextinformationen für moderne Security-Tools (CMDB, Asset-Datenbank, <kes> 2016#4, S. 26)
• Informationsklassifizierung (<kes> 2016#5, S. 70)
• Sinnvolle SIEM-Architektur (<kes> 2016#6, S. 60)
• Innovationsmanagement (<kes> 2017#1, S. 12)
• Brückenschlag zum Datenschutz (<kes> 2017#2, S. 48)
• Einbindung von Produktionsumgebungen (OT, ICS – <kes> 2017#3, S. 6)
• Etablieren einer organisationsweiten Sicherheitskultur (<kes> 2017#5, S. 18)
• Netzwerksegmentierung (<kes> 2017#6, S. 62)
• Identitätsmanagement(<kes> 2018#1, S. 22)

Und irgendwie gehört außerdem noch der leicht provokante „Flop-up oder Bottom-down?“-Beitrag aus Heft 2017#6 (S. 15) zur Serie, der sich mit den Nachteilen der Bottom-up-Vorgehensweise bei Security-Projekten befasst hat, bei denen die Initiative allein von der technischen Security ausgeht und die Akteure versuchen, die Managementperspektive zu umgehen.

Ein etwas genauerer Blick auf diese Liste offenbart, dass nicht alle aufgegriffenen Themen auf der gleichen Ebene angesiedelt sind: Die Bereitstellung von Kontextinformationen etwa und die Informationsklassifizierung sind Voraussetzungen, deren Fehlen diverse andere Projekte wie SOC-Aufbau oder Netzwerksegmentierung behindern – und das Identitätsmanagement steht mit praktisch allen anderen diskutierten Themen in Verbindung. Wollte man eine Hierarchie der in der Serie behandelten Themen aufbauen, würden diese drei weit nach oben gehören.

Betrachtet man außerdem die praktischen Ratschläge, die das Autorenteam jeweils zur Behebung von Projekthindernissen zusammengestellt hat, fallen zwei Punkte immer wieder ins Auge: Die Forderung nach kommunikativem und nach kooperativem Vorgehen. Das brachte uns auf die Idee, für unseren generalisierenden Abschlussbeitrag auf fünf zentrale Stichworte zu verweisen, die mit hilfreichen Ansätzen für besser beherrschbare Securitymaßnahmen verbunden sind: Kooperation, Kommunikation, Klassifizierung, Kontextinformation und Abstraktion.

Wenn man diesen fünf Begriffen und den dahinterstehen den Konzepten Beachtung schenkt, kommen Security-Projekte schneller und effektiver voran. „Kooperation“ und „Kommunikation“ stehen für geeignete Vorgehensweisen, während es bei den Aspekten „Klassifizierung“, „Kontextinformation“ und „Abstraktion“ um das Schaffen hilfreicher Voraussetzungen geht.

Kooperation

Kooperativ angelegte Security-Projekte binden alle Institutionen einer Organisation, die von den Vorhaben betroffen sind, von vornherein in Planung und Praxis ein. „Kooperation“ ist der Gegenentwurf zur verbreiteten Strategie, potenziell konfliktträchtige Projekte erst einmal so weit wie möglich „ungestört“ voranzutreiben, vollendete und damit vermeintlich stabile Tatsachen zu schaffen und mögliche Zweifler so spät mit dem jeweiligen Projekt zu konfrontieren, wie es nur geht.

Die Tendenz zur Verheimlichung, die sich in manchen Security-Teams noch immer feststellen lässt, hat historische Gründe: Fachabteilungen für IT- und Informations-Sicherheit hatten in der Vergangenheit mit einer noch unterentwickelten Cyberkriminalität häufig den Ruf, „Verhinderer“ produktiver Lösungen zu sein, vornehmlich als Bedenkenträger aufzutreten oder einfach einen Kostenfaktor darzustellen, den es möglichst kleinzuhalten galt.

In den meisten Organisationen hat sich dies allerdings inzwischen fundamental geändert, da das Management direkt mit gesetzlichen Anforderungen, Mindeststandards von Branchenverbänden oder hartnäckigen Fragen von Kunden und Partnern konfrontiert wird, die allesamt dieselbe Grundaussage vermitteln: Ohne solide Basis in Sachen Informationssicherheit und/oder Datenschutz geht geschäftlich heute nicht mehr viel.

Securityspezialisten sollten sich vor diesem Hintergrund genau überlegen, wie sie im Unternehmen auftreten, und die Verstecktaktik hinter sich lassen. Wenn sie Projekte mit gutem Grund „Bottom-up“ aufsetzen, also aus eigener Initiative und nicht auf Order des Managements hin starten, dürfen sie durchaus selbstsicher agieren – und zwar als unverzichtbarer Dienstleister und als potenzieller Überlebensgarant der Organisation, der seine Anliegen als Beiträge zum Unternehmenserfolg jederzeit vortragen kann.

Dennoch lohnt es sich, strategisch vorzugehen, um sich nicht ausgerechnet zu Beginn an denjenigen Positionen aufreiben zu müssen, die Security-Projekten auch heute noch Widerstand entgegensetzen. Manager, die den Wert von Security und Datenschutz für ein Unternehmen oder eine öffentliche Organisation überhaupt nicht anerkennen, stellen inzwischen zwar eine aussterbende Splittergattung der Spezies Unternehmensleitung dar. Im mittleren Management aber verläuft die Wachablösung noch eher langsam.

Problematische Mitte

Die Ursache dafür lässt sich an einem Beispiel gut demonstrieren: In einem produzierenden Betrieb, der etwa als Zulieferer für den Maschinenbau oder die Automobilindustrie fungiert, bekommen die Vorstands- oder Leitungsebene und der verhandelnde Verkauf unmittelbar mit, dass Großkunden den Nachweis professioneller Informationssicherheit einfordern oder zur harten Bedingung für die Teilnahme an Ausschreibungen machen. Kommt es in diesem Zusammenhang zu direkten Audits durch Kunden, Branchenvertreter oder Partner, laufen diese Prüfungen allerdings bei den Abteilungen für IT, IT-Security, Informations- oder Unternehmenssicherheit und gegebenenfalls Datenschutz auf. Bei den Verantwortlichen für einzelne Werke oder Produktionsprozesse kommt die Dringlichkeit der neuen Anforderungen dagegen nur mittelbar an – nicht zuletzt, weil die Verantwortung für die Erfüllung der Kooperationsbedingungen aus Sicht der Leitung bei den oben genannten Security-Departments liegt.

Aus diesem Grund spüren Angehörige des mittleren Managements in modernen Unternehmen häufig den geringsten Druck, dem Thema Sicherheit größere Priorität einzuräumen. Für sie bleibt das Erfüllen monetärer Business-Vorgaben oder der Verfügbarkeit eines Produktionsprozesses deshalb oberstes Ziel. Landet man als Securityspezialist ausgerechnet auf dieser Ebene mit Forderungen nach potenziell hinderlichen Prozessänderungen oder zusätzlichem Budget, ist die Wahrscheinlichkeit wohlwollender Aufnahme am geringsten.

Eine typische moderne Organisation umfasst somit eine wachsende Zahl von Security-Befürwortern und zugleich eine sinkende Zahl von Personen, die den Wert der Sicherheitsbemühungen geringschätzen – aber durch aus noch über Macht und Blockadepotenzial verfügen. Projektleiter oder -initiatoren mit Sicherheitszielen sollten deshalb direkt zu Beginn ihrer Tätigkeit erst einmal eine Landkarte aller Abteilungen und „Stakeholder“ in ihrer Organisation erstellen, die von ihrem Projekt profitieren könnten.

Dauerbaustellen der Security – Infos zur Serie

Die <kes>-Serie „Grüße von der langen Bank“ widmete sich Security-Themen, die in Organisationen gern „vergessen“ oder aus anderen Gründen nicht in Angriff genommen werden – und sich dann bei Sicherheitsprojekten als gefährliche Showstopper erweisen. Alle Beiträge beschrieben die jeweilige Situation, arbeiteten mögliche Gründe auf, zeigten die wahrscheinlichen Folgen und versuchten schließlich zu erklären, wie sich Mängel am besten und schnellsten beheben lassen.

Partnersuche

Häufig entpuppen sich Compliance-Abteilungen, etwa für Datenschutz oder die Sicherheit von Finanzdaten (z.B. Kreditkarteninformationen), nicht etwa als mögliche Gegner, sondern vielmehr als potenzielle Kooperateure. Denn in diesen Bereichen müssen harte Audits überstanden werden, die darüber entscheiden, ob ein Unternehmen in seinem Geschäftsfeld überhaupt agieren darf oder nicht.

Bietet die Security hier gezielt prüfungsgerechten Zugriff auf Assetdaten, Logfiles oder gar SIEM-Auswertungen an, kann dies die Bewältigung konkreter Audits erheblich erleichtern – und die Security darf neue Fürsprecher für ihr Tun verbuchen, denn schnellere Audits und eine höhere Wahrscheinlichkeit, Prüfungen tatsächlich zu bestehen, lassen sich durchaus „hart“ in reduzierte Geschäftsrisiken und finanzielle Einsparungen umrechnen.

Mit den neuen internen Partnern lässt sich dann auch der Widerstand von Managern überwinden, die für ihre Tätigkeiten keinen direkten Gewinn aus Security-Aktivitäten ableiten können. Mit dem Faktor „Kooperation“ ist also gemeint: Security-Akteure sollten im Unternehmen aktiv nach Managern suchen, die sich von ihrer Tätigkeit Vorteile beim Erreichen eigener Ziele versprechen dürfen, und sie sollten ihre Projekte in die Form eines Service-Angebots kleiden. Dies bedeutet allerdings auch, kompromissbereit zu sein – Sicherheitsrisiken sind nun einmal eine Teilmenge der Geschäftsrisiken, und die Kosten für Sicherheitsmaßnahmen müssen deshalb auch ganz pragmatisch an ihrem potenziellen Beitrag für den Geschäftserfolg und das Erzielen des primären Geschäftszwecks gemessen werden.

Das Beharren auf Auswahlkriterien für Verfahren und Lösungen, die allein technische Perfektion zum Ziel haben, ist deshalb aussichtslos und kontraproduktiv, wenn das abzuwehrende Risiko nicht selbst absolute Perfektion verlangt. Die Forderung, Sicherheit müsse immer als „hinreichend“ und nicht als „absolut“ gedacht werden, findet hier ihren Anker in der Realität.

Kommunikation

Wer sich kooperationsbereit zeigen will, muss dies auch mitteilen können. Fast alle Beiträge der „LangeBank“-Reihe zeigen, dass Security-Projekte nur dann vorankommen, wenn die dafür Verantwortlichen mit den unterschiedlichsten Abteilungen in einer Organisation erfolgreich kommunizieren. Abstrakt heißt dies zunächst, dass die Sicherheitsfachleute ihre Positionen so aufzubereiten haben, dass auch Nicht-Kollegen die Argumentationen nachvollziehen können. Mit purer Ausrichtung auf Allgemeinverständlichkeit ist es aber noch nicht getan – es gilt auch, die Ziele und Positionen unterschiedlichster anderer Departments vorherzusehen und auf die Arbeitsbedingungen und rollenbedingten Präferenzen potenzieller Kooperationspartner (siehe oben) im Dialog einzugehen. Nur wer zielgruppengerecht argumentiert, findet Anklang und Budget-Support.

Bei „Bottom-up“-Projekten ist dies vielleicht eine jener Anforderungen der Security-Praxis, die am schwierigsten zu erfüllen sind. IT-Security-Fachleute bekommen während ihres Studiums und ihrer Ausbildungsgänge gewöhnlich keine besondere Förderung zur fachübergreifenden Präsentation und Aufbereitung ihrer Themen – und oft genug haben sie den technischen Karriereweg ja gerade gewählt, um der als „schwammig“ empfundenen Welt der eleganten Formulierungen, diplomatischen Gesprächsführungen und grafischen Aufbereitungsleistungen zu entgehen. Diese Flucht mündet heute allerdings unweigerlich in Erfolgs- und Karriereknicks.

Unternehmensgerechte Security kommt um intensive Abstimmung mit Juristen, Businessmanagern, Datenschützern, Krisenmanagern und anderen aus Sicht der Security-Technik „fachfremden“ Akteuren einfach nicht mehr herum – sie ist sonst nicht mehr zeitgemäß und kann ihre Anliegen nicht durchsetzen.

Der Ausweg heißt: heterogene Teams. Wo sich niemand aus dem engeren Security-Stab auf die Kür der fachübergreifenden Präsentationen einlassen mag oder faktisch niemand diese Kunst hinreichend beherrscht, muss man externe Dienstleistungen einkaufen – oder die Abteilung sollte sich gezielt bemühen, selbst ein paar Spezialisten für kommunikativen Brückenbau und interdisziplinäre Kommunikation ins Boot zu holen.

Ein Tipp: Versuchen Sie gegebenenfalls, Zeitbudgets von technikaffinen Mitarbeitern der Marketingabteilung abzugreifen. Ein derartiges „Cross-over“ kann zu erstaunlichen Ergebnissen führen, denn es zwingt die Sicherheitstechniker, ihre Anliegen zunächst im Dialog mit neutralen, gutwilligen Partnern zu erläutern, ohne dass den „Nerds“ zugleich auch der Zwang auferlegt wird, ihre Gedanken selbst in eine sprachlich oder grafisch ansprechende Form gießen zu müssen. Diesen Schritt übernimmt dann der Kommunikationsspezialist oder die Kommunikationsspezialistin – und wenn ihm oder ihr keine korrekte Darstellung auf der Basis der vorangegangenen technischen Ausführungen gelingt, darf die Securityabteilung getrost davon ausgehen, dass ihr auch der direkte Versuch einer Darstellung für fachfremdes Publikum misslungen wäre.

Klassifizierung

Es hört sich so simpel an: Das richtige Maß an Sicherheit für eine bestimmte Sorte von Informationen und Systemen findet nur, wer sich zuvor darüber Gedanken gemacht hat, welche Folgen eine Verletzung der fraglichen Assets haben könnte. Sowohl die Effektivität präventiver Maßnahmen als auch der Erfolg der Abwehr laufender Angriffe hängen davon ab, dass die wichtigsten Daten und Systeme mit Priorität geschützt werden und man vor allem die Energie der teuren Security-Analysten nicht auf Unwichtiges verschwendet. Dazu muss für alles Wichtige in einer Organisation eine sicherheits- und risikobezogene Klassifizierung vorliegen, auf die alle Security-Prozesse und -Lösungen zugreifen können.

Die einzige Alternative läge darin, wirklich alles in einer Organisation – von Finanzdaten wichtiger Kunden über Produktionsrezepturen bis hin zur Löffelzahl in der Kantine – mit der gleichen Intensität zu überwachen. Das allerdings kann sich keine Organisation finanziell leisten. Die risikobezogene Klassifizierung möglichst vieler Entitäten ist somit eine der zentralen Voraussetzungen dafür, dass Security-Projekte erfolgreich sein können.

Klassifizierung als Tätigkeit ist allerdings ein schwieriges Geschäft. Geht es um Informationen, für die allgemein akzeptierte Vorschriften vorliegen (wie es etwa bei personenbezogenen Daten oder Informationen von Kreditkarteninhabern der Fall ist), lässt sich eine Einstufung (hier im Bereich der Vertraulichkeit) noch vergleichsweise einfach durchführen.

Bei anderen, individuelleren Positionen (bspw. Produktions- und Geschäftsprozesse, Firmengeheimnisse, interne Geschäftsdaten) stößt man weit eher auf Schwierigkeiten. Zwingt man Mitarbeiter dazu, solche Assets auf Risiken hin zu bewerten, ohne ihnen praxisgerechte Hilfen dafür an die Hand zu geben, endet das Projekt allzu leicht in unendlicher Vertagung oder dem verzweifelten Versuch, allem die höchste Security-Stufe angedeihen zu lassen, um nur kein weiteres Risiko heraufzubeschwören.

Hier der Rat: Besser gut geschätzt als gar nicht klassifiziert – und wo die Teams auch mit Beispielen und Schulungen nicht weiterkommen, klärt man die Schutzbedarfs- und Risikostufen am besten in Workshops, bei denen die Einstufung im Dialog vorgenommen wird. Diskussionen von Vertretern unterschiedlicher Abteilungen, die ein wirklich anschauliches Bild von der Bedeutung bestimmter Informationen für Prozesse und Leistungen eines Unternehmens vermitteln können, führen oft erstaunlich schnell zu einer sinnvollen Einstufung strittiger Objekte. Detailliertere Tipps liefert der Klassifizierungsbeitrag unserer Serie, der in <kes> 2016#5 unter dem Titel: „Was schützen wir hier eigentlich?“ erschienen ist.

Das kooperativ (siehe oben) erhobene Ergebnis der Klassifizierung gehört dann in eine Asset-Datenbank oder Configuration-Management-Database (CMDB), die unterschiedlichsten Konzepten und Systemen von der Netzwerk-Segmentierung bis hin zum Security-Operations-Center (SOC) zur Verfügung steht – und damit landet man beim Thema „Kontextinformation“, mit dem sich die Folge „Haie fischt man nicht im Trüben“ in Ausgabe 2016#4 befasst hat.

Kontextinformation

„Kontext“-Informationen im Sinne dieses Beitrags sind alle Daten, die bei einer Schutzbedarfseinstufung für ein System oder ein Informationscluster in einer Organisation eine Rolle spielen können. Häufig von Bedeutung sind folgende Aspekte:

• Art der Daten oder Zweck des verarbeitenden/speichernden Systems
• Compliance-Umfeld (Vorgaben)
• aktueller Security-Status (Schwachstellen, bereits aktivierte Schutzmaßnahmen)
• Klassifizierung/Risikoeinstufung nach Verfügbarkeit, Integrität und Vertraulichkeit
• Anwenderkreis/Zugriffsberechtigte
• Konnektivität (zur Ermittlung denkbarer Angriffsszenarien)

Wie im oben erwähnten Beitrag ausführlich dargestellt, werden diese Informationen deshalb immer wichtiger, weil moderne Security-Lösungen zunehmend automatisch Schutz-Prioritäten anhand des jeweils aktuellen Bedrohungspotenzials setzen können und sollen, um das Personal in den chronisch unterbesetzten SOC zu entlasten. Dazu müssen die Werkzeuge in der Lage sein, von außen eingespielte Security-Intelligence-Informationen auf den vorhandenen Informations- und Systembestand anzuwenden. Erreicht sie etwa die Auskunft, dass Cyberkriminelle weltweit eine groß angelegte Kampagne zur Exfiltration von Patientendaten gestartet haben, müssen sie feststellen, ob derartige Gesundheitsdaten in der Organisation vorhanden sind, wo sie sich befinden und wie angreifbar sie sind. Außerdem sollen zum Beispiel Re-Klassifizierungen von Daten (z. B. die Herabstufung der Vertraulichkeit der Entwicklungsdaten eines neuen Produkts nach dessen Markteinführung) automatisch ihren Weg zu den Security-Abteilungen und deren Tools finden. Ein guter Bestand an Kontextinformationen hilft aber auch bei Infrastruktur-Projekten wie etwa der Netzwerk-Segmentierung („Jedem das Seine und allem die Welt“, <kes> 2017#6). Wo die Basisdaten für Securitymaßnahmen hingegen jedes Mal, wenn ein Projekt startet, für genau dieses Projekt wieder neu erhoben werden müssen, verlängert sich der Umsetzungszeitraum extrem.

Abstraktion

Der letzte Einzelbeitrag der Lange-Bank-Serie befasste sich mit dem Identitätsmanagement und seinen Problemen (<kes> 2018#1) und brachte dabei unversehens eine Idee auf den Tisch, welche die Aspekte „Klassifizierung“ und „Kontext“ noch einmal ergänzt und schärft. Der Vorschlag lautet, Informationen über zentrale und unverzichtbare Assets eines Unternehmens, die auch auf lange Sicht für den Sicherheitsstatus und die Sicherheitspraxis relevant sind, komplett abstrakt und unabhängig von der gerade vorherrschenden Verwendung zu beschreiben und in einem eigenen Repository abzulegen und aktuell zu halten. Sind eine vorhandene Asset-Datenbank oder die CMDB dafür geeignet, lassen sich diese Instanzen auch dafür verwenden – andernfalls lohnt sich die Definition standardisierter Artefakte in Form von Online-Formularen oder anderen Repositories.

Das Beispiel „Identitäten“ macht recht gut deutlich, worum es dabei geht und worin der zusätzliche, graduelle Schritt gegenüber dem weiter oben geforderten Management von Kontextinformationen besteht: In einer Organisation modellieren sich die Rollen und Rechte unterschiedlicher menschlicher und technischer Akteure, die auf weitere Informationen und Prozesse zugreifen, anhand des Geschäftszwecks und der zentralen Tätigkeiten der Organisation. Bestimmte Gruppen von Akteuren müssen mit bestimmten Assets arbeiten können, um ihre Aufgaben zu erfüllen.

Führt man in einer Organisation eine neue Software oder einen neuen Verarbeitungsprozess ein, dann müssen Zugriffsrechte und -notwendigkeiten gewöhnlich immer wieder neu geprüft und individuell für diese Lösung definiert werden. Oft stellt sich dann heraus, dass die bisherigen Mappings (Gruppe A greift auf Lösungen der Prozesskategorie Z zu, Gruppe B auf solche der Kategorie Y) nicht mehr passen – vielleicht weil der neue Ansatz einen bisher nicht gesehenen, kreativen Verarbeitungsweg einschlägt. Die dann notwendige Diskussion und Neuzuordnung fallen leichter, wenn bereits an zentraler Stelle ein system- und prozessunabhängiger Katalog der im Unternehmen überhaupt anzutreffenden Identitätskategorien vorliegt.

Ähnliches gilt für andere Assets und andere Projektkategorien. So ist beispielsweise eine abstrahierende Beschreibung der in der Organisation wichtigsten Datentypen hilfreich, wenn über geeignete Schutzmaßnahmen bei einer Verlagerung von Informationen und Verarbeitungsschritten in die Cloud nachzudenken ist.

In diesem Sinne stellen abstrakte Asset-Repositories auch eine wichtige Hilfe fürs Innovationsmanagement (Dauerbaustelle in <kes> 2017#1) dar: Bringt der Fortschritt plötzlich völlig neue Verarbeitungsansätze oder Werkzeuge ins Spiel, kann das einführende Team mit bereits vorab standardisiert aufbereiteten Informationen arbeiten und muss für die neue Herangehensweise nicht in alle Richtungen individuelle Schnittstellen und Konvertierungsverfahren aufbauen. Schon in den ersten Beiträgen der Dauerbaustellenreihe hatte sich ja gezeigt, dass die lang geübte Praxis, sicherheitsrelevante Informationen in Zahlenlisten für spezielle Werkzeuge umzusetzen, überholt ist und durch Informationsvorhaltung im Klartext ersetzt oder ergänzt werden muss.

Außerhalb der Security findet man die entsprechenden Ansätze häufig unter Namen wie „unternehmensweites Informationsmanagement“ oder „Datenmanagement“. Das Ziel ist das gleiche wie im hier diskutierten Einsatzbereich: Alle fürs Unternehmen wichtigen Informationen sollen in einer Form bereitgestellt werden, die neuen Projekten oder neu einzubindenden Abteilungen eine sofortige Arbeit mit den Beständen erleichtert.

Vielleicht versteckt sich hier am Ende doch noch eine „Patentlösung“ beziehungsweise ein einzelner Ansatz, der die Beherrschbarkeit von Security-Projekten in Organisationen effektiv steigern kann: Ein dediziertes, konsequent betriebenes Management von Security-Informationen würde in vielen Fällen langwierige und wiederholte Assessments, Erhebungen und Diskussionen abkürzen oder vermeiden helfen und dafür sorgen, dass sich sowohl die Konsensfindung zu einem Projekt als auch die technische Umsetzung schneller abwickeln lassen.

Bettina Weßelmann (bettina@wesselmann.com) ist Beraterin für Unternehmenskommunikation und Fachautorin mit dem Spezialgebiet Informationssicherheit. Dr. Johannes Wiele (johannes@wiele.com) ist freier Autor sowie GDD-geprüfter Datenschutzbeauftragter und arbeitet als Managing Security-Consultant.