Etwas, das Sie beim Erstellen Ihrer nächsten Bedrohungsmodelle wahrscheinlich einbeziehen sollten

Wir arbeiten hier bei DisruptOps an unseren Bedrohungsmodellen, deshalb habe ich beschlossen, mein Wissen über verschiedene Ansätze aufzufrischen. Dabei fiel schnell auf, dass so gut wie keine der Dokumentationen oder Werkzeuge zur Bedrohungsmodellierung, die ich gesehen habe, die CI/CD-Pipeline abdeckt.

Das. Ist. Ein. Problem. Beziehen Sie Ihre Pipeline in Ihre Bedrohungsmodelle ein.

In den vergangenen Jahren habe ich neben verschiedenen anderen Beratungstätigkeiten einige Dutzend Cloud-Sicherheitsbewertungen selbst durchgeführt. Ich beziehe dabei durchgängig Entwicklungs- und Deployment-Pipelines in den Umfang ein, und dort sehe ich häufig die größeren Sicherheitsprobleme. Ihre hochsichere Cloud-Umgebung ist ein Kartenhaus, wenn jemand grundlegende Infrastruktur verändern kann, indem er irgendwo ein Template anpasst oder gespeicherte Schlüssel kompromittiert.

Die meisten Bedrohungsmodelle beginnen mit einem Datenflussdiagramm oder einer Architektur, anhand derer Sie Ihre Anwendung durchgehen und Bedrohungen modellieren können (ich selbst bevorzuge STRIDE, das von Microsoft stammt). Das deckt die Anwendungsfunktionalität ab, nicht aber die Pipeline.

Wenn Sie Ihr jeweiliges Bedrohungsmodell *du jour* auf Ihre Pipeline anwenden, behandeln Sie Ihre Entwickler und Administratoren als Benutzer – und die Pipeline selbst ebenfalls als Benutzer, sofern sie Anmeldedaten gespeichert hat (unter Berücksichtigung der Art, wie sie sich mit Ihrer Umgebung verbindet).

Kann zum Beispiel jemand einen API-Aufruf an Jenkins fälschen, um eine Änderung an Ihrer Produktionsanwendung auszulösen? (Vermutlich ja, so wie Jenkins häufig konfiguriert ist.) Wie steht es um die Abstreitbarkeit von Job-Änderungen gegenüber Code-Änderungen? Um Rechteausweitung in der Pipeline?

Pipelines halten einer sicherheitstechnischen Prüfung in der Regel nicht besonders gut stand, deshalb werden wir sie in künftigen Beiträgen zu Sicherheitsgrundlagen behandeln. Es dürfte Sie kaum überraschen, dass ich üblicherweise Leitplanken sowohl für Pipeline-Deployments als auch für jede angebundene Infrastruktur empfehle, um das Risiko zu senken. Ihr CI-Server sollte beispielsweise niemals öffentlich zugänglich oder zugänglich zu machen sein. Sie könnten sich gegenseitig verstärkende Leitplanken nutzen, um sicherzustellen, dass er sich in einem Netzwerksegment ohne Internet Gateway befindet und dass Ihre Sicherheitsgruppen keinen öffentlichen Zugriff erlauben (besser noch: Stellen Sie außerdem sicher, dass CI-Server stets hinter Elastic Load Balancern stehen).

Die Zeiten, in denen sich die Angriffsfläche einer Anwendung auf deren Komponenten beschränkte, sind längst vorbei. In der Cloud werden die meisten unserer Anwendungen von Pipelines gespeist, die aufgrund weitreichender Zugriffsrechte und gespeicherter Anmeldedaten enormes Potenzial als verwundbare Stelle besitzen.