DevOps aus Sicherheitsperspektive

Sicherheitsvalidierung von Programmcode

Zur Risikominimierung sollte man den gesamten Programmcode, der in die Produktivumgebung überführt werden soll, aus der Perspektive der Informationssicherheit validieren. So können Entwickler keine Hintertüren in den Programmcode einschleusen oder unter Umständen unbeabsichtigt Sicherheitslücken zulassen. Dazu wird ein Peer-Review durchgeführt, um den Code auf Korrektheit und Einhaltung der Softwareentwicklungsrichtlinien des Unternehmens zu überprüfen. Insbesondere sensiblen Programmcode sollten zusätzlich andere Entwickler überprüfen. Der Peer-Review-Prozess ist vorab vom Management zu institutionalisieren, um zu gewährleisten, dass der Prozess stets durchgeführt wird und die Reviewer für ihre Aufgaben qualifiziert sind. Zur Sicherheitsvalidierung gehört außerdem ein automatischer Sicherheitstest, zum Beispiel mittels Tools zur Quellcodeanalyse. Bei der Suche nach Schwachstellen sollte man unter anderem die schwerwiegendsten Sicherheitsschwachstellen von Webanwendungen gemäß OWASP berücksichtigen [4].

Funktionsvalidierung von Programmcode

Darüber hinaus ist es sinnvoll, den Programmcode in angemessener Weise auf seine Funktion zu validieren. So stellt man sicher, dass die Software wie gewünscht in der Produktivumgebung funktioniert und Störungen verhindert oder schnell beseitigt werden. Die Entwickler arbeiten dafür am besten bereits vor der Erstellung des Programmcodes Testroutinen aus. So werden eine fehlende oder mangelnde Testbarkeit des Codes verhindert und die Erstellung der Tests grundsätzlich nicht durch Zeitdruck oder Nachlässigkeit beeinträchtigt. Wenn alle durchgeführten Tests positiv ausfallen, können die Verantwortlichen den Code freigeben. Die Testergebnisse sollten sie jedoch dauerhaft vorhalten, beispielsweise mithilfe einer Versionskontrollsoftware. Wenn Tests nicht bestanden werden, sind die Entwickler und der entsprechende Manager darüber zu informieren, zum Beispiel mittels automatischem E-Mail-Versand. Anhand von Protokollen sollte man zudem die Funktionsfähigkeit des Programmcodes in der Produktivumgebung nachhalten, sodass Entwickler diese Informationen im Fall von Störungen als Hilfsmittel bei der Fehlersuche nutzen können. Nachdem ein Fehler durch beispielsweise eine Wiederherstellung des Ursprungszustands oder durch einen Patch – der jedoch erneut die Tests durchlaufen muss – behoben wurde, sollten Entwicklungsabteilung und IT-Betrieb zusammen herausfinden, wie die automatischen Tests anzupassen sind, damit gleichartige Probleme nicht mehr auftreten.

Zugriffsschutz

Die dritte technische Kontrollmaßnahme betrifft den Zugriffsschutz. Alle Systeme und Applikationen in der jeweiligen Umgebung, zum Beispiel Datenbanken, Betriebssysteme, Netzwerkgeräte und Speichersysteme, müssen vor unbefugtem Zugriff geschützt werden. Vertreter der Softwareentwicklung, des IT-Betriebs und der Informationssicherheit sollten zusammenarbeiten, um die Übergänge der Umgebungen abzusichern. Die Netzwerkumgebung ist so zu betreiben, dass unerwünschte ein- und ausgehende Verbindungen blockiert und Angriffsversuche erkannt werden. Sie sollte zudem regelmäßig gescannt werden, um sicherzustellen, dass sie so konfiguriert und segmentiert ist, wie ursprünglich im Design vorgegeben. Hierzu kann man zum Beispiel prüfen, ob bestimmte IP-Adressen erreichbar sind. Außerdem hilft es, wenn externe Spezialisten regelmäßig Penetrationstests durchführen und die Ergebnisse Vertretern der Softwareentwicklung, des IT-Betriebs und der Informationssicherheit kommunizieren.

