Kolumne: DevOps Stories

Bist du sicher? Security als First Class Citizen in DevOps-Teams

Konstantin Diener

© S&S_Media

Das MusicStore-Team sitzt beim Mittagessen zusammen. Martin hat am Vorabend an einem Meetup teilgenommen und berichtet seinen Kollegen von den neuen Erkenntnissen, die er dort gewonnen hat.

Die DevOps Story

  • Martin: „Ich war gestern Abend das erste Mal auf dem Sec Meetup.“
  • Lukas: „Cool, ist das dieses Security Meetup, von dem du erzählt hast? Wie bist du darauf gekommen?“
  • Martin: „Das Meetup fand in der Firma statt, in der mein Kumpel Rüdiger arbeitet. Sehr coole Location …“
  • Lukas: „Ich hab’s gestern leider nicht geschafft. War’s denn interessant?“
  • Martin: „Auf jeden Fall. Es ging um ‚DevSecOps – Für Security ist jeder verantwortlich‘. Ich habe nur gemerkt, dass ich mir solche Themen nicht abends anhören kann. Es hat mich so intensiv zum Grübeln gebracht, dass ich noch zwei Stunden wach gelegen habe.“
  • Lukas: „Wow. Was hat dich so beschäftigt?“
  • Martin: „Worauf man alles achten muss, wenn man halbwegs sichere Software bauen möchte – und was man alles falsch machen kann. Wir haben da ganz schön Nachholbedarf!“
  • Christian: „Wieso? Security kaspert Erik doch mit Gunnar, unserem CISO, aus.“
  • Martin: „Es ging gestern auch um einige Themen, die sich auf die Zusammenarbeit mit dem PO bezogen. Wusstet ihr aber, dass es zum Beispiel ein Tool gibt, mit dem man Maven Dependencies auf Schwachstellen scannen kann? Oder eins, mit dem sich Angriffspunkte für SQL Injections in der Anwendung aufdecken lassen? Das sehe ich auch eher als Aufgabe der Entwickler. Da hat Erik nichts mit zu tun.“
  • Lukas: „Außerdem, Christian, haben wir uns in letzter Zeit auch nicht mit Ruhm bekleckert, wenn Erik sicherheitsrelevante Dinge eingekippt hat. Ich erinnere nur an die Testumgebung, die immer noch offen im Netz rumsteht …“
  • Christian: „Was soll da auch groß passieren, ehrlich?“
  • Martin: „Oh, da habe ich gestern die eine oder andere Horrorstory mit Data Leaks gehört. Das würde ich spätestens seit gestern nicht mehr so auf die leichte Schulter nehmen, Christian. Vor allem, weil die Daten ja unverschlüsselt auf der Umgebung liegen.“

 

Abb. 1: Martin berichtet seinen Kollegen beim Mittagessen vom gestrigen Security Meetup

Abb. 1: Martin berichtet seinen Kollegen beim Mittagessen vom gestrigen Security Meetup

 

Security wird oft als lästiges Nice-to-have gesehen

Martin ist nach dem Meetup überzeugt: Jeder ist für Security verantwortlich. Christian sieht das ganz anders. Für ihn ist Security ein lästiges Thema, um das sich der Chief Information Security Officer (CISO) zusammen mit dem Product Owner kümmern soll. Vermutlich gibt es bei jedem Go Live einen Schritt, in dem Gunnar, der CISO, noch ein paar Securitytests durchführt.

DevOpsCon Istio Cheat Sheet

Free: BRAND NEW DevOps Istio Cheat Sheet

Ever felt like service mesh chaos is taking over? Then our brand new Istio cheat sheet is the right one for you! DevOpsCon speaker Michael Hofmann has summarized Istio’s most important commands and functions. Download FOR FREE now & sort out your microservices architecture!

Die ablehnende Haltung der Entwickler kommt nicht von ungefähr. Oft wird Security auch im Management als kostspieliges Nice-to-have gesehen. Das Thema wird erst interessant, wenn das erste Sicherheitsproblem aufgetaucht ist. Bis dahin wird Security auf einen kurzen Checklisteneintrag vor dem Go Live reduziert.

Mit der agilen Softwareentwicklung zog ein konsequentes Qualitätsmantra in die Entwicklungsteams ein. Waren Tests zuvor ein manueller Schritt vor der Inbetriebnahme, gibt es nun eine Vielzahl unterschiedlicher Tests in jedem Stadium des Softwareentwicklungsprozesses. Diese Tests werden bereits im Sprint Planning beim Schreiben von User Stories vorbereitet. DevOps-Teams messen zudem kontinuierlich den Gesundheitszustand ihrer Anwendung in Produktion.

Genau wie beim Thema Qualität ist auch für Security ein Kulturwandel notwendig.

Entwicklungsteams müssen eine ebenso positive Einstellung zum Thema Security wie zur Softwarequalität entwickeln. Es ist klar, dass keine Organisation jemals hundertprozentige Security erreichen wird, noch passiert aber oft zu wenig.

Werner Vogels hat in einem Blogpost ein Resümee über zehn Jahre AWS geschrieben. Bemerkenswert ist, dass in diesem Text mindestens drei von zehn Punkten mit Security zu tun haben: 2. Expect the unexpected, 7. Build security in from the ground up, 8. Encryption is a first-class citizen.

Security fängt beim Sprint Planning an …

