Zwei Secure DevOps-Profis teilen ihre hart erarbeiteten Erkenntnisse
Mike Johnson, CISO bei Fastly, und Ben Kero, Senior DevOps Engineer bei Brave Software, sind begeisterte Sicherheitsexperten mit insgesamt 35 Jahren Erfahrung. Beide sind überzeugte Anhänger von Secure DevOps und haben erlebt, auf welch vielfältige Art diese Denkweise ihren jeweiligen Unternehmen hilft, ihre Produkte abzusichern und überragende Nutzererlebnisse zu bieten. Während Mike sich als Hüter von Fastlys Vision von Sicherheit und Compliance gemeinsam mit unserem Produktteam um die Programmierung entwicklerfreundlicher Tools für die Absicherung von Webanwendungen kümmert, treibt Ben tagtäglich die Kultur hinter dem neuesten sicheren Webbrowser voran. Mike und Ben haben sich kürzlich über das Konzept von Secure DevOps (oder DevSecOps) unterhalten und darüber gesprochen, wie Unternehmen Security zu einem Kernbestandteil ihrer Development Pipeline machen können. Wir haben die Highlights für Sie zusammengefasst:
Es wird Abstriche geben, aber sie werden sich lohnen.
Die Implementierung von Sicherheitsmaßnahmen zu einem früheren Zeitpunkt im Entwicklungsprozess bedeutet unter Umständen mehr Arbeit bei späteren Updates und Verbesserungen. Allerdings zahlt sich dieser zusätzliche Zeit- und Arbeitsaufwand aus, wenn das Ergebnis sichere Anwendungen sind.
Das Brave Team arbeitet nach dem Prinzip der geringstmöglichen Privilegien – es vergibt nur die Zugriffsrechte, die zur Ausführung einer bestimmten Aufgabe nötig sind. Dies bringt laut Ben aber folgenden Nachteil mit sich: Wenn man im Nachhinein eine Funktion ändert, muss man gegebenenfalls „Fang den Maulwurf“ spielen, wenn man versucht, eine einzelne, von einer Funktion benötigte neue Berechtigung hinzuzufügen. Aufgrund des hohen Sicherheitsniveaus, das dieser Kompromiss den Anwendungen von Brave beschert, lohnt er sich aber für Bens Team, und das Unternehmen ist bereit, in diese Vorgehensweise zu investieren, da sie es zukünftig möglicherweise vor kostspieligen Sicherheitsverletzungen schützt.
Mike und das Fastly Team konzentrieren sich gerne auf die langfristigen Vorteile dieses Ansatzes: Je weiter der Entwicklungsprozess bereits fortgeschritten ist, wenn eine Schwachstelle aufgedeckt wird, desto größer der potenzielle Schaden, die Kosten, die Haftung und der Gesamtaufwand für eine Kurskorrektur. Je früher man sich also über Security Gedanken macht, desto geringer der spätere Aufwand beim Durchforsten von Code. Mike merkt außerdem an, dass das Erreichen von „absoluter Sicherheit“ nahezu unmöglich ist und wahrscheinlich zu einer Arbeitsweise führen würde, durch die sich sowohl die Unternehmenskultur verschlechtern als auch Produkte entstehen könnten, die nicht wirklich auf die Anforderungen der Kunden zugeschnitten sind.
Bedrohungsmodellierung nützt allen.
Die Bedrohungsmodellierung – das Verfahren zur Ermittlung potenzieller Schwachstellen einer Anwendung und ihres Schweregrads sowie zur Zuweisung der richtigen Abwehrstrategie – ist etwas, das bei Fastly mit besonderer Sorgfalt durchgeführt wird. Es handelt sich dabei um eines unserer wichtigsten Sicherheitstools, das gar nicht so schwer zu realisieren ist. Ein gut durchdachtes Bedrohungsmodell versetzt Entwickler in die Lage, schneller zu programmieren, Sicherheitsteams, die eigentlichen Vorgänge während der Laufzeit der Anwendung zu verstehen, und DevSec-Spezialisten, Anomalien leichter zu erkennen. Bedrohungsmodelle eignen sich hervorragend als Blaupause für die Performance einer Anwendung und für die Zuweisung einer Lösung, falls entsprechende Probleme auftreten.
Eine laufende Bestandsaufnahme Ihres Open-Source-Codes könnte Ihr Rettungsanker sein.
Ihr nutzerdefinierter Code mag zwar fehlerfrei und gegen jeden Angriff geschützt sein, aber sobald er mit Code aus anderen Quellen wie beispielsweise einer Code-Bibliothek oder einem Open-Source-Modul in Berührung kommt, führen Sie potenzielle Schwachstellen ein. Hinzu kommt, dass eine bestimmte Schwachstelle heute vielleicht noch gar nicht existiert und erst in späteren Versionen der Bibliothek auftritt. Alles von Grund auf neu zu programmieren ist keine Lösung. Die Wiederverwendung von Code und Open-Source-Code bilden die Grundlage der modernen App- und Website-Entwicklung – auch bei Fastly. Mike empfiehlt eine laufende Bestandsaufnahme des in Ihrer App verwendeten Open-Source-Codes, bei der Ihr Team idealerweise automatisch alarmiert wird, wenn eine bekannte Schwachstelle in einem Teil dieses Codes auftritt. So lassen sich zukünftige Probleme proaktiv im Auge behalten.
Ergonomie zählt – auch in der Entwicklung.
Um sicherzustellen, dass die Sicherheitsmaßnahmen bereits zu einem früheren Zeitpunkt im DevOps-Zyklus greifen, ist es wichtig, dass Ihre Sicherheitstools mit Blick auf die Entwickler konzipiert werden. Anbieter von Sicherheitstools können, so Mike, nicht davon ausgehen, dass ihre Nutzer Sicherheitsexperten sind, aber sie sollten auch nicht davon ausgehen, dass sie Anfänger sind. Das Vertrauen und Verständnis der Nutzer für Sicherheitspraktiken zu beurteilen, ist entscheidend. Laut Mike steht die Transparenz an zweiter Stelle nach dem Verständnis des Nutzers, da Entwickler – genau wie Sicherheitsexperten – es zu schätzen wissen, wenn sie einen genauen Überblick darüber haben, was ihr Code und ihr Produkt tun. Entwicklern ein Tool an die Hand zu geben, das sowohl ihren Code als auch ihr Sicherheitsdenken stärkt, ist eine Win-win-Situation.
Zu den Features, die sich für Ben und sein Team als besonders nützlich erwiesen haben, gehören Changelogs für Korrekturen und neue Funktionen, Dokumentation über die Integrationsmöglichkeiten Ihres Tools in verschiedene Workflows wie Travis oder Terraform, und eine Anleitung (Bonuspunkt für Screenshots!), was man mit einer guten Konfiguration erreichen kann. Diese Dinge helfen Entwicklern bei der Visualisierung des Endziels. Entwicklerorientierte Tools können auch zusätzliche Layer bei einer Defense-in-Depth-Sicherheitsstrategie bieten. Beispielsweise halten Fastlys Code-Snippets – kurze Blöcke von VCL-Logik, die direkt in Konfigurationen eingebunden werden können – Braves S3-Buckets geheim.
Secure DevOps ist kein Ersatz für Sicherheitsupdates nach der Bereitstellung, sondern lediglich ein Zusatz.
Die Anwendung Ihrer CI/CD-Sicherheitserfahrungen auf Ihre Sicherheitsmaßnahmen im Anschluss an die Bereitstellung kann Ihrem Team helfen, neue Effizienzen aufzubauen – besonders durch Automatisierung. Das Brave Team verwendet eine nutzerdefinierte GitHub Aktion, die den bereitgestellten Code scannt und eine Warnung sendet, sobald eine Sicherheitslücke erkannt wird. Sie öffnet sogar automatisch einen Pull Request und initiiert eine Überprüfung. Ben ist der Meinung, dass die besten Tools diejenigen sind, die die Zeit zwischen dem Auffinden von Schwachstellen und deren Behebung minimieren.
Erinnern Sie sich an das Bedrohungsmodell? Bei der Untersuchung des Traffics greift Mikes Team hier bei Fastly immer wieder auf das Bedrohungsmodell zurück, um zu ermitteln, ob es sich dabei um normale Traffic-Muster handelt und wie man am besten gegen Bedrohungen vorgeht. Wenn das Team irgendeine Abweichung von diesem ursprünglichen Plan feststellt, kann es diese genauer untersuchen und gegebenenfalls Abwehrmaßnahmen ergreifen. (Ein Tipp vom Profi: Wenn Sie nach Abhilfemaßnahmen suchen, sollten Sie zuerst Ihre bestehenden Kontrollmechanismen überprüfen. Ist die WAF für die Traffic-Last angemessen konfiguriert? Wenn es sich um ein hohes Traffic-Volumen handelt, bedeutet das, dass die DDoS-Abwehr nicht angemessen funktioniert?) Die wahre Stärke eines guten Bedrohungsmodells liegt darin, dass es Ihnen den besten nächsten Schritt aufzeigt und einen ganzheitlichen Blick auf die Security bietet – sowohl innerhalb von CI/CD als auch nach der Bereitstellung.
Eine engagierte Community kann Ihre geheime Zutat sein.
Brave nutzt Communities, um sowohl deren CI/CD-Workflow als auch seine eigenen Produkte zu verbessern. Um die Pipeline zu rationalisieren, sucht Bens Team bei Sicherheitsanbietern nach Tools, die von anderen Teams entwickelten wurden und sich umfunktionieren lassen. Auf der anderen Seite belohnt Braves Bug Bounty Programm Nutzer und Sicherheitsforscher für das Auffinden und Melden von Fehlern in der Software des Unternehmens – eine Feedback-Schleife, die für Nutzer nicht nur zu einer sichereren Anwendung führt, sondern auch ihr Vertrauen in Brave stärkt.
Fastly investiert in Communities und Organisationen, die sich für die Sicherheit unserer Produkte und des Internets als Ganzes für beide Seiten als vorteilhaft erwiesen haben. Unsere Entwickler haben die Ausarbeitung von Sicherheitsrichtlinien und Fuzzing-Integrationen in einigen der Open-Source-Projekte, die wir im Laufe der Jahre genutzt haben, gefördert. Dazu gehören unter anderem H2O, Wasmtime, Knot DNS, und Tokio-rs. Und unsere Mitarbeit bei der IETF hat dazu beigetragen, die Entwicklung und Freigabe von TLS 1.3 zu ermöglichen. Auf der anderen Seite stellt die Bytecode Alliance eine Schlüsseltechnologie für unsere serverlose Compute@Edge Umgebung bereit, bei der die Verwendung von WebAssembly besonders starke Isolationsgarantien ermöglicht.
Sehen Sie sich im nachfolgenden Video das komplette Gespräch an, um tiefer in die technischen Details dieser Erkenntnisse einzutauchen.
