Microsoft 365-Zertifizierungsübermittlungshandbuch

Inhalt dieses Artikels:

• Einführung
• Voraussetzungen
• Microsoft 365-Zertifizierungsspezifikationsupdates
• Zertifizierungsbereich
• Zertifizierungsprozess
• Anfängliche Dokumentübermittlung
• Aktivitäten zur Sammlung und Bewertung von Beweisen
• Zertifizierungskriterien
• Application Security
• Betriebssicherheit
• Sicherheit und Datenschutz bei der Datenverarbeitung
• Überprüfung optionaler externer Complianceframeworks
• Anhang A
• Anhang B
• Anhang C
• Anhang D
• Anhang E
• Anhang F
• Anhang G
• Weitere Informationen
• Glossar

Einführung

Als Teil des Microsoft 365 App Compliance-Programms bietet die Microsoft 365-Zertifizierung Unternehmen die Gewissheit und das Vertrauen, dass Daten und Datenschutz bei der Integration von Entwickler-Apps/Add-Ins von Drittanbietern in die Microsoft 365-Plattform angemessen geschützt und geschützt werden. Anwendungen und Add-Ins, die die Überprüfung bestehen, werden im gesamten Microsoft 365-Ökosystem als Microsoft 365 Certified eingestuft.

Durch die Teilnahme am Microsoft 365-Zertifizierungsprogramm erklären Sie sich mit diesen ergänzenden Bedingungen einverstanden und mit allen Begleitdokumentationen einverstanden, die für Ihre Teilnahme am Microsoft 365-Zertifizierungsprogramm mit der Microsoft Corporation gelten ("Microsoft", "wir", "uns" oder "unser"). Sie versichern und garantieren uns, dass Sie berechtigt sind, diese ergänzenden Bedingungen für die Microsoft 365-Zertifizierung im Eigenen Namen, eines Unternehmens und/oder einer anderen Juristischen Person zu akzeptieren, sofern zutreffend. Wir können diese ergänzenden Bedingungen jederzeit ändern, ändern oder kündigen. Ihre fortgesetzte Teilnahme am Microsoft 365-Zertifizierungsprogramm nach jeder Änderung oder Änderung bedeutet, dass Sie den neuen ergänzenden Bedingungen zustimmen. Wenn Sie den neuen ergänzenden Bedingungen nicht zustimmen oder wenn wir diese ergänzenden Bedingungen kündigen, müssen Sie die Teilnahme am Microsoft 365-Zertifizierungsprogramm beenden.

Dieses Dokument richtet sich an ISVs (Independent Software Vendors), um Informationen zum Microsoft 365-Zertifizierungsprozess, Voraussetzungen für den Start des Prozesses und Details zu bestimmten Sicherheitskontrollen bereitzustellen, die ISVs benötigen. Allgemeine Informationen zum Microsoft 365 App Compliance-Programm finden Sie auf der Seite Microsoft 365 App Compliance Programm.

Voraussetzungen

Herausgebernachweis

Bevor Sie den Microsoft 365-Zertifizierungsprozess erhalten, müssen Sie den Herausgebernachweis abgeschlossen haben. Sie können jedoch den Microsoft 365-Zertifizierungsprozess starten, bevor Sie den Herausgebernachweis abschließen.

Lesen Sie die Microsoft 365-Zertifizierungsspezifikation.

Microsoft empfiehlt allen ISVs (Independent Software Vendor), diese Microsoft 365-Zertifizierungsspezifikation vollständig zu lesen, um sicherzustellen, dass alle anwendbaren Kontrollen von der Bereichsumgebung und der App/dem Add-In erfüllt werden. Dies trägt dazu bei, einen reibungslosen Bewertungsprozess zu gewährleisten.

Microsoft 365-Zertifizierungsspezifikationsupdates

Updates der Microsoft 365-Zertifizierungsspezifikation werden ungefähr alle sechs bis 12 Monate erwartet. Diese Updates können neue Zielsicherheitsdomänen und/oder Sicherheitskontrollen einführen. Updates basieren auf Entwicklerfeedback, Änderungen an der Bedrohungslandschaft und zur Erhöhung der Sicherheitsbaseline des Programms, wenn es reif wird.

ISVs, die die Microsoft 365-Zertifizierungsbewertung bereits gestartet haben, können die Bewertung mit der Version der Microsoft 365-Zertifizierungsspezifikation fortsetzen, die beim Start der Bewertung gültig war. Alle neuen Einreichungen, einschließlich der jährlichen Rezertifizierung, müssen anhand der veröffentlichten Version bewertet werden.

Zertifizierungsbereich

Die Bereichsumgebung ist die Umgebung, die die Übermittlung des App-/Add-In-Codes und alle Back-End-Systeme unterstützt, mit denen die App bzw. das Add-In möglicherweise kommuniziert. Alle zusätzlichen verbundenen Umgebungen werden ebenfalls in den Bereich aufgenommen, es sei denn, eine angemessene Segmentierung ist vorhanden. Die verbundenen Umgebungen können sich nicht auf die Sicherheit der bereichsinternen Umgebung auswirken. Alle Notfallwiederherstellungsumgebungen müssen ebenfalls in den Bereich der Bewertung einbezogen werden, da diese Umgebungen erforderlich wären, um den Dienst zu erfüllen, wenn etwas mit der primären Umgebung passiert. Der Begriff systeminterne Komponenten bezieht sich auf ALLE Geräte und Systeme, die in der Bereichsumgebung verwendet werden. Zu den In-Scope-Komponenten gehören, sind jedoch nicht beschränkt auf:

• Die Webanwendung(en).
• Diener.
• Firewalls (oder gleichwertig).
• Schalter.
• Lastenausgleichsmodule.
• Virtuelle Infrastruktur.
• Webverwaltungsportale für Cloudanbieter

Infrastructure-as-a-Service (IaaS), Platform-as-a-Service (PaaS) und Software-as-a-Service (SaaS)

Wenn IaaS und/oder PaaS verwendet werden, um die Infrastruktur der zu überprüfenden Anwendung oder Add-In-Codebereitstellung zu unterstützen, ist der Cloudplattformanbieter für einige der Sicherheitskontrollen verantwortlich, die während des Zertifizierungsprozesses bewertet werden. Daher müssen Zertifizierungsanalysten mit einer unabhängigen externen Überprüfung bewährter Sicherheitsmethoden durch den Cloudplattformanbieter über externe Complianceberichte wie [PCI DSS] Attestation of Compliance (AOC), ISO27001 oder [SOC 2] Type II-Berichte bereitgestellt werden.

Anhang F enthält Details dazu, welche Sicherheitskontrollen basierend auf den folgenden Bereitstellungstypen wahrscheinlich anwendbar sein werden und ob die App/Add-In Microsoft 365-Daten exfiltriert oder nicht:

• IsV gehostet
• IaaS gehostet
• PaaS/serverlos gehostet
• Hybrid gehostet
• Freigegeben gehostet

Wenn IaaS oder PaaS bereitgestellt wird, müssen Sie nachweisen, dass die Umgebung innerhalb dieser Bereitstellungstypen gehostet wird.

Probenahme

Beweisanträge zur Unterstützung der Zertifizierungsbewertung sollten auf einer Stichprobe der systeminternen Komponenten unter Berücksichtigung verschiedener Betriebssysteme, primärer Funktion des Geräts und verschiedener Gerätetypen basieren. Ein geeignetes Beispiel wird zu Beginn des Zertifizierungsprozesses ausgewählt. Die folgende Tabelle sollte als Leitfaden für die mögliche Stichprobengröße verwendet werden:

Größe der Population	Beispiel
<5	1
>5 & <10	2
>9 & <25	3
>24	4

Zertifizierungsprozess

Bevor Sie mit dem Zertifizierungsprozess beginnen, müssen Sie Den Herausgebernachweis erfolgreich abgeschlossen haben. Nach Abschluss des Vorgangs wird der Microsoft 365-Zertifizierungsprozess wie folgt fortgesetzt:

Vorbereitung

1. Navigieren Sie zu Partner Center, und lesen Sie ihre vollständige Dokumentation zum Herausgebernachweis . Bei Bedarf können Sie Ihre Antworten bearbeiten und aktualisieren. In diesem Fall müssen Sie ihre Nachweisdokumentation jedoch erneut zur Genehmigung übermitteln. Wenn Ihre Übermittlung älter als drei Monate ist, müssen Sie den Herausgebernachweis zur Überprüfung und Validierung erneut übermitteln.
2. Lesen Sie den Leitfaden zur Microsoft 365-Zertifizierungsübermittlung sorgfältig durch, um zu verstehen, was von Ihnen benötigt wird. Stellen Sie sicher, dass Sie die kontrollanforderungen erfüllen können, die im Leitfaden zur Übermittlung von Microsoft 365-Zertifizierungen angegeben sind.
3. Wählen Sie im Partner Center "Zertifizierung starten" aus. Dadurch gelangen Sie zu Ihrem anfänglichen Dokumentübermittlungsportal. Übermitteln Sie Ihre anfängliche Dokumentübermittlung. Dies hilft uns, basierend darauf, wie Ihre App entworfen wird und wie Kundendaten verarbeitet werden, den Umfang Ihrer Bewertung zu bestimmen. Überprüfen Sie diese Seite häufig, um festzustellen, ob Ihre Übermittlung akzeptiert wurde.

Bewertung

1. Sobald die anfängliche Dokumentübermittlung akzeptiert wurde, werden die für Ihre App erforderlichen Sicherheitskontrollen automatisch im Portal angezeigt. Anschließend müssen Sie für jedes Steuerelement Nachweise einreichen, die belegen, dass das Steuerelement vorhanden ist. Denken Sie daran, dass Sie 60 Tage zeit haben, um alle Nachweise einzureichen. Ein Analyst überprüft Ihre Beweise und genehmigt entweder die Kontrolle oder fordert neue oder zusätzliche Beweise an. Überprüfen Sie diese Seite häufig, um festzustellen, ob Ihre Beweise akzeptiert wurden.

Zertifizierung

1. Nachdem Ihre Übermittlung von einem Analysten überprüft wurde, werden Sie über Ihre Zertifizierungsentscheidung benachrichtigt. Apps, die mit einer Zertifizierung ausgezeichnet wurden, erhalten einen Badge auf ihrer Anwendung in AppSource und auf den Microsoft-Dokumentationsseiten . Informationen zu den vorteilen der Zertifizierung finden Sie hier.

Überprüfung und Erneute Zertifizierung

Wenn Ihre Anwendung zu einem beliebigen Zeitpunkt signifikante Änderungen erfährt, müssen Sie uns benachrichtigen.

Außerdem müssen Sie jährlich erneut zertifiziert werden. Dies erfordert die erneute Überprüfung der bereichsinternen Steuerelemente für Ihre aktuelle Umgebung. Dieser Prozess kann bis zu 90 Tage vor Ablauf Ihrer Zertifizierung beginnen. Ihre vorhandene Zertifizierung läuft während des Rezertifizierungszeitraums nicht ab. Die erneute Zertifizierung für alle Programme läuft am einjährigen Jahrestag Ihrer Microsoft 365-Zertifizierung ab.

Wenn Ihre Zertifizierung nicht vor dem Ablaufdatum verlängert wird, wird der Zertifizierungsstatus Ihrer Apps widerrufen. Alle Badgings, Symbole und das zugehörige Zertifizierungsbranding werden aus Ihrer App entfernt, und Es ist Ihnen untersagt, Ihre App als Microsoft 365 Certified zu bewerben.

Anfängliche Dokumentübermittlung

Die anfängliche Dokumentübermittlung hilft Zertifizierungsanalysten dabei, Bereichsdefinitionen durchzuführen und zu bestimmen, was für Ihre Bewertung vorgesehen ist. Danach müssen Sie unterstützende Dokumente und Nachweise einreichen, die für die Durchführung der Bewertung verwendet wurden. Ihre erste Übermittlung muss die unten angegebenen Informationen enthalten. Weitere Anleitungen finden Sie im Leitfaden zur Übermittlung von Ersten Dokumenten.

Dokumentationsübersicht	Dokumentationsdetails
App-/Add-In-Beschreibung	Eine Beschreibung des Zwecks und der Funktionalität der App bzw. des Add-Ins. Dies sollte dem Zertifizierungsanalysten ein gutes Verständnis dafür vermitteln, wie die App/das Add-In funktioniert und welche Verwendung sie beabsichtigt hat.
Penetrationstestbericht	Ein Penetrationstestbericht, der innerhalb der letzten 12 Monate abgeschlossen wurde. Dieser Bericht muss die Umgebung enthalten, die die Bereitstellung der App/add unterstützt, sowie jede zusätzliche Umgebung, die den Betrieb der App/Add-In unterstützt. Hinweis: Wenn Sie keine jährlichen Penetrationstests durchführen, können Sie diese im Rahmen des Zertifizierungsprozesses durchführen lassen.
Architekturdiagramme	Ein logisches Architekturdiagramm, das eine allgemeine Übersicht über die unterstützende Infrastruktur Ihrer App bzw. Ihres Add-Ins darstellt. Dies muss alle Hostingumgebungen und die unterstützende Infrastruktur umfassen, die die App bzw. das Add-In unterstützen. Dieses Diagramm MUSS alle verschiedenen unterstützenden Systemkomponenten innerhalb der Umgebung darstellen, um Zertifizierungsanalysten dabei zu helfen, systeme im Umfang zu verstehen und die Stichprobenentnahme zu bestimmen. Geben Sie auch an, welcher Hostingumgebungstyp verwendet wird. ISV gehostet, IaaS, PaaS oder Hybrid. Anmerkung: Wenn SaaS verwendet wird, geben Sie die verschiedenen SaaS-Dienste an, die verwendet werden, um die unterstützenden Dienste innerhalb der Umgebung bereitzustellen.
Öffentlicher Fußabdruck	Details aller öffentlichen IP-Adressen und URLs, die von der unterstützenden Infrastruktur verwendet werden. Dies muss den vollständigen routingfähigen IP-Adressbereich umfassen, der der Umgebung zugeordnet ist, es sei denn, eine angemessene Segmentierung wurde implementiert, um den verwendeten Bereich aufzuteilen (es ist ein angemessener Nachweis für die Segmentierung erforderlich).
Datenflussdiagramme	Flussdiagramme, die Folgendes beschreiben:
	✓ Microsoft 365 Daten fließen in die und aus der App/ dem Add-In (einschließlich EUII und OII ).
	✓ Microsoft 365 Datenflüsse innerhalb der unterstützenden Infrastruktur (sofern zutreffend)
	✓ Diagramme, die zeigen, wo und welche Daten gespeichert werden, wie Daten an externe Dritte weitergegeben werden (einschließlich Details darüber, welche Dritten) und wie Daten während der Übertragung über offene/öffentliche Netzwerke und ruhende Netzwerke geschützt werden.
API-Endpunktdetails	Eine vollständige Liste aller API-Endpunkte, die von Ihrer App verwendet werden. Um den Umgebungsbereich besser zu verstehen, geben Sie API-Endpunktstandorte in Ihrer Umgebung an.
Microsoft API-Berechtigungen	Stellen Sie eine Dokumentation mit allen Microsoft-APIs bereit, die zusammen mit den berechtigungen verwendet werden, die für die App/das Add-In angefordert werden, zusammen mit einer Begründung für die angeforderten Berechtigungen.
Datenspeichertypen	Datenspeicherung und -verarbeitung von Dokumenten, die Folgendes beschreiben:
	✓ In welchem Umfang werden Ihre Kunden Microsoft 365 Data EUII und OII empfangen und gespeichert?
	✓ Die Datenaufbewahrungsdauer.
	✓ Warum der Kunde Microsoft 365-Daten erfasst wird.
	✓ Wo Microsoft 365-Kundendaten gespeichert werden (sollten in den oben angegebenen Datenflussdiagrammen enthalten sein).
Konformitätsbestätigung	Unterstützende Dokumentation für externe Sicherheitsframeworks, die in der Herausgebernachweisübermittlung enthalten sind oder bei der Überprüfung der Microsoft 365-Zertifizierungskontrollen berücksichtigt werden müssen. Derzeit werden die folgenden drei unterstützt:
	✓ PCI DSS Attestation of Compliance (AOC).
	✓ SOC 2 Typ I/Typ II Berichte.
	✓ ISMS / IEC - 1S0/IEC 27001 Statement of Applicability (SoA) und Zertifizierung.
Webabhängigkeiten	Dokumentation, die alle Abhängigkeiten auflistet, die von der App bzw. dem Add-In mit den aktuell ausgeführten Versionen verwendet werden.
Softwareinventur	Eine aktuelle Softwareinventur, die alle in der Bereichsumgebung verwendeten Software zusammen mit den Versionen enthält.
Hardwareinventur	Ein aktueller Hardwarebestand, der von der unterstützenden Infrastruktur verwendet wird. Dies wird verwendet, um die Stichprobenentnahme bei der Durchführung der Bewertungsphase zu unterstützen. Wenn Ihre Umgebung PaaS enthält, geben Sie Details zu den genutzten Diensten an.

Aktivitäten zur Sammlung und Bewertung von Beweisen

Zertifizierungsanalysten müssen Beweise für alle Systemkomponenten innerhalb des definierten Beispielsatzes überprüfen. Zu den Arten von Beweisen, die zur Unterstützung des Bewertungsprozesses erforderlich sind, gehören folgende:

Beweissammlung

• Erste Dokumentation, hervorgehoben im Abschnitt Erste Dokumentationsübermittlung oben
• Richtliniendokumente
• Dokumente verarbeiten
• Systemkonfigurationseinstellungen
• Tickets ändern
• Änderungssteuerungsdatensätze
• Systemberichte

Es werden verschiedene Methoden verwendet, um die für den Abschluss des Bewertungsprozesses erforderlichen Beweise zu sammeln. Diese Beweissammlung kann folgende Formen haben:

• Dokumente
• Screenshots
• Interviews
• Bildschirmfreigabe

Die verwendeten Methoden zur Beweissammlung werden während des Bewertungsprozesses ermittelt. Konkrete Beispiele für die Art der in Ihrer Einreichung erforderlichen Nachweise finden Sie im Leitfaden zu Beispielen für Nachweise.

Bewertungsaktivitäten

Zertifizierungsanalysten überprüfen die von Ihnen bereitgestellten Nachweise, um festzustellen, ob Sie die Kontrollen in dieser Microsoft 365-Zertifizierungsspezifikation angemessen erfüllt haben.

Wenn möglich und um die für die Durchführung der Bewertung erforderliche Zeit zu verkürzen, sollten die in der Ursprünglichen Dokumentationsübermittlung beschriebenen Unterlagen im Voraus bereitgestellt werden.

Zertifizierungsanalysten überprüfen zunächst die beweise aus der ursprünglichen Dokumentationsübermittlung und die Herausgebernachweisinformationen, um geeignete Untersuchungslinien, Stichprobengröße und die Notwendigkeit weiterer Nachweise zu ermitteln, wie oben beschrieben. Zertifizierungsanalysten analysieren alle gesammelten Informationen, um Rückschlüsse darauf zu ziehen, wie und ob Sie die Kontrollen in dieser Microsoft 365-Zertifizierungsspezifikation erfüllen.

App-Zertifizierungskriterien

Ihre App, die unterstützende Infrastruktur und die unterstützende Dokumentation werden in den folgenden Sicherheitsdomänen bewertet:

1. Application Security
2. Betriebssicherheit/Sichere Bereitstellung
3. Sicherheit und Datenschutz bei der Datenverarbeitung

Jede dieser Sicherheitsdomänen umfasst bestimmte Schlüsselkontrollen, die eine oder mehrere spezifische Anforderungen umfassen, die im Rahmen des Bewertungsprozesses ausgewertet werden. Um sicherzustellen, dass die Microsoft 365-Zertifizierung für Entwickler aller Größen gilt, wird jede der Sicherheitsdomänen mithilfe eines Bewertungssystems bewertet, um eine Gesamtbewertung aus jeder der Domänen zu ermitteln. Die Bewertungen für jede der Microsoft 365-Zertifizierungskontrollen werden basierend auf dem wahrgenommenen Risiko, dass diese Kontrolle nicht erfüllt wird, zwischen 1 (niedrig) und 3 (hoch) zugeordnet. Jede der Sicherheitsdomänen verfügt über eine Mindestprozentmarke, die als bestanden gilt. Bestimmte Elemente dieser Spezifikation enthalten einige Kriterien für automatische Fehler:

• API-Berechtigungen, die nicht dem Prinzip der geringsten Rechte (PoLP) folgen.
• Es werden keine Penetrationstests gemeldet, wenn dies erforderlich ist.
• Keine Antischadsoftware-Schutzmaßnahmen
• Die mehrstufige Authentifizierung wird nicht zum Schutz des Administratorzugriffs verwendet.
• Keine Patchprozesse.
• Kein geeigneter Datenschutzhinweis der DSGVO .

Application Security

Die Anwendungssicherheitsdomäne konzentriert sich auf die folgenden drei Bereiche:

• GraphAPI-Berechtigungsüberprüfung
• Externe Konnektivitätsprüfungen
• Anwendungssicherheitstests

GraphAPI-Berechtigungsüberprüfung

Die Überprüfung der GraphAPI-Berechtigung wird durchgeführt, um zu überprüfen, ob die App/das Add-In keine übermäßig freizügigen Berechtigungen anzufordern. Dies erfolgt durch manuelle Überprüfung, welche Berechtigungen angefordert werden. Zertifizierungsanalysten verweisen auf diese Überprüfungen mit der Übermittlung des Herausgebernachweises und bewerten die angeforderte Zugriffsebene, um sicherzustellen, dass die Praktiken mit den geringsten Rechten eingehalten werden. Wenn Zertifizierungsanalysten der Meinung sind, dass diese Praktiken der "geringsten Rechte" nicht erfüllt werden, führen Zertifizierungsanalysten eine offene Diskussion mit Ihnen, um die geschäftliche Begründung für die angeforderten Berechtigungen zu überprüfen. Alle Abweichungen zu Ihrer Herausgebernachweis-Übermittlung, die während dieser Überprüfung gefunden wurden, erhalten auch Feedback, damit Ihr Herausgebernachweis aktualisiert werden kann.

Externe Konnektivitätsprüfungen

Im Rahmen der Bewertung führt ein Analyst eine einfache exemplarische Vorgehensweise der Anwendungsfunktionen durch, um Verbindungen außerhalb von Microsoft 365 zu identifizieren. Alle Verbindungen, die nicht als Microsoft oder direkte Verbindungen mit Ihrem Dienst identifiziert werden, werden während der Bewertung gekennzeichnet und erläutert.

Anwendungssicherheitstests

Eine angemessene Überprüfung der Risiken, die mit Ihrer App/Ihrem Add-In und Ihrer unterstützenden Umgebung verbunden sind, ist unerlässlich, um Kunden sicherheit in Bezug auf die Sicherheit der App/Add-Ins zu bieten. Anwendungssicherheitstests in Form von Penetrationstests MÜSSEN durchgeführt werden, wenn Ihre Anwendung mit einem Dienst verbunden ist, der nicht von Microsoft veröffentlicht wurde. Wenn Ihre App eigenständig ohne Konnektivität mit einem Nicht-Microsoft-Dienst oder Back-End betrieben wird, sind keine Penetrationstests erforderlich.

Penetrationstestbereich

Penetrationstests müssen in der Live-Produktionsumgebung durchgeführt werden, die die Bereitstellung der App/Add-Ins unterstützt (z. B. in dem der App-/Add-In-Code gehostet wird, der in der Regel die Ressource in der Manifestdatei ist), zusammen mit jeder zusätzlichen Umgebung, die den Betrieb der App bzw. des Add-Ins unterstützt (z. B. wenn die App/das Add-In mit anderen Webanwendungen außerhalb von Microsoft 365 kommuniziert). Bei der Definition des Bereichs muss darauf geachtet werden, dass alle "verbundenen" Systeme oder Umgebungen, die sich auf die Sicherheit der bereichsinternen Umgebung auswirken können, auch in ALLE Penetrationstestaktivitäten einbezogen werden.

Wenn Techniken verwendet werden, um die In-Scope-Umgebungen von anderen Umgebungen zu segmentieren, MÜSSEN Penetrationstestaktivitäten die Wirksamkeit dieser Segmentierungstechniken überprüfen. Dies muss im Penetrationstestbericht ausführlich beschrieben werden.

Die Berichte zu Penetrationstests werden überprüft, um sicherzustellen, dass keine Sicherheitsrisiken vorhanden sind, die die folgenden automatischen Fehlerkriterien erfüllen, die in den folgenden Kontrollen beschrieben sind.

Anforderungen an Penetrationstests