Den ersten Punkt „Expect the unexpected“ bezieht er eigentlich darauf, dass in einem verteilten System jede Komponente jederzeit ausfallen kann. Dieses Mantra hilft uns aber auch bei der Planung von Security (dem sogenannten „Whiteboard Hacking“) weiter. Jedes vom Benutzer übertragene Datum ist potenziell gefährlich und kann SQL Injections oder ähnlichen Schadcode enthalten. Bei diesen Daten muss es sich nicht unbedingt um direkte Eingaben in einer Webanwendung handeln. Es können beispielsweise auch manipulierte Metadaten in einer Datei sein. Gojko Adzic beschreibt in seinem Buch „Humans vs. Computers“ [1] einige Szenarien, die beschreiben, was in diesem Zusammenhang alles schiefgehen kann.

Ein nützliches Werkzeug für das Whiteboard Hacking sind Evil User Stories. Herkömmliche User Stories beschreiben das Verhalten von normalen beziehungsweise wohlmeinenden Benutzern. Evil User Stories versetzen sich in einen möglichen Angreifer hinein und beschreiben seine Versuche, die Anwendung zu kompromittieren. Diese Stories kann das Team gemeinsam mit seinem Product Owner schreiben – möglicherweise unterstützt von Securityexperten – und der PO kann sie wie alle anderen Stories im Backlog priorisieren.

… ist fester Bestandteil der Softwareentwicklung …

Durch Whiteboard Hacking lassen sich potenzielle Schwachstellen im Rahmen der Planung aufdecken. Während der Entwicklung ist eine konsequente Berücksichtigung ebenso wichtig – dies kann zum Beispiel in Form von Security Code Reviews geschehen. Zusätzlich gibt es eine ganze Reihe mächtiger und zum Teil kostenloser Werkzeuge, die bei Penetrationstests oder beim Aufdecken von Sicherheitslücken unterstützen.

Entwicklungsteams machen heute im großen Umfang Gebrauch von Open-Source-Bibliotheken und schreiben nur noch einen Teil ihrer Software selbst. Diese Bibliotheken enthalten ebenfalls immer wieder Schwachstellen, die ein Angreifer sich zunutze machen kann. Martin berichtet seinen Kollegen von einem Werkzeug, das Maven Dependencies mit einer Liste bekannter Schwachstellen abgleicht (OWASP Dependency Check ,hier und hier). Solche Werkzeuge helfen im Entwicklungsprozess, Schwachstellen in den verwendeten Bibliotheken zügig zu identifizieren und entsprechend darauf zu reagieren (Update der Bibliothek oder Anpassung des aufrufenden Codes).

Laut den „OWASP Top 10“ gehört die Verwendung von Komponenten mit bekannten Schwachstellen zu den zehn häufigsten Securityproblemen. Für kleine Teams stellt es eine besondere Herausforderung dar, alle Infrastrukturkomponenten auf einem aktuellen Patch Level zu halten. Solche Teams entscheiden sich häufig, Managed Components einzusetzen und damit die Verantwortung für die Security und das Patchen der Infrastrukturkomponenten zum Beispiel an einen Cloud-Anbieter zu delegieren.

Die Verwendung von Managed Services entbindet das Team allerdings nicht davon, bei seiner Architektur konsequent auf verschlüsselte Kommunikation und Speicherung sensibler Daten zu achten.

Die Verwendung von Managed Services entbindet Teams leider nicht davon, bei ihrer Architektur immer konsequent auf die verschlüsselte Kommunikation und Speicherung sensibler Daten zu achten.

… und des Betriebs

Außerdem fallen, unabhängig davon, ob ausschließlich Managed Services verwendet werden oder nicht, in jedem Fall eine Reihe von Securityaufgaben im Betrieb der Anwendung an. Ebenso wie DevOps-Teams den Gesundheitszustand ihrer Anwendung kontinuierlich messen, sollte es auch ein entsprechendes Security Logging und Monitoring geben (fehlgeschlagene Anmeldeversuche, versuchte SQL Injections etc.), um Angreifer aussperren oder zumindest einen Angriff nachverfolgen zu können. Laut den „OWASP Top 10“ gehört auch unzureichendes Logging und Monitoring zu den zehn häufigsten Securityproblemen. Aus diesem Grund tauchen diese Themen gleich zweimal im Manifesto der DevSecOps-Initiative auf.

Jedes Unternehmen sollte Securityexpertise haben, nicht zwingend jeder Mitarbeiter

Der bisherige Artikel enthielt nur eine kleine Auswahl von Themen, die im DevSecOps-Kontext relevant sind. Auch diese Auswahl zeigt, dass das Thema sehr vielschichtig und umfassend ist. Aus diesem Grund muss die Regel „Jeder ist für Security verantwortlich“ nicht bedeuten, dass alle Mitarbeiter auch Securityexperten sind – genau wie in einem DevOps-Team auch nicht alle Teammitglieder Infrastrukturexperten sind. Alle Mitarbeiter sollten jedoch für dieses Thema sensibilisiert und lernwillig sein und darüber hinaus sollte es noch Securityexperten in den einzelnen Teams oder in einem separaten Team geben. Diese Experten können dann zum Beispiel Tools für den Softwareentwicklungsprozess und fürs Monitoring entwickeln und den Kollegen zur Verfügung stellen.

Martin hat mit Kollegen aus anderen Teams eine Community of Practice ins Leben gerufen, in der sie entsprechende Werkzeuge und Prozeduren für ihr Unternehmen entwickeln möchten. Im Sprint Planning wollen er und sein Team sich zukünftig zusammen mit Erik und Gunnar auch mit Evil User Stories beschäftigen.

Geschrieben von
Konstantin Diener
Konstantin Diener
Konstantin Diener ist CTO bei cosee. Sein aktueller Interessenschwerpunkt liegt auf selbstorganisierten Teams, agiler Unternehmensführung, Management 3.0 und agiler Produktentwicklung. Daneben entwickelt er noch leidenschaftlich gerne selbst Software. Twitter: @onkelkodi
Kommentare

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
4000
  Subscribe  
Benachrichtige mich zu: