Freigeben über


Microsoft Entra ID und PCI-DSS-Anforderung 11

Anforderung 11: Regelmäßiges Testen der Sicherheit von Systemen und Netzwerken
Anforderungen des definierten Ansatzes

11.1 Prozesse und Mechanismen zum regelmäßigen Testen der Sicherheit von Systemen und Netzwerken sind definiert und werden verstanden.

Anforderungen des durch PCI DSS definierten Ansatzes Leitfaden und Empfehlungen für Microsoft Entra
11.1.1 Alle Sicherheitsrichtlinien und Betriebsabläufe, die in Anforderung 11 identifiziert werden, sind:
Dokumentiert
Auf dem neuesten Stand
In Gebrauch
Allen betroffenen Parteien bekannt
Verwenden Sie die hierin enthaltenen Anleitungen und Links zur Erstellung der Dokumentation, um die Anforderungen basierend auf Ihrer Umgebungskonfiguration zu erfüllen.
11.1.2 Rollen und Verantwortlichkeiten für die Durchführung von Aktivitäten in der Anforderung 11 sind dokumentiert, zugewiesen und verstanden. Verwenden Sie die hierin enthaltenen Anleitungen und Links zur Erstellung der Dokumentation, um die Anforderungen basierend auf Ihrer Umgebungskonfiguration zu erfüllen.

11.2 Drahtlose Zugangspunkte sind identifiziert und überwacht, und nicht autorisierte drahtlose Zugangspunkte werden adressiert.

Anforderungen des durch PCI DSS definierten Ansatzes Leitfaden und Empfehlungen für Microsoft Entra
11.2.1 Autorisierte und nicht autorisierte drahtlose Zugangspunkte werden wie folgt verwaltet:
Das Vorhandensein von drahtlosen (WLAN) Zugangspunkten wird getestet für.
Alle autorisierten und nicht autorisierten drahtlosen Zugangspunkte sind erkannt und identifiziert.
Testen, Erkennen und Identifizierung findet mindestens alle drei Monate statt.
Wenn eine automatisierte Überwachung verwendet wird, werden die Mitarbeiter über generierte Warnungen benachrichtigt.
Wenn Ihre Organisation Netzwerkzugriffspunkte für die Authentifizierung in Microsoft Entra ID integriert, lesen Sie Anforderung 1: Installation und Wartung von Netzwerksicherheitskontrollen.
11.2.2 Es wird ein Inventar autorisierter drahtloser Zugangspunkte geführt, einschließlich einer dokumentierten geschäftlichen Begründung. Gilt nicht für Microsoft Entra ID.

11.3 Externe und interne Sicherheitsrisiken werden regelmäßig identifiziert, priorisiert und adressiert.

Anforderungen des durch PCI DSS definierten Ansatzes Leitfaden und Empfehlungen für Microsoft Entra
11.3.1 Interne Sicherheitsrisikoscans werden wie folgt durchgeführt:
Mindestens einmal alle drei Monate.
Risikoreiche und kritische Sicherheitsrisiken (gemäß den unter Anforderung 6.3.1 definierten Einstufungen für Sicherheitsrisiken der Entität) werden behoben.
Erneute Scans werden durchgeführt, die bestätigen, dass alle risikoreichen und kritischen Sicherheitsrisiken (wie festgestellt) behoben wurden.
Das Scantool wird aktuell gehalten mit den neuesten Sicherheitsrisikoinformationen.
Scans werden von qualifiziertem Personal durchgeführt und die organisatorische Unabhängigkeit des Testers besteht.
Schließen Sie Server ein, die Microsoft Entra-Hybridfunktionen unterstützen. Beispiel: Microsoft Entra Connect, Anwendungsproxyconnectors usw. als Teil der interner Sicherheitsrisikoscans.
Organisationen, die Verbundauthentifizierung verwenden: Überprüfen und beheben Sie Sicherheitsrisiken in der Verbundsysteminfrastruktur. Was ist ein Verbund mit Microsoft Entra ID?
Überprüfen und mindern Sie die von Microsoft Entra ID Protection gemeldeten Risikoerkennungen. Integrieren Sie die Signale in eine SIEM-Lösung, um besser in Wartungsworkflows oder Automatisierungen zu integrieren. Risikotypen und Erkennung
Führen Sie das Microsoft Entra-Bewertungstool regelmäßig aus, und beheben Sie die Ergebnisse. AzureADAssessment
Sicherheitsvorgänge für die Infrastruktur
Integrieren von Microsoft Entra-Protokollen in Azure Monitor-Protokolle
11.3.1.1 Alle anderen anwendbaren Sicherheitsrisiken (diejenigen, die gemäß den unter Anforderung 6.3.1 definierten Risikoeinstufung der Entität nicht als risikoreich oder kritisch eingestuft werden) werden wie folgt verwaltet:
Adressiert basierend auf dem Risiko, das in der gezielten Risikoanalyse der Entität definiert ist, die gemäß allen in Anforderung 12.3.1 angegebenen Elementen durchgeführt wird.
Erneute Scans werden bei Bedarf durchgeführt.
Schließen Sie Server ein, die Microsoft Entra-Hybridfunktionen unterstützen. Beispiel: Microsoft Entra Connect, Anwendungsproxyconnectors usw. als Teil der interner Sicherheitsrisikoscans.
Organisationen, die Verbundauthentifizierung verwenden: Überprüfen und beheben Sie Sicherheitsrisiken in der Verbundsysteminfrastruktur. Was ist ein Verbund mit Microsoft Entra ID?
Überprüfen und mindern Sie die von Microsoft Entra ID Protection gemeldeten Risikoerkennungen. Integrieren Sie die Signale in eine SIEM-Lösung, um besser in Wartungsworkflows oder Automatisierungen zu integrieren. Risikotypen und Erkennung
Führen Sie das Microsoft Entra-Bewertungstool regelmäßig aus, und beheben Sie die Ergebnisse. AzureAD/AzureADAssessment
Sicherheitsvorgänge für die Infrastruktur
Integrieren von Microsoft Entra-Protokollen in Azure Monitor-Protokolle
11.3.1.2 Interne Sicherheitsrisikoscans werden wie folgt über authentifizierte Scans durchgeführt:
Systeme, die keine Anmeldeinformationen für authentifizierte Scans akzeptieren können, werden dokumentiert.
Für Systeme, die Anmeldeinformationen für das Scannen akzeptieren, werden ausreichende Berechtigungen verwendet.
Wenn Konten, die für authentifiziertes Scannen verwendet werden, für die interaktive Anmeldung verwendet werden können, werden sie gemäß Anforderung 8.2.2 verwaltet.
Schließen Sie Server ein, die Microsoft Entra-Hybridfunktionen unterstützen. Beispiel: Microsoft Entra Connect, Anwendungsproxyconnectors usw. als Teil der interner Sicherheitsrisikoscans.
Organisationen, die Verbundauthentifizierung verwenden: Überprüfen und beheben Sie Sicherheitsrisiken in der Verbundsysteminfrastruktur. Was ist ein Verbund mit Microsoft Entra ID?
Überprüfen und mindern Sie die von Microsoft Entra ID Protection gemeldeten Risikoerkennungen. Integrieren Sie die Signale in eine SIEM-Lösung, um besser in Wartungsworkflows oder Automatisierungen zu integrieren. Risikotypen und Erkennung
Führen Sie das Microsoft Entra-Bewertungstool regelmäßig aus, und beheben Sie die Ergebnisse. AzureADAssessment
Sicherheitsvorgänge für die Infrastruktur
Integrieren von Microsoft Entra-Protokollen in Azure Monitor-Protokolle
11.3.1.3 Interne Sicherheitsrisikoscans werden nach jeder wesentlichen Änderung wie folgt durchgeführt:
Risikoreiche und kritische Sicherheitsrisiken (gemäß den unter Anforderung 6.3.1 definierten Einstufungen der Sicherheitsrisiken der Entität) werden behoben.
Erneute Scans werden bei Bedarf durchgeführt.
Scans werden von qualifiziertem Personal durchgeführt, und die organisatorische Unabhängigkeit des Testers besteht (muss kein Qualified Security Assessor (QSA) oder Approved Scanning Vendor (ASV) sein).
Schließen Sie Server ein, die Microsoft Entra-Hybridfunktionen unterstützen. Beispiel: Microsoft Entra Connect, Anwendungsproxyconnectors usw. als Teil der interner Sicherheitsrisikoscans.
Organisationen, die Verbundauthentifizierung verwenden: Überprüfen und beheben Sie Sicherheitsrisiken in der Verbundsysteminfrastruktur. Was ist ein Verbund mit Microsoft Entra ID?
Überprüfen und mindern Sie die von Microsoft Entra ID Protection gemeldeten Risikoerkennungen. Integrieren Sie die Signale in eine SIEM-Lösung, um besser in Wartungsworkflows oder Automatisierungen zu integrieren. Risikotypen und Erkennung
Führen Sie das Microsoft Entra-Bewertungstool regelmäßig aus, und beheben Sie die Ergebnisse. AzureADAssessment
Sicherheitsvorgänge für die Infrastruktur
Integrieren von Microsoft Entra-Protokollen in Azure Monitor-Protokolle
11.3.2 Externe Sicherheitsrisikoscans werden wie folgt durchgeführt:
Mindestens einmal alle drei Monate.
Durch eine PCI SSC-ASV.
Sicherheitsrisiken werden behoben, und die Anforderungen des ASV-Programmleitfadens für einen bestandenen Scan werden erfüllt.
Nach Bedarf werden erneute Scans durchgeführt, um zu bestätigen, dass Sicherheitsrisiken gemäß den Anforderungen des ASV-Programmleitfadens für eine bestandene Überprüfung behoben werden.
Gilt nicht für Microsoft Entra ID.
11.3.2.1 Externe Sicherheitsrisikoscans werden nach jeder wesentlichen Änderung wie folgt durchgeführt:
Sicherheitsrisiken, die vom CVSS mit 4.0 oder höher bewertet werden, werden behoben.
Erneute Scans werden bei Bedarf durchgeführt.
Scans werden von qualifiziertem Personal durchgeführt und die organisatorische Unabhängigkeit des Testers besteht (muss kein QSA oder ASV sein).
Gilt nicht für Microsoft Entra ID.

11.4 Externe und interne Penetrationstests werden regelmäßig durchgeführt, und ausnutzbare Sicherheitsrisiken und Sicherheitsschwachstellen werden behoben.

Anforderungen des durch PCI DSS definierten Ansatzes Leitfaden und Empfehlungen für Microsoft Entra
11.4.1 Eine Methodik für Penetrationstests wird von der Entität definiert, dokumentiert und implementiert und umfasst:
Branchenweit akzeptierte Penetrationstestvorgehen.
Abdeckung für die gesamte Karteninhaberdatenumgebung (Cardholder Data Environment, CDE) und kritische Systeme.
Tests werden sowohl von innerhalb als auch von außerhalb des Netzwerks durchgeführt.
Tests zum Überprüfen allfälliger Segmentierung und Kontrollen zur Reduktion des Umfangs.
Penetrationstests auf Anwendungsebene, um mindestens die in Anforderung 6.2.4 aufgelisteten Sicherheitsrisiken zu identifizieren.
Penetrationstests auf Netzwerkebene, die alle Komponenten umfassen, die Netzwerkfunktionen und Betriebssysteme unterstützen.
Überprüfen und Berücksichtigen von Bedrohungen und Sicherheitsrisiken, die in den letzten 12 Monaten aufgetreten sind.
Dokumentierter Ansatz zur Bewertung und Adressierung des Risikos durch ausnutzbare Sicherheitsrisiken und Sicherheitsschwachstellen, die bei Penetrationstests gefunden wurden.
Aufbewahrung der Ergebnisse von Penetrationstests und Korrekturaktivitäten für mindestens 12 Monate.
Einsatzregeln für Penetrationstests, Microsoft Cloud
11.4.2 Interne Penetrationstests werden durchgeführt:
Gemäß der definierten Methodik der Entität.
Mindestens einmal alle 12 Monate.
Nach jedem signifikanten Upgrade oder jeder signifikanten Änderung der Infrastruktur oder Anwendungen.
Durch eine qualifizierte interne Ressource oder einen qualifizierten externen Drittanbieter.
Die organisatorische Unabhängigkeit des Testers ist gegeben (muss kein QSA oder ASV sein).
Einsatzregeln für Penetrationstests, Microsoft Cloud
11.4.3 Externe Penetrationstests werden durchgeführt:
Gemäß der definierten Methodik der Entität.
Mindestens einmal alle 12 Monate.
Nach jedem signifikanten Upgrade oder jeder signifikanten Änderung der Infrastruktur oder Anwendungen.
Durch eine qualifizierte interne Ressource oder einen qualifizierten externen Drittanbieter.
Die organisatorische Unabhängigkeit des Testers ist gegeben (muss kein QSA oder ASV sein).
Einsatzregeln für Penetrationstests, Microsoft Cloud
11.4.4 Ausnutzbare Sicherheitsrisiken und Sicherheitsschwachstellen, die bei Penetrationstests gefunden wurden, werden wie folgt korrigiert:
Gemäß der Bewertung der Entität bezüglich des Risikos durch das Sicherheitsproblem wie in Anforderung 6.3.1 definiert.
Penetrationstests werden wiederholt, um die Korrekturen zu überprüfen.
Einsatzregeln für Penetrationstests, Microsoft Cloud
11.4.5 Wenn die Segmentierung verwendet wird, um die CDE von anderen Netzwerken zu isolieren, werden Penetrationstests für Segmentierungskontrollen wie folgt durchgeführt:
Mindestens einmal alle 12 Monate und nach jeder Änderung an Segmentierungskontrollen/-methoden.
Deckt alle verwendeten Segmentierungskontrollen/-mechanismen ab.
Gemäß den definierten Testmethode für Penetrationstests der Entität.
Bestätigen, dass die Segmentierungskontrollen/-methoden betriebsbereit und effektiv sind und die CDE von allen Systemen außerhalb des Bereichs isolieren.
Bestätigen der Wirksamkeit jeglicher Isolierung zur Trennung von Systemen mit unterschiedlichen Sicherheitsstufen (siehe Anforderung 2.2.3).
Durchgeführt durch eine qualifizierte interne Ressource oder einen qualifizierten externen Drittanbieter.
Die organisatorische Unabhängigkeit des Testers ist gegeben (muss kein QSA oder ASV sein).
Gilt nicht für Microsoft Entra ID.
11.4.6Zusätzliche Anforderung nur für Dienstanbieter: Wenn die Segmentierung verwendet wird, um die CDE von anderen Netzwerken zu isolieren, werden Penetrationstests für Segmentierungskontrollen wie folgt durchgeführt:
Mindestens einmal alle sechs Monate und nach jeder Änderung an Segmentierungskontrollen/-methoden.
Deckt alle verwendeten Segmentierungskontrollen/-mechanismen ab.
Gemäß den definierten Testmethode für Penetrationstests der Entität.
Bestätigen, dass die Segmentierungskontrollen/-methoden betriebsbereit und effektiv sind und die CDE von allen Systemen außerhalb des Bereichs isolieren.
Bestätigen der Wirksamkeit jeglicher Isolierung zur Trennung von Systemen mit unterschiedlichen Sicherheitsstufen (siehe Anforderung 2.2.3).
Durchgeführt durch eine qualifizierte interne Ressource oder einen qualifizierten externen Drittanbieter.
Die organisatorische Unabhängigkeit des Testers ist gegeben (muss kein QSA oder ASV sein).
Gilt nicht für Microsoft Entra ID.
11.4.7Zusätzliche Anforderung nur für mehrmandantenfähige Dienstanbieter: Mehrmandantenfähige Dienstanbieter unterstützen ihre Kunden bei externen Penetrationstests gemäß Anforderung 11.4.3 und 11.4.4. Einsatzregeln für Penetrationstests, Microsoft Cloud

11.5 Eindringversuche in das Netzwerk und unerwartete Dateiänderungen werden erkannt, und es wird darauf reagiert.

Anforderungen des durch PCI DSS definierten Ansatzes Leitfaden und Empfehlungen für Microsoft Entra
11.5.1 Techniken zur Erkennung und/oder Verhinderung von Eindringversuchen werden verwendet, um Eindringversuche in das Netzwerk wie folgt zu erkennen und/oder zu verhindern:
Der gesamte Datenverkehr wird im Umkreis des CDE überwacht.
Der gesamte Datenverkehr wird an kritischen Punkten im CDE überwacht.
Das Personal wird bei vermuteten Kompromittierungen alarmiert.
Alle Module, Baselines und Signaturen zur Erkennung und Verhinderung von Eindringversuchen sind auf dem neuesten Stand.
Gilt nicht für Microsoft Entra ID.
11.5.1.1Zusätzliche Anforderung nur für Dienstanbieter: Techniken zur Erkennung und/oder Verhinderung von Eindringversuchen erkennen, warnen/verhindern und adressieren verdeckte Malware-Kommunikationskanäle. Gilt nicht für Microsoft Entra ID.
11.5.2 Ein Änderungserkennungsmechanismus (z. B. Tools zur Überwachung der Dateiintegrität) wird wie folgt bereitgestellt:
Zum Benachrichtigen des Personals bei nicht autorisierten Änderungen (einschließlich Änderungen, Ergänzungen und Löschungen) kritischer Dateien.
Zum Durchführen von Vergleichen kritischer Dateien mindestens einmal pro Woche.
Gilt nicht für Microsoft Entra ID.

11.6 Nicht autorisierte Änderungen auf Zahlungsseiten werden erkannt, und es wird darauf reagiert.

Anforderungen des durch PCI DSS definierten Ansatzes Leitfaden und Empfehlungen für Microsoft Entra
11.6.1 Ein Mechanismus zur Erkennung von Änderungen und Manipulationen wird wie folgt bereitgestellt:
Um das Personal bei nicht autorisierten Änderungen (einschließlich Indikatoren für Kompromittierung, Änderungen, Ergänzungen und Löschungen) an den HTTP-Headern und den Inhalt der Zahlungsseiten zu benachrichtigen, die vom Browser des Verbrauchers empfangen wurden.
Der Mechanismus ist so konfiguriert, dass der empfangene HTTP-Header und die Zahlungsseite ausgewertet werden.
Die Funktionen des Mechanismus werden wie folgt ausgeführt: Mindestens einmal alle sieben Tage
ODER
Regelmäßig mit der in der gezielten Risikoanalyse der Entität definierten Häufigkeit, die gemäß allen Elementen durchgeführt wird
Gilt nicht für Microsoft Entra ID.

Nächste Schritte

Die Anforderungen des Datensicherheitsstandards der Zahlungskartenbranche (Payment Card Industry Data Security Standard, PCI-DSS) 3, 4, 9 und 12 gelten nicht für Microsoft Entra ID. Daher gibt es keine entsprechenden Artikel. Alle Anforderungen finden Sie auf pcisecuritystandards.org: Offizielle Website des PCI Security Standards Council.

Informationen zum Konfigurieren von Microsoft Entra ID zur Einhaltung der PCI-DSS-Anforderungen finden Sie in den folgenden Artikeln.