Teamsport Risikomanagement Warum Security-Risiken Einzelkämpfer überwältigen

Anbieter zum Thema

sysob IT-Distribution GmbH & Co. KG

Fsas Technologies GmbH

FTAPI Software GmbH

In vielen Unternehmen liegt das Risikomanagement bei einzelnen IT-Security-Verantwortlichen. Die Aufgabe ist jedoch so umfassend, dass sie ein Team oder sogar nur eine Einzelperson nicht systemübergreifend managen kann. Hier ist ein neuer Denkansatz dringend nötig.

„Ich bin der Einzige, der sich hier um die Security kümmert!“ Kommt Ihnen das bekannt vor? In den Gesprächen mit anderen CISOs und IT-Security-Verantwortlichen in Unternehmen höre ich diese Beschwerde immer häufiger. Und selbst wenn es Security-Teams gibt, sind die Kapazitäten knapp. Denn die Mitarbeitenden müssen immer mehr Tickets bearbeiten. Die Folgen: frustriertes Personal, negative Stimmung und Verzweiflung angesichts fehlender Unterstützung. Dadurch steigt das Risiko, qualifizierte Fachkräfte zu verlieren – und so die Arbeitslast pro Person noch weiter zu erhöhen. Ein Teufelskreis.

Um daraus auszubrechen, ist es hilfreich, alternative Herangehensweisen in Betracht zu ziehen. Häufig hört man aus der Branche, dass seit Jahrzehnten die gleichen Security-Probleme auftauchen und keine Besserung in Sicht sei. Allerdings sind auch die Lösungsansätze seit Jahrzehnten die gleichen, weshalb es kaum Fortschritte gibt.

Um Security-Probleme zukünftig besser in den Griff zu bekommen, hilft es, die Gründe für das bisherige Scheitern des Risikomanagements in Unternehmen zu analysieren. Aus meiner Erfahrung sind die Fehlschläge meistens auf folgende drei Ursachen zurückzuführen:

1. Silos beim Identifizieren von Risiken

Was ich häufig erlebe: Security-Teams sind überzeugt davon, dass sie allein dafür verantwortlich sind, Risiken zu identifizieren. Entsprechend versuchen sie das selbst in Systemen, mit denen sie sich nicht auskennen – und beziehen dabei die Systemverantwortlichen nicht einmal mit ein. So fehlt ihnen der größere Kontext und in der Folge ein besseres Verständnis dafür, wie ein erfolgreiches Risikomanagement in diesen Systemen aussehen oder funktionieren könnte. Das typische Ergebnis: Die Rufe der Security-Verantwortlichen nach mehr Unterstützung aus anderen Abteilungen verhallen ungehört.

Gleichzeitig beschweren sich die Security-Teams darüber, dass sie niemanden dazu bewegen können, die von ihnen entdeckten Probleme zu beheben. Unglücklicherweise informieren die Security-Teams die Systemverantwortlichen häufig erst, wenn es schon zu spät ist. Wenn sie also in deren Systemen Probleme entdecken und einfordern, dass sie die lösen. Das verschärft die Spannungen weiter.

Um auch andere Teams mitzunehmen, sollten die Security-Verantwortlichen ihre vermeintliche Monopolstellung aufgeben. Wer ein System administriert und dadurch dessen Ecken und Kanten kennt, sollte auch die Risiken selbst prüfen. Jemand, der täglich mit einem System arbeitet, kann die Risiken deutlich besser bewerten als ein Außenstehender. Sinnvoll ist es zudem, alle IT-Risiken eines Systems zu bewerten, nicht nur die Security-Risiken.

Schaffen Sie daher einen standardisierten Prozess, anhand dessen die Teams regelmäßig diese Prüfungen durchführen. Bauen Sie dann ein Backend-System auf, mit dem Sie die Risiken verwalten können, Aufgaben verteilen und Status-Updates erhalten. Das größere Mitspracherecht an den eigenen Systemen kann den zuständigen Personen bereits eine ausreichende Motivation sein, mehr Engagement für das Risikomanagement an den Tag zu legen.

2. Verwechseln von Schwachstellen und Risiken

