Ist es Zeit, Ihre DevOps-Prozesse zu DevSecOps weiterzuentwickeln?

Ein ganz normaler Morgen im Büro von Jim, dem CTO eines aufstrebenden Start-ups. Er nähert sich dem Ende seines 30-minütigen Rituals, nach dem erneut ein hektischer Tag beginnen wird. Wie immer überfliegt er die allgemeinen Nachrichten und Neuigkeiten aus der Tech-Start-up-Szene. Dann erregt eine Schlagzeile seine Aufmerksamkeit: Bei einem Wettbewerber gelang es Hackern, in die Systeme einzudringen. Der Vorfall scheint existenzbedrohend zu sein.

Jim ist keineswegs schadenfroh. Trotz allem tobt in der Start-up-Welt ein gnadenloser Konkurrenzkampf, weshalb er sich ein dezentes Grinsen nicht verkneifen kann. Immerhin hatte sich der Mitbegründer des Wettbewerbers nicht immer fair gegenüber Jim und seinem Unternehmen verhalten. Natürlich waren sie Konkurrenten. Mehr Freundlichkeit und Respekt im Umgang wäre aber dennoch angebracht gewesen.

Noch bevor Jim sich seiner Schadenfreude hingeben konnte, wandelte sich sein Lächeln in Sorgenfalten: „Was ist, wenn die Kriminellen uns angreifen? Wir haben zwar unseren IT-Sicherheitsbeauftragten Bill, er kümmert sich jedoch vorwiegend um die Infrastruktur. Gelegentlich führt er Penetrationstests durch. Allerdings haben wir wöchentliche Deployments.Reichen die Tests in diesem Fall überhaupt aus?“

Tatsächlich sind die Maßnahmen oftmals überfällig und umfassen nicht alle neuen Deployments. Hierdurch entstehen potenzielle Einfallstore für Angreifer.

 Jims Situation ist keineswegs ungewöhnlich. In zahlreichen Organisationen spielen Security-Abteilungen im Entwicklungs- und Deployment-Prozess nur eine untergeordnete Rolle. Die umfassenden Sicherheitsmaßnahmen und -dokumentationen, die mit DecSecOps einhergehen, werden nicht selten als Hürde für agile Methoden, DevOps, QS und schnelle Markteinführungen interpretiert betrachtet.

Dies kann jedoch eine verheerende Fehleinschätzung sein, wenn Hackern ein erfolgreicher Angriff gelingt. Das Beispiel von Jims Wettbewerber, dem es offensichtlich um Kosteneinsparungen ging, zeigt das deutlich. Wird ein DevOps-Sicherheitsprozess sinnvoll integriert, bremst er die Abläufe keineswegs aus. Im Vergleich zu möglichen finanziellen Schäden durch Sicherheitsvorfälle sind die Kosten zudem vernachlässigbar.

Die Fortsetzung von Jims Geschichte zeigt auf, wie DevOps-Manager Continuous-Security-Standards implementieren können, ohne dass hohe Zusatzkosten entstehen. Sehen wir uns also an, wie aus DevOps DevSecOps wird.

Zunächst muss das Top-Management umdenken – exakt, wie Jim es befürchtet hat. Für IT-Manager steht jedoch im Vordergrund, in einem umkämpften Marktumfeld wettbewerbsfähige Funktionalitäten und reibungslos laufende Anwendungen zu realisieren. All dies erfolgt meist mit begrenzten Budgets und unter engen Terminvorgaben.

Jim muss also gewährleisten, dass die übergeordneten Ziele erreicht werden und sein Team gleichzeitig innerhalb einer absolut sicheren DevOps-Umgebung agiert.

„Was ich brauche, ist ein Prozess, der gewährleistet, dass die Anwendung und die Infrastruktur jederzeit sicher sind. Es sollte KEINE Möglichkeiten geben, ihn zu umgehen. Kurzfristige Lösungen kommen also nicht infrage. Zudem ist für den Sicherheitsverantwortlichen Bill und jeden andern Auditor eine umfassende Dokumentation wichtig. Insbesondere bei Kunden, die sich um die Sicherheit personenbezogener Daten sorgen, kann dies sogar als Alleinstellungsmerkmal angeführt werden.“

Jim erinnerte sich an die Probleme mit der Codequalität, die vor einigen Jahren aufgetreten waren, als sich der DevOps-Prozess des Unternehmens gerade in der Feinabstimmung befand. Fehler in der Produktion hatten seinerzeit erhebliche Schwierigkeiten verursacht und die Kundenzufriedenheit beeinträchtigt. Die Lösung war es, QS-Maßnahmen in den Entwicklungsprozess zu integrieren. Diese beinhalteten automatisierte Tests zum Commit- oder Build-Zeitpunkt sowie einen gut dokumentierten Prozess für manuelle Tests vor der Auslieferung.

Warum sollte sich dies nicht auch auf DevOps-Security übertragen lassen?

„Ich benötige die Unterstützung des gesamten Teams, um aus DevOps DevSecOps zu machen“, dachte Jim. Es wurde ein Meeting einberufen, an dem Bill von der IT-Sicherheit, Joanne aus dem Vertrieb und DevOps-Leiter Igor teilnehmen sollten.

Bill, der sich in seiner Freizeit mit Militärgeschichte und Amateurtheater beschäftigte, hatte ein Faible für Dramatik. Als ihm klar wurde, dass es in dem Meeting um DevSecOps gehen wird und er etwas beitragen sollte, bereitete er eine Folie mit diesem Zitat vor. „Jeder liebt gute Zitate“, dachte er. Das würde die anderen sicher beeindrucken.

„Fangen wir ganz von vorne an“, sagte Bill. „Zuerst müssen wir ein Verständnis für mögliche Bedrohungen entwickeln. Was sind die größten Sicherheitsrisiken und wie entstehen sie? Zunächst sollten alle Interessensgruppen die Wichtigkeit ihrer Daten beurteilen. Zudem sollte bewertet werden, welche Auswirkungen es für das Unternehmen hat, wenn diese Daten aufgrund von Sicherheitslücken kompromittiert werden. An dieser Stelle sollte Threat Modeling der richtige Ansatz für uns sein.“

„Wenn du möchtest, dass ich mich darum kümmere, dann integriere das bitte ins Backlog“, antwortete Igor, das „DevOps -Arbeitstier“.

“Ist das ein Feature?”, warf Joanne ein.

„Nein, das ist eher eine Art Anti-Feature,” entgegnete Bill, der sich aufgrund seiner eleganten Antwort erneut über seinen Sinn für Dramatik freute.

„Ich schlage vor, Methoden aus der agilen Software-Entwicklung zu nutzen. Damit können wir alle negativen User-Storys nochmals überprüfen, um sicherzustellen, dass wir sie an dieser Stelle vermeiden„.

Eine gute Roadmap ist die Basis jeder sicheren Infrastruktur. DevSecOps bildet hierbei keine Ausnahme. Da sich das Team nun auf den Entwicklungsprozess konzentrierte, wurden Infrastruktur-Themen wie Firewalls trotz Ihrer Bedeutsamkeit in der Diskussion nicht berücksichtigt.

Bill, den seine besondere Rolle in Jims Sicherheitsbemühungen mehr als motivierte, war jedoch sofort im Thema. Er schlug vor, eine Architektur für DAST-Technologien (Dynamic Application Security Testing) zu entwickeln. Auf diese Weise würde es möglich sein, Sicherheitslücken einer App im Betrieb zu erkennen. Der Ansatz würde es nicht nur ermöglichen, Schwachstellen im Quellcode zu finden, sondern auch diejenigen, die erst während der Nutzung auftraten.

Nachdem die Strategie des Teams feststand, war es an der Zeit, dass Jim gemeinsam mit den anderen eine Security-Checkliste für die DevOps-Infrastruktur zusammenstellte. Entsprechend wurden folgende Punkte zusammengetragen:

• Passwörter verschlüsseln (Passwörter sollten in Datenbanken grundsätzlich in einem verschlüsselten Format gespeichert werden, um Diebstahl zu verhindern).
• SSL-Verbindungen für die Kommunikation nutzen
• Konfiguration und Setup der Server automatisieren
• Regelmäßige Back-ups durchführen
• Zugriffskontrolle für Cloud-Dienste einrichten
• SSH sicherer konfigurieren

 Zahlreiche Teams mögen für diese Art von Checkliste nur ein müdes Lächeln übrig haben, da die Punkte offensichtlich und einfach erscheinen. Dies trifft zwar zu, dennoch werden einige dieser naheliegenden Schritte oftmals übersehen. Es gibt gute Gründe dafür, dass sich Reinigungschecklisten in den Toiletten von Raststätten oder Restaurants befinden, die von den Mitarbeitern nach Durchführung der Arbeiten unterschrieben werden müssen. Es geht weniger darum, dass die Reinigungskräfte stündlich den Sauberkeitszustand überprüfen. Vielmehr zeigt die Erfahrung, dass einfache Checklisten das Verantwortungsbewusstsein stärken und funktionieren: Die Toiletten befinden sich stets in gutem Zustand. Diese Methode ist zwar einfach, aber effektiv. Exakt nach diesen Maßstäben sollte auch die DevSecOps-Checkliste des Teams aufgebaut werden.

Natürlich würde ein gewisser Entwicklungsaufwand entstehen, um der neuen Checkliste zu entsprechen. Igor hatte hierfür jedoch einige einfache OWASP-Frameworks und -Templates in petto.

