Windows Defender Systemüberwachung: Wie ein hardwarebasierter Vertrauensstamm zum Schutz von Windows 10 beiträgt

Um kritische Ressourcen wie den Windows-Authentifizierung-Stapel, SSO-Token, den Windows Hello biometrischen Stapel und das Virtual Trusted Platform-Modul zu schützen, müssen Firmware und Hardware eines Systems vertrauenswürdig sein.

Windows Defender Systemüberwachung organisiert die vorhandenen Windows 10 Systemintegritätsfeatures unter einem Dach neu und richtet die nächsten Investitionen in die Windows-Sicherheit ein. Es wurde entwickelt, um folgende Sicherheitsgarantien zu gewährleisten:

  • Schützen und Aufrechterhalten der Integrität des Systems beim Starten
  • Überprüfen, ob die Systemintegrität durch lokalen und Remotenachweis tatsächlich aufrechterhalten wurde

Beibehalten der Integrität des Systems beim Starten

Static Root of Trust for Measurement (SRTM)

Mit Windows 7 bestand eine der Mittel, mit denen Angreifer die Erkennung beibehalten und umgehen würden, darin, ein bootkit oder rootkit auf dem System zu installieren. Diese schadhafte Software wurde gestartet, bevor Windows gestartet wurde, oder während des Startvorgangs selbst, sodass sie mit der höchsten Berechtigungsstufe beginnen kann.

Wenn Windows 10 auf moderner Hardware (d. h. Windows 8-zertifiziert oder höher) ausgeführt wird, stellt ein hardwarebasierter Vertrauensstamm sicher, dass keine nicht autorisierte Firmware oder Software (z. B. ein Bootkit) vor dem Windows-Startladeprogramm gestartet werden kann. Dieser hardwarebasierte Vertrauensstamm stammt aus dem Feature "Sicherer Start" des Geräts, das Teil der Unified Extensible Firmware Interface (UEFI) ist. Diese Technik zur Messung der statischen UEFI-Komponenten für den frühen Start wird als Static Root of Trust for Measurement (SRTM) bezeichnet.

Da es Tausende von PC-Anbietern gibt, die viele Modelle mit verschiedenen UEFI-BIOS-Versionen produzieren, wird beim Start eine unglaublich große Anzahl von SRTM-Messungen. Es gibt zwei Verfahren, um vertrauen zu können: entweder eine Liste der bekannten "schlechten" SRTM-Messungen (auch als Blockliste bezeichnet) oder eine Liste der bekannten "guten" SRTM-Messungen (auch als Positivliste bezeichnet).

Jede Option hat einen Nachteil:

  • Eine Liste der bekannten "schlechten" SRTM-Messungen ermöglicht es einem Hacker, nur 1 Bit in einer Komponente zu ändern, um einen völlig neuen SRTM-Hash zu erstellen, der aufgelistet werden muss. Dies bedeutet, dass der SRTM-Fluss von Natur aus spröde ist - eine geringfügige Änderung kann die gesamte Vertrauenskette für ungültig erklären.
  • Eine Liste der bekannten "guten" SRTM-Messungen erfordert, dass jede neue BIOS/PC-Kombinationsmessung sorgfältig hinzugefügt wird, was langsam ist. Außerdem kann das Entwerfen, Erstellen, Erneutes Testen, Überprüfen und erneutes Bereitstellen einer Fehlerbehebung für UEFI-Code lange dauern.

Sicherer Start – der dynamische Vertrauensstamm für die Messung (DRTM)

Windows Defender Systemüberwachung Secure Launch, das erstmals in Windows 10 Version 1809 eingeführt wurde, zielt darauf ab, diese Probleme durch den Einsatz einer Technologie zu beheben, die als Dynamic Root of Trust for Measurement (DRTM) bekannt ist. DRTM ermöglicht es dem System, zunächst frei in nicht vertrauenswürdigen Code zu starten, aber kurz danach startet das System in einen vertrauenswürdigen Zustand, indem es die Kontrolle über alle CPUs übernimmt und sie auf einen bekannten und gemessenen Codepfad zwingt. Dies hat den Vorteil, dass nicht vertrauenswürdiger früher UEFI-Code das System starten kann, dann aber sicher in einen vertrauenswürdigen und gemessenen Zustand übergehen kann.

