{"id":52742,"date":"2025-03-20T07:58:00","date_gmt":"2025-03-20T15:58:00","guid":{"rendered":"https:\/\/www.sumologic.com\/blog\/schuetzen-sie-ihre-ci-cd-pipelines-mit-den-sumo-logic-cloud-siem-regeln-vor-supply-chain-attacken"},"modified":"2025-09-30T13:17:03","modified_gmt":"2025-09-30T21:17:03","slug":"secure-azure-devops-github-supply-chain-attacks","status":"publish","type":"blog","link":"https:\/\/www.sumologic.com\/de\/blog\/secure-azure-devops-github-supply-chain-attacks","title":{"rendered":"Sch\u00fctzen Sie Ihre CI\/CD-Pipelines mit den Sumo Logic Cloud-SIEM-Regeln vor Supply-Chain-Attacken"},"content":{"rendered":"\n<section class=\"e-stn e-stn-0d652506f82b000a392973813b918ee25d5b4211 e-stn--glossary-inner-content e-stn--table-of-content\"><div class=\"container\">\n<div class=\"wp-block-b3rg-row e-row row\">\n<div class=\"wp-block-b3rg-column e-col e-col-1f7b3997080fc292474d26ff00c905d99d3520fa e-col--content-wrapper  col-sm-12 col-lg-12 col-xl-12\">\n<div class=\"e-div e-div-a1b32f66e1749758df41d5aea14f647cd10e362c e-div--card-btn-link\">\n<figure class=\"wp-block-image size-full\"><img loading=\"lazy\" decoding=\"async\" width=\"1400\" height=\"400\" src=\"https:\/\/www.sumologic.com\/wp-content\/uploads\/header-ThreatLabs_SupplyChain_blog_700x200.jpg\" alt=\"\" class=\"wp-image-14766\" title=\"\"><\/figure>\n\n\n\n<p><\/p>\n\n\n\n<p>Supply-Chain-Attacken, insbesondere solche, die auf\u00a0<a href=\"\/solutions\/developer-tools\">Continuous Integration\/Continuous Delivery (CI\/CD)-Pipelines<\/a> abzielen, sind auf dem Vormarsch. Es ist leicht, diese Angriffe als etwas zu betrachten, das nur anderen passiert, aber die Realit\u00e4t ist, dass auch Ihr Unternehmen Teil der Lieferkette ist. Unabh\u00e4ngig davon, ob Ihr Unternehmen Software f\u00fcr den internen Gebrauch entwickelt, sie als Teil einer Dienstleistung f\u00fcr Ihre Kunden anbietet oder sie als Produkt verkauft \u2013 Sie sind einem Risiko ausgesetzt.<\/p>\n\n\n\n<p>Wenn Ihr Unternehmen CI\/CD-Tools wie Azure DevOps oder GitHub Enterprise verwendet, k\u00f6nnen 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\u00fcfung der Nutzung, eine Sammlung von Audit-Logs in Ihrer <a href=\"https:\/\/www.sumologic.com\/guides\/siem\" data-type=\"resource\" data-id=\"3026\">SIEM<\/a>-L\u00f6sung und ein aktives Monitoring von Logs auf b\u00f6sartige Aktivit\u00e4ten, um Verst\u00f6\u00dfe oder Sicherheitsvorf\u00e4lle zu verhindern.<\/p>\n\n\n\n<p>Die sofort einsatzbereiten Cloud-SIEM-Regeln von Sumo Logic f\u00fcr 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\u00f6glichen.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"supply-chain-attacks-defined\">Supply-Chain-Attacken: eine Definition<\/h2>\n\n\n\n<p>Supply-Chain-Attacken haben in den letzten Jahren f\u00fcr Schlagzeilen gesorgt. Bemerkenswerte Beispiele sind:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>der verheerende\u00a0<a href=\"https:\/\/cloud.google.com\/blog\/topics\/threat-intelligence\/evasive-attacker-leverages-solarwinds-supply-chain-compromises-with-sunburst-backdoor\/\" target=\"_blank\" rel=\"noreferrer noopener\">Angriff auf SolarWinds<\/a>, dem fast 18.000 Unternehmen zum Opfer fielen.<\/li>\n\n\n\n<li>die\u00a0<a href=\"https:\/\/www.infosecurity-magazine.com\/news\/3cx-hackers-compromised-critical\/\" target=\"_blank\" rel=\"noreferrer noopener\">Kompromittierung der Finanzsoftware X_TRADER<\/a>\u00a0f\u00fchrte zu Angriffen auf Kommunikations-, Finanz- und kritische Infrastrukturunternehmen.<\/li>\n\n\n\n<li>die\u00a0<a href=\"https:\/\/www.zdnet.com\/article\/updated-kaseya-ransomware-attack-faq-what-we-know-now\/\" target=\"_blank\" rel=\"noreferrer noopener\">Kompromittierung von Kaseya<\/a>, bei der Angreifer die Verwaltungssoftware des Unternehmens kompromittierten, um Ransomware-Angriffe auf etwa 1.500 Kunden des Unternehmens durchzuf\u00fchren.<\/li>\n<\/ul>\n\n\n\n<p><a href=\"https:\/\/www.welivesecurity.com\/en\/business-security\/assessing-mitigating-cybersecurity-risks-supply-chain\/\" target=\"_blank\" rel=\"noreferrer noopener\">Supply-Chain-Attacken<\/a>\u00a0gibt es in vielen Formen. Sie k\u00f6nnen vom Diebstahl der Anmeldedaten eines Dienstleisters (wie 2013 beim\u00a0<a href=\"https:\/\/krebsonsecurity.com\/2014\/02\/target-hackers-broke-in-via-hvac-company\/\" target=\"_blank\" rel=\"noreferrer noopener\">Target-Datendiebstahl \u00fcber dessen HVAC-Vertragspartner<\/a>) bis hin zur Ausnutzung von Schwachstellen in Open-Source-Code reichen, der in der Software vieler Anbieter (wie\u00a0<a href=\"https:\/\/security.googleblog.com\/2021\/12\/understanding-impact-of-apache-log4j.html\" target=\"_blank\" rel=\"noreferrer noopener\">log4j<\/a>) verwendet wird.<\/p>\n\n\n\n<p>Lesen Sie weiter, um mehr \u00fcber Angriffe zu erfahren, die w\u00e4hrend der Softwareentwicklung und -distribution auftreten. Bei diesen Attacken wird b\u00f6sartiger Code in vertrauensw\u00fcrdiger Software ausgef\u00fchrt, der sie zu einer potenziellen Waffe macht, um Schaden anzurichten.<\/p>\n\n\n\n<p>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\u00f6swilligen Absichten haben und ihre Sicherheitspraktiken gewissenhaft anwenden.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"how-attackers-exploit-ci-cd-pipelines-for-supply-chain-attacks\">Wie Angreifer CI\/CD-Pipelines f\u00fcr Supply-Chain-Attacken ausnutzen<\/h2>\n\n\n\n<p>Sehen wir uns einmal an, wie die Angreifer die oben aufgef\u00fchrten hochkar\u00e4tigen Attacken durchgef\u00fchrt und ihre Ziele erreicht haben. In all diesen F\u00e4llen hat der Angreifer eine Phase der Softwareerstellung oder des Softwareverteilungsprozesses gekapert, um b\u00f6sartigen Code einzuschleusen. Lassen Sie uns einen genaueren Blick auf die Methoden werfen, die Angreifer verwendet haben, um in diese Systeme einzudringen:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><a href=\"https:\/\/venafi.com\/blog\/solarwinds-sunburst-attack-explained-what-really-happened\/\" target=\"_blank\" rel=\"noreferrer noopener\">SolarWinds<\/a>: \u201e[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 \u00fcber deren Website zur Verf\u00fcgung gestellt.\u201c<\/li>\n\n\n\n<li><a href=\"https:\/\/cloud.google.com\/blog\/topics\/threat-intelligence\/3cx-software-supply-chain-compromise\" target=\"_blank\" rel=\"noreferrer noopener\">3CX<\/a>: (Die durch den X_TRADER-Angriff erm\u00f6glichte Supply-Chain-Attacke): \u201eSchlie\u00dflich 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 \u00fcber 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.\u201c<\/li>\n\n\n\n<li><a href=\"https:\/\/news.sophos.com\/en-us\/2021\/07\/04\/independence-day-revil-uses-supply-chain-exploit-to-attack-hundreds-of-businesses\/\" target=\"_blank\" rel=\"noreferrer noopener\">Kaseya<\/a>: \u201eUnter Ausnutzung des VSA-Remote-Management-Dienstes von Kaseya brachten die REvil-Akteure ein b\u00f6sartiges 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.\u201c<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"the-sumo-logic-azure-devops-and-github-rules\">Die Sumo Logic Azure DevOps- und GitHub-Regeln<\/h2>\n\n\n\n<p>Das Team von Sumo Logic Threat Labs hat zwei Regels\u00e4tze innerhalb des\u00a0<a href=\"https:\/\/www.sumologic.com\/de\/cloud-siem\">Sumo Logic Cloud-SIEM<\/a>\u00a0ver\u00f6ffentlicht, um die \u00dcberwachung und Erkennung von Angreiferaktivit\u00e4ten in Ihrer CI\/CD-Umgebung zu unterst\u00fctzen:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><a href=\"https:\/\/help.sumologic.com\/release-notes-cse\/2024\/12\/31\/#rules-1\" target=\"_blank\" rel=\"noreferrer noopener\">GitHub-Regeln<\/a>: Eine Reihe von Regeln, die verd\u00e4chtige Aktivit\u00e4ten auf GitHub erkennen sollen, ver\u00f6ffentlicht am 6. Dezember 2024.<\/li>\n\n\n\n<li><a href=\"https:\/\/help.sumologic.com\/release-notes-cse\/2025\/03\/13\/content\/\" target=\"_blank\" rel=\"noreferrer noopener\">Azure DevOps-Regeln<\/a>: Eine Reihe von Regeln, die auf\u00a0<a href=\"https:\/\/github.com\/Azure\/Azure-Sentinel\/tree\/master\/Solutions\/AzureDevOpsAuditing\/Analytic%20Rules\" target=\"_blank\" rel=\"noreferrer noopener\">Sentinel-Regeln von Microsoft f\u00fcr Azure DevOps<\/a>, zusammen mit der Tuning-Anleitung von IBMs X-Force Red in ihrem hervorragenden Papier \u201e<a href=\"https:\/\/www.ibm.com\/downloads\/documents\/us-en\/10a99803d42fd1e5\" target=\"_blank\" rel=\"noreferrer noopener\"><em>Hiding in the Clouds: Abusing Azure DevOps Services to Bypass Microsoft Sentinel Analytic Rules<\/em><em><\/em><\/a><em>\u201c basieren.\u00a0<\/em>Diese Regeln wurden am 13. M\u00e4rz 2025 ver\u00f6ffentlicht.<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"how-to-get-started-with-sumo-logic-s-azure-devops-and-github-rules\">Wie Sie mit den Azure DevOps- und GitHub-Regeln von Sumo Logic loslegen<\/h2>\n\n\n\n<p>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\u00fchrung der Protokollerfassung.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"azure-devops-log-collection\">Azure DevOps-Protokollerfassung<\/h3>\n\n\n\n<p>Um Azure DevOps-Protokolle zu erfassen:<\/p>\n\n\n\n<ol class=\"wp-block-list\">\n<li>Aktivieren Sie Auditing in Ihrer Azure DevOps-Organisation.<\/li>\n\n\n\n<li>Konfigurieren Sie die Audit-Protokolle so, dass sie an einen Azure Event Hub gestreamt werden.<\/li>\n\n\n\n<li>Erfassen Sie die Protokolle vom Event Hub mit einem\u00a0<a href=\"https:\/\/help.sumologic.com\/docs\/send-data\/hosted-collectors\/\" target=\"_blank\" rel=\"noreferrer noopener\">Sumo Logic Hosted Collector<\/a>.<\/li>\n<\/ol>\n\n\n\n<p>Detaillierte Anweisungen finden Sie in der\u00a0<a href=\"https:\/\/learn.microsoft.com\/en-us\/azure\/devops\/organizations\/audit\/azure-devops-auditing?view=azure-devops&amp;tabs=preview-page\" target=\"_blank\" rel=\"noreferrer noopener\">Dokumentation von Microsoft zur Aktivierung von Auditing<\/a>\u00a0in Ihrer Azure DevOps-Organisation und zur Konfiguration der Audit-Protokolle f\u00fcr den Stream zu einem\u00a0<a href=\"https:\/\/learn.microsoft.com\/en-us\/azure\/devops\/organizations\/audit\/auditing-streaming?view=azure-devops\" target=\"_blank\" rel=\"noreferrer noopener\">Azure Event Hub<\/a>. Siehe auch\u00a0<a href=\"https:\/\/help.sumologic.com\/docs\/send-data\/hosted-collectors\/cloud-to-cloud-integration-framework\/azure-event-hubs-source\/\" target=\"_blank\" rel=\"noreferrer noopener\">das Sumo Logic-Hilfethema \u201eAzure Event Hubs Source\u201c<\/a>\u00a0f\u00fcr weitere Details zum Erfassen von Protokollen von Azure Event Hubs. Stellen Sie sicher, dass \u201eForward to Cloud-SIEM\u201c in der von Ihnen erstellten Protokollquelle aktiviert ist.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"github-log-collection\">GitHub-Protokollerfassung<\/h3>\n\n\n\n<p><strong>Hinweis: Die GitHub-Regeln wurden speziell f\u00fcr GitHub Enterprise Audit Logs entwickelt.<\/strong><\/p>\n\n\n\n<p>Zum Erfassen von GitHub-Protokollen:<\/p>\n\n\n\n<ol class=\"wp-block-list\">\n<li>Streamen Sie GitHub-Protokolle in einen AWS S3-Bucket.<\/li>\n\n\n\n<li>Erfassen Sie die GitHub-Protokolle von S3 \u00fcber einen Sumo Logic Hosted Collector.<\/li>\n<\/ol>\n\n\n\n<p>F\u00fcr die Einrichtung folgen Sie dem GitHub-Thema\u00a0<a href=\"https:\/\/docs.github.com\/en\/enterprise-cloud@latest\/admin\/monitoring-activity-in-your-enterprise\/reviewing-audit-logs-for-your-enterprise\/streaming-the-audit-log-for-your-enterprise#setting-up-streaming-to-amazon-s3\" target=\"_blank\" rel=\"noreferrer noopener\">\u201eSetting Up Streaming to Amazon S3\u201c<\/a>\u00a0zur Konfiguration des Protokoll-Streamings zu S3. Verwenden Sie dann\u00a0<a href=\"https:\/\/help.sumologic.com\/docs\/send-data\/hosted-collectors\/amazon-aws\/aws-s3-source\/\" target=\"_blank\" rel=\"noreferrer noopener\">das Sumo Logic-Hilfethema \u201eAmazon S3 Source\u201c<\/a>, um die Protokollerfassung vom S3-Bucket zu konfigurieren. F\u00fcgen Sie beim Einrichten der Protokollquelle unbedingt die folgenden Felder hinzu:<\/p>\n\n\n\n<figure class=\"wp-block-table\"><table class=\"has-fixed-layout\"><tbody><tr><td><strong>Feldname<\/strong><\/td><td><strong>Feldwert<\/strong><\/td><\/tr><tr><td>_siemForward<\/td><td>true<\/td><\/tr><tr><td>_parser<\/td><td>\/Parser\/System\/Github\/GitHub Enterprise Audit<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n<figure class=\"wp-block-image size-full\"><img loading=\"lazy\" decoding=\"async\" width=\"1156\" height=\"1278\" src=\"https:\/\/www.sumologic.com\/wp-content\/uploads\/blog-DetectingAzure-image7.jpg\" alt=\"\" class=\"wp-image-14228\" title=\"\"><\/figure>\n\n\n\n<p><em>Konfigurationsbeispiel \u2013 GitHub-Protokollerfassung \u00fcber Amazon S3-Protokollquelle<\/em><\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"attacker-techniques-that-sumo-logic-s-cloud-siem-rules-detect\">Angriffstechniken, die von den Sumo Logic Cloud-SIEM-Regeln erkannt werden<\/h2>\n\n\n\n<p>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.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"technique-pull-request-review-bypass\">Technique: Pull Request Review Bypass<\/h3>\n\n\n\n<p>Erkennungsregeln:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Azure DevOps \u2013 First seen pull request policy bypassed<\/li>\n\n\n\n<li>GitHub \u2013 Pull request review requirement removed<\/li>\n<\/ul>\n\n\n\n<p>CI\/CD-Pipelines sind auf Tempo ausgelegt und erm\u00f6glichen es Entwicklern, Code-Updates mehrmals t\u00e4glich in die Produktion zu \u00fcbertragen. Obwohl dieser schnelle Ver\u00f6ffentlichungsrhythmus f\u00fcr ein Unternehmen und seine Kunden von Vorteil ist, erh\u00f6ht er das Risiko, dass ein Entwickler einseitig fehlerhaften oder b\u00f6sartigen Code in die Produktion einbringt.<\/p>\n\n\n\n<p>Eine M\u00f6glichkeit, dieses Risiko zu mindern, ist ein Peer Review, ein Prozess, bei dem Pull-Anfragen genehmigt werden m\u00fcssen, bevor sie in die Build\/Release-Pipeline gelangen.<\/p>\n\n\n\n<p>Laut der\u00a0<a href=\"https:\/\/owasp.org\/www-project-top-10-ci-cd-security-risks\/\" target=\"_blank\" rel=\"noreferrer noopener\">OWASP Top 10 CI\/CD-Sicherheitsrisiken<\/a> ist die Umgehung des Review-Prozesses das gr\u00f6\u00dfte Risiko bei CI\/CD. Ein reales Beispiel f\u00fcr dieses Risiko trat im M\u00e4rz 2021 auf, als\u00a0<a href=\"https:\/\/news-web.php.net\/php.internals\/113981\" target=\"_blank\" rel=\"noreferrer noopener\">nicht genehmigte \u00c4nderungen<\/a>\u00a0an der PHP-Codebasis vorgenommen wurden.<\/p>\n\n\n\n<p>Die Umgehung der \u00dcberpr\u00fcfung kann gerechtfertigt sein, und Azure DevOps bietet die M\u00f6glichkeit, die Richtlinien f\u00fcr Pull-Requests \u00fcber die\u00a0<a href=\"https:\/\/learn.microsoft.com\/en-us\/azure\/devops\/repos\/git\/branch-policies?view=azure-devops&amp;tabs=browser#bypass-branch-policies\" target=\"_blank\" rel=\"noreferrer noopener\">Einstellung \u201ebypass policy\u201c<\/a> zu umgehen. Ihr Unternehmen kann triftige Gr\u00fcnde haben, die Pull-Request-Richtlinien zu umgehen, wenn auch nur vor\u00fcbergehend. Wenn eine Umgehungsrichtlinie erlaubt ist, sollten Sie auf m\u00f6glichen Missbrauch achten.<\/p>\n\n\n\n<figure class=\"wp-block-image size-full\"><img loading=\"lazy\" decoding=\"async\" width=\"1918\" height=\"368\" src=\"https:\/\/www.sumologic.com\/wp-content\/uploads\/blog-DetectingAzure-image4.jpg\" alt=\"\" class=\"wp-image-14229\" title=\"\"><\/figure>\n\n\n\n<p><\/p>\n\n\n\n<p>Die Azure DevOps-Regel \u201eFirst seen pull request policy bypassed\u201c 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\u00f6st wird, sollte der SOC-Analyst feststellen, ob die Umgehung der Pull-Request erwartet wurde, und den Benutzer, der die Umgehung der Pull-Request durchgef\u00fchrt hat, auf Anzeichen einer Kontokompromittierung oder anderer Insider-Bedrohungsaktivit\u00e4ten untersuchen.<\/p>\n\n\n\n<figure class=\"wp-block-image size-full\"><img loading=\"lazy\" decoding=\"async\" width=\"886\" height=\"1142\" src=\"https:\/\/www.sumologic.com\/wp-content\/uploads\/blog-DetectingAzure-image6.jpg\" alt=\"\" class=\"wp-image-14230\" title=\"\"><\/figure>\n\n\n\n<figure class=\"wp-block-image size-full\"><img loading=\"lazy\" decoding=\"async\" width=\"1388\" height=\"840\" src=\"https:\/\/www.sumologic.com\/wp-content\/uploads\/blog-DetectingAzure-image15.jpg\" alt=\"\" class=\"wp-image-14231\" title=\"\"><\/figure>\n\n\n\n<p><em>Regel \u201eFirst seen pull request policy bypassed\u201c und Log-Auszug<\/em><\/p>\n\n\n\n<p>Die GitHub-Regel \u201ePR review requirement removed\u201c \u00fcberwacht ebenfalls die Umgehung der Pull Request Reviews, aber sie tut dies, indem sie die \u00dcberpr\u00fcfungsanforderung vollst\u00e4ndig aus dem Repository entfernt.<\/p>\n\n\n\n<figure class=\"wp-block-image size-full\"><img loading=\"lazy\" decoding=\"async\" width=\"1902\" height=\"630\" src=\"https:\/\/www.sumologic.com\/wp-content\/uploads\/blog-DetectingAzure-image10-1.jpg\" alt=\"\" class=\"wp-image-14233\" title=\"\"><\/figure>\n\n\n\n<figure class=\"wp-block-image size-full\"><img loading=\"lazy\" decoding=\"async\" width=\"950\" height=\"708\" src=\"https:\/\/www.sumologic.com\/wp-content\/uploads\/blog-DetectingAzure-image14.jpg\" alt=\"\" class=\"wp-image-14234\" title=\"\"><\/figure>\n\n\n\n<p><em>Regel \u201ePR review requirement removed\u201c und Log-Auszug<\/em><\/p>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"technique-membership-changes-to-privileged-groups\">Technik: Mitgliedschafts\u00e4nderungen in privilegierten Gruppen<\/h3>\n\n\n\n<p>Erkennungsregeln:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Azure DevOps \u2013 Change made to the administrator group<\/li>\n\n\n\n<li>GitHub \u2013 Administrator added or invited<\/li>\n<\/ul>\n\n\n\n<p>Im Mai 2019 wurde das\u00a0<a href=\"https:\/\/stackoverflow.blog\/2021\/01\/25\/a-deeper-dive-into-our-may-2019-security-incident\/\" target=\"_blank\" rel=\"noreferrer noopener\">Stack Overflow-Netzwerk von einem Angreifer<\/a>\u00a0kompromittiert, der sich \u201eZugang zur Moderatoren- und Entwicklerebene auf allen Seiten des Stack Exchange-Netzwerks verschafft hat.\u201c Der Angreifer hat durch diesen Angriff Quellcode und personenbezogene Daten von 184 Stack Overflow-Benutzern exfiltriert.<\/p>\n\n\n\n<p>Jedes Ereignis, bei dem ein Benutzer administrative Privilegien erh\u00e4lt, ist angesichts der Auswirkungen, die der Benutzer haben kann, bemerkenswert. OWASP stuft eine unzureichende Identit\u00e4ts- und Zugriffsverwaltung als das zweitgr\u00f6\u00dfte Risiko f\u00fcr CI\/CD-Pipelines ein. Dieses Risiko deckt eine Vielzahl von M\u00f6glichkeiten ab, wie ein falsches Identit\u00e4tsmanagement die CI\/CD-Pipeline kompromittieren kann, einschlie\u00dflich der Nichteinhaltung Least-Privilige-Prinzips.<\/p>\n\n\n\n<p>Die Azure DevOps-Regel \u201eChanges made to administrator group\u201c benachrichtigt SOC-Analysten, wenn ein Benutzer zu mehreren privilegierten Gruppen in Azure DevOps hinzugef\u00fcgt wird, z. B. Projekt-Administratoren, Project-Collection-Administratoren, Project-Collection-Service-Accounts, Build-Administratoren und Project-Collection-Build-Administratoren.<\/p>\n\n\n\n<p>Wenn diese Regel ausgel\u00f6st wird, sollte der SOC-Analyst feststellen, ob es sich bei der Gruppen\u00e4nderung um eine genehmigte \u00c4nderung handelt, z. B. indem er nach einem entsprechenden \u00c4nderungskontrollticket sucht, wenn CI\/CD in den Bereich der \u00c4nderungskontrolle f\u00e4llt, und den Benutzer, der die \u00c4nderung vorgenommen hat, auf Anzeichen einer Kontokompromittierung untersuchen.<\/p>\n\n\n\n<figure class=\"wp-block-image size-full\"><img loading=\"lazy\" decoding=\"async\" width=\"1924\" height=\"540\" src=\"https:\/\/www.sumologic.com\/wp-content\/uploads\/blog-DetectingAzure-image5.jpg\" alt=\"\" class=\"wp-image-14235\" title=\"\"><\/figure>\n\n\n\n<figure class=\"wp-block-image size-full\"><img loading=\"lazy\" decoding=\"async\" width=\"1532\" height=\"938\" src=\"https:\/\/www.sumologic.com\/wp-content\/uploads\/blog-DetectingAzure-image2.jpg\" alt=\"\" class=\"wp-image-14236\" title=\"\"><\/figure>\n\n\n\n<p><em>Regel \u201eChange made to administrator group\u201c und Log-Auszug<\/em><\/p>\n\n\n\n<p>\u00c4hnlich wie der Name schon sagt, erkennt die GitHub-Regel \u201eAdministrator added or invited\u201c, wenn ein neuer Administrator hinzugef\u00fcgt oder eingeladen wird.<\/p>\n\n\n\n<figure class=\"wp-block-image size-full\"><img loading=\"lazy\" decoding=\"async\" width=\"1122\" height=\"500\" src=\"https:\/\/www.sumologic.com\/wp-content\/uploads\/blog-DetectingAzure-image8.png\" alt=\"\" class=\"wp-image-14237\" title=\"\"><\/figure>\n\n\n\n<figure class=\"wp-block-image size-full\"><img loading=\"lazy\" decoding=\"async\" width=\"666\" height=\"500\" src=\"https:\/\/www.sumologic.com\/wp-content\/uploads\/blog-DetectingAzure-image13.jpg\" alt=\"\" class=\"wp-image-14238\" title=\"\"><\/figure>\n\n\n\n<p><em>Regel \u201eAdministrator added or invited\u201c und Log-Auszug<\/em><\/p>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"technique-malicious-tool-integration\">Technik: Integration b\u00f6sartiger Tools<\/h3>\n\n\n\n<p>Erkennungsregeln:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Azure DevOps \u2013 First seen \u2013 New extension installed<\/li>\n\n\n\n<li>GitHub \u2013 First seen application interacting with API<\/li>\n<\/ul>\n\n\n\n<p>Es gibt ein reichhaltiges \u00d6kosystem von Tools, die in Ihre CI\/CD-Umgebung integriert werden k\u00f6nnen, um Funktionen wie Codepr\u00fcfung, Ressourcenmanagement und Secrets Substitution hinzuzuf\u00fcgen. Leider sind diese Tools und Dienste auch ein Angriffsvektor.<\/p>\n\n\n\n<p>Im Juli 2020 wurden die Zugangsdaten f\u00fcr die DeepSource GitHub-Anwendung, die Funktionen wie statische Analyse, SAST, Code Coverage und IaC-Analyse bietet, kompromittiert und dazu verwendet, die\u00a0<a href=\"https:\/\/discuss.deepsource.com\/t\/security-incident-on-deepsource-s-github-application\/131\" target=\"_blank\" rel=\"noreferrer noopener\">Zugangsdaten<\/a>\u00a0der Benutzer der Anwendung zu kompromittieren.<\/p>\n\n\n\n<p>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\u00f6sartiger Code von der Erweiterung selbst oder von Angreifern eingeschleust wird, die \u00fcber die Erweiterung in Ihrer DevOps-Umgebung Fu\u00df fassen. OWASP stuft dieses Risiko, das in die Kategorie \u201eunkontrollierte Nutzung von Diensten Dritter\u201c f\u00e4llt, als das achth\u00e4ufigste Risiko ein.<\/p>\n\n\n\n<p>Die Azure DevOps-Regel \u201eNew extension installed\u201c wird ausgel\u00f6st, wenn eine neue Erweiterung (gegen\u00fcber einer 90-Tage-Baseline) in der Azure DevOps-Organisation installiert wurde. Wenn diese Regel ausgel\u00f6st wird, sollte der SOC-Analyst untersuchen, ob es sich um eine bekannte \u00c4nderung handelt (z. B. \u00fcber \u00c4nderungskontrolltickets) und ob die Erweiterung f\u00fcr die Verwendung im Unternehmen zugelassen ist.<\/p>\n\n\n\n<figure class=\"wp-block-image size-full\"><img loading=\"lazy\" decoding=\"async\" width=\"930\" height=\"1210\" src=\"https:\/\/www.sumologic.com\/wp-content\/uploads\/blog-DetectingAzure-image9.jpg\" alt=\"\" class=\"wp-image-14241\" title=\"\"><\/figure>\n\n\n\n<figure class=\"wp-block-image size-full\"><img loading=\"lazy\" decoding=\"async\" width=\"1532\" height=\"908\" src=\"https:\/\/www.sumologic.com\/wp-content\/uploads\/blog-DetectingAzure-image1.jpg\" alt=\"\" class=\"wp-image-14242\" title=\"\"><\/figure>\n\n\n\n<p><em>Regel \u201eNew extension seen rule\u201c und Log-Auszug<\/em><\/p>\n\n\n\n<p>Die GitHub-Regel \u201eFirst seen application interacting with API\u201c \u00fcberwacht Anwendungen, die die GitHub-API verwenden und in den letzten 90 Tagen nicht dabei beobachtet wurden. Diese Erkennung ist umfassender als die Erkennung \u201eNew extension seen\u201c, da sie alle unbekannten Anwendungen ausl\u00f6st, die mit der API interagieren, nicht nur Erweiterungen.<\/p>\n\n\n\n<figure class=\"wp-block-image size-full\"><img loading=\"lazy\" decoding=\"async\" width=\"962\" height=\"920\" src=\"https:\/\/www.sumologic.com\/wp-content\/uploads\/blog-DetectingAzure-image3.jpg\" alt=\"\" class=\"wp-image-14243\" title=\"\"><\/figure>\n\n\n\n<figure class=\"wp-block-image size-full\"><img loading=\"lazy\" decoding=\"async\" width=\"882\" height=\"990\" src=\"https:\/\/www.sumologic.com\/wp-content\/uploads\/blog-DetectingAzure-image11.jpg\" alt=\"\" class=\"wp-image-14251\" title=\"\"><\/figure>\n\n\n\n<p><em>Regel \u201eFirst seen application interacting with API\u201c und Log-Auszug<\/em><\/p>\n\n\n\n<p>Die Protokollierung Ihrer CI\/CD-Umgebung ist entscheidend f\u00fcr die \u00dcberwachung ihrer Sicherheit. OWASP stimmt zu, stuft\u00a0<a href=\"https:\/\/owasp.org\/www-project-top-10-ci-cd-security-risks\/CICD-SEC-10-Insufficient-Logging-And-Visibility\" target=\"_blank\" rel=\"noreferrer noopener\">\u201eUnzureichende Protokollierung und Sichtbarkeit\u201c als Risiko Nr. 10<\/a> ein und f\u00fchrt an, dass \u201eunzureichende Protokollierung und Sichtbarkeit es einem Angreifer erm\u00f6glichen, b\u00f6sartige Aktivit\u00e4ten innerhalb der CI\/CD-Umgebung durchzuf\u00fchren, ohne in irgendeiner Phase der Attack-Kill-Chain entdeckt zu werden, einschlie\u00dflich der Identifizierung der Techniken, Taktiken und Verfahren (Techniques, Tactics and Procedures, TTPs) des Angreifers als Teil einer Untersuchung nach einem Vorfall.\u201c<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"secure-your-ci-cd-environment-with-sumo-logic\">Sichern Sie Ihre CI\/CD-Umgebung mit Sumo Logic<\/h2>\n\n\n\n<p>Supply-Chain-Attacken stellen eine wachsende Bedrohung dar, und Ihre CI\/CD-Umgebung ist ein bevorzugtes Ziel. Durch die proaktive \u00dcberwachung Ihres CI\/CD-\u00d6kosystems mit den Sumo Logic Cloud-SIEM-Regeln k\u00f6nnen Sie verd\u00e4chtige Aktivit\u00e4ten erkennen und darauf reagieren, bevor sie zu einer vollst\u00e4ndigen Sicherheitsverletzung f\u00fchren.<\/p>\n\n\n\n<p>Um mehr \u00fcber Sumo Logic Cloud-SIEM zu erfahren, schauen Sie sich das\u00a0<a href=\"https:\/\/www.sumologic.com\/de\/cloud-siem\">Produkt<\/a>\u00a0an oder klicken Sie sich durch eine\u00a0<a href=\"\/demo\/experiencing-the-insight-radar\">interaktive Demo<\/a>.<\/p>\n<\/div>\n<\/div>\n<\/div>\n<\/div><\/section>\n","protected":false},"excerpt":{"rendered":"","protected":false},"author":332,"featured_media":45467,"template":"","meta":{"_acf_changed":false,"show_custom_date":false,"custom_date":"","featured":false,"featured_image":0,"learn_more_label":"","image_alt_text":"","learn_more_type":"","show_popup":false,"learn_more_link_file":0,"event_date":false,"event_start_date":"","event_end_date":"","place_holder_image_url":"","post_reading_time":"7","notification_enabled":false,"notification_text":"","notification_logo":"","notification_expiration_time":0,"is_enable_transparent_header":false,"selected_taxonomy_terms":{"blog-category":[255,257],"blog-tag":[],"translation_priority":[]},"selected_primary_terms":[],"learn_more_link":[],"featured_page_list":[],"notification_enabled_post_list":[],"_gspb_post_css":"","_relevanssi_hide_post":"","_relevanssi_hide_content":"","_relevanssi_pin_for_all":"","_relevanssi_pin_keywords":"","_relevanssi_unpin_keywords":"","_relevanssi_related_keywords":"","_relevanssi_related_include_ids":"","_relevanssi_related_exclude_ids":"","_relevanssi_related_no_append":"","_relevanssi_related_not_related":"","_relevanssi_related_posts":"52702,62709,62726","_relevanssi_noindex_reason":"","inline_featured_image":false,"footnotes":""},"blog-category":[255,257],"blog-tag":[],"class_list":["post-52742","blog","type-blog","status-publish","has-post-thumbnail","hentry","blog-category-cloud-siem","blog-category-secops-security"],"acf":[],"_links":{"self":[{"href":"https:\/\/www.sumologic.com\/de\/wp-json\/wp\/v2\/blog\/52742","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.sumologic.com\/de\/wp-json\/wp\/v2\/blog"}],"about":[{"href":"https:\/\/www.sumologic.com\/de\/wp-json\/wp\/v2\/types\/blog"}],"author":[{"embeddable":true,"href":"https:\/\/www.sumologic.com\/de\/wp-json\/wp\/v2\/users\/332"}],"version-history":[{"count":3,"href":"https:\/\/www.sumologic.com\/de\/wp-json\/wp\/v2\/blog\/52742\/revisions"}],"predecessor-version":[{"id":53729,"href":"https:\/\/www.sumologic.com\/de\/wp-json\/wp\/v2\/blog\/52742\/revisions\/53729"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.sumologic.com\/de\/wp-json\/wp\/v2\/media\/45467"}],"wp:attachment":[{"href":"https:\/\/www.sumologic.com\/de\/wp-json\/wp\/v2\/media?parent=52742"}],"wp:term":[{"taxonomy":"blog-category","embeddable":true,"href":"https:\/\/www.sumologic.com\/de\/wp-json\/wp\/v2\/blog-category?post=52742"},{"taxonomy":"blog-tag","embeddable":true,"href":"https:\/\/www.sumologic.com\/de\/wp-json\/wp\/v2\/blog-tag?post=52742"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}