Eine Migration in die Microsoft Office Cloud spart administrativen Aufwand und hat viele weitere Vorteile, die Microsoft nicht müde wird weitlaufend kund zu tun. Ein Cloud-Betrieb bringt jedoch neue Risiken sowie eine notwendige neue Planung der IT-Sicherheit mit sich, welche ich im Folgend kurz anreißen möchte.
Der Inhalt im Überblick
Microsoft Office 365 Account kompromittiert
Das Bedrohungsszenario ist inzwischen bekannt. Ein Angreifer erbeutet meist via (Spear-)Phishing Zugangsdaten eines Azure Accounts. Der Login stellt dabei optisch die Microsoft Login Seite nach. Meist ist die betroffene Adresse auch schon im Login-Formular eingetragen. Bei der Website handelt es sich oft um eine gekaperte Seite und nicht einen eigenen Server des Angreifers. Gibt man seine Zugangsdaten ein, werden diese nicht selten „abgelehnt“. Dies wird implementiert, damit das Opfer seine Daten erneut eingibt und sie somit „verifiziert“.
Das grüne Schloss hilft nicht weiter
Wie im Screenshot zu erkennen, ist nicht auf den ersten Blick eindeutig, dass es sich hier um eine Phishing-Seite handelt. Das grüne Schloss wiegt die arglosen Anwender dabei in falscher Sicherheit. Es weist lediglich darauf hin, dass das Zertifikat von einer anerkannten Zertifizierungsstelle ausgestellt wurde und eine Transportverschlüsselung via TLS etabliert wurde. Darüber hinaus ist es möglich unter fremden Namen Zertifikate ausstellen zu lassen bzw. Zertifikate für Domains ausstellen zu lassen, deren Eigentümer man nicht selbst ist. So mussten die Zertifizierungsstellen Comodo und Let‘s Encrypt in der Vergangenheit mit Problemen dieser Art kämpfen. Letztere hat vor Kurzem den Validierungsprozess erneut verbessert.
Einmal drin, alles hin
Mit dem Zugang zum System kann ein Angreifer Kontaktdaten abziehen, Mailkommunikation ausspähen und ggf. auf Dokumente im SharePoint oder OneDrive zugreifen. Nachdem genug Daten gesammelt wurden, sendet der Angreifer Mails im Namen desjenigen, dessen Account er infiltriert hat. Des Weiteren besteht die Gefahr, dass sich ein Angreifer via VPN in das Firmennetzwerk einloggt, da die Accounts in der Regel auch mit dem Active-Directory (AD)-Konto verknüpft sind. Von dort aus, kann ein Angreifer das Netzwerk von innen weiter angreifen. Fehlen grundlegende Maßnahmen, wie eine Netzwerksegmentierung oder ein Rollen- und Benutzerkonzept, ist die gesamte Firma ab dem Eindringen des Angreifers ein offenes Buch.
Schutzmaßnahmen und Audit Logs
Selbstverständlich können Maßnahmen integriert werden, die das Risiko bzw. die Auswirkungen eines solchen Angriffs erheblich reduzieren.
Filterung mittels IP-Adresse
Eine einfache Methode, die oft schon viel bewirken kann, ist einen Filter bzgl. der Geolokation zu definieren. Wenn nicht zu erwarten ist, dass sich jemand z.B. aus Russland, China, den USA oder Spanien einloggt, können sämtliche Login-Versuche aus diesen Ländern blockiert werden. Ist einem Angreifer gelungen Zugangsdaten zu erbeuten, kommt er dennoch nicht in das System. An dieser Stelle könnte ein einfacher Angriff schon enden, da der Angreifer nicht weiß, ob die Zugangsdaten falsch sind, oder er aufgrund der IP-Adresse abgelehnt wurde.
In eine ähnliche Richtung geht auch die Konfiguration zum „unmöglichen Reisen“. Wenn ein Benutzer sich innerhalb weniger Minuten z.B. erst aus Italien und dann aus Dänemark einloggt, spricht viel dafür, dass er nicht gereist ist, sondern seine IP-Adresse z.B. via VPN versteckt. Hier kann bei Detektion eines solchen Verhaltes eine automatische Blockade des Benutzerkontos konfiguriert werden.
Multi-Faktor-Authentifizierung ist ein Muss
Der wirksamste Schutz ist die Multi-Faktor-Authentifizierung. Microsoft unterstürzt von Haus aus eine Reihe von Methoden, um den Login zusätzlich abzusichern. Selbst mit gestohlenen Zugangsdaten kann ein Angreifer keinen weiteren Schaden anrichten. Die Multi-Faktor-Authentifizierung sollte konsequent auf alle (externen) Services, die auf einem AD-Konto aufbauen, implementiert sein. Dies können z.B. ein VPN, ein Webtool für Tickets oder ein Terminalserverservice sein.
Aufklärung des Vorfalls
Ist es einem Angreifer gelungen einen erfolgreichen Angriff durchzuführen, muss dieser im Nachgang aufgearbeitet werden. Bei der Cloud fehlen jedoch die Systeme, um Spuren zur Ursachenermittlung zu sichern. Wird das Einfallstor nicht sauber aufgearbeitet besteht die Gefahr, dass ein erneuter Angriff auf die gleiche Art und Weise durchgeführt werden kann.
Microsoft bietet hierfür die Möglichkeit sogenannte Audit Logs zu aktiveren und zu durchsuchen. Diese betreffen z.B. die Nutzung des Postfaches, Logins der Benutzer oder administrative Tätigkeiten. Die Logfiles können sehr ausführlich sein und sind zugleich das einzige Mittel, um einen IT-Sicherheitsvorfall in der Microsoft Cloud forensisch aufzuarbeiten. Daher sollte direkt zum Start in die Cloud evaluiert werden, wie der eigene Bedarf an Logfiles ausschaut. Microsoft macht es dabei vom Abonnement abhängig, wie lange Logfiles vorgehalten werden.
Das Lizenzproblem im Detail
Microsoft justiert die Möglichkeit anhand der gebuchten Lizenz, in wie weit Logfiles rückwirkend eingesehen werden können. Office 365 E3 und Microsoft 365 E3 Pläne hält die Logs 90 Tage vor, wohingegen Unternehmen mit einer Office 365 E5 oder Microsoft 365 E5 Abonnement die Logfiles von einem Jahr rückwirkend einsehen können. Dies wird dann relevant, wenn man betrachtet, wie viel Zeit verstreichen kann, bis ein Angriff entdeckt wird. Nach den aktuellen M-Trends von FireEye ist die Median der Erkennungszeit im EMEA Raum im Jahr 2019 im Vergleich zu 2018 von 177 auf 54 Tage gesunken. Dennoch können Vorfälle, deren Ursprung länger als 90 Tage her ist, nicht mehr untersucht werden, da keine Spuren mehr vorhanden sind.
Die Berichtsdaten bei Buchung von Azure AD zeigen eine ähnliche Problematik. Auch hier sind die Speicherfristen davon abhängig, welches Abonnement gebucht wird. Die längste Frist, die sicherheitsrelevante Logs bis zu 90 Tage vorhält, ist im Azure AD Premium P2 (nur im E5 Abonnement) enthalten
Nicht zuletzt wurde erst vor Kurzem bekannt, dass Microsoft bei günstigeren Cloud-Plänen von Office Produkten diese so konfiguriert, dass Gruppenrichtlinien nicht wirken. Dies führt u.a. dazu das bereits getroffene Sicherheitsmaßnahmen, wie die globale Deaktivierung von Makros in Office, nicht (mehr) wirken und ein Anwender so schädliche Markos wieder ausführen kann.
Bei einem Sicherheitsvorfall helfen nur die Logfiles
Ohne Aktivierung der Audit Logfiles ist man bei einem Sicherheitsvorfall in der Microsoft Cloud quasi blind. Da keine eigenen Server mehr betrieben werden und ein Angriff auch nicht über die eigene Infrastruktur läuft, ist man zwingend auf die Audit Logfiles der Cloud angewiesen. Mit Hilfe dieser lassen sich Zugriffe und Tätigkeiten eines Angreifers nachvollziehen. Daher sollte nicht nur der reine Funktionsumfang der Anwendungen bei der Auswahl der richtigen Cloud Lizenz betrachtet werden, sondern auch die Möglichkeiten zur Absicherung dieser. Die kann unter Umständen höheren Kosten führen, sollte aber bei einer Wirtschaftlichkeitsbetrachtung mit einbezogen werden, denn ein Sicherheitsvorfall verursacht in den meisten Fällen weit mehr als nur einen finanziellen Schaden.
Letztendlich erhärtet sich der Verdacht, dass zur Umsetzung eines umfassenden Sicherheitskonzeptes man nur schwer an dem teuren E5 Plan von Microsoft vorbeikommt. Wenigstens sind in diesem weitere Sicherheitsfeatures wie Microsoft Defender Advanced Persistent Threats mit dabei.
