Penetrationstest-Anforderungen des Microsoft 365-App-Compliance-Programms

Die Teilnahme am Compliance-Programm für Microsoft 365-Zertifizierungs von Apps für Teams-Anwendungen, SharePoint-Apps/Add-Ins, Office-Add-Ins und WebApps erfordert die Durchführung eines Penetrationstests. Bei der Erstdokumenteneinreichung muss ein Unternehmen Unterlagen und Nachweise einreichen. Neben anderen Doikumenten ist ein Bericht von einem Penetrationstest erforderlich, der innerhalb der letzten 12 Monate abgeschlossen wurde. Der Pentest muss der Live-Umgebung prüfen, die die Bereitstellung der App unterstützt, sowie alle zusätzlichen Umgebungen, die den Betrieb der App ermöglichen. Wenn Segmentierungskontrollen vorhanden sind, müssen diese ebenfalls getestet werden.

Die Pentest-Anforderungen von Microsoft sind:

  • Alle 12 Monate muss jährlich ein Applikations- und Infrastruktur-Pentest stattfinden.
  • Diese Tests müssen von einem renommierten unabhängigen Unternehmen durchgeführt werden.
  • Die Behebung identifizierter kritischer und hochriskanter Schwachstellen muss innerhalb eines Monats erfolgen nachdem Pentest-Bericht abgeschlossen ist.
  • Die gesamte externe Angriffsfläche (IP-Adressen, URLs, API-Endpunkte usw.) muss in den Umfang des Penetrationstests einbezogen und im Penetrationstestbericht dokumentiert werden.
  • Penetrationstests für Webanwendungen müssen alle typischen Schwachstellenklassen umfassen; zum Beispiel die aktuellsten OWASP Top 10 oder SANS Top 25 CWE.
  • Ein erneutes Testen identifizierter Schwachstellen durch das Penetrationstestunternehmen ist nicht erforderlich – Behebung und Selbstüberprüfung sind ausreichend, jedoch müssen während der Bewertung angemessene Nachweise für eine ausreichende Behebung erbracht werden. Das erneute Testen identifizierter Schwachstellen ist dennoch Best Practice in der Informationssicherheit.
  • Penetrationstestberichte werden am Ende überprüft, um sicherzustellen, dass es keine Schwachstellen gibt, die aus einer der folgenden Kategorien stammen:
    • Nicht unterstütztes Betriebssystem.
    • Standardmäßige, aufzählbare oder erratbare Administratorkonten.
    • SQL-Injection-Risiken
    • XSS
    • Sicherheitslücken bei Directory Traversal (Dateipfad).
    • Typische HTTP-Schwachstellen, z. B. Header-Response-Splitting, Request-Smuggling und Desync-Angriffe.
    • Offenlegung des Quellcodes (einschließlich LFI).
    • Jede kritische oder hoher Score nach CVSS-Richtlinien für das Patch-Management
    • Jede bedeutende technische Schwachstelle, die leicht ausgenutzt werden kann, um eine große Menge an EUII oder OUI zu kompromittieren.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert