Empfohlen

Skynet im Büro: Die Risiken einer unkontrollierten Einführung von M365 CoPilot

Die Integration von Microsoft 365 CoPilot in die Unternehmenswelt verspricht, durch den Einsatz fortschrittlicher KI die Effizienz, Kreativität und Entscheidungsfindung zu revolutionieren. Doch ohne eine fundierte Governance und Compliance kann diese technologische Innovation schnell zu einem Kontrollverlust führen, ähnlich dem fiktiven Aufstieg von Skynet, der selbstbewussten KI, die in der „Terminator“-Filmreihe die Menschheit bedroht. Die fortschrittlichen Fähigkeiten von CoPilot, Daten und Informationen zu indizieren und zu analysieren, können unbeabsichtigt zu Datenschutzverletzungen und Sicherheitsrisiken führen, wenn die Governance-Strukturen nicht sorgfältig angepasst werden. Leider wurde das Thema bei vielen M365 Einführungen stiefmütterlich behandelt.


Ein alltägliches Beispiel:

Ein Mitarbeiter ist sich nicht bewusst, dass ein Gehaltsdokument versehentlich in einem öffentlich zugänglichen Teamordner abgelegt wurde. Die Sicherheit dieses Dokuments beruht auf dem fehlenden Wissen des Mitarbeiters über seine technischen Berechtigungen und den Standort des Dokuments. Die KI jedoch, die nur die bestehenden Benutzer-Berechtigungen berücksichtigt, kennt den Standort und könnte somit sensibelste Daten freilegen, ohne die Absicht oder das Wissen des Benutzers.

Vielleicht etwas genauer

Ein Aspekt, der nicht allen Benutzern – einschließlich einiger Administratoren – bewusst ist, betrifft die Zugänglichkeit von Inhalten öffentlicher Teams innerhalb der Office 365-Umgebung. Alle Dokumente, die in den öffentlichen Teamordnern abgelegt sind, können über die Office 365-Suche von jedem Benutzer im Unternehmen gefunden werden, unabhängig davon, ob der Suchende Mitglied des jeweiligen Teams ist oder nicht. Diese Dokumente lassen sich nicht nur über die M365-Suche auffinden, sondern auch in SharePoint öffnen und sind ebenso über die Teams-Suche oder Delve zugänglich.

Diese weitreichende Zugänglichkeit eröffnet in Bezug auf M365 CoPilot eine neue Dimension der Datenverarbeitung. CoPilot kann auf sämtliche Inhalte zugreifen, zu denen der Nutzer Berechtigungen besitzt – und somit auch auf alle Inhalte aller öffentlichen Teams. Im Unterschied zur herkömmlichen Suche, die Nutzer vielleicht manuell durchführen, kann M365 CoPilot diese Informationen nicht nur effizienter verlinken, sondern sie auch in seinen Antworten auf eine Weise nutzen, die weit über die einfache Wiedergabe von Suchergebnissen hinausgeht.

Dies bedeutet, dass M365 CoPilot potenziell Zugriff auf eine breitere Palette von Dokumenten und Informationen hat, als den Nutzern möglicherweise bewusst ist. Während dies die Effizienz und Produktivität durch den Zugang zu einer Fülle von Ressourcen steigern kann, unterstreicht es auch die Notwendigkeit einer sorgfältigen Überwachung und Verwaltung von Berechtigungen und Zugriffsrechten innerhalb von Office 365.

Die Sicherstellung, dass nur relevante und angemessene Inhalte öffentlich zugänglich gemacht werden, wird zu einer kritischen Komponente im Management von Informationen und der Gewährleistung der Datensicherheit in einer zunehmend durch KI unterstützten Arbeitsumgebung.

Ein weiteres konkretes Beispiel: Der alte Produktkatalog

Nehmen wir an, ein Vertriebsmitarbeiter bittet M365 CoPilot, die aktuellen Preise für ein bestimmtes Produkt zu nennen. Unbekannterweise basiert die Antwort des CoPilot auf einem veralteten Produktkatalog, der in einem der vielen Ordner des Cloudnetzwerks gespeichert ist. Dieser Katalog, der längst durch neuere Versionen ersetzt wurde, ist immer noch zugänglich, da die Data Governance nicht nachjustiert wurde, um solche veralteten Dokumente zu identifizieren und ihre Sichtbarkeit einzuschränken.

Das Resultat? Der Vertriebsmitarbeiter erhält Informationen, die auf veralteten Preisen oder gar Produkten basieren. Im schlimmsten Fall führt dies zu Angeboten, die weit unter dem aktuellen Marktpreis liegen oder nicht mehr lieferbar sind, was direkte finanzielle Verluste und Vertrauensverlust bei Kunden nach sich ziehen kann. Dieses Szenario verdeutlicht nicht nur die potenziellen Risiken einer unkontrollierten KI-Nutzung, sondern auch die Notwendigkeit eines dynamischen und proaktiven Ansatzes in der Data Governance und im Rechte- und Rollenmanagement.

Die Bedeutung von Data Governance

Diese Beispiele zeigen deutlich, dass Data Governance und das Management von Zugriffsrechten ein stetiger Prozess sein müssen.

Um die Herausforderungen im Zusammenhang mit der Zugänglichkeit und Verwendung von Daten durch fortschrittliche KI-Systeme wie M365 CoPilot zu bewältigen, sind proaktive Lösungsansätze erforderlich. Diese sollten ein robustes Rechte- und Rollenmanagement, die kontinuierliche Schulung von Mitarbeitern sowie die effektive Klassifizierung von Daten umfassen. Es reicht nicht aus, einmalig Berechtigungen zu vergeben; vielmehr müssen Organisationen proaktiv den Zugriff auf Daten und Informationen steuern und sicherstellen, dass nur autorisierte Benutzer auf sensible Daten zugreifen können.

