Basiswissen DevSecOps

DevSecOps ist eine Erweiterung des bestehenden Ansatzes, Entwicklung (Development) und Betrieb (Operations) bei einem einzigen Team anzusiedeln. Mit DevSecOps wird auch die Sicherheit (Security) im selben Team angesiedelt und erhält damit eine zentrale Rolle.

Mit DevSecOps wechselt man in der Regel von einer Welt, in der die meisten Dienste zentral verwaltet werden, in eine Welt, in der Dienste nur noch zur Verfügung gestellt werden. Dabei wird auch das Prinzip von Infrastructure as a Service (IaaS) gestärkt.

Zeitalter der Komplexität

Von der Entscheidung, ein Produkt ins Leben zu rufen, bis zur Ausserbetriebnahme dieses Produkts stellt sich immer wieder die Frage, wie dessen Sicherheit garantiert werden soll.

Nachfolgend werden verschiedene Möglichkeiten im Bereich DevSecOps festgehalten, die als Orientierungspunkte dienen sollen für Teams, die sicher und schnell an ihr Ziel gelangen wollen.

Grundregel 1: Prozesse über Tools

Damit ein DevSecOps-Team erfolgreich ist, muss es regelmässiges Feedback erhalten und Änderungen schnell umsetzen können. Denn DevSecOps-Prozesse müssen rasch angepasst werden können. Dies ist insbesondere aus folgenden Gründen wichtig:

• Die Frustration in DevSecOps-Teams steigt rasch an, wenn Prozesse erst nach Wochen angepasst werden können.
• Beim Start einer Anwendung sind jeweils viele Änderungswünsche vorhanden. Können diese nicht bald umgesetzt werden, erreichen sie bereits nach wenigen Monaten ein kritisches Niveau.
• DevSecOps-Teams können nicht selbstständig arbeiten, wenn langwierige Feedback-Prozesse sie ausbremsen.
• Wenn die Prozesse zu komplex und umständlich sind, werden DevSecOps-Teams Wege finden, sie zu umgehen.

Wenn Sie DevSecOps in Ihrem Unternehmen einführen, sollten Sie sich am besten auf einzelne Themengebiete konzentrieren und hier durchstarten. Von heute auf morgen alles auf DevSecOps umzustellen, ist weder notwendig noch sinnvoll. Die Teams brauchen Zeit, um sich einzuspielen.

Grundregel 2: Tools meistern

DevSecOps-Teams müssen ihre Tools meistern. Dabei gilt es Folgendes zu beachten:

• Damit Tools effektiv genutzt werden können, sollten sie nicht zu oft ausgewechselt werden.
• Tools sollten eingesetzt werden, um Aufgaben automatisiert zu erledigen und den Teams mühsame Arbeit zu ersparen.
• Die Tools sollten den Teams möglichst vertraut sein. Hilfestellung für die richtige Nutzung muss bereitgestellt werden.

Damit ist die Wahl der Tools von grosser Bedeutung. Je nach Bedarfssituation können sich auch Eigenentwicklungen lohnen. Netflix entwickelte beispielsweise mit Chaos Monkey ein Tool, das zufallsbasiert Instanzen (Container und virtuelle Maschinen) herunterfährt - ein guter Stresstest für Hochverfügbarkeitslösungen. Wer eigene Lösungen entwickelt, sollte in Betracht ziehen, diese über GitHub, GitLab oder andere Plattformen öffentlich zugänglich zu machen. Es darf nicht unterschätzt werden, wie viel positive Reputation man sich damit aufbauen kann. Ausserdem kommt man so mitunter mit Bewerbern in Kontakt, die sonst nie von einem erfahren hätten.

Das Sec in DevSecOps

Im Bereich DevOps gilt: Automatisieren, automatisieren und nochmal automatisieren. Dasselbe Prinzip sollte für das Sec in DevSecOps verfolgt werden. Mithilfe von Ticketsystemen und ausgereiften Prozessen können neue Features rasch in eine Applikation implementiert werden. Mit denselben Mitteln kann auch die Sicherheit gestärkt werden.

