Über unsMediaKontaktImpressum
Christina Paule 04. Februar 2020

Continuous Delivery: Software-Prozessautomatisierung – aber sicher?

Ein heutzutage weit verbreiteter Ansatz in der Softwareentwicklung ist Continuous Delivery (CD). Welche Vorteile bringt der Einsatz unseren Unternehmen? Wir möchten Kunden in kurzen Zeitabständen einen erkennbaren Mehrwert liefern. Außerdem haben wir durch Continuous Delivery die Möglichkeit schnell Feedback zu erhalten. Wir können die Time to Market reduzieren und unsere Kunden schneller zufriedenstellen, indem wir in kurzen Zeitabständen z. B. Fehler beheben. Um Continuous Delivery automatisiert durchzuführen, werden Pipelines eingesetzt [1]. Eine Pipeline ist ein automatisierter Prozess, mit dem Software von der Entwicklung bis in die Produktion gebracht werden kann. Doch was passiert, wenn der Continuous-Delivery-Prozess nicht sicher ist und Angreifer diesen Missstand ausnutzen?

Jedes Unternehmen muss sicherstellen, dass sein Continuous-Delivery-Prozess gegen gängige Angriffe abgesichert ist. Dass das Thema sehr aktuell ist, zeigt der Angriff auf Equifax [2]. Equifax ist eine Wirtschaftsauskunftei aus der USA. Das Unternehmen speichert sensitive Daten, wie Kreditkarten und Sozialversicherungsnummern. Im Zeitraum von März bis Juli 2017 gelang es Angreifern Daten zu stehlen, die 147 Millionen Menschen in Amerika betroffen haben. Die Ursache war die Ausnutzung einer Schwachstelle in einer verwendeten öffentlichen Bibliothek. Der Übergriff hätte verhindert werden können, wenn die Bibliothek nach Bekanntgabe der Schwachstelle auf die gepatchte Version aktualisiert worden wäre. Als Folge des Übergriffs muss Equifax jetzt hunderte Millionen Dollar Strafe zahlen und das Image des Unternehmens ist dadurch auch geschädigt.

Wie sicher ist Ihr Continuous-Delivery-Prozess? Schlummert vielleicht auch eine Schwachstelle in Ihrem Prozess, welche Sie noch nicht entdeckt haben?

Dieser Artikel deckt auf, welche Angriffe bei Continuous-Delivery-Prozessen existieren, wie Schwachstellen erkannt und welche Gegenmaßnahmen getroffen werden können.

Jedes Unternehmen hat schützenswerte Güter (Assets). Ein solches Gut, z. B. sensitive Daten (Kreditkartennummer, Sozialversicherungsnummer, ...) oder Ressourcen, sollten nicht für einen Angreifer (Hacker) sichtbar oder manipulierbar sein. Ziel eines Unternehmens sollte sein, dass seine Applikationen und Ansätze gegen die üblichen Angriffe gerüstet sind. Das kann gelingen, wenn Sicherheit – ein Softwarequalitätsmerkmal – so früh wie möglich in den Softwareentwicklungsprozess integriert wird. Nachdem im Mai 2018 in der Europäischen Union eine neue allgemeine Datenschutzverordnung (DSGVO) [3] in Kraft getreten ist, müssen sich Unternehmen damit beschäftigen, wie sie das Sicherheitsniveau ihrer Anwendungen erhöhen können.

Welche typischen Angriffe gibt es denn in Bezug auf Continuous Delivery?

  • Denial-of-Service-Angriffe: Es gelingt einem Angreifer Komponenten abzuschalten oder so zu verlangsamen, dass das System nicht mehr nutzbar ist.
  • Man-in-the-middle-Angriffe: Ein Angreifer kann eine Verbindung zwischen zwei Endpunkten kontrollieren und dabei die Anfragen (Request) und die Ergebnisse (Response) manipulieren oder eventuell an diesen Stellen bösartigen oder ausführbaren Code einschleusen. Ein Angriffszenario könnte sein, dass ein Angreifer während des Herunterladens von externen Bibliotheken bösartigen Code in den Build-Prozess einschleust.
  • Authentifizierungs-Angriffe: Authentifizierung bezeichnet die Prüfung der Identität. Wenn eine Applikation oder Pipeline keine oder unzureichende Zugriffsbeschränkungen hat, dann ist es für einen Angreifer leicht, sich Zugriff zur Applikation zu verschaffen.
  • Autorisierungs-Angriffe: Bei der Autorisierung handelt es sich um die Prüfung der Berechtigung. Vergibt ein Unternehmen allen Mitarbeitern z. B. Administrator-Rechte, kann jeder Mitarbeiter, auch unabsichtlich, sehr leicht in vielen Komponenten die Sicherheitseinstellungen ausschalten.
  • Cryptojacking-Angriffe: Dabei werden Ressourcen (CPU) von Unternehmen/Personen missbraucht, um digitale Währungen zu schürfen (Crypto-Mining) [4].

