Inhalt
„Schneller liefern.“ „Zuerst für die Cloud entwickeln“. In der modernen Softwareentwicklung bedeuten solche Vorgaben, dass Sicherheit und Betrieb oft hinter der Bereitstellung von Funktionen zurückstehen. DevSecOps ist das angesagte Schlagwort in diesem Bereich, aber die Implementierung von DevSecOps erfordert das Aufbrechen aller organisatorischen Silos. Wenn sich die allgemeine Sicherheitslage eines Unternehmens in einem kritischen Zustand befindet, ist dies nicht immer eine Option.
Die Betonung von Entwicklungszyklen bei gleichzeitiger Vernachlässigung von Sicherheit und Betrieb kann Unternehmen anfällig für Angriffe machen. Eine einzige öffentlich bekannt gewordene Kompromittierung erschüttert das Vertrauen der Kunden und stellt eine existenzielle, kritische Bedrohung für das Unternehmen dar. Unternehmen, die ihren Betrieb und ihre Sicherheit im Gleichschritt mit ihrer Softwareentwicklung skalieren, sind viel besser in der Lage, zu skalieren und Kunden – und deren Vertrauen – langfristig zu erhalten.
Was ist SecOps?
SecOps ist die Abkürzung für Security Operations: die Implementierung und Pflege verschiedener Sicherheitssysteme und -prozesse sowie die konsequente Überwachung und Pflege dieser Systeme, um eine effektive Gesamtsicherheitslage gegen potenzielle Angriffe zu gewährleisten. Obwohl es verlockend sein kann, SecOps einfach auf „Betrieb mit Sicherheitsfokus“ zu reduzieren, wird dabei der potenzielle Wert ignoriert, der sich aus der Verbesserung von Betrieb und Sicherheit als separate Teile eines größeren Ganzen ergibt. Die Verbesserung der Betriebskultur hat den impliziten Vorteil, eine bessere Sicherheitslage zu schaffen, während die Operationalisierung der Sicherheit diese Ziele in die tägliche Arbeit der Betriebsteams integriert.
Wenn die operative Kultur scheitert
Wie sieht eine schlechte operative Kultur aus? Sie kann sich auf verschiedene Weise manifestieren: nicht behobene Sicherheitsschwachstellen (in der Regel ein Ergebnis schlecht ausgearbeiteter Verfahren), unzureichender Einblick in Produktionsumgebungen oder manuelle Sicherheitsprozesse, die bei wachsendem Unternehmen zu Engpässen führen. Die operative Sicherheit kann auch durch einen Mangel an gemeinsamem Wissen zwischen den Teams und eine eingeschränkte Nutzung von Tools wie kontextbezogenen durchsuchbaren Protokollen oder Dashboards beeinträchtigt werden. Ein klassisches Beispiel ist die Alarmmüdigkeit: Werden Schwachstellenwarnungen ignoriert? Werden Protokolle gespeichert und nie wieder gesehen? Dies sind Schlüsselindikatoren für eine schlechte Betriebskultur.
Die Konzentration auf die operative Kultur kann jedem an der Softwareentwicklung beteiligten Team zugutekommen. Effektive Betriebsprozesse, Tools und Systeme sind eine grundlegende Komponente nicht nur für die Aufrechterhaltung der Sicherheit und Stabilität bestehender Systeme, sondern auch für die schnelle Bereitstellung neuer, funktionierender Produkte und Funktionen.
Warum nicht DevSecOps?
Eine der Fragen, die sich an dieser Stelle sofort aufdrängt, lautet: „Was ist mit DevSecOps?“ Das ist eine berechtigte Frage, denn die DevOps-Bewegung ist der sicherheitsorientierten Philosophie auf den Fersen, die Sicherheitsziele durch DevSecOps nach links zu verschieben. Dies ist jedoch keineswegs einfach und kann für Teams, die bereits ihre Softwareentwicklungskultur ändern, eine große Herausforderung darstellen.
Für die meisten Unternehmen ist der Übergang zu einer auf DevOps ausgerichteten Kultur ein schrittweiser Prozess, der mit einigen Wachstumsschmerzen einhergeht. Der Versuch, DevSecOps ohne das Lernen und den Aufbau einer Kultur zu implementieren, die sich aus der Etablierung einer starken DevOps-Grundlage ergibt, ist ein Rezept zum Scheitern. Die meisten Unternehmen, die sich in einem Vor-DevOps-Zustand befinden, müssen sich die Arbeit machen, grundlegende DevOps-Workflows zu implementieren; es gibt nicht viele Abkürzungen, um kulturelle Veränderungen vorzunehmen. Es sind diese kulturellen Veränderungen, die die Einführung von DevSecOps so viel einfacher oder sogar möglich machen. Die Automatisierung und Integration von Sicherheitszielen in die Softwareentwicklung haben die größte Wirkung, wenn sie innerhalb einer gesunden DevOps-Umgebung erfolgen.
Ehrlich gesagt, gibt es eine ganze Reihe von tief hängenden Problemen, die Engineering-Unternehmen angehen können, um die Sicherheit und den Betrieb zu verbessern, ohne DevSecOps implementieren zu müssen. Ein kurzes Beispiel: Werden alle Ihre Systeme über eine zentralisierte, durchsuchbare Schnittstelle protokolliert? Wenn Sie das beheben, haben Sie Ihre Betriebsabläufe und Ihre Sicherheitslage verbessert, ohne dass Sie größere organisatorische Änderungen vornehmen müssen. DevSecOps ist nach wie vor ein anzustrebendes Ideal, aber Entwicklungsteams sollten zuerst die einfacheren Betriebs- und Sicherheitshebel ziehen.
Skalierung der Prozesse
Skalierbarkeit ist in bestimmten Kontexten, wie z. B. WAAP (Webapplication and API-Protection), offensichtlich ein Muss. Es liegt auf der Hand, dass Unternehmen ihre Web Application Firewall (WAF), ihren Schutz vor DDoS-Angriffen und andere Web-Sicherheitstechnologien automatisch skalieren müssen, um auf Angriffe reagieren zu können.
Doch allzu oft vernachlässigen Softwareentwicklungsunternehmen die Zeit, die sie für ihre operativen Prozesse, Tools und Kenntnisse aufwenden. Das ist ein verständliches Versäumnis; Startups, die versuchen, ein MVP vor Kunden und Investoren zu präsentieren, konzentrieren sich auf die Entwicklung ausgefeilter, funktionierender Funktionen. Leider können sich kleine betriebliche Ärgernisse für kleine Teams im Laufe der Zeit zu großen Engpässen bei der Skalierung entwickeln.
Schlanke Teams, wie Startups, haben oft keinen dedizierten Infrastruktur- oder DevOps-Ingenieur im Gründungsteam. Softwareingenieure müssen schon früh im Lebenszyklus des Produkts Instrumentierungsschnittstellen in ihre Anwendungen einbauen: Sie werden vielleicht nicht sofort verwendet, aber sie erleichtern die Skalierung wichtiger Betriebswerkzeuge wie Überwachungs- und Beobachtungssysteme, wenn die Infrastruktur wächst. Frameworks wie OpenTelemetry können standardisierte Schnittstellen für Entwickler zur Instrumentierung ihrer Anwendungen bereitstellen.
Wissensaustausch
Ein weiterer Schwerpunkt bei der Skalierung des Betriebs ist die gemeinsame Nutzung von Wissen. Teams sollten schnell gemeinsames Wissen aufbauen. Es ist auch wichtig, dieses Wissen so aufzubauen, dass es organisiert und durchsucht werden kann und anderen zum Lesen und Lernen asynchron zur Verfügung steht. Es ist eine häufige Erfahrung, in einer Umgebung gearbeitet zu haben, in der ein langjähriger Ingenieur das System in- und auswendig kennt und alle kleinen Tricks und Hacks kennt, um Fehler oder Probleme zu beheben. Wenn dann ein Problem auftaucht und der besagte Ingenieur im Urlaub oder krank ist oder, schlimmer noch, das Unternehmen verlassen hat, müssen die verbleibenden Ingenieure in einem verrückten Gedränge das Wissen zusammensuchen, das zur Wiederherstellung der Funktionalität erforderlich ist. Durch den Einsatz von Tools für die gemeinsame Nutzung von Wissen wie Confluence oder Notion sowie durch eine Unternehmenskultur, die sich auf eine effektive Dokumentation konzentriert, lassen sich solche Szenarien vermeiden.
Ausfälle und Notfallwiederherstellungen
Wenn man während eines Ausfalls Zeit damit verbringt, herauszufinden, welches Warn- oder Überwachungssystem nützliche Daten über das Geschehen bereithält, gehen wichtige Minuten bis zur Lösung des Problems verloren, was letztendlich zu einer schlechten Benutzererfahrung führt. Die Einrichtung einer begrenzten Anzahl genehmigter Tools und Dashboards trägt dazu bei, ein einheitliches Bild zu vermitteln und sicherzustellen, dass alle Beteiligten mit einem gemeinsamen, einheitlichen Verständnis des Problems arbeiten. Dies ist besonders wichtig für die Web-Sicherheit, da die Sichtbarkeit und Kontrolle des Datenverkehrs in Echtzeit bei Angriffen unerlässlich sind.
Eine weitere wichtige Überlegung in diesem Zusammenhang ist die Einrichtung einer Form der Notfallwiederherstellung. Zumindest sollte ein kleines Team von Softwareingenieuren ein grundlegendes Gedankenexperiment durchführen: „Wenn die gesamte Anwendung ausfiele oder kompromittiert würde, was wäre das absolute Minimum, um sie wieder funktionsfähig zu machen?“ Leider wird selbst über grundlegende Notfallmaßnahmen oft erst dann nachgedacht, wenn es tatsächlich zu einer Notfallsituation kommt, und dann ist es in der Regel zu spät für eine effektive Wiederherstellung, die die Geschäftskontinuität gewährleistet. Die Erstellung einer guten Betriebsdokumentation sowie die Implementierung von Unveränderlichkeit in Entwicklung und Infrastruktur können die Wiederherstellung im Katastrophenfall erleichtern. Im Idealfall führen die Techniker schon früh und häufig im Lebenszyklus der Anwendung Wiederherstellungsszenarien durch, die dem “Spieltag” entsprechen.
Skalierung der Sicherheit
Die Magie von SecOps besteht darin, dass sowohl die Sicherheit als auch der Betrieb von der Konzentration auf operative Exzellenz profitieren. Die Betriebsteams verbessern ihre Reaktionszeiten und die Genauigkeit bei der Bewältigung von Ausfällen und potenziellen Sicherheitsereignissen, und die Sicherheitsteams können ein starkes Sicherheitsniveau aufrechterhalten und sich gleichzeitig auf die Bereitstellung einer guten Benutzererfahrung konzentrieren.
Bei der Sicherheit geht es um eine sorgfältige Abwägung von Risiko und Komfort. Die moderne Softwareentwicklungslandschaft verändert sich ständig und bringt neue Sicherheitsbedrohungen und betriebliche Probleme mit sich, die angegangen werden müssen. Strenge Sicherheitsrichtlinien werden die Risiken erheblich reduzieren, aber zu welchem Preis? Wenn sich Entwickler durch Sicherheitsregeln eingeengt fühlen, werden sie Abkürzungen finden und vorgeschriebene Prozesse umgehen, oder im schlimmsten Fall sogar eine neue Rolle außerhalb des Unternehmens suchen. Umgekehrt wird die vollständige Anpassung der Sicherheitsmaßnahmen an den maximalen Komfort wahrscheinlich zu einer schlechten Sicherheitslage führen. Die besten Sicherheitsteams bewerten aktiv und konsequent das Verhältnis von Risiko und Komfort in ihren Umgebungen.
Die Sicherheit muss auch mit den Entwicklungsteams und den von ihnen unterstützten Anwendungen skalieren können. Das bedeutet, dass man sich auf die operative Skalierung konzentrieren muss; Automatisierung und Wissensaustausch sind wichtige Bestandteile dieser Strategie. Manuelle Sicherheitsprozesse werden irgendwann zu einem Engpass, wenn der Prozess manuell bleibt, während das Entwicklungsteam unweigerlich wächst. Eine gute Sicherheitsführung wird ihre Teams so positionieren, dass sie in den verschiedenen Reifestadien des Unternehmens und der Infrastruktur kontinuierlich einen Mehrwert bieten. Das bedeutet, dass sie bereit sind, ihre Teams zu skalieren und zu optimieren, wenn es die Situation erfordert: Die Auswahl der richtigen Qualifikationen bei der Einstellung, die Aufrechterhaltung eines hervorragenden Entwicklererlebnisses und eine solide operative Grundlage sind alles entscheidende Elemente. Eine schlechte Sicherheitsführung wird sich nur fragen, wie sie die Fähigkeit ihres Teams, öfter „Nein“ zu sagen, verbessern kann.
Zentralisierung
Aus technischer Sicht sollte das Hauptthema für ein Sicherheitsteam, das operativ skalieren möchte, die Zentralisierung sein. Moderne Sicherheitsteams sind im Vergleich zu den Entwicklungsteams, die sie unterstützen sollen, oft personell dünn besetzt, so dass jedes Tool eingesetzt werden sollte, das dem Management bei der Skalierung helfen kann.
- Identität: Die Zeiten separater Benutzerkonten auf jedem Server und Knoten sind vorbei. Die Identitäten und der Zugriff der Entwickler sollten über eine zentrale Schnittstelle verwaltet werden. Wenn eine Identität kompromittiert wird, sollte der Sicherheitsdienst in der Lage sein, den Zugriff auf jedes System, auf das sie Zugriff hat, von einem einzigen Tool aus zu sperren. Probieren Sie FoxPass und Okta für den Anfang aus.
- Beobachtung/Monitoring: Wenn Betriebs-, Entwicklungs- und Sicherheitsteams unterschiedliche Tools verwenden, um den Zustand und den Status der Infrastruktur zu überwachen, ist es sehr viel schwieriger, ein klares und konsistentes Bild eines Betriebs- oder Sicherheitsproblems zu erhalten. Die Standardisierung auf etwas wie Prometheus/Grafana ermöglicht eine Zentralisierung der Überwachung.
- Wissen: Sich auf implizites oder Stammeswissen in der Technik zu verlassen, ist ein kurzer Weg zu operativen Schmerzen und Leiden. Jedes Team mit internen Kunden und/oder Infrastrukturverantwortung sollte eine aktuelle und gut organisierte Dokumentationshierarchie mit Software wie Confluence oder Notion pflegen.
- Kommunikation: Die Verständigung über bestimmte Themen oder Probleme, wie z. B. einen Ausfall oder eine Kompromittierung, hängt von einem einheitlichen und mit Zeitstempel versehenen Kommunikationsmedium mit klar definierten Prozessen und Regeln für die Ereignisverwaltung ab. Wenn zwei oder mehr getrennte Kommunikationstools im Einsatz sind, wird die Reaktion auf Vorfälle chaotischer und weniger effektiv sein. Tools wie Slack sind in dieser Hinsicht sehr hilfreich.
Mehr als ein weiteres “Ops”
Security Operations ist nicht nur ein weiteres trendiges Konzept auf dem „-Ops“-Stapel. Es gibt viele Marketingaspekte, um SecOps zu definieren, wie z. B. ein gemeinsamer Fokus auf operative Exzellenz, die sowohl der Sicherheit als auch dem Betrieb zugutekommt. Während DevSecOps für die meisten softwarebasierten Unternehmen wahrscheinlich das ultimative Ziel ist, kann SecOps eine wichtige Etappe auf diesem Weg sein.
Share this post