Aber nicht nur die Übergänge der Umgebungen sollte man schützen, sondern auch die Bestandteile im Inneren. Beispielsweise sind Skripte so zu gestalten, dass sie konform zu branchenüblichen Best Practices sind. Auch sollten sie regelmäßig überprüft, aktualisiert und durch die Informationssicherheit genehmigt werden. Das Ausrollen der Software sollte zudem auf einem Image basieren, das hinreichend getestet wurde. In der Produktivumgebung ist außerdem die Integrität wichtiger Dateien mit geeigneter Software zu überwachen, um nicht autorisierte Änderungen zu identifizieren. Zusätzlich müssen die Systeme im Hinblick auf unübliches Verhalten überwacht werden.

Neben diesen technischen Kontrollmaßnahmen bieten sich auch einige organisatorische an. So können Unternehmen mithilfe von Richtlinien den sicheren Umgang von DevOps-Tools regeln. Solche Richtlinien machen verbindlich, welche Vorgaben und Erwartungen an Administratoren und Entwickler gestellt werden. Unter anderem sollte man darin Informationen, Systeme und Applikationen definieren, auf die Mitarbeiter im Rahmen von DevOps zugreifen dürfen. Die Richtlinien sollten auch unterstreichen, dass jeder Mitarbeiter die Verantwortung für sein Handeln übernehmen muss und ein Verstoß in jedem Fall definierte und klare disziplinarische Maßnahmen mit sich bringt. Um zu beurteilen, ob die vorhandenen Richtlinien angemessen sind, bieten sich folgende Fragen als Hilfestellung an:

• Welche Richtlinien sind aktuell verbindlich?
• Sind die Richtlinien effektiv und effizient?
• Wie und durch wen wird die Einhaltung der Richtlinien überwacht?
• Wie zufrieden ist das Management mit den Richtlinien?
• Benötigen die Richtlinien eine Überarbeitung oder Aktualisierung?
• Werden die involvierten Risiken verstanden?
• Müssen die Risiken grundsätzlich vermindert oder anders bewältigt werden?

Zusätzlich sollte das Unternehmen mithilfe passender Schulungen bei den Entwicklern und Administratoren ein Verständnis über die DevOps-Methode und den sicheren Umgang mit DevOps-Tools herstellen. Dabei ist zu verdeutlichen, dass die ständige Bewahrung eines angemessenen Sicherheitsniveaus besonders wichtig ist. Neben Schulungen können Unternehmen auch Maßnahmen zur Förderung des Sicherheitsbewusstseins durchführen. Dafür bieten sich Webinare, Newsletter oder auch regelmäßige Informationen im Intranet an. Nur wenn die Mitarbeiter wissen, wie sensibel die Daten sind, mit denen sie im Rahmen von DevOps arbeiten, und welche Sicherheitskriterien dabei von Bedeutung sind, können sie bewusst darauf achten und Abweichungen vermeiden oder melden.

In manchen Fällen können Unternehmen aufgrund technischer oder organisatorischer Beschränkungen eigentlich notwendige Kontrollmaßnahmen nicht umsetzen. Sie sollten dann jedoch zumindest kompensierende Maßnahmen oder Workarounds einführen, die das verbleibende Risiko auf ein akzeptables Maß reduzieren. Dazu gehören zum Beispiel zusätzliche Autorisierungen, bevor neuer Programmcode in die Produktivumgebung überführt werden darf, ergänzende Genehmigungen und Überwachungen für Entwickler, die auf solche Systeme zugreifen, die Überwachung des gesamten Programmcodes auf Änderungen, die Überwachung der Zugriffe auf den originalen Quellcode oder weitere Schutzmaßnahmen für produktive Daten, zum Beispiel Verschlüsselung oder restriktivere Berechtigungen sowie umfassende Protokollierungen und Protokollauswertungen.

Implementierung

