Freigeben über


Empfehlungen für Sicherheitstests

Gilt für diese Empfehlung für die Sicherheit von Azure Well-Architected Framework:

SE:11 Richten Sie ein umfassendes Testsystem ein, das Ansätze kombiniert, um Sicherheitsprobleme zu verhindern, Implementierungen der Bedrohungsprävention zu überprüfen und Bedrohungserkennungsmechanismen zu testen.

Strenge Tests sind die Grundlage eines guten Sicherheitsdesigns. Tests sind eine taktische Form der Überprüfung, um sicherzustellen, dass Steuerelemente wie vorgesehen funktionieren. Tests sind auch eine proaktive Möglichkeit, Sicherheitsrisiken im System zu erkennen.

Richten Sie Prüfer durch Kadenz und Überprüfung aus mehreren Perspektiven ein. Sie sollten Innensichten einbeziehen, die Plattform- und Infrastruktur- und Außerhalbbewertungen testen, die das System wie ein externer Angreifer testen.

Dieses Handbuch enthält Empfehlungen zum Testen des Sicherheitsstatus Ihrer Workload. Implementieren Sie diese Testmethoden, um den Widerstand Ihrer Workload gegen Angriffe zu verbessern und Vertraulichkeit, Integrität und Verfügbarkeit von Ressourcen aufrechtzuerhalten.

Definitionen

Ausdruck Definition
Anwendungssicherheitstests (APPLICATION Security Testing, AST) Eine Microsoft Security Development Lifecycle (SDL)-Technik, die Whitebox- und Blackbox-Testmethoden verwendet, um auf Sicherheitsrisiken im Code zu überprüfen.
Black-Box-Tests Eine Testmethodik, die das extern sichtbare Anwendungsverhalten ohne Kenntnis der Internen des Systems überprüft.
Blaues Team Ein Team, das sich gegen die Angriffe des roten Teams in einer Kriegsspielübung wehrt.
Penetrationstests Eine Testmethodik, die ethische Hacking-Techniken verwendet, um die Sicherheitsmaßnahmen eines Systems zu überprüfen.
Rotes Team Ein Team, das die Rolle eines Gegners 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überprüfungs- und Complianceanforderungen unterstützen.
Lebenszyklus der Softwareentwicklung (SDLC) Ein mehrstufiger, systematischer Prozess für die Entwicklung von Softwaresystemen.
Whitebox-Tests Eine Testmethodik, bei der die Struktur des Codes dem Praktiker bekannt ist.

Wichtige Entwurfsstrategien

Tests sind eine nichtverhandelbare Strategie, insbesondere für Sicherheit. Es ermöglicht Ihnen, Sicherheitsprobleme proaktiv zu ermitteln und zu beheben, bevor sie ausgenutzt werden können, und um zu überprüfen, ob die von Ihnen implementierten Sicherheitskontrollen wie entworfen funktionieren.

Der Umfang der Tests muss die Anwendung, Infrastruktur und automatisierte und menschliche Prozesse umfassen.

Hinweis

Dieser Leitfaden unterscheidet zwischen Tests und Vorfallreaktionen. Obwohl Tests ein Erkennungsmechanismus sind, der Probleme vor der Produktion ideal behebt, sollte es nicht mit der Behebung oder Untersuchung verwechselt werden, die als Teil der Reaktion auf Vorfälle durchgeführt wird. Der Aspekt der Wiederherstellung von Sicherheitsvorfällen wird in den Empfehlungen zur Reaktion auf Vorfälle beschrieben.

SDL enthält mehrere Arten von Tests, die Sicherheitsrisiken im Code erfassen, Laufzeitkomponenten überprüfen und ethische Hacking verwenden, um die Sicherheitsresilienz des Systems zu testen. SDL ist eine wichtige Schicht-links-Aktivität. Sie sollten Tests wie statische Codeanalyse und automatisierte Überprüfung der Infrastruktur als Code (IaC) so früh wie möglich im Entwicklungsprozess ausführen.