Verwechseln die zuständigen Personen Schwachstellen mit Risiken, können sie den anderen Teams unnötigerweise zu viel Arbeit abverlangen – ohne dass die Teams verstehen, welchen Nutzen diese Arbeit wirklich bringt. Da die Zeit für solch eine Auswertung meist begrenzt ist, sind Kompromisse unvermeidlich. Behandelt man aber jede Schwachstelle wie ein Risiko, fällt es schwer, die Aufgaben sinnvoll zu priorisieren. Das gilt insbesondere, wenn das Security-Team den Schwerpunkt darauf legt, Wahrscheinlichkeiten und Konsequenzen zu kalkulieren – und in der Kommunikation mit den anderen Teams viel Fachvokabular nutzt. Das kann zu Frustration führen, insbesondere wenn die Mitarbeitenden dadurch die Folgen eines Risikos nicht nachvollziehen und einschätzen können. Arbeiten sie stundenlang an Aufgaben, deren Sinn und betrieblichen Wert sie nicht nachvollziehen können, steigert das den Rechtfertigungsdruck für das Security-Team.

Daher müssen die Security-Verantwortlichen klar kommunizieren und sorgfältig abwägen, welche Aufträge sie in die Abteilungen weitergeben. Denn generell gilt: Schwachstellen sind zwar Schwachstellen, aber nicht jede Schwachstelle ist auch ein Risiko. Sie können die identifizierten Risiken allerdings beeinflussen. Aber die Security-Teams sollten den anderen Abteilungen nicht aufbürden, zahlreiche Schwachstellen zu prüfen – und diese auch nicht als Risiken verkaufen.

3. Gute Absichten führen zu Überforderung

Manchmal beginnen Security-Teams mit einer positiven Dynamik, die Risiken zu identifizieren und beziehen die anderen Fachabteilungen mit ein. Der nächste Schritt ist allerdings unkonstruktiv. Pro Risiko erstellen sie einfach ein Ticket im Backlog der anderen Teams. Der dadurch entstehende Stau an gemeldeten Schwachstellen lähmt schließlich die Teams, denen sie die Tickets zugewiesen haben. Die meisten werden die Arbeit nie beenden – wenn sie diese überhaupt anfangen. Verdenken kann man ihnen das kaum. Denn manchmal vergessen die Security-Verantwortlichen schlicht, dass diese Teams ihre eigene Arbeitslast haben. Das Risikomanagement ist zwar für jedes Unternehmen wichtig, die Arbeit an technischen Aufgaben verursacht allerdings insgesamt ähnliche Kosten wie Security-bezogene Aufgaben.

Wenn Security-Teams allerdings ihre Tickets für wichtiger halten als alles andere, werden die Fachbereiche nicht mehr mit ihnen zusammenarbeiten wollen. Denn so überhäufen sie diese einfach mit Problemen, anstatt gemeinsam einen passenden Prozess für die Lösung der Probleme zu entwickeln. Das können zum Beispiel eine angemessene, ausgewogene Schwachstellenanalyse sein und faire Service-Level-Agreements, um die wirklich wichtigen Schwachstellen schnellstmöglich zu beheben. Darüber hinaus ist es sinnvoll, systemische Probleme zu identifizieren und den Teams Leitplanken für deren Beseitigung an die Hand zu geben. Damit diese Probleme nicht wieder auftreten, helfen sogenannte „Golden Paths“. Dabei handelt es sich um eine Reihe definierter Prozesse, um Anwendungen sicher erstellen und einsetzen zu können.

Fazit

Bezieht man verschiedene Menschen mit unterschiedlichen Mentalitäten und Ansichten in die Analyse eines Problems ein, ergibt das eine umfassendere Lösung. Versucht ein Security-Team den Alleingang, insbesondere in unbekannten Systemen, erzeugt das Frust. Ich bin überzeugt davon, dass die Security-Verantwortlichen hier das Richtige tun möchten. Verursacht das aber mehr Schwierigkeiten als eine einfache Lösung, ist solch ein Projekt zum Scheitern verurteilt. Jede Minute Arbeitsaufwand hat ihren Preis. Security-Teams müssen deshalb bereit sein, Rahmenvorgaben mit klaren Prioritäten zu entwickeln und dabei diese Kosten mit einzubeziehen. Die Aufgabe Risikomanagement ist nicht eindimensional, sondern umfassend und vielschichtig. Deshalb ist es nicht praktikabel, den Fokus ausschließlich auf die Prioritäten der Security-Teams zu legen.

Alle Beteiligten müssen sich eines bewusst machen: Das Risikomanagement ist eine fortlaufende Aufgabe, die alle gemeinsam immer wieder neu angehen müssen. Eine dauerhaft perfekte Lösung dafür zu finden, ist kaum möglich. Deshalb sollten die Teams gemeinsam schauen, was für den jetzigen Zeitpunkt das beste Vorgehen ist. Dann klappt es auch mit der Zusammenarbeit.

Über den Autor: Emilio Escobar ist Chief Information Security Officer bei Datadog.

(ID:49537327)