Kriterientyp	Penetrationsteststeuerungen
Allgemeine Kriterien	Controls
	Anwendungs- und Infrastruktur-Penetrationstests MÜSSEN jährlich (alle 12 Monate) von einem renommierten unabhängigen Unternehmen durchgeführt werden.
	Die Behebung identifizierter kritischer und risikoreicher Sicherheitsrisiken MUSS innerhalb eines Monats nach Abschluss des Penetrationstests oder je nach dokumentiertem Patchprozess früher abgeschlossen werden.
	Der vollständige externe Speicherbedarf (IP-Adressen, URLs, API-Endpunkte usw.) MUSS in den Rahmen der Penetrationstests aufgenommen werden und muss im Penetrationstestbericht dokumentiert werden.
	Penetrationstests für Webanwendungen MÜSSEN alle Sicherheitsrisikoklassen enthalten. Beispielsweise die aktuellsten OWASP Top 10 oder SANS Top 25 CWE.
	Ein erneutes Testen der identifizierten Sicherheitsrisiken durch das Penetrationstestunternehmen ist nicht erforderlich. Korrekturen und Selbstüberprüfungen sind jedoch ausreichend, um eine ausreichende Behebung nachzuweisen, müssen während der Bewertung ausreichende Beweise vorgelegt werden.
Kriterien für automatische Fehler:	Controls
	Vorhandensein eines nicht unterstützten Betriebssystems.
	Vorhandensein von standardmäßigen, aufzählbaren oder erratenden Administratorkonten.
	Das Vorhandensein von Risiken für die Einschleusung von SQL-Befehlen.
	Vorhandensein websiteübergreifender Skripts.
	Vorhandensein von Sicherheitsrisiken im Verzeichnisdurchlauf (Dateipfad).
	Vorhandensein von HTTP-Sicherheitsrisiken, z. B. Aufteilen von Headerantworten, Anforderungsschmuggel und Desync-Angriffe.
	Vorhandensein einer Offenlegung des Quellcodes (einschließlich LFI).
	Alle kritischen oder hohen Bewertungen, wie in den CVSS-Patchverwaltungsrichtlinien definiert.
	Jede erhebliche technische Sicherheitslücke, die leicht ausgenutzt werden kann, um eine große Menge von EUII oder OUI zu kompromittieren.

Anforderungen und Regeln für ergänzende Penetrationstests

• Für ISVs, die derzeit keine Penetrationstests durchführen, können Penetrationstests kostenlos mit der Microsoft 365-Zertifizierung durchgeführt werden. Microsoft übernimmt die Kosten für einen Penetrationstest für bis zu 12 Tage für manuelle Tests. Die Kosten für Penetrationstests werden basierend auf der Anzahl der Tage berechnet, die zum Testen der Umgebung erforderlich sind. Alle Kosten, die 12 Tage der Prüfung überschreiten, sind sache des ISV.
• ISVs sind verpflichtet, Nachweise vorzulegen und die Genehmigung für 50 % der Kontrollen im Gültigkeitsbereich zu erhalten, bevor der Penetrationstest durchgeführt wird. Füllen Sie zunächst Ihre erste Dokumentübermittlung aus, und wählen Sie penetrationstests in Ihre Bewertung ein. Wenn Sie 50 % der Steuerelemente abgeschlossen haben, werden Sie kontaktiert, um den Penetrationstest zu planen und zu planen.
• Der Bericht, der nach Abschluss des Pentests ausgegeben wird, wird dem ISV zur Verfügung gestellt, sobald er die Zertifizierung abgeschlossen hat. Dieser Bericht kann zusammen mit Ihrer Microsoft 365-Zertifizierung verwendet werden, um potenziellen Kunden zu zeigen, dass Ihre Umgebung sicher ist.
• ISVs werden auch dafür verantwortlich sein, nachzuweisen, dass die im Penetrationstest identifizierten Sicherheitsrisiken vor der Vergabe einer Zertifizierung behoben wurden, aber keinen sauberen Bericht erstellen müssen.

Sobald ein Penetrationstest eingerichtet wurde, ist der ISV für die Gebühren im Zusammenhang mit Neuplanung und Stornierung wie folgt verantwortlich:

Zeitskala für die Neuplanung von Gebühren	Zahlbarer Anteil
Eine Neuplanungsanforderung, die mehr als 30 Tage vor dem geplanten Startdatum empfangen wurde.	0% Zahlbar
Die Neuplanungsanforderung wurde 8 bis 30 Tage vor dem geplanten Startdatum empfangen.	25% Zahlbar
Eine Neuplanungsanforderung, die innerhalb von 2 bis 7 Tagen vor dem geplanten Startdatum mit einem festen Umbuchungsdatum empfangen wurde.	50% Zahlbar
Anforderung zur Neuplanung, die weniger als 2 Tage vor dem Startdatum empfangen wurde.	100% Zahlbar

Stornogebühr Zeitskala	Zahlbarer Anteil
Die Stornierungsanforderung wurde mehr als 30 Tage vor dem geplanten Startdatum empfangen.	25% Zahlbar
Die Stornierungsanforderung wurde 8 bis 30 Tage vor dem geplanten Startdatum empfangen.	50% Zahlbar
Stornierungsanfrage, die innerhalb von 7 Tagen vor dem geplanten Startdatum empfangen wurde.	90% Zahlbar

Betriebssicherheit

Diese Domäne misst die Ausrichtung der unterstützenden Infrastruktur und Bereitstellungsprozesse Ihrer App mit bewährten Sicherheitsmethoden.

Steuerelemente

Steuerelementfamilie	Controls
Schutz vor Schadsoftware – Antivirus	Stellen Sie Richtliniendokumentation bereit, die Antivirenpraktiken und -verfahren regelt.
	Stellen Sie nachweisbare Beweise dafür bereit, dass Antivirensoftware in allen abgetasteten Systemkomponenten ausgeführt wird.
	Stellen Sie einen nachweisbaren Beweis dafür bereit, dass Antivirensignaturen in allen Umgebungen (innerhalb eines Tages) auf dem neuesten Stand sind.
	Stellen Sie nachweisbare Beweise dafür bereit, dass Virenschutz für die Durchführung von Zugriffsüberprüfungen oder regelmäßigen Überprüfungen für alle erfassten Systemkomponenten konfiguriert ist. Hinweis: Wenn die Zugriffsüberprüfung nicht aktiviert ist, müssen mindestens tägliche Überprüfungen und Warnungen aktiviert werden.
	Stellen Sie nachweisbare Beweise dafür bereit, dass Virenschutz so konfiguriert ist, dass Schadsoftware automatisch blockiert oder isoliert und über alle erfassten Systemkomponenten hinweg benachrichtigt wird.
Anwendungssteuerungen: NUR erforderlich, wenn herkömmliche Antischadsoftware nicht verwendet wird	Stellen Sie nachweisbare Beweise dafür bereit, dass Anwendungen vor der Bereitstellung genehmigt wurden.
	Stellen Sie nachweisbare Beweise bereit, dass eine vollständige Liste genehmigter Anwendungen mit geschäftlicher Begründung vorhanden ist und verwaltet wird.
	Stellen Sie eine unterstützende Dokumentation bereit, in der erläutert wird, dass die Anwendungskontrollessoftware so konfiguriert ist, dass sie bestimmten Anwendungssteuerungsmechanismen entspricht. (Beispiel: Zulässige Auflistung: Sample1, Sample3, Codesignatur)
	Stellen Sie einen nachweisbaren Beweis dafür bereit, dass die Anwendungssteuerung so konfiguriert ist, wie sie von allen erfassten Systemkomponenten dokumentiert ist.
Patchverwaltung – Risikorangfolge	Stellen Sie eine Richtliniendokumentation bereit, die steuert, wie neue Sicherheitsrisiken identifiziert und einer Risikobewertung zugewiesen werden.
	Stellen Sie Beweise dafür bereit, wie neue Sicherheitsrisiken identifiziert werden.
	Stellen Sie Beweise bereit, die belegen, dass allen Sicherheitsrisiken nach der Identifizierung eine Risikorangfolge zugewiesen wird.
Patchverwaltung – Patchen	Stellen Sie Richtliniendokumentation für das Patchen von systeminternen Komponenten bereit, die einen geeigneten minimalen Patchzeitrahmen für kritische, hohe und mittlere Sicherheitsrisiken enthält. und Außerbetriebnahme von nicht unterstützten Betriebssystemen und Software.
	Stellen Sie einen nachweisbaren Beweis dafür bereit, dass alle systemkomponenten mit Stichproben gepatcht werden.
	Stellen Sie nachweisbare Beweise bereit, dass nicht unterstützte Betriebssysteme und Softwarekomponenten in der Umgebung nicht verwendet werden.
Überprüfung auf Sicherheitsrisiken	Stellen Sie die vierteljährlichen Berichte zur Überprüfung von Sicherheitsrisiken in Infrastruktur und Webanwendung bereit. Die Überprüfung muss für den gesamten öffentlichen Speicherbedarf (IP-Adressen und URLs) und interne IP-Adressbereiche durchgeführt werden.
	Stellen Sie nachweisbare Beweise dafür bereit, dass Korrekturen von Sicherheitsrisiken, die während der Überprüfung auf Sicherheitsrisiken identifiziert wurden, gemäß Ihrem dokumentierten Patchzeitrahmen gepatcht werden.
Firewalls	Stellen Sie Richtliniendokumentation bereit, die die Vorgehensweisen und Verfahren der Firewallverwaltung regelt.
	Stellen Sie nachweisbare Beweise dafür bereit, dass alle administrativen Standardanmeldeinformationen vor der Installation in Produktionsumgebungen geändert werden.
	Stellen Sie nachweisbare Beweise dafür bereit, dass Firewalls an der Grenze der bereichsinternen Umgebung und zwischen dem Umkreisnetzwerk (auch als DMZ, demilitarisierte Zone und überprüftes Subnetz bezeichnet) und internen vertrauenswürdigen Netzwerken installiert sind.
	Stellen Sie nachweisbare Beweise dafür bereit, dass der gesamte öffentliche Zugriff in der demilitarisierten Zone (DMZ) endet.
	Stellen Sie nachweisbare Beweise dafür bereit, dass der gesamte durch die Firewall zugelassene Datenverkehr einen Genehmigungsprozess durchläuft.
	Stellen Sie nachweisbare Beweise dafür bereit, dass die Firewallregelbasis so konfiguriert ist, dass Datenverkehr gelöscht wird, der nicht explizit definiert ist.
	Stellen Sie nachweisbare Beweise bereit, dass die Firewall nur starke Kryptografie auf allen Verwaltungsschnittstellen unterstützt, die keine Konsolen sind.
	Stellen Sie nachweisbare Beweise bereit, dass Sie Firewallregelüberprüfungen mindestens alle 6 Monate durchführen.
Web Application Firewall (WAF) (OPTIONAL):Zusätzliche Gutschrift wird für die Erfüllung der folgenden Steuerelemente belohnt.	Stellen Sie nachweisbare Beweise dafür bereit, dass die Web Application Firewall (WAF) für die aktive Überwachung, Warnung und Blockierung schädlichen Datenverkehrs konfiguriert ist.
	Stellen Sie nachweisbare Beweise bereit, dass die WAF SSL-Auslagerung unterstützt.
	Stellen Sie nachweisbare Beweise bereit, dass die WAF vor einigen oder allen der folgenden Klassen von Sicherheitsrisiken gemäß dem OWASP-Kernregelsatz (3.0 oder 3.1) schützt.
Änderungssteuerung	Stellen Sie Richtliniendokumentation bereit, die Änderungskontrollprozesse steuert.
	Stellen Sie nachweisbare Beweise dafür bereit, dass Entwicklungs- und Testumgebungen die Trennung von Aufgaben von der Produktionsumgebung erzwingen.
	Stellen Sie nachweisbare Beweise dafür bereit, dass vertrauliche Produktionsdaten in den Entwicklungs- oder Testumgebungen nicht verwendet werden.
	Stellen Sie nachweisbare Beweise dafür bereit, dass dokumentierte Änderungsanforderungen Auswirkungen der Änderung, Details der Back-Out-Verfahren und der durchzuführenden Tests enthalten.
	Stellen Sie nachweisbare Beweise dafür bereit, dass Änderungsanforderungen einem Autorisierungs- und Abmeldeprozess unterzogen werden.
