In drei Schritten zur sicheren Software-Lieferkette

Wesentliche Bestandteile der digitalen Transformation sind automatisierte Softwareentwicklungs- und -bereitstellungsprozesse sowie der Zugang zu Cloud-basierten Tools und Repositories. Zugleich erhöhen sich damit auch die Sicherheitsrisiken für ein Unternehmen.

Folglich sollte eine Defense-in-Depth-Strategie verfolgt werden. Kernelemente sind dabei die Sicherung der Developer-Workstations, der Application-Credentials und der Administrationskonsolen von DevOps-Tools.

Angriffe auf die Software-Lieferkette wie bei SolarWinds können vielschichtig sein und mehrere Zwischenschritte oder Vektoren umfassen. Sie haben jedoch ein gemeinsames Ziel: die Kompromittierung von Identitäten und die Ausweitung des privilegierten Zugriffs.

Bei der Absicherung der Software-Lieferkette besteht bei den meisten Unternehmen noch ein großer Handlungsbedarf, wie eine kürzlich von CyberArk durchgeführte Untersuchung zeigt. So haben 59 Prozent der befragten Unternehmen in Deutschland nach dem SolarWinds-Angriff nichts unternommen, um ihre Software-Lieferkette zu sichern. Zudem erklären 66 Prozent, dass eine Kompromittierung eines Software-Lieferanten bedeuten würde, dass ein Angriff auf ihr Unternehmen nicht aufgehalten werden kann.

Eine ideale Maßnahme zur Gefahrenabwehr stellt der Defense-in-Depth-Ansatz dar. Zu den Kernkomponenten zählt dabei die Sicherung von Identitäten in der gesamten Entwicklungsumgebung, gerade auch unter Berücksichtigung Cloud-nativer Anwendungen. Von essenzieller Bedeutung ist vor allem die Absicherung von CI (Continuous Integration)- und CD (Continuous Deployment)-Prozessen. Drei zentrale Schritte sollte ein Unternehmen im Rahmen eines Defense-in-Depth-Konzepts ergreifen:

1. Sicherung der Developer-Workstations

Entwickler müssen produktiv arbeiten können, ohne dabei durch Sicherheitsmaßnahmen behindert zu werden. Ziel Nummer 1 sollte sein, die Sicherheit transparent zu machen, den Zugriff auf benötigte Ressourcen und Services zu ermöglichen und gleichzeitig den Zugang zu nicht zwingend erforderlichen Ressourcen intelligent einzuschränken.

Unabhängig davon, ob der Zugriff lokal über einen Desktop oder remote über ein Notebook erfolgt, ist für einige DevOps-Prozesse und -Systeme ein hohes Maß an Privilegien vonnöten, wenn auch nur für bestimmte Aktivitäten oder für begrenzte Zeiträume.

Eine der größten Gefahren besteht darin, dass Credentials oft lokal gespeichert werden. Dadurch werden die Workstations der Entwickler zu attraktiven Zielen für Angreifer – etwa für Phishing-E-Mail-Attacken.

Einen effizienten Schutz von Credentials auf Entwickler-Workstations gewährleistet die Einhaltung der folgenden Best Practices:

• Entfernung der lokalen Administratorrechte und Anwendung der Zero-Trust- und Least-Privilege-Prinzipien, um sicherzustellen, dass die Berechtigungen nur bei Bedarf erhöht werden
• Nutzung einer MFA (Multi-Faktor-Authentifizierung)
• Unterbindung der Installation von ungewollten und unbekannten Applikationen
• Unterbindung der Abschaltung von erforderlicher (Sicherheits-) Software
• Sicherung der lokalen Credentials, das heißt Schutz der Standardspeicherorte von Cloud-Zugangsschlüsseln wie AWS Access Keys oder Git-Anmeldedaten
• Blockierung bekannter Malware und Verhinderung potenzieller Gefährdungen durch das Ausführen unbekannter Anwendungen in einem eingeschränkten Modus
• Regelmäßige Überprüfung aller Restriktionen mit dem Ziel, Privilegien zu minimieren und zugleich übermäßige Einschränkungen zu vermeiden, um die Produktivität von Entwicklern nicht zu beeinträchtigen.

2. Schutz der Application-Credentials

Nahezu alle Anwendungen verwenden Anmeldeinformationen für den Zugriff auf Unternehmensressourcen. Der SolarWinds-Angriff hat deutlich gezeigt, warum Unternehmen alle ihre Anwendungen überall und in der gesamten Organisation absichern müssen.

