falkebo

Aus meiner Sicht ist es ganz wichtig zu verstehen, dass solche Projekte komplex, umfangreich und zwingend erforderlich sind. Mehrere Perspektiven dazu. In über 35 schwerwiegenden Security Vorfällen die ich in den letzten 4 Jahren bearbeitet habe, gab es nur einen Kunden der ein Tiering implementiert hatte (leider lückenhaft). In über 20 durchgeführten Pentests sind wir immer Domain Admin geworden, bis auf einen einzigen Kunden. Das war auch der einzige Kunde der das Tiering Konzept inkl. PAWs (und anderen Komponenten) richtig umgesetzt hat. Da ich bei Kunden (von 300 Mitarbeitern bis 50.000) schon solche Konzepte erarbeitet und umgesetzt habe, kann ich dir sagen, dass es unerlässlich ist ein solches Konzept zu erstellen. Abgesehen vom Tiering gibt es noch viel mehr Komponenten die hier zusammenspielen, damit das AD robust aufgebaut wird.

Das eingesetzte Verfahren sollte davon abhängig gemacht werden: a) Wer verantwortet/verwaltet die Applikation b) Was sind die Anforderungen hinsichtlich der Berechtigungen Grundsätzlich ist ein zentrales Berechtigungsmanagement sinnvoll und sollte immer vorhanden sein, ansonsten ist z.B. ein Least Privilege Prinzip gar nicht wirklich anwendbar. Sehe ich nicht so. Jede Applikation sollte - wie auch immer - an einen zentralen Identity Provider angebunden werden. Um externe dafür zu berechtigen, würdest du im idealen Fall einfach einen Gast Benutzer in Entra ID für den externen anlegen und diesen entsprechend für die Applikation berechtigen. Vorteile: Der externe Benutzer nutzt einfach den Identity Provider seiner eigenen Organisation weiter Eure Zugriffssteuerung (z.B. mit Conditional Access) stellt trotzdem sicher, dass die Identität für den Zugriff auf die Applikation eure Company Anforderungen erfüllt (MFA, etc.) Welche Berechtigungen er dann innerhalb der Applikation erhält, darüber kann man im Zweifell streiten. Wenn die Applikation in der Verantwortung der Fachabteilung liegt, dann kann dies entweder innerhalb von Entra ID delegiert werden (Berechtigung erteilen um Gruppenmitgliedschaften zu verwalten) oder aber innerhalb der Applikation, liegt dann nicht mehr in der Verantwortung der IT. So oder so muss der Zugriff jedoch über den zentralen Identity Provider erfolgen, alles andere führt dazu, dass ihr keine Chance mehr habt eure Daten zu schützen.

Im Verhältnis zu dem was in den letzten Jahren AD Seitig empfohlen wurde, Stichwort: ESAE, SCAMA, usw. sind das definitiv Quickwins. Ich lenke vielleicht noch ein, wenn es darum geht Tier1 und Tier2 vollständig zu implementieren, alles andere ist wirklich keine Raketenwissenschaft.

Meine Quickwins für dieses Thema: 1. Administrative Tiering einführen. In deinem Fall ist zusätzlich darauf zu achten, dass der Hyper-V Host ebenfalls als T0 System zu betrachten ist, da dieser direkt/indirekt den Domain-Controller kontrolliert. 2. PAWs für die Administration einführen und am Besten nach SCT härten, des Weiteren empfehle ich den Zugriff auf die PAW lediglich via RDP + 2. Faktor zu realisieren. Für jedes Tier wird zwangsweise eine separate PAW benötigt. Die unprivilegierte Workstation von wo aus du zugreifst, sollte stark gesichert sein (Hardening, EDR, Logging) 3. LAPS für alle Server und Clients (bis auf DCs!!!) einführen 4. Allgemeines Client Hardening nach SCT, BSI oder CIS (einschließlich Device Guard, Credential Guard, usw.) Damit hast du erstmal eine gute Grundlage.

Was hat das jetzt genau mit DLP bzw. Information Protection zu tun? Du unterschreibst beim Einritt in die Firma eine Verschwiegenheitsklausel in der auch festgehalten ist, dass nach Beendigung des Arbeitsverhältnisses alle firmenrelevanten Daten restlos und nachweislich vernichtet werden müssen. Mit obigen Maßnahmen erzielt man folgendes: 1. Datendiebstahl wird technisch erschwert, da Dokumente (ohne die aufwendige Verwendung von Workarounds mittels Screenshots etc.) nicht mehr unkontrolliert kopiert werden können. 2. Durch die Protokollierung behältst du zumindest die Kontrolle um im Falle eines Falles bei bösartigem Handeln potenzielle rechtliche Ansprüche geltend zu machen. Ich bin kein Jurist, jedoch würde ich mir als Unternehmer welcher mit hochsensiblen Daten hantiert, diese Möglichkeit nicht nehmen lassen. Wenn man diesen Satz so liest, entsteht so bisschen das Gefühl, dass alle Unternehmen welche z.B. MIP einsetzen, ***en sind. Microsoft Information Protection in Microsoft 365 - Microsoft 365 Compliance | Microsoft Docs Wie gesagt, 100% Schutz gibt es nicht. Im Zweifel heißt du Edward Snowden und schleust die Daten in einem Zauberwürfel raus. Hier geht es darum verschiedene Maßnahmen einzusetzen um das Risiko zu minimieren.

