Microsoft Azure Security E-Book

Michael Howard

• Herausgeber: dpunkt.verlag
• Kategorie: Wissenschaft und neue Technologien
• Serie: Best Practices
• Sprache: Deutsch
• Veröffentlichungsjahr: 2023

Seitenzahl: 809

Beschreibung

Sichere Anwendungen und Workloads in der Cloud - praktisches Tutorial und hilfreiches Referenzwerk in einem - behandelt die Azure-Sicherheitsdienste sowohl auf Anwendungs- als auch auf Netzwerkebene sowie deren Zusammenarbeit - inkl. kostenloser Code-Beispiele zum Download Wenn wichtige Anwendungen und Workloads eines Unternehmens in die Microsoft Azure-Cloud verlagert werden, müssen sie gegen eine Vielzahl von ebenso unterschiedlichen wie gefährlichen Bedrohungen gewappnet werden. Um ihre Sicherheit zu optimieren, ist es erforderlich, dass Sie diese bereits zuverlässig in Ihre Entwürfe einbauen, bewährte Best Practices über die gesamte Entwicklung hinweg anwenden und verschiedene Azure-Dienste kombinieren. In diesem Buch zeigen Ihnen drei führende Azure-Sicherheitsexperten, wie Sie genau das tun. Auf der Grundlage ihrer umfangreichen Erfahrungen mit der Absicherung von Azure-Workloads geben die Autoren Ihnen eine praktische Anleitung zur Bewältigung unmittelbarer Sicherheitsherausforderungen an die Hand sowie eine umfassende Referenz, auf die Sie sich über Jahre hinweg verlassen können. Egal ob Softwarearchitektin, Softwareentwickler oder beim Testen: Integrieren Sie die wichtigsten Azure-Sicherheitstechnologien – von Entwurf und Entwicklung über Tests und Bereitstellung bis hin zu Governance und Compliance. In diesem Buch werden folgende Themen behandelt: - Verbesserung der Anwendungs-/Workload-Sicherheit, Verringerung der Angriffsflächen und Implementierung von Zero Trust im Cloud-Code - Anwendung von Sicherheitsmustern zur einfacheren Lösung gängiger Probleme - Frühzeitige Modellierung von Bedrohungen, um wirksame Abhilfemaßnahmen zu planen - Implementierung moderner Identitätslösungen mit OpenID Connect und OAuth2 - Azure-Monitoring, Protokollierung und Kusto-Abfragen optimal nutzen - Absicherung von Workloads mit den Best Practices von Azure Security Benchmark (ASB) - Prinzipien für sicheren Code, defensiven Code schreiben, unsicheren Code reparieren und Codesicherheit testen - Nutzung von Azure-Kryptographie und Technologien für verschlüsselte Datenverarbeitung - Verstehen von Compliance- und Risikoprogrammen - Sichere automatisierte CI/CD-Workflows und -Pipelines - Verstärkung der Container- und Netzwerksicherheit

Leseprobe

Michael Howard ist derzeit Principal Security Program Manager im Azure Data Platform Team und arbeitet an der Sicherheitstechnik. Er ist einer der ursprünglichen Architekten des Microsoft Security Development Lifecycle und unterstützt verschiedene Kunden aus den Bereichen öffentliche Verwaltung, Militär, Bildung, Finanzen und Gesundheitswesen bei der Sicherung ihrer Azure-Workloads. Er war der Leiter Application Security für die Olympischen Spiele in Rio 2016; die Anwendungen wurden auf Azure gehostet.

Heinrich Gantenbein ist Senior Principal Consultant für Cybersecurity in Microsofts Industry Solutions Delivery. Mit mehr als 30 Jahren Erfahrung in der Softwareentwicklung und in der Beratung bringt er eine Fülle von praktischem Know-how in seine Rolle ein. Heinrich Gantenbein ist spezialisiert auf Azure-Sicherheit, Bedrohungsmodellierung und DevSecOps.

Simone Curzi ist Principal Consultant von Microsofts Industry Solutions Delivery. Er verfügt über mehr als 20 Jahre Erfahrung in verschiedenen technischen Rollen bei Microsoft und hat sich seit mehr als 10 Jahren ganz dem Thema Sicherheit gewidmet. Als anerkannter Experte für Bedrohungsmodellierung und Microsoft Security Development Lifecycle-Experte, ist Simone Curzi ein regelmäßiger Redner auf internationalen Konferenzen wie Microsoft Ready, Microsoft Spark, (ISC)2 Security Congress, Carnegie Mellon’s SEI DevOps Days und Security Kompass Equilibrium. Simone Curzi ist außerdem Autor eines Open-Source-Tools zur Bedrohungsmodellierung, Threats Manager Studio.

Copyright und Urheberrechte:Die durch die dpunkt.verlag GmbH vertriebenen digitalen Inhalte sind urheberrechtlich geschützt. Der Nutzer verpflichtet sich, die Urheberrechte anzuerkennen und einzuhalten. Es werden keine Urheber-, Nutzungs- und sonstigen Schutzrechte an den Inhalten auf den Nutzer übertragen. Der Nutzer ist nur berechtigt, den abgerufenen Inhalt zu eigenen Zwecken zu nutzen. Er ist nicht berechtigt, den Inhalt im Internet, in Intranets, in Extranets oder sonst wie Dritten zur Verwertung zur Verfügung zu stellen. Eine öffentliche Wiedergabe oder sonstige Weiterveröffentlichung und eine gewerbliche Vervielfältigung der Inhalte wird ausdrücklich ausgeschlossen. Der Nutzer darf Urheberrechtsvermerke, Markenzeichen und andere Rechtsvorbehalte im abgerufenen Inhalt nicht entfernen.

Microsoft Azure Security

Bewährte Methoden, Prozesse undGrundprinzipien für das Entwerfenund Entwickeln sicherer Anwendungenin der Cloud

Michael HowardHeinrich GantenbeinSimone Curzi

Michael Howard

Heinrich Gantenbein

Simone Curzi

Übersetzung: Rainer G. Haselier

Lektorat: Sandra Bollenbacher

Lektoratsassistenz: Friederike Demmig

Copy-Editing: Petra Heubach-Erdmann, Düsseldorf

Satz: Gerhard Alfes, mediaService, Siegen, www.mediaservice.tv

Herstellung: Stefanie Weidner

Umschlaggestaltung: Eva Hepper, Silke Braun

ISBN:

Print

978-3-86490-985-6

PDF

978-3-98890-088-3

ePub

978-3-98890-089-0

mobi

978-3-98890-090-6

1. Auflage 2024

Translation Copyright für die deutschsprachige Ausgabe © 2024 dpunkt.verlag GmbH

Wieblinger Weg 17

69123 Heidelberg

Authorized translation from the English language edition, entitled DESIGNING AND DEVELOPING SECURE AZURE SOLUTIONS 1st Edition by HOWARD, MICHAEL; GANTENBEIN, HEINRICH; CURZI, SIMONE published by Pearson Education, Inc, publishing as Microsoft Press © 2023 by Pearson Education.

All rights reserved. No part of this book may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopying, recording or by any information storage retrieval system, without permission from Pearson Education, Inc.

ISBN of the English language edition: 978-0-13-790875-2

German language edition published by DPUNKT.VERLAG GMBH, Copyright © 2024

Hinweis:

Dieses Buch wurde mit mineralölfreien Farben auf PEFC-zertifiziertem Papier aus nachhaltiger Waldwirtschaft gedruckt. Der Umwelt zuliebe verzichten wir zusätzlich auf die Einschweißfolie. Hergestellt in Deutschland.

Schreiben Sie uns:

Falls Sie Anregungen, Wünsche und Kommentare haben, lassen Sie es uns wissen: [email protected]

Die vorliegende Publikation ist urheberrechtlich geschützt. Alle Rechte vorbehalten. Die Verwendung der Texte und Abbildungen, auch auszugsweise, ist ohne die schriftliche Zustimmung des Verlags urheberrechtswidrig und daher strafbar. Dies gilt insbesondere für die Vervielfältigung, Übersetzung oder die Verwendung in elektronischen Systemen.

Es wird darauf hingewiesen, dass die im Buch verwendeten Soft- und Hardware-Bezeichnungen sowie Markennamen und Produktbezeichnungen der jeweiligen Firmen im Allgemeinen warenzeichen-, marken- oder patentrechtlichem Schutz unterliegen.

Alle Angaben und Programme in diesem Buch wurden mit größter Sorgfalt kontrolliert. Weder Autoren noch Verlag noch Übersetzer können jedoch für Schäden haftbar gemacht werden, die in Zusammenhang mit der Verwendung dieses Buches stehen.

5 4 3 2 1 0

Inhaltsverzeichnis

Danksagungen

Vorwort

Einleitung

Teil 1: Sicherheitsgrundsätze

Kapitel 1

Prozesse für sichere Entwicklungszyklen

Entwickler sind die Hauptursache für Kompromittierungen

Einführung in den Microsoft Security Development Lifecycle

Qualität ≠ Sicherheit

Sicherungsmerkmale vs. Sicherheitsmerkmale

SDL-Komponenten

Sicherheitsschulung

Definieren Ihrer Bug Bar, Ihres Klassifizierungsschemas

Analyse der Angriffsfläche

Modellierung von Bedrohungen

Definieren Ihrer Toolchain

Verbotene Funktionalität vermeiden

Werkzeuge zur statischen Analyse verwenden

Dynamische Analysetools verwenden

Code-Review unter Sicherheitsaspekten

Reaktionsplan bei Zwischenfällen haben

Penetrationstests durchführen

SDL-Aufgaben nach Sprint

Das menschliche Element

Zusammenfassung

Kapitel 2

Sicherer Entwurf

Die Cloud, DevOps und Sicherheit

IaaS vs. PaaS vs. SaaS und die gemeinsame Verantwortung

Zero Trust für Entwickler

Nachdenken über sicheres Design

Azure-Entwurfsprinzipien für sichere Systeme

Angriffsfläche reduzieren

Vollständige Zugriffskontrolle

Sicherheit in der Tiefe – Defense in Depth

Einfachheit der Mechanismen

Sichere Standardeinstellungen

Fail Safe und Fail Secure

Minimale gemeinsame Ressourcen

Minimale Berechtigungen

Vorhandene Komponenten nutzen

Offener Entwurf

Psychologische Akzeptanz

Funktionstrennung

Single Point of Failure

Schwächstes Glied

Zusammenfassung

Kapitel 3

Sicherheitsmuster

Was ist ein Muster?

Unsere Meinung zu Azure-Sicherheitsmustern

Das Azure Well-Architected Framework

Authentifizierungsmuster

Zentralisierten Identitätsanbieter für die Authentifizierung verwenden

Autorisierungsmuster

Einführung einer Just-in-Time-Administration

Rollen an Gruppen zuweisen

Vom Internet isolieren

Isolieren mit einem Identitätsperimeter

Rollenbasierte Zugriffssteuerung (RBAC) verwenden