Beteiligen Sie sich an der Testplanung. Das Arbeitsauslastungsteam entwerfen die Testfälle möglicherweise nicht. Diese Aufgabe wird häufig im Unternehmen zentralisiert oder von externen Sicherheitsexperten abgeschlossen. Das Workloadteam sollte an diesem Entwurfsprozess beteiligt sein, um sicherzustellen, dass sicherheitsvorkehrungen 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 auf strukturierte Weise und mit einem wiederholbaren Prozess aus. Erstellen Sie Ihre Test rigor um Kadenz, Arten von Tests, Faktoren und beabsichtigten Ergebnissen.

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 sie nicht. Sicherheitstools sind hochspezialisiert, und das Erstellen Ihres eigenen Tools kann Risiken mit sich bringen. Nutzen Sie das Know-how und die Tools, die von zentralen SecOps-Teams oder von externen Mitteln angeboten werden, wenn das Workload-Team nicht über diese Expertise verfügt.

Richten Sie separate Umgebungen ein. Tests können als destruktiv oder nicht destruktiv klassifiziert werden. Nicht destruktive Tests sind nicht invasiv. Sie deuten darauf hin, dass ein Problem vorliegt, aber sie ändern die Funktionalität nicht, um das Problem zu beheben. Destruktive Tests sind invasive Tests und können Funktionen beschädigen, indem Daten aus einer Datenbank gelöscht werden.

Tests in Produktionsumgebungen geben Ihnen die besten Informationen, verursachen jedoch die meisten Unterbrechungen. Sie neigen dazu, nur nicht destruktive Tests in Produktionsumgebungen durchzuführen. Tests in Nichtproduktionsumgebungen sind in der Regel weniger störend, stellen aber möglicherweise nicht genau die Konfiguration der Produktionsumgebung auf eine Weise dar, die für die Sicherheit wichtig ist.

Wenn Sie IaC und Automatisierung bereitstellen, überlegen Sie, ob Sie einen isolierten Klon Ihrer Produktionsumgebung für Tests erstellen können. Wenn Sie über einen kontinuierlichen Prozess für Routinetests verfügen, empfehlen wir die Verwendung einer dedizierten Umgebung.

Bewerten Sie immer die Testergebnisse. Tests sind ein verschwendeter Aufwand, wenn die Ergebnisse nicht verwendet werden, um Aktionen zu priorisieren und Verbesserungen vorgelagert vorzunehmen. Dokumentieren Sie die Sicherheitsrichtlinien, einschließlich bewährter Methoden, die Sie aufdecken. Dokumentation, die Ergebnisse und Wartungspläne erfasst, informiert das Team über die verschiedenen Möglichkeiten, wie Angreifer möglicherweise versuchen, die Sicherheit zu verletzen. Führen Sie regelmäßige Sicherheitsschulungen für Entwickler, Administratoren und Tester durch.

Wenn Sie Ihre Testpläne entwerfen, überlegen Sie sich die folgenden Fragen:

  • Wie oft erwarten Sie, dass der Test ausgeführt wird und wie wirkt sich der Test auf Ihre Umgebung aus?

  • Welche Testtypen sollten Sie ausführen?

Regelmäßiges Testen der Arbeitsauslastung

Testen Sie die Workload regelmäßig, um sicherzustellen, dass Änderungen keine Sicherheitsrisiken verursachen und dass keine Regressionen vorhanden sind. 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. In den folgenden Abschnitten finden Sie Empfehlungen zur Häufigkeit der Tests.

Routinetests

Routinetests werden in regelmäßigen Abständen durchgeführt, als Teil Ihrer Standardbetriebsverfahren und zur Erfüllung der Complianceanforderungen. Verschiedene Tests können in unterschiedlichen Abständen ausgeführt werden, aber der Schlüssel besteht darin, 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 tiefe Verteidigung bieten. Diversifizieren Sie die Testsuite, um die Sicherheiten 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 keine Regressionen vorhanden sind. Routinetests helfen bei der Einrichtung eines anfänglichen Benchmarks. Das ist jedoch nur ein Ausgangspunkt. Wenn Sie neue Probleme an den gleichen Punkten des Lebenszyklus entdecken, fügen Sie neue Testfälle hinzu. Die Tests verbessern sich auch mit Wiederholung.

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 mit der Automatisierung verbessern, ausgeglichen mit Peer-Reviews.

Erwägen Sie das Ausführen von Sicherheitstests als Teil einer automatisierten Pipeline oder geplanten Testausführung. 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 menschliche Kenntnisse erfassen können. Manuelle Tests sind gut für explorative Anwendungsfälle und das Auffinden unbekannter Risiken geeignet.

Improvisierte Tests

Improvisierte Tests bieten zeitnahe Überprüfung der Sicherheitsmaßnahmen. Diese Tests werden durch Sicherheitswarnungen ausgelöst, die die Workload zu diesem Zeitpunkt beeinträchtigen könnten. Organisatorische Vorgaben erfordern möglicherweise eine Anhalten-und-Testen-Denkweise, um die Wirksamkeit von Verteidigungsstrategien zu überprüfen, wenn die Warnung zu einem Notfall eskaliert.

Der Vorteil von improvisierten Tests ist bereitschaftsbereit für einen echten Vorfall. Diese Tests können eine Erzwingungsfunktion sein, um Benutzerakzeptanztests (User Acceptance Testing, UAT) durchzuführen.

Das Sicherheitsteam überwacht möglicherweise alle Workloads und führt diese Tests nach Bedarf aus. Als Workloadbesitzer müssen Sie Sicherheitsteams vereinfachen und zusammenarbeiten. Verhandeln Sie genügend Vorlaufzeit mit Sicherheitsteams, damit Sie sich vorbereiten können. Bestätigen und kommunizieren Sie Ihrem Team und den Projektbeteiligten, dass diese Unterbrechungen erforderlich 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 Vorgänge neu geschrieben werden, was andere geplante Arbeiten verzögern kann.

Risiko: Es besteht das Risiko des Unbekannten. Improvisierte Tests können einmalige Anstrengungen ohne etablierte Prozesse oder Werkzeuge sein. Aber das vorherrschende Risiko ist die potenzielle Unterbrechung des Rhythmus des Geschäfts. Sie müssen diese Risiken im Verhältnis zu den Vorteilen bewerten.

Sicherheitsvorfalltests

Es gibt Tests, die die Ursache eines Sicherheitsvorfalls an seiner Quelle erkennen. Diese Sicherheitslücken müssen aufgelöst werden, um sicherzustellen, dass der Vorfall nicht wiederholt wird.

Vorfälle verbessern auch Testfälle im Laufe der Zeit, indem vorhandene Lücken aufgedeckt werden. Das Team sollte die Erkenntnisse aus dem Vorfall anwenden und routinemäßig Verbesserungen integrieren.

Verwenden einer Vielzahl von Tests

Tests können nach Technologie und durch Testmethoden kategorisiert werden. Kombinieren Sie diese Kategorien und Ansätze innerhalb dieser Kategorien, um eine vollständige Abdeckung zu erhalten.

Indem Sie mehrere Tests und Testtypen hinzufügen, können Sie Folgendes ermitteln:

  • Lücken bei Sicherheitskontrollen oder Ausgleichskontrollen.

  • Fehlkonfigurationen.

  • Lücken bei der Observierbarkeit und Erkennungsmethoden.

Eine gute Übung zur Bedrohungsmodellierung kann auf wichtige Bereiche verweisen, um die Testabdeckung und -häufigkeit sicherzustellen. Empfehlungen zur Bedrohungsmodellierung finden Sie unter Empfehlungen zum Sichern eines Entwicklungslebenszyklus.

Die meisten in diesen Abschnitten beschriebenen Tests können als Routinetests ausgeführt werden. Die Wiederholbarkeit kann jedoch in einigen Fällen zu Kosten führen und zu Störungen führen. Berücksichtigen Sie diese Kompromisse sorgfältig.

Tests, die den Technologiestapel überprüfen

Hier sind einige Beispiele für Arten von Tests und deren Fokusbereiche. Die Liste ist nicht vollständig. Testen Sie den gesamten Stapel, einschließlich Anwendungsstapel, Front-End, Back-End, APIs, Datenbanken und alle externen Integrationen.

  • Datensicherheit: Testen Sie die Effektivität von Datenverschlüsselung und Zugriffskontrollen, um sicherzustellen, dass Daten ordnungsgemäß 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 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ädigung und Berechtigungsprobleme abfangen. Weitere Informationen finden Sie unter diesen Communitylinks.

  • Identität: Bewerten Sie, ob die Rollenzuweisungen und bedingte Überprüfungen wie beabsichtigt funktionieren.

Testmethodik

Es gibt viele Perspektiven für Die 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 Arbeitsauslastung 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 einem Teil von Routinetests machen, verwenden Sie eine außenstehende Perspektive, um die Workload zu überprüfen und sicherzustellen, dass die Verteidigung einem Angriff standhalten kann.

  • Basierend auf den gelernten Lektionen aktualisiert das Team sein Wissen und Qualifikationsniveau. Das Team verbessert das Situationsbewusstsein und kann seine Bereitschaft zur Reaktion auf Vorfälle selbst bewerten.

Risiko: Das Testen im Allgemeinen kann sich auf die Leistung auswirken. Möglicherweise treten Geschäftskontinuitätsprobleme auf, wenn destruktive Tests gelöscht oder beschädigte Daten gelöscht werden. Es gibt auch Risiken, die mit der Exposition von Informationen verbunden sind; stellen Sie sicher, dass die Vertraulichkeit der Daten gewahrt bleibt. Stellen Sie die Integrität der Daten nach Abschluss des Tests sicher.

Einige Beispiele für simulierte Tests sind Blackbox- und Whitebox-Tests, Penetrationstests und Kriegsspielübungen.

Blackbox- und Whitebox-Tests

Diese Testtypen bieten zwei verschiedene Perspektiven. Bei Blackbox-Tests sind die Internen des Systems nicht sichtbar. Bei Whitebox-Tests verfügt der Tester über ein gutes Verständnis der Anwendung und hat sogar Zugriff auf Code, Protokolle, Ressourcentopologie und Konfigurationen für die Durchführung des Experiments.

Risiko: Der Unterschied zwischen den beiden Typen ist die Vorabkosten.Risk: The difference between the two types is upfront cost. White-Box-Tests können in Bezug auf die zeitaufwendige Nutzung des Systems teuer sein. In einigen Fällen müssen Sie mit Whitebox-Tests spezielle Tools erwerben. Black-Box-Tests benötigen keine Rampenzeit, aber es ist möglicherweise nicht so effektiv. Möglicherweise müssen Sie zusätzliche Anstrengungen unternehmen, um Probleme aufzudecken. Es ist ein Zeitinvestitionskonflikt.

Tests, die Angriffe durch Penetrationstests simulieren

Sicherheitsexperten, die nicht Teil der IT- oder Anwendungsteams der Organisation sind, führen Penetrationstests oder Pentesting durch. Sie betrachten das System so, wie böswillige Akteure eine Angriffsfläche festlegen. Ihr Ziel ist es, Sicherheitslücken zu finden, indem Informationen gesammelt, Sicherheitsrisiken analysiert und die Ergebnisse gemeldet werden.

Kompromiss: Penetrationstests sind improvisiert und können in Bezug auf Störungen und geldpolitische Investitionen teuer sein, da Pentesting in der Regel ein kostenpflichtiges Angebot von Drittanbietern ist.

Risiko: Eine Pentestübung kann sich auf die Laufzeitumgebung auswirken und die Verfügbarkeit für normalen Datenverkehr stören.

Die Praktiker benötigen möglicherweise Zugriff auf vertrauliche Daten in der gesamten Organisation. Befolgen Sie die Regeln des Engagements, um sicherzustellen, dass der Zugriff nicht missbraucht wird. Weitere Informationen finden Sie in den ressourcenbezogenen Links.

Tests, die Angriffe durch Kriegsspielübungen simulieren

In 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 im Sicherheitsdesign und bewerten den Strahlradius ihrer Verstöße.

  • Das blaue Team ist das Workload-Team, das sich gegen die Angriffe wehrt. Sie testen ihre Fähigkeit, die Angriffe zu erkennen, zu reagieren und zu beheben. Sie überprüfen die Abwehrmaßnahmen, die implementiert wurden, um Workloadressourcen zu schützen.

Wenn sie als Routinetests durchgeführt werden, können Kriegsspielübungen fortlaufende Sichtbarkeit und Sicherheit bieten, dass Ihre Verteidigung wie vorgesehen funktioniert. Kriegsspielübungen können potenziell innerhalb Ihrer Arbeitsauslastungen getestet werden.

Eine beliebte Wahl zum Simulieren realistischer Angriffsszenarien ist die Microsoft Defender für Office 365-Angriffssimulationstraining.

Weitere Informationen finden Sie unter Insights und Berichte für Angriffssimulationstraining.

Informationen zum Einrichten von red-team und blue-team finden Sie unter Microsoft Cloud Red Teaming.

Azure-Erleichterung

Microsoft Sentinel ist ein systemeigenes Steuerelement, das sicherheitsbezogene Informationsereignisverwaltung (SECURITY Information Event Management, SIEM) und Funktionen zur automatisierten Reaktion (SoAR) kombiniert. Mit dieser Lösung werden Ereignisse und Protokolle von verschiedenen verbundenen Quellen analysiert. Basierend auf Datenquellen und deren Warnungen erstellt Microsoft Sentinel Vorfälle und führt Bedrohungsanalysen für die früherkennung aus. Durch intelligente Analysen und Abfragen können Sie proaktiv nach Sicherheitsproblemen suchen. Wenn ein Vorfall vorhanden ist, können Sie Workflows automatisieren. Außerdem können Sie mit Arbeitsmappenvorlagen schnell Einblicke durch Visualisierung gewinnen.

Produktdokumentation finden Sie unter "Suchfunktionen" in Microsoft Sentinel.

Microsoft Defender für Cloud bietet Sicherheitsrisikoüberprüfungen für verschiedene Technologiebereiche. Ausführliche Informationen finden Sie unter Aktivieren der Sicherheitsrisikoüberprüfung mit Microsoft Defender Vulnerability Management – Microsoft Defender für Cloud.

Die Praxis von DevSecOps integriert Sicherheitstests als Teil einer kontinuierlichen und kontinuierlichen Verbesserungsdenken. Kriegsspielübungen sind eine gängige Praxis, die in den Rhythmus des Geschäfts bei Microsoft integriert ist. Weitere Informationen finden Sie unter "Sicherheit in DevOps (DevSecOps)".

Azure DevOps unterstützt Tools von Drittanbietern, die als Teil der kontinuierlichen Integrations- und kontinuierlichen Bereitstellungspipelinen automatisiert werden können. Ausführliche Informationen finden Sie unter Aktivieren von DevSecOps mit Azure und GitHub – Azure DevOps.

Befolgen Sie die Regeln des Engagements, um sicherzustellen, dass der Zugriff nicht missbraucht wird. Anleitungen zum Planen und Ausführen simulierter Angriffe finden Sie in den folgenden Artikeln:

Sie können Denial-of-Service-Angriffe (DoS) in Azure simulieren. Achten Sie darauf, die in Azure DDoS Protection-Simulationstests festgelegten Richtlinien zu befolgen.

Anwendungssicherheitstests: Tools, Typen und bewährte Methoden – GitHub Resources beschreibt die Arten von Testmethoden, die die Buildzeit- und Laufzeitabwehr der Anwendung testen 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 Methoden für Sicherheit für Anwendungen und Testfälle, die häufige Bedrohungen abdecken.

Checkliste für die Sicherheit

Lesen Sie den vollständigen Satz von Empfehlungen.