Threat Modeling – ein Ansatz, der die Probleme von Anfang an betrachtet

Um den Continuous-Delivery-Prozess gegen diese Angriffe schützen zu können, muss bekannt sein, an welcher Stelle eine Bedrohung bzw. Schwachstelle besteht. Um das herauszufinden eignet sich der Threat-Modeling-Ansatz [5], welcher aus drei Teilen besteht:

  1. Zerlegung der Anwendung in Komponenten und Datenflüsse,
  2. Bestimmung und Ordnung der Bedrohungen nach Kritikalität und
  3. Ermittlung von Gegen- und Minderungsmaßnahmen.

Dieser Ansatz hilft dabei, schon frühzeitig Sicherheit in den Prozess zu integrieren.

Wann ist ein Prozess sicher?

Doch kann man behaupten, dass eine Applikation/Prozess zu 100 Prozent sicher ist? Nein. Aber es können Maßnahmen getroffen werden, die dazu führen, dass ein System sicherer wird und gegen die typischen Angriffe resistent ist. Die Einhaltung der sechs bekannten Informationssicherheitsattribute erhöht die Sicherheit im Prozess:

  1. Vertraulichkeit (Confidentiality): Meine Assets sollten nicht an die Öffentlichkeit gelangen und von nicht berechtigten Personen gelesen werden dürfen.
  2. Integrität (Integrity): Mein Asset sollte nicht von jemandem externen manipuliert werden können.
  3. Verfügbarkeit (Availability): Mein Prozess sollte immer erreichbar sein.
  4. Nichtabstreitbarkeit (Nonrepudiation): Es sollten alle Aktionen der Mitarbeiter nachvollzogen werden können.
  5. Authentifizierung: Prüfung der Identität der zugreifenden Personen. Jede berechtigte Person, die Zugriff zu meinem Continuous-Delivery-Prozess haben soll, muss sich ausweisen können, z. B. mit Benutzername und Passwort.
  6. Autorisierung: Nicht jeder Nutzer benötigt für alle Komponenten den vollen Zugriff (Administrator-Rechte).

Durchführung des Threat-Modeling-Ansatzes an einem konkreten Beispiel

Wie dieser Ansatz sich jetzt auf den Continuous-Delivery-Ansatz anwenden lässt, zeige ich nun an einer Beispiel-Pipeline, die in Abb. 1. dargestellt ist. Der Ablauf der Pipeline ist wie folgt:

  • 1. Der Entwickler commited den Code in das Source-Code Repository Bitbucket.
  • 2. & 3. Der Build-Prozess wird gestartet.
  • 4. & 5. Die Artefakte werden auf 20 zur Verfügung stehenden AWS Docker Nodes gebaut.
  • 6. Die entstandenen Artefakte werden in JFrog Artifactory gespeichert.
  • 7. & 8. & 9. Die Software wird dann in die Cloud deployed, oder wenn es sich um die mobile Version handelt, in den Hockey-App-Store.

Die grafische Darstellung der Komponenten und Datenabläufe ist in Abb. 1 dargestellt. Somit ist der erste Schritt des Threat-Modeling-Ansatzes erreicht. Wir haben dadurch eine Abbildung der Komponenten und ihrer Datenabläufe für diesen speziellen Continuous-Delivery-Prozess erhalten.

Doch wie können nun die Schwachstellen in einer solchen Pipeline erkannt werden? Dazu eignet sich die "STRIDE"-Methode (Schritt 2). Jeder Buchstabe dieses Wortes steht für eine Bedrohungskategorie.

  • S steht für Spoofing Identity: Es gelingt einem Angreifer, sich als jemanden auszugeben, der er gar nicht ist. Ist ein Angriff erfolgreich, wird die Authentifizierung dadurch verletzt.
  • T steht für Tampering with Data: Gelingt es einem Angreifer sich z. B. zwischen zwei Endpunkte zu schalten, damit er dadurch die abgesendeten Requests/Responses des Nutzers manipulieren kann, dann ist die Integrität verletzt.
  • R steht für Repudiation: Es kann nicht nachvollzogen werden, welche Aktionen ein Angreifer ausgeführt hat. Dadurch wird die Nachvollziehbarkeit verletzt.
  • I steht für Information Disclosure: Es gelingt Personen, Daten einzusehen, für die sie nicht berechtigt sind. Tritt diese Bedrohung ein, wird das Attribut Vertraulichkeit verletzt.
  • D steht für Denial of Service: Einem Angreifer ist es möglich, das System herunterzufahren oder es so stark zu verlangsamen, dass es nicht mehr nutzbar ist. Diese Bedrohung beeinflusst die Verfügbarkeit des Systems/Prozesses.
  • E steht für Elevation of Privilege: Kann ein Angreifer eine solche Schwachstelle ausnutzen und die Kontrolle des Systems erlangen, wird das Sicherheitsattribut Autorisierung verletzt. Er kann somit alle Tätigkeiten ausführen, wie ein berechtigter Nutzer.

Abb. 2 zeigt bildhaft die verschiedenen sechs Bedrohungskategorien der STRIDE-Methode. Werden die Bedrohungskategorien auf die Pipeline angewandt, lassen sich daraus die Schwachstellen ableiten.

Hat sich Ihr Unternehmen noch nie mit der STRIDE-Methode auseinandergesetzt und Sie möchten möglichst viele Schwachstellen und Bedrohungen in Pipelines auffinden, dann eignet sich sehr gut das "Elevation of Privilege (EoP) Threat Modeling Card Game" von Microsoft [6]. Auf jeder Karte steht ein möglicher Angriff. Mit diesen Karten können Sie spielerisch feststellen, welche Bedrohungen und Schwachstellen in ihrem Prozess existieren.

Die Ausführung der STRIDE-Methode auf der Beispiel-Pipeline ergab folgende potenzielle Schwachstellen:

  1. Jeder Mitarbeiter, der Zugriff zur Pipeline hat, kann eine Schwachstelle der Pipeline sein. Durch absichtliche oder unabsichtliche Handlungen kann die Sicherheit beeinträchtigt werden. Auch Mitarbeiter, die nicht mehr im Unternehmen sind, können mit nicht-abgestellten Zugängen Schäden anrichten.
    Tipp: Schulen Sie ihre Mitarbeiter, wie sie mit der Pipeline umgehen sollen. Entziehen Sie Mitarbeitern, welche das Unternehmen verlassen, die Zugriffsrechte und geben Sie nicht allen Mitarbeitern Administrator-Rechte.
  2. Unverschlüsselte Verbindungen zwischen den Komponenten der Pipeline. In der Beispiel-Pipeline existiert eine Schwachstelle, sodass die externen Bibliotheken beim Build von Maven Central über HTTP heruntergeladen wurden. Diese Schwachstelle wurde nach Aufdeckung umgehend entfernt. Einem Angreifer wäre es möglich gewesen, über diese unverschlüsselte Verbindung als Man-in-the-middle die Bibliotheken auszutauschen und bösartige Software einzuschleusen.
    Tipp: Verwenden Sie immer HTTPS, um auf Komponenten zuzugreifen.
  3. Unsichere Umgebungen der CD-Pipeline-Komponenten
    Tipp: Prüfen Sie regelmäßig die Sicherheitseinstellungen Ihrer Umgebung und stellen Sie sicher, dass es einem Angreifer nicht gelingen kann, sich mit Ihrer Umgebung z. B. der Cloud zu verbinden.
  4. Keine oder wenige Zugangsbeschränkungen existieren. Existiert kein Authentifizerungsmechanismus für die Pipeline-Komponenten können alle möglichen Personen auf Ihre Systeme zugreifen.
    Tipp: Jede Pipeline-Komponente sollte eine Zugangsbeschränkung besitzen und diese sollte auch verwendet werden.
  5. Die Verwendung von anfälligen Versionen der CD-Pipeline-Komponenten oder unzureichende Sicherheitskonfigurationen: In der Beispiel-Pipeline wurde mit der Schwachstellen-Datenbank VulDB  [7] festgestellt, dass die eingesetzten Versionen von Jenkins und Bitbucket mit Schwachstellen behaftet waren. Über diese Schwachstellen kann der Angreifer bösartigen Code in die Pipeline einschleusen und ausführen. Das kann dazu führen, dass bei jedem Build der Anwendung ungewollter Code ausgeführt wird.
    Tipp: Regelmäßiges Updaten der Pipeline-Komponenten.
  6. Verwundbare Code-Commits, CD-Pipeline-Skripte, Dockerimages/-container, Artefakte. Wenn Entwickler alle Rechte haben, können sie jeglichen Code committen. Dabei sollte darauf geachtet werden, dass sich keine sensitiven Daten in den Commits befinden. Des Weiteren sollte darauf geachtet werden, dass die Artefakte oder Dockerimages keine Schwachstellen besitzen. Alle genannten Komponenten sind Einfallstore für Angreifer.
    Tipp: Verwenden Sie automatisierte Tools, die ihre Artefakte auf Schwachstellen prüfen, z. B. OWASP Dependency Check [8] oder SpotBugs [9]. Des Weiteren können Tools eingesetzt werden, die automatisiert Dockerimages auf Schwachstellen prüfen. Zudem sollten sensitive Daten in Git entweder gar nicht oder nur verschlüsselt abgelegt werden sollten. Hier bieten sich Tools wie Hashicorp Vault [10] oder git-secret.io [11] an.
  7. Keine Überprüfung der Änderungen an der Pipeline. In der Pipeline ist es möglich, dass jeder Entwickler Änderungen an den Pipeline-Skripten vornehmen kann. Das Risiko ist bei diesem Team aber sehr gering, dass etwas commited wird, dass die Pipeline zerstört, da ein Review nach dem 4-Augen-Prinzip stattfindet. Jede Änderung muss von einem anderen Entwickler geprüft werden.
    Tipp: Review nach dem 4-Augen-Prinzip einführen und vorher die Pipeline-Skripte testen, bevor sie in der Produktion Schaden anrichten können.
  8. Nichtnachvollziehbarkeit von Änderungen an der Pipeline.
    Tipp: Um diese Schwachstelle zu vermeiden sollte Logging eingesetzt und Monitoring-Tools verwendet werden.

