Microsoft Azure Security (eBook)

KAPITEL 1

Prozesse für sichere Entwicklungszyklen

Am Ende dieses Kapitels

• verstehen Sie einige der Prozesse, die für die Entwicklung sicherer Software erforderlich sind.
• können Sie innerhalb Ihrer Organisation dazu beitragen, eine Sicherheitskultur zu entwickeln.
• sind Sie in der Lage, den Zweck der verschiedenen Arten von Umgebungen für die Entwicklung bis hin zur Produktion zu erläutern und welche unterschiedlichen Sicherheitsmaßnahmen sie erfordern.

Entwickler sind die Hauptursache für Kompromittierungen

Die Hauptursache für Gefährdungen sind nicht Hacker, Angreifer oder andere ruchlose Akteure. Vielmehr sind wir, die Softwareentwickler, die Hauptursache für Sicherheitslücken. Laut einer Analyse von Contrast Security aus dem Jahr 2020 sind fast 50 Prozent aller Kompromittierungen auf Schwachstellen in Anwendungen zurückzuführen – Schwachstellen, die letztlich von Softwareentwicklern geschaffen wurden. Eine Zusammenfassung des Berichts können Sie hier lesen: https://azsec.tech/lvz.

Als Softwareentwickler können wir nicht viel gegen Angriffe tun. Sie werden auf jeden Fall stattfinden. Was wir aber tun können, ist, die Sicherheit unseres Codes zu verbessern. Wir kommen nicht darum herum, dass das Design unseres Systems und die Qualität unseres Codes den Unterschied zwischen einem fehlgeschlagenen und einem erfolgreichen Angriff ausmachen können. Wir müssen die Art und Weise ändern, wie wir Software entwerfen und entwickeln, um die Sicherheit so nahtlos wie möglich und mit so wenig Reibungsverlusten wie möglich zu verbessern. Das entscheidende Wort hier ist Reibung. Sicherheit wird oft als eine Art Steuer angesehen, die Entwickler zahlen müssen und die die Entwicklung behindert. Sie steht einfach im Weg. Wir müssen Prozesse und Aufgaben einbeziehen, die die Sicherheit erhöhen, die so reibungslos wie möglich sind und einfach als ein weiterer wichtiger Aspekt bei der Erledigung der Aufgabe angesehen werden.

Natürlich sind auch Werkzeuge wichtig. Aber sie sollten nicht blindlings eingesetzt oder als einzige Quelle für die Sicherheit Ihrer Lösung betrachtet werden. Ganz gleich, wie viele Tools oder Automatisierungsfunktionen Sie bei Ihren Entwicklungsverfahren einsetzen, letztendlich sind es Menschen, die Software erstellen, und auch Ihre Sicherheitslage hängt von Menschen ab. Wie das Sprichwort sagt: »Ein Dummkopf mit einem Werkzeug ist immer noch ein Dummkopf.« Wir müssen also nicht nur in die neuesten Sicherheitstools investieren, sondern auch in menschliches Sicherheitskapital und Prozesse.

Einführung in den Microsoft Security Development Lifecycle

Der Microsoft Security Development Lifecycle (SDL) entstand Anfang der 2000er-Jahre und wurde im Laufe der Jahre angewandt und angepasst. Ein Sprichwort sagt: »Es gibt nichts Neues unter der Sonne«, und das trifft auf den SDL zu. Der SDL unterscheidet sich jedoch durch die Menge an unterstützender Dokumentation, Werkzeugen, Forschungsergebnissen und Vordenkern, die Microsoft öffentlich zugänglich gemacht hat.

Was also ist der SDL? Der SDL besteht aus einer Reihe von Praktiken zur Verbesserung der Softwaresicherheit. Er verfolgt zwei übergreifende Ziele:

• Verringerung der Anzahl von Sicherheitslücken in Ihrem Code
• Verringerung der Schwere der Schwachstellen, die Sie übersehen

Diese beiden Ziele führen zu einer gewissen Spannung in Ihrer Sicherheitsstrategie. Sie möchten die sicherste Software entwickeln, müssen aber gleichzeitig damit rechnen, dass Ihnen etwas entgeht und dass sich die Strategien der Angreifer mit der Zeit weiterentwickeln. Was heute sicher und korrekt ist, kann morgen angreifbar sein.

Qualität ≠ Sicherheit

Wir hören oft, dass Leute sagen: »Wenn man die Qualität verbessert, dann verbessert sich auch die Sicherheit.« Diese Aussage klingt zwar plausibel, aber es gibt keine Beweise, die diese Aussage stützen. Keine. Softwarequalitätsprogramme finden nur selten Sicherheitsprobleme, denn Sicherheitsprobleme sind etwas anderes als Qualitätsprobleme. Außerdem wird Sicherheit, wie wir später in diesem Buch erörtern, oft als »zusätzliche« Funktionalität definiert.

Angenommen, Sie haben eine Anwendung, die lediglich die folgenden Datenbankoperationen durchführt:

• Hinzufügen eines neuen Benutzers (Erstellen/Create in CRUD)
• Lesen der Details eines Benutzers (Lesen/Read in CRUD)
• Bearbeitung der Benutzerdaten (Aktualisierung/Update in CRUD)
• Löschen eines Benutzers (Löschen/Delete in CRUD)
• Drucken der Benutzerdaten

Sie erstellen einige Tests, die erfolgreich oder (absichtlich!) fehlschlagen sollen, und überprüfen dann diese Erfolge und Fehlschläge. Wenn alle Tests, die den Erfolg überprüfen sollen, erfolgreich sind und alle Tests, die das Scheitern überprüfen sollen, pflichtgemäß scheitern, könnte man zu dem Schluss kommen, dass die Anwendung keine Fehler aufweist. Dies ist jedoch nicht der Fall. Wenn die Anwendung beispielsweise eine SQL-Injection-Schwachstelle aufweist, die es einem Tester (oder Angreifer) ermöglicht, alle Benutzer zu lesen oder eine Datenbanktabelle zu löschen, wird die Anwendung dennoch alle Erfolgstests bestehen und alle Fehlertests nicht bestehen. Die Moral von der Geschichte ist, dass Sie Ihren Softwareentwicklungsprozessen Sicherheit als eigenen Faktor hinzufügen müssen.

Sicherungsmerkmale vs. Sicherheitsmerkmale

Das Microsoft SDL konzentriert sich auf die Sicherung Ihrer Software, nicht nur auf das Hinzufügen weiterer Sicherheitsfunktionen. Sicherheitsfunktionen sind wichtig, aber Sie können nicht einfach jedes beliebige Sicherheitsprodukt in Ihre Lösung einbauen und sie als sicher bezeichnen. Die Funktionen, die Sie Ihren Lösungen hinzufügen, müssen ebenfalls sicher sein. Diese philosophische Perspektive stellt einen wichtigen Sinneswandel für viele dar, die glauben, sie könnten ein Produkt kaufen und es als erledigt betrachten – vor allem, wenn so viele Unternehmen ihre Produkte als Allheilmittel verkaufen.

SDL-Komponenten

Die wichtigsten Aufgaben und Anforderungen von Microsoft SDL sind wie folgt:

• Sicherheitsschulung
• Definieren Ihrer Bug Bar
• Analyse der Angriffsfläche
• Modellierung von Bedrohungen
• Definieren Ihrer Toolchain
• Verbotene Funktionalität vermeiden
• Werkzeuge zur statischen Analyse verwenden
• Dynamische Analysetools verwenden
• Review des Sicherheitscodes
• Reaktionsplan bei Zwischenfällen zur Hand haben
• Penetrationstests durchführen

Schauen wir die einzelnen Punkte genauer an.

Sicherheitsschulung

Sicherheitsschulungen sind ein Muss. Aber mit Sicherheitsschulung meinen wir nicht die Schulung »Passwörter nicht wiederverwenden!«, sondern die Schulung »Sicherheit bei der Anwendungsentwicklung«.

Lange Zeit verlangte Microsoft von allen technischen Mitarbeitern, dass sie an allgemeinen Sicherheitsschulungen teilnehmen, und die Mitarbeiter können dies auch heute noch tun, wenn sie wollen. Heutzutage verwenden wir jedoch ein...