Muster für die Verwaltung von Geheimnissen

Verwaltete Identitäten verwenden

Geheimnisse mit Azure Key Vault schützen

Muster für die Verwaltung vertraulicher Informationen

Sichere Kanäle schaffen

Daten clientseitig verschlüsseln

Bring Your Own Key (BYOK) einsetzen

Verfügbarkeitsmuster

Entwurf für Denial of Service

Zusammenfassung

Kapitel 4

Bedrohungsmodellierung

TL;DR

Was ist Bedrohungsmodellierung?

Die vier Hauptphasen der Bedrohungsmodellierung

Der STRIDE-Ansatz zur Klassifizierung von Bedrohungen

Das Problem mit der Bedrohungsmodellierung

Auf der Suche nach einem besseren Prozess zur Modellierung von Bedrohungen

Ein besserer Weg, Bedrohungsmodelle zu erstellen: Die fünf Faktoren

Tools zur Bedrohungsmodellierung

Bewertung der fünf Faktoren

CAIRIS

Microsoft Threat Modeling Tool

OWASP Threat Dragon

pytm

Threagile

Threats Manager Studio

Wie man ein Bedrohungsmodell erstellt: Ein Praxisbeispiel

Analysieren Sie die Lösung: Das erste Meeting

Analysieren Sie die Lösung: Das zweite Meeting

Identifizierung spezifischer Bedrohungen und Gegenmaßnahmen

Angabe des Schweregrads

Gegenmaßnahmen festlegen

Automatisch zusätzliche Bedrohungen und Gegenmaßnahmen identifizieren

Roadmap erstellen

Das Dashboard verwenden

Ausgewählte Gegenmaßnahmen in das Backlog pushen

Zusammenfassung

Kapitel 5

Identität, Authentifizierung und Autorisierung

Identität, Authentifizierung und Autorisierung unter dem Aspekt der Sicherheit

Authentifizierung vs. Autorisierung vs. Identität

Moderne Identität und Zugriffsmanagement

Identität: Grundlagen von OpenID Connect und OAuth2

OpenID Connect und OAuth2

Anwendung registrieren

Microsoft-Authentifizierungsbibliothek

Rollen in OAuth2

Flows

Clienttypen

Token

Gültigkeitsbereiche, Berechtigungen und Zustimmung

Anatomie eines JSON Web Token (JWT)

OAuth2 in Ihren Azure-Anwendungen verwenden

Authentifizierung

Etwas, das Sie wissen

Etwas, das Sie besitzen

Etwas, das Sie sind

Multi-Faktor-Authentifizierung

Wer authentifiziert wen?

Erstellen einer eigenen Authentifizierungslösung

Die Rolle des einmaligen Anmeldens (Single Sign-On)

Zugriff ohne Authentifizierung erhalten

Authentifizierung von Anwendungen

Autorisierung

Microsoft Entra ID-Rollen und -Bereiche

Integrierte Azure-RBAC-Rollen für die Steuerungsebene

Integrierte Azure-RBAC-Rollen für die Datenebene

Rollenzuweisungen verwalten

Benutzerdefinierte Rollendefinitionen

Zuweisungen ablehnen

Bewährte Verfahren für die Rollenzuweisung

Microsoft Entra ID Privileged Identity Management

Attributbasierte Zugriffssteuerung in Azure

Zusammenfassung

Kapitel 6

Überwachung und Überprüfung

Überwachung, Überprüfung, Protokollierung. Ach du meine Güte!

Die Möglichkeiten der Azure-Plattform nutzen

Diagnoseeinstellungen

Log-Kategorien und Kategoriegruppen

Log Analytics

Kusto-Abfragen

Warnungen auslösen

Schutz von Überwachungsprotokollen

Richtlinien zum Hinzufügen von Überwachungsprotokollen verwenden

Eindämmung der Kosten

Die Notwendigkeit einer gezielten Sicherheitsüberwachung und -überprüfung

Die Rolle der Bedrohungsmodellierung

Benutzerdefinierte Ereignisse

Warnungen für benutzerdefinierte Ereignissen auf Azure Sentinel

Zusammenfassung

Kapitel 7

Governance

Governance und der Entwickler

Microsoft Cloud Security Benchmark Version 1

Netzwerksicherheit

Identitätsmanagement

Privilegierter Zugriff

Datenschutz

Asset-Management

Protokollierung und Bedrohungserkennung

Reaktion auf Vorfälle

Status- und Sicherheitsrisikoverwaltung

Endpunktsicherheit

Sicherung und Wiederherstellung

DevOps-Sicherheit

Governance und Strategie

Durchsetzung der Governance

Durchsetzung durch Prozesse

Governance-Dokumentation und Sicherheitsschulung

Rollenbasierte Zugriffssteuerung

Automatisierte Durchsetzung während der Bereitstellung

Microsoft Defender für Cloud

Sicherheitsbewertung

Überprüfung des Konformitätsstatus für die Lösung

Azure Policy

Azure-Initiativen und Frameworks für die Einhaltung von Vorschriften

Auswirkungen von Azure Policy

Durchsetzungsebenen (Effekte) und RBAC nach Umgebung

Richtlinienzuweisungen

Richtliniendefinitionen als Code

Zusammenfassung

Kapitel 8

Compliance und Risikomanagement

Vorweg: Mögliche Missverständnisse ausräumen

Was ist Compliance?

HIPAA

HITRUST

DSGVO (GDPR)

PCI DSS

FedRAMP

NIST SP 800-53

NIST Cybersecurity Framework

FIPS 140

SOC

ISO/IEC 27001

ISO/IEC 27034

Center for Internet Security Benchmarks

Microsoft Cloud Security Benchmark (MCSB)

OWASP

MITRE

Übersicht zu weiteren Compliance-Programmen

Verwendung von Bedrohungsmodellen zur Erstellung von Compliance-Artefakten

Zusammenfassung

Teil 2: Sichere Implementierung

Kapitel 9

Secure Coding

Unsicherer Code

Regel Nr. 1: All input is evil

Explizit überprüfen

Ermitteln Sie die Korrektheit

Bekannte fehlerhafte Daten ablehnen

Daten codieren

Weitverbreitete Schwachstellen

A01: Fehler in der Zugriffssteuerung

A02: Kryptografische Fehler

A03: Injection

A04: Unsicheres Design

A05: Sicherheitsrelevante Fehlkonfiguration

A06: Veraltete Komponenten mit bekannten Schwachstellen

A07: Fehler in der Identifizierung und Authentifizierung

A08: Integritätsfehler in Software und Daten

A09: Fehler bei der Sicherheitsprotokollierung und -überwachung

A10: Serverseitige Anforderungsfälschung (Server-Side Request Forgery, SSRF)

Anmerkungen zur Verwendung von C++

Schreiben Sie kein glorifiziertes C

Abwehrmaßnahmen im Compiler und Linker verwenden

Analysetools verwenden

Security Review

Ehrlichkeit der Entwickler durch Fuzz-Tests

Erzeugung völlig zufälliger Daten

Mutation vorhandener Daten

Intelligente Manipulation von Daten in Kenntnis ihres Formats

Fuzzing von APIs

Zusammenfassung

Kapitel 10

Kryptografie in Azure

Eine Wahrheit über Sicherheit

Schlüssel absichern

Zugriffssteuerung und Azure Key Vault

Key Vault Premium in der Produktion verwenden

Protokollierung und Auditing aktivieren

Netzwerkisolierung

Microsoft Defender für Key Vault verwenden

Sichern Sie Ihre Key Vault-Assets

Verwaltetes HSM und Azure Schlüsseltresor

Sichere Schlüssel mit Key Vault, eine kurze Zusammenfassung

Kryptografische Agilität

Wie man kryptografische Agilität erreicht

Implementierung von Krypto-Agilität

Krypto-Agilität, eine kurze Zusammenfassung

Das Microsoft Data Encryption SDK

Optionale Parameter

SDK-Schlüssel in Schlüsseltresor verwalten

Azure-Dienste und Kryptografie

Serverseitige Verschlüsselung mit plattformseitig verwalteten Schlüsseln

Serverseitige Verschlüsselung mit kundenseitig verwalteten Schlüsseln

Clientseitige Verschlüsselung

Azure Storage und Kryptografie

Azure VM und Kryptografie

Azure SQL-Datenbank sowie Cosmos DB und Kryptografie

Schlüsselrotation

Azure Key Vault Schlüsselrotation

Schutz von Daten bei der Übertragung

TLS und Krypto-Agilität

Ciphersuiten

TLS in Azure PaaS

Ciphersuiten einstellen

TLS in Azure IaaS

Ein häufiger TLS-Fehler im .NET-Code

TLS testen

Debugging von TLS-Fehlern

Unsichere Verwendung von SSH

Zusammenfassung

Kapitel 11

Confidential Computing

Was ist Confidential Computing?

Prozessoren für Confidential Computing

Intel Software Guard Extensions

AMD Secure Encrypted Virtualization-Secure Nested Paging

Arm TrustZone

VMs der DCsv3-Serie, SGX, Intel Total Memory Encryption und Intel Total Memory Encryption Multi-Key

Attestation

Vertrauenswürdiger Start für Azure-VMs

Azure-Dienste, die Confidential Computing nutzen

SQL Server Always Encrypted

Azure Confidential Ledger

Vertrauliche Container

Zusammenfassung

Kapitel 12

Containersicherheit

Was sind Container?

Hier brauchen Sie keine Container!

Wie geht es jetzt weiter?

Containerbezogene Dienste auf Azure

Container für IaaS-Angebote verwenden

Azure-Containerdienste im Vergleich

Probleme mit Containern

Komplexität

Unausgereiftheit

Fragmentierung

Containerdienste absichern

Entwicklung und Bereitstellung

Die Container Registry

Der Cluster

Die Knoten

Die Pods und Container

Die Anwendung

Zusammenfassung

Kapitel 13

Datenbanksicherheit

Warum Datenbanksicherheit?

Welche Datenbanken?

Über die Sicherheit von Datenbanken nachdenken

Die SQL Server-Familie

SQL Server

Azure SQL-Datenbank

Azure SQL Managed Instance

Sicherheit in der SQL Server-Familie

Authentifizierung auf der Steuerungsebene

Autorisierung auf der Steuerungsebene

Überwachung der Steuerungsebene

Verschlüsselung der Steuerungsebene bei der Übertragung

Netzwerkisolierung auf der Steuerungsebene

Authentifizierung auf der Datenebene

Autorisierung auf der Datenebene

Überwachung der Datenebene

Verschlüsselung auf der Datenebene während der Übertragung

Netzwerkisolierung auf der Datenebene

Kryptografische Maßnahmen für ruhende Daten

Sonstiges

Cosmos DB Sicherheit

Authentifizierung auf der Steuerungsebene

Autorisierung auf der Steuerungsebene

Überwachung der Steuerungsebene

Netzwerkisolierung auf der Steuerungsebene

Authentifizierung auf der Datenebene

Autorisierung auf der Datenebene