100% gibt es in dem Kontext nicht, schon klar. Aber es ist durchaus ein riesiger Unterschied, ob ich 1000 Dateien manuell screenshote oder einfach STRG-C, STRG-V mache. Abgesehen davon, und das ist eigentlich der springende Punkt, habe ich mittels Audit Log die Möglichkeit nachzuvollziehen welche Dateien ein Mitarbeiter kurz vor der Kündigung angesehen hat.

Ich verstehe die Diskussion um das Thema PKI und Kerberos hier gerade nicht wirklich. Also ja, NTLM hat diverse Schwachstellen, die man im besten Fall durch abschalten des Protokolls komplett unterbindet, nur leider ist das in wahrscheinlich 80% der Unternehmen nicht möglich, da harte Abhängigkeiten zu Legacy Protokollen vorhanden sind (wie bereits einige hier schon angebracht haben). In meiner Top 5 der wichtigsten AD Security Maßnahmen, würde NTLM abschalten und PKI (wahrscheinlich ist hiermit Zertifikatsbasierte Authentifizierung gemeint) jedoch sowieso nicht landen. Denn trotz Kerberos UND Zertifikatsbasierter Authentifizierung, sind Angriffe wie Pass-The-Ticket immer noch möglich, die machen IMHO den größten Teil der Angriffsvektoren in einem AD aus.

Hallo @Thomas Maggnussen. Ich weiß nicht, ob ich deine Frage richtig verstanden habe, versuche Sie jedoch zu beantworten. Die Schwachstellen im Windows Print Spooler, welche unter CVE-2021-34527 und CVE-2021-36958 geführt werden, sind ganz grundsätzlich erstmal sogenannte RCEs (Remote-Code-Execution) Schwachstellen. Hierbei wird es einem Angreifer ermöglicht, Schwachstellen in einem Programm über das Netzwerk auszunutzen. Im Rahmen von Print Nightmare, können Angreifer (sofern Sie sich im internen Netzwerk befinden), präparierten Code an beliebige Print Spooler schicken und sich anschließend z.B. eine SYSTEM Shell erzeugen lassen. Gegen DCs oder ähnlich privilegierte Server gerichtet, hat dieser Angriff verheerende Folgen. Die möglichen Eintrittspunkte für solch einen Angriff reichen von "Ich stöpsele mich am Netzwerk an", bis zu "Ich bringe meinen Exploit via E-Mail, Drive-By, etc. ins Netzwerk und lasse mir eine Reverse-Shell aufbauen".

Ich würde 20 Jahre mit 5-10 Jahre ersetzen, ansonsten gebe ich dir Recht. Angemessenes Backup Konzept samt Disaster Recovery Plan -> Halbe Miete Endpoint Detection & Response Lösung (EDR / XDR) für alle Clients und Server (gerne inkl. Ransomware Schutz auf Endpoints und Fileserver) Active Directory Security (Tiering Konzept, AD Hardening, PAWs, MFA für privilegierte Konten, Device Guard & Credential Guard, etc.) Vernünftige Netzwerksegmentierung samt Next-Gen Perimeter Firewall Angemessenes Patchmanagement (OS inkl. 3Party Software) State of the Art E-Mail Content Filter Wenn die obigen Punkte alle eingehalten werden, wird keiner Kopfschmerzen mit Ransomware haben. Das ist natürlich kein fertiger Bauplan sondern lediglich ein paar Bullet Points, aber wem erzähle ich es, ihr wisst es ja eh schon.

Magst du die denn haben? ;)

Hi @Thomas Maggnussen. Die Entrypoints für Ransomware sind tatsächlich in der Praxis sehr unterschiedlich, ich liste dir einfach mal diverse Möglichkeiten auf: E-Mail (beinhaltet Attachments, Download Links, Phishing, etc.) Drive-By Downloads Zero Day Exploits (Citrix NetScaler, Exchange, Webserver, etc.) Konfigurationsfehler VPN Tunnel jeglicher Art (Site2Site, SSL-VPN) Infizierte Hardware (USB Sticks) Social Engineering Es gibt heutzutage sehr gute Methoden und Techniken, die Wahrscheinlichkeit eines erfolgreichen Ransomware-Angriffs einschließlich der damit verbundenen Auswirkungen drastisch zu reduzieren.

Ist einem von euch eigentlich aufgefallen, dass der Spooler Service in einer Windows Server 2019 Core Installation garnicht vorhanden ist? Trotzdem ist obige Version als vulnerable gelistet: https://msrc.microsoft.com/update-guide/vulnerability/CVE-2021-34527

Ich erkenne hier halt nirgends einen Grund für separate Domänen... Bei ADs geht der Trend heutzutage in Richtung "keep it simple". 1 Domain, die Gesellschaften können auch locker mittels OUs getrennt werden (und sogar eingeschränkt delegiert). Ist mittlerweile aber auch schon wieder von MS retired

Schon klar, im Rahmen und den Möglichkeiten des Forums natürlich.

Hi @baccus, was du beschreibst läuft eigentlich auf ein Szenario hinaus: Es wird ein riesen Migrationsprojekt. Was sind denn die Anforderungen dieses Projekts? Braucht jede Firma wirklich eine eigene Domäne? Wenn du hier mehr Infos teilst, kann man dir vermutlich helfen eine "bessere" Entscheidung zu treffen.