Ob die Implementierung von DevOps in Anbetracht der zu berücksichtigenden Sicherheitsaspekte tatsächlich wirtschaftlich lohnenswert ist, hängt von unterschiedlichen Faktoren ab. Zum Beispiel spielt die vorhandene Arbeitskultur eine große Rolle. Die Vorteile der Methode lassen sich nämlich nur durch eine bessere Zusammenarbeit realisieren. Gibt es im IT-Bereich eines Unternehmens noch keine Arbeitskultur, die von Zusammenarbeit und offener Kommunikation geprägt ist, beeinträchtigt das stark die Effektivität von DevOps.

Essenziell ist auch die Unterstützung der Geschäftsführung. Nur wenn diese die IT als wichtig genug erachtet, um einen spürbaren Einfluss auf die Profitabilität des Unternehmens zu nehmen, erhalten neue Methoden, wie DevOps, das nötige Gewicht. Das brauchen die Verantwortlichen dann beispielsweise, wenn womöglich Änderungen an der Organisation und am Arbeitsverhalten vorgenommen und durchgesetzt werden müssen.

Grundsätzlich spielt bei der Überlegung, ob DevOps überhaupt Sinn macht, die Zahl der Eigenentwicklungen eine Rolle. Die Anzahl und die Bedeutung der selbst entwickelten Applikationen müssen hoch genug sein, damit sich ein fundamentales Umdenken der Entwickler und Administratoren im Rahmen von DevOps überhaupt lohnt. Ansonsten sind die Investitionen zur Umstellung höher als die zu erwartende Steigerung der Wertschöpfung.

Hat sich ein Unternehmen jedoch für DevOps entschieden, sollte die Einführung gut vorbereitet und schrittweise ausgeführt werden. Auf diese Weise kann man verhindern, dass sich die womöglich hohen Erwartungen an DevOps nicht erfüllen oder dass Verantwortliche gravierende Sicherheitsmängel übersehen. Vor allem folgende Punkte sollten Unternehmen bei der Planung der Implementierung bedenken:

• Pilotierung: Zunächst sollte eine bestimmte Applikation ausgewählt werden, bei der man erste praktische Erfahrungen mit der DevOps-Methode sammeln kann, ohne dass das gesamte produktive Umfeld des Unternehmens gefährdet wird oder andere Risiken für den Geschäftsbetrieb entstehen. Kommt es dann zu Sicherheitsverletzungen, sind sie in der Regel gut einzugrenzen und schnell zu beheben. Die maximal akzeptablen Wiederherstellungszeiten und der maximal akzeptable Datenverlust sollten eher hoch sein. Die in der Pilotierung erlangten Erfahrungen müssen dann bei der Umstellung weiterer Applikationen berücksichtigt werden.
• Modellierung: Der Softwareentwicklungsprozess inklusive der Änderungen, die durch DevOps entstanden sind, sollte vor dem praktischen Einsatz vollständig modelliert werden. Auf diese Weise schafft man bei den Beteiligten im Vorfeld Verständnis und im Rahmen von Reviews können Defizite, die sich aus dem Modell ergeben, identifiziert und korrigiert werden.
• Test: Neben der Modellierung bietet sich auch ein Test des Softwareentwicklungsprozesses an. Dadurch wird eine praxisorientiertere Sichtweise ermöglicht, die eventuell weitere Defizite oder Verbesserungsansätze hervorbringt. Umsetzbar ist so ein Test beispielsweise mittels Checklisten, Simulationen, theoretischen Übungen oder Live-Tests. Mit Checklisten prüft man, ob alle Voraussetzungen und Kontrollmaßnahmen für DevOps vorhanden sind. In den Simulationen gehen alle Beteiligten zusammen die Schritte der DevOps-Methode durch und haben die Möglichkeit, Fragen zu stellen und Kritik zu äußern. Bei theoretischen Übungen wird der praktische Einsatz simuliert und ein bestimmter Anwendungsfall theoretisch bearbeitet. Hierbei sollen Diskussionen und unerwartete Situationen gefördert werden, um eventuelle Sicherheitsverletzungen oder Ineffizienzen aufzudecken. Mit Live-Tests schließlich üben die Beteiligten DevOps „live“: Hierbei wird allerdings keine geschäftlich relevante Applikation geändert, sondern lediglich eine Dummy- Software, die Geschäftsfunktionen, wenn überhaupt, nur nachbildet.
• Beschränkungen: Die technischen und organisatorischen Beschränkungen, die DevOps womöglich behindern, sollten in Erfahrung gebracht werden. Ist die Softwareentwicklung oder der IT-Betrieb zum Beispiel an ein anderes Unternehmen ausgelagert, kann das die Steigerung der Zusammenarbeit blockieren. Auch wenn zu wenig Budget eingeplant ist, macht die Einführung von DevOps keinen Sinn. Denn so sind eine unvollständige Planung, nicht ausreichende Schulung der Beteiligten oder aber das Fehlen von DevOps-Tools vorprogrammiert.
• Kompetenzen: Weiterhin sollten Unternehmen dafür sorgen, dass bei der Einführung von DevOps die fachlichen und sozialen Kompetenzen der Mitarbeiter aus Entwicklung und IT-Betrieb ausreichen. Bei Bedarf muss man Schulungsmaßnahmen durchführen. Andernfalls wird nicht nur die effiziente Aufgabenerfüllung beeinträchtigt, sondern es können auch Sicherheitsverletzungen aufgrund von Unkenntnissen auftreten oder unerkannt bleiben.