Jim hatte noch ein weiteres Anliegen:

„Wir müssen die Widerstandsfähigkeit unserer Anwendungen gegen Angreifer verbessern. Wenn es einem Angreifer gelingt, unsere Außenverteidigung zu durchbrechen, müssen wir zumindest sicherstellen, dass er seinen Weg nicht fortsetzen kann! Unsere Webanwendungen müssen prüfen, ob Anfragen gültig und authentifiziert sind. Weitere Checks brauchen wir außerdem für Datenfehler – beispielsweise einen Remote Procedure Call, SIP (Session Initiation Protocol) und so weiter.“

Nun füllte sich das Whiteboard im Besprechungsraum mit zunehmender Geschwindigkeit. Bill war glücklich darüber, dass er sein Zitat aus „Die Kunst des Krieges“ über den Beamer präsentiert hatte. Sicherlich hätte es vom Whiteboard weichen müssen, um Platz zu schaffen. Zudem brauchte das Team Inspiration. „Ich kannte meinen Feind“, dachte Bill, den seine Weitsicht nun mit Stolz erfüllte.

Die Puzzlestücke passten wunderbar ineinander und eine selten anzutreffende Einigkeit erfüllte den Raum, als sich das Team mit einer gewissen Selbstzufriedenheit zurücklehnte. Sie hatten gute Arbeit geleistet. Die kurze Atempause wurde jedoch unterbrochen, als Igor ein Problem ansprach, das bisher übersehen wurde: Es bestand die Notwendigkeit, einige Altsysteme zu integrieren.

„Niemand kennt den Code, also kann niemand die potenziellen Bedrohungen beurteilen!“

Diesmal war es Joanne, die eine elegante Lösung präsentierte:

„Warum verschieben wir die Legacy-Systeme nicht in Container mit eingeschränkten Zugriffsrechten? Damit schützen wir die anderen Anwendungen, falls kritische Schwachstellen vorhanden sind.“

Alle stimmten zu, dass dies die Risiken minimieren würde.

„Das nennt man Runtime Application Self-Protection (RASP)“, sagte Joanne mit gewissem Stolz. Erst kürzlich hatte sie eine Weiterbildung besucht. Im Gegensatz zu vielen Mitarbeitern des Unternehmens nahm sie Fortbildungen sehr ernst. Sie besaß eigens für diesen Zweck ein spezielles Federmäppchen und einen Notizblock. Im Anschluss digitalisierte sie ihre Notizen. Joanne ist schlau. Sei wie Joanne!

„RASP ist eine Sicherheitstechnologie, die Angriffe blockiert. Im Gegensatz zu Firewalls, die Bedrohungen nur anhand von Netzwerkinformationen erkennen können, ist RASP effizienter. RASP überwacht Eingaben und blockiert diejenigen, die von Angreifern stammen könnten. Dadurch lässt sich die Sicherheit deutlich verbessern.“

Code war das nächste Thema auf der Agenda. Nun stand Igor im Mittelpunkt. Er war kein Naturtalent auf der Bühne. Eigentlich war er grundsätzlich kein Naturtalent – außer im Programmieren und in ungepflegtem Aussehen. Es galt jedoch nicht, seinen Kleidungsstil und seine Körperpflege zu rechtfertigen, sondern seine Programmierkenntnisse zu verteidigen.

„Natürlich schreibe ich sicheren Code“, geriet Igor in Rage.

Als es jedoch darum ging, die Sicherheit objektiv nachzuweisen, musste er zugeben, dass er Zweifel hatte. Selbstverständlich kümmerte er sich um die Passwortstärke und nutzte verschlüsselte Backend-Verbindungen, aber Hacker sind heute wahre Genies. Er wusste, dass einige seiner damaligen Studienkollegen zur dunklen Seite übergelaufen waren. Und wie sah es mit den Nachwuchskräften in seinem Team aus? Nicht jeder war bereits ein Coding-Jedi wie er. Einige von ihnen waren nicht einmal in der Lage, ihr Star-Wars-Shirt richtig herum anzuziehen. Sie verließen sich darauf, dass er die Anhänger des Sith-Ordens abwehren würde.

Nachdem er eine Weile seine Stirn gerunzelt hatte, schlug Igor eine einfache Lösung vor.

„Diese Komponente unseres DevSecOps könnte eine Software für Sicherheits-Automatisierung übernehmen, die alle relevanten Checks sofort durchführt. Es existieren Tools, die den Code mittels Static-Code-Analysis-Testing (SAST) schon beim Schreiben überprüfen.“