Sichere Softwareentwicklung/-bereitstellung	Stellen Sie Richtlinien und Verfahren bereit, die eine sichere Softwareentwicklung und -bereitstellung unterstützen, einschließlich bewährter Methoden für die sichere Codierung für gängige Sicherheitsrisikoklassen wie OWASP Top 10 oder SANS Top 25 CWE.
	Stellen Sie nachweisbare Beweise dafür bereit, dass Codeänderungen einem Überprüfungs- und Autorisierungsprozess durch einen zweiten Prüfer unterzogen werden.
	Stellen Sie nachweisbare Beweise dafür bereit, dass Entwickler jährlich eine sichere Softwareentwicklungsschulung durchlaufen.
	Stellen Sie nachweisbare Beweise dafür bereit, dass Coderepositorys mit mehrstufiger Authentifizierung (Multi-Factor Authentication, MFA) geschützt sind.
	Stellen Sie nachweisbare Beweise dafür bereit, dass Zugriffssteuerungen zum Sichern von Coderepositorys vorhanden sind.
Kontoführung	Stellen Sie Richtliniendokumentation bereit, die die Methoden und Verfahren für die Kontoverwaltung regelt.
	Stellen Sie einen nachweisbaren Beweis dafür bereit, dass Standardanmeldeinformationen für die erfassten Systemkomponenten entweder deaktiviert, entfernt oder geändert werden.
	Stellen Sie nachweisbare Beweise dafür bereit, dass die Erstellung, Änderung und Löschung eines Kontos einen etablierten Genehmigungsprozess durchlaufen.
	Stellen Sie einen nachweisbaren Beweis dafür bereit, dass ein Prozess vorhanden ist, um Konten zu deaktivieren oder zu löschen, die nicht innerhalb von drei Monaten verwendet werden.
	Stellen Sie einen nachweisbaren Beweis dafür bereit, dass eine Richtlinie für sichere Kennwörter oder andere geeignete Gegenmaßnahmen zum Schutz von Benutzeranmeldeinformationen vorhanden sind. Folgendes sollte als Mindestrichtlinie verwendet werden: Minimale Kennwortlänge von 8 Zeichen, Kontosperrungsschwellenwert von nicht mehr als 10 Versuchen, Kennwortverlauf von mindestens 5 Kennwörtern, Erzwingung der Verwendung von sicherem Kennwort
	Stellen Sie nachweisbare Beweise bereit, dass eindeutige Benutzerkonten für alle Benutzer ausgestellt werden.
	Stellen Sie einen nachweisbaren Beweis dafür bereit, dass die Prinzipien der geringsten Rechte in der Umgebung befolgt werden.
	Stellen Sie nachweisbare Beweise bereit, dass ein Prozess zum Sichern oder Absichern von Dienstkonten vorhanden ist und der Prozess befolgt wird.
	Stellen Sie nachweisbare Beweise dafür bereit, dass MFA für alle Remotezugriffsverbindungen und alle Verwaltungsschnittstellen ohne Konsole konfiguriert ist.
	Stellen Sie nachweisbare Beweise dafür bereit, dass eine starke Verschlüsselung für alle Remotezugriffsverbindungen und alle Verwaltungsschnittstellen ohne Konsole konfiguriert ist, einschließlich des Zugriffs auf Coderepositorys und Cloudverwaltungsschnittstellen.
	Stellen Sie nachweisbare Beweise dafür bereit, dass MFA zum Schutz des Verwaltungsportals verwendet wird, das Sie zum Verwalten und Verwalten aller DNS-Einträge (Public Domain Name Service) verwenden.
Intrusion Detection and Prevention (OPTIONAL): Zusätzliche Gutschriften werden für die Erfüllung der folgenden Kontrollen belohnt	Stellen Sie nachweisbare Beweise dafür bereit, dass Intrusion Detection and Prevention Systems (IDPS) im Umkreis der in-scope-Umgebungen bereitgestellt werden.
	Stellen Sie einen nachweisbaren Beweis dafür bereit, dass IDPS-Signaturen (innerhalb von 24 Stunden) auf dem neuesten Stand gehalten werden.
	Stellen Sie einen nachweisbaren Beweis dafür bereit, dass IDPS so konfiguriert ist, dass die TLS-Überprüfung des gesamten eingehenden Webdatenverkehrs unterstützt wird.
	Stellen Sie einen nachweisbaren Beweis dafür bereit, dass IDPS für die Überwachung aller eingehenden Datenverkehrsflüsse konfiguriert ist.
	Stellen Sie einen nachweisbaren Beweis dafür bereit, dass IDPS für die Überwachung aller ausgehenden Datenverkehrsflüsse konfiguriert ist.
Protokollierung von Sicherheitsereignissen	Stellen Sie Richtliniendokumentation für bewährte Methoden und Verfahren bereit, die die Protokollierung von Sicherheitsereignissen steuern.
	Stellen Sie nachweisbare Beweise bereit, die zeigen, dass die Protokollierung von Sicherheitsereignissen für alle erfassten Systemkomponenten eingerichtet ist, um die folgenden Ereignisse zu protokollieren: Benutzerzugriff auf Systemkomponenten und die Anwendung, Alle Aktionen, die von einem Benutzer mit hohen Berechtigungen ausgeführt werden, Ungültige logische Zugriffsversuche Privilegierte Kontoerstellung oder -änderung, Manipulation des Ereignisprotokolls, Deaktivieren von Sicherheitstools (z. B. Antischadsoftware oder Ereignisprotokollierung), Antischadsoftwareprotokollierung (z. B. Updates, Schadsoftwareerkennung und Scanfehler)., IDPS- und WAF-Ereignisse, falls konfiguriert
	Stellen Sie nachweisbare Beweise bereit, dass protokollierte Sicherheitsereignisse die folgenden Mindestinformationen enthalten: Benutzer, Ereignistyp, Datum und Uhrzeit, Erfolgs- oder Fehlerindikatoren, Bezeichnung, die das betroffene System identifiziert
	Stellen Sie einen nachweisbaren Beweis dafür bereit, dass alle erfassten Systemkomponenten mit denselben primären und sekundären Servern zeitsynchronisiert sind.
	Stellen Sie nachweisbare Beweise bereit, wenn öffentliche Systeme verwendet werden, dass Sicherheitsereignisprotokolle an eine zentralisierte Protokollierungslösung gesendet werden, die sich nicht im Umkreisnetzwerk befindet.
	Stellen Sie nachweisbare Beweise bereit, die zeigen, dass die zentralisierte Protokollierungslösung vor unbefugter Manipulation von Protokollierungsdaten geschützt ist.
	Stellen Sie nachweisbare Beweise dafür bereit, dass Daten zur Protokollierung von Sicherheitsereignissen für mindestens 30 Tage sofort verfügbar sind, wobei 90 Tage lang Sicherheitsereignisprotokolle aufbewahrt werden.
Sicherheitsereignisprotokollüberprüfungen	Stellen Sie Richtliniendokumentation bereit, die die Verfahren und Verfahren der Protokollüberprüfung regelt.
	Stellen Sie nachweisbare Beweise bereit, dass Protokolle täglich von einem Menschen oder automatisierten Tools überprüft werden, um potenzielle Sicherheitsereignisse zu identifizieren.
	Stellen Sie nachweisbare Beweise dafür bereit, dass potenzielle Sicherheitsereignisse und Anomalien untersucht und behoben werden.
Alarmierung	Stellen Sie richtliniendokumentation bereit, die die Methoden und Verfahren für Sicherheitsereigniswarnungen regelt.
	Stellen Sie nachweisbare Beweise dafür bereit, dass Warnungen für die sofortige Selektierung für die folgenden Arten von Sicherheitsereignissen ausgelöst werden: Erstellung oder Änderung privilegierter Konten, Viren- oder Schadsoftwareereignisse, Manipulation von Ereignisprotokollen, IDPS- oder WAF-Ereignisse
	Stellen Sie nachweisbare Beweise bereit, die zeigen, dass Mitarbeiter den ganzen Tag und jeden Tag immer zur Verfügung stehen, um auf Sicherheitswarnungen zu reagieren.
Risikomanagement	Stellen Sie nachweisbare Beweise bereit, dass ein formaler Prozess für das Risikomanagement der Informationssicherheit eingerichtet wurde.
	Nachweise dafür liefern, dass mindestens jährlich eine formale Risikobewertung stattfindet.
	Stellen Sie nachweisbare Beweise dafür bereit, dass die Bewertung des Informationssicherheitsrisikos Bedrohungen, Sicherheitsrisiken oder das entsprechende umfasst.
	Stellen Sie nachweisbare Beweise dafür bereit, dass die Bewertung des Informationssicherheitsrisikos Auswirkungen, Wahrscheinlichkeitsrisikomatrix oder das entsprechende umfasst.
	Stellen Sie nachweisbare Beweise dafür bereit, dass die Risikobewertung der Informationssicherheit ein Risikoregister und einen Behandlungsplan umfasst.
Reaktion auf Vorfälle	Geben Sie den Plan zur Reaktion auf Sicherheitsvorfälle (Security Incident Response Plan, IRP) an.
	Stellen Sie nachweisbare Beweise dafür bereit, dass das Sicherheits-IRP einen dokumentierten Kommunikationsprozess umfasst, um eine rechtzeitige Benachrichtigung an wichtige Interessenträger wie Zahlungsmarken und Erwerber, Aufsichtsbehörden, Aufsichtsbehörden, Direktoren und Kunden sicherzustellen.
	Stellen Sie nachweisbare Beweise bereit, dass alle Mitglieder des Incident Response-Teams ein jährliches Training oder eine Table Top-Übung abgeschlossen haben.
	Stellen Sie nachweisbare Beweise bereit, um zu zeigen, dass die Sicherheits-IRP basierend auf gewonnenen Erkenntnissen oder organisatorischen Änderungen aktualisiert wird.

Sicherheit und Datenschutz bei der Datenverarbeitung

Daten, die zwischen dem Anwendungsbenutzer, zwischengeschalteten Diensten und den Systemen des ISV übertragen werden, müssen durch Verschlüsselung über eine TLS-Verbindung geschützt werden, die mindestens TLS v1.1 unterstützt. SieheAnhang A.

Wenn Ihre Anwendung Microsoft 365-Daten abruft und speichert, müssen Sie ein Verschlüsselungsschema für die Datenspeicherung implementieren, das der in Anhang B definierten Spezifikation folgt.

Steuerelemente

Steuerelementfamilie	Controls
Daten während der Übertragung	Bereitstellen von nachweisbaren Beweisen, dass die TLS-Konfiguration die Verschlüsselungsanforderungen innerhalb der TLS-Profilkonfigurationsanforderungen erfüllt oder überschreitet
	Stellen Sie einen nachweisbaren Beweis dafür bereit, dass die TLS-Komprimierung für alle öffentlichen Dienste, die Webanforderungen verarbeiten, deaktiviert ist.
	Stellen Sie nachweisbare Beweise dafür bereit, dass tls http strict transport security aktiviert und auf >= 15552000 an allen Standorten konfiguriert ist.
Ruhende Daten	Stellen Sie nachweisbare Beweise bereit, dass ruhende Daten inline mit den Anforderungen des Verschlüsselungsprofils verschlüsselt werden, indem Verschlüsselungsalgorithmen wie AES, Blowfish, TDES und Verschlüsselungsschlüsselgrößen von 128-Bit und 256-Bit verwendet werden.
	Stellen Sie nachweisbare Beweise dafür bereit, dass die Hashfunktion oder Nachrichtenauthentifizierung (HMAC-SHA1) nur verwendet wird, um ruhende Daten inline mit den Anforderungen des Verschlüsselungsprofils zu schützen.
	Stellen Sie einen Bestand bereit, der alle gespeicherten Daten anzeigt, einschließlich des Speicherorts und der Verschlüsselung, die zum Schutz der Daten verwendet werden.
Datenaufbewahrung und -entsorgung	Stellen Sie nachweisbare Beweise dafür bereit, dass ein genehmigter und dokumentierter Zeitraum für die Datenaufbewahrung formell festgelegt wurde.
	Stellen Sie nachweisbare Beweise bereit, dass beibehaltene Daten dem definierten Aufbewahrungszeitraum entsprechen.
	Stellen Sie nachweisbare Beweise dafür bereit, dass Prozesse vorhanden sind, um Daten nach dem Aufbewahrungszeitraum sicher zu löschen.
Datenzugriffsverwaltung	Stellen Sie eine Liste aller Personen mit Zugriff auf Daten oder Verschlüsselungsschlüssel bereit, einschließlich der geschäftlichen Begründung.
	Stellen Sie nachweisbare Beweise bereit, dass die personen, die in der Stichprobe Zugriff auf Daten oder Verschlüsselungsschlüssel haben, formal genehmigt wurden, wobei die für ihre Funktion erforderlichen Berechtigungen detailliert beschrieben werden.
	Stellen Sie einen nachweisbaren Beweis dafür bereit, dass die in der Stichprobe erfassten Personen, die Zugriff auf Daten oder Verschlüsselungsschlüssel haben, nur über die in der Genehmigung enthaltenen Berechtigungen verfügen.
	Stellen Sie eine Liste aller Drittanbieter bereit, für die Kundendaten freigegeben werden.
	Stellen Sie nachweisbare Beweise dafür bereit, dass alle Drittanbieter, die Kundendaten nutzen, über Freigabevereinbarungen verfügen.