Lösungsansätze

  • Proaktives Rechte- und Rollenmanagement: Die Vergabe von Zugriffsrechten muss auf einer gründlichen Analyse der Notwendigkeit des Zugriffs basieren. Sensible Informationen sollten besonders geschützt und regelmäßig überprüft werden.
  • Kontinuierliche Schulung der Mitarbeiter: Die Sensibilisierung der Mitarbeiter für den sicheren Umgang mit Daten und die Bedeutung des Datenschutzes ist entscheidend, um unbeabsichtigte Sicherheitsrisiken zu minimieren.
  • Einführung von Sensitivity Labels: Microsoft 365 CoPilot ist darauf ausgelegt, innerhalb der Sicherheits- und Compliance-Frameworks von Microsoft 365 zu arbeiten, einschließlich des Umgangs mit Sensitivity Labels und geschützten Inhalten. Sensitivity Labels sind ein zentraler Bestandteil der Microsoft 365 Compliance-Lösung, die es Organisationen ermöglicht, Daten basierend auf ihrer Sensibilität zu klassifizieren und zu schützen. Diese Labels können verwendet werden, um zu steuern, wer Zugriff auf bestimmte Informationen hat, und um Richtlinien für die Aufbewahrung, Verschlüsselung und andere Schutzmaßnahmen zu definieren.

Sensitivity Labels

Integration mit Sensitivity Labels

CoPilot respektiert die durch Sensitivity Labels definierten Zugriffs- und Schutzrichtlinien. Wenn ein Dokument oder eine E-Mail mit einem Sensitivity Label versehen ist, welches bestimmte Schutzmaßnahmen vorschreibt – wie etwa eine Verschlüsselung oder Zugriffsbeschränkungen, werden diese Schutzmaßnahmen auch von CoPilot eingehalten. Das bedeutet, dass CoPilot Inhalte, welche beispielsweise als „vertraulich“ oder mit höheren Schutzstufen gekennzeichnet sind, nicht für Benutzer zugänglich macht, die nicht die entsprechenden Berechtigungen besitzen.

Verhalten bei geschützten Inhalten

Für geschützte Inhalte, die durch Technologien wie Azure Information Protection (AIP) gesichert sind, gewährleistet CoPilot, dass die Schutzmaßnahmen beibehalten werden. CoPilot kann solche Inhalte im Rahmen der vom Benutzer zugewiesenen Berechtigungen verarbeiten, aber es wird sichergestellt, dass die Datenverarbeitung den Richtlinien entspricht, die durch die Sensitivity Labels festgelegt sind. Beispielsweise würde CoPilot keine Informationen aus einem als „streng vertraulich“ gekennzeichneten Dokument in einer Antwort verwenden, wenn der anfragende Benutzer nicht die erforderlichen Rechte zum Anzeigen dieses Dokuments besitzt.

Auswirkungen auf die Datensicherheit und Compliance

Durch die Einhaltung der durch Sensitivity Labels festgelegten Richtlinien trägt CoPilot dazu bei, die Datensicherheit und Compliance innerhalb von Microsoft 365 zu verstärken. Organisationen können somit die Vorteile von KI-gestützten Produktivitätswerkzeugen nutzen, ohne Kompromisse bei der Sicherheit sensibler Informationen eingehen zu müssen. Dies unterstreicht die Bedeutung der sorgfältigen Implementierung und Verwaltung von Sensitivity Labels und Schutzrichtlinien, um ein hohes Maß an Sicherheit und Compliance in der digitalen Arbeitsumgebung zu gewährleisten.

Fazit

Die Einführung von Technologien wie M365 CoPilot kann erhebliche Vorteile für Unternehmen bringen, stellt jedoch auch neue Anforderungen an das Management von Rechten und Rollen. Durch die sorgfältige Anpassung von Data Governance-Prozessen können Unternehmen die Risiken minimieren und sicherstellen, dass die Technologie zum Wohl aller Beteiligten eingesetzt wird, ohne ungewollt ein Szenario à la Skynet zu riskieren.

Exchange Server 2025: Was Sie bei der Migration zur Subscription Edition beachten müssen

Im Mai 2024 hat Microsoft seine Exchange Server Roadmap vorgestellt und die Pläne für die Zukunft von Exchange Server veröffentlicht. Siehe Neuerungen in der Exchange Server Roadmap: Neueste Updates zur Exchange Server Roadmap: Entdecken Sie CU15 und Exchange Server SE

Mit dem bevorstehenden Release der Exchange Server Subscription Edition (SE) ab 2025 stellt Microsoft wichtige Neuerungen und Anforderungen für Organisationen vor, die ältere Versionen von Exchange Server nutzen. Die Migration zu Exchange SE ist entscheidend, da ältere Versionen wie Exchange 2016 und 2019 nur noch begrenzt unterstützt werden. In diesem Artikel erfahren Sie, wie Sie Ihre Organisation optimal auf das Upgrade vorbereiten.

Die Roadmap

Zur besseren zeitlichen Darstellung, hier ist eine Tabelle, die diese Veröffentlichungen und ihre Auswirkungen auf die Koexistenz mit früheren Versionen zusammenfasst:

NameErscheinungsdatumDetailsKoexistenz
Exchange Server 2019 CU15Zweite Halbjahr 2024Finales CU für Exchange Server 2019. Codeparität mit Exchange Server SE RTM (mit Ausnahme von SUs, die vor Exchange SE RTM veröffentlicht wurden)Keine Koexistenz mit Exchange 2013
(Installation wird durch CU15-Setup blockiert)
Exchange Server SE RTMAnfang zweite Halbjahr 2025Ermöglicht ein direktes Upgrade von Exchange 2019 CU14 oder CU15. Codeparität mit Exchange 2019 CU15 + alle SUs, die seit CU15 veröffentlicht wurden (keine neuen Features oder andere Codeänderungen)Keine Koexistenz mit Exchange 2013
(Installation wird durch RTM-Setup blockiert)
Exchange Server SE CU1Ende zweite Halbjahr 2025Erste Einführung neuer Funktionen in Exchange Server SEKeine Koexistenz mit Exchange 2013, Exchange 2016 oder Exchange 2019 (Installation durch CU1-Setup blockiert)
Übersicht Roadmap