Systemüberwachung Sicherer Start.

Secure Launch vereinfacht die Verwaltung von SRTM-Messungen, da der Startcode jetzt nicht mehr mit einer bestimmten Hardwarekonfiguration zusammenhängt. Dies bedeutet, dass die Anzahl der gültigen Codemessungen gering ist und zukünftige Updates breiter und schneller bereitgestellt werden können.

Schutz des Systemverwaltungsmodus (System Management Mode, SMM)

Der Systemverwaltungsmodus (System Management Mode, SMM) ist ein spezieller CPU-Modus in x86-Mikrocontrollern, der Energieverwaltung, Hardwarekonfiguration, thermische Überwachung und alles andere verarbeitet, was der Hersteller für nützlich hält. Wenn einer dieser Systemvorgänge angefordert wird, wird zur Laufzeit ein nicht maskierbarer Interrupt (SMI) aufgerufen, der den vom BIOS installierten SMM-Code ausführt. SMM-Code wird in der höchsten Berechtigungsstufe ausgeführt und ist für das Betriebssystem unsichtbar, was ihn zu einem attraktiven Ziel für böswillige Aktivitäten macht. Selbst wenn Systemüberwachung sicherer Start für den späteren Start verwendet wird, kann SMM-Code potenziell auf hypervisor-Arbeitsspeicher zugreifen und den Hypervisor ändern.

Um dies zu schützen, werden zwei Techniken verwendet:

  • Auslagerungsschutz, um unangemessenen Zugriff auf Code und Daten zu verhindern
  • SMM-Hardwareüberwachung und -nachweis

Der Auslagerungsschutz kann implementiert werden, um bestimmte Codetabellen schreibgeschützt zu sperren, um Manipulationen zu verhindern. Dadurch wird der Zugriff auf keinen Speicher verhindert, der nicht zugewiesen wurde.

Ein hardwaregestütztes Prozessorfeature, das als Supervisor-SMI-Handler bezeichnet wird, kann den SMM überwachen und sicherstellen, dass er nicht auf einen Teil des Adressraums zugreift, den es nicht verwenden soll.

Der SMM-Schutz basiert auf der Secure Launch-Technologie und erfordert, dass sie funktioniert. In Zukunft werden Windows 10 auch das Verhalten dieses SMI-Handlers messen und bestätigen, dass kein betriebssystemeigener Arbeitsspeicher manipuliert wurde.

Überprüfen der Plattformintegrität nach der Ausführung von Windows (Laufzeit)

Während Windows Defender Systemüberwachung erweiterten Schutz bietet, der dabei hilft, die Integrität der Plattform während des Starts und zur Laufzeit zu schützen und aufrechtzuerhalten, ist die Realität, dass wir selbst bei unseren anspruchsvollsten Sicherheitstechnologien eine "Sicherheitsverletzung annehmen"-Mentalität anwenden müssen. Wir können darauf vertrauen, dass die Technologien ihre Arbeit erfolgreich erledigen, aber wir brauchen auch die Fähigkeit, zu überprüfen, ob sie ihre Ziele erfolgreich erreicht haben. Aus Gründen der Plattformintegrität können wir nicht einfach darauf vertrauen, dass die Plattform, die möglicherweise kompromittiert werden könnte, ihren Sicherheitsstatus selbst bestätigt. Daher umfasst Windows Defender Systemüberwachung eine Reihe von Technologien, die eine Remoteanalyse der Integrität des Geräts ermöglichen.

Wenn Windows 10 gestartet wird, werden eine Reihe von Integritätsmessungen von Windows Defender Systemüberwachung unter Verwendung des Trusted Platform Module 2.0 (TPM 2.0) des Geräts durchgeführt. Systemüberwachung Sicherer Start unterstützt keine früheren TPM-Versionen, z. B. TPM 1.2. Dieser Prozess und die Daten sind hardwareisoliert von Windows, um sicherzustellen, dass die Messdaten nicht der Art der Manipulation unterliegen, die bei einer Kompromittierung der Plattform auftreten könnte. Von hier aus können die Messungen verwendet werden, um die Integrität der Firmware des Geräts, den Hardwarekonfigurationsstatus und windows-startbezogene Komponenten zu bestimmen, um nur einige zu nennen.

