Pragmatisch ans Ziel

von Dr. Matthias Wübbeling

Das Site Reliability Engineering, kurz SRE, wurde ursprünglich entwickelt, um große Produktionssysteme beherrschbar zu halten. Dabei bietet das Verfahren überraschend viele Ansätze, die sich direkt auf Security-Operationen übertragen lassen. Der Security-Tipp in diesem Monat zeigt, wie moderne SRE-Prinzipien helfen, Security-Prozesse effizienter, belastbarer und praxistauglicher zu gestalten.

In vielen Unternehmen hat sich die Rolle von IT-Security in den vergangenen Jahren deutlich verändert. Sicherheitsvorfälle sind längst kein theoretisches Risiko mehr, sondern Teil des normalen Betriebsalltags geworden. Gleichzeitig wachsen Infrastrukturen kontinuierlich: hybride Umgebungen, Clouddienste, SaaS-Plattformen, mobile Endgeräte und verteilte Identitäten erhöhen die Komplexität erheblich. Für Ihr Sicherheits- team bedeutet das vor allem mehr Systeme, mehr Daten, mehr Warnmeldungen und mehr operative Belastung.

Vielleicht kennen Sie die Situation aus Ihrem eigenen Alltag. Das Security-Team arbeitet auf hohem Niveau, verbringt aber einen Großteil seiner Zeit mit Alarmen, Tickets, Schwachstellenmeldungen und spontanen Incidents. Strategische Themen bleiben liegen, weil operative Aufgaben permanent Priorität haben. Genau an diesem Punkt lohnt sich ein Blick auf Site Reliability Engineering (SRE), ein Konzept, das ursprünglich gar nicht aus der Informationssicherheit stammt.

SRE wurde entwickelt, um große und komplexe IT-Systeme zuverlässig betreiben zu können. Viele Probleme, die Plattform- und Operationsteams dabei lösen mussten, ähneln den Herausforderungen der Sicherheitsverantwortlichen in IT-Abteilungen. Diese kämpfen heute mit steigender Komplexität, Alarmüberlastung, manueller Routinearbeit und fehlender Priorisierung. Deshalb können auch Security-Teams von vielen SRE-Grundsätzen profitieren.

Belastbarkeit statt Perfektionismus

Ein zentraler Gedanke im SRE ist, dass sich komplexe Systeme nicht vollständig fehlerfrei betreiben lassen. Statt Perfektion anzustreben, geht es vielmehr darum, Systeme belastbar und kontrollierbar zu machen. Genau dieser Perspektivwechsel kann auch Ihren Kollegen helfen. Viele Unternehmen arbeiten noch immer mit der impliziten Erwartung, jede Warnung untersuchen, jede Schwachstelle sofort schließen und jedes Risiko vollständig vermeiden zu müssen. In der Realität ist das kaum möglich.

Die Frage sollte daher nicht "Wie verhindern wir jeden Vorfall?" lauten, sondern eher "Wie sorgen wir dafür, dass Sicherheitsprozesse unter realen Bedingungen zuverlässig funktionieren?" Dieser Unterschied mag Ihnen zunächst klein vorkommen, er verändert aber mitunter die gesamte Arbeitsweise Ihres Teams.

Vielleicht lohnt es sich auch in Ihrer IT-Abteilung, bestehende Abläufe einmal unter diesem Blickwinkel zu betrachten:

- Welche Sicherheitsmaßnahmen funktionieren tatsächlich zuverlässig?

- Welche Prozesse hängen (zu) stark von einzelnen Personen ab?

- Wo entstehen regelmäßig Engpässe?

- Welche Warnmeldungen liefern wirklich verwertbare Informationen und welche erzeugen vor allem immer dieselbe Beschäftigung?

Gerade bei Alarmen zeigt sich immer wieder ein Problem moderner Security-Teams. SIEM-Systeme, EDR-Lösungen, Cloudsecurity-Plattformen und Netzwerküberwachung erzeugen enorme Mengen sicherheitsrelevanter Events. Mit jedem zusätzlichen Tool, das eigentlich Übersicht schaffen sollte, steigt die Zahl der Warnmeldungen weiter an. Irgendwann entsteht dabei fast zwangsläufig ein Gewöhnungseffekt. Die Analysten arbeiten die Warnungen routinemäßig ab, ohne den eigentlichen Kontext wirklich umfassend bewerten zu können.

SRE verfolgt einen pragmatischen Ansatz. Monitoring soll nicht möglichst viele Meldungen erzeugen, sondern operativ nutzbare Signale liefern. Ihr Team muss sich fragen, welche Warnungen tatsächlich zu wirklich relevanten Erkenntnissen führen, welche Meldungen fast ausschließlich Fehlalarme erzeugen oder in welchen Fällen Ihre Analysten unverhältnismäßig viel Zeit mit manueller Voranalyse verbringen, obwohl die Ergebnisse selten sicherheitsrelevant sind.

Allein diese Auseinandersetzung in Ihrem Team kann bereits dabei helfen, die operative Belastung deutlich zu reduzieren. Viele Unternehmen sammeln zwar enorme Mengen Telemetrie, erzeugen daraus aber nur begrenzt verwertbare Erkenntnisse. Weniger Alarme bedeuten nicht automatisch weniger Sicherheit, aus SRE-Sicht häufig sogar das Gegenteil.

Weniger Routine

Ein weiterer SRE-Grundsatz ist die konsequente Reduzierung sich wiederholender manueller Arbeit. Im SRE ist dabei von sogenanntem "Toil" die Rede. Das sind notwendige, aber wenig wertschöpfende Routinearbeiten, die dauerhaft Ressourcen binden. Genau solche Tätigkeiten finden sich bestimmt auch in Ihrem Security-Team. Analysten prüfen tagein, tagaus identische Alarmtypen, korrelieren Informationen manuell oder halbautomatisiert zwischen verschiedenen Systemen oder ergänzen Tickets immer wieder um dieselben Kontextinformationen.

Das Team priorisiert Schwachstellen händisch, prüft Benutzeraktivitäten einzeln oder isoliert kompromittierte Systeme nach standardisierten Abläufen. Solche Aufgaben kosten nicht nur Zeit, sondern erhöhen langfristig auch die Fehleranfälligkeit. Gleichzeitig sinkt die Motivation, wenn hochqualifizierte Mitarbeiter dauerhaft mit operativer Routine beschäftigt sind.

Für die Automatisierung von Security-Prozessen müssen Sie nicht sofort eine komplexe SOAR-Plattform einführen. Häufig reichen bereits kleinere Maßnahmen, um das Team deutlich zu entlasten. Wenn das System Alarme automatisch mit Asset- und Benutzerinformationen anreichert, Eskalationen standardisiert ablaufen oder Playbooks wiederkehrende Incident-Prozesse steuern, entsteht häufig ein schnell spürbarer Gewinn. Der Vorteil liegt aber nicht nur in der reinen Zeitersparnis, sondern auch in der beiläufig auftretenden Konsistenz. Die Prozesse werden reproduzierbarer und hängen weniger stark vom Erfahrungswissen einzelner Mitarbeiter ab.

Aus Fehlern lernen

Auch die Fehlerkultur in Unternehmen kann vom SRE-Gedanken profitieren. Oft betrachten Unternehmen Sicherheitsvorfälle stark personalisiert. Nach einem Incident steht so schnell die Frage im Raum, wer einen Fehler gemacht oder eine Warnung übersehen hat. Das führt häufig dazu, dass Teams die eigentlich zugrundeliegenden strukturellen Probleme kaum analysieren.