Supportstatus von Exchange Server-Versionen

In der folgenden Tabelle werden die letzten drei Versionen von Exchange, ihre LifeCycle und die Auswirkungen der oben genannten Versionen dargestellt:

Exchange VersionEnd of SupportAb 2019 CU15Ab Exchange SE RTMAb Exchange SE CU1
Exchange 201311.04.2023not supportednot supportednot supported
Exchange 201614.10.2025Extended SupportExtended SupportNot supported
Exchange 2019 CU14.10.2025Extended SupportExtended SupportNot supported
Übersicht Support

Alle anderen Versionen und Builds von Exchange Server werden nicht unterstützt, mit Ausnahme von Exchange 2019 CU13, das mit der Veröffentlichung von Exchange 2019 CU15 nicht mehr unterstützt wird.

Koexistenz verschiedener Versionen in derselben AD Organisation

Microsoft nimmt gravierende Änderungen in Exchange Server vor, die sich auf die Koexistenz mit älteren Versionen in derselben Organisation (Forest) auswirken. In der Vergangenheit war es möglich, eine ältere (und sogar nicht unterstützte) Version von Exchange Server in einer Organisation mit neueren Versionen von Exchange Server weiterhin auszuführen. Wir IT-Consultants sprachen gerne von einer N-2 Versionskoexistenz. Dies bedeutet, in der Vergangenheit wurden die aktuelle und zwei vorherige Versionen innerhalb einer AD Organisation unterstützt.

Dies ändert sich in zweierlei Hinsicht:

  • Das Setup in Exchange Server 2019 CU15 und Exchange Server SE RTM blockiert die Koexistenz mit Exchange Server 2013.
  • Das Setup in Exchange Server SE CU1 blockiert die Koexistenz mit allen nicht unterstützten Versionen (z. B. Exchange Server 2013, Exchange Server 2016, Exchange Server 2019) und lässt die Koexistenz nur mit Exchange Server SE zu.

Wichtig: Wenn Exchange Server SE CU1 veröffentlicht wird, wird der Support für alle anderen Versionen von Exchange Server eingestellt. Wie in der folgenden Tabelle beschrieben, müssen Sie zum Installieren von CU1 (oder höher) zunächst alle älteren Versionen von Exchange Server außer Betrieb nehmen und ordnungsgemäß aus Ihrer Organisation entfernen.

Was Sie nun unternehmen sollten

Um auf Exchange Server SE zu aktualisieren, haben Sie verschiedene Optionen.

Da Exchange 2013 bereits sein „End of Life“ erreich hat, sollten Sie bereits Exchange Server 2016 CU23 oder Exchange Server 2019 CU13/CU14 nutzen. Falls Sie eine frühere Version von Exchange 2016 einsetzen, ist ein sofortiges Update auf CU23 erforderlich. Für Exchange 2019 Kunden wird CU14 empfohlen, jedoch wird auch CU13 noch unterstützt.

Wenn Sie ältere Versionen wie Exchange 2013 oder noch älter betreiben, sollten Sie entweder auf Exchange Online migrieren oder ein Upgrade auf Exchange Server 2019 mit dem neuesten Cumulative Update in Betracht ziehen.

Warum sollten wir unsere Server aktualisieren, wenn es keine neuen Features gibt?

Microsoft wird den Support für Exchange Server 2016 und 2019 am 14. Oktober 2025 einstellen. Um ein direktes und unkompliziertes Upgrade von Exchange Server 2019 zu ermöglichen, wurden neue Funktionen entweder bereits in Exchange Server 2019 CU15 integriert oder für Exchange Server SE CU1 und höher vorbereitet.

Der Wechsel zu Exchange Server SE RTM führt zu einem Update des Brandings sowie neuen Lebenszyklus- und Supportrichtlinien. Nach der Veröffentlichung von Exchange SE CU1 werden ältere Versionen nicht mehr unterstützt, und Microsoft führt ab CU1 neue Funktionen für Exchange Server ein.

Intune schneller als GPOs?

Bisher hatte die Verwaltung von Richtlinien für Windows Geräte über Intune einen entscheidenden Nachteil gegenüber GPOs. Der Refresh Zyklus von 8 Stunden. So werden bisher die MDM-Richtlinien nur alle 8 Stunden aktualisiert. Die GPOs jedoch alle 90 Minuten. Mit dem neuen Feature Config Refresh ist das nun Vergangenheit und der Aktualisierungszeitraum für Intune Richtlinien lässt sich anpassen. Mit diesen Anpassungen ist Intune schneller als GPOs!

Was ist der Config Refresh?

Config Refresh ist eine Funktion, die für Windows 11 ab dem Juni 2024 Security Update verfügbar ist. Es ermöglicht, die Häufigkeit der Aktualisierung von MDM-Richtlinien zu konfigurieren. Dies ist wichtig, um sicherzustellen, dass die Einstellungen nicht von den vorgesehenen Richtlinien abweichen. Aber auch, dass Konfigurationsanpassungen schnell auf den Endgeräten ankommen.

Die Vorteile von Config Refresh

Mit Config Refresh können Administratoren die Aktualisierungszeit der Richtlinien auf ein Intervall zwischen 30 Minuten und 24 Stunden einstellen. Zu den weiteren Schlüsselfunktionen von Config Refresh gehören:

  • Eine Reset-Operation, um die Einstellungen, die über den Policy CSP verwaltet werden, zurückzusetzen
  • Offline-Funktionalität
  • Pausieren von Config Refresh für Troubleshooting

Die Konfiguration des Config refresh und des Aktualisierungsintervall findet sich bereits innerhalb des Settings catalog:

Intune Settings catalog: Einstellung für ein schnelleres Intune
Intune Settings catalog: Einstellung für ein schnelleres Intune