Durch die Integration der statischen Code-Analyse während der Entwicklung und der Commit-Zeit in die IDE (Integrierte Entwicklungsumgebung) erhalten Entwickler eine sofortige Rückmeldung zum Sicherheitsniveau ihrer Anwendung. Hierdurch würde sich ihr Wissen im Bezug auf sicheres Coding drastisch verbessern. Außerdem ließen sich klassische Schwachstellen wie SQL-Einschleusung oder Cross-Site-Scripting identifizieren.

„Ich werde die Jungspunde lehren, die Macht zu beherrschen“ kündigte Igor an, und erntete fragende Blicke aus der Runde.

Die nächste Sicherheitsbedrohung, die angegangen werden musste, war die eingesetzte Drittanbieter-Software – ein potenzielles trojanisches Pferd für Angreifer.

„Was ist mit Software, die wir nicht selbst geschrieben haben?“, fragte Jim. „Wir setzen viele Drittanbieterlösungen ein, um unsere Entwicklung zu beschleunigen und Kosten zu reduzieren. Unglücklicherweise sind gerade diese Systeme oftmals Einfallstore, durch die Angreifer unsere starken DevOps-Sicherheitssysteme umgehen können.“

Schnell wurde klar, dass statische Code-Analysen auch zur Überprüfung von externem Code eingesetzt werden müssen.

„Wie sieht es mit Open Source Software aus?“, fuhr Jim fort. „Das würde die Entwicklungskosten deutlich senken.“

„Code dieser Art stellt oftmals ein potenzielles Sicherheitsrisiko dar“, stimmte Igor zu. „Indem man den Code auf bekannte Schwachstellen überprüft (z. B. mit OWASP Dependency-Check), können solche Mängel allerdings erkannt und unverzüglich behoben werden.“

OWASP Dependency-Check durchsucht den Code und die entsprechenden 3rd-Party-Komponenten, um OWASP-Sicherheitslücken zu identifizieren. Open Source Code wird anhand einer ständig aktualisierten Datenbank mit bekannten Schwachstellen in Open Source Software abgeglichen.

„Großes Lob an das Team“, sagte Jim stolz. „Wir haben potenzielle Risiken erkannt und eine Architektur geschaffen, die diese reduziert. Wir prüfen außerdem sowohl neuen als auch alten Code auf bekannte Schwachstellen. Haben wir noch etwas vergessen?“

Das Team hatte hinsichtlich eines leistungsfähigen DevSecOps-Systems an alles gedacht, außer an die zusätzliche Überprüfung externer Sicherheitslücken. Igor sprach diesen Punkt jedoch sofort an und verlieh der Agenda somit den letzten Schliff.

 Zusätzlich zum White-Box-Testing in der Entwicklungsphase sowie zu automatisierten Sicherheits- und Schwachstellen-Checks entschied sich Jim für Tests, welche die Vorgehensweise von Hackern simulieren. Diese Tests werden in den Deployment-Prozess integriert, sodass ihre Durchführung nicht vergessen oder unter Zeitdruck übersprungen werden kann. Reports liefern abschließend den Nachweis für das Management.

Das Team war nun fast am Ziel. Jim hatte jedoch noch einen Tagesordnungspunkt, der abgearbeitet werden musste.

„Zu guter Letzt müssen wir sicherstellen, dass DevSecOps über den gesamten Software-Lebenszyklus aufrechterhalten wird. Bei der Durchführung der Tests, auf die wir uns verständigt haben, darf die Produktion keine Ausnahme sein. Die Tests müssen weitergehen und sorgfältig überwacht werden. Jeder noch so unbedeutende Vorfall muss den Architekturspezialisten und dem Entwicklungsteam gemeldet werden, sodass das Sicherheitslevel der Anwendung verbessert werden kann.“

 Jim kehrte in sein Büro zurück. Ihr neuer Ansatz war sicherlich der beste Weg für das Deployment in die Produktion. Er hatte nun ein striktes Regelwerk und unter seiner Regie würde es keine Schwachstellen mehr geben, die das Unternehmen verwundbar machen könnten.

 „Jetzt haben wir endlich einen manipulationssicheren Ansatz für unseren Deployment-Prozess, der Best Practices aus dem Bereich DevSecOps folgt“, freute er sich. Wenn trotz aller Maßnahmen etwas passieren sollte, lässt sich sofort feststellen, woher das Problem kommt und wie wir es lösen können. Unsere DSGVO-Beauftragte Helen wird ebenfalls erfreut sein. Immerhin entsprechen wir mit unseren Maßnahmen nun dem neuen EU-Recht. Und ich kann mich zurücklehnen, da sämtliche Aktivitäten nun in Form eines klaren Prozesses definiert sind. Liebe Hacker, jetzt könnt ihr kommen!“

 Er übte vor dem Spiegel noch schnell einen erschrockenen Gesichtsausdruck – für die theoretisch vorhandenen Massen an Hackern. Dann machte er sich einen Kaffee und kehrte zum Tagesgeschäft zurück.