Unzureichend oder inkonsistent gespeicherte Credentials in Anwendungen oder Skripten stellen eine große Schwachstelle dar. Häufig können diese Zugangsdaten nicht einfach rotiert, überwacht oder nachverfolgt werden. Sie werden auch preisgegeben, wenn der Code auf einer Website wie GitHub – versehentlich oder wissentlich ­– veröffentlicht wird.

Mit den folgenden Best Practices können die von Anwendungen, Skripten und anderen nicht-menschlichen Identitäten verwendeten Anmeldeinformationen für den Zugriff auf Datenbanken und andere kritische Ressourcen geschützt werden:

• Eliminierung aller hart kodierten Credentials und Ersatz durch sichere Maßnahmen wie einen API-Aufruf zur Abfrage des Secrets aus einem digitalen Tresor
• Zentrales Rotieren, Verwalten, Speichern und Überwachen von Secrets und Anmeldedaten
• Starke Authentifizierung von Anwendungen, Containern und nicht-menschlichen Identitäten, die auf Secrets und Berechtigungsnachweise zugreifen wollen – in Abhängigkeit der Umgebung (beispielsweise Entwicklung, Test, Produktion)
• Anwendung der Least-Privilege- und RBAC (Role Based Access Control)-Prinzipien, damit eine Anwendung, ein Container, ein Skript oder ein Automatisierungsprozess nur Zugriff auf die benötigten Anmeldeinformationen hat.

Einfach umsetzen lassen sich diese Best Practices mit einer zentralen Secrets-Management-Plattform.

3. Sicherung der Administrationskonsolen von DevOps-Tools

Weit verbreitete DevOps-Tools und -Plattformen wie Jenkins und Azure DevOps, Provisioning-Tools wie Ansible und Puppet sowie Container-Orchestrierungsumgebungen wie Red Hat OpenShift, Kubernetes und VMware Tanzu bieten einen Zugang zu den Entwicklungsressourcen eines Unternehmens – teilweise auch einen Zugriff auf Unternehmensressourcen über die Entwicklung hinaus.

Da solche Administrationskonsolen immer häufiger genutzt werden, sind sie zu attraktiven Zielen für Angreifer geworden, die ungesicherte Konsolen nutzen können, um auf andere Ressourcen in der Entwicklungsumgebung oder darüber hinaus zuzugreifen. Sehr viele Unternehmen verwenden die Standardkonfigurationen dieser Tools, die in einigen Fällen keine Kennwörter für den privilegierten Zugriff erfordern. Angreifer nutzen Bot-Crawler, um diese Schwachstellen systematisch ausfindig zu machen und missbräuchlich zu nutzen.

Obwohl Anbieter und Open-Source-Communities daran gearbeitet haben, diese Schwachstellen zu beheben, bleiben Sicherheitslücken bestehen.

Für die Sicherung der Verwaltungskonsolen von DevOps-Tools empfehlen sich folgende Best Practices:

• Anwendung bewährter Verfahren für den Passwortschutz und MFA-Nutzung für kritische Vorgänge ­– idealerweise für alle Konsolenzugriffe; nach Möglichkeit auch Vermeidung der Verwendung von Standardkonfigurationen und -kennwörtern
• Zentrale Kontrolle und Verwaltung der menschlichen und sonstigen interaktiven Zugriffe auf eine Verwaltungskonsole und eine Kommandozeile (CLI – Command Line Interface), etwa im Hinblick auf die Sicherung des Zugriffs auf das Jenkins User Interface
• Transparente Verwaltung und Überwachung von Sessions und Begrenzung der Angriffsfläche, indem etwa ein CLI-Zugriff nur über Jump-Server möglich ist
• Nutzung einer adaptiven, kontextbasierten MFA, um zum einen die Produktivität aufrechtzuerhalten und zum anderen das Risiko zu minimieren; eine starke Authentifizierung erfordert eine menschliche Überprüfung oder Genehmigung, bevor sensible Skripte automatisch ausgeführt werden wie beim Übertragen von Commits an Git.

Ein ganzheitlicher Ansatz kombiniert diese drei Best Practices, um die gesamte Entwicklungsumgebung zu sichern und einen mehrschichtigen Defense-in-Depth-Ansatz umzusetzen. Zwingend erforderlich ist dafür eine enge Zusammenarbeit der Entwicklungs- und Sicherheitsverantwortlichen, um Strategien festzulegen – und deren Einhaltung durchzusetzen. Diese Kooperation ist allein schon deshalb ein absolutes Muss, weil Entwickler möglicherweise nicht alle potenziellen Schwachstellen kennen. Umgekehrt sind IT- und Sicherheitsteams oft auch weniger vertraut mit Entwicklungstools und -prozessen. Nur gemeinsam können Entwicklung und IT-Security folglich ein hohes Sicherheitsniveau im gesamten Unternehmen realisieren.