Ein benutzerdefiniertes Profil ermöglicht die Konfiguration der Pause. Der Entsprechende Key lautet:

./Device/Vendor/MSFT/DMClient/Provider/MS%20DM%20Server/ConfigRefresh/PausePeriod

Gültige Werte sind eine Zahl zwischen 0 und 1440 Minuten (24 Stunden).

Wichtiger Hinweis

Der Config Refresh ist für MDM-Richtlinien konzipiert, die durch den Policy CSP verwaltet werden. Einige Richtlinien, insbesondere der BitLocker CSP, werden ebenfalls Config Refresh-Regeln folgen. Andere Richtlinien, wie Firewall, AppLocker, PDE und LAPS, fallen nicht in diesen Bereich!

Fazit

Ein interessantes Feature und weiterer Pluspunkt Policies über Intune, anstatt GPOs zu konfigurieren. Neben dem Vorteil Statusmeldungen zu den Policies zu erhalten und der Tatsache, dass eine Verbindung zum Internet ausreichend ist, um eine Policy-Änderungen auf ein Gerät anzuwenden. Bei den klassischen GPOs ist hierfür immer eine Verbindung zum Domain Controller erforderlich. Nun sind ist Intune auch deutlich schneller als die klassischen GPOs.

Microsoft MFA für alle Benutzer ab Juli 2024?

Eigentlich sollte sie bereits für jeden Microsoft 365 Benutzer aktiv sein, die Multi Faktor Authentifizierung (MFA). Trotzdem hat Microsoft mit der Ankündigung MFA für alle Benutzer anzufordern für Aufregung gesorgt (Microsoft will require MFA for all Azure users). Insbesondere da es Gründe für bestimmte Benutzer bestehen, keine MFA zu forcieren. Hierunter fallen z.B. Service Benutzer oder auch bestimmte Benutzergruppen.

Die Ankündigung wurde mittlerweile präzisiert und es betrifft nur Benutzer, die auf folgende Anwendungen zugreifen:

  • Azure portal
  • Microsoft Entra admin center
  • Azure PowerShell
  • Azure CLI
  • Terraform für die Administration von Azure

Auf die genannten Anwendungen greifen in der Regel nur Benutzer zu, die administrative Vorgänge durchführen. Vom MFA-Zwang ausgenommen werden sollen: Dienstprinzipalobjekte, verwaltete Identitäten, Workload-Identitäten und weitere tokenbasierte Konten. Microsoft sammelt hier auch noch weiteren Input für weitere Szenarien, wie z.B. Break-Glass Administratoren. Diese sind als Best-Practise ohne MFA empfohlen, um im Notfall weiterhin Zugang zum Tenant zu bieten.

Wie setzt Microsoft die Anforderung technisch um?

Dazu gibt es leider noch keine konkrete Aussage. Ich vermute allerdings, dass dies über eine von Microsoft verwaltete Regel des bedingten Zugriffs realisiert wird. In der Technet zu den von Microsoft verwalteten Richtlinien (Secure your resources with Microsoft-managed Conditional Access policies – Microsoft Entra ID | Microsoft Learn), findet sie die folgende Regel, die stark an die Ankündigung von Microsoft erinnert: „Require multifactor authentication for Azure management.“

Welche Aufgaben ergeben sich hieraus?

  • Prüfen der Sign-in Logs auf die oben genannten Anwendungen, um die betroffenen Benutzer, insbesondere Service Benutzer zu identifizieren.
  • Registrieren der MFA für alle Benutzer, die auf die oben genannten Anwendungen zugreifen.
  • Bei allen klassischen Service Benutzern die Möglichkeit prüfen, diese auf tokenbasierte Konten umzustellen.
  • Falls es über eine von Microsoft verwaltete Richtlinie realisiert wird, unbedingt die Break Glass Admins ausschließen.

Fazit

Zusammenfassend handelt es sich um eine sinnvolle Maßnahme um die Sicherheit der Tenants zu erhöhen. Noch immer gibt es viele ungesicherte Konten mit kritischen Zugriffen. Für diese soll nun die MFA aktiviert werden. Auch sind viele Service Accounts im Einsatz, die längst durch tokenbasierte Konten ersetzt werden könnten. Leider ist die ist die Kommunikation recht kurzfristig und vage.

Neuer Missbrauch der DHCP-Administratorengruppe zur Erweiterung der Privilegien in Windows-Domänen

Als IT-Consultant möchte ich Sie, die IT-Administratoren, über eine kritische Sicherheitsbedrohung informieren, die die DHCP-Administratorengruppe in Windows-Domänen betrifft. Dieses Risiko könnte unzureichend abgesicherte DHCP-Server in Machtinstrumente für Angreifer verwandeln, die vollständige Domain-Übernahmen anstreben.

Was Sie wissen müssen: Die DHCP-Administratorengruppe kann in einigen Fällen dazu missbraucht werden, erweiterte Berechtigungen innerhalb einer Windows-Domäne zu erlangen. Dies geschieht durch das Manipulieren von DHCP-Optionen, die eigentlich dazu dienen, Netzwerkkonfigurationen zu verteilen.

Wie genau funktioniert der Angriff?

Der Angriff mittels der DHCP-Administratorengruppe für Privilegienerweiterung in Windows-Domänen erfolgt durch die missbräuchliche Verwendung der DHCP-Konfigurationsmöglichkeiten. Angreifer, die Zugang zur DHCP-Administratorengruppe haben, können spezielle DHCP-Optionen manipulieren. Ein kritischer Punkt dabei ist die Veränderung der DNS-Servereinstellungen über DHCP, was es ermöglicht, DNS-Anfragen umzuleiten. Dies kann zu einer Maschine-im-Mittelpunkt (MITM)-Attacke führen, bei der der Angreifer DNS-Anfragen abfängt oder manipuliert, um weitergehende Angriffe wie Kerberos-Authentifizierungsumleitungen durchzuführen. Solche Angriffe ermöglichen eine Eskalation der Privilegien bis hin zur Übernahme eines Domain Controllers, wenn der DHCP-Server auf diesem installiert ist.

