Umfassendes Security-Monitoring liefert Einblicke für alle IT-Disziplinen

Ab in die Mitte: DevSecOps macht Sicherheit zum Bestandteil des gesamten Software-Lifecycles

Bernd F. Dollinger, Thomas Haase

© Shutterstock / Jaiz Anuar

Während das Zusammenspiel von Development und Operations dank wachsender Erfahrungswerte immer runder läuft, meldet sich eine weitere, wichtige IT-Disziplin zu Wort: Mitarbeiter, die für die Sicherheit einer Infrastruktur verantwortlich sind, wollen ebenfalls stärker in die holistische Betrachtung von technologischen Ökosystemen eingebunden werden. Mit DevSecOps setzt sich eine Denk- und Arbeitsweise durch, bei der die Sicherheit von IT-Infrastrukturen vom ersten Tag an über den gesamten Software-Lebenzyklus hinweg mitgedacht wird. Grundlegende Voraussetzung für ein wirkungsvolles Ineinandergreifen aller drei Disziplinen ist ein einheitlicher Blick auf zentrale Kennzahlen und alle sicherheitsrelevanten Signale.

Bei DevSecOps handelt es sich letztlich um die logische Weiterführung des DevOps-Gedankens: Unternehmen und IT-Teams, welche die Vorteile einer engen Zusammenarbeit zwischen Entwicklung und Betrieb ausschöpfen wollen, dürfen das Thema Security nicht isoliert betrachten. Trotzdem ist es in den meisten Organisationen noch heute so, dass die Sicherheit einem speziell für diese Aufgabe eingerichteten Team zugewiesen wird. In Zeiten agiler und oft sehr schneller Softwareentwicklungen stellt die nachgelagerte Betrachtung von Security allerdings ein nicht unerhebliches Problem dar. Überholte Sicherheitsmethoden sind oft sehr statisch und reaktiv und können damit selbst die besten Entwicklungs- und Anwendungsprozesse ausbremsen.

Flexibilität schafft komplexe Strukturen

So wie Cloud Computing inzwischen vielerorts ein integraler Bestandteil moderner Architekturen geworden ist, entwickeln sich offene, API-basierte Ansätze ebenso zu einem grundlegenden Bestandteil zukunftsfähiger IT-Infrastrukturen. Je komplexer unsere technologischen Ökosysteme werden, umso wichtiger wird es sein, nahtlose, voll integrierte Prozesse und Lösungen sicherzustellen – eine Maxime, die zunehmend auch für Sicherheitsmaßnahmen gilt. Bei DevSecOps geht es deshalb um mehr als nur darum, ein Notebook, ein einzelnes Server-Rack oder irgendeinen spezifischen Login abzusichern. DevSecOps zielt auf den Schutz kompletter Infrastrukturen – insbesondere dann, wenn sie sich auf dem Weg in die Cloud befinden. So liegt der zentrale Vorteil Cloud-basierter Migrationsvorhaben zwar in der neu gewonnenen Flexibilität; ihre Achillesferse ist allerdings die Komplexität, die hieraus entsteht. Die vielschichtige Natur und damit verbundene steigende Komplexität moderner IT-Architekturen macht verwundbar und stellt eine regelrechte Einladung für Hacker und externe Angreifer dar. Deshalb müssen Cloud-Infrastrukturen, die den Prinzipen des DevOps-Frameworks folgen, auch in Fragen der System-Security überdacht und holistisch betrachtet werden. DevSecOps liefert einen ausgesprochen vielversprechenden Lösungsansatz, um die Anforderungen einer ganzheitlichen Verankerung von Sicherheitspraktiken zu realisieren.

Hindernisse durch offene Kommunikation abbauen