Schwachstelle entdeckt und dann?

Doch wie ist das Vorgehen, wenn Schwachstellen entdeckt wurden? Es muss entschieden werden, wie kritisch und wie hoch das Risiko für das Unternehmen ist. Daraus muss abgeleitet werden, welche Gegen- oder Minimierungsmaßnahmen einzuleiten sind.

Warum ist es so schwierig, Sicherheit in den Continuous-Delivery-Prozess zu integrieren?

Meine Erfahrung aus der Praxis zeigt, dass viele Entwicklungsteams von Drittanbietern und vor allem von ihren Kunden abhängig sind, wie stark sie Sicherheit in den Prozess integrieren können. Stellt der Kunde kein Budget und Zeit zur Verfügung, fällt die Sicherheit buchstäblich unter den Tisch. Deshalb ist es sehr wichtig, die Kunden für dieses Thema zu sensibilisieren und bei ihnen das Bewusstsein für dieses Qualitätsmerkmal zu stärken. Sicherheit sollte aus meiner Sicht genauso integriert werden, wie das Testen. Je früher es Beachtung findet, desto geringer sind die Kosten am Ende. Eins ist klar: wer bei Continuous Delivery nur auf schnelle automatisierte Softwareauslieferung setzt und Sicherheit dabei vernachlässigt, verliert aus meiner Sicht. Gelingt es einem Hacker die Kontrolle über Ihren Prozess zu erlangen, dann ist es schon zu spät und Sie haben es versäumt, die Sicherheit rechtzeitig in Ihrem Prozess zu integrieren. Eine einzige Schwachstelle in ihrem Prozess reicht aus, damit ein Angreifer die vollständige Kontrolle über Ihren Prozess erlangen kann. Deshalb setzen Sie sich das Ziel, dem Angreifer immer einen Schritt voraus zu sein und fangen Sie direkt an, Sicherheit in Ihren Continuous-Delivery-Prozess zu integrieren.

Quellen
  1. J. Humble, D. Farley: Continuous delivery: Reliable Software Releases Through Build, Test, and Deployment Automation. A Martin Fowler signature book. Upper Saddle River, NJ: Addison-Wesley, 2011
  2. FAZ: Hacker erbeuten Daten von mehr als 140 Millionen Amerikanern
  3. Datenschutz-Grundverordnung DSGVO
  4. Security Insider: Neue Gefahr Cryptojacking
  5. A. Shostack: Threat Modeling: Designing for Security. John Wiley & Sons, 2014
  6. Microsoft: Elevation of Privilege (EoP) Threat Modeling Card Game
  7. VulDB
  8. Dependency-Check
  9. SpotBugs
  10. Vault-Project
  11. git-secret

Autorin

Christina Paule

Christina Paule entwickelt agile cloud-native Java- und Kotlin-Applikationen auf Basis der Spring-Plattform und berät die Kunden rund um diese Themen.
>> Weiterlesen
Das könnte Sie auch interessieren