Ein kritischer Aspekt dieses Angriffs auf die DHCP-Administratorengruppe ist, dass er auf legitimen Konfigurationsmöglichkeiten beruht und keine direkten Schwachstellen ausnutzt. Daher existiert keine einfache „Fix“ oder Patch, um diese Angriffsart zu unterbinden.

Präventionsmaßnahmen

In der Welt der Netzwerksicherheit ist die korrekte Platzierung und Verwaltung von Rollen innerhalb einer Active Directory (AD)-Umgebung entscheidend, um Sicherheitsrisiken zu minimieren. Ein häufig übersehener, aber kritischer Aspekt ist die Trennung von Diensten durch das AD Tiering Modell, speziell die Positionierung der DHCP-Rolle in Bezug auf Domain Controller (DC).

Das Risiko einer inkorrekten Rollenverteilung: Wenn der DHCP-Dienst auf einem Domain Controller installiert ist, öffnet dies Tür und Tor für potenzielle Angriffe. Angreifer, die Zugriff auf die DHCP-Administratorengruppe erlangen, können diese Position nutzen, um weitreichende Privilegien innerhalb der Domäne zu eskalieren. Diese Gefahr wird durch die Nutzung von DHCP-Optionen verstärkt, die manipuliert werden können, um bösartige Netzwerkkonfigurationen zu verbreiten oder unerlaubte DNS-Updates zu initiieren.

Die Lösung durch AD Tiering: Ein gut durchdachtes AD Tiering Modell bietet eine effektive Strategie, um solche Risiken zu mindern.

Im idealen Modell:

  • Tier 0 umfasst die Domain Controller und andere kritische Infrastrukturkomponenten, die die höchsten Sicherheitsanforderungen haben.
  • Tier 1 sollte Dienste wie DHCP beherbergen, die zwar wichtig sind, aber eine klare Trennung von den Kernkomponenten des Active Directory benötigen.

Durch die Einhaltung dieses Modells wird verhindert, dass DHCP-Administratoren Zugriff auf die kritischsten Bereiche der IT-Infrastruktur erhalten und somit das Risiko einer Privilegienerweiterung drastisch reduziert.

Schritte zur Implementierung und Überwachung:

  1. Überprüfung der aktuellen Infrastruktur: Identifizieren Sie alle Instanzen, in denen DHCP-Dienste auf Domain Controllern laufen, und planen Sie deren Migration.
  2. Einrichtung von Zugriffsbeschränkungen: Stellen Sie sicher, dass nur autorisierte Benutzer Zugriff auf kritische Systeme im Tier 0 haben.
  3. Regelmäßige Überwachung und Anpassungen: Überwachen Sie die Einhaltung des Tiering-Modells und passen Sie die Zugriffsrechte kontinuierlich an.

Fazit: Die strikte Trennung von Diensten nach dem AD Tiering Modell ist ein wesentlicher Bestandteil einer robusten Sicherheitsstrategie. Indem Sie sicherstellen, dass kritische und weniger kritische Systeme ordnungsgemäß isoliert sind, stärken Sie die Sicherheit Ihrer gesamten IT-Infrastruktur und minimieren das Risiko von Sicherheitsvorfällen, die durch eine falsche Rollenzuweisung entstehen könnten. Mehr zum Tiering Model finden Sie hier:

AD Tiering Struktur – Funktion und Nutzen

Neuerungen in der Exchange Server Roadmap: Neueste Updates zur Exchange Server Roadmap: Entdecken Sie CU15 und Exchange Server SE

Die aktuelle Roadmap für den Exchange Server von Microsoft enthält wichtige Updates, die erhebliche Auswirkungen auf die zukünftige Planung und Verwaltung der IT-Infrastruktur in Unternehmen haben. Für IT-Entscheider und Administratoren ergeben sich daraus spezifische Handlungsanweisungen und Überlegungen.

Hier sind die wesentlichen Neuerungen und deren zeitliche Einordnung:

Wichtige Entwicklungen und Zeitplan

  1. Letztes Kumulatives Update für Exchange Server 2019:
    • Im zweiten Halbjahr 2024 wird das finale kumulative Update (CU15) für den Exchange Server 2019 veröffentlicht. Dieses Update wird wichtige Funktionen einführen, die auf die Unterstützung der RTM-Version des Exchange Server Subscription Edition (SE) abzielen.
  2. Einführung des Exchange Server Subscription Edition:
    • Anfang des dritten Quartals 2025 wird der Exchange Server SE veröffentlicht, gefolgt vom ersten kumulativen Update (CU1) Ende 2025. Diese neue Edition erfordert Abonnement-Lizenzen oder Lizenzen mit aktiver Software Assurance für Server und Benutzerlizenzen.
  3. Kostenloser Exchange Hybrid Server:
    • Microsoft wird weiterhin eine kostenlose Lizenz für den Hybrid Server anbieten, die über den Hybrid Configuration Wizard verfügbar ist. Dies unterstreicht das Engagement von Microsoft, Hybrid- und On-Premises-Lösungen zu unterstützen.
  4. Technische Updates und Sicherheitsverbesserungen:
    • CU15 führt die Unterstützung für TLS 1.3 ein, um die Sicherheit zu verbessern, indem veraltete kryptografische Algorithmen eliminiert werden. Zudem wird die Zertifikatsverwaltung im Exchange Admin Center (EAC) wieder eingeführt, was Administratoren die Verwaltung von Zertifikaten erleichtert.
  5. Unterstützung für neue Betriebssysteme:
    • Exchange Server 2019 CU15 wird auch Windows Server 2025 unterstützen, sobald dieses Betriebssystem allgemein verfügbar ist.

Strategische Bedeutung und Umsetzung