Startzeitintegrität.

Nachdem das System gestartet wurde, signiert und versiegelt Windows Defender Systemüberwachung diese Messungen mithilfe des TPM. Auf Anfrage kann ein Verwaltungssystem wie Intune oder Microsoft Configuration Manager sie für die Remoteanalyse erwerben. Wenn Windows Defender Systemüberwachung darauf hinweist, dass dem Gerät die Integrität fehlt, kann das Verwaltungssystem eine Reihe von Aktionen ausführen, z. B. das Verweigern des Zugriffs auf Ressourcen für das Gerät.

Systemanforderungen für Systemüberwachung

Für Intel® vPro-Prozessoren™ ab Intel® Coffeelake, Whiskeylake oder höher Beschreibung
CPU mit 64 Bit Ein 64-Bit-Computer mit mindestens vier Kernen (logische Prozessoren) ist für hypervisor- und virtualisierungsbasierte Sicherheit (VBS) erforderlich. Weitere Informationen zu Hyper-V finden Sie unter Hyper-V auf Windows Server 2016 oder Einführung in Hyper-V auf Windows 10. Weitere Informationen zum Hypervisor finden Sie unter Hypervisorspezifikationen.
Trusted Platform Module (TPM) 2.0 Plattformen müssen ein diskretes TPM 2.0 unterstützen. Integrierte/Firmware-TPMs werden nicht unterstützt, mit Ausnahme von Intel-Chips, die Platform Trust Technology (PTT) unterstützen. Hierbei handelt es sich um eine Art integriertes Hardware-TPM, das die TPM 2.0-Spezifikation erfüllt.
Windows DMA-Schutz Plattformen müssen die Windows DMA-Schutzspezifikation erfüllen (alle externen DMA-Ports müssen standardmäßig deaktiviert sein, bis das Betriebssystem sie explizit antreibt).
SMM-Kommunikationspuffer Alle SMM-Kommunikationspuffer müssen in den Speichertypen EfiRuntimeServicesData, EfiRuntimeServicesCode, EfiACPIMemoryNVS oder EfiReservedMemoryType implementiert werden.
SMM-Seitentabellen Darf KEINE Zuordnungen zu EfiConventionalMemory enthalten (z. B. kein Betriebssystem-/VMM-Speicher).
Darf KEINE Zuordnungen zu Codeabschnitten in EfiRuntimeServicesCode enthalten.
Darf NICHT über Ausführungs- und Schreibberechtigungen für dieselbe Seite verfügen
Darf NUR zulassen, dass TSEG-Seiten als ausführbar markiert werden können, und die Speicherzuordnung muss TSEG EfiReservedMemoryType melden.
Der BIOS-SMI-Handler muss so implementiert werden, dass SMM-Seitentabellen für jeden SMM-Eintrag gesperrt sind.
Moderner/verbundener Standbymodus Plattformen müssen modernen/verbundenen Standbymodus unterstützen.
TPM-AUX-Index Die Plattform muss einen AUX-Index mit Index, Attributen und Richtlinien einrichten, die genau dem in der TXT DG angegebenen AUX-Index mit einer Datengröße von genau 104 Bytes (für SHA256-AUX-Daten) entsprechen. (NameAlg = SHA256)
Plattformen müssen einen PS-Index (Plattformlieferant) einrichten mit:
  • Genau der "TXT PS2"-Stil Attribute bei der Erstellung wie folgt:
    • AuthWrite
    • RichtlinieLöschen
    • WriteLocked
    • WriteDefine
    • AuthRead
    • WriteDefine
    • Noda
    • Geschrieben
    • PlattformErstellen
  • Eine Richtlinie von genau PolicyCommandCode(CC = TPM2_CC_UndefineSpaceSpecial) (SHA256 NameAlg und Policy)
  • Größe von genau 70 Bytes
  • NameAlg = SHA256
  • Außerdem muss es zum Zeitpunkt des Betriebssystemstarts initialisiert und gesperrt worden sein (TPMA_NV_WRITTEN = 1, TPMA_NV_WRITELOCKED = 1).