DSGVO (falls zutreffend)	Stellen Sie einen dokumentierten Sar-Prozess (Subject Access Request) bereit, und stellen Sie Beweise bereit, die belegen, dass die betroffenen Personen in der Lage sind, SARs zu erheben.
	Stellen Sie nachweisbare Beweise bereit, dass Sie alle Speicherorte der Daten betroffener Personen identifizieren können, wenn Sie auf eine SAR reagieren.
	Sie führen einen Datenschutzhinweis, der die Details des Unternehmens (Name, Adresse usw.) enthalten sollte.
	Sie führen einen Datenschutzhinweis, in dem die Arten der verarbeiteten personenbezogenen Daten erläutert werden sollen.
	Sie führen einen Datenschutzhinweis, der die Rechtmäßigkeit der Verarbeitung personenbezogener Daten erläutern sollte
	Sie führen eine Datenschutzerklärung, in der die Rechte der betroffenen Person ausführlich erläutert werden: Recht auf Information, Recht auf Zugang der betroffenen Person, Recht auf Löschung, Recht auf Einschränkung der Verarbeitung, Recht auf Datenübertragbarkeit, Recht auf Widerspruch, Rechte in Bezug auf automatisierte Entscheidungsfindung, einschließlich Profilerstellung.
	Sie bewahren einen Datenschutzhinweis auf, in dem erläutert werden sollte, wie lange personenbezogene Daten aufbewahrt werden.

Überprüfung optionaler externer Complianceframeworks

Obwohl dies nicht erforderlich ist, können Sie, wenn Sie derzeit iso 27001, PCI DSS oder SOC2 einhalten, diese Zertifizierungen verwenden, um einige der Microsoft 365-Zertifizierungskontrollen zu erfüllen. Zertifizierungsanalysten versuchen, vorhandene externe Sicherheitsframeworks an die Microsoft 365-Zertifizierungsspezifikation anzupassen. Wenn die unterstützende Dokumentation jedoch nicht sicherstellen kann, dass die Microsoft 365-Zertifizierungskontrollen im Rahmen der Überwachung/Bewertung externer Sicherheitsframeworks bewertet wurden, müssen Sie zusätzliche Nachweise dafür bereitstellen, dass diese Kontrollen vorhanden sind.

Die Dokumentation muss angemessen nachweisen, dass die bereichsinterne Umgebung für die Microsoft 365-Zertifizierung in den Geltungsbereich dieser externen Sicherheitsframeworks eingeschlossen wurde. Die Validierung dieser Sicherheitsframeworks wird erfüllt, indem der Nachweis gültiger Zertifizierungen akzeptiert wird, die von renommierten externen Drittanbietern durchgeführt werden. Diese seriösen Unternehmen müssen Mitglieder internationaler Akkreditierungsstellen für relevante Compliance-Programme sein. Siehe ISO-Zertifizierung und Konformitätsstandards für ISO 27001 und Qualifizierte Sicherheitsassessoren (QSA) für PCI-DSS.

In der folgenden Tabelle sind die externen Frameworks und die Dokumentation aufgeführt, die von Zertifizierungsanalysten im Rahmen dieses Validierungsprozesses benötigt werden:

Standard	Anforderungen
ISO 27001	Eine öffentlich zugängliche Version der Erklärung zur Anwendbarkeit (Statement of Applicability , SOA) und eine Kopie des ausgestellten ISO 27001-Zertifikats sind erforderlich. Der SOA fasst Ihre Position zu jeder der 114 Informationssicherheitskontrollen zusammen und wird verwendet, um zu identifizieren, ob ein Ausschluss von Kontrollen, die im ISO 27001-Zertifikat nicht zufriedenstellend beschrieben sind. Wenn dies nicht durch überprüfen der öffentlich zugänglichen Version des SOA ermittelt werden kann, benötigt der Analyst möglicherweise Zugriff auf den vollständigen SOA, wenn ISO 27001 verwendet wird, um einige der Steuerelemente der Microsoft 365-Zertifizierungsspezifikation zu überprüfen. Neben der Überprüfung des Umfangs der ISO 27001-Bewertungsaktivitäten werden die Analysten auch die Gültigkeit des Auditunternehmens wie oben beschrieben bestätigen.
PCI/DSS	Es muss ein gültiges AOC-Dokument ( Level 1 Attestation of Compliance ) bereitgestellt werden, in dem die Anwendung und die Systemkomponenten im Bereich eindeutig identifiziert werden. Eine Selbstbewertungs-AOC wird nicht als Beweis für die Erfüllung bewährter Sicherheitsmethoden akzeptiert. Die AOC wird verwendet, um zu bestimmen, welche der Kontrollen der Microsoft 365-Zertifizierungsspezifikation im Rahmen der PCI-DSS-Bewertung bewertet und bestätigt wurden.
SOC 2	Der SOC 2-Bericht (Typ I oder Typ II) muss aktuell sein (ausgestellt innerhalb der letzten 15 Monate und des deklarierten Zeitraums, der innerhalb der letzten 27 Monate begonnen wurde), um als Nachweis für die Konformität mit einer der Bewertungskontrollen in dieser Microsoft 365-Zertifizierungsspezifikation verwendet zu werden.

Wenn externe Sicherheitsframeworks in den Herausgebernachweis aufgenommen wurden, müssen Zertifizierungsanalysten die Gültigkeit dieser Sicherheitscompliance-Frameworks im Rahmen der Microsoft 365-Zertifizierungsbewertung überprüfen.

Framework	Zusätzliche Überlegungen
ISO 27001	Anhang C: Beweissammlung – Deltas für ISO 27001.
PCI/DSS	Anhang D: Beweissammlung – Deltas für PCI-DSS.
SOC 2	Anhang E: Beweissammlung – Deltas für SOC 2.

Anforderungen für die Verwendung externer Complianceframeworks

✓ Die unterstützende App-/Add-In-Umgebung UND alle unterstützenden Geschäftsprozesse MÜSSEN in den Rahmen beliebiger unterstützter externer Sicherheits-Compliance-Frameworks aufgenommen werden und müssen in der bereitgestellten Dokumentation deutlich angegeben werden.

✓ Unterstützte externe Sicherheitscompliance-Frameworks MÜSSEN aktuell sein, d. a. innerhalb der letzten 12 Monate (oder innerhalb von 15 Monaten, wenn die Neubewertung derzeit durchgeführt wird und Beweise vorgelegt werden können).

✓ Unterstützte externe Sicherheits-Compliance-Frameworks MÜSSEN von einem unabhängigen akkreditierten Unternehmen durchgeführt werden.

Anhang A

Konfigurationsanforderungen für TLS-Profil

Der gesamte Netzwerkdatenverkehr innerhalb eines virtuellen Netzwerks, eines Clouddiensts oder eines Rechenzentrums muss mindestens mit TLS v1.1 (TLS v1.2+ wird empfohlen) oder einem anderen anwendbaren Protokoll geschützt werden. Ausnahmen von dieser Anforderung sind:

• HTTP-zu-HTTPS-Umleitung. Ihre App kann über HTTP antworten, um Clients an HTTPS umzuleiten, aber die Antwort darf keine vertraulichen Daten (Cookies, Header, Inhalte) enthalten. Außer Umleitungen an HTTPS und Antworten auf Integritätstests sind keine anderen HTTP-Antworten zulässig. Siehe unten.
• Integritätstests. Ihre App kann nur über HTTP auf Integritätstests reagieren , wenn HTTPS-Integritätstests von der Prüfpartei nicht unterstützt werden.
• Zertifikatzugriff. Der Zugriff auf CRL-, OCSP- und AIA-Endpunkte zum Zwecke der Zertifikatvalidierung und -sperrungsüberprüfung ist über HTTP zulässig.
• Lokale Kommunikation. Ihre App kann HTTP (oder andere nicht geschützte Protokolle) für Kommunikationen verwenden, die das Betriebssystem nicht verlassen, z. B. eine Verbindung mit einem Webserverendpunkt, der auf localhost verfügbar gemacht wird.

DIE TLS-Komprimierung MUSS deaktiviert sein.

Anhang B

Konfigurationsanforderungen für Verschlüsselungsprofile

Nur kryptografische Grundtypen und Parameter sind wie folgt zulässig:

Symmetrische Kryptografie

Verschlüsselung

 ✓ Nur AES, BitLocker, Blowfish oder TDES sind zulässig. Alle unterstützten Schlüssellängen >=128 sind zulässig (128 Bits, 192 Bit und 256 Bit) und können verwendet werden (256-Bit-Schlüssel werden empfohlen).

 ✓ Nur der CBC-Modus ist zulässig. Jeder Verschlüsselungsvorgang muss einen neuen, zufällig generierten Initialisierungsvektor (IV) verwenden.

 ✓ Die Verwendung von Datenstromchiffren wie RC4 , IST NICHT zulässig.

Hashfunktionen

 ✓ Jeder neue Code muss SHA-256, SHA-384 oder SHA-512 (zusammen als SHA-2 bezeichnet) verwenden. Die Ausgabe kann auf nicht weniger als 128 Bit abgeschnitten werden.

 ✓ SHA-1 darf nur aus Kompatibilitätsgründen verwendet werden.

 ✓ Die Verwendung von MD5, MD4, MD2 und anderen Hashfunktionen ist nicht zulässig, auch für nicht kryptografische Anwendungen.

Nachrichtenauthentifizierung

 ✓ Der neue Code MUSS HMAC mit einer der genehmigten Hashfunktionen verwenden. Die Ausgabe des HMAC kann auf nicht weniger als 128 Bit abgeschnitten werden.

 ✓ HMAC-SHA1 darf nur aus Kompatibilitätsgründen verwendet werden.

 ✓ Der HMAC-Schlüssel MUSS mindestens 128 Bits aufweisen. 256-Bit-Schlüssel werden empfohlen.

Asymmetrische Algorithmen

Verschlüsselung

 ✓ RSA ist zulässig. Der Schlüssel MUSS mindestens 2.048 Bits aufweisen, und die OAEP-Auffüllung muss verwendet werden. Die Verwendung des PKCS-Abstands ist nur aus Kompatibilitätsgründen zulässig.

Signaturen

 ✓ RSA ist zulässig. Der Schlüssel MUSS mindestens 2.048 Bits aufweisen, und PSS-Auffüllung muss verwendet werden. Die Verwendung des PKCS-Abstands ist nur aus Kompatibilitätsgründen zulässig.

 ✓ECDSA ist zulässig. Der Schlüssel MUSS mindestens 256 Bits aufweisen. Die NIST-Kurve P-256, P-384 oder P-521 muss verwendet werden.

Schlüsselaustausch

 ✓ ECDH ist erlaubt. Der Schlüssel MUSS mindestens 256 Bits aufweisen. Die NIST-Kurve P-256, P-384 oder P-521 muss verwendet werden.

 ✓ ECDH ist erlaubt. Der Schlüssel MUSS mindestens 256 Bits aufweisen. Die NIST-Kurve P-256, P-384 oder P-521 muss verwendet werden.

Anhang C

Beweissammlung – Delta für ISO 27001

Wenn Sie bereits ISO27001 Konformität erreicht haben, müssen die folgenden Deltas (Lücken), die nicht vollständig von ISO 27001 abgedeckt sind, mindestens im Rahmen dieser Microsoft 365-Zertifizierung überprüft werden.

Schutz vor Schadsoftware – Anti-Virus

Wenn der Schutz vor Schadsoftware mithilfe der Anwendungssteuerung vorhanden ist und innerhalb des ISO 27001-Berichts bestätigt wird, ist keine weitere Untersuchung erforderlich. Wenn keine Anwendungskontrolle vorhanden ist, müssen Zertifizierungsanalysten Beweise für Anwendungssteuerungsmechanismen identifizieren und bewerten, um die Detonation von Schadsoftware in der Umgebung zu verhindern. Dies erfordert Folgendes:

• Veranschaulichen, dass Antivirensoftware in allen Systemkomponenten der Stichprobe ausgeführt wird.