Diese Entwicklungen erfordern eine sorgfältige Planung und Umsetzung durch IT-Entscheider und Administratoren:

  • Planung der Migration: Unternehmen, die derzeit Exchange 2013 verwenden, müssen vor der Installation von Exchange 2019 CU15 oder SE ihre Systeme von Exchange 2013 entfernen, da die Unterstützung für die Koexistenz mit Exchange 2013 entfernt wird.
  • Lizenzmanagement: Die Umstellung auf Exchange Server SE erfordert neue Produktlizenzen, außer für Hybrid-Server, die weiterhin kostenlos über den Hybrid Configuration Wizard lizenziert werden.
  • Sicherheitsstrategie aktualisieren: Die Einführung von TLS 1.3 und die fortlaufenden Updates sollen die Sicherheit von Exchange Server weiter stärken und Unternehmen helfen, ihre Daten effektiv zu schützen.

Zusammenfassung

Die jüngsten Ankündigungen von Microsoft bieten eine klare Richtung für die Zukunft des Exchange Servers, mit einem starken Fokus auf Sicherheit, Unterstützung neuer Technologien und die Flexibilität durch das Abonnementmodell. Unternehmen sind gut beraten, diese Entwicklungen in ihre IT-Strategie zu integrieren, um die Vorteile der neuen Funktionen voll auszuschöpfen und gleichzeitig Compliance und Sicherheit zu gewährleisten.

Wie Hacker Schwachstellen durch Netzwerkerkennung (NDR) aufdecken

Netzwerkerkennung und -reaktion (Network Detection and Response, kurz NDR) ist eine fundamentale Komponente in der Sicherheitsarchitektur vieler Unternehmen. Sie bietet tiefe Einblicke in den Netzwerkverkehr und ermöglicht es Sicherheitsteams, ungewöhnliche Aktivitäten zu erkennen, die auf eine Kompromittierung hindeuten könnten. Doch obwohl NDR viele Vorteile bietet, gibt es bestimmte Aspekte, durch die Hacker in der Lage sind, Lücken in dieser Sicherheitsebene zu finden und zu nutzen.

Die Doppelrolle von NDR

NDR als Detektor: NDR-Systeme sind darauf ausgelegt, Anomalien im Netzwerkverkehr zu erkennen. Sie nutzen fortschrittliche Algorithmen und maschinelles Lernen, um Muster zu identifizieren, die auf Malware-Infektionen, Datenexfiltration oder unautorisierten Zugriff hinweisen könnten. Diese Systeme sind essenziell, um schnell auf Bedrohungen reagieren zu können, die traditionelle Sicherheitslösungen wie Firewalls und Antivirus-Programme umgehen.

NDR als Ziel: Gleichzeitig können NDR-Systeme selbst zum Ziel werden. Hacker, die die Funktionsweise von NDR verstehen, entwickeln Methoden, um diese Systeme zu umgehen oder irrezuführen. Beispielsweise können sie verschleierten oder getarnten Datenverkehr nutzen, der so gestaltet ist, dass er von NDR-Systemen als normal eingestuft wird. Außerdem können Angriffe zeitlich so geplant werden, dass sie während Volumenspitzen stattfinden, bei denen die Wahrscheinlichkeit größer ist, dass sie in der Masse des normalen Verkehrs untergehen.

Wie Hacker NDR-Systeme austricksen

1. Einsatz von Verschleierungstechniken: Hacker verwenden Techniken wie das Splitting von Datenpaketen oder das Verschlüsseln von Malware-Kommunikation, um die Erkennung durch NDR-Systeme zu erschweren. Diese Methoden können dazu führen, dass bösartiger Datenverkehr als harmlos eingestuft wird.

2. Ausnutzung von Konfigurationsschwächen: Schwachstellen in der Konfiguration von NDR-Systemen können es Angreifern ermöglichen, Warnungen zu unterdrücken oder Fehlalarme zu generieren, die Sicherheitsteams ablenken und echte Angriffe verbergen.

3. Angriffe auf die Datenintegrität: Durch Manipulation der von NDR-Systemen erfassten Daten können Hacker die Glaubwürdigkeit der Systemausgaben untergraben. Dies kann durch gezielte Netzwerkangriffe geschehen, bei denen Datenpakete modifiziert oder gefälschte Pakete injiziert werden.

Strategien zur Stärkung von NDR

A. Fortlaufende Überprüfung und Anpassung: Regelmäßige Updates und Patches für NDR-Systeme sind unerlässlich, um Schutzmaßnahmen gegen neu entdeckte Angriffstechniken zu verstärken.

B. Erweiterte Schulung der Sicherheitsteams: Sicherheitsteams sollten speziell geschult werden, um die Taktiken, Techniken und Prozeduren (TTPs) der Angreifer, die auf NDR-Systeme abzielen, zu verstehen und effektiv zu bekämpfen.

C. Integration in eine umfassende Sicherheitsstrategie: NDR sollte nicht isoliert betrachtet werden. Eine Integration in eine übergreifende Sicherheitsstrategie, die andere Ebenen und Maßnahmen umfasst, ist entscheidend, um die Wirksamkeit zu maximieren und Sicherheitslücken zu minimieren.

Obwohl NDR-Systeme eine kritische Rolle in der modernen Netzwerksicherheit spielen, ist es wichtig, sich bewusst zu sein, dass keine Technologie allein ausreicht, um gegen fortschrittliche Cyberbedrohungen immun zu sein. Unternehmen müssen eine mehrschichtige Verteidigungsstrategie verfolgen, die sowohl präventive als auch reaktive Sicherheitsmaßnahmen umfasst.

Warum EDR und XDR gegenüber ausgefeilten Angriffen immer wieder scheitern

In der heutigen komplexen IT-Landschaft, die von ständigen Bedrohungen und sich entwickelnden Angriffstechniken geprägt ist, setzen viele Unternehmen auf Endpoint Detection and Response (EDR) und Extended Detection and Response (XDR) Lösungen, um ihre Netzwerke zu schützen. Obwohl diese Tools entscheidend sind, um viele Arten von Sicherheitsvorfällen zu erkennen und darauf zu reagieren, zeigen Erfahrungen, dass sie bei besonders ausgeklügelten Angriffen an ihre Grenzen stoßen können.

