Secure by Design 

Wie kann man Sicherheitsprinzipien frühzeitig in den Entwicklungsprozess einbeziehen, anstatt sie erst hinterher irgendwie reinzubasteln?. Eoin erzählt von seinen Erfahrungen aus der Vergangenheit und zeigt, wie das Sicherheitsbewusstsein im Laufe der Jahre gewachsen ist. Er betont die Bedeutung von Prinzipien wie „Defense in Depth“ und die Verwendung sicherer Standardeinstellungen. Wir sprechen auch über die Herausforderungen, mit den neuesten Sicherheitsbedrohungen Schritt zu halten, und über den Wert der frühen Einbindung von Sicherheitsingenieuren und Testern in das Projekt.

“If you start thinking about security in the last 10% of your project, you’re going to get 10% security.” – Eoin Woods

Eoin Woods ist Chief Engineer bei Endava, wo er für Kompetenzentwicklung, Innovation und neue Technologien zuständig ist. In seinem früheren Berufsleben hat er Datenbanken entwickelt und Sicherheitssoftware erstellt. Außerhalb seines Berufslebens interessiert er sich für Softwarearchitektur, Softwaresicherheit, DevOps und Software-Energieeffizienz. Er ist ein regelmäßiger Konferenzredner, hat drei Bücher über Softwarearchitektur mitverfasst und wurde 2018 mit dem Linda Northrup Award for Software Architecture des Software Engineering Institute an der CMU ausgezeichnet.

Highlights in dieser Episode:

• Sicherheit als first-class citizen im Entwicklungsprozess
• Softwareentwickler fehlen tiefgreifenden Kenntnisse im Bereich Sicherheit, was sich erst langsam ändert.
• Das Konzept „Defense in Depth“ zum Schutz eines Systems beinhaltet.
• Etablierte Bibliotheken statt Eigenentwicklungen.
• Die Nutzung von Ressourcen von OWASP.
• Die Herausforderung von Zero-Day-Schwachstellen und wie wichtig es ist, Komponenten auf dem neuesten Stand zu halten.

Weiterführende Links:

• Eoins Website
• Continuous Architecture in Practice
• Software Systems Architecture

Security by Design implementieren

In dieser Folge bespreche ich mit Eoin das Konzept der „Security by Design“. Wir untersuchen Prinzipien wie „Defense in Depth“, die Vermeidung benutzerdefinierter Sicherheitslösungen und die Einbeziehung der Sicherheit in den gesamten Lebenszyklus der Softwareentwicklung. Dieses Gespräch unterstreicht die Bedeutung proaktiver Sicherheitsmaßnahmen in der Softwareentwicklung.

Einführung in Security by Design

Hallo und willkommen zu einer neuen Folge des Podcasts Software Testing! Heute haben wir eine besondere Folge, die live von der OOP 2024 Konferenz in München aufgezeichnet wurde. Ich bin Richie, Ihr Gastgeber, und unser heutiger Gast ist Eoin Wutz. Wir hatten ein interessantes Gespräch über die Umsetzung von ‘Security by Design’ in der Softwareentwicklung. Dieses Thema liegt mir sehr am Herzen, denn wie wir alle wissen, erfolgt das Testen auf Sicherheit oft zu spät im Prozess. Dann ist es, als würde man versuchen, das Kind wieder in den Brunnen zu stecken – es ist bereits zu spät. Lassen Sie uns also ergründen, wie wir Sicherheit von Anfang an integrieren können.

Der Wandel in der Sicherheitsmentalität

Eoin erzählte zunächst von seiner Reise in die Sicherheitstechnik. Er erinnerte sich daran, wie schwierig es vor zehn Jahren war, Menschen für das Thema Sicherheit zu begeistern. Damals fand er sich oft in Räumen wieder, in denen nur eine Handvoll Interessierter saß – alle auf Sicherheit spezialisiert. Heute jedoch haben sich die Dinge dramatisch verändert. Die Räume sind jetzt voll von Menschen, die sich für Sicherheit interessieren. Dieser Wandel bedeutet nicht nur einen Bewusstseinswandel, sondern auch eine Anerkennung der kritischen Rolle, die Sicherheit in verschiedenen Bereichen spielt – sei es Leistung, Belastbarkeit oder Verfügbarkeit.

