Hey InfoSec, was unternehmt ihr, um euer DevOps-Team zu schützen?

DevOps, serverlose Anwendungen und Container sind nur einige der neuesten Entwicklungen im Werkzeugkasten von Entwicklern. Für Entwicklungsteams bedeutet dies eine schnellere Markteinführung – insbesondere für agile Teams. Doch wie stellen Sicherheitsteams sicher, dass die Sicherheit mit dieser rasanten Entwicklung Schritt hält? Die meisten versuchen, einen Sicherheitsingenieur in ihre Entwicklungsteams zu integrieren – ein guter erster Schritt –, aber es sind mehrere Ebenen erforderlich, um Ihr Unternehmen über den Quellcode hinaus zu schützen.

DevOps bzw. DevSecOps ist ein großer Fortschritt, doch die Einführung (und Implementierung) von DevOps stellt viele Unternehmen nach wie vor vor Herausforderungen. Selbst wenn ein Unternehmen DevSecOps implementiert hat, bestehen weiterhin wichtige Sicherheitsrisiken, die jedes Sicherheitsteam kennen sollte.

Unabhängig von der Unternehmensgröße – vom kleinen Tech-Startup bis zum globalen Konzern – ist die schnelle Bereitstellung entscheidend für den Wettbewerbsvorteil. Die Sicherheitsabteilung muss Ihrem Entwicklungsteam die notwendigen Berechtigungen für die erfolgreiche Durchführung seiner Aufgaben gewähren. Entwickler und Sicherheitsteams müssen gleichermaßen in der Lage sein, alle benötigten Tools, Bibliotheken usw. zu installieren.

Sie haben davon gehört NPM ist kompromittiert Stimmt's? Was ist mit Arch Linux? PythonWelche Sicherheitsmaßnahmen haben Sie in Ihrem Unternehmen implementiert, um dies zu erkennen und zu verhindern?

Überwachen Sie alle Umgebungen

Sicherheitsteams stehen täglich vor einer Vielzahl von Herausforderungen, von kompromittierten Drittanbieterpaketen bis hin zu ihren Produktionssystemen. Doch wie sieht es mit den Bereitstellungsumgebungen aus? Und mit den Testumgebungen? Werden diese genauso gründlich überwacht wie die Produktionsumgebungen? Das sollten Sie unbedingt tun.

In vielen Situationen (wenn auch nicht unbedingt nach bestem Wissen und Gewissen) ist eine Entwicklungs- oder QA-Umgebung eine Nachbildung einer bekannten, funktionierenden Umgebung (wie der Produktionsumgebung). Das bedeutet, dass diese Umgebung könnte haben Produktion Daten, die Ihren Sicherheitsteams bekannt sein sollten. Diese Entwicklungsumgebungen sollten über dieselben oder ähnliche Sicherheitskontrollen verfügen wie ihre Produktionsumgebungen und sollten wie jedes andere Produktionssystem überwacht (und protokolliert) werden.

Es gibt noch viele weitere Kontrollmechanismen, die Sie hinzufügen können, aber der springende Punkt ist, dass Sie sicherstellen müssen, dass Ihr Team diese Umgebungen genau überwacht und Einblick in alle Änderungen hat, die an einer Umgebung vorgenommen werden.

Wenn Ihre Entwicklungs- oder QA-Umgebungen mit Nicht-Produktionsdaten vollgestopft sind, bestehen dennoch Risiken, derer Sie sich bewusst sein sollten.

Schlüssel, Token, CI/CD, oh je!

Haben Ihre Entwickler Zugriff auf Ihre CI/CD-Build- und Deployment-Umgebungen (Continuous Integration und Continuous Delivery)? Haben sie Zugriff auf Entwicklungsumgebungen, entweder lokal oder in AWS/Azure/GCP/etc.?

Wenn Sie mit Ja geantwortet haben, müssen Sie die Aktivitäten Ihrer Entwickler (insbesondere auf deren lokalen Systemen) genau überwachen! Schon der Besuch einer unseriösen Website oder das Fallenlassen auf eine Phishing-E-Mail kann Sie in ernsthafte Gefahr bringen.

Wenn Ihre Entwickler auf Cloud-basierte Ressourcen zugreifen, verwenden sie in der Regel Anmeldeinformationen oder Zugriffs-/geheime Schlüssel. Und raten Sie mal, wo diese gespeichert sind? Genau, auf ihrem lokalen System. Hier ist eine kurze Liste der Speicherorte:

AWS CLI: ls ~/.aws ~/.aws/credentials ~/.aws/config Azure CLI: $HOME/.azure (*nix & macOS) %USERPROFILE%\.azure (Windows)

