Was ist eine unsichere Systemkonfiguration?
Eine unsichere Systemkonfiguration ist ein OWASP Top 10 CI/CD-Sicherheitsrisiko. Es entsteht, wenn CI/CD-Systeme mit suboptimalen oder Standardkonfigurationen bereitgestellt werden. Dazu können unnötig offene Ports, Standard-Anmeldeinformationen, ungepatchte Systeme, schlecht getrennte Netzwerke oder deaktivierte Sicherheitsfunktionen gehören. Diese Schwachstellen können dazu führen, dass Unbefugte auf das System zugreifen und die Verbreitung von Malware und die Möglichkeit der Einspeisung von bösartigem Code in den Bereitstellungsprozess erhöhen, was letztlich zu Datenschutzverletzungen und Störungen des Geschäftsbetriebs führt. Unsichere Konfigurationen können auch zum Missbrauch legitimer CI/CD-Prozesse führen und es Angreifern ermöglichen, Workflows zu manipulieren und sich Zugang zu Produktionsumgebungen zu verschaffen.
CICD-SEC-7: Unsichere Systemkonfiguration erklärt
Eine unsichere Systemkonfiguration stellt ein erhebliches Sicherheitsrisiko dar. Es entsteht durch Mängel in den Sicherheitseinstellungen, der Konfiguration und der Absicherung verschiedener Systeme in der gesamten Pipeline, wie z.B. Source Code Management (SCM), CI-Systeme und Artefakt-Repositories. Diese Schwachstellen sind oft ein leichtes Ziel für Angreifer, die versuchen, ihre Reichweite innerhalb der Umgebung zu vergrößern.
CI/CD-Umgebungen bestehen aus mehreren Systemen verschiedener Anbieter. Um die CI/CD-Sicherheitzu verbessern, ist es unerlässlich, sich nicht nur auf den Code und die Artefakte zu konzentrieren, die durch die Pipeline fließen, sondern auch auf die Standfestigkeit und Ausfallsicherheit jedes einzelnen Systems.
Ähnlich wie bei Systemen zur Datenspeicherung und -verarbeitung sind auch bei CI/CD-Systemen zahlreiche Sicherheitseinstellungen und Konfigurationen auf Anwendungs-, Netzwerk- und Infrastrukturebene erforderlich. Diese Einstellungen spielen eine wichtige Rolle bei der Bestimmung der Sicherheitslage der CI/CD-Umgebungen und ihrer Anfälligkeit für mögliche Verstöße.
Angreifer sind auf der Suche nach CI/CD-Schwachstellen und Fehlkonfigurationen, die sie ausnutzen können. Mögliche Härtungsfehler sind:
- Systeme mit veralteten Versionen
- Systeme mit allzu freizügigen Netzwerk-Zugriffskontrollen
- Selbst gehostete Systeme mit administrativen Rechten für das zugrunde liegende Betriebssystem
- Schlechte Hygiene bei den Anmeldeinformationen
Systemkonfiguration definiert
Die Systemkonfiguration bezieht sich auf den Prozess der Einrichtung von Systemen und Diensten, die Definition ihrer Interaktion und die Festlegung der Regeln für ihren Betrieb. Dazu gehören die Einrichtung von Hardware, die Installation und Konfiguration von Software und die Herstellung von Netzwerkverbindungen. Da sich der Konfigurationsprozess erheblich auf die Funktionalität, Leistung und Sicherheit eines Systems auswirken kann, ist es von entscheidender Bedeutung, ihn richtig zu machen - und seinen optimalen Status zu erhalten.
Komponenten einer sicheren Systemkonfiguration
Eine sichere Konfiguration umfasst die korrekte Einstellung von Systemparametern, die Verwaltung von Zugriffskontrollen und die Implementierung von Sicherheitsmaßnahmen für die Systeme, die der CI/CD-Pipelinezugrunde liegen. Solche Konfigurationen vermindern das Risiko eines unbefugten Zugriffs und verhindern die Ausnutzung von Schwachstellen in den Systemen, die das Rückgrat der Entwicklungsumgebung bilden.
Die Komplexität in der CI/CD-Umgebung ergibt sich aus der CI/CD-Umgebung, da die Systemkonfiguration über die einzelnen Systeme hinausgeht und die Verbindungen zwischen den in der Pipeline verwendeten Tools, Diensten und Plattformen umfasst. Es überrascht nicht, dass die wichtigste Komponente einer effektiven und sicheren Systemkonfiguration eine strikte Konfigurationsverwaltung ist.
Wie CICD-SEC-7 abläuft
Die Ursache für unsichere Systemkonfigurationen liegt häufig in menschlichem Versagen, dem Fehlen geeigneter Verfahren oder einem unzureichenden Verständnis der Sicherheitsanforderungen. Die Ursache kann so einfach sein wie das Belassen von Standardeinstellungen, das Zulassen übermäßiger Berechtigungen oder das Vernachlässigen von System-Updates und -Patches.
Eine hypothetische Situation
Der Angreifer scannt das Netzwerk des Ziels, ein auf künstliche Intelligenz spezialisiertes Technologieunternehmen, und entdeckt einen ungeschützten Jenkins-Server, der mit Standardeinstellungen konfiguriert ist. Mithilfe leicht verfügbarer Tools und eines API-Aufrufs durchsuchen sie die Metadaten des Jenkins-Servers nach potenziellen Informationen über das zugrunde liegende System. Eine Goldgrube von Informationen überflutet ihren Bildschirm - Daten über Plugins, Aufträge, Systemkonfigurationen und mehr. Aus dieser Fülle von Details sticht eine Information besonders hervor. AWS-Schlüssel. Sie wurden von Jenkins für die Bereitstellung von Anwendungen auf AWS verwendet und waren nicht ausreichend gesichert. Die Schlüssel sind für ein Administratorkonto, das potenziell uneingeschränkten Zugriff auf die AWS-Umgebung des Unternehmens gewährt.
Mit Hilfe der Schlüssel dringt der Angreifer in die AWS-Infrastruktur des Unternehmens ein und gelangt so in das Herz des Systems der Organisation. Sie finden einen S3-Bucket, der proprietäre KI-Modelle enthält, und mit dem Admin-Zugang über die gestohlenen AWS-Schlüssel laden sie die Modelle schnell herunter und verschwinden, ohne einen Alarm auszulösen.
Der Angreifer beschließt dann, dieses System weiter auszunutzen. Da sie wissen, dass der Jenkins-Server über Schreibrechte für die GitHub-Repositories verfügt, fügen sie einen bösartigen Codeschnipsel in den Quellcode der Hauptanwendung ein, der eine Hintertür in die Anwendung öffnet. Im nächsten Bereitstellungszyklus schiebt das Unternehmen die Anwendung unwissentlich in die Produktion. Mit einer hartnäckigen Hintertür bewaffnet, kann der Angreifer nun Daten stehlen, die Systemsteuerung manipulieren und zusätzliche Malware einschleusen - alles unter dem Radar der Sicherheitssysteme des Unternehmens.
Die Bedeutung einer sicheren Systemkonfiguration in CI/CD
Eine Fehlkonfiguration an einem beliebigen Punkt der technischen Umgebung kann die gesamte Pipeline potenziellen Bedrohungen aussetzen. Ein Angreifer, der die Fehlkonfiguration ausnutzt, könnte sich unbefugten Zugriff auf das CI/CD-System verschaffen - oder schlimmer noch, das System kompromittieren und auf das zugrunde liegende Betriebssystem zugreifen. Der Angreifer könnte legitime CI/CD-Abläufe manipulieren, sensible Token erlangen und potenziell auf Produktionsumgebungen zugreifen. In einigen Szenarien können Konfigurationsfehler es einem Angreifer ermöglichen, sich seitlich innerhalb der Umgebung und außerhalb des Kontexts von CI/CD-Systemen zu bewegen.
Risiken im Zusammenhang mit einer unsicheren Systemkonfiguration
DevOps-Teams, die die mit unsicheren Systemkonfigurationen verbundenen Risiken kennen, sind in der Lage, weniger anfällige Systeme zu entwickeln, die Verantwortung für die Sicherheit der von ihnen entwickelten Systeme zu übernehmen und Risiken zu mindern, wenn sie auftreten.
Fallstudie 1: PHP wechselt nach einem Sicherheitsvorfall und einem möglichen Leck in der Benutzerdatenbank zu GitHub
Im April 2021 wurde die PHP-Community mit einem Sicherheitsvorfall konfrontiert, der git.php.net betraf. Ursprünglich wurde vermutet, dass es sich um eine Kompromittierung des Servers handelte. Die Untersuchung ergab jedoch, dass die böswilligen Übertragungen über HTTPS und Kennwort-Authentifizierung erfolgten, wodurch die Gitolite-Infrastruktur umgangen wurde. Die Benutzerdatenbank von master.php.net ist möglicherweise undicht geworden, so dass das System auf main.php.net umgestellt und das Kennwort für alle php.net-Benutzer zurückgesetzt werden muss. Git.php.net und svn.php.net wurden schreibgeschützt und das primäre PHP-Repository wurde nach GitHub verlegt, um die Sicherheit zu erhöhen und den Entwicklungsprozess zu vereinfachen.
Fallstudie 2: Webmin überarbeitet Sicherheitsmaßnahmen nach Vorfall mit bösartigem Code
Im August 2019 wurde Webmin, ein webbasiertes Systemkonfigurations-Tool, von einer Sicherheitslücke heimgesucht, als bösartiger Code in seinen Quellcode eingefügt wurde. Die Lücke, die kein zufälliger Fehler war, ermöglichte die Ausführung von Befehlen aus der Ferne. Der bösartige Code wurde über einen kompromittierten Entwicklungs-Build-Server eingeschleust. Nach der Entdeckung reagierte Webmin, indem es den Erstellungsprozess aktualisierte, um nur eingecheckten Code von GitHub zu verwenden, alle zugänglichen Geheimnisse zu rotieren und alle GitHub-Commits des letzten Jahres auf ähnliche Schwachstellen zu überprüfen.
Fallstudie 3: Quellcode von Nissan North America aufgrund eines falsch konfigurierten Git-Servers online gestellt
In einer bedeutenden Sicherheitslücke ist der Quellcode von Nissan North America für mobile Apps und interne Tools aufgrund eines falsch konfigurierten Git-Servers ins Internet gelangt. Der Server, der mit dem Standard-Benutzernamen und dem Kennwort "admin/admin" offengelegt wurde, wurde von dem in der Schweiz ansässigen Software-Ingenieur Tillie Kottmann entdeckt. Das Repository enthielt Code für verschiedene Nissan-Apps, Diagnose-Tools, Händlerportale, Marketing-Tools und mehr. Nissan bestätigte den Vorfall, sicherte das betroffene System und versicherte, dass keine persönlichen Daten zugänglich waren.
Fallstudie 4: Die IT-Abteilung des Staates New York stellt internes Code-Repository online
Ein internes Code-Repository, das von der IT-Abteilung des Staates New York genutzt wird, wurde versehentlich online gestellt und damit für jeden zugänglich gemacht. Der GitLab-Server, der von der Cybersecurity-Firma SpiderSilk entdeckt wurde, enthielt Projekte mit geheimen Schlüsseln und Kennwörtern für staatliche Regierungssysteme. Der Server war so konfiguriert, dass jeder ein Benutzerkonto erstellen und sich anmelden konnte. Der Server wurde erstmals am 18. März online entdeckt und nach der Meldung der Aufdeckung offline genommen. Bei dem Server handelte es sich Berichten zufolge um eine von einem Anbieter eingerichtete Testbox, die inzwischen außer Betrieb genommen wurde.
Verhindern einer unsicheren Systemkonfiguration in CI/CD
Obwohl Fehlkonfigurationen ein Einfallstor für Angreifer sein können, das zu erheblichen Sicherheitsverletzungen führt, wird die sichere Systemkonfiguration in vielen Entwicklungsprozessen immer noch übersehen. Mit den Insider-Empfehlungen der Autoren der OWASP Top 10 CI/CD Security Risks Liste können Sie Ihre Systeme auf Vordermann bringen:
- Führen Sie ein Inventar der verwendeten Systeme und Versionen und ordnen Sie jedes System einem bestimmten Eigentümer zu. Überprüfen Sie diese Komponenten regelmäßig auf bekannte Sicherheitslücken. Wenn ein Sicherheits-Patch verfügbar ist, aktualisieren Sie die anfällige Komponente. Wenn kein Patch für die anfällige Komponente verfügbar ist, sollten Sie die Komponente oder das System entfernen. Oder minimieren Sie die potenziellen Auswirkungen einer Ausnutzung der Schwachstelle, indem Sie den Zugriff auf das System oder seine Fähigkeit, sensible Operationen durchzuführen, einschränken.
- Stellen Sie sicher, dass der Netzwerk-Zugriff auf die Systeme dem Prinzip des Least-Privilege-Zugriffsentspricht.
- Richten Sie einen Prozess zur regelmäßigen Überprüfung aller Systemkonfigurationen ein. Konzentrieren Sie sich bei der Überprüfung auf Einstellungen, die die Sicherheit des Systems beeinträchtigen könnten. Sorgen Sie für optimale Einstellungen.
- Erteilen Sie Berechtigungen für die Pipeline-Ausführungsknoten nach dem Prinzip der geringsten Berechtigung. Eine häufige Fehlkonfiguration in diesem Zusammenhang ist die Gewährung von Debug-Berechtigungen auf Ausführungsknoten für Ingenieure. Viele Organisationen erlauben dies, aber es ist wichtig zu bedenken, dass jeder Benutzer mit Zugriff auf den Ausführungsknoten im Debug-Modus alle Geheimnisse preisgeben könnte, während sie in den Speicher geladen werden. Sie könnten auch die Identität des Knotens verwenden und damit jedem Ingenieur mit dieser Berechtigung erweiterte Rechte gewähren.
Industriestandards für die Sicherheit der Systemkonfiguration
Mehrere Industriestandards beschreiben bewährte Verfahren für die Sicherheit der Systemkonfiguration. Das Center for Internet Security (CIS) bietet umfassende Benchmarks für eine sichere Konfiguration, während das National Institute of Standards and Technology (NIST) ebenfalls Richtlinien für die Konfiguration von Systemen für die Sicherheit veröffentlicht.
Ihre Geheimnisse verschlüsseln
Geheimnisse wie Kennwörter, API-Schlüssel und Datenbankanmeldeinformationen sollten im Ruhezustand und bei der Übertragung verschlüsselt werden. Speichern Sie niemals Geheimnisse in Ihrem Code oder Ihren Konfigurationsdateien. Verwenden Sie ein Tool zur Verwaltung von Geheimnissen wie HashiCorp Vault oder AWS Secrets Manager. Diese Tools verschlüsseln Geheimnisse und kontrollieren den Zugriff darauf. So können Sie verhindern, dass die Daten Ihrer Organisation in die falschen Hände geraten.
Protokollierung und Überwachung Ihrer Systeme
Ein wichtiger Teil der Aufrechterhaltung einer sicheren Systemkonfiguration ist die Festlegung klarer Richtlinien und die routinemäßige Überwachung der Compliance. Es ist wichtig, alle Aktivitäten zu protokollieren, damit Sie verdächtige Aktivitäten erkennen und schnell auf Sicherheitsvorfälle reagieren können. Sie sollten Ihr System auch auf Anzeichen von Angriffen überwachen, wie z.B. ungewöhnliche Verkehrsmuster oder fehlgeschlagene Anmeldeversuche.
Patches für Sicherheitslücken
Stellen Sie sicher, dass Sie über ein umfassendes System zur Erkennung von Sicherheitslücken und zum Patching verfügen. Identifizieren Sie systematisch Schwachstellen und setzen Sie Prioritäten bei der Behebung. In Fällen, in denen Schwachstellen nicht gepatcht werden können, sollten Sie alternative Abhilfemaßnahmen ergreifen, wie z.B. das Entfernen von Administratorrechten. Denken Sie daran, dass Sie Ihre Systeme auf dem neuesten Stand halten müssen, indem Sie regelmäßig Patches und Updates für Ihre Server, Anwendungen und CI/CD-Tools installieren.
Eliminierung unnötiger Konten und Privilegien
Setzen Sie das Prinzip der geringsten Rechte durch, indem Sie unnötige Konten (wie verwaiste Konten und ungenutzte Konten) entfernen. Dies ist eine der wirksamsten Sicherheitspraktiken, um Ihre Angriffsfläche zu reduzieren. Stellen Sie sicher, dass jede Komponente Ihres Systems - einschließlich Benutzern, Prozessen und Diensten - nur über die minimalen Berechtigungen verfügt, die zur Erfüllung ihrer Funktion erforderlich sind. Auf diese Weise können Sie den Schaden im Falle einer beschädigten Komponente begrenzen.
Errichten von Netzwerk-Straßensperren
Die Aufteilung Ihres Netzwerks in kleinere, isolierte Segmente schränkt die seitliche Bewegung ein, wenn ein Angreifer Zugang zu Ihrem Netzwerk erhält. Verwenden Sie Firewalls und Zugriffskontrolllisten (ACLs), um den Datenverkehr zwischen den Segmenten zu kontrollieren. Verschlüsseln Sie den Datenverkehr, blockieren Sie ungenutzte oder nicht benötigte offene Netzwerk-Ports, und deaktivieren oder entfernen Sie unnötige Protokolle und Dienste. Prüfen Sie regelmäßig Ihre Firewall-Regeln.
Absicherung Ihrer Build Server
Ihre Build-Server sind für die Kompilierung und das Paketieren Ihres Codes zuständig und damit ein bevorzugtes Ziel für Angreifer. Stellen Sie sicher, dass Ihre Build-Server mit aktuellen Sicherheits-Patches und sicheren Kennwörtern geschützt sind. Und denken Sie daran, dass die Sicherung Ihrer Build-Umgebung bedeutet, dass Sie sie von Ihrer Produktionsumgebung isolieren müssen.
Überprüfung Ihrer bestehenden Systeme
Regelmäßige Audits und Überprüfungen tragen dazu bei, dass die Systemkonfigurationen auf Dauer sicher bleiben. Führen Sie eine umfassende Prüfung Ihrer vorhandenen Technologie durch. Verwenden Sie Penetrationstests, Schwachstellen-Scans, Konfigurationsmanagement und andere Sicherheitsüberprüfungs-Tools, um Schwachstellen im System zu finden und deren Behebung zu priorisieren. Führen Sie Systembewertungen gegen Ressourcen durch, indem Sie die Industriestandards von NIST, Microsoft, CIS, DISA, etc. verwenden.
Tools für eine sichere Systemkonfiguration verwenden
Es gibt viele Tools, die bei der Verwaltung und Sicherung der Systemkonfiguration helfen. Konfigurationsmanagement-Tools wie Ansible, Chef oder Puppet ermöglichen eine automatisierte Konfiguration und eine konsistente Anwendung in verschiedenen Umgebungen. Für Cloud-basierte Systeme können Cloud-native Dienste wie AWS Config, Azure Policy und Google Cloud Security Command Center bei der Aufrechterhaltung einer sicheren Konfiguration helfen.
FAQs zur unsicheren Systemkonfiguration
Standards zur Systemhärtung sind Richtlinien und bewährte Praktiken, die dazu dienen, Systeme vor Bedrohungen zu schützen. Die oft von Organisationen für Cybersicherheit oder Industriegruppen entwickelten Härtungsstandards bieten einen Rahmen für die Konfiguration eines Systems, um dessen Angriffsfläche zu minimieren.
Beispiele für Härtungsstandards sind die Center for Internet Security (CIS) Benchmarks, die klar definierte, unvoreingenommene und auf einem Konsens basierende Best Practices der Branche bieten, um Organisationen bei der Bewertung und Verbesserung ihrer Sicherheit zu helfen.
Weitere Standards sind die Security Technical Implementation Guides (STIGs) der Defense Information Systems Agency (DISA) und die Härtungsrichtlinien des National Institute of Standards and Technology (NIST). Diese Standards decken eine breite Palette von Systemen ab, darunter Betriebssysteme, Netzwerkgeräte und Cloud-Umgebungen, und werden regelmäßig aktualisiert, um neue Bedrohungen und Schwachstellen zu beseitigen.