• Veranschaulichen, dass Virenschutz für alle erfassten Systemkomponenten konfiguriert ist, um Schadsoftware entweder automatisch zu blockieren, & Warnungen unter Quarantäne zu stellen oder warnungen.

• Antivirensoftware MUSS so konfiguriert werden, dass alle Aktivitäten protokolliert werden.

Patchverwaltung – Patchen

Da ISO 27001-Audits diese Kategorie nicht speziell bewerten, ist folgendes erforderlich:

• Softwarekomponenten und Betriebssysteme, die vom Anbieter nicht mehr unterstützt werden , DÜRFEN nicht innerhalb der Umgebung verwendet werden. Unterstützende Richtlinien MÜSSEN vorhanden sein, um sicherzustellen, dass nicht unterstützte Softwarekomponenten/Betriebssysteme aus der Umgebung entfernt werden. Außerdem muss ein Prozess zum Ermitteln des Ablaufs der Lebensdauer von Softwarekomponenten vorhanden sein.

Prüfung auf Schwachstellen

Da ISO 27001-Audits diese Kategorie nicht speziell bewerten, ist folgendes erforderlich:

• Veranschaulichen, dass vierteljährlich interne und externe Überprüfungen auf Sicherheitsrisiken durchgeführt werden.

• Vergewissern Sie sich, dass die unterstützende Dokumentation für die Behebung von Sicherheitsrisiken basierend auf der Risikorangfolge und gemäß der Spezifikation wie folgt vorhanden ist:

✓ Beheben Sie alle Kritischen und Highs-Risikoprobleme im Einklang mit der Risikorangfolge für die interne Überprüfung.

✓ Beheben Sie alle Probleme mit kritischem, hohem und mittlerem Risiko im Einklang mit der Risikorangfolge für externe Scans.

✓ Veranschaulichen, dass die Korrektur im Einklang mit der dokumentierten Richtlinie zur Behebung von Sicherheitsrisiken erfolgt.

Firewall – Firewalls (oder gleichwertige Technologien)

Da ISO 27001-Audits diese Kategorie nicht speziell bewerten, ist folgendes erforderlich:

• Veranschaulichen, dass Firewalls an der Grenze der Bereichsumgebung installiert sind.

• Veranschaulichen, dass Firewalls zwischen der DMZ und vertrauenswürdigen Netzwerken installiert sind.

• Veranschaulichen, dass der gesamte öffentliche Zugriff in der DMZ beendet wird.

• Veranschaulichen, dass die standardmäßigen Administratoranmeldeinformationen vor der Installation in der Liveumgebung geändert werden.

• Zeigen Sie, dass der gesamte zulässige Datenverkehr durch die Firewalls einen Autorisierungsprozess durchläuft, der zur Dokumentation des gesamten Datenverkehrs mit einer geschäftlichen Begründung führt.

• Veranschaulichen, dass alle Firewalls so konfiguriert sind, dass Datenverkehr gelöscht wird, der nicht explizit definiert ist.

• Veranschaulichen, dass Firewalls nur starke Kryptografie auf allen Verwaltungsschnittstellen unterstützen, die keine Konsolen sind.

• Veranschaulichen, dass die nicht konsolenbasierten Verwaltungsschnittstellen der Firewall, die für das Internet verfügbar gemacht werden, MFA unterstützen.

• Veranschaulichen, dass Firewallregelüberprüfungen mindestens alle 6 Monate durchgeführt werden

Firewall – Web Application Firewalls (WAF)

Zusätzliche Gutschriften werden bereitgestellt, wenn eine WAF bereitgestellt wird, um sich vor den unzähligen Bedrohungen und Sicherheitsrisiken von Webanwendungen zu schützen, denen die Anwendung ausgesetzt werden kann. Wenn eine WAF oder ein ähnliches vorhanden ist, müssen Sie folgendes ausführen:

• Veranschaulichen, dass die WAF im aktiven Verteidigungsmodus konfiguriert ist, oder überwachen Sie mehr mit Warnungen.

• Veranschaulichen, dass die WAF für die Unterstützung der SSL-Abladung konfiguriert ist.

• Wird gemäß dem OWASP Core-Regelsatz (3.0 oder 3.1) konfiguriert, um vor den meisten der folgenden Angriffstypen zu schützen:

✓ Protokoll- und Codierungsprobleme.

✓ Headerinjektion, Anforderungsschmuggel und Antwortaufteilung.

✓ Datei- und Pfaddurchquerungsangriffe.

✓ RFI-Angriffe (Remote File Inclusion).

✓ Remote-Codeausführungsangriffe.

✓ PHP-Einschleusungsangriffe.

✓ Cross-Site Scripting-Angriffe.

✓ Sql-Injection-Angriffe.

✓ Sitzungsfixierungsangriffe.

Änderungssteuerung

Da ISO 27001-Audits einige Elemente von Change Request-Prozessen nicht speziell bewerten, müssen Sie folgendes ausführen:

• Veranschaulichen, dass Änderungsanforderungen die folgenden Details aufweisen:

✓ Dokumentierte Auswirkung.

✓ Details dazu, welche Funktionalitätstests durchgeführt werden sollen.

✓ Details zu allen Back-Out-Verfahren.

• Veranschaulichen, dass Funktionstests durchgeführt werden, nachdem die Änderungen abgeschlossen sind.

• Veranschaulichen, dass Änderungsanforderungen nach durchführung von Funktionstests abgemeldet werden.

Kontoführung

Da ISO 27001-Audits einige Elemente von Kontoverwaltungsprozessen nicht speziell bewerten, ist folgendes erforderlich:

• Veranschaulichen, wie ✓s implementiert werden, um Replay-Angriffe (z. B. MFA, Kerberos) zu mindern.
• Veranschaulichen, wie Konten, die seit drei Monaten nicht mehr verwendet wurden, deaktiviert oder gelöscht werden.
• ✓oder andere geeignete Entschärfungen müssen zum Schutz von Benutzeranmeldeinformationen konfiguriert werden. Die folgende Mindestkennwortrichtlinie sollte als Richtlinie verwendet werden:

✓ Minimale Kennwortlänge von 8 Zeichen.

✓ Kontosperrungsschwellenwert von maximal 10 Versuchen.

✓ Kennwortverlauf von mindestens fünf Kennwörtern.

✓ Durchsetzung der Verwendung von sicheren Kennwörtern.

• Veranschaulichen, dass MFA für alle Remotezugriffslösungen konfiguriert ist.

• Veranschaulichen, dass für alle Remotezugriffslösungen eine starke Verschlüsselung konfiguriert ist.

• Wenn sich die Verwaltung des öffentlichen DNS außerhalb der Bereichsumgebung befindet, müssen alle Benutzerkonten, die DNS-Änderungen vornehmen können, für die Verwendung von MFA konfiguriert werden.

Intrusion Detection and Prevention (OPTIONAL)

Da ISO 27001-Audits einige Elemente von IdPS-Prozessen (Intrusion Detection and Prevention Services) nicht speziell bewerten, müssen Sie folgendes tun:

• IDPS SOLLTEN im Umkreis der unterstützenden Umgebung bereitgestellt werden.

• IDPS-Signaturen sollten innerhalb des letzten Tages auf dem neuesten Stand gehalten werden.

• IDPS SOLLTEN für die TLS-Überprüfung konfiguriert werden.

• IDPS SOLLTEN für DEN GESAMTEN eingehenden und ausgehenden Datenverkehr konfiguriert werden.

• IDPS SOLLTEN für Warnungen konfiguriert werden.

Ereignisprotokollierung

Da ISO 27001-Überwachungen einige Elemente der Protokollierung von Sicherheitsereignissen nicht speziell bewerten, ist folgendes erforderlich:

• Veranschaulichen, dass öffentliche Systeme die Protokollierung in einer zentralisierten Protokollierungslösung durchführen, die sich nicht innerhalb der DMZ befindet.

• Veranschaulichen, wie Protokollierungsdaten im Wert von mindestens 30 Tagen sofort verfügbar sind, wobei 90 Tage aufbewahrt werden.

Überprüfen (Protokollieren von Daten)

Da ISO 27001-Audits einige Elemente dieser Kategorie nicht speziell bewerten, ist folgendes erforderlich:

• Veranschaulichen, wie tägliche Protokollüberprüfungen durchgeführt werden und Wie Ausnahmen und Anomalien identifiziert werden, zeigen Sie, wie diese behandelt werden.

Alarmierung

Da ISO 27001-Audits einige Elemente dieser Kategorie nicht speziell bewerten, ist folgendes erforderlich:

• Veranschaulichen, wie Sicherheitsereignisse so konfiguriert werden, dass Warnungen zur sofortigen Selektierung ausgelöst werden.

• Veranschaulichen, wie Mitarbeiter 24/7 verfügbar sind, um auf Sicherheitswarnungen zu reagieren.

Risikomanagement

Da ISO 27001-Audits einige Elemente von Risikobewertungsprozessen nicht spezifisch bewerten, ist folgendes erforderlich:

• Veranschaulichen, dass ein formaler Risikomanagementprozess eingerichtet wurde.

Reaktion auf Vorfälle

Da ISO 27001-Audits einige Elemente von Richtlinien und Prozessen zur Reaktion auf Vorfälle nicht speziell bewerten, müssen Sie folgendes ausführen:

• Zeigen Sie, dass der Plan/die Prozedur zur Reaktion auf Vorfälle Folgendes umfasst:

✓ Spezifische Reaktionsverfahren für erwartete Bedrohungsmodelle.

✓ Funktionen zur Behandlung von Vorfällen, die auf das NIST Cybersecurity Framework (Identifizieren, Schützen, Erkennen, Reagieren, Wiederherstellen) ausgerichtet sind.

✓ Das IRP deckt die In-Scope-Systeme ab.

✓ Jährliche Schulung für das Incident Response Team.

Anhang D

Beweissammlung – Deltas für PCI-DSS

Wenn Sie bereits PCI-DSS-Konformität erreicht haben, müssen die folgenden Deltas (Lücken), die nicht vollständig von PCI-DSS abgedeckt sind, mindestens im Rahmen dieser Microsoft 365-Zertifizierung überprüft werden.

Schutz vor Schadsoftware – Anwendungssteuerung

Wenn schadsoftwareschutz durch Den Einsatz von Antivirensoftware vorhanden ist und im PCI-DSS-Bericht bestätigt wird, ist keine weitere Untersuchung erforderlich. Wenn kein Virenschutz vorhanden ist, müssen Zertifizierungsanalysten Beweise für Anwendungssteuerungsmechanismen identifizieren und bewerten, um die Detonation von Schadsoftware in der Umgebung zu verhindern. Dies erfordert Folgendes:

• Veranschaulichen Sie, wie die Genehmigung des Antrags durchgeführt wird, und bestätigen Sie, dass dies abgeschlossen ist.

• Zeigen Sie, dass eine vollständige Liste genehmigter Anwendungen mit geschäftlicher Begründung vorhanden ist.

• Bereitstellen oder Veranschaulichen sie unterstützende Dokumentation, in der ausführlich beschrieben wird, wie Die Anwendungskontrollessoftware so konfiguriert ist, dass sie bestimmte Anwendungssteuerungsmechanismen (d. h. Zulassungsliste, Codesignatur usw.) erfüllt.

• Veranschaulichen, dass die Anwendungssteuerung für alle erfassten Systemkomponenten wie dokumentiert konfiguriert ist.

Patchverwaltung – Risikorangfolge

Da PCI-DSS-Audits diese Kategorie nicht speziell bewerten, müssen Sie folgendes ausführen:

• Veranschaulichen, wie die Risikoeinstufung von Sicherheitsrisiken durchgeführt wird.

Prüfung auf Schwachstellen

Da PCI-DSS-Audits diese Kategorie nicht speziell bewerten, müssen Sie folgendes ausführen:

• Veranschaulichen, dass die Korrektur im Einklang mit der dokumentierten Richtlinie zur Behebung von Sicherheitsrisiken durchgeführt wird.

Firewall – Firewalls (oder gleichwertige Technologien)

Da PCI-DSS-Audits diese Kategorie nicht speziell bewerten, müssen Sie folgendes ausführen:

• Veranschaulichen, dass Firewalls nur starke Kryptografie auf allen Verwaltungsschnittstellen unterstützen, die keine Konsolen sind.

• Veranschaulichen, dass die nicht konsolenbasierten Verwaltungsschnittstellen der Firewall, die für das Internet verfügbar gemacht werden, MFA unterstützen.

Zusätzliche Gutschriften werden bereitgestellt, wenn eine Web Application Firewall (WAF) bereitgestellt wird, um sich vor den unzähligen Bedrohungen und Sicherheitsrisiken von Webanwendungen zu schützen, denen die Anwendung ausgesetzt sein kann. Wenn eine WAF oder ein ähnliches vorhanden ist, müssen Sie folgendes ausführen:

• Veranschaulichen, dass die WAF im aktiven Verteidigungsmodus konfiguriert ist, oder überwachen Sie mehr mit Warnungen.

• Veranschaulichen, dass die WAF für die Unterstützung der SSL-Abladung konfiguriert ist.

• Wird gemäß dem OWASP Core-Regelsatz (3.0 oder 3.1) konfiguriert, um vor den meisten der folgenden Angriffstypen zu schützen:

✓ Protokoll- und Codierungsprobleme.

✓ Headerinjektion, Anforderungsschmuggel und Antwortaufteilung.

✓ Datei- und Pfaddurchquerungsangriffe.

✓ RFI-Angriffe (Remote File Inclusion).

✓ Remote-Codeausführungsangriffe.

✓ PHP-Einschleusungsangriffe.

✓ Cross-Site Scripting-Angriffe.

✓ Sql-Injection-Angriffe.

✓ Sitzungsfixierungsangriffe.

Änderungssteuerung

Da PCI-DSS-Audits einige Elemente von Change Request-Prozessen nicht speziell bewerten, müssen Sie folgendes ausführen:

• Veranschaulichen, dass Änderungsanforderungen ausgelöst werden, bevor sie in Produktionsumgebungen vorgenommen werden.

• Veranschaulichen, dass Änderungen autorisiert werden, bevor sie in die Produktion gehen.

• Veranschaulichen, dass Funktionstests durchgeführt werden, nachdem die Änderungen abgeschlossen sind.

• Veranschaulichen, dass Änderungsanforderungen nach durchführung von Funktionstests abgemeldet werden.

Sichere Softwareentwicklung/-bereitstellung

Da PCI-DSS-Audits nicht speziell auf einige Elemente sicherer Softwareentwicklungs- und -bereitstellungsprozesse zugreifen; Dies erfordert Folgendes:

• Coderepositorys MÜSSEN durch MFA gesichert werden.

• Es MÜSSEN angemessene Zugriffskontrollen vorhanden sein, um Coderepositorys vor böswilligen Codeänderungen zu schützen.

Kontoführung

Da PCI-DSS-Audits einige Elemente von Kontoverwaltungsprozessen nicht speziell bewerten, müssen Sie folgendes ausführen:

• Veranschaulichen, wie die Autorisierungsmechanismen implementiert werden, um Replay-Angriffe (z. B. MFA, Kerberos) zu minimieren.

• Richtlinien für sichere Kennwörter oder andere geeignete Gegenmaßnahmen müssen konfiguriert werden, um Benutzeranmeldeinformationen zu schützen. Die folgende Mindestkennwortrichtlinie sollte als Richtlinie verwendet werden:

✓ Minimale Kennwortlänge von 8 Zeichen.

✓ Kontosperrungsschwellenwert von maximal 10 Versuchen.

✓ Kennwortverlauf von mindestens fünf Kennwörtern.

✓ Durchsetzung der Verwendung von sicheren Kennwörtern.

• Veranschaulichen, dass für alle Remotezugriffslösungen eine starke Verschlüsselung konfiguriert ist.

• Wenn sich die Verwaltung des öffentlichen DNS außerhalb der Bereichsumgebung befindet, müssen alle Benutzerkonten, die DNS-Änderungen vornehmen können, für die Verwendung von MFA konfiguriert werden.

Intrusion Detection and Prevention (OPTIONAL)

Da PCI-DSS-Audits einige Elemente von Intrusion Detection and Prevention Services (IDPS)-Prozessen nicht speziell bewerten, müssen Sie folgendes tun:

• IDPS SOLLTEN für die TLS-Überprüfung konfiguriert werden.

• IDPS SOLLTEN für DEN GESAMTEN eingehenden und ausgehenden Datenverkehr konfiguriert werden.

Risikomanagement

Da PCI-DSS-Audits einige Elemente von Risikobewertungsprozessen nicht spezifisch bewerten, ist folgendes erforderlich:

• Veranschaulichen der Risikobewertung, die Auswirkungen- und Wahrscheinlichkeitsmatrizen umfasst.

Reaktion auf Vorfälle

Da PCI-DSS-Überwachungen einige Elemente von Richtlinien und Prozessen zur Reaktion auf Vorfälle nicht speziell bewerten, erfordert dies folgendes:

• Veranschaulichen der Funktionen zur Behandlung von Vorfällen, die dem NIST Cybersecurity Framework entsprechen (Identifizieren, Schützen, Erkennen, Reagieren, Wiederherstellen).

Anhang E

Beweissammlung – Deltas für SOC 2

Wenn Sie bereits DIE SOC 2-Konformität erreicht haben, müssen die folgenden Deltas (Lücken), die nicht vollständig von SOC 2 abgedeckt sind, im Rahmen dieser Microsoft 365-Zertifizierung überprüft werden.

Schutz vor Schadsoftware – Anwendungssteuerung

Wenn ein Schadsoftwareschutz durch den Einsatz von Viren besteht und in Ihrem SOC 2-Bericht bestätigt wird, ist keine weitere Untersuchung erforderlich. Wenn kein Virenschutz vorhanden ist, müssen Zertifizierungsanalysten Beweise für Anwendungssteuerungsmechanismen identifizieren und bewerten, um die Detonation von Schadsoftware in der Umgebung zu verhindern. Dies erfordert Folgendes:

• Bereitstellen oder Veranschaulichen sie unterstützende Dokumentation, in der ausführlich beschrieben wird, wie Die Anwendungskontrollessoftware so konfiguriert ist, dass sie bestimmte Anwendungssteuerungsmechanismen (d. h. Zulassungsliste, Codesignatur usw.) erfüllt.

• Veranschaulichen Sie, wie die Genehmigung des Antrags durchgeführt wird, und bestätigen Sie, dass dies abgeschlossen ist.

• Zeigen Sie, dass eine vollständige Liste genehmigter Anwendungen mit geschäftlicher Begründung vorhanden ist.

• Veranschaulichen, dass die Anwendungssteuerung für alle erfassten Systemkomponenten wie dokumentiert konfiguriert ist.

Patchverwaltung – Patchen

Da SOC 2-Überwachungen diese Kategorie nicht speziell bewerten, müssen Sie folgendes ausführen:

• Jedes Low-, Medium-, High- oder Critical-Problem muss in normalen Patchaktivitätsfenstern gepatcht werden.

• Softwarekomponenten und Betriebssysteme, die vom Anbieter nicht mehr unterstützt werden, DÜRFEN nicht innerhalb der Umgebung verwendet werden. Unterstützende Richtlinien MÜSSEN vorhanden sein, um sicherzustellen, dass nicht unterstützte Softwarekomponenten/Betriebssysteme aus der Umgebung entfernt werden, und es muss ein Prozess zur Identifizierung des Ablaufs der Lebensdauer von Softwarekomponenten vorhanden sein.

Firewall – Firewalls

Da SOC 2-Überwachungen änderungssteuerungen für Firewallzugriffssteuerungslisten nicht speziell bewerten, müssen Sie folgendes ausführen:

• Veranschaulichen, dass der gesamte zulässige Datenverkehr durch die Firewalls einen Autorisierungsprozess durchläuft, der zur Dokumentation des gesamten Datenverkehrs mit einer geschäftlichen Begründung führt.

• Veranschaulichen, dass Überprüfungen von Firewallregeln mindestens alle sechs Monate durchgeführt werden.

Zusätzliche Gutschriften werden bereitgestellt, wenn eine Web Application Firewall (WAF) oder ähnliches bereitgestellt wird, um sich vor den unzähligen Bedrohungen und Sicherheitsrisiken von Webanwendungen zu schützen, denen die Anwendung ausgesetzt sein kann. Wenn eine WAF oder ein ähnliches vorhanden ist, müssen Sie folgendes ausführen:

• Veranschaulichen, dass die WAF im aktiven Verteidigungsmodus konfiguriert ist, oder überwachen Sie mehr mit Warnungen.

• Veranschaulichen, dass die WAF für die Unterstützung der SSL-Abladung konfiguriert ist.

• Wird gemäß dem OWASP Core-Regelsatz ((3.0 oder 3.1) konfiguriert, um vor den meisten der folgenden Angriffstypen zu schützen:

 ✓ Protokoll- und Codierungsprobleme.

 ✓ Headerinjektion, Anforderungsschmuggel und Antwortaufteilung.

 ✓ Datei- und Pfaddurchquerungsangriffe.

 ✓ RFI-Angriffe (Remote File Inclusion).

 ✓ Remote-Codeausführungsangriffe.

 ✓ PHP-Einschleusungsangriffe.

 ✓ Cross-Site Scripting-Angriffe.

 ✓ Sql-Injection-Angriffe.

 ✓ Sitzungsfixierungsangriffe.

Änderungssteuerung

Da SOC 2-Überwachungen einige Elemente von Änderungsanforderungsprozessen nicht speziell bewerten, erfordert dies vom Entwickler Folgendes:

• Veranschaulichen, wie Entwicklungs-/Testumgebungen von der Produktionsumgebung getrennt sind, um die Trennung von Aufgaben zu erzwingen.

• Veranschaulichen, dass Livedaten in den Entwicklungs-/Testumgebungen nicht verwendet werden.

• Veranschaulichen, dass Funktionstests durchgeführt werden, nachdem die Änderungen abgeschlossen sind.

• Veranschaulichen, dass Änderungsanforderungen nach durchführung von Funktionstests abgemeldet werden.

Sichere Softwareentwicklung/-bereitstellung

Da SOC 2-Überwachungen nicht speziell auf einige Elemente sicherer Softwareentwicklungs- und -bereitstellungsprozesse zugreifen; Dies erfordert Folgendes:

• Sie MÜSSEN über einen etablierten und dokumentierten Softwareentwicklungsprozess verfügen, der den gesamten Lebenszyklus der Softwareentwicklung abdeckt.

• Entwickler MÜSSEN sich mindestens jährlich einer sicheren Softwarecodierungsschulung unterziehen.

• Coderepositorys MÜSSEN durch MFA gesichert werden.

• Es MÜSSEN angemessene Zugriffskontrollen vorhanden sein, um Coderepositorys vor böswilligen Codeänderungen zu schützen.

Kontoführung

Da SOC2-Überwachungen einige Elemente von Kontoverwaltungsprozessen nicht speziell bewerten, ist folgendes erforderlich:

• Veranschaulichen, wie die Autorisierungsmechanismen implementiert werden, um Replay-Angriffe (z. B. MFA, Kerberos) zu minimieren.

• Veranschaulichen, wie Konten, die seit drei Monaten nicht mehr verwendet wurden, deaktiviert oder gelöscht werden.

• Richtlinien für sichere Kennwörter oder andere geeignete Gegenmaßnahmen müssen konfiguriert werden, um Benutzeranmeldeinformationen zu schützen. Die folgende Mindestkennwortrichtlinie sollte als Richtlinie verwendet werden:

 ✓ Minimale Kennwortlänge von 8 Zeichen.

 ✓ Kontosperrungsschwellenwert von maximal 10 Versuchen.

 ✓ Kennwortverlauf von mindestens 5 Kennwörtern.

 ✓ Durchsetzung der Verwendung von sicheren Kennwörtern

• Veranschaulichen, dass eindeutige Benutzerkonten für alle Benutzer ausgestellt werden.

• Wenn sich die Verwaltung des öffentlichen DNS außerhalb der Bereichsumgebung befindet, müssen alle Benutzerkonten, die DNS-Änderungen vornehmen können, für die Verwendung von MFA konfiguriert werden.

Angriffserkennung und -verhinderung (OPTIONAL).

Da SOC 2-Überwachungen einige Elemente von Intrusion Detection and Prevention Services (IDPS)-Prozessen nicht speziell bewerten, ist folgendes erforderlich:

• IDPS-Signaturen sollten innerhalb des letzten Tages auf dem neuesten Stand gehalten werden

• IDPS SOLLTEN für die TLS-Überprüfung konfiguriert werden

• IDPS SOLLTEN für DEN GESAMTEN eingehenden und ausgehenden Datenverkehr konfiguriert werden

Ereignisprotokollierung

Da SOC 2-Überwachungen einige Elemente der Protokollierung von Sicherheitsereignissen nicht speziell bewerten, müssen Sie folgendes ausführen:

• Veranschaulichen, wie für alle Systemkomponenten innerhalb des Beispielsatzes das folgende System so konfiguriert wird, dass die folgenden Ereignisse protokolliert werden

 ✓ Benutzerzugriff auf Systemkomponenten und die Anwendungen.

 ✓ Alle Aktionen, die von einem Benutzer mit hohen Berechtigungen ausgeführt werden.

 ✓ Ungültige logische Zugriffsversuche.

Veranschaulichen, dass protokollierte Ereignisse folgendes enthalten: mindestens die folgenden Informationen:

 ✓ Benutzer.

 ✓ Art des Ereignisses.

 ✓ Datum und Uhrzeit.

 ✓ Erfolgs-/Fehleranzeige.

 ✓ Bezeichnung, um das betroffene System zu identifizieren.

• Veranschaulichen, dass alle Systemkomponenten innerhalb des Beispielsatzes für die Verwendung der Zeitsynchronisierung konfiguriert sind und dass diese mit den primären/sekundären Zeitservern identisch sind.

• Veranschaulichen, dass öffentliche Systeme die Protokollierung in einer zentralisierten Protokollierungslösung durchführen, die sich nicht innerhalb der DMZ befindet.

• Veranschaulichen, dass öffentliche Systeme die Protokollierung in einer zentralisierten Protokollierungslösung durchführen, die sich nicht innerhalb der DMZ befindet.

• Veranschaulichen, wie die zentralisierte Protokollierungslösung vor unbefugter Manipulation von Protokollierungsdaten geschützt ist.

• Veranschaulichen, wie Protokollierungsdaten im Wert von mindestens 30 Tagen sofort verfügbar sind, wobei mindestens 90 Tage aufbewahrt werden.

Risikomanagement

Da SOC2-Audits einige Elemente von Risikobewertungsprozessen nicht speziell bewerten, müssen Sie folgendes ausführen:

• Nachweisen, dass mindestens jährlich eine formale Risikobewertung durchgeführt wird.

Reaktion auf Vorfälle.

Da BEI SOC2-Überwachungen einige Elemente von Richtlinien und Prozessen zur Reaktion auf Vorfälle nicht speziell bewertet werden, ist folgendes erforderlich:

• Zeigen Sie, dass der Plan/die Prozedur zur Reaktion auf Vorfälle Folgendes umfasst:

 ✓ Spezifische Reaktionsverfahren für erwartete Bedrohungsmodelle.

 ✓ Dokumentierter Kommunikationsprozess, um eine rechtzeitige Benachrichtigung wichtiger Akteure (Zahlungsmarken/Erwerber, Aufsichtsbehörden, Aufsichtsbehörden, Direktoren, Kunden usw.) zu gewährleisten.

Anhang F

Hostingbereitstellungstypen

Microsoft bestätigt, dass Sie Anwendungen bereitstellen und App-/Add-In-Code in verschiedenen Hostingumgebungen speichern. Die Gesamtverantwortung einiger sicherheitsrelevanter Kontrollen innerhalb der Microsoft 365-Zertifizierung hängt von der verwendeten Hostingumgebung ab. Anhang F befasst sich mit gängigen Bereitstellungstypen und ordnet diese den Sicherheitskontrollen zu, die im Rahmen des Bewertungsprozesses ausgewertet werden. Die folgenden Hostingbereitstellungstypen wurden identifiziert:

Hostingtypen	Beschreibung
IsV gehostet	Von ISV gehostete Typen können als definiert werden, wo Sie für die Infrastruktur verantwortlich sind, die zur Unterstützung der App-/Add-In-Umgebung verwendet wird. Dies kann sich physisch in Ihren eigenen Rechenzentren oder Rechenzentren von Drittanbietern mit einem Co-Location-Dienst befinden. Letztendlich haben Sie den vollständigen Besitz und die administrative Kontrolle über die unterstützende Infrastruktur und die Betriebsumgebung.
Infrastructure-as-a-Service (IaaS) (https://azure.microsoft.com/overview/what-is-iaas/)	Infrastructure-as-a-Service ist ein Dienst, der bereitgestellt wird, bei dem die physische unterstützende Infrastruktur in ihrem Namen vom Clouddienstanbieter (Cloud Service Provider, CSP) verwaltet und verwaltet wird. In der Regel sind Netzwerke, Speicher, physische Server und die Virtualisierungsinfrastruktur die gesamte Verantwortung des CSP. Betriebssystem, Middleware, Runtime, Daten und Anwendungen liegen in ihrer Verantwortung. Firewallfunktionen würden auch vom Drittanbieter verwaltet und verwaltet, aber die Wartung der Firewallregelbasis würde in der Regel weiterhin in der Verantwortung der Verbraucher stehen.
Platform-as-a-Service/Serverless (PaaS) (https://azure.microsoft.com/overview/what-is-paas/)	Mit Platform-as-a-Service werden Sie mit einer verwalteten Plattform bereitgestellt, die einen Dienst darstellt, der genutzt werden kann. Sie müssen keine sysadmin-Funktionen ausführen, da das Betriebssystem und die unterstützende Infrastruktur vom CSP verwaltet werden. Dies wird in der Regel verwendet, wenn Organisationen sich nicht um die Präsentation eines Webdiensts kümmern möchten, sondern sich stattdessen auf die Erstellung des Quellcodes der Webanwendung und die Veröffentlichung der Webanwendung in den cloudverwalteten Webdiensten konzentrieren können. Ein weiteres Beispiel ist ein Datenbankdienst, bei dem die Konnektivität mit einer Datenbank erfolgt, die unterstützende Infrastruktur und Datenbankanwendung jedoch vom Consumer abstrahiert wird. Hinweis: Serverlos und PaaS sind ähnlich, sodass für den Zweck des Microsoft 365-Zertifizierungshosting-Bereitstellungstyps serverlos und PasS als identisch angesehen werden.
Hybrid gehostet	Mit dem hybrid gehosteten Typ können Sie mehrere gehostete Typen verwenden, um verschiedene Teile der unterstützenden Umgebung zu unterstützen. Dies kann eher der Fall sein, wenn Apps/Add-Ins über mehrere Microsoft 365-Stapel hinweg verwendet werden. Obwohl die Microsoft 365-Zertifizierung unterstützt, wo Apps/Add-Ons für mehrere Microsoft 365-Dienste entwickelt werden, muss eine Bewertung der gesamten (app-/add-ins-übergreifenden) unterstützenden Umgebung gemäß den jeweiligen "Gehosteten Typzuordnungen" bewertet werden. Gelegentlich können Sie verschiedene gehostete Typen für ein einzelnes Add-In verwenden. Die Anwendbarkeit von Kriterien muss weiterhin den Kriterien für die verschiedenen gehosteten Typen folgen.
Freigegebenes Hosting	Shared Hosting ist der Ort, an dem Sie die Umgebung innerhalb einer Plattform hosten, die von mehreren einzelnen Consumern gemeinsam genutzt wird. Die Microsoft 365-Zertifizierungsspezifikation wurde aufgrund der Einführung der Cloud nicht dazu geschrieben, dies zu berücksichtigen. Gemeinsames Hosting ist nicht üblich. Wenn Sie der Meinung sind, dass dies verwendet wird, wenden Sie sich an Microsoft, da zusätzliche Anforderungen erstellt werden müssen, um die zusätzlichen Risiken bei diesem Hostingtyp zu berücksichtigen.

Anhang G

Weitere Informationen

Microsoft 365 App Compliance Program OverviewWas ist Microsoft 365 App Publisher Attestation?Was ist die Microsoft 365-Zertifizierung?

Glossar

AIA

*Zugriff auf Autoritätsinformationen ist ein Dienststandortdeskriptor, der zum Suchen des Zertifikats der ausstellenden Zertifizierungsstelle verwendet wird.

ZERTIFIKATSPERRLISTE

*Zertifikatsperrliste bietet eine Möglichkeit für einen SSL-Endpunkt (Secure Sockets Layer), um zu überprüfen, ob ein von einem Remotehost empfangenes Zertifikat gültig und vertrauenswürdig ist.

CVSS-Bewertung

*Common Vulnerability Scoring System ist ein veröffentlichter Standard, der die Sicherheitsanfälligkeit misst und eine numerische Bewertung basierend auf ihrem Schweregrad berechnet.

CVSS-Patchverwaltungsrichtlinien

• Kritisch (9.0 - 10.0)
• Hoch (7,0 - 8,9)
• Mittel (4.0 - 6.9)
• Niedrig (0,0 - 3,9)

DMZ

*Demilitarisierte Zone ist ein physisches oder logisches Zwischennetzwerk, das direkt externe oder nicht anständige Netzwerke interagiert und gleichzeitig das interne, private Netzwerk des Hosts getrennt und isoliert hält.

EUII

Identifizierbare Informationen des Endbenutzers.

DSGVO

*Die Datenschutz-Grundverordnung ist eine Datenschutz- und Datenschutzverordnung der Europäischen Union (EU) für alle Daten von EU-Bürgern, unabhängig davon, wo sich Ihre Anwendungswebsite befindet.

HSTS

*HTTP Strict Transport Security verwendet einen HTTP-Antwortheader, der den Webbrowser anweist, nur auf Inhalte über HTTPS zuzugreifen. Dies dient zum Schutz vor Downgrade-Angriffen und Cookie-Hijacking.

IEC

*Internationale Elektrotechnische Kommission.

ISMEN

*Informationssicherheits-Managementsystem.

ISV

Unabhängige Sicherheitsanbieter sind Einzelpersonen und Organisationen, die Software entwickeln, vermarkten und verkaufen, die auf Software- und Hardwareplattformen von Drittanbietern ausgeführt wird.

ISO 27001

Ein Spezifikationsframework für das Informationssicherheits-Managementsystem für alle technischen Kontrollen in Risikomanagementrichtlinien und Verfahrensprozessen einer Organisation.

LFI

Die Lokale Dateieinschluss ermöglicht es einem Angreifer, Dateien über den Webbrowser auf einem Server einzuschließen.

NIST

Das National Institute of Standards (NIST), eine Nicht-Regulierungsbehörde des US-Handelsministeriums, stellt Anleitungen für Organisationen des privatsektors in den USA bereit, um ihre Fähigkeit zu bewerten und zu genehmigen, Cyberangriffe zu verhindern, zu erkennen und darauf zu reagieren.

Nicht signifikante Änderungen

• Kleinere Fehlerbehebungen.
• Geringfügige Leistungsverbesserungen.
• Patches für Betriebssysteme/Bibliotheken/Client- und Serveranwendungen.

OCSP

Online Certificate Status Protocol wird verwendet, um den Sperrstatus von digitalen X.509-Zertifikaten zu überprüfen.

OII

Identifizierbare Informationen der Organisation.

OWASP

Öffnen Sie das Webanwendungssicherheitsprojekt.

PCI/DSS

Payment Card Industry Data Security Standard, eine Organisation, die Weltweit Standards für die Sicherheit von Karteninhaberdaten verwaltet.

Stifttests

Penetrationstests sind eine Methode zum Testen einer Web-App, indem böswillige Angriffe simuliert werden, um Sicherheitsrisiken zu finden, die ein Angreifer ausnutzen könnte.

SAML

Security Assertion Markup Language ist ein offener Standard für den Austausch von Authentifizierungs- und Autorisierungsdaten zwischen dem Benutzer, dem Identitätsanbieter und dem Dienstanbieter.

Vertrauliche Daten

• Zugriffssteuerungsdaten.
• Kundeninhalte.
• Informationen zur Endbenutzeridentität.
• Supportdaten.
• Öffentliche personenbezogene Daten.
• Pseudonyme Endbenutzerinformationen.

Wesentliche Änderungen

• Verlagerung der Hostingumgebung.
• Umfangreiche Modernisierungen der unterstützenden Infrastruktur; Beispielsweise die Implementierung einer neuen Firewall, wichtige Upgrades für Front-Facing-Dienste usw.
• Hinzufügen von Funktionen und /oder Erweiterungen zu Ihrer App.
• Updates für Ihre App, die zusätzliche vertrauliche Daten erfassen.
• Änderungen an den Datenflüssen oder Autorisierungsmodellen Ihrer App
• Hinzufügen von API-Endpunkten oder API-Endpunktfunktionen.

SOC 2

Service Organization Control 2, ein technisches Überwachungsverfahren, das aus fünf Trust Service Principles besteht, um sicherzustellen, dass Dienstanbieter die Daten und den Datenschutz für die Kunden einer Organisation sicher verwalten.

SSL

Secure Sockets Layer.

TLS

Transport Layer Security.