PS-Indexdaten DataRevocationCounters, SINITMinVersion und PolicyControl müssen alle 0x00
AUX-Richtlinie Die erforderliche AUX-Richtlinie muss wie folgt aussehen:
  • A = TPM2_PolicyLocality (Lokalität 3 & Ort 4)
  • B = TPM2_PolicyCommandCode (TPM_CC_NV_UndefineSpecial)
  • authPolicy = {A} OR {{A} AND {B}}
  • authPolicy digest = 0xef, 0x9a, 0x26, 0xfc, 0x22, 0xd1, 0xae, 0x8c, 0xec, 0xff, 0x59, 0xe9, 0x48, 0x1a, 0xc1, 0xec, 0x53, 0x3d, 0xbe, 0x22, 0x8b, 0xec, 0x6d, 0x17, 0x93, 0x0f, 0x4c, 0xb2, 0xcc, 0x5b, 0x97, 0x24
TPM NV-Index Plattformfirmware muss einen TPM NV-Index für die Verwendung durch das Betriebssystem einrichten mit:
  • Handle: 0x01C101C0
  • Attribute:
    • TPMA_NV_POLICYWRITE
    • TPMA_NV_PPREAD
    • TPMA_NV_OWNERREAD
    • TPMA_NV_AUTHREAD
    • TPMA_NV_POLICYREAD
    • TPMA_NV_NO_DA
    • TPMA_NV_PLATFORMCREATE
    • TPMA_NV_POLICY_DELETE
  • Eine Richtlinie von:
    • A = TPM2_PolicyAuthorize(MSFT_DRTM_AUTH_BLOB_SigningKey)
    • B = TPM2_PolicyCommandCode(TPM_CC_NV_UndefineSpaceSpecial)
    • authPolicy = {A} OR {{A} AND {B}}
    • Digestwert von 0xcb, 0x45, 0xc8, 0x1f, 0xf3, 0x4b, 0xcf, 0x0a, 0xfb, 0x9e 0x1a, 0x80, 0x29, 0xfa, 0x23, 0x1c, 0x87, 0x27, 0x30, 0x3c, 0x09, 0x22, 0xdc, 0xce, 0x68, 0x4b, 0xe3, 0xdb, 0x81, 0x7c, 0x20, 0xe1
Plattformfirmware Plattformfirmware muss den gesamten Code enthalten, der zum Ausführen eines sicheren Starts der Intel® Trusted Execution Technology erforderlich ist:
  • Intel® SINIT ACM muss im OEM-BIOS mitgeführt werden
  • Plattformen müssen mit einem Produktions-ACM ausgeliefert werden, der vom richtigen Intel® ACM-Produktionssignierer für die Plattform signiert ist.