Überwachung der Datenebene

Verschlüsselung auf der Datenebene während der Übertragung

Netzwerkisolierung auf der Datenebene

Kryptografische Schutzmaßnahmen für ruhende Daten

Verschiedenes

Verschlüsselung der Daten während der Verarbeitung: Always Encrypted

Always Encrypted

Always Encrypted mit sicheren Enklaven

Cosmos DB und Always Encrypted

SQL Injection

Zusammenfassung

Kapitel 14

CI/CD-Sicherheit

Was ist CI/CD?

CI/CD-Tools

Quellcodesysteme und Lieferkettenangriffe

Sicherheits-Tooling

Ihre Entwickler schützen

Genehmigung von Pull Requests und PR-Hygiene

Funktionstrennung, Übersicht über die geringsten Privilegien

Geheimnisse und Dienstverbindungen

Schutz des Main-Branch in Azure DevOps und GitHub

Schutz der PROD-Bereitstellung in Azure DevOps und GitHub

Sicherung von Bereitstellungsagents

Absicherung von Azure DevOps-Agents

Absicherung von GitHub-Agents

Zusammenfassung

Kapitel 15

Netzwerksicherheit

Azure-Netzwerk-Grundlagen

IPv4, IPv6 in Azure

IPv4-Konzepte

IPv4-Adressen in Azure und die CIDR-Notation

Routing und benutzerdefinierte Routen

Netzwerksicherheitsgruppen

Anwendungssicherheitsgruppen

Zielzonen, Hubs und Spokes

Hubs, Spokes und Segmentierung

Trennung von Umgebungen, VNets und erlaubte Kommunikation

Ingress- und Egress-Kontrollen

Network Virtual Appliances und Gateways

Azure Firewall

Azure Firewall Premium SKU

Azure Web Application Firewalls

API-Management-Gateways

Azure Anwendungsproxy

PaaS und private Netzwerke

Private gemeinsam genutzte PaaS

Dedizierte PaaS-Instanzen

Verwaltete VNets

Agent-basierte Netzwerkbeteiligung

Netzwerke für Azure Kubernetes Service

Ingress-Controller

Egress-Controller mit benutzerdefinierter Route

Private Endpunkte für Kubernetes-API-Server

Cluster-Netzwerkrichtlinien

Das Problem der verwaisten DNS-Einträge

Ein Beispiel

Das Problem der verwaisten DNS-Einträge angehen

Zusammenfassung

Index

Für meine Familie, die Geduld mit mir hatte, als ich ein weiteres Buch schrieb.

– Michael

Mit Liebe zu meiner Frau Denyse, um ihr für ihre Unterstützung zu danken.

– Heinrich

Mit Dankbarkeit und Liebe zu meiner Familie, Silvia, Alice und Viola, die mich unermüdlich erdulden und unterstützen.

– Simone

Danksagungen

Dieses Buch behandelt eine Vielzahl komplexer sicherheitsrelevanter Themen. Beim Schreiben eines Buches müssen wir als Autoren sicherstellen, dass unsere Fakten stimmen und unsere Anleitungen korrekt sind. Dies können wir nur erreichen, indem wir Personen in den Azure-Produktgruppen befragen und indem wir Personen, die Experten auf ihrem jeweiligen Gebiet sind, um Unterstützung bitten. Wir möchten uns daher an dieser Stelle für die Hilfe und Unterstützung der folgenden Personen bei Microsoft bedanken:

Amar Gowda, Amaury Chamayou, Anthony Nevico, Antoine Delignat-Lavaud, Barry Dorrans, Ben Co, Ben Hanson, Ben Oberhaus, Bhuvaneshwari Krishnamurthi, Dan Simon, David Nunez Tejerina, Dhruv Iyer, Eric Beauchesne, Eustace Asanghanwa, Hannah Hayward, Jack Richins, Jakub Szymaszek, Jenny Hunter, Joachim Hammer, Jon Lange, John Lambert, Josh Brown-White, Ken St. Cyr, Kozeta Garrett, Luciano Raso, Mark Simos, Michael McReynolds, Michael Withrow, Mirek Sztajno, Nicholas Kondamudi, Niels Ferguson, Panagiotis Antonopoulos, Pieter Vanhove, Prasad Nelabhotla, Rafael Pazos Rodriguez, Robert Jarret, Rohit Nayak, Run Cai, Sameer Verkhedkar, Shubhra Sinha, Srđan Božović, Steven Gott, Sylvan Clebsch, Taylor Bianchi, Thomas Weiss, Vikas Bhatia und Yuri Diogenes.

Andere Microsoft-Kollegen waren in beratender Funktion tätig und halfen stundenlang bei einigen der komplexeren Teile des Buches. Es sind:

Kyle Marsh, Mark Morowczynski und Bailey Bercik (für Identität); Dave Thaler, Graham Berry und Vikas Bhatia (für Confidential Computing); und Hervey Wilson (für Schlüsseltresor)

Wir haben auch Feedback von Personen außerhalb von Microsoft erhalten, die über spezielles Fachwissen verfügen:

Arun Prabhakar (Boston Consulting Group), Avi Douglen (Bounce Security), Brook S. E. Schoenfield (True Positives, LLC), Dave Kaplan (AMD), David Litchfield (Apple), Donna McCally (HITRUST), Izar Tarandach (Squarespace), Lotfi Ben Othmane (Iowa State University), Mark Bode (AMD), Mark Cox (RedHat), Mark Curphey (Crash Override), Matthew Coles (Dell Technologies), Michael F. Angelo (Micro Focus), Mike Dietz und Robert Seacord (Woven Planet) sowie Shane Gashette und Steve Christey Coley (MITRE)

Wir möchten uns bei unseren technischen Reviewern bedanken, die jeden Aspekt unserer Entwürfe unter die Lupe genommen haben. Die technischen Reviewer waren:

Altaz Valani (Security Compass), Hasan Yasar (Software Engineering Institute, Carnegie Mellon), Jonathan Davis (Microsoft), Mike Becker (Microsoft) und Rick Alba (Microsoft)

Dieses Buch wäre ohne die Mitarbeiter von Pearson/Microsoft Press nicht möglich gewesen:

Loretta Yates, die »ja« gesagt hat; Charvi Arora, die uns dazu gebracht hat, unsere Termine einzuhalten; und schließlich Kate Shoup, die unseren Text hervorragend redigiert hat und dabei unseren Ton und unsere inhaltlichen Intentionen beibehalten hat.

Schließlich möchten wir Scott Guthrie für das Schreiben des Vorworts und für die Leitung des großartigen Teams von Microsoft Azure danken.

Michael Howard

Austin, Texas

Heinrich Gantenbein

St. Paul, Minnesota

Simone Curzi

Perugia, Italien

Vorwort

Im vergangenen Jahrzehnt haben wir einen dramatischen Wandel in der Art und Weise erlebt, wie Unternehmen Technologie nutzen, um ihre Geschäftsabläufe völlig neu zu erfinden und zu verändern. Die jüngsten globalen Herausforderungen und unvorhersehbare, weitreichende Ereignisse haben diesen Wandel nur noch beschleunigt, und die Unternehmen mussten sich neu orientieren und anpassen, um die Bedürfnisse ihrer Kunden und Mitarbeiter zu erfüllen und die Widerstandsfähigkeit ihres Unternehmens sicherzustellen.

Diese digitale Transformation wurde zum Teil durch technologische Fortschritte und Hyperscale-Cloudanbieter wie Microsoft Azure ermöglicht, die Unternehmen die nötige Flexibilität bieten, um neue Effizienzen und Fähigkeiten zu realisieren. In dieser Ära der beispiellosen Transformation, einschließlich der Migration in die Cloud, gibt es jedoch auch neue Bedrohungen und Anforderungen an die Sicherheit und den Datenschutz.

Wenn Menschen an Sicherheit denken, denken sie oft an Endpunktschutz, Firewalls und Anti-Malware-Tools, die von entscheidender Bedeutung sind; aber Architekten und Entwickler können die Anwendungssicherheit während des Designs und der Entwicklung nicht ignorieren. Dieses Buch, »Microsoft Azure Security«, ist eine unverzichtbare Ressource für das Verständnis der wesentlichen Elemente eines durchgängig sicheren Softwaredesigns und der Entwicklung auf Azure. Es behandelt zwei Bereiche, die mir sehr am Herzen liegen – die Sicherheit von Azure und die Softwareentwicklung.

Die Microsoft Cloud bietet viele Zuverlässigkeits- und Sicherheitsvorteile im Vergleich zu On-Premises-Lösungen, aber Architekten und Entwickler können grundlegende Sicherheitspraktiken nicht ignorieren, wenn sie auf Azure bereitstellen. Cloudbasierte Lösungen verwenden ein Modell der geteilten Verantwortung, und ein Teil der Sicherheitsverantwortung liegt sowohl beim Mandanten als auch beim Cloudanbieter. »Microsoft Azure Security« bietet eine ganzheitliche und leicht zugängliche Ressource für jeden, der sichere Workloads auf Azure entwickelt. Leser, die an Azure-Lösungen arbeiten, erhalten ein zeitgemäßes Verständnis für sichere Entwicklung, Design und Implementierung.

Die Autoren Michael, Heinrich und Simone verfügen zusammen über jahrzehntelange Erfahrung im Bereich der Anwendungssicherheit. Sie haben mit öffentlichen Auftraggebern und Unternehmen – großen und kleinen – zusammengearbeitet, die alle in der Lage waren, sichere Lösungen auf Azure zu entwerfen, zu entwickeln, bereitzustellen und zu verwalten. Ich weiß, dass die Autoren sich dafür einsetzen, allen, die auf Azure entwerfen und entwickeln, dabei zu helfen, die Zuverlässigkeit, Skalierbarkeit und Sicherheit zu erreichen, die von ihren Organisationen und Endbenutzern gefordert werden.

Dieses Buch ist ein unverzichtbarer Leitfaden für jeden Architekten und Entwickler, der sichere, geschäftskritische Lösungen auf Azure bereitstellt.

Scott Guthrie

Executive Vice President

Cloud + AI-Gruppe, Microsoft

Einleitung

Mitte 2021, während einer Aufzeichnung des Azure-Security-Podcasts, wurde Michael Howard vom Azure-Sicherheitsexperten und Autor Yuri Diogenes gefragt, ob er plane, ein Update zu seinem Buch »The Security Development Lifecycle« zu schreiben. Ohne zu zögern, antwortete Michael: »Nein!«

Doch damit war die Angelegenheit noch nicht erledigt.

Die Frage, die Yuri Diogenes stellte, legte den Grundstein. In den nächsten Wochen schmiedeten wir drei – Michael, Heinrich und Simone – einen Plan, um dieses Buch zu schreiben. Gemeinsam haben wir mit Hunderten von Kunden zusammengearbeitet, um ihnen dabei zu helfen, geschäftskritische Lösungen auf Azure zuverlässig einzusetzen. Dieses Buch ist die Krönung dieser praktischen Erfahrung.