Wer Teams mit einem Agile-Ansatz führt, muss Sicherheit zu einem integralen Teil des bestehenden Setups machen. Es empfiehlt sich, Champions zu definieren, die sich auf das Thema Sicherheit spezialisieren und sich diesbezüglich mit anderen Teams austauschen. Bereits bei der Grundsteinlegung zum Bau einer Lösung kann in den Sprints erster Handlungsbedarf definiert werden. Es können Lösungen gefunden werden, die immer wieder neu evaluiert werden. So kann beispielsweise die Frage der Transportverschlüsselung im Unternehmen immer wieder neu angegangen werden. Ist TLS 1.2 etwa noch Stand der Dinge? Ein Champion nimmt sich dieser Frage an und setzt sich zum Beispiel dafür ein, dass fertige Konfigurationsdateien angeboten werden, die dann wiederum von anderen Teams genutzt werden können. Die anderen Teams müssen sich dann nicht mehr durch eine Kryptographie-Richtlinie durchkämpfen, die oftmals viele Fragen offen lässt und ein Nachfragen beim Chief Information Security Officer (CISO) erfordert. Die Konfigurationsdateien können ausserdem zentral auf dem Repository angeboten werden. Dies vereinfacht es auch für den CISO oder Dritte, ein Audit durchzuführen. Daneben kann man darüber nachdenken, Konfigurationsdateien zu veröffentlichen. Vielleicht ist man dadurch bei einer Websuche auf der ersten Seite zu finden.

Gesammeltes Wissen

Eine Wissenssammlung im Intranet wird von sämtlichen Mitarbeitenden im Unternehmen genutzt und von einigen auch gepflegt. Es ergibt jedoch wenig Sinn, DevSecOps-Teams zur Nutzung des Intranets zu zwingen. Zur Erinnerung: Grundregel 2 weiter oben besagt, dass DevSecOps-Teams die am besten geeigneten Tools nutzen sollten. Wenn das Intranet nicht über ein Git Repository pflegbar ist, werden Dokumentationen zu Tools, Konfigurationen und Weiterem sehr mühsam zu pflegen sein. Verwendet man eine einfache Wissenssammlung im Intranet, werden Aktualisierungen verpasst, Änderungen über mehrere Versionen sind kaum oder nicht effektiv nachvollziehbar und eine Automatisierung ist nicht möglich.

Die meisten DevSecOps-Teams werden sich wünschen, dass ihr Wissen in einem öffentlichen Repository abgelegt und auch dort gepflegt wird. Wenn die Teams ihre Dokumentation nicht bei einem zuverlässigen Repository-Anbieter hinterlegen können (Git Push zu GitHub/GitLab), führt dies zu Problemen im späteren Lebenszyklus.

Weiter sollten Sie darauf achten, dass das Wissen effektiv gespeichert wird. Wenn Sie auf wichtige Informationen von Dritten angewiesen sind, sollten Sie eine Kopie dieser Informationen im eigenen System ablegen. Man weiss nie, ob eine öffentlich verfügbare Information irgendwann gelöscht oder gesperrt wird. Auch hier kann Automatisierung helfen: Man kann sich stets eine Kopie anfertigen und sich informieren lassen bei Änderungen oder Löschungen.

Plattformsicherheit

Wenn Sie auf eine Plattform setzen, sollten Sie diese für all Ihre Anwendungen sicher machen. In unsicheren Umgebungen zu arbeiten, wird früher oder später zu Problemen führen. Muss das DevSecOps-Team beispielsweise nur schnell eine Änderung machen oder etwas Kleines prüfen, geht dies in der unsicheren Umgebung in der Regel schneller und einfacher. Die nächste Person wiederholt dieselben Schritte und ist sich nicht bewusst, welches Risiko dadurch entsteht. In eine umfassende sichere Umgebung zu investieren, ist ein einmaliger Aufwand, der sich nachhaltig lohnt. Für die Teams fällt damit auch die kognitive Belastung geringer aus - sie müssen sich nicht in jedem Einzelfall für die passende Umgebung mit den entsprechenden Tools und Prozessen entscheiden, sondern haben alles in einer Umgebung. Richten Sie sich beim Aufbau einer sicheren Umgebung am besten nach einem Standard.

Für sehr strikte Umgebungen könnte sich ein Monitoring anbieten, bei dem die Plattform auf mehrere Punkte geprüft wird:

• Standards und Benchmarks:
  • Application Container Security Guide NIST 800-190
  • Securing Docker CIS Benchmark
• Host Hardening:
  • OS Hardening, inklusive CPU/Memory Isolation Features
  • Automatisiertes tägliches Patchen
  • Monitoring & Alarming der Basisservices
    • Tracing & Timing
    • CPU-, RAM-, Disk-Nutzungslimits
  • HIDS/HIPS
  • IAM-Anbindung
  • Netzwerk
    • Zugriff nur nach Authentisierung
    • Host Firewall
  • Disk-Verschlüsselung
• Container:
  • Etablierte Standards für Images und Nutzung
  • Integrierte Features und Konfiguration
    • Monitoring & Alarming
    • IAM-Anbindung für Systemnutzer
    • Firewall

Identity and Access Management (IAM)

Dem Thema IAM widmen wir uns bei TEMET seit mehr als einem Jahrzehnt. Auf unserer Homepage finden Sie einige Artikel hierzu. Hervorzuheben sind drei Punkte, denen Sie in diesem Zusammenhang vertiefte Aufmerksamkeit widmen sollten. Diese Punkte werden in den folgenden Kapiteln betrachtet.

Der Artikel Zentrales Authentisierungs- und Autorisierungsmanagement - eine Chance für die Zukunft vermittelt ein gutes Basiswissen zum Thema IAM.

Passwordless

Ähnlich wie das Papier wird auch das Passwort langsam überfällig. Gegenüber Alternativen, die ohne Passwort auskommen (Passwordless), bietet das Passwort immer weniger Sicherheit. Zu schwierig ist es geworden, sich im Dschungel der Systeme sämtliche Passwörter zu merken. Man wählt lieber keine langen und sicheren Passwörter, weil man sie zu oft eingeben muss. Einfacher ist da die Step-up-Authentifizierung mittels eines weiteren Faktors. Den DevSecOps-Teams komplizierte Passwort-Lösungen aufzubürden, stärkt Ihren Schutz nicht, sondern birgt Risiken, weil Workarounds gefunden werden, um Passworteingaben zu umschiffen.

Fragen Sie sich deshalb stets Folgendes: Ist es im betrachteten Fall sinnvoll, mit einer Step-up-Authentifizierung zu arbeiten, oder ist ein Passwort notwendig? Gibt es Tools, die Ihnen das Leben einfacher machen könnten, indem beispielsweise PGP Keys auf einem FIDO2-Gerät abgelegt werden?

Einen spannenden Artikel hierzu finden Sie hier: Nach Paperless kommt nun Passwordless.

Identity Provider

Die Frage, ob ein eigener Identity Provider benötigt wird, wird meistens sehr früh gestellt und oftmals mit «Ja» beantwortet. In diesem Fall müssen aber alle Applikationen und Services, die neu eingeführt werden, daran angebunden werden. Insellösungen führen bald zu Problemen und sind zu vermeiden. Beispielsweise wird der Ein- und Austritt von Mitarbeitern durch Insellösungen problematisch. Wenn Sie einen Identity Provider einsetzen, sollten Sie darauf achten, dass dieser nicht nur im Firmennetzwerk verfügbar ist, sondern unbedingt auch extern.

Secrets / Vaults / HSM

Das Thema IAM umfasst heute viel mehr als die blosse Rollenverwaltung. Es muss mit Zertifikaten, Security Credentials und Secrets gearbeitet werden. Key Sharing und Hash Signing sind Themen, die hier zu beachten sind.

Beim Key Sharing wird ein Schlüssel zur Signierung mit anderen Teammitgliedern geteilt. So können etwa Applikationsversionen, die geprüft und freigegeben wurden, als vertrauenswürdig gekennzeichnet werden.

Das Hash Signing sollte bei erhöhter Maturität ein Standardwerkzeug sein. Beim Hash Signing wird der Source Code / das Source File mit einem Fingerabdruck (Hash) ausgestattet und durch einen Signing Key signiert. Nur mit dieser Signatur gilt der Code oder das File als vertrauenswürdig. Dadurch kann verhindert werden, dass bei einem Hackerangriff fremder Code eingeschleust wird.

Netzwerk

Beim Thema Netzwerk gibt es diverse sicherheitsrelevante Trends, die es zu beachten gilt. IPv6 ist nur ein Beispiel von vielen. Gerade weil Trends ständig wechseln und die Services immer dezentraler betrieben werden, ist das klassische Perimeterdenken nicht mehr anwendbar. Eine Web Application Firewall (WAF), die vielleicht bei Ihnen im Rechenzentrum läuft, ist nicht lokal auf der Maschine des Programmierers vorhanden oder fehlt beim Deployment in der Cloud. Es müssen deshalb neue Lösungen zum Einsatz kommen.

Service Mesh Hardening

Die Kommunikation zwischen den Containern (Inter-Process Communication und Service Communication) erfolgt mittels eines Service Mesh. Dieses erfolgreich zu verwalten, ist eine Fähigkeit, die jedes DevSecOps-Team früher oder später erwerben muss. In diesem Kontext gilt es insbesondere zu beachten, dass Ingress und Egress Controls am besten automatisch konfiguriert werden. Sobald Service-Mesh-Dienste zum Einsatz kommen, sollten diese über Konfigurationen gesteuert werden, die die verschiedenen DevSecOps-Teams anliefern.