Grundsätze für eine frühzeitige Sicherheitsintegration

Ein wichtiger Punkt, den Eoin hervorhob, war die Bedeutung einer frühzeitigen Integration der Sicherheit in den Entwicklungsprozess. Wenn Sie erst in den letzten 10 % Ihres Projekts über Sicherheit nachdenken“, warnte Eoin, “werden Sie nur 10 % Sicherheit erhalten. Vielen Software-Ingenieuren fehlt es an einem soliden Hintergrundwissen im Bereich Sicherheit; einige Universitäten beginnen jedoch, diese Lücke zu schließen, indem sie bereits im ersten Studienjahr mehr sicherheitsbezogene Lehrveranstaltungen anbieten. Trotz dieser Fortschritte gibt es immer noch eine Kluft zwischen Softwareentwicklern und Sicherheitsingenieuren – jede Gruppe spricht ihre eigene Sprache und hat ihre eigenen Prioritäten.

Defense in Depth und Vermeidung von Speziallösungen

Eoin hob mehrere Grundsätze hervor, beginnend mit der „Verteidigung in der Tiefe“. Angesichts der ausgefeilten Angreifer von heute ist es naiv, sich auf eine einzige Sicherheitsebene wie Verschlüsselung oder Authentifizierung zu verlassen. Mehrere Ebenen stellen sicher, dass selbst wenn eine Ebene durchbrochen wird, die anderen weiterhin Bestand haben. Ein weiterer Grundsatz, den er betonte, war die Vermeidung von maßgeschneiderten Sicherheitslösungen. Es mag für Ingenieure verlockend erscheinen, eigene Verschlüsselungssysteme oder Passwort-Tresore zu bauen, aber das ist mit Risiken verbunden. Fachleute testen Industriestandardlösungen rigoros; selbstentwickelte Lösungen werden selten einer solchen Prüfung unterzogen.

Navigieren zwischen Open-Source- und Closed-Source-Lösungen

Wenn es um die Wahl zwischen Open-Source- und Closed-Source-Lösungen für Verschlüsselung und andere Sicherheitsmaßnahmen geht, weist Eoin darauf hin, dass der Kontext sehr wichtig ist. Open-Source-Lösungen bieten Transparenz und werden ständig von unabhängigen Forschern überprüft. Allerdings können Closed-Source-Lösungen je nach den spezifischen Marktanforderungen oder Anwendungen manchmal überlegen sein. Das Wichtigste ist, den Anbietern die richtigen Fragen zu stellen und das auszuwählen, was für Ihr Projekt am besten geeignet ist.

Sicherer Lebenszyklus der Softwareentwicklung (SDLC)

Designprinzipien richten sich an Designer“, erklärte Eoin, als es darum ging, wie man Sicherheit in den Softwareentwicklungsprozess einbinden kann. Er empfahl, ein branchenübliches Modell für den Lebenszyklus der sicheren Softwareentwicklung (SDLC) zu übernehmen, wie z. B. die Modelle von OWASP oder verschiedenen Regierungsstellen. Diese Modelle leiten Teams bei der Integration von Sicherheit in jeder Phase an – von der Anforderungserfassung bis zur Bereitstellung. Die Anpassung dieser Modelle an die spezifischen Projektanforderungen kann Unternehmen dabei helfen, potenzielle Schwachstellen systematisch und frühzeitig zu beseitigen.

Sicherheit in die tägliche Praxis bringen

Gegen Ende unseres Gesprächs gingen wir auf praktische Schritte ein, die Teams unternehmen können, um Sicherheit zu einer täglichen Praxis zu machen und nicht nur als nachträglichen Gedanken zu betrachten. Ein effektiver Ansatz ist die Verwendung von „Security User Stories“ oder „Abuser Stories“ während der Bedrohungsmodellierungssitzungen. Dabei werden kritische Fragen darüber gestellt, was schief gehen könnte und wer die Schwachstellen des Systems ausnutzen könnte. Durch die Einbindung von Testern zu einem frühen Zeitpunkt im Entwicklungsprozess können potenzielle Probleme erkannt werden, bevor sie sich verfestigen. Und schließlich kann die Einbeziehung von sachkundigen Anwendungssicherheitsingenieuren während der Entwurfsprüfungen und Bedrohungsmodellierungssitzungen unschätzbare Erkenntnisse liefern.