Wir haben dieses Buch nicht nur geschrieben, um Ihnen zu zeigen, wie Sie sichere Lösungen auf Azure entwerfen und entwickeln können, sondern auch, um Ihnen pragmatische Ratschläge zu geben. Das in Abbildung E-1 dargestellte Venn-Diagramm zeigt, wie wir dieses Buch sehen.

Abbildung E-1Der Schnittpunkt der in diesem Buch behandelten Themenbereiche

Einige Bereiche von Azure werden nicht behandelt, da dieses Buch sonst zu einem ziemlichen Wälzer werden würde. Insbesondere behandeln wir keine Themen wie die folgenden:

Privileged Access Workstation (PAW)

Eine Arbeitsstation mit privilegiertem Zugriff ist eine Arbeitsstation, die nur für administrative Aufgaben vorgesehen ist. Sie hat keinen Zugriff auf E-Mail, allgemeines Web-Browsing und andere Produktivitätsaufgaben. PAWs werden von Konten mit erhöhten Berechtigungen verwendet, um Aktionen in Umgebungen mit hohem Risiko durchzuführen, zum Beispiel in der Produktion, bei der Kontenverwaltung und in anderen Bereichen. Mehr über PAWs erfahren Sie hier:

https://learn.micro-soft.com/azure-stack/ruggedized/customer-replaceable-unit/privileged-access-workstation

.

Bedingter Zugriff und Multi-Faktor-Authentifizierung (MFA)

Diese Aufgaben werden häufig von einem Identitätsteam übernommen, und die Infrastruktur sollte bereits vorhanden sein. Bedingter Zugriff und MFA sind jedoch entscheidend für die Sicherheit einer Azurebasierten Lösung. Hier erfahren Sie mehr zu diesem Thema:

https://learn.microsoft.com/azure/active-directory/conditional-access/overview

.

Datenschutz

Dies ist ein Buch über Sicherheit. Obwohl sich Sicherheit und Datenschutz überschneiden, geht es bei der Sicherheit hauptsächlich darum, ein System und seine Daten gegen unbefugte Nutzung zu schützen, während es beim Datenschutz um den Umgang mit personenbezogenen Daten geht. Man kann Sicherheit ohne Datenschutz haben, aber es gibt keinen Datenschutz ohne Sicherheit.

Wir haben uns relativ kurzgefasst, indem wir viele Links zu externen Informationen eingefügt haben, anstatt einige Themen in diesem Buch ausführlich zu behandeln.

Wie ist dieses Buch organisiert?

Dieses Buch ist nicht dazu gedacht, von vorne bis hinten gelesen zu werden. Das können Sie natürlich tun, aber wir haben versucht, die Kapitel so unabhängig wie möglich zu gestalten, damit sie auch einzeln gelesen werden können. Dennoch gibt es Querverweise zwischen den Kapiteln, und es kann sein, dass Sie manchmal einen Abschnitt eines anderen Kapitels lesen müssen, um das Gesamtbild zu verstehen.

Außerdem werden im Buch mehrere Möglichkeiten zur Erledigung einer Aufgabe beschrieben, wie die folgenden:

Verwendung des Azure-Portals (obwohl es nicht üblich ist, das Azure-Portal in Produktionssystemen zu verwenden, da die Bereitstellung in der realen Welt in der Regel eine Pipeline nutzt, um Ressourcen zu pushen)

Verwendung der Azure-Befehlszeilenschnittstelle (Command-line Interface, CLI)

Verwendung von PowerShell-Code

Verwendung vollständigerer Code-Beispiele in verschiedenen Sprachen wie C#, Python, JavaScript und anderen

Wir haben Codebeispiele und Schnipsel in unser GitHub-Repository unter https://github.com/AzureDevSecurityBook hochgeladen, besuchen Sie es also regelmäßig. Lokalisierte Versionen der Begleitdateien sind auf der Produktseite des Buches verfügbar: https://dpunkt.de/produkt/microsoft-azure-security

Wer sollte dieses Buch lesen?

Für wen ist dieses Buch gedacht? Es richtet sich an alle, die Lösungen auf Azure bereitstellen – seien es Architekten, Entwickler oder Tester –, die vielleicht nicht viel über Sicherheit wissen, aber möchten, dass ihr Design und ihr Code so sicher wie möglich sind. Wir decken in diesem Buch viel ab, aber wir gehen auch auf viele komplexe Themen ein.

Ein letzter Punkt: Wenn Sie das NIST Cybersecurity Framework (NIST CSF) verwenden, dann sind Sie mit dessen Kernkomponenten vertraut: Identifizieren, Schützen, Erkennen, Reagieren und Wiederherstellen (identify, protect, detect, respond, recover). Das Material in diesem Buch konzentriert sich hauptsächlich auf die Komponente Schützen und einige Aspekte der Komponente Erkennen. Wenn Sie für den produktiven Einsatz gedachte Lösungen auf Azure einführen möchten, muss Ihr Unternehmen die anderen vier Komponenten des NIST CSF abdecken. Weitere Informationen über das NIST CSF finden Sie in Kapitel 8, »Compliance und Risikomanagement«, und auf der NIST-Website unter https://azsec.tech/81t.

Vielen Dank fürs Lesen!

Konventionen und Features in diesem Buch

In diesem Buch werden die Informationen unter Verwendung von Konventionen dargestellt, die die Informationen lesbar und leicht nachvollziehbar machen sollen:

Umrandete Elemente mit Beschriftungen wie

Hinweis

liefern zusätzliche Informationen.

Text, den Sie eingeben (außer Codeblöcken), erscheint fett.

Ein Pluszeichen (+) zwischen zwei Tastennamen bedeutet, dass Sie diese Tasten gleichzeitig drücken müssen. Zum Beispiel bedeutet: »Drücken Sie «, dass Sie die -Taste gedrückt halten, während Sie die -Taste drücken.

Ein vertikaler Balken zwischen zwei oder mehr Menüpunkten (z. B.

Datei

|

Schließen

) bedeutet, dass Sie das erste Menü oder den ersten Menüpunkt auswählen, dann das nächste und so weiter.

Systemvoraussetzungen

Die Beispiele und Szenarien in diesem Buch erfordern den Zugang zu einem Microsoft Azure-Abonnement und einen Computer, der eine Verbindung zu Azure herstellen kann. Weitere Informationen über ein Probeabonnement finden Sie auf dieser Website:

azure.microsoft.com/free

GitHub-Repo

Das GitHub-Repository des Buches enthält den englischsprachigen Beispielcode und Codeschnipsel; die Autoren werden es im Laufe der Zeit aktualisieren. Das Repository lautet github.com/AzureDevSecurityBook.

Lokalisierte Versionen der Begleitdateien sind auf der Produktseite des Buches verfügbar:

https://dpunkt.de/produkt/microsoft-azure-security

Errata und Support

Wir haben alle Anstrengungen unternommen, um die Richtigkeit dieses Buches und der dazugehörigen Inhalte zu gewährleisten. Sie können auf Aktualisierungen dieses Buches – in Form einer Liste der eingereichten Errata und der damit verbundenen Korrekturen – unter folgender Adresse zugreifen:

MicrosoftPressStore.com/SecureAzureSolutions/errata

Wenn Sie einen Fehler entdecken, der noch nicht aufgeführt ist, teilen Sie uns diesen bitte auf der gleichen Seite mit.

Weitere Unterstützung und Informationen zu Büchern finden Sie unter

MicrosoftPressStore.com/Support.

Mit Anmerkungen, Fragen oder Verbesserungsvorschlägen auf Deutsch zu diesem Buch können Sie sich auch an den dpunkt.verlag wenden:

[email protected]

Bitte beachten Sie, dass der Produktsupport für Microsoft-Software und -Hardware nicht über die oben genannten Adressen angeboten wird. Hilfe zu Microsoft-Software oder -Hardware finden Sie unter support.microsoft.com.

TEIL 1

Sicherheitsgrundsätze

KAPITEL 1

Prozesse für sichere Entwicklungszyklen

KAPITEL 2

Sicherer Entwurf

KAPITEL 3

Sicherheitsmuster

KAPITEL 4

Bedrohungsmodellierung

KAPITEL 5

Identität, Authentifizierung und Autorisierung

KAPITEL 6

Überwachung und Überprüfung

KAPITEL 7

Governance

KAPITEL 8

Compliance und Risikomanagement

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.

Dieses Kapitel beschäftigt sich sowohl mit dem Prozess und den menschlichen Aspekten der Praktiken für die Softwareentwicklung; aber auch die technischen Aspekte kommen nicht zu kurz. Das Ziel ist, wie erwähnt, bei der Bereitstellung von sicheren Softwarelösungen so reibungslos zu sein wie möglich.

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.

Um Ihr Wissen zu vervollständigen, empfehlen wir Ihnen, die vollständige Liste der SDL-Anforderungen zu lesen, die Sie hier finden:https://www.microsoft.com/securityengineering/sdl/practices.

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.

Kurz, Sie müssen sich auf die Disziplin der Softwareentwicklungssicherheit konzentrieren. Sie können diese Verantwortung nicht auf ein Produkt abwälzen.

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.

Agile SDL

Sie werden vielleicht denken, dass diese Liste mit Anforderungen vor allem für ein Wasserfallmodell gilt. Tatsächlich handelt es sich aber nur um eine Liste von Aufgaben, die erledigt werden müssen; sie gibt nicht an, wann Sie sie erledigen müssen. Es kann sein, dass Sie nur einen Sprint damit verbringen, an einigen Aufgaben zu arbeiten, und diese Arbeit wird dann für alle zukünftigen Sprints gelten. Wir werden erläutern, wie man jede dieser Aufgaben in einer agilen Umgebung am besten anwendet.

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 schlankeres Schulungsmodell, das eher bereichsspezifisch ist. So verlangen wir zum Beispiel von unseren technischen Mitarbeitern, dass sie sicherheitsrelevante Kurse besuchen, die sich auf ihre Rolle beziehen, anstatt eine allgemeine Schulung zu absolvieren.

Wenn ein Entwickler beispielsweise serverseitigen Node.js-JavaScript-Code für eine Webanwendung schreibt, muss er Cross-Site-Scripting-Probleme (XSS), die sichere Verwendung von Cookies und andere Web- und HTTP-bezogene Sicherheitsprobleme und Abwehrmaßnahmen verstehen. Wenn dieselbe Anwendung mit einer SQL-Datenbank kommuniziert, sind solide Kenntnisse über SQL Injection, Datenbankverbindungen mit geringsten Rechten und das sichere Speichern von Verbindungszeichenfolgen ebenfalls wichtig. Es ist jedoch sehr wahrscheinlich, dass dieser Entwickler die potenziellen Probleme der Speicherbeschädigung bei der Verwendung von strcpy() in C nicht verstehen muss. Er könnte also einfach lesen, ein Video ansehen oder eine Onlineschulung zu den für ihn wichtigen Themen absolvieren.

Es gibt mehrere Schulungsmodi, daher sollten Sie den Modus wählen, der für Sie als Entwickler, Architekt oder Tester am besten geeignet ist. Unterschätzen Sie jedoch nie den Wert eines kurzen Videos, das den Kern des Problems auf den Punkt bringt!

Aus agiler Sicht sollte es niemandem erlaubt werden, an einem Sprint mitzuarbeiten, solange er nicht über ein Grundniveau an Wissen über Sicherheit verfügt. Vergewissern Sie sich, dass alle Mitglieder des Entwicklungsteams über die Anforderungen des Unternehmens an die Erstellung sicherer Software informiert sind. Wenn es in Ihrem Unternehmen keine Liste der empfohlenen Ressourcen für den Entwurf und die Entwicklung sicherer Anwendungen gibt, sollten Sie eine erstellen. Sie könnten sogar in Erwägung ziehen, dieses Buch zur Pflichtlektüre für alle Ihre technischen Mitarbeiter zu machen.

Praktische Erfahrungen: »Pflichtlektüre«

Als Michael (Howard) zusammen mit David LeBlanc »Writing Secure Code« (die deutsche Ausgabe erschien unter dem Titel »Sichere Software programmieren«) schrieb, las Bill Gates das Buch und erklärte die zweite Auflage zur Pflichtlektüre bei Microsoft. Dadurch wurde der kollektive Sicherheits-IQ im gesamten Unternehmen schnell erhöht.

Definieren Ihrer Bug Bar, Ihres Klassifizierungsschemas

Nicht alle Sicherheitslücken sind gleich; die Festlegung einer Methode zur Berechnung des Schweregrads Ihrer Sicherheitslücken ist entscheidend. Es gibt viele Möglichkeiten, den Schweregrad zu berechnen, aber die gängige Methode ist das Common Vulnerability Scoring System (CVSS). Laut NIST ist das CVSS »ein offenes Framework für die Kommunikation der Merkmale und des Schweregrads von Softwareschwachstellen«. Das CVSS gibt das mit einer bestimmten Schwachstelle verbundene Risiko anhand einer numerischen Punktzahl an, die von 1 (niedrig) bis 10 (kritisch) reicht.

First.org stellt eine Liste von CVSS-Beispielen zur Verfügung, mit deren Hilfe Sie lernen können, wie man Schwachstellen bewertet. Sie finden sie hier: https://azsec.tech/wt7.

Kapitel 8, »Compliance und Risikomanagement«, behandelt CVSS ausführlich. Im Moment ist es wichtig, dass Sie definieren, was die CVSS-Risiko-Scores für Sie bedeuten. Nehmen wir zum Beispiel an, Sie sind dabei, einen Code in die Produktion zu überführen, aber Sie stellen fest, dass er eine Sicherheitslücke mit einem CVSS-Score von 7,3 enthält. Was sollten Sie tun? Hätte dieselbe Schwachstelle einen CVSS-Wert von 1,7, wäre es ein Bug mit geringem Risiko – kein Fehler, der Sie davon abhalten sollte, den Code in Produktion zu geben, sondern etwas, das Sie wahrscheinlich irgendwann einmal beheben sollten. Ein Wert von 7,3 stellt eher ein Dilemma dar. Sollten Sie den Code in die Produktion überführen und den Fehler danach schnell beheben? Oder sollten Sie die Bereitstellung um ein oder zwei Tage verschieben, um die Fehlerbehebung sofort vorzunehmen und sie vorher zu testen? Es ist eine schwierige Entscheidung, aber im Allgemeinen ist es am besten, nach dem Motto »Vorsicht ist die Mutter der Porzellankiste« zu handeln.

Obwohl CVSS weit verbreitet ist, gibt es einen gewissen Druck, in der agilen Entwicklung andere Methoden einzusetzen. Jedoch hat sich keine Methode herauskristallisiert, die CVSS verdrängen könnte. Es gibt eine ausgezeichnete Abhandlung zu diesem Thema: https://azsec.tech/1zh.

Zur Risikobewertung hat Microsoft in der Vergangenheit einen Bug Bar-Ansatz verwendet. Eine Bug Bar enthält eine Reihe von Bedingungen und das relative Schadenspotenzial der einzelnen Bedingungen. Viele dieser Bedingungen beziehen sich auf die Angriffsfläche (siehe nächster Abschnitt), denn je anfälliger eine potenzielle Sicherheitslücke ist, desto schwerwiegender könnte sie sein.

Ein Beispiel für eine Microsoft Bug Bar finden Sie hier: https://learn.microsoft.com/previous-versions/windows/desktop/cc307404(v=msdn.10)?redirectedfrom=MSDN.

Die Idee hinter einer Bug Bar ist, dass Sie nur die Bedingungen innerhalb der Umgebung bewerten, um zu einer allgemeinen »T-Shirt-Größe« zu gelangen. Microsoft verwendet die folgenden T-Shirt-Größen sowohl intern als auch für externe Patches:

Kritisch

Eine kritische Schwachstelle ist eine Schwachstelle, deren Ausnutzung die Ausführung von Code ohne Benutzerinteraktion ermöglichen könnte.

Wichtig

Eine wichtige Schwachstelle ist eine Schwachstelle, deren Ausnutzung zu einer Beeinträchtigung der Vertraulichkeit, Integrität oder Verfügbarkeit von Benutzerdaten oder der Integrität oder Verfügbarkeit von Verarbeitungsressourcen führen könnte.

Mäßig

Die Auswirkungen einer als mäßig eingestuften Schwachstelle können in erheblichem Maße gemildert werden, indem eine Authentifizierung verlangt wird, die die zugehörige Komponente nur auf nicht standardmäßige Konfigurationen anwendet.

Niedrig

Die Auswirkungen einer niedrig eingestuften Sicherheitsanfälligkeit werden durch die Eigenschaften der betroffenen Komponente umfassend gemildert. Microsoft empfiehlt seinen Kunden, zu prüfen, ob sie das Sicherheitsupdate auf die betroffenen Systeme anwenden sollen.

Abbildung 1-1 und Abbildung 1-2 zeigen die Hauptkomponenten einer Bug Bar. Beachten Sie, dass das in Abbildung 1-1 gezeigte Diagramm zu dem in Abbildung 1-2 gezeigten führt; wir haben dies getan, um das Schema besser lesbar zu machen.

Abbildung 1-1Der erste Schritt eines Beispiels für eine Bug Bar mit Schwerpunkt auf der Schwachstellenklasse und der Authentifizierungsstufe

Abbildung 1-2Der zweite Schritt eines Beispiels für eine Bug Bar, der sich auf Autorisierung und kryptografische Schutzmechanismen konzentriert und bei dem der Endknoten von der jeweiligen Schwachstellenklasse abhängt

Beim obersten Knoten, Schwachstellenklasse, handelt es sich um eine der STRIDE-Kategorien. Diese werden in Kapitel 4, »Bedrohungsmodellierung«, ausführlich erläutert. Kurz ausgedrückt, ist STRIDE ein Akronym für eine Reihe von Schlüsselzielen der Angreifer, die wie folgt lauten:

Spoofing (Identitätsverschleierung)

Nachahmung einer anderen Person, zum Beispiel eines Benutzers oder eines Computers

Tampering (Manipulation)

Ändern von Daten oder Code ohne entsprechende Berechtigung

Repudiation (Verleugnung)

Rückgängigmachung oder Verschleierung einer Transaktion

Information disclosure (Offenlegung von Daten, Datenpanne)

Einsichtnahme in Daten ohne ordnungsgemäße Genehmigung

Denial of Service (DoS, Dienstverweigerung)

Beeinträchtigung oder Verhinderung des Funktionierens eines Dienstes

Elevation of privilege (Erhöhung der Berechtigungen)

Erlangung von Privilegien, die man normalerweise nicht hätte

Angenommen, in einem Azure-Blob-Speicherkonto befinden sich vertrauliche Daten und Sie möchten das potenzielle Risiko berechnen, das entsteht, wenn ein Angreifer die Daten liest. Wenn Sie die in Abbildung 1-1 und Abbildung 1-2 gezeigten Bug Bar von oben nach unten durchgehen, ergibt sich das folgende (pathologisch schlechte) Szenario:

Schwachstellenklasse

Offenlegung von Informationen

Clientauthentifizierung

Keine (das heißt, der Blob ist auf anonymen Zugriff eingestellt)

Zugriffssteuerung/Berechtigung

Keine (das heißt, es gibt keine Shared Access Signature [SAS]-Token oder rollenbasierte Zugriffssteuerungsmechanismen [RBAC] für die Datenebene)

Datenverschlüsselung

Keine

Vertraulichkeit der Daten

Hoch

Der letzte Punkt, die Vertraulichkeit der Daten, ist spezifisch für die Schwachstellenklasse der Offenlegung von Informationen, da es bei dieser Art von Sicherheitslücke um die Vertraulichkeit der Daten geht.

Diese Reihe von katastrophalen Zuständen ist sicherlich ein Beispiel für ein kritisches Problem (also eine bestimmte T-Shirt-Größe). Tatsächlich muss man sich fragen, wie es überhaupt dazu kommen konnte. Wie auch immer, Sie müssen das Problem schnell beheben.

In einer agilen Umgebung brauchen Sie eine Möglichkeit, den Schweregrad von Sicherheitslücken zu berechnen, bevor Sie mit der Codeerstellung beginnen. Wenn Sie keine haben, müssen Sie schnell eine definieren – und dafür sorgen, dass jeder weiß, wie sie zu verwenden ist. Das bereits erwähnte Beispiel des Microsoft-Klassifizierungsschemas unter https://learn.microsoft.com/previous-versions/windows/desktop/cc307404(v=msdn.10)?redirectedfrom=MSDN deckt spezifische Probleme ab, die den Schweregrad einer bestimmten Schwachstelle beeinflussen könnten, und ist somit eine gute Ressource für die Entwicklung Ihres eigenen Ansatzes zur Berechnung des Schweregrads von Schwachstellen.

Betrachten wir nun ein anderes Szenario mit diesen Parametern:

Schwachstellenklasse

Offenlegung von Informationen

Clientauthentifizierung

Microsoft Entra ID-Authentifizierung

Während der Arbeiten an der deutschen Ausgabe dieses Buches veröffentlichte Microsoft eine Pressemitteilung, in der die Umbenennung von Azure Active Directory in Microsoft Entra ID angekündigt wurde. Wir haben daher den Text des Buches und so weit uns möglich auch die Links im Buch angepasst. Weitere Informationen über diese Namensänderung finden Sie hier: https://learn.microsoft.com/azure/active-directory/fundamentals/new-name.

Zugriffssteuerung/Berechtigung

RBAC auf der Datenebene, die den Zugriff auf eine kleine Gruppe von vertrauenswürdigen Benutzern beschränkt

Datenverschlüsselung

Clientseitige Verschlüsselung mit in Azure Key Vault verwalteten Schlüsseln und einer RBAC-Richtlinie, die den Zugriff auf die Schlüssel einschränkt

Vertraulichkeit der Daten

Hoch

Obwohl die Vertraulichkeit der Daten in diesem Szenario immer noch hoch ist, handelt es sich um ein Szenario mit geringem Risiko, das in der Tat ein gutes Design darstellt. Natürlich gibt es so etwas wie »kein Risiko« nicht. Es gibt immer ein Risiko. Aber in diesem Szenario ist das Risiko akzeptabel.

Analyse der Angriffsfläche

In Kapitel 9, »Secure Coding«, wird die Analyse der Angriffsfläche ausführlicher behandelt. Für den Moment genügt es zu wissen, dass es sich um eine Methode handelt, um festzustellen, wie anfällig Ihre Anwendung für Angreifer ist.

Ihr Ziel ist es natürlich, die Angriffsfläche so weit wie möglich zu minimieren. Die beiden Hauptachsen für die Bestimmung der Angriffsfläche sind wie folgt:

Erreichbarkeit des Netzes

Grad der Authentifizierung

Die Verringerung der Angriffsfläche stellt in der Cloud ein interessantes Problem dar, da Plattform-as-a-Service-Angebote (PaaS) standardmäßig über das Internet zugänglich sind. Aus diesem Grund gibt es Technologien wie private Endpunkte, die dazu beitragen, die Netzwerkerreichbarkeit des Dienstes zu isolieren und zu reduzieren. Durch die Hinzufügung einer angemessenen Authentifizierung und Autorisierung wird auch die Anfälligkeit eines Dienstendpunkts für Angreifer verringert. Ein Endpunkt (beispielsweise ein REST-Endpunkt), der ohne Authentifizierung oder Autorisierung über das Internet zugänglich ist, bietet eine wesentlich größere Angriffsfläche als derselbe Endpunkt, der nur von einer Untergruppe von IP-Adressen aus zugänglich und bei dem für den Zugriff eine Authentifizierung erforderlich ist.

Unabhängig davon, ob Sie agile Entwicklungsmethoden verwenden oder nicht, sollten Sie sich immer fragen, wie groß die Angriffsfläche für alle Ihre Endpunkte ist. Sie müssen auch festlegen, wie die Netzwerk-, Authentifizierungs- und Autorisierungsrichtlinien aussehen sollen und wie sie durchgesetzt werden. Microsoft bietet ein Tool zur Analyse von Angriffsflächen namens Attack Surface Analyzer an, das Ihnen eine Vorstellung davon vermitteln kann, wie die Windows-Plattform Angriffsflächen misst, und das Sie hier kennenlernen können: https://azsec.tech/p0r. In einer Azure-Umgebung ist dies immer noch nützlich, wenn Sie Ihren Code in IaaS-Windows-VMs bereitstellen.

Sie sollten sich bemühen, Ihre Angriffsfläche so klein wie möglich zu halten – und sie dann noch weiter zu verringern!

Modellierung von Bedrohungen

Dieses Buch enthält ein ganzes Kapitel über die Modellierung von Bedrohungen (Kapitel 4), weshalb wir hier nicht im Detail darauf eingehen werden. Es genügt zu erwähnen, dass die Bedrohungsmodellierung eine äußerst wichtige Methode für sicheres Softwaredesign darstellt. Wenn Sie in einer agilen Umgebung eine Anwendung erstellen, müssen Sie ein Bedrohungsmodell entwickeln, sobald dies möglich ist, und es bei Bedarf anpassen, wenn Sie der Anwendung neue Funktionen hinzufügen. Auf diese Weise können Sie sicherstellen, dass die entsprechenden Abhilfemaßnahmen getroffen werden.

Definieren Ihrer Toolchain

Die Toolchain ist ein Satz von Werkzeugen, die für die Softwareentwicklung verwendet werden. Sie umfasst alles, vom Editor bis hin zu Ihren Compilern, Linkern, Bibliotheken und Bug-Tracking-Tools. Wenn Sie bei der Softwareentwicklung agile Methoden verwenden, müssen Sie Ihre Toolchain definieren und festlegen, welche Optionen Sie zur Unterstützung der Sicherheit einsetzen wollen. In diesem Abschnitt werden einige dieser Werkzeuge vorgestellt. Technisch gesehen umfasst die Toolchain auch statische und dynamische Analysewerkzeuge, auf die wir jedoch etwas weiter hinten in diesem Kapitel eingehen werden.

Für die Entscheidung, welche Toolchain-Versionen zu verwenden sind, benötigen Sie möglicherweise jemanden, der sich in diesem Bereich auskennt, da dies spezielle Kenntnisse erfordern kann.

