peopleimages.com - stock.adobe.c
Wie Observability und Security zusammenwirken können
In vielen IT-Umgebungen mangelt es nicht an Werkzeugen, die auf mögliche Probleme aufmerksam machen. Viele Warnmeldungen bedeuten jedoch nicht, dass das Ausfallrisiko sinkt.
Sichtbarkeit und Transparenz in IT-Umgebungen sind aus mannigfaltigen Gründen wichtige Faktoren für einen reibungslosen Geschäftsbetrieb. Das ist in den heutigen komplexen IT-Landschaften kein leichtes Unterfangen. Observability geht da ja einige Schritte weiter als Monitoring und hilft im bestem Fall die Komplexität besser zu verstehen und fundierte Entscheidungen zu treffen.
Splunk hat sich in seinem Lagebericht Observability unter anderem einmal angesehen, mit welchen Herausforderungen IT-Teams in diesem Zusammenhang zu kämpfen haben. Für den Report wurden zu Beginn des Jahre 2025 insgesamt 1855 Fachleute aus ITOps und Engineering befragt. Die Befragten kamen aus Australien, Deutschland, Frankreich, Indien, Japan, Neuseeland, Singapur, dem Vereinigten Königreich und den USA. Aus Deutschland haben 200 Personen an der Befragung teilgenommen.
Anzahl der Tools und Fehlalarme hängen zusammen
Die Kombination aus der hohen Anzahl der verwendeten Tools und von diesen produzierten Fehlalarme sorgt bei IT-Teams für einen Belastungszustand, ohne dass diesem wirklich produktiv abgearbeitete Aufgaben zugrunde liegen. So geben 59 Prozent der Befragten an, dass die ausufernde Menge der Tools sie beeinträchtige. Je mehr Tools im Einsatz seien, desto höher sei die Wahrscheinlichkeit, dass die Lösungen Fehlalarme auslösten. So sei einer der Gründe, dass die Quantität der Werkzeuge es auch erschwere, die einzelnen Lösungen wirklich optimal zu konfigurieren, was Warnmeldungen angeht.
Die hohe Anzahl der Alarmmeldungen führt dazu, dass IT-Teams Entscheidungen treffen, die mit Risiken verbunden sein können. So haben 13 Prozent der Befragten eingestanden, dass sie Warnmeldungen oft oder immer ausblenden. In diesem Zusammenhang ist besonders beunruhigend, dass 73 Prozent der Teams schon Ausfälle aufgrund von ignorierten oder unterdrückten Warnmeldungen erlebt haben.
Dabei sollten Warnmeldungen eigentlich immer Aufmerksamkeit erregen und genügend Kontext mitliefern, dass IT-Teams angemessen reagieren können.
Zusammenarbeit von Observability und Security
Wenn Tools per Warnmeldungen auf ungewöhnliche Situationen aufmerksam machen, so ist dies ja häufig nicht einer auf den ersten Blick erkennbaren Ursache geschuldet. Der Report nennt da exemplarisch ein Szenario, in dem die IT feststellt, dass die Login-Latenzen auf Kundenseite stark zunehmen und die Last auf der E-Commerce-Plattform des Unternehmens steigt. Demzufolge würden Kunden das Shopsystem eher unverrichteter Dinge verlassen, was unmittelbar Folgen für den Umsatz hat. Warnmeldungen führen dazu, dass ITOps das Problem an das Engineering eskaliert, die die Software zurücksetzen, ohne dass dies das Problem löst. Parallel dazu würde das Security-Team einen Blick auf die Problematik hinsichtlich möglichen Bot-Traffics werfen. Dies werde aber nicht als dringend eingestuft.
Hier würde es sich auszahlen, wenn Teams gemeinsam agieren und den möglichen Kontext von Observability-Plattformen nutzen, um die Ursache aufzuspüren. Eine effiziente Zusammenarbeit kann eine Ursachenanalyse (RCA, Root-Cause-Analyse) beschleunigen und verbessern. Etwa einen Credential-Stuffing-Angriff erkennen, der die Ressourcen auslasten würde.
So hätten 64 Prozent der Befragten weniger Probleme mit der Performance von Anwendungen und Infrastruktur, wenn Observability und Security zusammenarbeiten. Wenn weniger Zeit für Untersuchungen aufgewendet würde, ließe sich diese auch an besseren MTTD- und MTTR-Werten erkennen.
Nicht ganz unwesentlich: 64 Prozent der Befragten gaben an, dass es durch die Zusammenarbeit mit den Sicherheitsteams weniger Vorfälle geben würde, von denen Kunden etwas mitbekommen würden.
Wie Security und Observability zusammenarbeiten
Aber was heißt Zusammenarbeit in Bezug auf Security und Observability eigentlich in der Praxis? Das Teams sich Daten teilen, sollte prinzipiell die kleinste Einstiegshürde sein. In der Befragung gaben 74 Prozent an, dass ihre Observability- und Security-Teams Daten teilen und untereinander nutzen. Zudem sagten 68 Prozent, dass sie die gleichen Tools einsetzen würden.-
Um Zusammenhänge aufdecken und erkennen zu können, würde es aber nicht genügen, gemeinsame Dashboards zu nutzen. Es seien zusätzliche Korrelationsebenen vonnöten. Auch hier wird ein Beispiel angeführt. Wenn etwa von der Entwicklung ein API-Schlüssel eines Backend-Dienstes ausgetauscht wird, der vorgelagerte Service aber dafür nicht angepasst wird. Wenn nun Login-Versuche scheitern, hohe Latenzen auftreten und Nutzeranfragen fehlschlagen müssen Latenzspitzen mit Security-Logs in Verbindung gebracht werden, um die Ursache zeitnah nachvollziehen zu können. Daher genüge ein einfaches Teilen von Daten häufig nicht.
Bei immerhin 62 Prozent der Befragten beinhalte die Teamarbeit, das Troubleshooting und Problemlösung gemeinsam mit den Sicherheitsteams angegangen werde. Und 63 Prozent geben an, dass sie schnell unterscheiden könnten, ob Performance-Probleme aufgrund von Infrastruktur- oder Security-Fehlern auftreten würden.
Hindernisse bei der Zusammenarbeit
Auch wenn die Vorteile einer Zusammenarbeit von Observability und Security offensichtlich scheinen, scheitert diese in der Praxis offenbar aus einer Reihe von Gründen. Dazu gehört ein Klassiker bei entsprechenden Vorhaben, so nennen 59 Prozent der Befragten als Problem das Sträuben gegen Veränderungen durch die jeweils Beteiligten.
Darüber hinaus könne es Probleme hinsichtlich unterschiedlicher Ansätze geben und etwa zu klärender Fragen, was beispielsweise überhaupt als Incident zu werten sei. Darüber hinaus würden Widerstände auch in Form von Schuldzuweisungen und Schuldverschiebungen existieren.
Ein weiteres Hemmnis in Sachen Zusammenarbeit seien Wissenslücken. So nennen 41 Prozent der ITOps- und Engineering-Teams den Mangel an technischem Fachwissen als Herausforderung. „SREs und NOC-Engineers haben nur wenig Ahnung, was Sicherheitsprobleme sind, weil sie dafür gar nicht ausgebildet sind“, sagt Greg Leffler. Director of Developer Evangelism bei Splunk. „Die Security-Teams wiederum machen sich keine sonderlichen Sorgen um die Performance von Anwendungen, solange die Apps nicht gehackt werden.“
Und selbstredend existieren auch technische Hürden bei der Zusammenarbeit von Security und Observability. Die verwendeten Werkzeuge machten es oftmals schwer Signale, system und teamübergreifend zu korrelieren. So könne eine SIEM-Plattform beispielsweise Warnsignale für einen DDoS-Angriff auf eine Anwendung signalisieren, während die Observability-Software vielleicht nur Performance-Probleme meldet, die wiederum durch diesen Angriff verursacht werden könnten, wie etwa Latenzen oder Ressourcenauslastung.
Ein ganzheitlicher Ansatz, bei dem Observability-Daten auch als Security-Informationen betrachtet werden, könne dabei helfen, Folgen für die Sicherheit mittels Technologie besser zu identifizieren.
Der vollständige Lagebericht Observability kann bei Splunk gegen Registrierung heruntergeladen werden.