Unternehmen, die ihre IT-sicherheitsrelevanten Prozesse modernisieren und übergreifende DevSecOps-Strukturen etablieren wollen, werden sich zunächst mit ausgesprochen menschlichen Hürden konfrontiert sehen. Sie sind in erster Linie kommunikativer Natur und können durch einen offenen Dialog und die Bereitschaft, voneinander zu lernen, sehr gut gelöst werden. Eine dieser Herausforderungen liegt im Development: Entwickler überführen Hunderte Male am Tag einzelne Softwaresequenzen in den operativen Zustand. Bei dieser Menge an Code hat das Security-Team keine Chance, jede einzelne Zeile zu überprüfen. Deshalb ist es so wichtig, dass die Entwickler selbst für sicherheitsrelevante Aspekte sensibilisiert werden und Ihnen entsprechende Tools seitens des Security-Teams für statische und dynamische Analysen zur Verfügung gestellt werden. Idealerweise sind sie in der Lage, potenzielle Schwachstellen und Angriffspunkte bereits in dem Moment zu erkennen, in dem sie produziert werden – und diese Erkenntnisse in einem offenen und lösungsorientierten Dialog mit den Kollegen vom gesamten DevSecOps-Team zu teilen, um den gewünschten Wissenstransfer zu erreichen.

Auf der anderen Seite dieser Medaille steht das Security-Team: IT-Sicherheitsverantwortliche sind traditionell darauf bedacht, ihre Tools in das Gesamtdesign ebenso wie in einzelne Anwendungen und Services einzubinden. Sie verfügen allerdings oft nicht über die gleiche Expertise wie ihre Kollegen aus der Entwicklungsabteilung, wenn es um die Zuverlässigkeit und die Performance von Lösungen geht. Deshalb ist es sehr wichtig, dass Security-Teams auch diese wichtigen Aspekte berücksichtigen und bereit sind, von der Erfahrung ihrer Kollegen aus dem Development-Bereich zu profitieren. Das bedeutet unter anderem, relevante Daten und Systemeinblicke zu teilen und für die Anwendungen und Tools der DevOps-Spezialisten bereitzustellen. Diese Daten müssen auch zur Analyse von Security-Lösungen genutzt werden: Es muss ganz klar sein, inwiefern eine sicherheitsrelevante Software das Gesamtsystem tangiert, bevor das Tool tatsächlich zu Einsatz kommt.

DevOps Kubernetes Camp
DevOps Kubernetes Camp

Kubernetes als Programmierschnittstelle: Neues DevOps Training für Fortgeschrittene mit Erkan Yanar.

Beginnend mit KubernetesCluster, über PodPriority und Verwendung von Operator-Lifecycle-Manager bis hin zu ArgoCD lernen Sie im 3-tägigen Intensiv-Training, wie komplexe Kubernetes-Projekte effizient paketieret werden.

Ab in die Mitte: Vor- und Nachteile von Security-Tools abwägen

Es ist vielleicht kein revolutionärer Paradigmenwechsel – und dennoch werden Unternehmen eine spürbar bessere Systemsicherheit realisieren können, wenn sie ihre Security-Implementierungen integrierter anordnen, als es vielerorts bisher der Fall war. Dies betrifft alle Prozesse und Handhabungen im Lebenszyklus eines Softwareproduktes, die zur Vermeidung von Attacken, Betrug und allen anderen externen Bedrohungen relevant sind. Durch die Realisierung von DevSecOps sind Sicherheitsmaßnahmen nicht länger an das Ende eines Lifecycles verband. Stattdessen wird das Security-Team Glied mit Entwicklung und dem Anwendungsbetrieb.

Eine besondere technologische Herausforderung für die IT-Security besteht in vielen Unternehmen darin, dass ihre Werkzeuge meist nur eingeschränkt automatisiert, bestenfalls teilautomatisiert arbeiten und damit oft nur schwer in moderne Systemwelten integriert werden können. Diese Problematik wird durch den Umstand verschärft, dass zahlreiche Sicherheits-Tools lange brauchen, bis sie tatsächlich operativ sind – und damit nicht in das Tempo, das Design und die Entwicklungsprozesse des gesamten technologischen Ökosystems passen. Deshalb empfiehlt es sich an dieser Stelle ganz genau hinzuschauen, inwiefern die betreffenden Sicherheitspraktiken überhaupt einen Mehrwert liefern. Je nach Ausgang einer derartigen Effizienzanalyse kann dann entschieden werden, ob ein Weg zur Integration von Tools mit geringerer Entwicklungsgeschwindigkeit gefunden werden sollte oder ob die Nachteile verlangsamter Development-Workflows den Nutzen übertreffen und deshalb besser auf die eine oder andere Sicherheitslösung verzichtet werden sollte. Hinzu kommt der Umstand, dass Sicherheits-Tools eine große Anzahl an False Positive-Meldungen produzieren. Für alle Lösungen, deren Einsatz als sinnvoll erachtet wurde, ist es deshalb zielführend, sie mit einer möglichst hohen Spezifität zu konfigurieren und, um ein fortlaufendes Nachjustieren zu vermeiden, schon zu Beginn auf möglichst exakt arbeitende Systeme zu setzen.

IT-Security integrieren, Redundanz vermeiden bzw. gezielt managen

Sicherheitsstrategien und die entsprechenden Lösungen müssen an die Live-Systeme angepasst sein. IT-Teams sollten das Entstehen von Security-Silos vermeiden, da diese nicht mit der operativen Umgebung integriert werden können, sondern eine Parallelwelt darstellen. Die Gründe hierfür liegen unter anderem darin, dass verteilte Security-Systeme meist redundante Datensätze und Dubletten mit sich bringen. Diese Problematik kommt spätestens dann zum Tragen, wenn Informationen aus unterschiedlichen, isoliert vorgehaltenen Lösungen zusammengeführt werden sollen. Sind die Daten nicht bereinigt, harmonisiert und dadurch konsistent, können keine zuverlässigen Aussagen über sicherheitsrelevante Zustände und Ereignisse getroffen werden. Doch dies ist nicht die einzige Nebenwirkung von Dateiredundanzen: Liegen Daten doppelt vor, so müssen diese auch doppelt verwaltet werden – ein Faktor, der für unnötige Kosten sorgt.

Geradezu gegensätzlich, aber ebenso einflussreich ist das Phänomen fehlender oder lückenhafter Datenbestände. Oft ist es so, dass einem System Informationen vorliegen, die dem anderen wiederum gänzlich fehlen. Hier ist ein Abgleich ebenfalls unumgänglich, um bei Zusammenführung von sicherheitsrelevanten Informationen aus unterschiedlichen Systemen eindeutige Aussagen treffen zu können. Ob Dubletten oder blinde Flecken in den Datensätzen, beides ist sowohl aus operativer Sicht als auch für ein übergreifendes Security-Monitoring problematisch. Schließlich kann ein Security-Team nur davon profitieren, wenn es Zugriff auf Daten bekommt, die vorab aufgrund isolierter Workflows und Datenzugriffe, nicht eingesehen werden konnten. In den meisten Fällen handelt es sich um operative Daten, die für Sicherheitsverantwortliche extrem nützlich sein können – egal, ob es sich um die Log-Einträge laufender Development-Prozesse oder um Performance-Kennzahlen aktiver Maschinen handelt. Um die Entwicklung, den Betrieb und die Sicherheit von IT-Infrastrukturen nachhaltig besser miteinander zu verzahnen, müssen alle Mitarbeiter einen einheitlichen Blick auf relevante Daten und Analysen haben – und das eben nicht nur im Hinblick auf die Performance, sondern auch in Fragen der Systemsicherheit. Nur so können sich Unternehmen darauf verlassen, dass die Kollegen im interdisziplinären DevSecOps-Team von den gleichen Dingen reden, wenn sie Bedrohungen und ein präventives Risikomanagement thematisieren.

Hintergrundrauschen verrät viel über das System

Während die IT-Komplexität größer wird, werden zugleich die jedem technologischen System eigenen „Hintergrundgeräusche“ lauter. In modernen Infrastrukturen kann uns dieses Grundsummen eine Menge darüber verraten, was gerade in unseren Netzwerken vor sich geht – wenn wir in der Lage sind, die Signale richtig zu deuten. So sind in Logs (den Protokolldateien von Anwendungen, Netzwerkmodulen und sonstiger protokollbasierter Software) riesige Menge an Messdaten und Signalen gespeichert, die nur auf intelligente Art und Weise ausgelesen werden wollen, um wertvolle Informationen über kritische Sicherheitsrisiken zu liefern. Ein anschauliches Beispiel ist die Identifizierung von ungewöhnlichen, aber systematisch wiederkehrenden Zugriffsversuchen. Da auch die Komplexität und Möglichkeiten der Angreifer steigt, können diese auch von unterschiedlichen IP-Adressen von einem Angreifer kommen. Diese können sein Indikator dafür sein, dass gerade ein externer Angreifer versucht, sich unautorisierten Zugang zu einer Infrastruktur zu verschaffen.