In den meisten Fällen sind Editoren eine persönliche Vorliebe und haben nur sehr geringe Auswirkungen auf die Sicherheit. Einige Editoren bieten jedoch eine bessere Unterstützung für sicherheitsrelevante Plug-ins, wie zum Beispiel Linting-Tools. Ein Beispiel ist Microsofts DevSkim (https://azsec.tech/4lt), das mit Visual Studio und Visual Studio Code arbeitet. Apropos Visual Studio: Es verfügt auch über zahlreiche leichtgewichtige Tools, die auf der Rosyln-Compiler-plattform (https://learn.microsoft.com/dotnet/csharp/roslyn-sdk) basieren und in den Editor integriert werden können. Beispiele sind die folgenden:

Roslynator (

https://azsec.tech/ia0

)

SonarAnalyzer (

https://azsec.tech/0ws

)

GitHub Advanced Security (

https://github.com/advanced-security

)

Compiler und Linker werden häufig aktualisiert, um neue Sicherheitsmaßnahmen zu ergänzen. (Dies gilt insbesondere für C- und C++-Compiler.) So enthält beispielsweise .NET 6 und höher in der zugrunde liegenden Infrastruktur und den Bibliotheken neue Schutzmechanismen gegen Speicherkorruption namens W^X (kurz für Write XOR eXecute). Sie erhalten dieses Feature kostenlos, indem Sie einfach die neuere Version verwenden. (Weitere Informationen über einige der neueren Abwehrmechanismen von .NET 6 finden Sie unter https://learn.microsoft.com/dotnet/core/whats-new/dotnet-6#security.)

Wenn es möglich ist, eine Compiler-Version zu verwenden, die entweder standardmäßig oder durch Einsatz eines Compiler- oder Linker-Flags Sicherheitsvorkehrungen enthält, dann sollten Sie diese nutzen. Dies gilt auch für Frameworks und Bibliotheken. Sie sollten immer die Werkzeuge verwenden, die sichereren Code erzeugen. (Kapitel 9 befasst sich ausführlicher mit der Programmierung von sicherem Code.)

Die Nachverfolgung von Bugs ist ein weiterer wichtiger Teil der Toolchain. Alle Sicherheitsprobleme müssen als Typ=Sicherheitsproblem oder auf eine andere Weise gekennzeichnet werden, um anzuzeigen, dass das Problem als wichtig zu behandeln ist. Auf diese Weise können Sie auch die Entwicklung Ihrer Sicherheitslücken im Laufe der Zeit verfolgen. Idealerweise ist der Trend rückläufig!

Verbotene Funktionalität vermeiden

Bestimmte Funktionalitäten sind einfach schlecht – nicht nur unsicher, sondern schlichtweg schlecht – und sollten niemals verwendet werden. Beispiele hierfür sind schwache kryptografische Algorithmen, unsichere Methoden und unsichere Bibliotheken.

Beispiele für verbotene kryptografische Algorithmen mit bekannten praktischen Schwachstellen sind die folgenden:

MD4, MD5, SHA-1

RC4, DES, 3DES, Rijndael

Electronic Code Book (ECB) Blockverschlüsselungen

Tabelle 1-1 enthält weitere Beispiele für verbotene Funktionalitäten.

Funktionskategorie

Verbotene Funktionalität

JavaScript-Funktionen und -Methoden

eval

execScript

setTimeout, wenn als erstes Argument eine Zeichenfolge verwendet wird (es ist okay, diese Methode mit einer direkten Funktionsreferenz zu verwenden)

setInterval, wenn als erstes Argument eine Zeichenfolge verwendet wird (siehe setTimeout)

setImmediate, wenn als erstes Argument eine Zeichenfolge verwendet wird (siehe setTimeout)

Java-Funktionen und -Methoden

java.lang.System.runFinalizersOnExit

java.lang.Runtime.runFinalizersOnExit

C-Funktionen

strcpy, strcat

strncpy, strncat

gets

sprint

vsprintf

memcpy

Zu viele, um sie alle aufzuführen!

Tabelle 1-1Beispiele für verbotene Funktionalität

Sie können verbotene Funktionalitäten in C abfangen, indem Sie die Headerdatei banned.h verwenden, die in Michaels GitHub-Repository zur Verfügung steht, das Sie hier finden: https://github.com/x509cert/banned.

Außerdem sollte jede Funktion, die schwache Pseudozufallszahlen erzeugt, verboten werden, wenn die Ausgabe für kryptografische Zwecke verwendet wird. Zum Beispiel:

C

rand()

Java

java.lang.Math.random()

C#

System.Random()

Python

random.randint()

aus der Bibliothek für Zufallszahlen

Die Liste der verbotenen Funktionalitäten sollte auch Bibliotheken enthalten, die unsicheres Verhalten unterstützen. So waren beispielsweise alte Versionen von .NET anfällig für Denial-of-Service-Bomben mit XML-DTDs. Als Reaktion darauf fügte .NET ab Version 3.5 eine ProhibitDtd-Eigenschaft für verschiedene XML-Klassen hinzu, die, wenn sie auf true gesetzt ist, DTD-Bombenangriffe vollständig und elegant abwehrt.

DTD-Bomben

Eine XML-DTD-Bombe ist ein XML-Dokument, das eine selbstreferenzierende Dokumenttypdefinition (DTD) enthält. Hier ist ein Beispiel:

<?xml version="1.0"?>

<!DOCTYPE lolz [

<!ENTITY lol "lol">

<!ENTITY lol2 "&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;">

<!ENTITY lol3 "&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;">

<!ENTITY lol4 "&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;">

<!ENTITY lol5 "&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;">

<!ENTITY lol6 "&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;">

<!ENTITY lol7 "&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;">

<!ENTITY lol8 "&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;">

<!ENTITY lol9 "&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;">

]>

<lolz>&lol9;</lolz>

Wenn der XML-Parser &lol9 liest, wird dies zu zehn Verweisen auf &lol8 und jeder dieser Verweise zu zehn Verweisen auf &lol7. Sie können sehen, dass dies zu einer Datenexplosion führt, daher das Wort »Bombe« im Namen dieses Angriffs. Weitere Informationen finden Sie hier: https://learn.microsoft.com/archive/msdn-magazine/2009/november/xml-denial-of-service-attacks-and-defenses.

Für jeden Entwicklungsprozess, einschließlich Agile, ist es ein bewährtes Verfahren, eine Liste verbotener Funktionen und empfohlener Ersatzfunktionen zu führen und diese Liste zu aktualisieren, wenn neue Schwachstellen auftauchen. Hier sind einige Ressourcen, die Ihnen den Einstieg erleichtern:

Vulners

https://vulners.com

API Security

https://apisecurity.io

Praktische Erfahrungen: Verbot von Funktionen

Man kann nicht einfach etwas verbieten. Man benötigt auch einen brauchbaren Ersatz. Beispielsweise wollte Microsoft die C-Bibliotheksfunktion memcpy() eine Zeit lang verbieten, konnte dies aber nicht tun, bis die Funktion memcpy_s() allgemein verfügbar wurde.

Werkzeuge zur statischen Analyse verwenden

Tools für die statische Analyse – oder besser ausgedrückt Tools für statische Sicherheitstests von Anwendungen (Static Application Security Testing Tools, SAST) – sind ein Eckpfeiler agiler Methoden. Sie sollten diese Tools verwenden, und zwar frühzeitig und häufig. Diese Tools bieten Skalierbarkeit und ein Basisniveau an Korrektheit. Im Wesentlichen analysieren sie Ihren Quellcode und Ihre Datenflows, um Schwachstellen zu finden. Zumindest arbeiten die besseren Tools auf diese Weise! Einige sind nur glorifizierte Suchen nach Zeichenfolgen oder Grep-Tools.

Bei einigen Problemen ist das Greppen in Ordnung. Wenn Sie zum Beispiel in Quellcode nach MD4 suchen, stehen die Chancen gut, dass alles, was Sie finden, ein schwacher Hash-Algorithmus ist. Für so etwas müssen Sie keine Datenflussanalyse durchführen.

Eine Möglichkeit, statische Analysewerkzeuge zu verwenden, ist auf dem Desktop des Entwicklers, während er den Code kompiliert. Diese Tools sind in der Regel in die IDE oder Umgebung integriert und sollten häufig ausgeführt werden. Sie sind in der Regel relativ leichtgewichtig, und obwohl sie keine komplexe Datenflussanalyse durchführen, können sie oft schnell Probleme finden. Abbildung 1-3 zeigt ein Beispiel für C++-Code und die Ergebnisse der Ausführung der in Visual Studio integrierten Analysetools. In der Ausgabe ist zu erkennen, dass das Tool fünf Probleme gefunden und für drei davon Erklärungen geliefert hat.

Abbildung 1-3Ausgabe der statischen Analyse eines C++-Programms mit dem Compilerschalter/analyze in Visual Studio

Praktische Erfahrungen: Statische Analyse auf dem Planeten Erde

John Carmack, Mitbegründer von id Software und Hauptentwickler von Doom, Quake und Wolfenstein, macht in diesem Video einige sachdienliche Aussagen über den Wert von statischen Analysetools: https://azsec.tech/a64.

Der Fluch aller Softwareentwickler sind statische Analysewerkzeuge, die zahlreiche falsch-positive Ergebnisse erzeugen (das heißt, Elemente, die vom Werkzeug als Fehler markiert werden, aber keine echten Fehler sind) und die Probleme von geringer Schwere markieren. Wenn Sie diese Tools verwenden, müssen Sie die von ihnen entdeckten Probleme verfolgen und feststellen, welche Probleme echt sind und welche nicht. Wenn das Tool mehr nicht-reale Schwachstellen anzeigt, als vernünftig ist, sollten Sie die Liste der angezeigten Probleme einschränken oder mit dem Tool-Anbieter sprechen.

Um festzustellen, welche Fehler Ihr statisches Analysewerkzeug erkennen soll und welche nicht, stellen Sie sich diese drei Fragen:

Ist diese Fehlerklasse für mich von Bedeutung?

Einige Tools warnen Sie zum Beispiel, wenn Sie einen Variablennamen falsch schreiben. Wollen Sie, dass es das tut? Wollen Sie wirklich Hunderte von Warnungen in Bezug auf Camel Case vs. Pascal Case erhalten? Wahrscheinlich nicht!

Wie schwerwiegend ist der Fehler?

Sie möchten Warnungen über einen Fehler erhalten, der zu einem katastrophalen Fehler und damit zu Datenverlust führen könnte, aber ein Fehler, der einen abgeschnittenen Fehlertext in einem Dialogfeld verursacht, ist Ihnen vielleicht nicht so wichtig.

Wie sicher bin ich, dass es ein echter Bug ist?

Dies ist die wichtigste Frage. Um diese Frage zu beantworten, sollten Sie den Entwickler des Tools fragen, wie er feststellt, ob ein Fehler tatsächlich vorliegt. Die Analyse des Datenflusses zwischen den Funktionen deckt Probleme in der Regel mit größerer Sicherheit auf als eine einfache String-Suche.

Anhand dieser Antworten können Sie entscheiden, welche Warnungen Sie beherzigen sollten. Nehmen wir zum Beispiel an, dass Ihr Tool 170 verschiedene Probleme entdeckt; 65 davon sind nicht korrekt oder ein hohes Risiko, 70 sind ein geringes Risiko und 10 sind wenig vertrauenswürdig. Das bedeutet, dass Sie eigentlich nur 25 Warnungen berücksichtigen müssen. Im Laufe der Zeit können Sie weitere Warnungen hinzufügen; es ist am besten, klein anzufangen und die Entwickler nicht zu verärgern!

Sie können leichtgewichtige Analysewerkzeuge auf den Desktops der Entwickler als Teil des Build-Prozesses ausführen, aber ein zentrales Analyseteam könnte umfangreiche Werkzeuge verwenden. Dieses Team könnte dann die Ergebnisse sichten und einzelne Fehler mit den Entwicklern besprechen.

Praktische Erfahrungen: Effektiver Einsatz von Werkzeugen zur statischen Analyse

Geben Sie Ihren Entwicklern keine riesige Liste von nicht gesichteten, potenziell wenig schwer wiegenden Problemen, die bei der statischen Analyse gefunden wurden. Dies würde dazu führen, dass die Entwickler die Tools verachten und Sie zum »Staatsfeind Nr. 1« werden. Beginnen Sie stattdessen mit einer kleinen Anzahl von Warnungen mit hohem Schweregrad und hoher Zuverlässigkeit. Fügen Sie dann im Laufe der Zeit zu Ihrer Analyse und Ihren Berichten neue Warnungen hinzu. Es kann jedoch nicht schaden, die Tools mit allen aktivierten Warnungen laufen zu lassen und die Ergebnisse von den Sicherheitsexperten der Anwendungsentwicklung überprüfen zu lassen, die dann die schwerwiegenden Probleme für den Development-Backlog auswählen.

OWASP pflegt eine gute Liste kommerzieller und quelloffener statischer Analysetools unter https://azsec.tech/cf9. NIST pflegt eine ähnliche Liste (https://azsec.tech/9o0), und GitHub Advanced Security bietet Unterstützung für Sicherheitstools (https://azsec.tech/avb).

Dynamische Analysetools verwenden

In agilen Umgebungen sind dynamische Analysewerkzeuge genauso wichtig wie statische Analysewerkzeuge, und beide müssen frühzeitig und häufig – wenn nicht sogar kontinuierlich – eingesetzt werden, damit Sie Probleme schnell finden und beheben können. Schließlich ist es besser, pro Tag einen Bug zu finden und ihn zu beheben, als einen Monat zu warten, 45 Bugs zu finden und festzustellen, dass man sie wahrscheinlich nicht alle beheben kann! Fuzz-Testing, das in Kapitel 9 näher beschrieben wird, ist eine Form des dynamischen Testens, bei dem Sie Tests gegen ein laufendes System ausführen.

Eine genauere englische Bezeichnung für dynamische Analysetools ist Dynamic Application Security Testing (DAST).

Während statische Analysewerkzeuge den Quellcode analysieren, analysieren dynamische Analysewerkzeuge die laufenden Systeme. Und während statische Analysetools versuchen, logische Probleme zu verstehen und zu finden, versuchen dynamische Tools, Verhaltensfehler zu entdecken. Dennoch gibt es potenzielle Überschneidungen zwischen statischen und dynamischen Analysetools. Beispielsweise können beide Sicherheitslücken durch SQL Injection aufdecken. Sie tun dies jedoch mit unterschiedlichen Analysetechniken. OWASP pflegt hier eine Liste dynamischer Analysetools: https://azsec.tech/nh1.

Viele der Werkzeuge, in deren Namen das Wort Scanner vorkommt, sind dynamische Tools.

Interessanterweise weisen dynamische Tools nur wenige falsch-positive Ergebnisse auf. Denn wenn ein System während des Tests einen Fehler aufweist, handelt es sich um einen echten Fehler – die Art von Fehler, die ein Angreifer möglicherweise ausnutzen kann. Statische Analysetools übersehen viele dieser Fehler, weil sie nur den Code betrachten, ohne zu wissen, wie der Code eingesetzt wird.

Es gibt eine Kategorie von dynamischen Analysewerkzeugen, die zum Aufspüren von Konfigurationsschwachstellen verwendet werden, die vom SDL nicht erforderlich sind, da diese Werkzeuge Patches und die allgemeine Sicherheitslage untersuchen. Zu dieser Kategorie gehören Tools aus der Microsoft Defender-Suite. Diese Tools sind wichtig, liegen aber außerhalb des Bereichs von Softwarearchitekten und -entwicklern.

Praktische Erfahrungen: Analysetools dienen dem »Just-in-time-Lernen«

Das mag sich komisch anhören, aber wir wollen auf den Punkt eingehen, den wir gerade über die häufige Anwendung dieser Werkzeuge gemacht haben. Wenn Sie Code schreiben und dann ein Analysetool ausführen und einen Fehler finden, steigt Ihr »Bug-IQ«! Sie wissen jetzt, dass Sie das Konstrukt, das zu dem Fehler geführt hat, nicht mehr verwenden sollten, und wahrscheinlich werden Sie denselben Fehler in Zukunft nicht mehr machen.

Praktische Erfahrungen: Auswahl von statischen und dynamischen Analysewerkzeugen

Bitte beachten Sie, dass wir keine Liste gängiger statischer und dynamischer Analysetools bereitgestellt haben. Dies haben wir mit Absicht gemacht, denn:

Es gibt viele dieser Werkzeuge.Es gibt nicht das eine Werkzeug, das für alle passt.

Daher haben wir keine Liste erstellt, sondern einige Richtlinien, die Ihnen bei der Auswahl geeigneter Werkzeuge helfen sollen. Beginnen wir mit Werkzeugen für die statische Analyse. Stellen Sie sich diese Fragen:

Funktioniert das Tool mit meinen Programmiersprachen?Bietet es eine gute Liste von Schwachstellenarten?Weist das Tool nur wenige falsch-positive Ergebnisse auf?Funktioniert das Tool auf meinen Entwicklungsplattformen?

Bei dynamischen Analysewerkzeugen fragen Sie sich einfach, ob das Werkzeug Ihre Einsatzumgebung unterstützt. Und bei allen Tools sollten Sie prüfen, ob das Tool Details zur Codeabdeckung und umsetzbare Berichte liefert, wenn es Probleme entdeckt.

Code-Review unter Sicherheitsaspekten

Tools sind großartig, weil sie eine Skalierung ermöglichen und ein Mindestmaß an Sicherheit gewährleisten. Allerdings müssen Sie die Tools durch einen menschliche Code-Review ergänzen. Es gibt keinen Ersatz für einen sachkundigen Menschen, der einen Sicherheits-Code-Review durchführt, auch wenn der Prozess langsam ist.

Die allgemeine Vorgehensweise sieht wie folgt aus. Identifizieren Sie zunächst alle Eintrittspunkte, wie REST-API-Endpunkte und Websockets. Folgen Sie den Daten auf ihrem Weg durch den Code. Dies wird als Flussanalyse bezeichnet. Es gibt zwei Arten: Kontrollflussanalyse und Datenflussanalyse.

Sie sollten in der Lage sein, im Bedrohungsmodell die Endpunkte sehen zu können. Wenn diese nicht im Bedrohungsmodell enthalten sind, sollte das Bedrohungsmodell aktualisiert werden. Achten Sie auch auf die Endpunkte am oberen Ende der Vertrauensgrenze, da diese wahrscheinlich das größte Risiko darstellen.

Kontrollfluss analysieren

Zunächst führen wir eine manuelle Kontrollflussanalyse durch. Dies ist der Mechanismus, der verwendet wird, um durch logische Bedingungen im Code zu gehen. Der Prozess funktioniert wie folgt:

1.Beginnen Sie an einem Eintrittspunkt, untersuchen Sie den Code und identifizieren Sie jede bedingte Verzweigung. Dabei kann es sich um Schleifen, if-Anweisungen oder Blöcke zur Behandlung von Ausnahmen handeln.

2.Ermitteln Sie die Bedingungen, unter denen die einzelnen Blöcke ausgeführt werden, und stellen Sie sich die folgenden Fragen:

Sind sie korrekt?

Sind alle Bedingungen abgedeckt?

Werden in dieser Verzweigung Sicherheitsentscheidungen getroffen?

Sind die Bedingungen, unter denen die einzelnen Blöcke ausgeführt werden, korrekt?

Ist eine Sicherheitsentscheidung sicher gescheitert (fail-closed)?

3.Gehen Sie zum nächsten Eintrittspunkt und wiederholen Sie den Vorgang.

Datenfluss analysieren

Die Fragen im vorherigen Abschnitt werden Ihnen helfen, viele Fehler und Schwachstellen zu finden. Jetzt sind Sie bereit, eine Technik namens Datenflussanalyse anzuwenden, um Fehler zu finden, die mit einem schlechten Handling der Eingabedaten zusammenhängen. Die Datenflussanalyse ist der Mechanismus, der verwendet wird, um Daten von Eingabepunkten zu Ausgabepunkten zu verfolgen. Hier geht es nicht um den Kontrollfluss, sondern darum, wie eingehende Daten vom Code verarbeitet werden. Das Verfahren funktioniert wie folgt:

Bestimmen Sie für jeden Eintrittspunkt, wie sehr Sie der Eingangsquelle vertrauen. Im Zweifelsfall sollten Sie ihr kein Vertrauen schenken. Beziehen Sie sich bei Bedarf auf das Bedrohungsmodell.

Verfolgen Sie den Datenfluss zu jeder möglichen Ausgabe und beachten Sie dabei alle Versuche, die Daten zu validieren.

Gehen Sie zum nächsten Eintrittspunkt und wiederholen Sie den Vorgang.

Wenn Sie fertig sind, sollten Sie eine Liste aller Funktionen haben, die von den einzelnen Eingabedaten berührt werden, sowie die möglichen Ausgabestellen, an denen die Daten landen. Achten Sie besonders auf Bereiche, in denen Daten geparst werden und an mehreren Ausgabestellen landen könnten. Achten Sie auch auf zwischengeschaltete Ausgabestellen. So kann die Eingabe beispielsweise in einer Datenbank landen und später in den Inhalt einer Webseite einfließen.

In einer agilen Umgebung ist der Code-Review unter Sicherheitsaspekten wichtig. Da bei agilen Modellen in der Regel schnell kleine Mengen an Code produziert werden, ist es zum Glück einfacher, den Code-Diff zu überprüfen als eine ganze Quellcodedatei. Dennoch sollte irgendwann die gesamte Codebasis manuell überprüft werden.

Reaktionsplan bei Zwischenfällen haben

In den meisten Unternehmen wird die Reaktion auf einen Sicherheitsvorfall in einem Projekt normalerweise von einem zentralen Team und nicht vom Entwicklungsteam des Projekts übernommen. Dennoch muss es im Entwicklungsteam jemanden geben, der bei einem Problem zur Stelle ist – mit anderen Worten, jemanden, der den Anruf nachts um 3 Uhr entgegennimmt. Ihr zentrales Reaktionsteam benötigt eine Liste mit allen Ansprechpartnern für jede Ihrer Anwendungen, die bei einer Kompromittierung erreichbar sind. Falls Ihr Unternehmen über einen Notfallplan verfügt, muss jemand in Ihrem Team den Prozess verstehen. Wenn kein Plan vorhanden ist, müssen Sie einen erstellen. Diese Seite kann Ihnen zeigen, wie das geht: https://azsec.tech/dva.

Penetrationstests durchführen

Ein Penetrationstest (kurz Pentest) ist ein Test, der von einer qualifizierten Person durchgeführt wird, um Schwachstellen in Ihrer Anwendung zu finden und zu versuchen, sie zu knacken. Viele Compliance-Programme verlangen Penetrationstests.

Was die Penetrationstests betrifft, sollten Sie zwei Dinge beachten:

Ein Penetrationstest ist nur so gut wie der Pentester

Eine hochqualifizierte Person ist oft besser als vier mittelmäßige Personen mit wenig Erfahrung. Wenn Sie also eine Pentest-Organisation beauftragen, überzeugen Sie sich, dass die Mitarbeiter, die die Arbeit durchführen, qualifiziert sind.

Pentests sind nicht das, wofür man sie hält

Es mag wie Ketzerei klingen, aber zu viele Unternehmen gehen davon aus, dass der Zweck eines Pentests darin besteht, Sicherheitslücken zu finden, damit sie diese beheben können. Dies ist ein teurer Fehler. Tatsächlich ist ein erfolgreicher Pentest einer, bei dem nichts gefunden wird, weil Sie im Vorfeld die richtigen Sicherheitsmaßnahmen getroffen haben. Außerdem ist es töricht, darauf zu warten, dass ein Pentest ein Problem aufdeckt, denn wenn ein Problem gefunden wird, wie groß sind die Chancen, dass Sie es schnell genug beheben können?

Ihre Aufgabe ist es, Lösungen zu bauen, die den Pentestern das Leben schwer machen! Wenn Sie Ihre Lösungen sicher bauen und ein guter Pentester nichts Ernsthaftes findet, dann hat jeder seine Aufgabe erfüllt. Natürlich werden die Pentester etwas finden, egal wie unbedeutend es ist, denn sie müssen etwas finden! Aber so gut ein Pentester auch sein mag, er wird nicht alles finden.

Bei agilen Methoden wird in der Regel nicht angegeben, wann ein Penetrationstest abgeschlossen sein sollte, da er in der Regel nicht in den Entwicklungsprozess eingebunden ist. Zu einem bestimmten Zeitpunkt sollte jedoch ein Build den Pentestteilnehmern zugänglich gemacht werden, und sie sollten die ihnen zugewiesene Zeit aufwenden, um Probleme zu finden und zu melden, was sie entdeckt haben.

Die Payment Card Industry (PCI) bietet eine Anleitung zum Pentesting unter https://azsec.tech/0q2.

Praktische Erfahrungen: Technische Sicherheitsschulden

Wir haben festgestellt, dass Menschen, die Praktiken zur Verbesserung der Sicherheit einführen, in der Regel als Erstes feststellen, dass ihr Code und ihr Design eine Menge Sicherheitsprobleme aufweisen. Die Probleme waren schon immer da, aber jetzt haben sie einige gefunden (aber nicht alle!). Dies ist ein gutes Beispiel für technische Sicherheitsschulden.

Sie müssen technische Sicherheitsschulden so schnell wie möglich abbauen, ohne den Code zu zerstören. Seien Sie besonders vorsichtig, wenn Sie aufgrund von Problemen, die Sie in einem Bedrohungsmodell gefunden haben, Änderungen am Entwurf vornehmen; es besteht immer die Gefahr von Regressionen. Auch große Codeänderungen können zu Regressionen führen. Sobald Sie Ihre technischen Schulden unter Kontrolle haben, können Sie sich darauf konzentrieren, Prozesse und Tools einzurichten, die das Auftreten neuer Schwachstellen in Ihrem System verhindern.

Wenn das Management einen Anstieg bei Sicherheitsfehlern feststellt, wird die Frage aufkommen, ob diese neue Sicherheitsinitiative rentabel ist! Denken Sie daran, dass die Fehler schon immer da waren. Es waren lediglich neue sicherheitsrelevante Schulungen, Prozesse und Werkzeuge nötig, um sie zu finden.

SDL-Aufgaben nach Sprint

Sie werden nicht alle SDL-Aufgaben in jedem Sprint erledigen, aber Sie müssen sie irgendwann erledigen. Hier finden Sie einen Überblick darüber, was Sie wann tun müssen:

Sicherheitsschulung

Alle Entwickler müssen die Sicherheitsaspekte in Bezug auf den Code verstehen, an dem sie in jedem Sprint arbeiten werden. Arbeiten Sie an Datenbankcode? Sorgen Sie dafür, dass sie SQL Injection und Injection im Allgemeinen verstehen. Arbeiten sie an kryptografischem Code? Sorgen Sie dafür, dass sie die kryptografischen Anforderungen verstehen, wo die Schlüssel gespeichert werden usw.

Bug Bar definieren

Dies sollte vor Beginn des Projekts geschehen – vielleicht als Teil des Sprints Zero. Sprint Zero ist ein Schritt vor dem ersten Sprint, in dem die Entwickler Aufgaben wie das Einrichten der Entwicklungsumgebung, Tools zur Aufgabenverfolgung und Bedrohungsmodellierung durchführen.

Angriffsfläche analysieren

Diese kann fortlaufend erfolgen, wenn Werkzeuge verwendet werden. Was die Angriffsfläche ausmacht, sollte im Vorfeld geklärt werden.

Bedrohungen modellieren

Ein grundlegendes Bedrohungsmodell sollte vor der Arbeit am Code erstellt werden, etwa im Sprint Zero. Wenn wesentliche Änderungen am Entwurf vorgenommen werden, sollten die Aktualisierungen in jedem Sprint in das Bedrohungsmodell eingearbeitet werden. Der Arbeitsaufwand für die Aktualisierung eines Bedrohungsmodells mit relativ kleinen Änderungen in einem Sprint ist gering.

Toolchain definieren