Beispiel für eine Governance-Richtline (hier: MS 365 Sicherheitsrichtlinie
| REQ-ID | PRIO | REGELUNG |
| ISA-M365-XXX | [t.b.d.] | Die Verwaltung von Azure-Abonnements MUSS zentral vom Cloud-Team der X_ORG_X durchgeführt werden.
[HINTERGRUND] Da die Betriebsmodelle von Azure (insbesondere laaS) viel Freiheit beim Entwerfen von Netzwerken und Systemarchitekturen ermöglichen, darf das Erstellen und Verwalten von Abonnements in Azure NICHT für einzelne Benutzer oder für Teams zugelassen werden. Dies muss durch technische und organisatorische Mittel verhindert werden. |
| ISA-M365-XXX | [t.b.d.] | Administration via M365 Compliance und M365 Security Center
Die Administration der X_ORG_X Umgebung SOLLTE mittels M365 Security Center sowie über das M365 Compliance Center erfolgen. **gekürzte Version ohne weitergehende Erklärungen!** |
| ISA-M365-XXX | [t.b.d.] | Namenskonventionen für die Anlage von Gruppen, Teams, MPP Umgebungen etc. |
| ISA-M365-XXX | [t.b.d.] | Notfall-und Userkonzept (Break glass Account) |
| ISA-M365-XXX | [t.b.d.] | Härtung unter Einsatz von Empfehlungen aus Frameworks (z. B. NIST) |
| REQ-ID | PRIO | REGELUNG |
| ISA-M365-XXX | [t.b.d.] |
Das Identitätsmodell von Azure Active Directory bestimmt im Wesentlichen, woher Benutzerkonten stammen, wo sie verwaltet werden und welche Instanz in der Umgebung für die Authentifizierung von Benutzern verantwortlich ist.
Zulässig bei X_ORG_X sind grundsätzlich die nachfolgend gelisteten, wobei bzgl. exponierter Accounts Spezialanforderungen zu berücksichtigen sind (siehe ISA-M365-402 ff). - Kennwortsynchronisierung: Benutzerkonten werden hier mit Azure AD synchronisiert, einschließlich ihrer Kennworthashes. Bei der Anmeldung kann Azure AD die Anmeldeinformationen direkt überprüfen, indem das eingegebene Kennwort gehasht und verglichen wird. - Pass-Through-Authentifizierung: Die eigentliche Authentifizierung wird an einen lokalen Authentifizierungsdienst übergeben, der mit einem Domänencontroller kommuniziert. Der Client kommuniziert jedoch weiterhin nur mit Azure AD, und Azure AD selbst kommuniziert mit den lokalen Instanzen über einen separaten Kanal und erstellt Zugriffstoken bei Erfolg. Grundlegende Benutzerinformationen werden weiterhin von lokal mit Azure AD synchronisiert. - Verbund: Authentifizierung und Erstellung von Zugriffstoken, die vollständig an einen vertrauenswürdigen Verbunddienst (z.B. ADFS) übergeben werden. Azure AD leitet Benutzer hierfür einfach an den jeweiligen Webproxy von ADFS um und ist selbst nicht an der Authentifizierung von Verbundbenutzern beteiligt. Grundlegende Benutzerinformationen werden weiterhin von lokal mit Azure AD synchronisiert. |
| ISA-M365-XXX | [t.b.d.] | Vorgaben hinsichtlich der Konfiguration des Identitätsmodells bei exponierten Rollen
Benutzer mit Administratorrechten DÜRFEN in der lokalen Domäne NICHT mit der Cloud synchronisiert werden. Diese Maßnahme trägt dazu bei, die Angriffsfläche privilegierter Konten zu reduzieren und somit das Risiko einer Kompromittierung zu verringern.
Hinweis: Für einige bestimmte Benutzer (z. B. Notfallkonten) MUSS allerdings das Cloud ldentity-Modell verwendet werden, um den Verlust des Zugriffs auf die Cloud-Umgebung im Falle eines Ausfalls oder Angriffs auf die Verbunddienste zu verhindern. Darüber hinaus dürfen Notfallkonten NICHT auf die gleiche Kombination von Zugriffskontrollen (z.B. dieselben Multifaktor-Authentifizierungsmethoden) angewiesen sein wie normale Benutzer, z. B. Global Admin ohne Conditional Access / MFA (als „break-glass-account“). Seitens X_ORG_X IT ist ein Notfall-User-Konzept zu dokumentieren. |
| ISA-M365-XXX | [t.b.d.] | Grundsatz MFA-Authentifizierung
Die MFA-Authentifizierung MUSS für alle Benutzer in Microsoft 365 verwendet werden.
Ausnahme stellen ggfs. Notfalluser dar (siehe Break-Glass-Account). Für - privilegierte Administratorrollen und/oder - den Zugriff auf vertrauliche Unternehmensdaten MUSS jedoch die mehrstufige Authentifizierung aktiviert sein |
| ISA-M365-XXX | [t.b.d.] | MFA für exponierte Rollen mit privilegierten Rechten
Entsprechend der vorherig dokumentierten Anforderung muss für privilegierte Administratorrollen die mehrstufige Authentifizierung aktiviert sein¬¬. Für diese Art des Zugriffs MUSS die Vertrauensebene von MFA/Authentifizierung folglich „HOCH“ sein. Dazu gehören u.a folgende Rollen:
• Globaler Administrator • Abrechnungs/ Billling -Administrator • Exchange-Administrator • SharePoint-Administrator • Power BI-Administrator • Administrator für bedingten Zugriff • lntune Administrator • Administrator für privilegierte Authentifizierung • Teams-Administrator Hinweis: Der folgende Link zeigt eine vollständige Liste der Administratorrollen: https://docs.microsoft.com/en-us/microsoft-365/admin/add users/about-admin-roles?view=o365-worldwide X_ORG_X IT (IT-ORG) hat in einem Berechtigungskonzept aufzuzeigen, welche Rollen einer MFA Anforderung unterliegen. |
| ISA-M365-XXX | [t.b.d.] | Revisionssicheres Global-Admin-Konzept
Bei X_ORG_X sollten zwischen zwei und maximal fünf globale Administratoren benannt sind.
Die Tätigkeiten der Kollegen sind revisionssicher zu überwachen. |
| ISA-M365-XXX | [t.b.d.] | Verwendung der Self-Service-Kennwortzurücksetzung (SSPR)
Die Verwendung der Self-Service-Kennwortzurücksetzung (SSPR) sollte aktiviert sein. |
| ISA-M365-XXX | [t.b.d.] | Aktivierung des AD Passwortschutzes sowie Verhinderung von Legacy-Authentifizierung
Es muss sichergestellt sein, dass der Passwortschutz für Active Directory aktiviert ist.
Legacy-Authentifizierung darf im X_ORG_X Tenant ebenfalls nicht unterstützt werden, weshalb der Einsatz von „Richtlinien für bedingten Zugriff“ (Azure AD Conditional Access) aktiviert sein muss. |
| ISA-M365-XXX | [t.b.d.] | Einsatz von Azure AD Conditional Access
Bei X_ORG_X MUSS Azure AD Conditional Access (oder eine Alternativlösung) verwendet werden, um: - Nicht-konforme Geräte zu sperren, - riskante Benutzeranmeldungen (in Kombination mit ldentity Protection) zu verhindern und - ältere Authentifizierungsprotokolle zu blockieren. |
| ISA-M365-XXX | [t.b.d.] | Nutzung der Azure Active Directory Identity Protection-Richtlinien
Aktivierter Identitätsschutz, um anomales Anmeldeverhalten erkennen zu können MUSS für den X_ORG_X Tenant aktiviert sein. Hierzu sind die Azure AD Identity Protection-Anmelderisikorichtlinien (bzw. Benutzerrisikorichtlinien) zu aktivieren.
Hintergrund: Um Benutzer, die einem hohen Risiko unterliegen, automatisch identifizieren und blockieren zu können, MUSS Azure AD ldentity Protection zum Einsatz kommen. Darüber hinaus SOLLTEN das „gehashte“ Kennwort synchronisiert werden, um dieses auf offengelegte Anmeldeinformationen prüfen zu können (siehe nachfolgender Punkt). |
| ISA-M365-XXX | [t.b.d.] | Nutzung des Passwort-Kompromittierungs-Checks (basierend auf Passwort-Hash-Synchronisierung)
ldentity Protection bietet die Identifizierung von Benutzer- und Signaturrisiken und ist (beim Synchronisieren von Kennworthashes) auch in der Lage, Anmeldeinformationen zu identifizieren, die in Datenlecks offengelegt wurden. Es sollte von daher sichergestellt sein, dass die Passwort-Hash-Synchronisierung aktiviert ist, um Ausfallsicherheit und die Erkennung von durchgesickerten Anmeldeinformationen zu gewährleisten. |
| ISA-M365-XXX | [t.b.d.] | Verzicht auf ablaufende Passwörter mit einhergehender Stärkung der Passwortqualität durch Anhebung der PW-Richtlinie
Es wird empfohlen, dass Passwörter für Office 365 nicht auf Ablauf gesetzt werden und dafür die Passwort-Richtlinie zeitgemäß eingestellt ist. |
| ISA-M365-XXX | [t.b.d.] | Deaktivierung nicht genutzter Accounts
Accounts die 90 Tage nicht genutzt wurden, sind zu deaktivieren. Entsprechende Accounts sind zu prüfen, wieso ggfs. der Meldeweg (z. B. Entzug der Berechtigungen gemäß IAM-Prozess) nicht funktioniert hat. |
| ISA-M365-XXX | [t.b.d.] | Verwendung von privilegierten Just-In-Time-Zugriff auf exponierte Office 365-Rollen
Mittels Just-in-Time-Access können Unternehmen Benutzern Just-in-Time privilegierten Zugriff auf Azure und Azure AD gewähren und überwachen, was diese Benutzer mit ihrem privilegierten Zugriff tun. Es handelt sich hierbei also um ein Modell, bei dem Benutzer temporäre Berechtigungen zum Ausführen privilegierter Aufgaben erhalten. Dieses Modell verhindert, dass böswillige oder nicht autorisierte Benutzer nach dem Ablauf der Berechtigungen Zugriff erhalten. Der Zugriff wird nur gewährt, wenn Benutzer ihn benötigen. |
| REQ-ID | PRIO | REGELUNG |
| ISA-M365-XXX | [t.b.d.] | Einsatz moderner Authentifizierungsmethoden sowie Blockierung von „Legacy Authentication“
Es sollte sichergestellt sein, dass eine moderne Authentifizierung für SharePoint-Anwendungen erforderlich ist, also das veraltete Authentifizierungsmethoden (Legacy Authentication) blockiert werden. Hinweis: Die Unterstützung für alte Authentifizierungsverfahren wie SMTP/IMAP/POP wird von Microsoft in allen M365 Tenants sukzessive blockiert Diese Methoden sind anfälliger für Passwort-Angriffe, da sie keine MFA-Schicht implementiert haben. Es wird von daher dringend empfohlen, alle Legacy-Authentifizierungsmethoden zu verbieten. Legacy-Authentifizierungsmethoden können blockiert werden, indem Sicherheitsvorgaben (wie MFA) aktiviert oder Richtlinien für „Conditional Access“ erstellt werden. |
| ISA-M365-XXX | [t.b.d.] | Upload/Download von malware-behaftete Dateien muss unterbunden sein
Das Hoch bzw. Herunterladen von Dateien, die als mit „Schadsoftware-behaftet“ markiert wurden, MUSS unterbunden sein. Insbesondere MUSS die folgende Mandanteneinstellung auf ‚True‘ festgelegt sein: - Set-SPOTenant -DisallowinfectedFileDownload true |
| ISA-M365-XXX | [t.b.d.] | Aktivierung und Verwendung von Datenklassifizierungsrichtlinien
Um Daten kategorisieren und Verstößen nachgehen zu können, sollten Daten klassifiziert werden. Um dies zu erreichen, SOLLTEN Datenklassifizierungsrichtlinien in SharePoint Online aktiviert werden, die die Kennzeichnung sensibler Daten mit Hilfe sogenannter Vertraulichkeitskennzeichnungen ermöglichen. Hinweis: Alle Inhalte, die nicht gekennzeichnet sind, werden bei X_ORG_X standardmäßig als "Internal" klassifiziert. |
| ISA-M365-XXX | [t.b.d.] | Aktivierung und Verwendung der Advanced Threat Protection (ATP) „Safe Attachments”
ATP Safe Attachments MUSS in SharePoint Online aktiviert sein, um den Malwareschutz zu erweitern, indem Dateien ohne bekannte Malwaresignaturen an eine Hypervisorumgebung weitergeleitet werden, in der eine Verhaltensanalyse der Datei durchgeführt werden kann. |
| ISA-M365-XXX | [t.b.d.] | Steuerung der gemeinsamen Nutzung von Dokumenten mittels Zulassungs- oder Sperrlisten
Um eine versehentliche oder absichtliche Offenlegung sensibler Daten zu verhindern, SOLLTE die Freigabe in SharePoint Online zusätzlich durch blockierende Domains kontrolliert werden, z. B. durch geolokalisierungsbasierte Blockierung von Embargoländern, wie z. B. Nordkorea. |
| ISA-M365-XXX | [t.b.d.] | Einschränkung der Freigabe-Möglichkeiten von Dateien, Ordnern und Websites
SharePoint Online ermöglicht Benutzern die Freigabe von Dateien, Ordnern und Websitesammlungen. Es gibt hauptsächlich zwei verschiedene Arten von Sharing-Möglichkeiten, die bei X_ORG_X auf folgende Weise eingeschränkt werden müssen: - Das Teilen mit "Jedermann" DARF NICHT erlaubt sein, da dies den Zugriff für nicht authentifizierte Benutzer ermöglichen würde. - Die Freigabe mit externen/Gastbenutzern ist erlaubt, solange diese bei Microsoft angemeldet, also identifiziert und autorisiert sind. - der Zugriff auf SharePoint Online-Websites für externe Benutzer so konfiguriert werden, dass er nach 100 Tage automatisch abläuft. Darüber hinaus können interne Benutzer Daten für externe Benutzer freigeben, die über die richtigen Berechtigungen verfügen und diese für eine andere externe Partei freigeben können. Um Datenlecks zu verhindern und Daten aus der Kontrolle von X_ORG_X zu nehmen, MUSS SharePoint Online so konfiguriert sein, dass nur externe Benutzer Daten freigeben können, für die sie explizit als Eigentümer angegeben wurden. HINTERGRUND: Die externen Freigabefunktionen von SharePoint Online und OneDrive for Business ermöglichen es Benutzern, Inhalte mit Personen außerhalb des Unternehmens (z.B. Partner, Lieferanten, Clients oder Kunden) zu teilen. Das Prinzip der Freigaben basiert hierbei auf dem folgenden Grundverständnis: - SharePoint enthält Einstellungen für die externe Freigabe sowohl auf Organisationsebene als auch auf Websiteebene. - Um die externe Freigabe auf jeder Website zu ermöglichen, muss diese auf Organisationsebene zugelassen werden. - Anschließend die externe Freigabe für einzelne Websites eingeschränkt werden, beispielsweise anhand eines Sensitivity Labels für die Website. Für X_ORG_X MÜSSEN im Kontext der externen Freigabe auch die nachfolgenden Punkte geregelt sein: Ablauf Gastzugriff-Berechtigung: Nach Ablauf der zu definierenden Anzahl von Tagen muss der Zugriff verlängert werden, dazu erhalten sowohl der Administrator als auch der Gast entsprechende Erinnerungen. Eine permanente Freigabe ist nicht zugelassen. Re-Authentifizierung bei Verwendung Verifizierungscode: Wenn Personen, die einen Verifizierungscode verwenden, im Browser die Option „Angemeldet bleiben“ ausgewählt haben, müssen sie nach einer zu definierenden Anzahl von Tagen nachweisen, dass sie immer noch auf das Konto zugreifen können, welches sie zum Einlösen der Einladung („gemeinsamen Nutzung“) verwendet haben. Konfiguration der Einstellungen, die einem Benutzer beim Abrufen eines Links, standardmäßig angezeigt werden: Standardmäßig ist das Teilen mit Jedem erlaubt („Anyone with the link“), außerdem werden standardmäßig Schreibrechte auf die geteilten Dokumente vergeben, was bei X_ORG_X auf „Bestimmte Personen“ geändert werden SOLLTE, da diese Option am restriktivsten ist und so eine ungewollte breite interne Freigabe verhindert werden kann. Wenn die externe Freigabe zulassen ist, dann könnten Benutzer mit dieser Option Informationen für bestimmte Personen außerhalb der Organisation freigeben. Darüber hinaus sollten die Berechtigungen die mit dem Link erteilt werden, auf „Ansicht“ umgestellt werden, um unbeabsichtigtes Bearbeiten von Dokumenten zu verhindern. |
| ISA-M365-XXX | [t.b.d.] | Sicherung der Inhalte für die Wiederherstellung von Daten des SharePoint Online
Um wichtige Daten, die nach einem Vorfall oder Ausfall des Rechenzentrums in SharePoint Online gespeichert sind, wiederherstellen zu können, SOLLTEN „Microsoft Renetion Policies“ so konfiguriert sein, dass zumindest die kritischsten Daten über Aufbewahrungsrichtlinien von Microsoft gesichert werden. Hierfür müssen entsprechende Aufbewahrungsrichtlinien definiert werden. |
| REQ-ID | PRIO | REGELUNG |
| ISA-M365-XXX | [t.b.d.] | Die Freigabe-Möglichkeit von Kalenderdetails an externe Benutzer muss unterbunden sein.
Kalenderdetails DÜRFEN NICHT mit externen Benutzern geteilt werden. Die öffentliche Freigabe von Details mit externen Benutzern kann von einem Angreifer missbraucht werden, um organisatorische Beziehungen zu verstehen und festzustellen, wann Benutzer anfälliger für einen Angriff sind, z. B. während der Abwesenheit oder während der Reisezeiten. |
| ISA-M365-XXX | [t.b.d.] | Aktivierung der E-Mail Verschlüsselung
E-Mail-Verschlüsselungsregeln MÜSSEN bei X_ORG_X hinzugefügt werden, um eine Nachricht mit einem bestimmten Schlüsselwort, z. B. „VERTRAULICH“ in der Betreffzeile oder im Text zu verschlüsseln. Die Verschlüsselung von E-Mail-Nachrichten stellt sicher, dass nur die vorgesehenen Empfänger den Inhalt der Nachricht sehen können. |
| ISA-M365-XXX | [t.b.d.] | Verzicht auf Postfach-Delegation
Die Delegierung von Postfächern bedeutet, dass einer anderen Person die Verwaltung der eigenen Emails und des Kalenders ermöglicht wird, was die Verbreitung eines Angriffs beschleunigen kann. Wenn Benutzer ihre Postfächer nicht delegieren können, ist es für einen Angreifer schwieriger, von einem Konto zum anderen zu wechseln und Daten zu stehlen. Daher SOLLTE die Möglichkeit der Mailbox-Delegation grundsätzlich eingeschränkt werden. |
| ISA-M365-XXX | [t.b.d.] | Deaktivierung des Outlook Web Access (OWA) -Zugriffs auf freigegebene Postfächer
Um zu vermeiden, dass freigegebene Postfächer von einem Angreifer missbraucht werden, indem mögliche an den Mandanten angefügte Dienstkonten verwendet werden, SOLLTE Outlook Web Access (OWA) für diese Postfächer deaktiviert werden. |
| ISA-M365-XXX | [t.b.d.] | Filter für „gängige angehängte Typen“ aktivieren
Bei X_ORG_X sollte sichergestellt sein, dass der Filter für allgemeine angefügte Typen für Exchange Online aktiviert ist, um so bekannte bösartige Dateitypen, die ggfs. an E-Mails angehängt werden, blockieren zu können. |
| ISA-M365-XXX | [t.b.d.] | Keine Weiterleitung von E-Mails an externe Adressen
Benutzer DÜRFEN KEINE E-Mails von einer X_ORG_X-eigenen Domäne an eine externe Domäne (z.B. privates E-Mail-Konto) weiterleiten dürfen. |
| ISA-M365-XXX | [t.b.d.] | Deaktivierung der automatischen Weiterleitungsoptionen
Die automatische E-Mail-Weiterleitung SOLLTE in Exchange Online deaktiviert sein, um die Weiterleitung von E-Mails von Outlook an Outlook im Web zu verhindern, da dies von einem Angreifer verwendet werden könnte, um die Kontrolle über einen Endbenutzerkontoschlüssel zu erlangen, der dann zur Entwendung von Daten aus dem X_ORG_X Microsoft 365-Mandanten verwendet werden könnte. |
| ISA-M365-XXX | [t.b.d.] | Sperren von listenspezifischen Domänen in den E-Mail-Transportregeln
Die Maßnahme schützt vor einer „Umgehungen“ durch Angreifer, welche den Kanal für Malware- und Phishing-Scans nutzen könnten, die es einem Angreifer somit ermöglichen könnten, Angriffe auf Benutzer von einer "Safe Haven"-Domäne aus zu starten. Hinweis: Aus dedizierten geschäftlichen Gründen kann es notwendig sein, Listendomänen zuzulassen, dies MUSS aber eine Einzelfallentscheidung mit ordnungsgemäßer Dokumentation und Genehmigung sein und nicht die allgemeine Regel sein. |
| ISA-M365-XXX | [t.b.d.] | Aktivierung der Advanced Threat Protection (ATP) Safe links & Safe Attachements [Microsoft Defender]
ATP Safe Links MÜSSEN in Exchange Online aktiviert sein, um den Phishing-Schutz auf Dokumente, die Hyperlinks enthalten, auszuweiten und zwar unabhängig davon, ob die Dokumente bereits an den Benutzer zugestellt wurden. Diese Funktion wirkt sich auch auf Links aus, die direkt in den E-Mail-Text eingebettet sind, wenn sie entsprechend konfiguriert sind, was der Fall sein SOLLTE. ATP-sichere Anlagen MÜSSEN ebenfalls in Exchange Online aktiviert sein, um den Malwareschutz zu erweitern, indem Anlagen und Nachrichten ohne bekannte Malwaresignaturen an eine Hypervisorumgebung weitergeleitet werden, in der eine Verhaltensanalyse der Datei durchgeführt wird. Hinweis: Um Verzögerungen beim Schutz der Empfänger vor bösartigen Dateien zu vermeiden, MUSS die „Dynamic Delivery-Funktion“ verwendet werden, um Nachrichten sofort zuzustellen zu können, wobei aber Anhänge zunächst durch Platzhalter ersetzt sind, bis das Scannen der Anhänge abgeschlossen ist. |
| ISA-M365-XXX | [t.b.d.] | Deaktivierung der Standardauthentifizierung für Exchange Online
Um das Risiko einer Kompromittierung von Anmeldeinformationen durch schwache Anmeldeinformationen zu verringern, darf die Standardauthentifizierung NICHT verwendet werden und muss deaktiviert werden. Generell sollte moderne Authentifizierung zum Einsatz kommen und „Legacy Authentifizierung“ verhindert werden, z. B. durch MFA oder „Conditional Access“. |
| ISA-M365-XXX | [t.b.d.] | Aktivierung der Anti-Phishing-Richtlinie
Standardmäßig enthält Office 365 integrierte Funktionen, die Benutzer vor Phishing-Angriffen schützen, z. B. Identitätswechsel und Spoofing. Um den Angriffsvektor solcher Angriffe zu reduzieren, MÜSSEN Anti-Phishing-Richtlinien für M365 Exchange Online-Workloads für alle Benutzer und Benutzergruppen aktiviert werden. ANMERKUNG: Die Konfiguration erfolgt im M365 Security Center. Darüber hinaus muss überwacht werde, ob von einem X_ORG_X Account Spam Nachrichten verschickt werden, siehe nachfolgende Anforderung. |
| ISA-M365-XXX | [t.b.d.] | Aktivierung der Online-Benachrichtigungen für ausgehende Spam-Emails
Wenn Exchange Online-Benachrichtigungen für ausgehende Spam-Emails aktiviert ist, können Administratoren erkennen, wann ein Benutzer wegen des Versands von übermäßigen oder Spam-Emails blockiert wurde. Durch die Benachrichtigungen werden Administratoren zusätzlich benachrichtigt und erhalten eine Kopie der Email, die die Blockierung verursacht hat. Ein gesperrtes Konto ist ggfs. ein guter Hinweis darauf, dass das betreffende Konto missbraucht wurde und ein Angreifer es zum Versenden von Spam-Emails verwendet. Die nachfolgende Anforderung ergänzt diesen Ansatz. |
| ISA-M365-XXX | [t.b.d.] | Aktivierung der Malware-Benachrichtigung (bezogen auf Versand durch interne Benutzer)
Diese Anti-Malware-Einstellung MUSS aktiviert werden, um die Transparenz potenzieller Kompromittierungen von Benutzer- oder Dienstkonten zu gewährleisten. Die Richtlinie MUSS so konfiguriert sein, dass Administratoren im Falle des Versandes von Malware benachrichtigt werden, um so weitere Untersuchungen auf der Grundlage definierter Betriebsverfahren durchführen zu können. |
| ISA-M365-XXX | [t.b.d.] | Veröffentlichung von SPF-Einträge für alle (produktiven) Exchange-Domänen
Damit entfernte Mailserver überprüfen können, ob Nachrichten gefälscht wurden oder nicht, MUSS der X_ORG_X SPF-Eintrag aktiviert und den DNS-Einträgen von X_ORG_X SE hinzugefügt werden. |
| ISA-M365-XXX | [t.b.d.] | Aktivierung DKIM für alle (produktiven) Exchange Online-Domänen
Um sicherzustellen, dass durch das Signieren von Nachrichten nur autorisierte Nachrichten aus der X_ORG_X SE-Organisation gesendet werden, MUSS DKIM in Exchange Online aktiviert sein, um so potenzielle Spoofing-Angriffe erkennen und vermeiden zu können. Hinweis: Damit DKIM funktioniert, MÜSSEN die notwendigen Ergänzungen zu den DNS-Einträgen der X_ORG_X SE vorgenommen werden. |
| ISA-M365-XXX | [t.b.d.] | Veröffentlichung der DMARC-Datensätze für alle (produktiven) Domains
Domain-based Message Authentication Reporting and Conformance (DMARC) MUSS mindestens für alle Domänen aktiviert sein, die im produktiven X_ORG_X SE-Mandanten verwendet werden, um E-Mail-Absender zu authentifizieren und somit sichertellen, dass Ziel-E-Mail-Systeme den Nachrichten vertrauen, die von der Domäne gesendet werden. |
| ISA-M365-XXX | [t.b.d.] | Deaktivierung der Exchange Online PowerShell
Der PowerShell-Zugriff MUSS für Endbenutzer deaktiviert werden. Das Prinzip der geringsten Rechte MUSS hierbei befolgt werden. |
| ISA-M365-XXX | [t.b.d.] | Nutzung externer Speicheranbieter in Outlook bzw. generell WebShare reglementieren
Die Integration externer Speicheranbieter (z.B. Box, Dropbox, Facebook usw.) in Outlook im Web kann zur Offenlegung oder zum Verlust sensibler Daten führen und muss von daher bei X_ORG_X reglementiert werden. Um die Angriffsfläche zu reduzieren und die Möglichkeiten für Datenlecks einzugrenzen, SOLLTEN diese Integrationen bestenfalls vollständig deaktiviert werden. |
| ISA-M365-XXX | [t.b.d.] | Aktivierung der „E-Mail-Infos“ (Warnungen / Mail-Tips) für Endbenutzer
Endbenutzer-Benachrichtigungen (per Warnbanner) sollten genutzt werden, z. B. dann wenn E-Mails an große Gruppen von Empfängern oder E-Mails außerhalb des X_ORG_X-Mandanten gesendet werden. Insbesondere sollten die folgenden Werte aktiviert sein: Mail / TipsAIl / TipsEnabled: True Mail/TippsExternal RecipientsTipsEnabled: True Mail/TipsGroupMetricsEnab/ed: True Mail/TipsLargeAudienceThreshold: 20 |
| ISA-M365-XXX | [t.b.d.] | Es muss sichergestellt sein, dass die LinkedIn-Kontaktsynchronisierung deaktiviert ist. |
| REQ-ID | PRIO | REGELUNG |
| ISA-M365-XXX | [t.b.d.] | Kontrolle der gemeinsamen Nutzung von Dokumenten mittels Domänen-Whitelisting
Um eine versehentliche oder absichtliche Offenlegung sensibler Daten zu verhindern, SOLLTE die Freigabe in OneDrive mindestens durch blockierende Domains kontrolliert werden. Es wird dringend empfohlen die gemeinsame Nutzung nur mittels Domain-Whitelisting zu gestatten. |
| ISA-M365-XXX | [t.b.d.] | OneDrive for Business-Synchronisierung für nicht von X_ORG_X verwalteten Geräten blockieren
Die Synchronisierung von Daten in OneDrive for Business zu und von nicht von X_ORG_X verwalteten Geräten MUSS blockiert werden, da es über diese Funktion sonst zum Datenabfluss kommen kann. |
| ISA-M365-XXX | [t.b.d.] | Nutzung der Funktion „Sichere Anlagen“ im Kontext Advanced Threat Protection (ATP)
ATP Safe Attachments MÜSSEN auf OneDrive for Business aktiviert sein, um den Malwareschutz zu erweitern, indem Dateien ohne bekannte Malwaresignaturen an eine Hypervisorumgebung weitergeleitet werden, in der zunächst eine Verhaltensanalyse der Datei durchgeführt wird. |
| ISA-M365-XXX | [t.b.d.] | Einschränkung der Freigabe-Möglichkeit von OneDrive-Dateien
OneDrive ermöglicht Benutzern das Freigeben von Dateien und Ordnern. Es gibt hauptsächlich zwei verschiedene Arten von Sharing-Möglichkeiten, die auf folgende Weise eingeschränkt werden müssen: - Die Freigabe mit "Jedermann" darf NICHT erlaubt sein, da dies den Zugriff für nicht authentifizierte Benutzer ermöglichen würde. - Teilen mit bestimmten Personen (externe/Gastbenutzer). ist erlaubt, solange sie mit ihrem MS Konto bei Microsoft angemeldet sind |
| REQ-ID | PRIO | REGELUNG |
| ISA-M365-XXX | [t.b.d.] | Deaktivierung externer Cloud-Speicheranbieter
Um die Angriffsfläche zu reduzieren und die Möglichkeiten für Datenlecks einzuschränken, MUSS die Integrationen reglementiert und eingeschränkt werden, so dass nur die von X_ORG_X explizit zugelassenen Speicheranbieter verwendbar sind. |
| ISA-M365-XXX | [t.b.d.] | Reglementierung externer Zugriff
Generell sollten es X_ORG_X-Nutzern nicht erlaubt sein, mit Skype- oder Teams-Nutzern außerhalb Ihres Unternehmens zu kommunizieren. Da es legitime Szenarien für ein Öffnung gibt, z. B. Kommunikation mit All41, sollten Ausnahmen, die aber explizit genehmigt werden müssen, möglich sein. |
| ISA-M365-XXX | [t.b.d.] | Reglementierung GAST-Zugriff
Standardmäßig ist der Gastzugang in Teams eingeschaltet. Teambesitzer könnten also externe Benutzer einladen. Diese Einstellung muss bei X_ORG_X über das Teams Admin Center (siehe „Organisationsweiten Einstellungen“) wie folgt werden: Es MUSS einen generellen Anfrageprozess für das Hinzufügen von Gastbenutzern zum Azure AD geben, somit kann sichergestellt werden, dass z.B. nur bereits bestehende Gäste hinzugefügt werden können und bestimmte Bedingungen (wie Business Email-Adresse, NDA, Terms of Use etc.) eingehalten werden müssen. Der Gastzugang darf aus Sicherheits- und Compliance-Gründen immer nur zeitlich begrenzt, also auf einen bestimmten Zeitraum beschränkt, vergeben werden. |
| ISA-M365-XXX | [t.b.d.] | Zentrale Verwaltung von MS Teams sowie M365-Gruppen (inkl. Dokumentierter Genehmigungsworkflow)
Grundsätzlich hat in der Standardeinstellung jeder Benutzer eines Exchange Online Postfachs das Recht eine M365-Gruppe und damit auch ein MS Teams anzulegen. Das Recht zur Erstellung von Groups/Teams MUSS bei X_ORG_X eingeschränkt werden. Hierzu kann eine AAD Security Group oder eine M365 Gruppe ausgewählt werden, deren Mitglieder die Berechtigung haben, M365 Gruppen/Teams anzulegen. Alle anderen Mitglieder haben keine Möglichkeit ein Team anzulegen. |
| ISA-M365-XXX | [t.b.d.] | Gültigkeitsdauer von M365 Gruppen einschränken sowie Deaktivierung nicht genutzter Teams Die weitere Notwendigkeit von Teams muss mindestens jährlich hinterfragt werden, um einen Wildwuchs zu vermeiden. Nicht genutzte Teams sind zunächst zu deaktivieren und dann - nach einer zu definierenden Zeitspanne - zu löschen. |
| ISA-M365-XXX | [t.b.d.] | Genehmigungs-Workflow für Teams-Apps
Microsoft Teams kann erweitert werden, indem Apps in der Teams-Anwendung selbst installiert werden, was normalerweise von Benutzern ohne Administratorrechte durchgeführt werden könnte. Die Möglichkeit ist bei X_ORG_X zu unterbinden, da 3rd-Party-Apps X_ORG_X-Daten an externe Parteien weitergeben könnten und in den meisten Fällen die Datenschutzerklärungen der Apps vollständig von den Servicebedingungen von Microsoft getrennt sind. Daher MUSS, um rechtliche Probleme und Sicherheitsprobleme zu vermeiden. die Installation von 3-Parteien-Apps auf diejenigen beschränkt sein, die im Microsoft Marketplace bereitgestellt und von X_ORG_X SE genehmigt wurden. Hinweis: Es wird empfohlen, Anwendungen, die Benutzer hinzufügen können, auf eine „Whitelist“ zu setzen und einen formellen Antragsprozess („Genehmigungsworkflow“) für zusätzliche Anwendungen zu erstellen. |
| ISA-M365-XXX | [t.b.d.] | Reglementierung des Einsatzes von „Bots & MS Bots Framework“
Microsoft Teams kann mit „Bots“ erweitert werden, wobei es sich im Wesentlichen um Webdienste handelt, die auf Ereignisse und Benutzereingaben reagieren und dann eine entsprechende Antwort generieren. Bots können auch im Namen des aufrufenden Benutzers auf andere Dienste oder Daten zugreifen, um so z. B. Aufgaben zu automatisieren. Der Einsatz von Bots muss einem Release-to-Production (RTP) Workflow unterliegen, wie z. B. neue Software auch. Für die Entwicklung muss immer das offizielle Bot Framework SDK von Microsoft verwendet werden. Darüber hinaus MÜSSEN Bots in Übereinstimmung mit der offiziellen Azure-Sicherheitsbasislinie für Azure Bot Service entwickelt werden. |
| ISA-M365-XXX | [t.b.d.] | Veröffentlichung einer klaren Richtlinie zu Besprechungsaufzeichnungen
Besprechungsaufzeichnungen dürfen nur nach ausdrücklicher Zustimmung aller Beteiligten oder vorherigen Ankündigung aktiviert werden. |
| ISA-M365-XXX | [t.b.d.] | Einrichten von Richtlinien für den erweiterten Bedrohungsschutz für Teams
Mit Office 365 Advanced Threat Protection können Richtlinien für sichere Links und sichere Anhänge in vielen Office-Umgebungen, einschließlich Teams, konfiguriert werden. Eine Richtlinie für sichere Links ermöglicht einen Echtzeit-Klickschutz für alle Links, die über Teams-Chats geteilt werden. Dadurch wird die URL in einer Sandbox-Umgebung geöffnet und auf bösartige Inhalte gescannt. Sollte ein bösartiger Inhalt entdeckt werden, wird der Benutzer am Weiterklicken gehindert. Sichere Anhänge scannen Dateien, die in Teams freigegeben werden sowie Dateien in der mit Teams bereitgestellten Dokumentenbibliothek. |
| ISA-M365-XXX | [t.b.d.] | Definition einer mit X_ORG_X Business abgestimmten Richtlinien zur Vermeidung von Datenverlusten
Mithilfe von Richtlinien zur Vermeidung von Datenverlusten wird die Weitergabe sensibler Informationen in Teams-Chats verhindert. Die Richtlinien enthalten vordefinierte Vorlagen, die erkennen können, ob bestimmte Informationen wie personenbezogene Daten, Kreditkartennummern, Sozialversicherungsnummern usw. geteilt werden. Die Richtlinien sind konfigurierbar und müssen von IT-ORG an die Bedürfnisse des X_ORG_X Business angepasst werden. Benutzer können somit entweder darin gehindert werden, die Informationen zu teilen oder es können z. B. Ausnahmen nach Angabe einer Begründung erlaubt werden. |
| REQ-ID | PRIO | REGELUNG |
| ISA-M365-XXX | [t.b.d.] | Definition einer MPP Governance-Ebene
Die Verwaltung und Governance der Power Platform muss einem dokumentierten Berechtigungskonzept unterliegen. Hierbei sind mindestens die folgenden Stakeholder zu definieren: - MPP Low-Code Strategy Team: Entscheidungsträger in Bezug auf die MPP Strategie. - MPP-Administratorteam: Administratoren, die z. B. DLP-Richtlinien definieren, Benutzer verwalten, die Umgebung überwachen usw. - MPP-Nurture-Team: Experten, die als Mentoren und Helfer für App-Hersteller fungieren. Von diesen Teams MUSS das Admin-Team definiert sein und Administratoren MÜSSEN diesem Team zugewiesen werden. - MPP User: Benutzern wird mithilfe von Sicherheitsrollen Zugriff auf Daten in Power Platform gewährt. Ähnlich wie bei privilegierten Benutzern SOLLTEN Sicherheitsrollen nach Möglichkeit nach dem Prinzip der geringsten Rechte zugewiesen werden. Für den Fall, dass vordefinierte Sicherheitsrollen nicht genügend Granularität bieten, können benutzerdefinierte Rollen erstellt werden. Hinweis: Für jeden Mandanten, für den die Power Platform aktiviert ist, SOLLTEN mindestens zwei Mitglieder der Rolle "Microsoft Power Platform-Administrator" zugewiesen sein. Die Verwaltung und Authentifizierung dieser Rollen MUSS der X_ORG_X Referenzarchitektur „Privileged Access Management“ folgen. |
| ISA-M365-XXX | [t.b.d.] | Reglementierung der Erstellung von MPP-Umgebungen
MPP Umgebungen fungieren grundsätzlich als Sicherheitscontainer und sind voneinander isoliert zu betreiben. Die Umgebung selbst enthält dann die eigentlichen Apps und Flows, welche mittels MPP bereitgestellt werden. Standardmäßig kann jeder Benutzer, der ordnungsgemäß für Power Platform lizenziert ist, zusätzliche Umgebungen erstellen. Da dies für X_ORG_X nicht gewünscht ist, MUSS die Gruppe der Benutzer, die neue Umgebungen erstellen können, auf die entsprechenden Power Platform-Administratoren beschränkt sein. |
| ISA-M365-XXX | [t.b.d.] | Verwendung genehmigte Regionen für die Power Platform-Umgebungen
MPP-Umgebungen sind immer einer bestimmten Rechenzentrumsregion zugeordnet, was letztendlich auch den Speicherort der X_ORG_X Daten beeinflusst. Da der Speicherort der Daten verschiedenen Vorschriften und Gesetzen unterliegt, DÜRFEN grundsätzlich nur diejenigen Regionen verwendet werden, die explizit für die Datenspeicherung bei der X_ORG_X SE zugelassen sind. Ferner muss bei jeder Neu-Anlage einer Umgebung verifiziert werden, ob der Datenspeicher-Ort konform zu den rechtlichen Vorgaben ist. Die Entscheidung muss dokumentiert werden. |
| ISA-M365-XXX | [t.b.d.] | Definition von Richtlinien zur Verhinderung von Datenverlust über MPP
DLP-Richtlinien müssen auch für MPP aktiv sein., um über MPP einen ungehinderten Datenabfluss zu verhindern Hierfür MÜSSEN Administratoren allgemeine DLP-Richtlinien auf Mandantenebene in MPP definieren. |
| ISA-M365-XXX | [t.b.d.] | Ermöglichung von „mandantenübergreifender Isolation“
Connectors in Power Apps and Flows können eine Verbindung mit Apps und Flows herstellen, die sich in Hoheit anderen Mandanten befinden, welche also möglicherweise nicht unter der Kontrolle von X_ORG_X SE stehen. Ausgehende Verbindungen zu anderen Mandanten SOLLTEN von daher immer mit Hilfe von Azure AD-Mandanten-einschränkungen deaktiviert sein und nur bei Bedarf geöffnet werden (siehe Microsoft-Dokumentation zu Mandanteneinschränkungen). ANMERKUNG: Es wird empfohlen, die zur Verfügung stehenden Konnektoren zu klassifizieren und die Nutzung bestimmter Konnektoren innerhalb der Power Platform einzuschränken. Hierzu können auch Zuordnungen von Konnektoren, API‘s oder Datenbanken zu Power Platform Environments vorgenommen und die Berechtigungen auf die Environments reglementiert werden. lnbound-Verbindungen von anderen Mandanten (also in Richtung des X_ORG_X SE-Mandanten) MÜSSEN ebenfalls deaktiviert sein. Dies muss mittels „Mandantenisolation“ von den MPP Administratoren sichergestellt werden. |
| ISA-M365-XXX | [t.b.d.] | |
| ISA-M365-XXX | [t.b.d.] | Aktivierung der Überwachungsprotokollierung
Um Audit-Protokolle sammeln und die Nutzung von Power Plattform überwachen zu können, MUSS die Überwachungsprotokollsuche von den Mandantenadministratoren aktiviert werden. Audit-Protokolle SOLLTEN für mindestens 180 Tage gespeichert werden. |
| ISA-M365-XXX | [t.b.d.] | Überwachung sicherheitsrelevanter Aktivitäten auf der MPP
Nach der Aktivierung der Audit-Log-Suche SOLLTEN alle Aktivitäten genau überwacht werden, da diese sicherheitsrelevant sein könnten und für die frühzeitige Erkennung von Kompromittierungen oder allgemein von Verstößen gegen Unternehmenssicherheitsrichtlinien nützlich sein können. Der Mindestsatz der bei X_ORG_X zu überwachenden Aktivitäten umfasst: - Erstellung einer neuen App - Erstellung neuer Flow - Bearbeiten von Berechtigungen - Löschen von Berechtigungen - Veröffentlichung einer App - Bearbeiten von App-Berechtigungen - Löschen von App-Berechtigungen |
| ISA-M365-XXX | [t.b.d.] | Überwachen und Reagieren auf die Freigabe von Power Apps
Power Apps können mit anderen Benutzern, Gruppen oder dem gesamten Mandanten geteilt werden, was wiederum den jeweiligen Benutzern Zugriff auf die App gewährt. Die Freigabe einer App ermöglicht zumindest die Ausführung der App durch Benutzer, für die die App freigegeben wurde. Von anderen Benutzern, denen beim Teilen die Rolle "Co-Owner" zugewiesen wird, können sie die App auch bearbeiten und erneut freigeben. In einigen Fällen kann dies sicherheitsgefährdend sein, da eine App wiederum den Zugriff auf sensible Daten ermöglicht oder Funktionen implementiert, die nur für eine bestimmte Zielgruppe bestimmt sind. Daher MUSS die Freigabe von Apps regelmäßig überwacht und überprüft werden, z. B. über die Audit Log Search oder das Power BI Dashboard. Das Teilen einer App DARF NICHT für das gesamte Unternehmen/den gesamten Mandanten (spezielle Gruppe "Jeder") erfolgen, sondern immer mit einem eingeschränkten Satz von Zielbenutzern. Die Zuweisung der Rolle "Co-Owner" an andere Benutzer SOLLTE immer auf die unbedingt erforderliche Gruppe von Zielbenutzern beschränkt sein und DARF NICHT für Gastbenutzer verwendet werden. |
| ISA-M365-XXX | [t.b.d.] | Implementieren eines mehrstufigen Sicherheitsansatzes in Power Apps
Für die eigentlichen Power Apps selbst MUSS ein mehrstufiger Ansatz implementiert werden, um den Zugriff auf die App selbst und ihre Komponenten einzuschränken. Zu diesen Ebenen gehören normalerweise: • App-Ebene: Steuert den Zugriff auf die gesamte App an sich • Formularebene: Steuert den Zugriff auf einzelne Formulare innerhalb der App (z. B. können einige Benutzer ein Formular sehen und ausfüllen, andere jedoch nicht) • Datensatzebene: Steuert den Zugriff auf einzelne Datensätze und die Art des Zugriffs auf den Datensatz (Erstellen, Lesen, Aktualisieren und Löschen) • Feldebene: Steuert den Zugriff auf einzelne Felder innerhalb eines einzelnen Datensatzes (hat in der Regel die gleichen Arten der Zugriffskontrolle wie die Datensatzebene) Hinweis: Im Allgemeinen MUSS eine Zugriffssteuerung auf App-Ebene implementiert werden. Die Nichtumsetzung der anderen Ebenen SOLLTE einschließlich einer Begründung dokumentiert werden. |
| ISA-M365-XXX | [t.b.d.] | Einschränkung der Installation des OnPremises Data Gateway
Das lokale Daten-Gateway fungiert als Brücke, die eine schnelle und sichere Datenübertragung zwischen lokalen Daten und den Diensten Power BI, Power Automate, Logic Apps und Power Apps ermöglicht. Standardmäßig können Benutzer Daten-Gateways installieren, das hat zur Folge, dass potentielle Sicherheitslücken entstehen können. Daher SOLLTE die Option „Gateway-Installationsberechtigte verwalten“ im Power Platform Admin Center aktiviert werden, um festzulegen, wer das lokale Datengateway im Unternehmen installieren kann. Derzeit werden Gruppen für die Verwaltung von installationsberechtigten Personen nicht unterstützt, es können nur einzelne Benutzer hinzugefügt werden. |
| REQ-ID | PRIO | REGELUNG |
| ISA-M365-XXX | [t.b.d.] | Aktivierung von DLP-Richtlinien (inkl. Datenklassifizierungsrichtlinien)
DLP-Richtlinien sind für alle Workloads im Mandanten (z. B. Exchange Online-Postfächer, SharePoint Online, OneDrive, Teams etc.) zu erzwingen, um so sensible Daten zu erkennen und deren ungewollten Abfluss verhindern zu können. Hinweis: Alle Daten, die nicht gekennzeichnet sind, werden jedoch standardmäßig als "Intern" klassifiziert. |
| ISA-M365-XXX | [t.b.d.] | Nutzung von Microsoft Information Protection (MIP) und Labeling
Details, auf Anfrage Hinweis: Microsoft Information Protection (MIP) und Labeling sind zentrale MS365 Funktionen, da die meisten MIP-Features nur eingesetzt werden können, wenn die entsprechenden Labels konfiguriert sind. Daher müssen auch die Vorschläge für - Sensitivity Labels und - Retention Labels bei der X_ORG_X Planung und MS-365-Einführung Berücksichtigung finden (siehe Abschnitt MIP). |
| ISA-M365-XXX | [t.b.d.] | Definition eines Datensicherungsprozesses für Cloud-Dienste
X_ORG_X ist für die Erstellung vollständiger Backups selbst verantwortlich. Daher MUSS ein geeigneter Datensicherungsprozess für Cloud-Dienste eingerichtet werden. |
| ISA-M365-XXX | [t.b.d.] | Nutzung der Microsoft Graph-API als Standardzugriff auf Microsoft-Ressourcen
Der Standardzugriff auf Microsoft-Ressourcen SOLLTE über die Microsoft Graph-API gewährt werden. Im besten Fall werden hierfür Delegate-Berechtigungen verwendet. |
| ISA-M365-XXX | [t.b.d.] | Trennung der Dev-, Test und produktiven Microsoft-Mandanten
Die verschiedenen Staging-Umgebung des M365-Mandaten müssen komplett autark und voneinander separiert laufen. |
| ISA-M365-XXX | [t.b.d.] | Aktivierung der Kunden-Lockbox-Funktion
Die Funktion stellt sicher, dass Microsoft nicht unbemerkt auf Daten des X_ORG_X Tenants zugreifen kann, um z. B. einen Dienstvorgang ohne ausdrückliche Genehmigung zu starten. |
| REQ-ID | PRIO | REGELUNG |
| ISA-M365-XXX | [t.b.d.] | Nutzung von Labeling („Sensitivity Labels" und „Rentention Labels“)
Labeling ist eine technisch-organisatorische Maßnahme im Sinne des Datenschutzes, die z. B. zur Absicherung der Verarbeitung von personenbezogenen Daten dienen kann. Es wird empfohlen bereits sehr früh Sensitivity und Rentention Labels bereitzustellen und die X_ORG_X Mitarbeiter in der Anwendung der Labels zu schulen. |
| ISA-M365-XXX | [t.b.d.] | Erstellung X_ORG_X Labeling Konzept
Mittels Labeling können u.a. die nachfolgenden Ziele erreicht werden, welche auch bei X_ORG_X angestrebt werden sollten: - Erzwingen von Schutzeinstellungen wie Verschlüsselung oder Wasserzeichen für definierte („ge-label-te“) Inhalte. - Schützen von Inhalten in Office-Apps auf verschiedenen Plattformen und Geräten. - Verhindern, dass vertrauliche Inhalte der X_ORG_X (auf Geräten unter Windows) verlassen (Microsoft Intune Endpoint Protection). - Schützen von Inhalten in Drittanbieter-Apps und -Diensten (Microsoft Cloud App Security). - Erweitern von Vertraulichkeitsbezeichnungen auf Drittanbieter-Apps und -Dienste. - Klassifizieren von Inhalten ohne Verwendung von Schutzeinstellungen. IT-ORG hat ein Labeling Konzept basierend auf den Anforderungen des X_ORG_X Business zu erstellen. Ein Beispiel für Label Definitionen findet sich im Anhang A. |
| ISA-M365-XXX | [t.b.d.] | Nutzung von Rentention Labels Aufbewahrungsbezeichnungen können dazu verwendet werden, Daten organisationsweit für Governancezwecke zu klassifizieren und Aufbewahrungsregeln basierend auf dieser Klassifizierung durchzusetzen. Es wird empfohlen bereits sehr früh Retention Labels bereitzustellen und die X_ORG_X- Benutzer in der Anwendung der Labels zu schulen. Ein Beispiel für „Rentention Label“ - Definitionen findet sich im Anhang B. |
| REQ-ID | PRIO | REGELUNG |
| ISA-M365-XXX | [t.b.d.] | Aktivierung der M365-Überwachung
Um Benutzer- und Administratoraktivitäten im Überwachungsprotokoll aufzuzeichnen, MUSS die Überwachungsprotokollfunktion aktiviert sein. Das Überwachungsprotokoll kann durchsucht werden, um das Office 365-Team oder das lncident Response-Team bei der Untersuchung von Aktivitäten für den regulären Sicherheitsbetrieb zu unterstützen oder zu forensische Zwecke. Für eine einheitliche Sucherfahrung und die Möglichkeit längerer Aufbewahrungsfristen SOLLTEN die Protokolle auf ein zentrales SIEM übertragen werden. |
| ISA-M365-XXX | [t.b.d.] | Aktivierung der Postfachüberwachung (für alle Benutzer)
Die Postfachüberwachung MUSS für alle Postfächer aktiviert sein, um so Benutzer- und Administratoraktivitäten für die jeweiligen Postfächer, einschließlich der Anmeldungen, aufzuzeichnen. Hinweis: Seit Januar 2019 ist die Postfachüberwachung standardmäßig aktiviert. Wenn die Überwachung standardmäßig aktiviert ist, werden Aktivitäten für Postfächer unabhängig von den Einstellungen der tatsächlichen Postfächer aufgezeichnet. Dies betrifft jedoch nur die folgenden Postfachtypen: - Benutzerpostfächer - Freigegebene Postfächer - Microsoft 365 Group Postfächer Für die folgenden Typen SOLLTE die Überwachung separat auf Postfachebene zusätzlich aktiviert werden: - Ressourcenpostfächer - Postfächer für Öffentliche Ordner - DiscoverySearch-Postfächer |
| ISA-M365-XXX | [t.b.d.] | Überprüfung ders Azure AD-Berichts "Riskante Anmeldungen"
Zur frühzeitigen Erkennung von Fehlern, Fehlkonfigurationen und möglichen Kompromittierungen SOLLTEN die folgenden Berichte und Einstellungen regelmäßig von den jeweiligen Workload-Eigentümern überprüft werden: - Bericht über die Kontobereitstellungsaktivität - Malware Detections Bericht - Bericht "Mailbox-Zugriff durch Nicht-Besitzer" - Bericht zu gefälschten Domänen - Gastbenutzerzugriff im Allgemeinen (wenn nicht zeitlich begrenzt) - Postfachordnerberechtigungen (insbesondere für anonyme und Standardbenutzer) - Benutzer in hochprivilegierten Rollen - Domain-Registrierungsstatus überprüfen - Überprüfen der Richtlinien für den bedingten Zugriff - Überprüfen Sie ruhende Konten - Überprüfen Sie Benutzer, die MFA umgehen können - Überprüfen Sie die automatische Weiterleitung und E-Mail-Weiterleitung an Remote-Domänen Weitere zu prüfende Berichte sind: - Bericht über die Anwendungsnutzung (mindestens wöchentlich) - Aktivitätsbericht zum Zurücksetzen des Self-Service-Passworts - Änderungen an Benutzerrollengruppen sowie generell Überprüfung von Rollenänderungen - Regeln für die E-Mail-Weiterleitung - der Malware-Erkennungsbericht - der Bericht über die Kontobereitstellungsaktivität - nicht-globale Administratorrollengruppenzuweisungen - Bericht über gefälschte Domains - Bericht zur Sicherheit von Microsoft 365 Cloud-Apps - Bericht von Benutzern, deren E-Mail-Berechtigungen aufgrund von Spamming eingeschränkt wurden sowie - Gastbenutzer-Report |
| ISA-M365-XXX | [t.b.d.] | Integritätscheck MS-365 Konfiguration
Die Konfiguration der X_ORG_X MS-365-Konfiguration ist mindestens halbjährlich gegen eine SOLL-Konfiguration abzugleichen, das kann z. B. mittels eines Tools, wie beispielhaft SysKit Trace, durchgeführt werden. |