Bei der Implementierung von DevOps ist es aus Sicherheitsperspektive besonders empfehlenswert, Mitarbeiter aus der Informationssicherheit und der Revision einzubeziehen. Wie schon beschrieben, kann die Methode dazu führen, dass sich die Entwickler und Administratoren in Graubereichen bewegen und dass so neue Risiken für die Sicherheit des Unternehmens entstehen. Durch eine qualifizierte Risikobewertung und einer Hilfestellung bei der Auswahl und Umsetzung von Kontrollmaßnahmen können die Risiken bereits im Voraus vermindert und Compliance-Probleme reduziert werden.

Fazit

DevOps ist eine junge und vielversprechende Methode zur Verbesserung der Entwicklung und des Betriebs von Software, die große Vorteile für die Wertschöpfung durch die IT mit sich bringt. Allerdings können mit DevOps, besonders bei einer unüberlegten Implementierung, gravierende Risiken entstehen, die möglicherweise den gesamten Geschäftsbetrieb des Unternehmens gefährden. Dazu gehören finanzielle Schäden und Reputationsverluste, die mit Manipulationen, Programmfehlern, Angriffen, Prozessabweichungen und Bedienfehlern einhergehen können. Demgegenüber stehen allerdings auch potenzielle Sicherheitsvorteile, wie die verbesserte Kontrolle der Softwareverteilung sowie größere Nachvollziehbarkeit und erhöhte Transparenz.

Insgesamt kann man DevOps aus Sicherheitsperspektive weder grundsätzlich ablehnen noch empfehlen. Vielmehr müssen sich wie oben beschrieben Unternehmen vor der Einführung von DevOps aller Risiken und Chancen bewusst sein und angemessene Kontrollmaßnahmen auswählen. Vor der Implementierung von DevOps sollten sie zudem prüfen, ob alle erforderlichen Voraussetzungen vorhanden sind, damit der Nutzen nicht durch Defizite in der Sicherheit oder der Wirtschaftlichkeit ausbleibt. Die eigentliche Implementierung führt man dann wie beschrieben am besten schrittweise durch. Besonders zu empfehlen ist es, Vertreter der Informationssicherheit und der Revision in den gesamten Prozess mit einzubeziehen. So werden Experteneinschätzungen zur Sicherheit und Compliance von Anfang an berücksichtigt und Sicherheitsrisiken sowie spätere Compliance-Probleme vermieden.

Dr. Stefan Beißel (CISA, CISSP, PMP) verantwortet als ITSecurity Officer bei der EVO Payments International die Leitung sicherheitsrelevanter Projekte und die Compliance zum PCI-DSS (Stefan.Beissel@EVOpayments.com). Er promovierte am Institut für Produktion und Industrielles Informationsmanagement der Universität Duisburg-Essen.