Plattformfirmwareupdate Es wird empfohlen, die Systemfirmware über UpdateCapsule in Windows Update zu aktualisieren.
Für AMD-Prozessoren® ab Zen2-Silizium Beschreibung
CPU mit 64 Bit Ein 64-Bit-Computer mit mindestens vier Kernen (logische Prozessoren) ist für hypervisor- und virtualisierungsbasierte Sicherheit (VBS) erforderlich. Weitere Informationen zu Hyper-V finden Sie unter Hyper-V auf Windows Server 2016 oder Einführung in Hyper-V auf Windows 10. Weitere Informationen zum Hypervisor finden Sie unter Hypervisorspezifikationen.
Trusted Platform Module (TPM) 2.0 Plattformen müssen ein diskretes TPM 2.0 oder Microsoft Pluton TPM unterstützen.
Windows DMA-Schutz Plattformen müssen die Windows DMA-Schutzspezifikation erfüllen (alle externen DMA-Ports müssen standardmäßig deaktiviert sein, bis das Betriebssystem sie explizit antreibt).
SMM-Kommunikationspuffer Alle SMM-Kommunikationspuffer müssen in den Speichertypen EfiRuntimeServicesData, EfiRuntimeServicesCode, EfiACPIMemoryNVS oder EfiReservedMemoryType implementiert werden.
SMM-Seitentabellen Darf KEINE Zuordnungen zu EfiConventionalMemory enthalten (z. B. kein Betriebssystem-/VMM-Speicher).
Darf KEINE Zuordnungen zu Codeabschnitten in EfiRuntimeServicesCode enthalten.
Darf NICHT über Ausführungs- und Schreibberechtigungen für dieselbe Seite verfügen
Der BIOS-SMI-Handler muss so implementiert werden, dass SMM-Seitentabellen für jeden SMM-Eintrag gesperrt sind.
Moderner/verbundener Standbymodus Plattformen müssen modernen/verbundenen Standbymodus unterstützen.
TPM NV-Index Plattformfirmware muss einen TPM NV-Index für die Verwendung durch das Betriebssystem einrichten mit:
  • Handle: 0x01C101C0
  • Attribute:
    • TPMA_NV_POLICYWRITE
    • TPMA_NV_PPREAD
    • TPMA_NV_OWNERREAD
    • TPMA_NV_AUTHREAD
    • TPMA_NV_POLICYREAD
    • TPMA_NV_NO_DA
    • TPMA_NV_PLATFORMCREATE
    • TPMA_NV_POLICY_DELETE
  • Eine Richtlinie von:
    • A = TPM2_PolicyAuthorize(MSFT_DRTM_AUTH_BLOB_SigningKey)
    • B = TPM2_PolicyCommandCode(TPM_CC_NV_UndefineSpaceSpecial)
    • authPolicy = {A} OR {{A} AND {B}}
    • Digestwert von 0xcb, 0x45, 0xc8, 0x1f, 0xf3, 0x4b, 0xcf, 0x0a, 0xfb, 0x9e 0x1a, 0x80, 0x29, 0xfa, 0x23, 0x1c, 0x87, 0x27, 0x30, 0x3c, 0x09, 0x22, 0xdc, 0xce, 0x68, 0x4b, 0xe3, 0xdb, 0x81, 0x7c, 0x20, 0xe1
Plattformfirmware Plattformfirmware muss den gesamten Code enthalten, der zum Ausführen des sicheren Starts erforderlich ist:
  • AMD® Secure Launch-Plattformen müssen mit verfügbarem AMD® DRTM-Treiber und installiertem AMD® DRTM-Treiber ausgeliefert werden.

Auf der Plattform muss der AMD® Secure Processor Firmware Anti-Rollback-Schutz aktiviert sein.
Auf der Plattform muss AMD® Memory Guard aktiviert sein.
Plattformfirmwareupdate Es wird empfohlen, die Systemfirmware über UpdateCapsule in Windows Update zu aktualisieren.
Für Qualcomm-Prozessoren® mit SD850 oder höher-Chipsätzen Beschreibung
Kommunikation im Überwachungsmodus Alle Kommunikationspuffer im Monitormodus müssen entweder in EfiRuntimeServicesData (empfohlen) und datenabschnitten von EfiRuntimeServicesCode implementiert werden, wie in den Speichertypen "Memory Attributes Table", "EfiACPIMemoryNVS" oder "EfiReservedMemoryType" beschrieben.
Seitentabellen im Überwachungsmodus Alle Seitentabellen im Überwachungsmodus müssen:
  • KEINE Zuordnungen zu EfiConventionalMemory enthalten (z. B. kein Betriebssystem-/VMM-Speicher)
  • Sie dürfen NICHT über Ausführungs- und Schreibberechtigungen für dieselbe Seite verfügen.
  • Plattformen dürfen nur Seiten im Überwachungsmodus zulassen, die als ausführbare Datei gekennzeichnet sind
  • Die Speicherzuordnung muss den Monitormodus als EfiReservedMemoryType melden.
  • Plattformen müssen Einen Mechanismus bereitstellen, um die Seitentabellen im Überwachungsmodus vor Änderungen zu schützen.
Moderner/verbundener Standbymodus Plattformen müssen modernen/verbundenen Standbymodus unterstützen.
Plattformfirmware Plattformfirmware muss den gesamten Code enthalten, der zum Starten erforderlich ist.
Plattformfirmwareupdate Es wird empfohlen, die Systemfirmware über UpdateCapsule in Windows Update zu aktualisieren.