Continuous Delivery: Software-Prozessautomatisierung – aber sicher?

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.