Je größer ein Unternehmen und je vielschichtiger seine IT-Infrastruktur, umso höher ist natürlich auch das Aufkommen von Log-Einträgen. Doch bereits bei kleineren Mittelständlern entstehen täglich mehrere Gigabyte an Security-relevanten Protokolleinträgen. Wichtig ist, dass jeder Anfrage eine eindeutige ID zugeordnet wird. Eine derartige Tracing-ID kann dann über sämtliche Schnittstellen zwischen Quellen und Diensten hinweg weitergegeben werden. Auf diese Weise sind Unternehmen in der Lage, jeden beliebigen Netzwerkteilnehmer, jeden Log-Eintrag, jede Anfrage und jeden aktiv beteiligten Service konkret miteinander in Verbindung zu bringen.

Standard-Attribute und Aliasing für Einheitlichkeit in der Namensgebung

Die Zusammenführung von Logs aus einer Vielzahl unterschiedlicher Systeme und Anwendungen führt in der Regel zu einer wilden Anhäufung von Daten, die allein schon aufgrund der Attributbezeichnungen zu massenhaften Dubletten führen kann. Als Beispiel sei eine Client-IP angeführt, die als clientIP, client_IP_address, remote_adress oder auch client.ip im System hinterlegt sein kann. Ist die Namensgebung nicht harmonisiert, kann dies zwischen Development, Operation und Security für spürbare Verwirrung sorgen. Im Sinne einer vereinheitlichten, zentralen Vorhaltung von Log-Dateien ist es deshalb hilfreich, Standard-Attribute zu definieren und Aliasing-Mechanismen anzuwenden. So ist gewährleistet, dass IT-Mitarbeiter über alle Disziplinen hinweg die gleiche Sprache sprechen.

Es empfiehlt sich außerdem, alle Felder innerhalb einer Log-Datei zu dokumentieren, die untereinander in Beziehung stehen könnten. Das kann beispielsweise eine IP-Adressen sein, die im Zusammenhang mit definierten Standardattributen betrachtet werden kann. Zur Veranschaulichung: Angenommen, die IP 1.2.3.4 interagiert mit einem System. Der Betreiber der Infrastruktur kann anhand einer konsistenten Dokumentation alle Logs in Verbindung mit dieser spezifischen IP-Adresse hin untersuchen. Dadurch wird sichtbar, welche der beteiligten Komponenten mit der IP 1.2.3.4 interagiert hat. Das gleich ist für zahlreiche andere Attribute wie etwa einen Benutzernamen oder auch eine E-Mail-Adresse möglich.

Security-Signale weisen auf akute Bedrohungen hin

Neben Log-Dateien, die eine systematische Analyse und auch Prognose sicherheitsrelevanter Kennzahlen erlauben, gibt es Security-Signale, die aktiv werden, sobald eine Bedrohung entdeckt wurde. Die Identifizierung von Bedrohungen wie etwa einer feindlichen Account-Übernahme basiert auf so genannten Detection Rules, einem Regelwerk, in dem logische Regeln zur Erfassung von spezifischen Security-Ereignissen hinterlegt sind. Schließlich repräsentiert ein einzelner Log-Eintrag lediglich ein isoliertes Ereignis, wohingegen zahlreihe Einträge von verschiedenen Quellen und Netzwerkteilnehmern eine komplette Ereigniskette, also eine Geschichte erzählen. Deshalb werden in Umgebungen, in denen nach dem DevSecOps-Prinzip gearbeitet wird, sowohl Processing-Signale als auch Anwendungsdaten zusammengeführt, mit Metadaten angereichert und nach festgelegten Regeln analysiert. Da Security-Signale grundsätzlich komplexe sind, bedarf es eines klar definierten Frameworks, um die Sicherheit in vielschichtigen Infrastrukturen zu gewährleisten und Bedrohungen proaktiv zu entgegnen. Metadaten, die Aussagen über den Ursprung eines Signals und seine Bewegungsmuster zulassen, leisten eine wichtige Hilfestellung, wenn es darum geht, Regelmäßigkeiten zu erkennen und damit einen guten Rundumblick über Architekturen und ihre sicherheitsrelevanten Schwachstellen zu bekommen. Das Ergebnis sind zuverlässige und stets zeitnahe Entscheidungen in den DevSecOps-Teams.

