Dokumentation zu Microsoft 365 App Compliance – Anhang und Glossar

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.

Hinweis

Im Rahmen Ihrer Microsoft 365-Zertifizierungsbewertung bestimmt der Zertifizierungsanalyst, ob eines der zugeordneten ISO 27001-Kontrollen nicht im Rahmen der ISO 27001-Bewertung enthalten war, und kann sich auch für Stichprobenkontrollen entscheiden, die als einbezogen wurden, um weitere Sicherheit zu bieten. Alle Anforderungen, die in der ISO 27001 fehlen, müssen in Ihre Microsoft 365-Zertifizierungsbewertungsaktivitäten einbezogen 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.

Kontoverwaltung

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.

Hinweis

Im Rahmen der Microsoft 365-Zertifizierungsbewertung ermittelt der Zertifizierungsanalyst, ob eines der zugeordneten PCI-DSS-Steuerelemente nicht in die PCI-DSS-Bewertung einbezogen wurde, und kann sich auch entscheiden, Stichprobenkontrollen durchzuführen, die als einbezogen wurden, um weitere Sicherheit zu bieten. Alle Anforderungen, die im PCI-DSS fehlen, müssen in die Microsoft 365-Zertifizierungsbewertungsaktivitäten einbezogen 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 ein 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.

Kontoverwaltung

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.

Hinweis

Im Rahmen der Microsoft 365-Zertifizierungsbewertung bestimmt der Zertifizierungsanalyst, ob eines der zugeordneten SOC 2-Steuerelemente nicht in Ihre SOC 2-Bewertung einbezogen wurde, und kann sich auch für Stichprobenkontrollen entscheiden, die als einbezogen wurden, um weitere Sicherheit zu bieten. Alle Anforderungen, die in Ihrer SOC 2-Bewertung fehlen, müssen im Rahmen der Microsoft 365-Zertifizierungsbewertungsaktivitäten enthalten sein.

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.

Wenn ein Web Application Firewall (WAF) oder ähnliches bereitgestellt wird, wird ein zusätzliches Guthaben bereitgestellt, 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.

Kontoverwaltung

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.

FedRAMP

Das Federal Risk and Authorization Management Program (FedRAMP) ist ein 2011 in den USA gegründetes Bundesprogramm. Es bietet einen standardisierten Ansatz für die Sicherheitsbewertung, Autorisierung und kontinuierliche Überwachung von Cloudprodukten und -diensten.

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.

THEORIEN

*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 die Sperrung status digitaler X.509-Zertifikate zu überprüfen.

OII

Identifizierbare Informationen der Organisation.

OWASP

Öffnen Sie das Webanwendungssicherheitsprojekt.

PCI/DSS

Payment Card Industry Data Security Standard, ein organization, der Weltweit Standards für die Sicherheit von Karteninhaberdaten einhält.

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 zu Ihrer 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 Überprüfungsverfahren, das aus fünf Trust Service Principles besteht, um sicherzustellen, dass Dienstanbieter die Daten und den Datenschutz für die Kunden eines organization sicher verwalten.

SSL

Secure Sockets Layer.

TLS

Transport Layer Security.