SRE-Teams arbeiten mit "blameless Postmortems". Das Ziel dieser ist nicht, Verantwortung zu vermeiden, sondern systematisch zu verstehen, warum ein Vorfall überhaupt möglich wurde. Nach einem Incident sollte das Team weniger individuelle Fehler als vielmehr systemische Schwächen in den Blick nehmen. Dabei steht im Vordergrund, welche Signale sichtbar waren, warum die richtige Priorisierung ausblieb, ob bestimmte Prozesse eine Reaktion verzögert haben oder welche technischen oder organisatorischen Abhängigkeiten weitere Probleme verursacht haben.

Gleichzeitig verbessert sich so mitunter die Zusammenarbeit zwischen Security-, Infrastruktur- und Betriebsteams. Sicherheitsvorfälle werden weniger als Versagen betrachtet, sondern stärker als Möglichkeit, die Resilienz des gesamten Unternehmens zu erhöhen.

Messbare Ziele

Ein weiterer Aspekt, den Sie mit Ihrem Sicherheitsteam aus dem SRE übernehmen können, ist die stärkere Orientierung an messbaren Betriebszielen. In vielen Unternehmen existieren zwar umfangreiche Sicherheitsrichtlinien, aber nur begrenzt belastbare Kennzahlen zur tatsächlichen operativen Leistungsfähigkeit.

Vielleicht lohnt es sich deshalb, gemeinsam mit Ihrem Team konkrete Fragestellungen zu definieren, wie lange die Isolation kompromittierter Systeme tatsächlich dauert, wie schnell neue Systeme in Logging und Monitoring integriert werden oder welche Sicherheitsmaßnahmen die meisten Fehlalarme erzeugen. Solche Kennzahlen helfen nicht nur bei der Priorisierung, sondern schaffen auch Transparenz gegenüber der Abteilungsleitung und dem Management. Die Arbeit des Security-Teams wird dadurch nachvollziehbarer und mitunter besser steuerbar.

Realistische Tests

Besonders interessant ist zudem ein weiterer Gedanke aus dem SRE-Umfeld: Systeme und Prozesse sollten regelmäßig unter realistischen Bedingungen getestet werden. Viele Incident-Response-Pläne funktionieren auf dem Papier hervorragend, bis der erste echte Sicherheitsvorfall wirklich eintritt.

Vielleicht kennen Sie Situationen aus Ihrem Unternehmen, wo dann Kommunikationswege im Ernstfall nicht wie geplant funktionieren oder sich herausgestellt hat, dass die Wiederherstellungsprozesse nie praktisch getestet wurden. Dafür können Sie realitätsnahe Übungen durchführen. Tabletop-Exercises, etwa für simulierte Ransomware-Szenarien oder Wiederherstellungstests, decken oft organisatorische Schwächen auf. Haben Sie bereits festgelegt, wer Systeme abschalten darf oder welche Systeme tatsächlich kritisch sind?

SRE verändert auch die Rollen technischer Teams. Moderne SRE-Teams arbeiten stark Engineering-orientiert. Prozesse sollen nicht nur betrieben, sondern systematisch verbessert werden. Genau diese Denkweise wird auch für Security-Teams zunehmend wichtiger. Vielleicht lohnt es sich, IT-Sicherheit weniger als reine Kontrollfunktion und stärker als technische Plattform zu verstehen. Wenn Ihr Security-Team sichere Standardarchitekturen bereitstellt, automatisierte Compliancechecks integriert oder wiederverwendbare Sicherheitsbausteine entwickelt, profitieren häufig auch alle anderen IT-Bereiche davon.

Fazit

Der Security-Tipp in diesem Monat hat Ihnen das Site Reliability Engineering als Gedankenmodell für Ihr Security-Team vorgestellt. Zwar ist SRE eigentlich kein Modell für Informationssicherheit, dennoch kann sich der Blick auf SRE-Prinzipien gerade für kleine IT-Abteilungen lohnen. Der Blick über den Tellerrand hilft Ihnen dann mit reproduzierbaren Prozessen, klaren Betriebszielen, sinnvoller Automatisierung und einem realistischen Blick auf die tatsächliche Belastbarkeit der eigenen IT-Sicherheit.

Site Reliability Engineering in der IT-Sicherheit