4
Neue Sicherheits-Features von Windows 10 für Unternehmen (Device Guard und Credential Guard)
Zwei nennenswerte Neuerungen von Windows 10 welche die Sicherheit von Unternehmensrechnern zusätzlich stärken.
Fast unbemerkt hat MS zwei neue Features eingeführt, namentlich:
Es folgt eine kurze Zusammenfassung der Features beider Neuerungen.
Für die Einführung ist Windows 10 Enterprise oder Windows 10 Education nötig. Zusätzlich sind auch nicht unerhebliche Hardware-Anforderungen für das Deployment erforderlich, dazu später mehr.
Das Feature Device-Guard beruht auf der Virtualisierungs-Schicht des OS welche das Ausführen nicht vertrauenswürdiger Software verhindert. Die Hardware basierte Virtualisierung ist eine effektive Ergänzung zum Whitelisting von Applikationen.
Für die Funktion muss die Software eine gültige Signatur besitzen. Die Signierung kann das Unternehmen selbst für seine Anwendungen vornehmen und dann eine Whitelist der auszuführenden Anwendungen definieren. Device Guard bringt dazu diverse Tools mit um seine Anwendungen zu signieren, egal ob Universal oder Win32-Apps.
Jetzt fragt man sich, das gibt es doch schon mit App-Locker !? Das stimmt, jedoch werden die Whitelist-Informationen hier zusätzlich durch eine Hardware unterstütze virtuelle Maschine vor Zugriff geschützt, was es Malware sehr schwer macht diese Informationen zu manipulieren (selbst mit Administrator-Privilegien nicht).
Mehr Infos zum Deployment findet Ihr hier: Device Guard deployment guide
Zusätzlich laufen Windows Dienste die Treiber und Code überprüfen in einem virtuellen Container, der selbst wenn der Rechner von Malware befallen ist, von dieser nicht modifiziert werden kann.
Nur eine signierte neue Device-Policy der das Unternehmen vertraut kann die Informationen im virtuellen Container aktualisieren. Also ein sehr effektiver zusätzlicher Schutz.
Der Credential Guard schützt genutzte Zugangsdaten, indem sie durch Hardware basierte Virtualisierung vor Zugriff durch Malware etc. geschützt wird.
Bisher konnte Malware, hatte sie bereits Zugang zum System, sich mit den im LSA Store gehashten Zugangsdaten weiteren Zugang zu anderen Systemen im Netzwerk verschaffen. Das ist durch den neuen zusätzlichen Schutz durch einen virtuellen Container nicht mehr so einfach möglich.
Beide Features zusammen eingesetzt erhöhen massiv die Sicherheit eines Windows-Systems und legen die Latte für einen Hacker zusätzliche zwei Stufen höher.
Mehr Infos zum Deployment findet Ihr hier: Credential Guard
Um Device- und Credential Guard aktivieren zu können sind folgende Voraussetzungen nötig:
Der IT-Fuhrpark sollte also aus ziemlich aktueller Hardware bestehen wenn man die Feature einsetzen möchte.
Zusätzlich sollte man den Aufwand den Secure-Boot mit sich bringt auch nicht unterschätzen. Es ist also eine gute Planung Voraussetzung zum reibungslosen Deployment nötig.
Aber man ist ja nicht angewiesen gleich alle Rechner damit auszustatten, man hat also immer noch die Wahl welche Rechner den zusätzlichen Schutz bekommen sollen.
Grüße @colinardo
Fast unbemerkt hat MS zwei neue Features eingeführt, namentlich:
Es folgt eine kurze Zusammenfassung der Features beider Neuerungen.
Benötigte Windows Version
Für die Einführung ist Windows 10 Enterprise oder Windows 10 Education nötig. Zusätzlich sind auch nicht unerhebliche Hardware-Anforderungen für das Deployment erforderlich, dazu später mehr.Device Guard
Das Feature Device-Guard beruht auf der Virtualisierungs-Schicht des OS welche das Ausführen nicht vertrauenswürdiger Software verhindert. Die Hardware basierte Virtualisierung ist eine effektive Ergänzung zum Whitelisting von Applikationen.Für die Funktion muss die Software eine gültige Signatur besitzen. Die Signierung kann das Unternehmen selbst für seine Anwendungen vornehmen und dann eine Whitelist der auszuführenden Anwendungen definieren. Device Guard bringt dazu diverse Tools mit um seine Anwendungen zu signieren, egal ob Universal oder Win32-Apps.
Jetzt fragt man sich, das gibt es doch schon mit App-Locker !? Das stimmt, jedoch werden die Whitelist-Informationen hier zusätzlich durch eine Hardware unterstütze virtuelle Maschine vor Zugriff geschützt, was es Malware sehr schwer macht diese Informationen zu manipulieren (selbst mit Administrator-Privilegien nicht).
Mehr Infos zum Deployment findet Ihr hier: Device Guard deployment guide
Zusätzlich laufen Windows Dienste die Treiber und Code überprüfen in einem virtuellen Container, der selbst wenn der Rechner von Malware befallen ist, von dieser nicht modifiziert werden kann.
Nur eine signierte neue Device-Policy der das Unternehmen vertraut kann die Informationen im virtuellen Container aktualisieren. Also ein sehr effektiver zusätzlicher Schutz.
Credential Guard
Der Credential Guard schützt genutzte Zugangsdaten, indem sie durch Hardware basierte Virtualisierung vor Zugriff durch Malware etc. geschützt wird.Bisher konnte Malware, hatte sie bereits Zugang zum System, sich mit den im LSA Store gehashten Zugangsdaten weiteren Zugang zu anderen Systemen im Netzwerk verschaffen. Das ist durch den neuen zusätzlichen Schutz durch einen virtuellen Container nicht mehr so einfach möglich.
Beide Features zusammen eingesetzt erhöhen massiv die Sicherheit eines Windows-Systems und legen die Latte für einen Hacker zusätzliche zwei Stufen höher.
Mehr Infos zum Deployment findet Ihr hier: Credential Guard
Hardware-Anforderungen für die Nutzung der Features
Um Device- und Credential Guard aktivieren zu können sind folgende Voraussetzungen nötig:- Secure Boot
- 64-Bit Hardware-Virtualisierungsfunktionen
- UEFI Firmware
- TPM-Chip
Der IT-Fuhrpark sollte also aus ziemlich aktueller Hardware bestehen wenn man die Feature einsetzen möchte.
Zusätzlich sollte man den Aufwand den Secure-Boot mit sich bringt auch nicht unterschätzen. Es ist also eine gute Planung Voraussetzung zum reibungslosen Deployment nötig.
Aber man ist ja nicht angewiesen gleich alle Rechner damit auszustatten, man hat also immer noch die Wahl welche Rechner den zusätzlichen Schutz bekommen sollen.
Grüße @colinardo
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 283279
Url: https://administrator.de/contentid/283279
Printed on: April 25, 2024 at 16:04 o'clock
4 Comments
Latest comment
Moin Uwe,
Ich bin auch drauf und dran die Adminworkstations damit zu härten. Ob es sich für jedermann lohnt und "erheblich" die Sicherheit verbessert, wage ich hart zu bezweifeln, da das nicht wirklich die Grundlage eines Sicherheitskonzeptes darstellt, sondern eher den letzten Schliff. Auch stehen im "Kleingedruckten" interessante Dinge, ich zitiere mal:
Dann: das Prüfen der Systemvoraussetzengen ist nicht ohne, siehe die doch sehr schmale Liste zu IOMMU mainboards
https://en.wikipedia.org/wiki/List_of_IOMMU-supporting_hardware
Und wer mal reingelesen hat unter https://msdn.microsoft.com/library/windows/hardware/dn932805(v=vs.85).as ... merkt, was für Hansels das verfasst haben - alles andere als einfach nachvollziehbar. Ebenso sind Teile der Texte nicht korrekturgelesen - High-End, aber noch in den Kinderschuhen, möchte ich sagen.
Zu guter letzt:
Mal sehen, wann ich mich da ransetze. Es wäre doch schön einen Sammelthread für Erfahrungen damit zu starten.
Ich bin auch drauf und dran die Adminworkstations damit zu härten. Ob es sich für jedermann lohnt und "erheblich" die Sicherheit verbessert, wage ich hart zu bezweifeln, da das nicht wirklich die Grundlage eines Sicherheitskonzeptes darstellt, sondern eher den letzten Schliff. Auch stehen im "Kleingedruckten" interessante Dinge, ich zitiere mal:
Credentials not protected by Credential Guard:
Credentials that are stored with Credential Manager
oderCredentials that are stored with Credential Manager
If you are using TPM 1.2 or don't have a TPM installed, Credential Guard will still be enabled, but the keys used to encrypt Credential Guard will not be protected by the TPM
Also: sollte TPM 2.0 sein, geht aber in Teilen sogar ohne TPMDann: das Prüfen der Systemvoraussetzengen ist nicht ohne, siehe die doch sehr schmale Liste zu IOMMU mainboards
https://en.wikipedia.org/wiki/List_of_IOMMU-supporting_hardware
Und wer mal reingelesen hat unter https://msdn.microsoft.com/library/windows/hardware/dn932805(v=vs.85).as ... merkt, was für Hansels das verfasst haben - alles andere als einfach nachvollziehbar. Ebenso sind Teile der Texte nicht korrekturgelesen - High-End, aber noch in den Kinderschuhen, möchte ich sagen.
Zu guter letzt:
You cannot run Credential Guard on a virtual machine.
Dann mal fröhliches Testen ganz ohne VMs...Mal sehen, wann ich mich da ransetze. Es wäre doch schön einen Sammelthread für Erfahrungen damit zu starten.
Sers,
Zumindest wird es mit keinen der RTM Hyper-V Servern gehen. Keine Nested Virtualization, und kein virtualisiertes TPM. Zumindest letzteres ist beim 2016er TP3 Hyper-V mit Gen2 VMs bereits möglich. Ersteres wurde wenn ich mich recht entsinne zumindest annonciert.
Kann vSphere nicht mittlerweile TPMs virtualisieren? Nested Virt. hat VMware ja schon länger.
Grüße,
Philip
Zitat von @DerWoWusste:
Zu guter letzt:
Zu guter letzt:
You cannot run Credential Guard on a virtual machine.
Dann mal fröhliches Testen ganz ohne VMs...Zumindest wird es mit keinen der RTM Hyper-V Servern gehen. Keine Nested Virtualization, und kein virtualisiertes TPM. Zumindest letzteres ist beim 2016er TP3 Hyper-V mit Gen2 VMs bereits möglich. Ersteres wurde wenn ich mich recht entsinne zumindest annonciert.
Kann vSphere nicht mittlerweile TPMs virtualisieren? Nested Virt. hat VMware ja schon länger.
Grüße,
Philip
Das wird nicht nur am TPM liegen. Aber die Doku ist dazu sehr wortkarg.
Klar, wie immer noch alles in den Kinderschuhen, wie sich Windows 10 eben auch noch im Entwicklungsprozess befindet, und wir müssen dann wieder die Kohlen aus dem Feuer holen 
bis sie es dann hoffentlich letztendlich so abändern bis man es mit vertretbarem Aufwand anzuwenden vermag...
bis sie es dann hoffentlich letztendlich so abändern bis man es mit vertretbarem Aufwand anzuwenden vermag...