Wenn die Zugangsdaten auf den Rechnern Ihrer Entwickler kompromittiert werden, kann dies verheerende Folgen für Ihr Unternehmen haben. Ein Angreifer kann Ihre CI/CD-Umgebungen manipulieren und Ihre Codebasis verändern, ohne dass dies in kompilierten Binärdateien oder Bibliotheken jemals erkannt wird.

Darüber hinaus sollten Sie verhindern, dass Entwickler versehentlich Geheimnisse in Repositories einchecken. Es gibt mehrere Möglichkeiten, dies zu erkennen, eine davon ist die Verwendung von git-secrets von AWS.

Stellen Sie sicher, dass Ihr Sicherheitsteam versteht, wo Geheimnisse aufbewahrt werden, wie sie verwendet werden und welche Konsequenzen es hat, wenn ein potenzieller Missbrauch dieser Zugangsdaten nicht überwacht oder gemeldet wird.

Containerisierung

Mit dem Übergang von Unternehmen zu Containern, Serverless-Architekturen und Infrastruktur als Code sollten IT-Sicherheitsteams eng mit den Entwicklungsteams zusammenarbeiten, um ein internes Container-Repository einzurichten, das kontinuierlich vom Sicherheitsteam überwacht wird. Wird ein neues Paket oder eine neue Bibliothek benötigt, muss der Code vor dem Zusammenführen mit dem Master-Branch von einem Sicherheitsexperten (aus dem Entwicklungsteam) geprüft werden. Zusätzlich empfiehlt sich die Implementierung automatisierter Scans der Repositories, um potenziell in Commits verborgene Geheimnisse sowie anfällige Drittanbieterbibliotheken, die in das Produkt importiert oder verwendet werden, aufzuspüren.

Entwicklungsteam + Sicherheit

Stellen Sie sich vor, Sie arbeiten in einem Entwicklerteam und jemand aus einer anderen Abteilung kommt herein und sagt Ihnen, dass Ihre Arbeit miserabel ist und überall Sicherheitslücken lauern. Wie würden Sie reagieren? Wahrscheinlich nicht besonders begeistert, vor allem, wenn Sie der Meinung sind, dass Ihr Code ziemlich gut ist!

Diese Art der Interaktion mit Entwicklungsteams findet ständig statt, und wir müssen dieses Problem anders angehen. Deshalb müssen wir Sicherheitsingenieure in unsere Entwicklungsteams integrieren. Dieser Ingenieur sollte in der Lage sein, Sicherheitsprobleme zu identifizieren, Backlog-Einträge (Tickets) zu erstellen und diese zu bearbeiten (zu programmieren). Diese Schlüsselperson ist sowohl Entwickler als auch Sicherheitsspezialist im Entwicklungsteam.

Stellen Sie sich nun vor, Sie erhalten Feedback von einem Ihrer Teamkollegen. Die Reaktion des restlichen Entwicklerteams wäre verständnisvoller, und es gäbe einen direkten Kommunikationsweg – einschließlich des Aufbaus einer langfristigen Beziehung zwischen Entwicklern und Sicherheitsabteilung. Sobald sich die anderen Entwickler im Team wohlfühlen, möchten sie ihrem Kollegen keine zusätzliche Arbeit aufbürden. Glauben Sie also, dass sie sich Zeit nehmen oder innehalten und über die Implementierung nachdenken werden? Ich denke schon.

Darüber hinaus sollte dieser Sicherheitsingenieur bereits in den frühen Phasen in die Gespräche mit dem Produktmanager/Eigentümer und dem Architekten einbezogen werden, da er de facto das Sicherheitspersonal darstellt und an den ersten Designentscheidungen beteiligt sein sollte, die sich auf die Art und Weise auswirken können, wie Ihr Produkt mit Sicherheit umgeht (z. B. Authentifizierung, gemeinsame Geheimnisse, Kommunikation usw.).

Einpacken

Alle Sicherheitsexperten sind stark ausgelastet. Es gibt zu viele Warnmeldungen und zu wenig Zeit. Auch wenn wir nicht auf jede Warnmeldung reagieren können, müssen die Mitglieder des Security Operations Center (SOC) die Mission ihrer Organisation, den Standort kritischer Assets und die sich ständig verändernde Bedrohungslandschaft verstehen. Durch die Zusammenarbeit mit den Entwicklungsteams können wir unsere jeweiligen Organisationen schützen und Sicherheit fest in unseren Entwicklungszyklus integrieren.