다음을 통해 공유


[GDPRDemopalooza] Wie funktioniert das Reporting von bestimmten Office/Azure Diensten?

Basierend auf der GDPR / DSGVO Demopalooza hier das Demo zum Reporting von bestimmten Office/Azure Diensten.

Wie immer aufgeteilt in zwei Bereiche: Das "Why" und das "How"

Why

Einer der Hauptaspekte der DSGVO dreht sich um den eigentlichen Schutz der PII (Personally identifiable information). Um diesen Schutz gewährleisten zu können ist es unumgänglich, dass eine Unternehmung genau weiß was auf den technischen Systemen passiert. Dazu gehört , dass durch regelmäßige Überprüfungen sichergestellt ist, dass nur diejenigen über entsprechende Adminrechte verfügen, die diese Recht auch haben sollten. Das schließt mit ein, dass ein solches Reporting auch offenlegt, wenn ggf. ein erfolgreicher Angriff dazu genutzt worden ist sich (wie auch immer) Adminrechte zu übertragen.

Unsere Empfehlungen, welche Reportings regelmäßig zu überprüfen sind können u.a. aus dem Secure Score abgeleitet werden und die hier vorgestellten Reportings beziehen sich auch genau darauf. D.h., dass es noch weitere Reportings gibt, die im Gesamtkontext herangezogen werden müssen, diese werden in diesem Post aber nicht betrachtet.

How

Zu aller erst widmen wir uns der regelmäßigen Überprüfung der Rollen - und starten natürlich mit den global Admins:

  1. Dazu gehen wir auf https://portal.office.com/AdminPortal/Home#/users

  2. und wählen als "View" -> "Global Admins" aus:
    all global admins

  3. Unsere Empfehlung ist nicht mehr als 5 Global Admins zu haben, so sollte die Überprüfung hier sehr schnell sein.

  4. Neben den global Admins sollte es noch weitere geben. Diese müssen im folgenden über die Veränderung des Views überprüft werden. Damit dies erfolgreich ist, muss zu aller erst ein passendes Admin Konzept erstellt und umgesetzt worden sein. Dazu zählt auch, dass immer klar ist, wer (bzw. welche ID) welche Rolle innehaben sollte, so dass schnell ersichtlich ist, wenn eine ID der falschen Rolle zugewiesen ist:
    Change View to non global admin

  5. Nachdem nun die Administratoren überprüft worden sind - und sicher hier natürlich ;) nichts ungewöhnliches ereignet hat, sollten/müssen wir sicherstellen, dass wir keine ungewollten Rollenaktivitäten haben. Dies könnte ggf. auf side-moves von Angreifern hindeuten und sollte dann entsprechend im Auge behalten werden bzw. Gegenmaßnahmen ergriffen werden.

  6. Dazu besuchen wir https://portal.azure.com/#blade/Microsoft_AAD_IAM/ActiveDirectoryMenuBlade/Audit Account provisioning activities

  7. Die View kann/sollte ggf. weiter eingeschränkt werden, da die Liste gerne schnell groß wird und wenn dies nicht in kurzen Zyklen (=>mind. wöchentlich) regelmäßig überprüft wird, dann wird es möglicherweise zu umfangreich.

  8. Auch sollten die "Risky Signins" kontinuierlich beobachtet werden, damit Dinge wie "impossible travel", "ungewöhnliche Logonorte", "brute force attacks" schnellstmöglich wahrgenommen werden.

  9. Dazu muss der Report https://portal.azure.com/#blade/Microsoft_AAD_IAM/ActiveDirectoryMenuBlade/RiskySignIns aufgerufen werden:
    Risky Sign-Ins

  10. Dieser Report kann auch einfach in einem CSV Format heruntergeladen werden, welches dann exemplarisch so aussieht:
    CSV Version Risky Sign-Ins

  11. Zusätzlich gibt es in der Advanced Identity Protection noch den Punkt "Vulnerabilities" - welcher ein Stück weit auch in Richtung Secure Score geht.

  12. Diese Vulnerabilities sollten ebenfalls regelmäßig kontrolliert werden und es sollte dann auch einen Prozess geben, wie mit diesen umgegangen werden sollte, denn es gibt erkannte Vulnerabilities, die bewusst nicht abgestellt werden (z.B. "kein MFA für jeden").
    AAD Vulnerabilities

  13. Beim Klick auf eine gefundene Vulnerability werden noch weiterführende Informationen zu a) der Vulnerability und b) den betroffenen Nutzern dargestellt:
    Admins not using their priv roles

  14. Neben diesen allgemeinen Themen, gibt es auch noch weitere, etwas speziellere Themen. Dazu zählt z.B. die "Nutzung" einer Mailbox durch andere als den eigentlichen Eigentümer. Dies ist grade im Kontext DSGVO relevant, da in Emails Architektur bedingt nun mal sehr viele PII enthalten sind.

  15. Dazu wird https://outlook.office365.com/ecp/Reporting/NonOwnerAccessReport.aspx?rfr=admin_o365&exsvurl=1&mkt=en-US&Realm=ems666407.onmicrosoft.com&RpsCsrfState=83d6c52d-7f69-d045-f91b-b5e52ca810ed&wa=wsignin1.0 aufgerufen
    Mailbox access by non-owners

  16. Last but not least möchte ich hier auf das Reporting zu "safe attachments" bzw. "safe links" eingehen. "Safe Links" dienen dazu "after the facts" [sprich auch nach der Zustellung einer Mail/Dokument] Links zu disablen und somit etwaig gefährliche Links den Zahn zu ziehen. Dazu werden Links [sofern konfiguriert] umgewandelt und beim Aufruf redirected um bei Gefahr geblockt zu werden.
    Die Verwendung von Safe Links/Attachments kann entsprechend ausgewertet werden um hier vorrangig die Gefahr durch Phishing einzugrenzen, welches bei weitem die #1 der Angriffe auf User IDs darstellt.

  17. Hierzu wird https://protection.office.com/?pivot=EventType#/reportv2?id=ATPV2Report aufgerufen, welcher dann folgendes Zutage bringt:
    Spam Detection reportDas Reporting sieht mittlerweile anders aus, da dieses aus dem Exchange Admin Bereich in den O365 Reporting->"Threat protection status" gewandert ist, allerdings habe ich nur Tenants ohne Safe Link Aktivität, denn hierzu wären echte User hilfreich, die ich nicht vorweisen kann! ;) Hier trotzdem ein Blick auf das leere Reporting:
    Threat Protection Status Reporting

    Kleiner Hinweis am Rande: wer Safe Links einmal "positiv" testen möchte, der darf gerne https://www.spamlink.contoso.com/ verwenden!

 

Abschließend ist zu sagen, dass "Sicherheit" und damit auch "DSGVO Compliance" nicht 'mal eben so' passiert. Hier ist es essentiell wichtig, dass die Systeme (regelmäßig/permanent) im Auge behalten werden und entsprechende Reporting Mechanismen und SIEM genutzt werden. Da dies grade im Zuge der Cloud täglich schwieriger wird muss ein entsprechendes Security Operations Center (SOC) etabliert werden oder ggf. die damit verbundenen Tätigkeiten an vertrauenswürdige Partner abgegeben werden. (->Stw "Security as a Service")
Sprechen sie ihren Microsoft Vertreter oder den Microsoft Partner ihres Vertrauens gerne zu diesen Themen an, wir unterstützen gerne!

 

Diese Demoanleitung bietet einen Überblick zur Nutzung von O365/Azure Reportings im Kontext von DSGVO und stellt keine rechtlich bindende Aussage dar!