Mehr zu Sicherheit und Datenschutz als Konzept
Bei Microsofts SDL stehen Sicherheit und Datenschutz von vorneherein im Vordergrund. Sicherheits- und Datenschutzfunktionen sollten keine Add-Ons sein, sondern sind wesentliche Bestandteile unserer Produkte und Dienste. Wir integrieren Sicherheit in unsere Produkte, indem wir früh Sicherheitsanforderungen im Funktionslebenszyklus definieren, Bedrohungsmodelle für alle wichtigen Dienstkomponenten und -Features aktuell halten und für sämtlichen Quellcode eine manuelle Codeüberprüfung erfordern.
Sicherheits- und Datenschutzanforderungen
Sicherheits- und Datenschutzanforderungen sollten die Gestaltung aller hochsicheren Anwendungen und Systeme prägen. Bei Microsoft beginnt die Entwicklung jedes unserer Produkte, Dienste und Features mit klar definierten Sicherheits- und Datenschutzanforderungen. Da die Softwareentwicklung ein fortlaufender Prozess ist, aktualisieren wir diese Anforderungen während des gesamten Lebenszyklus eines Produkts kontinuierlich, um Änderungen an den erforderlichen Funktionen und der Bedrohungslandschaft widerzuspiegeln. Zu den Faktoren, die sich auf Sicherheits- und Datenschutzanforderungen auswirken, gehören die Art der entwickelten Software, bekannte Sicherheitsrisiken, Erkenntnisse aus Sicherheitsvorfällen, rechtliche und Branchenanforderungen sowie interne Standards und Codierungspraktiken.
Der optimale Zeitpunkt für die Definition von Sicherheits- und Datenschutzanforderungen ist während der ersten Entwurfs- und Planungsphasen eines Produkts oder Features. Dies ermöglicht es Entwicklungsteams, Sicherheitsfeatures in die Kernfunktionen eines Produkts zu integrieren. So fragen wir uns beispielsweise zu jedem Produkt während der Entwurfsphase, ob es sensible Daten wie z. B. Kundendaten verarbeiten wird. Der SDL von Microsoft umfasst Sicherheits- und Datenschutzanforderungen, um Entwickler bei der Implementierung bewährter Methoden für die Verarbeitung vertraulicher Daten zu unterstützen und sicherzustellen, dass unsere Software vertrauliche Daten unter Einhaltung der relevanten Anforderungen sicher sammelt, verarbeitet und speichert. Sdl-Anforderungen für die Verarbeitung vertraulicher Daten umfassen Verschlüsselung, Protokollierung und Reaktion auf Vorfälle, um vertrauliche Daten zu schützen und den Microsoft-Sicherheitsreaktionsteams die Überwachungsfunktionen zur Verfügung zu stellen, die für die Untersuchung und Reaktion auf potenzielle Sicherheitsvorfälle erforderlich sind.
Bedrohungsmodelle und Datenflussdiagramme (Data Flow Diagrams, DFDs)
Sobald der Entwurf eines Produkts klar definierte Sicherheits- und Datenschutzanforderungen umfasst, erstellen Entwicklungsteams Bedrohungsmodelle, um die Sicherheits- und Datenschutzbedrohungen zu visualisieren, die sich am wahrscheinlichsten auf das Produkt auswirken. Die Bedrohungsmodellierung hilft dabei, potenzielle Bedrohungen nach Risiko zu ermitteln, zu kategorisieren und zu bewerten, sodass Entwickler geeignete Gegenmaßnahmen vorschlagen und implementieren können. Das SDL erfordert, dass die Entwicklungsteams bei Microsoft aktuelle Bedrohungsmodelle und Datenflussdiagramme (DFDs) für alle wichtigen Dienstkomponenten und Features verwalten.
Die Bedrohungsmodellierung beginnt mit der Definition der Komponenten eines Produkts oder eines Features und der Erstellung eines Diagramms ihrer Beziehungen zueinander für wichtige funktionale Szenarien wie die Authentifizierung oder die Verarbeitung sensibler Daten. Bedrohungsmodellierungdiagramme umfassen relevante Datenströme, Funktionen und Prozesse, um Bedrohungen für den Dienst visuell darzustellen. Im Rahmen des Bedrohungsmodellierungsprozesses erstellen Serviceteams Datenflussdiagramme, die alle Datenströme, Ports und Protokolle dokumentieren, die von einer Dienstkomponente oder -Feature verwendet werden.
Die kompletten Diagramme werden zum Erkennen von Bedrohungen für das System sowie zur Priorisierung von Bedrohungen für Abhilfemaßnahmen verwendet. Entwicklungsteams schlagen Abhilfemaßnahmen gegen Risiken vor, die durch ihre Bedrohungsmodelle aufgedeckt wurden, und implementieren sie. Den Sicherheitsanforderungen des Produkts werden neue Abhilfemaßnahmen hinzugefügt, diese werden im Code während der manuellen Codeüberprüfung und automatisierten Tests validiert und im Rahmen des Genehmigungsprozesses vor der Veröffentlichung überprüft.
Da bei der modernen Softwareentwicklung mit Agile die schnelle Bereitstellung von Funktionen für Kunden im Vordergrund steht, ist die Bedrohungsmodellierung ein fortlaufender Prozess. Um Einheitlichkeit zwischen allen Entwicklungsteams hinweg zu gewährleisten und Bedrohungsmodelle auf dem neuesten Stand zu halten, müssen Microsoft-Entwickler für alle Bedrohungsmodelle das Threat Modeling Tool von Microsoft verwenden. Mit dem Threat Modeling Tool haben Entwickler oder Softwarearchitekten bei Microsoft folgende Möglichkeiten:
- Sich über das Sicherheitskonzept ihrer Systeme austauschen
- Sicherheitskonzepte anhand bewährter Methoden auf potenzielle Sicherheitsprobleme hin analysieren
- Abhilfemaßnahmen gegen Sicherheitsprobleme vorschlagen und verwalten
Während der Sicherheitsüberprüfung vor der Veröffentlichung werden alle Bedrohungsmodelle auf Richtigkeit und Vollständigkeit überprüft, einschließlich der Abhilfemaßnahmen gegen inakzeptable Risiken. Durch diese Überprüfungen werden Verantwortlichkeiten aufrechterhalten und sicherheitsorientierte Konzepte gefördert.
Manuelle Codeüberprüfung
Unsere Entwicklungsteams verwenden Azure DevOps Git zur Versionskontrolle aller neuen Code-Repositories. Um sicher zu gehen, dass der gesamte bei Microsoft entwickelte Code den Anforderungen von SDL und Konzept entspricht, erfordert der SDL die manuelle Codeüberprüfung durch einen zusätzlichen Überprüfer, bevor Codeänderungen in einen Release-Branch übernommen werden können. Codeüberprüfer suchen nach Codierungsfehlern und überprüfen, ob Codeänderungen den SDL- und Konzeptanforderungen entsprechen, ob sie Funktions- und Sicherheitstests bestehen und zuverlässig funktionieren. Außerdem prüfen sie zugeordnete Dokumentationen, Konfigurationen und Abhängigkeiten, um sicherzustellen, dass die Codeänderungen ordnungsgemäß dokumentiert wurden und keine unbeabsichtigten Nebeneffekte zur Folge haben.
Wenn ein Überprüfer während der Codeüberprüfung auf Probleme stößt, kann er die einreichende Person auffordern, den Code mit den vorgeschlagenen Änderungen und nach zusätzlichen Tests erneut einzureichen. Codeüberprüfer können die Übernahme des Codes auch gänzlich verhindern, wenn dieser den Anforderungen nicht entspricht. Alle Änderungen an für die Veröffentlichung eingereichtem Code müssen eindeutig auf einen einzelnen Entwickler zurückzuführen sein und von einem separaten Überprüfer geprüft werden, um die Verantwortlichkeiten aufrechtzuerhalten. Darüber hinaus müssen alle Änderungen an für die Veröffentlichung bestimmtem Code aufgezeichnet und für mindestens 18 Monate aufbewahrt werden, um eine überprüfbare Aufzeichnung aller Codeänderungen und ihres Autors, der geschäftlichen Begründung, der Testergebnisse sowie des Prüfers, der die Änderung genehmigt hat, bereitzustellen.