Dashboard sorgt für einheitlichen Blick aufs Ganze

Für Teams, die disziplinübergreifend das DevSecOps-Prinzip umsetzen wollen, ist es wichtig, dass alle Beteiligten die Zusammenführung und Auswertung von Signalen einsehen können. Ein einheitliches und unkompliziert konfigurierbares Dashboard ist deshalb eine unverzichtbare Voraussetzung, wenn DevSecOps wirklich funktionieren soll. Ein Beispiel: Entdeckt die Security-Monitoring-Lösung eine so genannte Credential Stuffing-Attacke, also den Versuch, einen Login durch automatisierte Passworteingabe zu knacken, kann der verantwortliche Mitarbeiter per Knopfdruck die Darstellung im Log-Explorer aktivieren. Dieser gewinnt konkrete Einblicke in alle Logs, die das Security-Signal getriggert haben. Die Regelwerke, die diesen Prozessen zugrunde liegen, können allesamt in der Benutzeroberfläche konfiguriert werden. Es besteht die Möglichkeit, vordefinierte Regeln zu nutzen oder auch komplett neue zu entwerfen. Über eine REST API können die Detection Rules sogar auf Code-Ebene verwaltet werden.

Ein übergreifendes DevSecOps-Monitoring schafft die nötigen Voraussetzungen, schnell und effizient auf Gefährdungen der Systemsicherheit zu reagieren und interdisziplinär nachhaltige Mechanismen für spezifische Security-Herausforderungen zu entwickeln. Wenn DevOps und Security ihre Datenpools nicht separat vorhalten, sondern diese wichtige Ressource zentral zusammenführen und harmonisieren, eröffnen sich damit unterschiedliche Perspektiven auf die sicherheitsrelevanten Faktoren einer spezifischen Infrastruktur – und die Chance, mit DevSecOps lückenlose Sicherheit über den gesamten Lebenszyklus eines Systems hinweg zu realisieren.

Geschrieben von
Bernd F. Dollinger
Bernd F. Dollinger
Bernd F. Dollinger ist Servicefeldmanager Presales & Business Intelligence bei T-Systems Multimedia Solutions. Seit über 30 Jahren ist er in der Branche tätig. Angefangen in der Systementwicklung folgten Projekte in der Software-Entwicklung und dem IT Service Management und dem strategischen Consulting. Sein Schwerpunkt liegt heute in der strategischen und taktischen Beratung zu Enterprise Service Management (ESM) mit der Analyse und Modellierung von Geschäfts- und ITSM-Prozessen sowie den zugehörigen Tool-Landschaften. Bei T-Systems Multimedia Solutions verantwortet als Teamleiter in der Business Unit Lösungen im Application Management on Multi-Clouds, Cloud Orchestration und Automation (DevOps). Dazu engagiert er sich seit Jahren im itSMF Deutschland e. V. und ist dort seit 2008 im Vorstand.
Thomas Haase
Thomas Haase
Thomas Haase ist Leiter des Bereichs Penetration Test and IT Forensics bei T-Systems Multimedia Solutions. Sein Bereich erbringt Leistungen mit Schwerpunkt in der IT-Sicherheit, Pentrationstests, forensischen Untersuchungen, IoT-Penetrationstest und des Managed Security Tests, hierbei werden Leistungen zur Beratung, Schulung und Management erbracht. Er ist bereits über 15 Jahre als Projektfeldmanager im Unternehmen und das Team auf aktuell 60 Personen ausgebaut.
Kommentare

Hinterlasse einen Kommentar

avatar
4000
  Subscribe  
Benachrichtige mich zu: