Empfehlungen für Sicherheitstests
Gilt für die folgende Empfehlung der Sicherheitsprüfliste für Azure Well-Architected Framework:
| SE:11 | Richten Sie ein umfassendes Testsystem ein, das Ansätze kombiniert, um Sicherheitsprobleme zu vermeiden, Implementierungen zur Bedrohungsprävention zu überprüfen und Mechanismen zur Bedrohungserkennung zu testen. |
|---|
Strenge Tests sind die Grundlage eines guten Sicherheitsentwurfs. Das Testen ist eine taktische Form der Validierung, um sicherzustellen, dass Die Steuerelemente wie gewünscht funktionieren. Tests sind auch eine proaktive Möglichkeit, Sicherheitsrisiken im System zu erkennen.
Richten Sie test rigor durch Rhythmus und Überprüfung aus mehreren Perspektiven ein. Sie sollten insider-out-Standpunkte einbeziehen, die Plattform und Infrastruktur testen, und externe Bewertungen, die das System wie ein externer Angreifer testen.
Dieser Leitfaden enthält Empfehlungen zum Testen des Sicherheitsstatus Ihrer Workload. Implementieren Sie diese Testmethoden, um die Widerstandsfähigkeit Ihrer Workload gegen Angriffe zu verbessern und Vertraulichkeit, Integrität und Verfügbarkeit von Ressourcen zu gewährleisten.
Definitionen
| Begriff | Definition |
|---|---|
| Anwendungssicherheitstests (AST) | Ein Microsoft Security Development Lifecycle -Verfahren (SDL), das Whitebox- und Blackbox-Testmethoden verwendet, um auf Sicherheitsrisiken im Code zu überprüfen. |
| Blackbox-Tests | Eine Testmethodik, die das extern sichtbare Anwendungsverhalten ohne Kenntnis der Internen des Systems überprüft. |
| Blaues Team | Ein Team, das sich in einer Kriegsspielübung gegen die Angriffe des roten Teams wehrt. |
| Penetrationstests | Eine Testmethodik, die ethische Hackertechniken verwendet, um die Sicherheitsabwehr eines Systems zu überprüfen. |
| Rotes Team | Ein Team, das die Rolle eines Angreifers spielt und versucht, das System in einer Kriegsspielübung zu hacken. |
| Security Development Lifecycle (SDL) | Eine Reihe von Methoden, die von Microsoft bereitgestellt werden, die Sicherheits- und Complianceanforderungen unterstützen. |
| Softwareentwicklungslebenszyklus (SDLC) | Ein mehrstufiger, systematischer Prozess zur Entwicklung von Softwaresystemen. |
| Whitebox-Tests | Eine Testmethodik, bei der die Struktur des Codes dem Praktiker bekannt ist. |
Wichtige Entwurfsstrategien
Testen ist eine nicht verhandelbare Strategie, insbesondere für die Sicherheit. Sie ermöglicht es Ihnen, Sicherheitsprobleme proaktiv zu ermitteln und zu beheben, bevor sie ausgenutzt werden können, und zu überprüfen, ob die von Ihnen implementierten Sicherheitskontrollen wie vorgesehen funktionieren.
Der Umfang der Tests muss die Anwendung, Die Infrastruktur sowie automatisierte und menschliche Prozesse umfassen.
Hinweis
In diesem Leitfaden wird zwischen Tests und Reaktion auf Vorfälle unterschieden. Obwohl das Testen ein Erkennungsmechanismus ist, der Probleme idealerweise vor der Produktion behebt, sollte er nicht mit der Korrektur oder Untersuchung verwechselt werden, die im Rahmen der Reaktion auf Vorfälle durchgeführt wird. Der Aspekt der Wiederherstellung nach Sicherheitsvorfällen wird unter Empfehlungen zur Reaktion auf Vorfälle beschrieben.
SDL umfasst mehrere Arten von Tests, die Sicherheitsrisiken im Code abfangen, Laufzeitkomponenten überprüfen und ethisches Hacken verwenden, um die Sicherheitsresilienz des Systems zu testen. SDL ist eine wichtige Verschiebungs-Links-Aktivität. Sie sollten Tests wie statische Codeanalyse und automatisierte Überprüfung von Infrastructure-as-Code (IaC) so früh wie möglich im Entwicklungsprozess ausführen.
In die Testplanung einbezogen werden. Das Workloadteam entwerfen die Testfälle möglicherweise nicht. Diese Aufgabe wird häufig im Unternehmen zentralisiert oder von externen Sicherheitsexperten erledigt. Das Workloadteam sollte an diesem Entwurfsprozess beteiligt werden, um sicherzustellen, dass Sicherheitsgarantien in die Funktionalität der Anwendung integriert werden.
Denken Sie wie ein Angreifer. Entwerfen Sie Ihre Testfälle mit der Annahme, dass das System angegriffen wurde. Auf diese Weise können Sie die potenziellen Sicherheitsrisiken aufdecken und die Tests entsprechend priorisieren.
Führen Sie Tests strukturiert und mit einem wiederholbaren Prozess aus. Erstellen Sie Ihre Testdisziplin anhand des Rhythmus, der Arten von Tests, der treibenden Faktoren und der beabsichtigten Ergebnisse.
Verwenden Sie das richtige Tool für den Auftrag. Verwenden Sie Tools, die für die Arbeit mit der Workload konfiguriert sind. Wenn Sie kein Tool haben, kaufen Sie das Tool. Erstellen Sie es nicht. Sicherheitstools sind hochspezialisiert, und das Erstellen eines eigenen Tools kann Risiken mit sich bringen. Nutzen Sie das Fachwissen und die Tools, die von zentralen SecOps-Teams oder auf externem Wege angeboten werden, wenn das Workloadteam nicht über dieses Fachwissen verfügt.
Richten Sie separate Umgebungen ein. Tests können als destruktiv oder nicht destruktiv klassifiziert werden. Nicht destruktive Tests sind nicht invasiv. Sie weisen darauf hin, dass ein Problem vorliegt, aber sie ändern die Funktionalität nicht, um das Problem zu beheben. Destruktive Tests sind invasiv und können die Funktionalität beeinträchtigen, indem Daten aus einer Datenbank gelöscht werden.
Das Testen in Produktionsumgebungen liefert Ihnen die besten Informationen, verursacht aber die meisten Unterbrechungen. Sie neigen dazu, in Produktionsumgebungen nur nicht destruktive Tests durchzuführen. Tests in Nichtproduktionsumgebungen sind in der Regel weniger störend, stellen aber möglicherweise die Konfiguration der Produktionsumgebung in einer für die Sicherheit wichtigen Weise nicht genau dar.
Wenn Sie die Bereitstellung mithilfe von IaC und Automatisierung durchführen, sollten Sie überlegen, ob Sie einen isolierten Klon Ihrer Produktionsumgebung zu Testzwecken erstellen können. Wenn Sie über einen kontinuierlichen Prozess für Routinetests verfügen, wird die Verwendung einer dedizierten Umgebung empfohlen.
Werten Sie die Testergebnisse immer aus. Das Testen ist ein vergeudeter Aufwand, wenn die Ergebnisse nicht dazu verwendet werden, Aktionen zu priorisieren und Verbesserungen Upstream vorzunehmen. Dokumentieren Sie die Sicherheitsrichtlinien, einschließlich bewährter Methoden, die Sie aufdecken. Die Dokumentation, in der Ergebnisse und Wartungspläne erfasst werden, informiert das Team über die verschiedenen Möglichkeiten, mit denen Angreifer versuchen können, die Sicherheit zu verletzen. Führen Sie regelmäßige Sicherheitsschulungen für Entwickler, Administratoren und Tester durch.
Berücksichtigen Sie beim Entwerfen Ihrer Testpläne die folgenden Fragen:
Wie oft erwarten Sie, dass der Test ausgeführt wird, und wie wirkt er sich auf Ihre Umgebung aus?
Welche verschiedenen Testtypen sollten Sie ausführen?
Wie oft wird erwartet, dass die Tests ausgeführt werden?
Testen Sie die Workload regelmäßig, um sicherzustellen, dass Änderungen keine Sicherheitsrisiken mit sich bringen und keine Regressionen auftreten. Das Team muss auch bereit sein, auf Sicherheitsüberprüfungen der Organisation 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 im regelmäßigen Rhythmus als Teil Ihrer Standardbetriebsverfahren und zur Erfüllung von Complianceanforderungen durchgeführt. Verschiedene Tests können in unterschiedlichen Abständen ausgeführt werden, aber der Schlüssel ist, dass sie regelmäßig und nach einem Zeitplan durchgeführt werden.
Sie sollten diese Tests in Ihr SDLC integrieren, da sie in jeder Phase eine umfassende Verteidigung bieten. Diversifizierung der Testsammlung, um Zusicherungen für Identität, Datenspeicherung und -übertragung sowie Kommunikationskanäle 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 zu erstellen. Dies ist jedoch nur ein Ausgangspunkt. Wenn Sie neue Probleme an denselben Punkten des Lebenszyklus aufdecken, fügen Sie neue Testfälle hinzu. Die Tests verbessern sich auch mit Wiederholungen.
In jeder Phase sollten diese Tests Code überprüfen, der hinzugefügt oder entfernt wurde, oder Konfigurationseinstellungen, die geändert wurden, um die Auswirkungen dieser Änderungen auf die Sicherheit zu erkennen. Sie sollten die Wirksamkeit der Tests durch Automatisierung verbessern, ausgeglichen mit Peer Reviews.
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 Sicherheitsrisiken zu erkennen, die nur durch menschliches Fachwissen erfasst werden können. Manuelle Tests eignen sich gut für explorative Anwendungsfälle und die Suche nach unbekannten Risiken.
Improvisierte Tests
Improvisierte Tests bieten eine Point-in-Time-Validierung von Sicherheitsschutzmaßnahmen. Sicherheitswarnungen, die sich möglicherweise auf die Workload zu diesem Zeitpunkt auswirken, lösen diese Tests aus. Organisationsmandate erfordern möglicherweise eine Pausen- und Testmentalität, um die Wirksamkeit von Verteidigungsstrategien zu überprüfen, wenn die Warnung zu einem Notfall eskaliert.
Der Vorteil von improvisierten Tests ist die Vorbereitung auf einen realen Vorfall. Diese Tests können eine Erzwingungsfunktion sein, um Benutzerakzeptanztests (User Acceptance Testing, UAT) durchzuführen.
Das Sicherheitsteam kann alle Workloads überwachen und diese Tests bei Bedarf ausführen. Als Workloadbesitzer müssen Sie die Zusammenarbeit mit Sicherheitsteams erleichtern und mit ihnen zusammenarbeiten. Verhandeln Sie genügend Vorlaufzeit mit Sicherheitsteams, damit Sie sich vorbereiten können. Erkennen Sie Ihr Team und Ihre Beteiligten an und kommunizieren Sie, dass diese Unterbrechungen notwendig sind.
In anderen Fällen müssen Sie möglicherweise Tests ausführen und den Sicherheitsstatus des Systems gegen die potenzielle Bedrohung melden.
Kompromiss: Da improvisierte Tests störende Ereignisse sind, erwarten Sie, dass Aufgaben neu geschrieben werden, was andere geplante Arbeiten verzögern kann.
Risiko: Es besteht die Gefahr des Unbekannten. Improvisierte Tests können einmalige Anstrengungen ohne etablierte Prozesse oder Tools sein. Das vorherrschende Risiko ist jedoch die mögliche Unterbrechung des Geschäftsrhythmus. Sie müssen diese Risiken im Verhältnis zu den Vorteilen bewerten.
Tests für Sicherheitsvorfälle
Es gibt Tests, die die Ursache eines Sicherheitsvorfalls an der Quelle erkennen. Diese Sicherheitslücken müssen behoben werden, um sicherzustellen, dass sich der Vorfall nicht wiederholt.
Incidents verbessern auch Testfälle im Laufe der Zeit, indem vorhandene Lücken aufgedeckt werden. Das Team sollte die aus dem Vorfall gewonnenen Erkenntnisse anwenden und routinemäßig Verbesserungen integrieren.
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 Hinzufügen mehrerer Tests und Testtypen können Sie Folgendes ermitteln:
Lücken in Sicherheitskontrollen oder ausgleichende Kontrollen.
Fehlkonfigurationen.
Lücken bei Beobachtbarkeit und Erkennungsmethoden.
Eine gute Bedrohungsmodellierungsübung kann auf wichtige Bereiche verweisen, um die Testabdeckung und -häufigkeit sicherzustellen. Empfehlungen zur Bedrohungsmodellierung finden Sie unter Empfehlungen zum Schützen eines Entwicklungslebenszyklus.
Die meisten in diesen Abschnitten beschriebenen Tests können als Routinetests ausgeführt werden. Die Wiederholbarkeit kann jedoch in einigen Fällen Kosten verursachen und zu Störungen führen. Berücksichtigen Sie diese Kompromisse sorgfältig.
Tests zum Überprüfen des Technologiestapels
Hier finden Sie einige Beispiele für Testtypen und deren Fokusbereiche. Die Liste ist nicht vollständig. Testen Sie den gesamten Stapel, einschließlich Anwendungsstapel, Front-End, Back-End, APIs, Datenbanken und allen externen Integrationen.
Datensicherheit: Testen Sie die Wirksamkeit von Datenverschlüsselung und Zugriffskontrollen, um sicherzustellen, dass Die Daten ordnungsgemäß vor unbefugtem Zugriff und Manipulationen geschützt sind.
Netzwerk und Konnektivität: Testen Sie Ihre Firewalls, um sicherzustellen, dass sie nur erwarteten, zulässigen und sicheren Datenverkehr für die Workload zulassen.
Anwendung: Testen Sie Quellcode mithilfe von AST-Techniken (Application Security Testing), um sicherzustellen, dass Sie sichere Codierungsmethoden befolgen und Laufzeitfehler wie Speicherbeschädigungen und Rechteprobleme abfangen. Ausführliche Informationen finden Sie unter diesen Communitylinks.
Identität: Bewerten Sie, ob die Rollenzuweisungen und bedingten Überprüfungen wie vorgesehen funktionieren.
Testmethodik
Es gibt viele Perspektiven für Testmethoden. Wir empfehlen Tests, die die Bedrohungssuche ermöglichen, indem reale Angriffe simuliert werden. Sie können potenzielle Bedrohungsakteure, ihre Techniken und ihre Exploits identifizieren, die eine Bedrohung für die Workload darstellen. Machen Sie die Angriffe so realistisch wie möglich. Verwenden 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 Routinetests machen, verwenden Sie eine Externe Perspektive, um die Workload zu überprüfen und sicherzustellen, dass die Verteidigung einem Angriff standhalten kann.
Basierend auf den Lektionen, die es gelernt hat, aktualisiert das Team sein Wissen und sein Qualifikationsniveau. Das Team verbessert das Situationsbewusstsein und kann seine Bereitschaft, auf Vorfälle zu reagieren, selbst beurteilen.
Einige Beispiele für simulierte Tests sind Blackbox- und Whiteboxtests, Penetrationstests und Übungen für Kriegsspiele.
Blackbox- und Whiteboxtests
Diese Testtypen bieten zwei unterschiedliche Perspektiven. In Blackbox-Tests sind die Internen des Systems nicht sichtbar. Bei Whiteboxtests hat der Tester ein gutes Verständnis der Anwendung und hat sogar Zugriff auf Code, Protokolle, Ressourcentopologie und Konfigurationen für die Durchführung des Experiments.
Tests zur Simulation von Angriffen durch Penetrationstests
Sicherheitsexperten, die nicht teil der IT- oder Anwendungsteams des organization sind, führen Penetrationstests oder Pentesting durch. Sie betrachten das System so, wie böswillige Akteure eine Angriffsfläche ausweiten. Ihr Ziel ist es, Sicherheitslücken zu finden, indem Sie Informationen sammeln, Sicherheitsrisiken analysieren und die Ergebnisse melden.
Die Praktizierenden benötigen möglicherweise Zugriff auf vertrauliche Daten in der gesamten organization. Befolgen Sie die Regeln des Engagements, um sicherzustellen, dass der Zugriff nicht missbraucht wird. Weitere Informationen finden Sie unter Verwandte Links.
Tests, die Angriffe durch Kriegsspielübungen simulieren
Bei dieser Methodik simulierter Angriffe gibt es zwei Teams:
Das rote Team ist der Gegner, der versucht, reale Angriffe zu modellieren. Wenn sie erfolgreich sind, finden Sie Lücken in Ihrem Sicherheitsdesign und bewerten den Explosionsradius der Sicherheitsverletzungen.
Das blaue Team ist das Workloadteam, das sich gegen die Angriffe schützt. Sie testen ihre Fähigkeit, die Angriffe zu erkennen, zu reagieren und zu beheben. Sie überprüfen die Schutzmaßnahmen, die zum Schutz von Workloadressourcen implementiert wurden.
Wenn sie als Routinetests durchgeführt werden, können Kriegsspielübungen fortlaufende Sichtbarkeit und Sicherheit bieten, dass Ihre Verteidigung wie geplant funktioniert. Kriegsspielübungen können möglicherweise ebenenübergreifend innerhalb Ihrer Workloads getestet werden.
Eine beliebte Wahl zum Simulieren realistischer Angriffsszenarien ist die Microsoft Defender for Office 365 Angriffssimulationstraining.
Weitere Informationen finden Sie unter Erkenntnisse und Berichte für Angriffssimulationstraining.
Informationen zur Einrichtung von red-team und blue-team finden Sie unter Microsoft Cloud Red Teaming.
Azure-Erleichterung
Microsoft Sentinel ist ein systemeigenes Steuerelement, das Siem (Security Information Event Management) und soAR (Security Orchestration Automated Response) funktionen kombiniert. Mit dieser Lösung werden Ereignisse und Protokolle von verschiedenen verbundenen Quellen analysiert. Basierend auf Datenquellen und deren Warnungen erstellt Microsoft Sentinel Incidents und führt Bedrohungsanalysen zur Früherkennung durch. Durch intelligente Analysen und Abfragen können Sie proaktiv nach Sicherheitsproblemen suchen. Wenn ein Incident vorliegt, können Sie Workflows automatisieren. Außerdem können Sie mit Arbeitsmappenvorlagen schnell Einblicke durch Visualisierung gewinnen.
Die Produktdokumentation finden Sie unter Hunting capabilities in Microsoft Sentinel.
Microsoft Defender für Cloud bietet Sicherheitsrisikoüberprüfungen für verschiedene Technologiebereiche. Ausführliche Informationen finden Sie unter Aktivieren der Überprüfung von Sicherheitsrisiken mit Microsoft Defender Vulnerability Management – Microsoft Defender für Cloud.
Die Praxis von DevSecOps integriert Sicherheitstests als Teil einer kontinuierlichen Verbesserungsmentalität. Kriegsspielü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 im Rahmen der Pipelines für continuous Integration/Continuous Deployment automatisiert werden können. Weitere Informationen finden Sie unter Aktivieren von DevSecOps mit Azure und GitHub – Azure DevOps.
Verwandte Links
Befolgen Sie die Regeln des Engagements, um sicherzustellen, dass der Zugriff nicht missbraucht wird. Eine Anleitung zum Planen und Ausführen simulierter Angriffe finden Sie in den folgenden Artikeln:
Sie können Denial-of-Service-Angriffe (DoS) in Azure simulieren. Befolgen Sie unbedingt die Richtlinien, die unter Simulationstests für Azure DDoS Protection beschrieben sind.
Communitylinks
Anwendungssicherheitstests: Tools, Typen und bewährte Methoden: GitHub Resources beschreibt die Arten von Testmethoden, mit denen die Buildzeit- und Laufzeitschutzmaßnahmen der Anwendung getestet werden können.
Der Ausführungsstandard für Penetrationstests (PTES) bietet Richtlinien zu gängigen Szenarien und den Aktivitäten, die zum Erstellen einer Basislinie erforderlich sind.
OWASP Top Ten | OWASP Foundation bietet bewährte Sicherheitsmethoden für Anwendungen und Testfälle, die häufige Bedrohungen abdecken.
Checkliste für die Sicherheit
Sehen Sie sich den vollständigen Satz von Empfehlungen an.
Feedback
Bald verfügbar: Im Laufe des Jahres 2024 werden wir GitHub-Issues stufenweise als Feedbackmechanismus für Inhalte abbauen und durch ein neues Feedbacksystem ersetzen. Weitere Informationen finden Sie unter https://aka.ms/ContentUserFeedback.
Feedback senden und anzeigen für