Die Grenzen von EDR und XDR

1. Abhängigkeit von bekannten Signaturen und Verhaltensmustern: EDR- und XDR-Systeme sind oft stark abhängig von Signaturen bekannter Malware und definierten Verhaltensmustern, um Bedrohungen zu identifizieren. Fortgeschrittene Angreifer entwickeln jedoch maßgeschneiderte Lösungen und Methoden, die speziell darauf ausgelegt sind, diese Erkennungsmechanismen zu umgehen. Das bedeutet, dass neue oder angepasste Schadsoftware, die keine erkennbaren Signaturen oder typischen Verhaltensmuster aufweist, möglicherweise nicht erkannt wird.

2. Mangel an Kontext und ganzheitlicher Sicht: Obwohl XDR-Lösungen eine breitere Datensammlung aus verschiedenen Quellen bieten, fehlt es ihnen oft an dem notwendigen Kontext, um die Daten effektiv zu korrelieren und zu interpretieren. Dies führt dazu, dass zwar viele Datenpunkte gesammelt werden, die Analyse jedoch oberflächlich bleibt und somit komplexe Angriffsszenarien nicht vollständig aufgedeckt werden können.

3. Falsche Alarme und Überwachungsmüdigkeit: Ein weiteres Problem stellt die hohe Anzahl von Fehlalarmen dar, die sowohl EDR- als auch XDR-Systeme produzieren können. Dies führt zu einer Überwachungsmüdigkeit bei den Sicherheitsteams, wodurch echte Bedrohungen in einem Meer von Fehlalarmen untergehen können.

4. Ressourcen- und Know-how-Begrenzungen: Viele Unternehmen verfügen nicht über die notwendigen Ressourcen oder das spezialisierte Wissen, um EDR- und XDR-Tools vollständig zu nutzen und zu warten. Dieses Manko wird besonders deutlich, wenn es darum geht, die von diesen Systemen gelieferten Daten zu interpretieren und darauf basierend angemessene Reaktionen zu formulieren.

Beispiele aus der Praxis

Die Herausforderungen und Grenzen von EDR- und XDR-Systemen lassen sich anhand einiger Beispiele aus der Praxis veranschaulichen:

1. Umgehung durch Polymorphismus: Angreifer nutzen polymorphe Malware, die ihr Erscheinungsbild ständig ändert, um Signaturen zu umgehen. Da EDR und XDR stark von Signaturen abhängig sind, können solche Malware-Arten oft unentdeckt bleiben.

2. Ausnutzung von Zero-Day-Schwachstellen: Zero-Day-Exploits, also Schwachstellen, die noch nicht öffentlich bekannt oder gepatcht sind, können von Angreifern genutzt werden, bevor Sicherheitssysteme wie EDR oder XDR darauf eingestellt sind. Diese Art von Angriff ist schwer zu erkennen, da sie keine bekannten Signaturen oder Verhaltensmuster verwenden.

3. Seitliche Bewegungen und legitime Tools: Fortgeschrittene Angreifer verwenden Techniken des seitlichen Bewegens (Lateral Movement) und setzen dabei legitime Administrationswerkzeuge ein, was die Erkennung durch EDR und XDR erschwert. Diese Werkzeuge generieren Aktivitäten, die normal erscheinen und daher oft nicht als bösartig erkannt werden.

4. Angriffe auf das EDR-System selbst: In einigen Fällen richten sich Angriffe direkt gegen die EDR- oder XDR-Lösungen, um diese zu deaktivieren oder zu manipulieren. Solche Angriffe können schwerwiegende Folgen haben, da sie das gesamte Sicherheitssystem kompromittieren.

5. Hohe Rate von Falschpositiven: Die hohe Anzahl von Fehlalarmen, die durch EDR und XDR generiert werden können, führt oft dazu, dass Sicherheitsteams wichtige Warnungen übersehen. Dieses Phänomen wird auch als „Alarmmüdigkeit“ bezeichnet und kann dazu führen, dass echte Bedrohungen nicht rechtzeitig erkannt oder behandelt werden.

Diese Beispiele unterstreichen die Notwendigkeit, Sicherheitssysteme kontinuierlich zu überprüfen und zu verbessern, um mit den sich ständig ändernden Taktiken und Techniken der Angreifer Schritt zu halten.

Strategien zur Verbesserung der Cybersicherheit

A. Anpassung und Weiterentwicklung: IT-Entscheider und Administratoren müssen kontinuierlich in die Weiterbildung ihrer Teams und die Anpassung ihrer Sicherheitssysteme investieren, um mit den sich ändernden Angriffstechniken Schritt zu halten.

B. Einsatz von KI und maschinellem Lernen: Der Einsatz von fortgeschrittenen KI-Technologien kann dazu beitragen, das Erkennungsvermögen von EDR- und XDR-Systemen zu verbessern, indem ungewöhnliche Muster erkannt werden, die sonst unentdeckt bleiben könnten.

C. Betonung auf proaktive Verteidigungsmaßnahmen: Statt sich ausschließlich auf Erkennung zu verlassen, sollten Unternehmen eine proaktivere Sicherheitsstrategie verfolgen, die Risikomanagement, die Stärkung von Endpunkten und die Schulung der Mitarbeiter umfasst.

D. Verbesserung der Incident Response: Eine effektive Incident-Response-Strategie ist entscheidend, um die Auswirkungen von Sicherheitsvorfällen zu minimieren. Diese sollte eine schnelle Identifikation, eine umfassende Untersuchung und eine koordinierte Reaktion auf Sicherheitsvorfälle beinhalten.

E. Härtung durch die Implementierung von einem „Berechtigungskonzept“ unter Berücksichtigung von einer AD Tiering Struktur.

F. Implementierung einer vollständigen Zero-Trust-Architektur.

Siehe hierzu: Zero-Trust-Implementierung mit Microsoft 365

Trotz der fortschrittlichen Technologien, die EDR und XDR bieten, sind sie keine Allheilmittel. Die Sicherheitslandschaft erfordert eine ständige Anpassung und Weiterentwicklung der Strategien und Werkzeuge, um den Bedrohungen immer einen Schritt voraus zu sein

„Mit Anmeldung fortfahren?“ Änderung bei Windows Single-Sign-On

Microsoft hatte es bereits im Dezember angekündigt. Aufgrund des Digital Markets Act (DMA) müssen die Benutzer dem Single-Sign-On auf Windows Geräten zustimmen. Hierzu erhält der Benutzer bei dem Zugriff auf M365 Ressourcen die Frage „Mit Anmeldung fortfahren?“. Diese muss der Anwender mit „weiter“ bestätigen um sich zu authentifizieren. Unter aka.ms/sso-info werden weitere Informationen angeboten. Die Infoseite erklärt, dass SSO weiterhin nur nach Bestätigung dieser Abfrage möglich ist.

Der Benutzer muss diese Meldung auf jedem Gerät an dem er arbeitet einmalig bestätigen. Die Bestätigung ist anschließend nicht mehr nötig, nur wenn sich der Benutzer 90 Tage nicht mehr an diesem Gerät authentifiziert hat.

Die Änderung wird nach und nach innerhalb des Europäischen Wirtschaftsraums aktiviert. Betroffen davon sind die Betriebssysteme Windows 10 und 11, bei denen innerhalb des initialen Gerätesetups ein Land innerhalb des Europäischen Wirtschaftsraums gewählt wurde. Explizit wirkt diese Änderung nicht auf Server Betriebssystemen.

Innerhalb der Entra-Anmeldeprotokolle führen fehlende Benutzerzustimmungen zu Anmeldefehlern mit dem Code 9002341 und der Fehlerursache „User is required to permit SSO“.

In einigen Fällen führt dies zu Problemen, da beispielsweise die Authentifizierung gegen Microsoft 365 Dienste wie z.B. bei einem automatischen Intune Join via GPO nicht durchgereicht wird. Dies klappt erst, wenn der Benutzer den SSO bestätigt hat. Aber auch bei nicht-persistenten VDIs führt das neue Feature bei jeder neuen Sitzung zur oben genannten Abfrage. Microsoft sind Probleme bekannt und will zeitnah nachbessern.

Weitere Infos und der Blog-Eintrag von Microsoft dazu:

Upcoming changes to Windows Single Sign-On | Windows IT Pro (microsoft.com)

Neue Grenzen für Exchange Online: Einführung eines Limits für externe Empfänger

Ab Januar 2025 führt Exchange Online eine neue Beschränkung für die Anzahl der externen Empfänger ein, die innerhalb von 24 Stunden kontaktiert werden können. Dieses Limit wird auf 2.000 Empfänger festgelegt. Diese Maßnahme soll den Missbrauch von Ressourcen verhindern und die Nutzung fairer gestalten.

Wer ist betroffen?

Unternehmen und Einzelpersonen, die Exchange Online verwenden, um große Mengen an E-Mails an externe Empfänger zu senden, sind von dieser Änderung direkt betroffen.

Was muss berücksichtigt werden?

  1. Planung für Volumen-Mailings: Organisationen müssen ihre Kommunikationsstrategien anpassen, um die Limits nicht zu überschreiten.
  2. Alternativen prüfen: Für Nutzer, die regelmäßig hohe Volumen benötigen, empfiehlt Microsoft den Wechsel zu Azure Communication Services Email, einer Lösung speziell für umfangreiche E-Mail-Sendungen.

Diese Änderung wird in zwei Phasen umgesetzt, beginnend mit neuen Tenants im Januar 2025 und anschließend für bestehende Tenants bis Ende Dezember 2025.

Weitere Informationen und Details zu dieser Änderung finden Sie auf der offiziellen Ankündigungsseite von Microsoft.

Exchange Online: Abschied von Basic Auth bei SMTP AUTH – Was Sie wissen müssen

Im September 2025 wird Exchange Online die Unterstützung für die Basic Authentication bei der Client Submission über SMTP AUTH einstellen. Diese Änderung betrifft alle Anwendungen und Geräte, die derzeit diese Methode nutzen, um E-Mails zu senden. Stattdessen wird OAuth als sicherere Authentifizierungsmethode erforderlich sein.

Wer ist betroffen?

Betroffen sind Organisationen und Einzelpersonen, die Exchange Online für das Versenden von E-Mails über SMTP AUTH nutzen. Insbesondere diejenigen, die bisher Basic Authentication verwendet haben, müssen auf moderne Authentifizierungsmethoden umstellen.

Was muss berücksichtigt werden?

  1. Überprüfung der Authentifizierungsmethode: Nutzer sollten im Exchange Admin Center überprüfen, ob bereits OAuth verwendet wird oder noch Basic Auth im Einsatz ist.
  2. Anpassung der E-Mail-Clients: Sollte Ihr E-Mail-Client noch Basic Auth verwenden, ist ein Update oder Wechsel des Clients notwendig, um OAuth zu unterstützen.
  3. Alternative Lösungen: Falls eine Umstellung auf OAuth nicht möglich ist, sollten Nutzer alternative E-Mail-Lösungen in Betracht ziehen, wie z.B. High Volume Email für Microsoft 365 oder Azure Communication Services Email.

Diese Umstellung erfordert eine frühzeitige Planung und gegebenenfalls technische Anpassungen, um einen reibungslosen Übergang zu gewährleisten und die Sicherheit der Datenkommunikation zu erhöhen. Es ist wichtig, dass betroffene Organisationen und Individuen rechtzeitig mit den Vorbereitungen beginnen, um Unterbrechungen im E-Mail-Verkehr zu vermeiden. Weitere Informationen finden Sie auf der offiziellen Ankündigungsseite von Microsoft.

Cookie Consent mit Real Cookie Banner