Was wir unter DevSecOps verstehen

Was wir darunter verstehen? Richtig gelesen. Denn obwohl der Begriff in aller Munde ist, so ist dieser weder geschützt noch eindeutig definiert. Jeder hat ähnliche Vorstellungen, was sich hinter dem Konzept verbirgt, lebt und beschreibt DevSecOps allerdings dann doch teilweise recht unterschiedlich. Das möchte ich heute auch tun - euch beschreiben, was DevSecOps für uns bei Objektkultur bedeutet.

Bei durchschnittlich ca. 70 neu veröffentlichten Sicherheitslücken pro Tag¹ sind wir der festen Überzeugung, dass es nicht ausreicht, sich dem Thema Sicherheit einmalig zu widmen und dann davon auszugehen, man hätte seine Schäfchen im Trockenen. Die Resilienz respektive Vulnerabilität von Geschäftsanwendungen muss kontinuierlich hinterfragt und geprüft werden, damit diese nicht nur heute, sondern auch morgen Angriffen von Bad Actors Stand halten. Nicht nur, aber vor allem, wenn die Anwendungen aktiv weiterentwickelt und mit neuen Features angereichert werden. Das muss in die Köpfe der Menschen. Dieses Verständnis ist für uns ein essenzieller Bestandteil des DevSecOps-Gedankens.

Sicherheit ist kein Feature, sondern ein Prozess.

Wir betrachten im Rahmen von DevOps bereits den kompletten Lebenszyklus unserer Software von der Entwicklung (Development) über die Bereitstellung bis hin zum Betrieb (Operations). Dabei streben wir neben einem hohen Automatisierungsgrad auch die Ganzheitlichkeit und die reibungslose Verzahnung aller Aspekte an. Vor allem befassen wir uns aber mit dem immer mehr in den Vordergrund rückenden Aspekt der Sicherheit (Security) unserer Software. Mehr noch, wir machen diesen zu einem integralen Bestandteil unseres Entwicklungsprozesses: aus DevOps wird DevSecOps.

Denn jedes digitalisierte und somit wettbewerbsfähige Unternehmen ist mittlerweile einer ständigen Bedrohungslage durch Cyber-Kriminelle ausgesetzt. Die größte Schwachstelle ist oft der Mensch, der Social-Engineering-Angriffen wie Phishing zum Opfer fällt. Umso wichtiger ist es dann, sich auf die technische Sicherheit seiner Geschäftsanwendungen verlassen zu können. Ein auf Sicherheit ausgelegter Entwicklungsprozess zahlt genau hierauf ein - kontinuierlich und von der Pike auf.

Mit der nachfolgenden Abbildung möchte ich veranschaulichen, wie der Aspekt der Sicherheit den gesamten Prozess umspannt und sich damit auf jede der Phasen auswirkt.

Abb.: Sicherheit als zentraler Bestandteil des Entwicklungsprozesses.

Wie wir DevSecOps leben

Unternehmenskultur

Wie bereits erwähnt, erfordert die Einführung von DevSecOps zunächst ein Umdenken im gesamten (Entwicklungs-) Team und eine Sensibilisierung für Sicherheitsrisiken. Das Bewusstsein für Sicherheit wird bei uns unter anderem dadurch geschaffen, dass jedem Mitarbeitenden Kontrollreports, z.B. für die Gerätesicherheit, zur Verfügung gestellt werden. Zudem werden unternehmensweite Sicherheitszertifizierungen, wie die ISMS-Zertifizierung nach ISO-27001, abgelegt und regelmäßige interne Phishing-Kampagnen zu Schulungszwecken ausgespielt. Außerdem nehmen wir gemeinsam an Hacking-Wettbewerben teil, sogenannte Capture the Flag (CTF) Events, um uns spielerisch zu verbessern und den Blick für Schwachstellen zu schulen.

Security by Design

Bestandteil der Planung ist immer die Anfertigung eines begleitenden Sicherheitskonzeptes für die Anwendung, um für Transparenz und Konsens zu sorgen. Dabei handelt es sich um ein lebendiges Dokument, das iterativ mit jedem Feature erweitert und regelmäßig ge-challenged wird. Denn Sicherheitsaspekte müssen nicht nur von Anfang an, sondern vor allem durchgehend berücksichtigt werden, um potenziellen Schwachstellen vorzubeugen - gerade bei wichtigen Architekturentscheidungen.

Automatisierte Sicherheitstests: Code-Reviews

Während der Implementierung setzen wir auf Secure-Code-Reviews , bei denen jede neu entwickelte Zeile auf Herz und Nieren geprüft wird. Über digitale Richtlinien forcieren wir Kontrollmechanismen, wie die Einhaltung des 4-Augen-Prinzips, der Einsatz von Werkzeugen für die statische Code- und Schwachstellenanalyse oder das Static Application Security Testing (SAST), indem wir beispielsweise SonarQube, NexusIQ oder Veracode in unsere automatisierten Build-Pipelines integrieren. Hierbei ist uns wichtig, sich zwar obligatorisch, allerdings nicht blind und ausschließlich auf diese automatisierten Tools und Tests zu stützen. Wir wertschätzen ganz besonders das Know-how unserer Engineers und deren Fähigkeit, die Ergebnisse entsprechend bewerten und in einen Kontext setzen zu können. Bei erhöhtem Bedarf an Sicherheit begeben wir uns auch selbst in die Rolle des Angreifers und nutzen Taktiken aus dem Bereich Offensive-Security, um unsere Anwendungen durch gezielte Simulationen von Angriffen noch sicherer zu gestalten.

Secure Configuration

Beim Deployment einer Secure Infrastructure für unsere Anwendungen implementieren wir eine Zero-Trust-Strategie in der Cloud. Konfigurationen, aufbereitet nach dem Least-Privilege-Prinzip, werden deklarativ via Infrastructure-as-Code (IaC) bereitgestellt. Schützenswerte Informationen wie Passwörter werden konsequent nur unter Verwendung abgesicherter Services (z.B. Azure Key Vault) verschlüsselt abgelegt. Auch hier lassen wir uns früh im Prozess durch Tools wie TruffleHog unterstützen, damit Geheimnisse auch Geheimnisse bleiben.

Security-Monitoring und Logging

Bei aller Vorsicht ist dennoch auch Nachsicht geboten. Denn beim Katz- und Mausspiel zwischen Angreifer und Verteidiger haben erstere immer die Nase vorn². Sicherheitsvorfälle, sollte es dazu kommen, müssen so früh wie möglich als solche identifiziert werden, um im Ernstfall schnell und effektiv handeln zu können. Daher definieren wir für unsere Anwendungen geeignete operationale Sicherheitsmetriken, wie beispielsweise verdächtig oft fehlgeschlagene Verbindungsversuche, und überwachen diese 24/7 mit entsprechenden Monitoring-Lösungen und Dashboards (z.B. Azure Monitor oder Elastic und Kibana). Hier mehr zu unseren Observability-Lösungen

Ach, da wäre noch eine Sache.

Wir wissen natürlich, dass Sicherheit immer ein Kompromiss bedeutet. Ein Kompromiss zwischen Kosten, Komfort und eben Sicherheit. Deshalb passen wir die Ausprägung des Sec-Anteils in DevSecOps immer individuell auf die Bedürfnisse unserer Kunden an. Hier die perfekte Balance zu finden, ist für uns genauso Teil unserer Beratungsleistung, wie auch von DevSecOps selbst.

Sie haben eine bestehende Software, die auf Performance und Code-Sicherheit überprüft werden soll? Hier geht es zu unserem Code-Review-Service.