Supply-Chain-Attacken, insbesondere solche, die auf Continuous Integration/Continuous Delivery (CI/CD)-Pipelines abzielen, sind auf dem Vormarsch. Es ist leicht, diese Angriffe als etwas zu betrachten, das nur anderen passiert, aber die Realität ist, dass auch Ihr Unternehmen Teil der Lieferkette ist. Unabhängig davon, ob Ihr Unternehmen Software für den internen Gebrauch entwickelt, sie als Teil einer Dienstleistung für Ihre Kunden anbietet oder sie als Produkt verkauft – Sie sind einem Risiko ausgesetzt.
Wenn Ihr Unternehmen CI/CD-Tools wie Azure DevOps oder GitHub Enterprise verwendet, können Angreifer diese Systeme ausnutzen, um Ihren Code zu kompromittieren, oder die Infrastruktur nutzen, um Zugang zu Ihrem Netzwerk zu erhalten. Die Absicherung Ihrer CI/CD-Pipelines ist nicht optional. Sie ist essentiell. Das bedeutet eine kontinuierliche Prüfung der Nutzung, eine Sammlung von Audit-Logs in Ihrer SIEM-Lösung und ein aktives Monitoring von Logs auf bösartige Aktivitäten, um Verstöße oder Sicherheitsvorfälle zu verhindern.
Die sofort einsatzbereiten Cloud-SIEM-Regeln von Sumo Logic für Azure DevOps und GitHub vereinfachen diesen Prozess, indem sie das Rauschen durchbrechen, Bedrohungen erkennen und Ihnen eine bessere Kontrolle und Sichtbarkeit Ihrer Software-Lieferkette ermöglichen.
Supply-Chain-Attacken: eine Definition
Supply-Chain-Attacken haben in den letzten Jahren für Schlagzeilen gesorgt. Bemerkenswerte Beispiele sind:
- der verheerende Angriff auf SolarWinds, dem fast 18.000 Unternehmen zum Opfer fielen.
- die Kompromittierung der Finanzsoftware X_TRADER führte zu Angriffen auf Kommunikations-, Finanz- und kritische Infrastrukturunternehmen.
- die Kompromittierung von Kaseya, bei der Angreifer die Verwaltungssoftware des Unternehmens kompromittierten, um Ransomware-Angriffe auf etwa 1.500 Kunden des Unternehmens durchzuführen.
Supply-Chain-Attacken gibt es in vielen Formen. Sie können vom Diebstahl der Anmeldedaten eines Dienstleisters (wie 2013 beim Target-Datendiebstahl über dessen HVAC-Vertragspartner) bis hin zur Ausnutzung von Schwachstellen in Open-Source-Code reichen, der in der Software vieler Anbieter (wie log4j) verwendet wird.
Lesen Sie weiter, um mehr über Angriffe zu erfahren, die während der Softwareentwicklung und -distribution auftreten. Bei diesen Attacken wird bösartiger Code in vertrauenswürdiger Software ausgeführt, der sie zu einer potenziellen Waffe macht, um Schaden anzurichten.
Letztlich nutzen Supply-Chain-Attacken Vertrauen aus. Angreifer machen sich das implizite Vertrauen der Benutzer zunutze, dass die Unternehmen, die Software und Dienste anbieten, keine böswilligen Absichten haben und ihre Sicherheitspraktiken gewissenhaft anwenden.
Wie Angreifer CI/CD-Pipelines für Supply-Chain-Attacken ausnutzen
Sehen wir uns einmal an, wie die Angreifer die oben aufgeführten hochkarätigen Attacken durchgeführt und ihre Ziele erreicht haben. In all diesen Fällen hat der Angreifer eine Phase der Softwareerstellung oder des Softwareverteilungsprozesses gekapert, um bösartigen Code einzuschleusen. Lassen Sie uns einen genaueren Blick auf die Methoden werfen, die Angreifer verwendet haben, um in diese Systeme einzudringen:
- SolarWinds: „[Der Angreifer] drang in einen der Build-Server von Orion ein und implantierte eine Backdoor in eines der Update-Module. Dieses kompromittierte, digital signierte Update wurde an etwa 18.000 SolarWinds-Kunden, darunter Fortune-500-Unternehmen, verteilt und über deren Website zur Verfügung gestellt.“
- 3CX: (Die durch den X_TRADER-Angriff ermöglichte Supply-Chain-Attacke): „Schließlich gelang es dem Angreifer, sowohl die Windows- als auch die macOS-Build-Umgebung zu kompromittieren. In der Windows-Build-Umgebung setzte der Angreifer einen TAXHAUL-Launcher und einen COLDCAT-Downloader ein, die durch DLL-Search-Order-Hijacking über den IKEEXT-Dienst bestehen blieben und mit LocalSystem-Privilegien liefen. Der macOS-Build-Server wurde mit der POOLRAT-Backdoor kompromittiert, die Launch Daemons als Persistenzmechanismus verwendete.“
- Kaseya: „Unter Ausnutzung des VSA-Remote-Management-Dienstes von Kaseya brachten die REvil-Akteure ein bösartiges Update-Paket auf den Markt, das auf Kunden von Managed Service Providern und Unternehmensanwender der On-Prem-Version der VSA-Remote-Monitoring- und -Management-Plattform von Kaseya abzielte.“
Die Sumo Logic Azure DevOps- und GitHub-Regeln
Das Team von Sumo Logic Threat Labs hat zwei Regelsätze innerhalb des Sumo Logic Cloud-SIEM veröffentlicht, um die Überwachung und Erkennung von Angreiferaktivitäten in Ihrer CI/CD-Umgebung zu unterstützen:
- GitHub-Regeln: Eine Reihe von Regeln, die verdächtige Aktivitäten auf GitHub erkennen sollen, veröffentlicht am 6. Dezember 2024.
- Azure DevOps-Regeln: Eine Reihe von Regeln, die auf Sentinel-Regeln von Microsoft für Azure DevOps, zusammen mit der Tuning-Anleitung von IBMs X-Force Red in ihrem hervorragenden Papier „Hiding in the Clouds: Abusing Azure DevOps Services to Bypass Microsoft Sentinel Analytic Rules“ basieren. Diese Regeln wurden am 13. März 2025 veröffentlicht.
Wie Sie mit den Azure DevOps- und GitHub-Regeln von Sumo Logic loslegen
Wenn Sie ein Sumo Logic Cloud-SIEM-Kunde sind, sind in Ihrer Umgebung bereits Azure DevOps- und GitHub-Regeln aktiviert. Um von diesen Regeln zu profitieren, sollten Sie sicherstellen, dass Sie Protokolle von Ihrer CI/CD-Plattform erfassen. Hier eine kurze Anleitung zur Durchführung der Protokollerfassung.
Azure DevOps-Protokollerfassung
Um Azure DevOps-Protokolle zu erfassen:
- Aktivieren Sie Auditing in Ihrer Azure DevOps-Organisation.
- Konfigurieren Sie die Audit-Protokolle so, dass sie an einen Azure Event Hub gestreamt werden.
- Erfassen Sie die Protokolle vom Event Hub mit einem Sumo Logic Hosted Collector.
Detaillierte Anweisungen finden Sie in der Dokumentation von Microsoft zur Aktivierung von Auditing in Ihrer Azure DevOps-Organisation und zur Konfiguration der Audit-Protokolle für den Stream zu einem Azure Event Hub. Siehe auch das Sumo Logic-Hilfethema „Azure Event Hubs Source“ für weitere Details zum Erfassen von Protokollen von Azure Event Hubs. Stellen Sie sicher, dass „Forward to Cloud-SIEM“ in der von Ihnen erstellten Protokollquelle aktiviert ist.
GitHub-Protokollerfassung
Hinweis: Die GitHub-Regeln wurden speziell für GitHub Enterprise Audit Logs entwickelt.
Zum Erfassen von GitHub-Protokollen:
- Streamen Sie GitHub-Protokolle in einen AWS S3-Bucket.
- Erfassen Sie die GitHub-Protokolle von S3 über einen Sumo Logic Hosted Collector.
Für die Einrichtung folgen Sie dem GitHub-Thema „Setting Up Streaming to Amazon S3“ zur Konfiguration des Protokoll-Streamings zu S3. Verwenden Sie dann das Sumo Logic-Hilfethema „Amazon S3 Source“, um die Protokollerfassung vom S3-Bucket zu konfigurieren. Fügen Sie beim Einrichten der Protokollquelle unbedingt die folgenden Felder hinzu:
| Feldname | Feldwert |
| _siemForward | true |
| _parser | /Parser/System/Github/GitHub Enterprise Audit |
Konfigurationsbeispiel – GitHub-Protokollerfassung über Amazon S3-Protokollquelle
Angriffstechniken, die von den Sumo Logic Cloud-SIEM-Regeln erkannt werden
Die Sumo Logic Cloud-SIEM-Regeln erkennen verschiedene Angriffstechniken in Ihrer CI/CD-Umgebung. Im Folgenden finden Sie einige wichtige Angriffstechniken, die von den Azure DevOps- und GitHub-Regeln erkannt wurden.
Technique: Pull Request Review Bypass
Erkennungsregeln:
- Azure DevOps – First seen pull request policy bypassed
- GitHub – Pull request review requirement removed
CI/CD-Pipelines sind auf Tempo ausgelegt und ermöglichen es Entwicklern, Code-Updates mehrmals täglich in die Produktion zu übertragen. Obwohl dieser schnelle Veröffentlichungsrhythmus für ein Unternehmen und seine Kunden von Vorteil ist, erhöht er das Risiko, dass ein Entwickler einseitig fehlerhaften oder bösartigen Code in die Produktion einbringt.
Eine Möglichkeit, dieses Risiko zu mindern, ist ein Peer Review, ein Prozess, bei dem Pull-Anfragen genehmigt werden müssen, bevor sie in die Build/Release-Pipeline gelangen.
Laut der OWASP Top 10 CI/CD-Sicherheitsrisiken ist die Umgehung des Review-Prozesses das größte Risiko bei CI/CD. Ein reales Beispiel für dieses Risiko trat im März 2021 auf, als nicht genehmigte Änderungen an der PHP-Codebasis vorgenommen wurden.
Die Umgehung der Überprüfung kann gerechtfertigt sein, und Azure DevOps bietet die Möglichkeit, die Richtlinien für Pull-Requests über die Einstellung „bypass policy“ zu umgehen. Ihr Unternehmen kann triftige Gründe haben, die Pull-Request-Richtlinien zu umgehen, wenn auch nur vorübergehend. Wenn eine Umgehungsrichtlinie erlaubt ist, sollten Sie auf möglichen Missbrauch achten.
Die Azure DevOps-Regel „First seen pull request policy bypassed“ macht den SOC-Analysten darauf aufmerksam, dass ein Benutzer eine Pull-Request umgeht, wenn er in den letzten 90 Tagen nicht dabei beobachtet wurde. Wenn die Regel ausgelöst wird, sollte der SOC-Analyst feststellen, ob die Umgehung der Pull-Request erwartet wurde, und den Benutzer, der die Umgehung der Pull-Request durchgeführt hat, auf Anzeichen einer Kontokompromittierung oder anderer Insider-Bedrohungsaktivitäten untersuchen.
Regel „First seen pull request policy bypassed“ und Log-Auszug
Die GitHub-Regel „PR review requirement removed“ überwacht ebenfalls die Umgehung der Pull Request Reviews, aber sie tut dies, indem sie die Überprüfungsanforderung vollständig aus dem Repository entfernt.
Regel „PR review requirement removed“ und Log-Auszug
Technik: Mitgliedschaftsänderungen in privilegierten Gruppen
Erkennungsregeln:
- Azure DevOps – Change made to the administrator group
- GitHub – Administrator added or invited
Im Mai 2019 wurde das Stack Overflow-Netzwerk von einem Angreifer kompromittiert, der sich „Zugang zur Moderatoren- und Entwicklerebene auf allen Seiten des Stack Exchange-Netzwerks verschafft hat.“ Der Angreifer hat durch diesen Angriff Quellcode und personenbezogene Daten von 184 Stack Overflow-Benutzern exfiltriert.
Jedes Ereignis, bei dem ein Benutzer administrative Privilegien erhält, ist angesichts der Auswirkungen, die der Benutzer haben kann, bemerkenswert. OWASP stuft eine unzureichende Identitäts- und Zugriffsverwaltung als das zweitgrößte Risiko für CI/CD-Pipelines ein. Dieses Risiko deckt eine Vielzahl von Möglichkeiten ab, wie ein falsches Identitätsmanagement die CI/CD-Pipeline kompromittieren kann, einschließlich der Nichteinhaltung Least-Privilige-Prinzips.
Die Azure DevOps-Regel „Changes made to administrator group“ benachrichtigt SOC-Analysten, wenn ein Benutzer zu mehreren privilegierten Gruppen in Azure DevOps hinzugefügt wird, z. B. Projekt-Administratoren, Project-Collection-Administratoren, Project-Collection-Service-Accounts, Build-Administratoren und Project-Collection-Build-Administratoren.
Wenn diese Regel ausgelöst wird, sollte der SOC-Analyst feststellen, ob es sich bei der Gruppenänderung um eine genehmigte Änderung handelt, z. B. indem er nach einem entsprechenden Änderungskontrollticket sucht, wenn CI/CD in den Bereich der Änderungskontrolle fällt, und den Benutzer, der die Änderung vorgenommen hat, auf Anzeichen einer Kontokompromittierung untersuchen.
Regel „Change made to administrator group“ und Log-Auszug
Ähnlich wie der Name schon sagt, erkennt die GitHub-Regel „Administrator added or invited“, wenn ein neuer Administrator hinzugefügt oder eingeladen wird.
Regel „Administrator added or invited“ und Log-Auszug
Technik: Integration bösartiger Tools
Erkennungsregeln:
- Azure DevOps – First seen – New extension installed
- GitHub – First seen application interacting with API
Es gibt ein reichhaltiges Ökosystem von Tools, die in Ihre CI/CD-Umgebung integriert werden können, um Funktionen wie Codeprüfung, Ressourcenmanagement und Secrets Substitution hinzuzufügen. Leider sind diese Tools und Dienste auch ein Angriffsvektor.
Im Juli 2020 wurden die Zugangsdaten für die DeepSource GitHub-Anwendung, die Funktionen wie statische Analyse, SAST, Code Coverage und IaC-Analyse bietet, kompromittiert und dazu verwendet, die Zugangsdaten der Benutzer der Anwendung zu kompromittieren.
Die Azure DevOps-Plattform umfasst einen Extensions Marketplace. Wie das DeepSource-Beispiel zeigt, besteht bei der Installation und Verwendung von Erweiterungen die Gefahr, dass bösartiger Code von der Erweiterung selbst oder von Angreifern eingeschleust wird, die über die Erweiterung in Ihrer DevOps-Umgebung Fuß fassen. OWASP stuft dieses Risiko, das in die Kategorie „unkontrollierte Nutzung von Diensten Dritter“ fällt, als das achthäufigste Risiko ein.
Die Azure DevOps-Regel „New extension installed“ wird ausgelöst, wenn eine neue Erweiterung (gegenüber einer 90-Tage-Baseline) in der Azure DevOps-Organisation installiert wurde. Wenn diese Regel ausgelöst wird, sollte der SOC-Analyst untersuchen, ob es sich um eine bekannte Änderung handelt (z. B. über Änderungskontrolltickets) und ob die Erweiterung für die Verwendung im Unternehmen zugelassen ist.
Regel „New extension seen rule“ und Log-Auszug
Die GitHub-Regel „First seen application interacting with API“ überwacht Anwendungen, die die GitHub-API verwenden und in den letzten 90 Tagen nicht dabei beobachtet wurden. Diese Erkennung ist umfassender als die Erkennung „New extension seen“, da sie alle unbekannten Anwendungen auslöst, die mit der API interagieren, nicht nur Erweiterungen.
Regel „First seen application interacting with API“ und Log-Auszug
Die Protokollierung Ihrer CI/CD-Umgebung ist entscheidend für die Überwachung ihrer Sicherheit. OWASP stimmt zu, stuft „Unzureichende Protokollierung und Sichtbarkeit“ als Risiko Nr. 10 ein und führt an, dass „unzureichende Protokollierung und Sichtbarkeit es einem Angreifer ermöglichen, bösartige Aktivitäten innerhalb der CI/CD-Umgebung durchzuführen, ohne in irgendeiner Phase der Attack-Kill-Chain entdeckt zu werden, einschließlich der Identifizierung der Techniken, Taktiken und Verfahren (Techniques, Tactics and Procedures, TTPs) des Angreifers als Teil einer Untersuchung nach einem Vorfall.“
Sichern Sie Ihre CI/CD-Umgebung mit Sumo Logic
Supply-Chain-Attacken stellen eine wachsende Bedrohung dar, und Ihre CI/CD-Umgebung ist ein bevorzugtes Ziel. Durch die proaktive Überwachung Ihres CI/CD-Ökosystems mit den Sumo Logic Cloud-SIEM-Regeln können Sie verdächtige Aktivitäten erkennen und darauf reagieren, bevor sie zu einer vollständigen Sicherheitsverletzung führen.
Um mehr über Sumo Logic Cloud-SIEM zu erfahren, schauen Sie sich das Produkt an oder klicken Sie sich durch eine interaktive Demo.
