Empfehlungen für Sicherheitstests
Hierfür gilt die Empfehlung der Power Platform Well-Architected Security-Checkliste:
| SE:09 | Richten Sie ein umfassendes Testprogramm ein, das Ansätze zur Vermeidung von Sicherheitsproblemen, zur Validierung von Implementierungen zur Bedrohungsprävention und zum Testen von Bedrohungserkennungsmechanismen kombiniert. |
|---|
Gründliche Tests sind die Grundlage eines guten Sicherheitsdesigns. Beim Testen handelt es sich um eine taktische Form der Validierung, um sicherzustellen, dass die Kontrollen wie vorgesehen funktionieren. Durch Tests lassen sich außerdem Schwachstellen im System proaktiv erkennen.
Sorgen Sie für strikte Tests durch Planung und Verifizierung aus mehreren Perspektiven. Sie sollten interne Perspektiven, mit denen Plattform und Infrastruktur getestet werden, sowie Bewertungen von außen, die das System wie ein externer Angreifer testen, einbeziehen.
Diese Anleitung enthält Empfehlungen zum Testen des Sicherheitsstatus Ihrer Workload. Implementieren Sie diese Testmethoden, um die Widerstandsfähigkeit Ihrer Workload gegen Angriffe zu verbessern und die Vertraulichkeit, Integrität und Verfügbarkeit der Ressourcen aufrechtzuerhalten.
Definitionen
| Begriff | Definition |
|---|---|
| Anwendungssicherheitstests (AST) | Eine Microsoft Security Development Lifecycle-Technik (SDL), die White-Box- und Black-Box-Testmethoden verwendet, um Code auf Sicherheitslücken zu prüfen. |
| Black-Box-Tests | Eine Testmethode, die das extern sichtbare Anwendungsverhalten validiert, ohne die internen Vorgänge des Systems zu kennen. |
| Blaues Team | Ein Team, das sich in einer Angriffsübung gegen die Angriffe des roten Teams verteidigt. |
| Penetrationstests | Eine Testmethode, die ethische Hacking-Techniken verwendet, um die Sicherheitsmaßnahmen eines Systems zu validieren. |
| Rotes Team | Ein Team, das die Rolle eines Gegners spielt und in einer Angriffsübung versucht, das System zu hacken. |
| Security Development Lifecycle (SDL) | Eine Reihe von Praktiken, die von Microsoft bereitgestellt wurden, und die die Sicherheitsgarantie- und Compliance-Anforderungen unterstützen. |
| Software Development Lifecycle (SDLC) | Ein mehrstufiger, systematischer Prozess zur Entwicklung von Softwaresystemen. |
| White-Box-Tests | Eine Testmethode, bei der die Struktur des Codes dem Anwender bekannt ist. |
Wichtige Designstrategien
Tests sind eine nicht verhandelbare Strategie, insbesondere im Hinblick auf die Sicherheit. Damit können Sie Sicherheitsprobleme proaktiv erkennen und beheben, bevor sie ausgenutzt werden können. Zudem können Sie überprüfen, ob die implementierten Sicherheitskontrollen wie vorgesehen funktionieren.
Der Testumfang muss die Anwendung, die Infrastruktur sowie automatisierte und menschliche Prozesse umfassen.
Anmerkung
Diese Anleitung unterscheidet zwischen Tests und Reaktion auf Vorfälle. Obwohl es sich beim Testen um einen Erkennungsmechanismus handelt, der im Idealfall Probleme vor der Produktion behebt, sollte er nicht mit der Behebung oder Untersuchung verwechselt werden, die im Rahmen der Reaktion auf Vorfälle durchgeführt wird. Der Aspekt der Wiederherstellung nach Sicherheitsvorfällen wird in den Empfehlungen zur Reaktion auf Sicherheitsvorfälle beschrieben.
Beteiligen Sie sich an der Testplanung. Das Workload-Team entwirft die Testfälle möglicherweise nicht. Diese Aufgabe wird häufig zentral im Unternehmen ausgeführt oder von externen Sicherheitsexperten übernommen. Das Workload-Team sollte in diesen Entwurfsprozess eingebunden werden, um sicherzustellen, dass die Sicherheitsgarantien in die Funktionalität der Anwendung integriert werden.
Denken Sie wie ein Angreifer. Entwerfen Sie Ihre Testfälle unter der Annahme, dass das System angegriffen wurde. Auf diese Weise können Sie potenzielle Schwachstellen aufdecken und die Tests entsprechend priorisieren.
Führen Sie Tests strukturiert und mit einem wiederholbaren Prozess durch. Bauen Sie Ihre Testgenauigkeit anhand von Plänen, Testarten, treibenden Faktoren und beabsichtigten Ergebnissen auf.
Nutzen Sie das richtige Tool für die Aufgabe. Verwenden Sie Tools, die für die jeweilige Workload konfiguriert sind. Wenn Sie kein Tool haben, kaufen Sie es. Erstellen Sie es nicht. Sicherheitstools sind hochspezialisiert und die Entwicklung eines eigenen Tools kann Risiken bergen. Nutzen Sie das Fachwissen und die Tools zentraler SecOps-Teams oder externer Anbieter, wenn das Workload-Team nicht über das entsprechende Fachwissen verfügt.
Richten Sie separate Umgebungen ein. Tests können als destruktiv und nicht destruktiv klassifiziert werden. Nicht destruktive Tests sind nicht invasiv. Sie weisen darauf hin, dass ein Problem vorliegt, ändern jedoch nicht die Funktionalität, um das Problem zu beheben. Destruktive Tests sind invasiv und können durch das Löschen von Daten aus einer Datenbank die Funktionalität beeinträchtigen.
Durch Test-in-Produktion-Umgebungen erhalten Sie die besten Informationen, es kommt jedoch auch zu den meisten Störungen. Sie neigen dazu, nur nicht destruktive Tests in Produktionsumgebungen durchzuführen. Das Testen in Nichtproduktionsumgebungen ist in der Regel weniger störend, stellt die Konfiguration der Produktionsumgebung jedoch unter Umständen nicht in für die Sicherheit wichtigen Bereichen genau dar.
Sie können einen isolierten Klon Ihrer Produktionsumgebung erstellen, indem Sie die Funktion zum Kopieren von Umgebungen verwenden. Wenn Sie Bereitstellungspipelines eingerichtet haben, können Sie Ihre Lösungen auch in einer dedizierten Testumgebung bereitstellen.
Bewerten Sie immer die Testergebnisse. Tests sind ein vergeblicher Aufwand, wenn die Ergebnisse nicht dazu genutzt werden, Maßnahmen zu priorisieren und im Vorfeld Verbesserungen vorzunehmen. Dokumentieren Sie die Sicherheitsrichtlinien, einschließlich der Best Practices, die Sie entdecken. Eine Dokumentation mit Ergebnissen und Behebungsplänen informiert das Team über die verschiedenen Möglichkeiten, mit denen Angreifer versuchen könnten, die Sicherheit zu verletzen. Führen Sie regelmäßig Sicherheitsschulungen für Entwickler, Administratoren und Tester durch.
Denken Sie beim Entwerfen Ihrer Testpläne über die folgenden Fragen nach:
- Wie oft wird der Test voraussichtlich ausgeführt und welche Auswirkungen hat er auf Ihre Umgebung?
- Welche verschiedenen Testtypen sollten Sie durchführen?
Wie oft werden die Tests voraussichtlich ausgeführt?
Testen Sie die Workload regelmäßig, um sicherzustellen, dass durch die Änderungen keine Sicherheitsrisiken entstehen und dass es zu keinen Regressionen kommt. Das Team muss außerdem bereit sein, auf organisatorische Sicherheitsüberprüfungen zu reagieren, die jederzeit durchgeführt werden können. Es gibt auch Tests, die Sie als Reaktion auf einen Sicherheitsvorfall ausführen können. Die folgenden Abschnitte enthalten Empfehlungen zur Häufigkeit von Tests.
Routinetests
Routinetests werden in regelmäßigen Abständen als Teil Ihrer Standardbetriebsabläufe und zur Erfüllung von Compliance-Anforderungen durchgeführt. Verschiedene Tests können in unterschiedlichen Abständen ausgeführt werden, wichtig ist jedoch, dass sie regelmäßig und planmäßig durchgeführt werden.
Sie sollten diese Tests in Ihren SDLC integrieren, da sie in jeder Phase eine umfassende Abwehr bieten. Diversifizieren Sie die Testsuite, um Zusicherungen hinsichtlich Identität, Datenspeicherung und -übertragung sowie Kommunikationskanälen zu überprüfen. Führen Sie dieselben Tests an verschiedenen Punkten im Lebenszyklus durch, um sicherzustellen, dass es keine Regressionen gibt. Routinetests helfen dabei, einen ersten Benchmark festzulegen. Dies ist jedoch nur ein Ausgangspunkt. Wenn Sie an den gleichen Punkten des Lebenszyklus neue Probleme entdecken, fügen Sie neue Testfälle hinzu. Auch die Tests verbessern sich durch Wiederholung.
In jeder Phase sollten diese Tests hinzugefügten oder entfernten Code bzw. geänderte Konfigurationseinstellungen validieren, um die Auswirkungen dieser Änderungen auf die Sicherheit zu erkennen. Sie sollten die Wirksamkeit der Tests durch Automatisierung verbessern und diese mit Peer-Überprüfungen abgleichen.
Erwägen Sie die Ausführung von Sicherheitstests als Teil einer automatisierten Pipeline oder eines geplanten Testlaufs. Je früher Sie Sicherheitsprobleme entdecken, desto einfacher ist es, den Code oder die Konfigurationsänderung zu finden, die sie verursacht.
Verlassen Sie sich nicht nur auf automatisierte Tests. Verwenden Sie manuelle Tests, um Schwachstellen zu erkennen, die nur durch menschliches Fachwissen erkannt werden können. Manuelle Tests eignen sich für explorative Anwendungsfälle und zum Auffinden unbekannter Risiken.
Improvisierte Tests
Improvisierte Tests ermöglichen eine zeitpunktbezogene Validierung der Sicherheitsvorkehrungen. Diese Tests werden durch Sicherheitswarnungen ausgelöst, die sich zu diesem Zeitpunkt auf die Workload auswirken könnten. Organisatorische Vorgaben erfordern möglicherweise eine Art Mentalität von Pausieren und Testen, um die Wirksamkeit von Abwehrstrategien zu prüfen, wenn sich der Alarm zu einem Notfall entwickelt.
Der Nutzen improvisierter Tests liegt in der Vorbereitung auf einen tatsächlichen Vorfall. Diese Tests können eine erzwungene Funktion zur Durchführung von Benutzerakzeptanztests (UAT) sein.
Das Sicherheitsteam prüft möglicherweise alle Workloads und führt diese Tests nach Bedarf aus. Als Workload-Besitzer müssen Sie die Sicherheitsteams unterstützen und mit ihnen zusammenarbeiten. Verhandeln Sie mit den Sicherheitsteams ausreichend Vorlaufzeit, damit Sie sich vorbereiten können. Erkennen Sie die Notwendigkeit dieser Unterbrechungen an, und teilen Sie sie Ihrem Team und den Stakeholdern mit.
In anderen Fällen müssen Sie möglicherweise Tests durchführen und den Sicherheitsstatus des Systems im Hinblick auf die potenzielle Bedrohung melden.
Kompromiss: Da improvisierte Tests störende Ereignisse sind, müssen Sie mit einer Neupriorisierung der Aufgaben rechnen, die andere geplante Arbeiten verzögern kann.
Risiko: Es besteht das Risiko des Unbekannten. Improvisierte Tests können einmalige Anstrengungen ohne etablierte Prozesse oder Tools sein. Das größte Risiko besteht jedoch in einer möglichen Unterbrechung des Geschäftsbetriebs. Sie müssen diese Risiken im Verhältnis zu den Vorteilen abwägen.
Tests zu Sicherheitsvorfällen
Es gibt Tests, die die Ursache eines Sicherheitsvorfalls an der Quelle erkennen. Diese Sicherheitslücken müssen geschlossen werden, um sicherzustellen, dass sich ein solcher Vorfall nicht wiederholt.
Darüber hinaus verbessern Vorfälle im Laufe der Zeit die Testfälle, indem sie vorhandene Lücken aufdecken. Das Team sollte die aus dem Vorfall gewonnenen Erkenntnisse anwenden und routinemäßig Verbesserungen einbeziehen.
Was sind die verschiedenen Arten von Tests?
Tests können nach Technologie und Testmethoden kategorisiert werden. Kombinieren Sie diese Kategorien und Ansätze innerhalb dieser Kategorien, um eine vollständige Abdeckung zu erhalten.
Durch das Hinzufügen mehrerer Tests und Testarten können Sie Folgendes erkennen:
- Lücken bei den Sicherheitskontrollen oder Ausgleichskontrollen.
- Falsche Konfigurationen.
- Lücken bei Einblicken und Erkennungsmethoden.
Eine gute Übung zur Bedrohungsmodellierung kann auf Schlüsselbereiche hinweisen, um Testumfang und -häufigkeit sicherzustellen. Empfehlungen zur Bedrohungsmodellierung finden Sie unter Empfehlungen zur Sicherung eines Entwicklungslebenszyklus.
Die meisten in diesen Abschnitten beschriebenen Tests können als Routinetests durchgeführt werden. Allerdings kann die Wiederholbarkeit in manchen Fällen Kosten verursachen und zu Störungen führen. Überlegen Sie sich diese Kompromisse gut.
Tests, die den Technologie-Stack validieren
Hier sind einige Beispiele für Testarten und ihre Schwerpunkte. Diese Liste ist nicht vollständig. Testen Sie den gesamten Stack, einschließlich Anwendungsstack, Front-End, Back-End, APIs, Datenbanken und aller externen Integrationen.
- Datensicherheit: Testen Sie die Wirksamkeit der Datenverschlüsselung und Zugriffskontrollen, um sicherzustellen, dass die Daten angemessen vor unbefugtem Zugriff und Manipulation geschützt sind.
- Netzwerk und Konnektivität: Testen Sie Ihre Firewalls, um sicherzustellen, dass sie nur erwarteten, zulässigen und sicheren Datenverkehr zur Arbeitslast zulassen.
- Anwendung: Testen Sie den Quellcode mithilfe von Techniken zum Testen der Anwendungssicherheit (AST), um sicherzustellen, dass Sie sichere Codierungspraktiken anwenden und um Laufzeitfehler wie Speicherbeschädigungen und Probleme mit den Berechtigungen zu erkennen.
- Identität: Bewerten Sie, ob die Rollenzuweisungen und Bedingungsprüfungen wie vorgesehen funktionieren.
Testmethodik
Es gibt viele Perspektiven zu Testmethoden. Wir empfehlen Tests, die die Suche nach Bedrohungen durch die Simulation realer Angriffe ermöglichen. Sie können potenzielle Bedrohungsakteure, ihre Techniken und ihre Exploits identifizieren, die eine Gefahr für die Workload darstellen. Gestalten Sie die Angriffe so realistisch wie möglich. Nutzen Sie alle potenziellen Bedrohungsvektoren, die Sie während der Bedrohungsmodellierung identifizieren.
Hier sind einige Vorteile des Testens durch reale Angriffe:
- Wenn Sie diese Angriffe zu einem Teil der Routinetests machen, nutzen Sie eine Außenperspektive, um die Workload zu überprüfen und sicherzustellen, dass die Abwehr einem Angriff standhalten kann.
- Auf der Grundlage der gewonnenen Erkenntnisse verbessert das Team sein Wissen und seine Fähigkeiten. Das Team verbessert sein Situationsbewusstsein und kann seine Bereitschaft, auf Vorfälle zu reagieren, selbst einschätzen.
Beispiele für simulierte Tests sind Black-Box- und White-Box-Tests, Penetrationstests und Angriffsübungen.
Black-Box- und White-Box-Tests
Diese Testarten bieten zwei unterschiedliche Perspektiven. Bei Black-Box-Tests sind die internen Komponenten des Systems nicht sichtbar. Bei White-Box-Tests verfügt der Tester über ein gutes Verständnis der Anwendung und hat für die Durchführung des Experiments sogar Zugriff auf Code, Protokolle, Ressourcentopologie und Konfigurationen.
Tests, die Angriffe durch Penetrationstests simulieren
Sicherheitsexperten, die nicht Teil der IT- oder Anwendungsteams der Organisation sind, führen Penetrationstests oder Pentests durch. Sie betrachten das System aus der Sicht von böswilligen Akteuren, die eine Angriffsfläche auskundschaften. Ihr Ziel besteht darin, Sicherheitslücken zu finden, indem sie Informationen sammeln, Schwachstellen analysieren und die Ergebnisse melden.
Die Praktiker benötigen möglicherweise Zugriff auf vertrauliche Daten in der gesamten Organisation. Befolgen Sie die Regeln des Projekts, um sicherzustellen, dass der Zugriff nicht missbraucht wird. Siehe die unter Zugehörige Informationen aufgeführten Ressourcen.
Tests, die Angriffe durch Angriffsübungen simulieren
Bei dieser Methode simulierter Angriffe gibt es zwei Teams:
- Das rote Team ist der Gegner, der versucht, reale Angriffe zu simulieren. Wenn sie erfolgreich sind, finden Sie Lücken in Ihrem Sicherheitskonzept und können die Eindämmung des Angriffsradius ihrer Sicherheitsverletzungen bewerten.
- Das blaue Team ist das Workload-Team, das die Angriffe abwehrt. Sie testen ihre Fähigkeit, die Angriffe zu erkennen, darauf zu reagieren und sie zu beheben. Sie validieren die Abwehrmaßnahmen, die zum Schutz der Workload-Ressourcen implementiert wurden.
Wenn Angriffsübungen als Routinetests durchgeführt werden, können sie fortlaufende Transparenz und Gewissheit darüber bieten, dass Ihre Abwehrmaßnahmen wie geplant funktionieren. Mit Angriffsübungen können Sie Ihre Workloads potenziell auf verschiedenen Ebenen testen.
Eine beliebte Wahl zum Simulieren realistischer Angriffsszenarien ist das Microsoft Defender für Office 365 Angriffssimulationstraining.
Weitere Informationen finden Sie unter Erkenntnisse und Berichte zum Angriffssimulationstraining.
Informationen zur Einrichtung des roten Teams und des blauen Teams finden Sie unter Microsoft Cloud Red Teaming.
Umsetzung in Power Platform
Mit der Microsoft Sentinel-Lösung für Microsoft Power Platform können Kunden verschiedene verdächtige Aktivitäten erkennen, darunter:
- Power Apps-Ausführung von nicht autorisierten geografischen Regionen
- Verdächtige Datenvernichtung durch Power Apps
- Massenlöschung von Power Apps
- Phishing-Angriffe durch Power Apps
- Power Automate-Flows-Aktivität durch ausscheidende Mitarbeiter
- Einer Umgebung hinzugefügte Microsoft Power Platform-Konnektoren
- Aktualisierung oder Entfernung von Microsoft Power Platform-Richtlinien zur Verhinderung von Datenverlust
Weitere Informationen finden Sie unter Übersicht über die Microsoft Sentinel-Lösung für Microsoft Power Platform.
Die Produktdokumentation finden Sie unter Hunting-Funktionen in Microsoft Sentinel.
Microsoft Defender for Cloud bietet Scans von Sicherheitsrisikos für verschiedene Technologiebereiche. Weitere Informationen finden Sie unter Prüfung des Sicherheitsrisikos mit Microsoft Defender Vulnerability Management aktivieren.
Die DevSecOps-Praxis integriert Sicherheitstests als Teil einer Denkweise der fortlaufenden und kontinuierlichen Verbesserung. Angriffsübungen sind eine gängige Praxis, die in den Geschäftsrhythmus bei Microsoft integriert ist. Weitere Informationen finden Sie unter Sicherheit in DevOps (DevSecOps).
Azure DevOps unterstützt Tools von Drittanbietern, die als Teil der CI/CD-Pipelines (Continuous Integration/Continuous Deployment) automatisiert werden können. Weitere Informationen finden Sie unter DevSecOps mit Azure und GitHub aktivieren.
Verwandte Informationen
Die neuesten Penetrationstests und Sicherheitsbewertungen finden Sie im Microsoft Service Trust-Portal.
Microsoft führt umfangreiche Tests von Microsoft Cloud Services durch. Zu diesen Tests gehört ein Penetrationstest, dessen Ergebnisse im Service Trust Portal für Ihre Organisation veröffentlicht werden. Ihre Organisation kann für Microsoft Power Platform und Microsoft Dynamics 365-Dienste eigene Penetrationstests durchführen. Alle Penetrationstests müssen den Microsoft Cloud-Regeln für Penetrationstests des Projekts entsprechen. Denken Sie daran, dass die Microsoft Cloud in vielen Fällen eine gemeinsam genutzte Infrastruktur nutzt, um Ihre Assets und die Assets anderer Kunden zu hosten. Sie müssen alle Penetrationstests auf Ihre Assets beschränken und unbeabsichtigte Folgen für andere Kunden in Ihrer Umgebung vermeiden.
Befolgen Sie die Regeln des Projekts, um sicherzustellen, dass der Zugriff nicht missbraucht wird. Hinweise zur Planung und Durchführung simulierter Angriffe finden Sie unter:
Sie können Denial-of-Service-Angriffe (DoS) in Azure simulieren. Befolgen Sie unbedingt die im Azure DDoS Protection-Simulationstest festgelegten Richtlinien.
Sicherheitscheckliste
Lesen Sie die vollständigen Empfehlungen.