Beim Start eines Service-Mesh-Dienstes mag Zero Trust noch nicht so wichtig sein. Es wird jedoch bald unabdingbar, wenn Ihr Team an Komplexität gewinnt. Die eine richtige Konfiguration zu finden und nichts zu übersehen, wird in komplexen Umgebungen schnell unmöglich. Mit zunehmender Komplexität wird es auch schwieriger, festzustellen, wenn plötzlich ganz viel Traffic in einem Netzwerk anfällt, da es keine zentralen Anlaufstellen mehr gibt, die über den Einsatz von Services informiert werden. Aber genau dieser plötzliche Anstieg von Traffic über offene Verbindungspunkte, die vergessen gingen, kann von Hackern genutzt werden, um Daten aus dem System zu tragen. Zero Trust sollte nicht als Ersatz für andere Sicherheitsmassnahmen gesehen werden, sondern als Leitidee beim Betreiben eines Service Mesh.

Verbindung mit Transparenz

Mit DevSecOps werden die klassischen Konfigurationen, bei denen über eine CLI auf Router, Firewall und Switches zugegriffen wird, aussterben. Schon heute liefern diverse Hersteller «Edge Router», die sich mithilfe unterschiedlicher Parameter wie IP-Adressen selbstständig über die Cloud konfigurieren. Dieses Umdenken von einer Konfiguration, die direkt auf dem Gerät gemacht wird, hin zu Infrastructure as a Code (IaaC) ist eine der grössten Herausforderungen der Zukunft - eine falsche Einstellung beim Routing und schon ist das gesamte Datacenter offline. DevSecOps-Teams können sich mit unglaublicher Geschwindigkeit in neue Technologien eindenken und diese umsetzen, aber beim Thema Netzwerk werden Sie nicht darum herumkommen, ein Team von Network Excellence Operators zu bilden. Dieses Team wird sich vertieft mit den Änderungen beim Software-Defined Networking (SDN) befassen, Engpässe erkennen und beheben und die Herausforderungen in Bezug auf Parameter (z. B. Handhabung von Jumbo Frames) meistern.

Das Team der Network Excellence Operators muss zwei Dinge liefern, damit die Netzwerkinfrastruktur reibungslos funktioniert:

• Best Practices für die Teams
• Transparenz im Netzwerk

Letzteres umfasst nicht nur ein eigenes Netzwerkmonitoring, bei dem Endpunkte gepingt und Latenzzeiten gemessen werden. Es fällt zusätzlich eine Vielzahl von Analysen an, die den anderen Teams zur Verfügung gestellt werden müssen. Wer einen Service entwickelt, möchte diesen nicht nur überwachen, sondern die Ergebnisse der Überwachung auch plausibilisieren können. Ein Webservice, der 200er-Statuscodes zurückgibt, kann hier wertvolle Dienste leisten. So kann ein Netzwerkbetrieb in Schicht 4 des OSI-Modells mit der Möglichkeit verbunden werden, Monitorings durchzuführen, ohne eigene Dienste stellen zu müssen.

DevSecOps: langfristige Perspektive

DevSecOps verlangt, dass Services neu als «as a Code» zur Verfügung gestellt werden. Momentan scheiden sich noch die Geister in Bezug auf die Frage, was ein Team selbstständig entscheiden darf und was von einem zentralen Team schriftlich freigegeben werden muss vor der Ausführung. Faktisch gibt es kaum Dinge, die wirklich zentral freigegeben werden müssen. Dies ist eigentlich nur für Entscheidungen in den Themenbereichen IAM, PKI und Netzwerk nötig. Bei der Auswahl der Infrastruktur (On Premise, Cloud oder hybrid), der Container-Technologie, der Code Frameworks und Datenmodelle und vielen anderen Fragen müssen die Teams eine Maturität entwickeln, dank der sie sich selbstständig bewegen können. Hier gilt es, sich an die eingangs erwähnten Grundsätze zu erinnern. Bremsen Sie Ihre Teams nicht mit festen Prozessen. Gehen Sie als Vorbild voran und passen Sie Prozesse aufgrund des Feedbacks der Teams an. Werden Sie es nicht tun, entkoppeln Sie zwei Welten innerhalb Ihres Unternehmens: die DevSecOps-Welt und die restliche Firmenwelt. Ein guter Prozess hilft Ihnen mehr als jedes Compliance-Tool, das am Schluss falsche Zahlen ausweist, weil niemand eine Anwendung versteht. Dort, wo Sie Tools einsetzen, sollten Sie sich zum Ziel setzen, diese zu meistern. Ein grösserer Fuhrpark an nur halb ausgereizten Tools macht Ihre Teams nicht schneller, sondern führt dazu, dass ihre Arbeit zäher und komplexer wird und damit auch grösseren Risiken ausgesetzt ist.

Wir helfen Ihnen gern, ein wirkungsvolles DevSecOps-Team aufzubauen, von dem Ihr ganzes Unternehmen profitiert.

Risk Management Identity und Access Management (IAM)

Über den Autor

Über den Autor

Daniel Brunner, Senior Security Consultant