Hardware Hashes für Autopilot Registrierung zentral erfassen

Windows Autopilot bietet die Möglichkeit, neue Geräte in Intune automatisch einzurichten und konfigurieren zu lassen. Hierdurch lassen sich die manuellen Schritte beim Onboarding neuer Geräte auf ein Minimum reduzieren oder sogar vollständig vermeiden. Ein in Autopilot registriertes Endgerät lässt sich zudem zentral aus der Ferne zurücksetzen.

Einleitung

Um ein Gerät für die Verwendung mit Autopilot zu registrieren, muss die eindeutige ID (der Hardwarehash) des Gerätes vorab bekannt sein. Der Hardwarehash ist auf jedem Windows Computer hinterlegt und kann z. B. mittels einer WMI-Abfrage ermittelt werden. Möglicherweise kann bereits der Hardwarelieferant die Hashes in Form einer CSV-Datei zusammen mit neu erworbenen Geräten übermitteln oder gar die Registrierung in Intune direkt vornehmen. In manchen Fällen ist es jedoch so, dass Endgeräte bereits in Umlauf sind, die im Laufe der Zeit manuell in Intune eingebucht worden sind. In diesem Fall kann das nachträgliche Ermitteln der Hashes zur Herausforderung werden. Das hier beschriebene Verfahren zeigt eine Möglichkeit auf, die Hashes von bereits in Intune sichtbaren Endgeräten zentral einzusammeln und für die Autopilotregistrierung zu nutzen.

Konzept

Das Einsammeln der Hardwarehashes erfolgt hier über die Installation eines Intune Application Packages. Dabei handelt es sich nicht um eine Installation im eigentlichen Sinne, da keine Dateien auf dem Endgerät installiert werden. Stattdessen ermittelt das Installationsprogramm auf dem Endgerät die Seriennummer sowie den Hardware-Hash und legt diese Daten in Form einer CSV-Datei in einem Dateishare innerhalb eines Azure Storage Accounts zentral ab.

Das Speichern der Hashwerte erfolgt in Form von .csv Dateien, wobei für jedes Gerät eine neue Datei angelegt wird, um den konkurrierenden Zugriff auf eine einzelne Datei zu vermeiden. Die einzelnen Dateien können später jedoch sehr einfach zu einer einzelnen Datei zusammengeführt werden.

Für den Zugriff auf den Azure Storage Share verwendet die Hardware Hash Collector App einen SAS Token, der über die Installationskommandozeile an das App Package übergeben wird.

Umsetzung

In diesem Abschnitt soll die Umsetzung der angedachten Lösung erläutert werden.

Storage Account

Zum Speichern der Hardwarehashes wird ein Azure Storage Account benötigt, der über das Azure Portal mit diesen Schritten angelegt werden kann:

  • Storage accounts | Create
  • Subscription | Resource group | Region wählen
  • Beliebigen, eindeutigen Storage acount name vergeben
  • Kostengünstigste Redundancy wählen
  • Review
  • Create
  • Go to resource

File Share anlegen

Innerhalb des Storage Accounts muss nun ein File Share mit diesen Schritten erzeugt werden:

  • File shares
  • File share
  • Eindeutigen Name vergeben und kostengünstigen Tier wählen
  • Create
  • Properties des gerade angelegten File Share auswählen
  • Nun die URL in die Zwischenablage kopieren und zur späteren Verwendung sichern

SAS-Token erzeugen

Für den Zugriff auf den FileShare wird eine Shared Access Signature (SAS) benötigt, die wie folgt angelegt werden kann:

  • Shared access signature wählen
  • Alle Allowed resource types auswählen
  • Sinnvolles expiry date wählen
  • Generate SAS and connection string
  • Generiertes SAS token in die Zwischenablage kopieren und sichern, da es später benötigt wird

Intune Application Package

Das eigentliche Ermitteln und Speichern des Hardwarehash geschieht mit Hilfe einer Application, die über Intune bereitgestellt und verteilt wird. Dabei handelt es sich nicht im engeren Sinne um eine Application, die auf dem Endgerät tatsächlich installiert wird, vielmehr besteht das Package aus einem Installationsskript, das einmalig ausgeführt wird. Zur Laufzeit des Skripts wird der Hashwert des Gerätes exportiert und zentral gespeichert. Zusätzlich wird ein Wert in der Windows Registry des Endgeräts angelegt, der für die erforderliche DetectionRule des Intune Application Package verwendet wird.

Vorbereiten der Intune Application

Wesentlicher Inhalt des Application Package ist ein PowerShell Skript namens Export-Hash.ps1, dessen Skriptcode hier aufgeführt ist.

[CmdletBinding()]

Param (

       [Parameter(Mandatory=$true)]

       [string]$TargetURL,

       [Parameter(Mandatory=$true)]

       [string]$SasToken

)

# Collect data

$computer = New-Object PSObject

$win32Bios = Get-CimInstance -Class Win32_BIOS

$devDetail = Get-CimInstance -Namespace root/cimv2/mdm/dmmap -Class MDM_DevDetail_Ext01 -Filter "InstanceID='Ext' AND ParentID='./DevDetail'"

$hash = ""

if ($devDetail)

{

       $hash = $devDetail.DeviceHardwareData

}

$computer | Add-Member -MemberType NoteProperty -Name "Device Serial Number" -Value $win32Bios.SerialNumber

$computer | Add-Member -MemberType NoteProperty -Name "Windows Product ID" -Value ""

$computer | Add-Member -MemberType NoteProperty -Name "Hardware Hash" -Value $hash

# Write data to CSV file

$tempFolderPathName = Join-Path $env:TEMP -ChildPath "CollectAutoPilotInfo"

If(-not (Test-Path -Path $tempFolderPathName))

{

    New-Item -Path $tempFolderPathName -ItemType Directory

}

$dataFileName = Join-Path -Path $tempFolderPathName -ChildPath "$($env:COMPUTERNAME).csv"

$computer | ConvertTo-Csv -NoTypeInformation -Delimiter "," | % {$_.Replace('"','')} | Out-File $dataFileName -Force

# Upload CSV file

$url = $TargetUrl

If(-not ($SasToken.StartsWith("?")))

{

    $url += "?"

}

$url += $SasToken

Start-Process -FilePath "azcopy.exe" -ArgumentList "copy $dataFileName `"$url`""

# Register successful application deployment for detection method to work.

$appRegistryKey = "HKLM:\SOFTWARE\Iteracon\Apps\HardwareHashCollector"

If(-not (Test-Path -Path $appRegistryKey))

{

    New-Item -Path $appRegistryKey -Force

}

New-ItemProperty -Path $appRegistryKey -Name "Version" -Value "1.0" -Force

Zur Laufzeit des Skripts wird zusätzlich AzCopy von Microsoft benötigt, das zusammen mit der oben dargestellten Skriptdatei in das Intune Application Package aufgenommen wird. Mehr zu AzCopy und der Möglichkeit zum Download des Tools findet man hier: https://learn.microsoft.com/de-de/azure/storage/common/storage-use-azcopy-v10.

Die Skriptdatei Export-Hash.ps1 sowie AzCopy.exe wird mit Hilfe des Microsoft Win32 Content Prep Tool zu einer .intunewin Datei konvertiert. Die Vorgehensweise hierzu wird als bekannt vorausgesetzt und hier nicht näher erläutert. Ausführliche Informationen zu diesem Thema findet man jedoch hier: https://learn.microsoft.com/de-de/mem/intune/apps/apps-win32-prepare .

Intune Package erstellen

Die Vorgehensweise des Anlegens eines Intune Win32 Application Package wird ebenfalls als bekannt angenommen, nähere Informationen dazu sind hier zu finden: https://learn.microsoft.com/de-de/mem/intune/apps/apps-win32-add.

Beim Anlegen der Application sind folgende Parameter zu berücksichtigen. Die Werte für <File Share URL> und <SAS Token> bei der Konstruktion des Install Command sind dabei durch die entsprechenden Werte zu ersetzen, die sich beim Anlegen des Storage Account und des File Share ergeben haben, siehe oben. Die beiden Werte müssen jeweils in doppelte Anführungszeichen gesetzt werden.

App Information
NameHardware Hash Collector
Version1.0
PublisherITERACON
Program
Install commandPowerShell.exe -ExecutionPolicy Bypass -File .\Export-Hash.ps1 -TargetURL "<File Share URL>" -SasToken "<SAS Token>"
Uninstall command-
Install behaviorSystem
Detection Rules
Rules formatManually configure detection rules
Rule TypeRegistry
Key PathHKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\iteracon\Apps\HardwareHashCollector
Value NameVersion
Detection methodVersion comparison
OperatorGreater than or equal to
Value1.0

Die so erstellte Application wird nun allen Geräten als required zugewiesen und damit die Verteilung gestartet. Nach und nach werden dann die Hardwarehashes in Form von .csv Dateien in dem zuvor bereitgestellten Azure Storage File Share abgelegt, von wo aus sie auf einen Adminrechner heruntergeladen werden können. Dies kann z. B. mit dem Microsoft Azure Storage Explorer erfolgen:

Die eingesammelten .csv Dateien können entweder einzeln in Intune importiert, besser jedoch mit Hilfe dieser beiden PowerShell Befehle zu einer einzelnen Datei zusammengeführt und dann importiert werden:

MD .\Merged

Get-ChildItem -Filter *.csv | Select -ExpandProperty FullName | Import-Csv | Export-Csv .\Merged\Autopilot.csv -NoTypeInformation -Append

"Besser bewirten: Möglichkeiten für eine reibungslose Durchführung von Bewirtungsprozessen" 

Bewirtungsanforderungsprozesse spielen eine zentrale Rolle in Unternehmen und Organisationen, wenn es darum geht, Mitarbeitern, Kunden oder Geschäftspartnern eine angemessene Verpflegung zur Verfügung zu stellen. Dabei geht es nicht nur um das Essen und Trinken an sich, sondern auch um die Bedingungen und Abläufe, die für eine reibungslose Bewirtung erforderlich sind. In diesem Blogbeitrag werden wir uns mit den unterschiedlichen Möglichkeiten befassen, die bei der Planung und Durchführung von Bewirtungen möglich sind. 

Nachfolgend werden die drei Möglichkeiten der Bewirtungsprozesse, mit ihren Vor- und Nachteilen vorgestellt. 

  1. Formlose Bewirtungsanforderung 

Eine formlose Bewirtungsanforderung ist die einfachste Form. Wie der Name es vermuten lässt, kann es auf jedem Weg erfolgen. Sei es die persönliche Aufforderung, per E-Mail oder in Papierform. 

Vorteile: 

  • Einfach 
  • Kostengünstig 

Nachteile: 

  • Keine Struktur 
  • Keine nachweißliche Freigabe von Vorgängen 
  • Skaliert nicht (für mittlere und größere Unternehmen nicht geeignet) 
  1. Formale Bewirtungsanforderung 

Wer schon in Großunternehmen tätig ist oder war, kann davon ein Liedchen singen. Für alles gibt es mindestens ein Formular. 
Diese Formulare sind oftmals immer noch klassisch auf Papier, können aber je nach Unternehmen auch digital in Form von einem PDF-Antrag sein, der ausgefüllt werden muss. Moderner wäre es über ein Forms Formular, welches eine Power-App im Hintergrund hat. 

PowerApps haben in dem Zusammenhang den Vorteil, dass sich viele Felder wie Abteilung und Kostenstelle automatisch aus dem Azure Active Directory befüllen können. Des Weiteren können PowerApps auch komplexe Freigabeprozesse abbilden und dieses dann in eine Tabelle oder Datenbank eintragen (Sollten Sie Interesse an einer solchen PowerApp haben kontaktieren Sie uns gerne.) 

Vorteile: 

  • Strukturiert  
  • Nachweißliche Freigaben 
  • Besonders für größere Unternehmen geeignet 
  • Skaliert besonders gut 

Nachteile: 

  • Mäßiger Aufwand bei der Erstellung 
  • Wegen der Einrichtungskosten nur bedingt für kleinere Unternehmen geeignet
  1. Kalender Bewirtungsanforderung 

Durch einen Eintrag eines Termins in einen Kalender wird dem Team oder der Assistenz mitgeteilt, dass es eine Veranstaltung gibt, zu der eine Bewirtung erbeten wird. 
Dieser Kalender kann traditionell auf Papier oder elektronisch erfolgen. 
Im Microsoft Umfeld haben wir die Möglichkeit, für solche Vorgänge, Ressourcen-Postfächer zu benutzen. Viele kennen diese Funktion bereits für die Buchung von Meeting-Räumen, Pool-Wagen oder Beamern. Diese Ressourcen-Postfächer können für alles benutzt werden, was für einen gewissen Zeitpunkt benötigt wird oder angefordert werden muss. 
Der Veranstalter lädt einfach die Ressource als Teilnehmer mit zu dem Termin ein. 

Normalerweise ist es so, dass Ressourcen eine Doppelbuchung nicht zulassen. Aber mit einer kleinen Einstellung auf der Exchange-Verwaltungsshell oder der Exchange Online-Verwaltungsshell kann man dieses Verhalten abstellen. 

Set-CalendarProcessing Bewirtung -AllowConflicts $true 

Auch kann man die Einstellung für die Buchungsdelegierten für einen einfachen Freigabevorgang einrichten und so sicherstellen, dass die zuständigen Personen den Termin wahrgenommen haben. 

Vorteile: 

  • Strukturiert  
  • Nachweißliche Freigaben 
  • Besonders für kleinere und mittelgroße Unternehmen geeignet 
  • Es werden keine Lizenzen für die Postfächer benötigt 
  • Einfach einzurichten, wenn man die PowerShell nicht scheut 

Nachteile: 

  • Skaliert nur bis zu einer gewissen Größe 
  1. Zusammenfassung 

Wie man den Prozess der Bewirtungsanforderung gestaltet, hängt von mehreren Faktoren ab. Die beiden wichtigsten sind die Unternehmenskultur und die Unternehmensgröße. Denn Prozesse, die für kleinere Unternehmen funktionieren, funktionieren nicht immer in größeren Unternehmen. Auf der anderen Seite ist es auch wichtig, dass der Prozess zur Unternehmenskultur passt, damit er auch gelebt wird. Auch für kleinere Unternehmen kann es interessant sein eine PowerApp für solche Vorgänge zu nutzen, wenn davon ausgegangen wird, dass das Unternehmen schnell wächst. 

Natürlich können auch andere Prozesse über die hier vorgestellten Wege abgebildet werden.  

Wenn Sie dazu Fragen haben, kommen Sie einfach auf uns zu. 

Active Directory TIERing – ganz oder gar nicht?

Ein nicht sauber gehärtetes Active Directory stellt heute eine leichte Beute für Angreifer dar. Um einen Angriff zu starten, wird zunächst Zugriff auf ein internes System benötigt. Dies kann z.B. über eine Verbindung mit einem öffentlich erreichbaren Terminal Server unter Verwendung von kompromittierten Benutzeranmeldedaten erfolgen. Angreifer lassen sich aber auch gerne in das Unternehmensnetz einladen, indem z.B. ein Anwender einen bösartigen E-Mail-Anhang öffnet und damit Schadcode innerhalb seiner Benutzersitzung ausführt. Mittlerweile laufen Angriffsverfahren teils vollautomatisiert ab. Damit schaffen es Angreifer oft, innerhalb kürzester Zeit bis auf die Domänencontroller vorzudringen und die komplette Domäne zu übernehmen. Danach hat der Angreifer die freie Wahl: Spionage, Daten vernichten, Daten verschlüsseln und Lösegeld erpressen, etc.

Um Angreifern das Ausbreiten im internen Netz („Lateral Movement“) und die Erlangung höher privilegierter Rechte („Privilege Escalation“) zu erschweren, hat Microsoft vor vielen Jahren ein Tiering Modell für das Active Directory entwickelt. Mit Einführung der Cloud Dienste wurde dieses Modell um entsprechende Cloud Elemente erweitert und in „Enterprise Access Model“ umbenannt (siehe Securing privileged access Enterprise access model | Microsoft Learn). Wer sich mit dem Thema schon mal beschäftigt hat, wurde wahrscheinlich von der Komplexität erschlagen und weiß nun nicht, wie das Thema angegangen werden kann und womit idealerweise anzufangen ist.

Wogegen schützen logische Schichten im AD?

Die saubere Trennung von logischen Schichten im AD erschwert einem Angreifer die Ausbreitung und die Erlangung höherer Rechte in der Konsolidierungsphase.

(Ablaufdiagramm aus: https://www.heise.de/news/Cybercrime-und-staatlichen-Hacker-Neue-Tools-und-Techniken-7324572.html?wt_mc=nl.red.ho.ho-nl-daily.2022-11-15.link.link)

Eine Aufteilung der Systeme in drei Schichten sieht üblicherweise so aus:

  • Tier 2: Workstations
  • Tier 1: Applikations-Server
  • Tier 0: Infrastruktur (z.B. Domain Controller, Storage, Virtualisierer, etc.)

Wenn ein Angreifer einmal in einer User Session auf einem Tier 1 Device Fuß gefasst hat, wäre ein beispielhafter weiterer Ablauf wie folgt denkbar. Dieses Beispiel ist zwar aus Sicht eines Angreifers sicherlich der „Best Case“, allerdings durchaus nicht praxisfern:

  1. Der Angreifer versucht, aus der User Session heraus das komplette System zu übernehmen.
    1. Der kompromittierte User ist lokaler Admin.
      1. Fertig – System übernommen!
    1. Der kompromittierte User ist kein lokaler Admin.
      1. Probleme in der User Session provozieren, damit der User den Helpdesk anruft und um Hilfe bittet.
      1. Der Helpdesk tippt innerhalb der User Session im Rahmen einer Remote Support Aktion die Credentials seines Helpdesk Accounts ein (z.B. via „run as“).
      1. Diese Credentials werden über einen vom Angreifer etablierten Key Logger abgegriffen.
      1. Fertig – System übernommen!
  2. Der Angreifer versucht, sich auf andere Systeme (Workstations) auszubreiten.
    1. Das lokale Admin-Kennwort ist auf allen Workstations identisch.
      1. Fertig – Alle Workstations übernommen!
      1. Tier 2 verloren!
  3. Der Angreifer möchte nun in den Besitz von höherwertigen Credentials kommen. Dafür reicht es, wenn sich ein solcher Account an einem kompromittierten Gerät anmeldet.
    1. Worst Case: Ein IT Mitarbeiter
      1. meldet sich mit einem Domain Admin Account an einem Client an, oder
      1. nutzt Domain Admin Credentials mittels „run as“, um aus seiner User Session heraus ein Admin Tool zu starten, oder
      1. meldet sich aus seiner User Session heraus via RDP-Client auf einem Drittsystem an und verwendet dabei Domain Admin Credentials,
      1. oder ähnliches…
    1. Ganz fertig – Domäne komplett übernommen!

Mit Tier 2 (Workstation Level) starten!

Da die überwiegende Mehrzahl der Angriffe über besuchte Web-Sites oder bösartige E-Mail-Anhänge erfolgen, sind die Workstations das größte Einfallstor und somit als erste abzusichern.

Das o.g. Beispiel zeigt recht deutlich, welches die wichtigsten Maßnahmen sind, um den Workstation Level (Tier 2) so abzusichern, dass Lateral Movement und Privilege Escalation erschwert werden.

  1. Ein automatisiertes Management der lokalen Administrator-Kennwörter auf den Workstations erschwert Lateral Movement (z.B. via LAPS, das mit dem April Update 2023 fest in das Betriebssystem wandert und nun auch Cloud-Umgebungen unterstützt, siehe: By popular demand: Windows LAPS available now! - Microsoft Community Hub)
    1. Individuelles Admin-Kennwort auf jedem Gerät.
    1. Admin-Kennwort wird regelmäßig automatisch geändert
  2. Entfernen weiterer Accounts und Gruppen aus der lokalen Gruppe der Administratoren auf allen Workstations (soweit möglich) erschwert Lateral Movement.
  3. Konfiguration von Logon Restrictions für Mitglieder privilegierter Gruppen erschwert Privilege Escalation. Somit können sich z.B. Domain Admins nicht mehr an Workstations anmelden.

Diese Maßnahmen sind relativ einfach und mit vertretbarem Aufwand durchführbar. Klar ist allerdings auch, dass in der Regel die bestehenden Workstation Support Prozesse nach der Umsetzung nicht mehr wie gewohnt funktionieren und entsprechend anzupassen sind.

Zusätzliche Maßnahmen sind innerhalb der Active Directory Struktur durchzuführen, um ggf. existierende „indirekte Kontrollpfade“ zu eliminieren. Beispielsweise würde eine indirekte Kontrolle über die Gruppe der Domain Admins gegeben sein, wenn folgendes Szenario zutrifft:

  • Es gibt eine OU im Active Directory, in der Standardbenutzerkonten einsortiert werden.
  • Für diese OU wurde eine Delegierung konfiguriert, dass der Helpdesk Benutzerkennwörter für Userobjekte unterhalb dieser OU zurücksetzen kann.
  • Ein Userobjekt unterhalb dieser OU ist Mitglied in der Gruppe Domain Admins.

Damit kann sich jeder Helpdesk-Mitarbeiter jederzeit einen Domain Admin Account verschaffen, indem er das Kennwort für das entsprechende User Objekt unterhalb der o.g. OU zurücksetzt und sich anschließend mit diesem Konto anmeldet.

Glücklicherweise gibt es Tools, die solche indirekten Kontrollpfade automatisch erkennen und dokumentieren können, so dass auch deren Beseitigung recht schnell und einfach erfolgen kann.

Damit ist die Separierung von Tier 2 (Workstations) in Kombination mit der notwendigen Active Directory Hygiene als absolutes Pflichtprogramm zu bezeichnen.

Wie weit muss ich gehen?

Die Aufwände für die Konzipierung, Implementierung und den Betrieb steigen mit jedem höheren TIER exponentiell an. Die Separierung von Tier 1 (Applikationsserver) ist bereits deutlich aufwändiger als für Tier 2, da hier in der Regel jeder Server / Service einzeln zu betrachten ist. Falls dann auch noch die Separierung von Tier 0 (Infrastruktur) erfolgen soll, müssen etliche Basis-Infrastruktur-Komponenten doppelt und getrennt nach Tier 1 und Tier 0 aufgebaut werden (Storage, Virtualisierung, Backup, etc.). Anders ist nicht zu verhindern, dass z.B. ein Tier 1 Virtualisierungsadmin Vollzugriff auf die Domäne erlangt, weil die Domain Controller mit auf dem Tier 1 Virtualisierer laufen.

Nachdem die Tier 2 Separierung als „Pflichtprogramm“ eingestuft ist, könnte man Tier 1 als „Empfehlung“ und Tier 0 als „Kür“ bezeichnen. Für wen allerdings welche Ausbaustufe zu empfehlen ist, hängt nicht nur von dem vorhandenen Etat ab, sondern auch von der eigenen Einschätzung, wie lohnenswert das eigene Unternehmen für Angreifer sein könnte. Soll heißen: Auch wenn unbegrenzte Geldmittel zur Verfügung stehen, möchte ich nicht jedem Unternehmen die Vollausbaustufe empfehlen. Denn mit steigender Ausbaustufe macht man es nicht nur den Angreifern bei einem Übernahmeversuch schwerer, sondern auch der eigenen IT – und zwar Tag für Tag. Unternehmen, die nach einem Erfolgreichen Hackerangriff von den Microsoft Consulting Services die große Blaupause verpasst bekommen haben, können ein Lied davon singen.

Die Zeit der klassischen Hacker ist vorbei, in der ein pickelgesichtiger, übergewichtiger Sonderling mit Kapuzenpulli in einem dunklen Keller zwischen leeren Pizzakartons an seinem Computer sitzt und manuell das Kennwort seines ausgewählten Opfers rät. Heute sind das hochprofessionelle und bestens organisierte Unternehmen, die Standardangriffe mit einem hohen Automatisierungsgrad gegen eine breite Masse von Unternehmen fahren. Dafür müssen diese Hacker-Organisationen viel Geld investieren, so dass sie einen hohen Wirkungsgrad benötigen, um den gewünschten Gewinn zu erzielen. Wenn es bei einem Unternehmen nicht auf Anhieb klappt, werden zunächst die anderen „Kunden“ in der Queue abgearbeitet. Damit ist es für Sie essenziell wichtig, besser aufgestellt zu sein als durchschnittlich üblich („Ich muss nicht schneller laufen als der Bär – ich muss nur schneller laufen als du“).

Also haben Sie mit der Implementierung von Tier 2 und des AD Hardenings schon den wichtigsten ersten Schritt getan, um vielen anderen Unternehmen das nötige Etwas vorauszuhaben. Als wie wertvoll die jeweiligen Kronjuwelen des Unternehmens einzustufen sind und ob es sich für Hacker lohnt, entsprechend mehr Aufwand zu spendieren, um die ersten Hürden zu überwinden, müssen Sie selbst beurteilen und ggf. weitere Hürden aufbauen.

Fazit

Beim Aufbau eines TIER Modells gibt es kein „ganz oder gar nicht“. Jeder Teilschritt ist ein Schritt in die richtige Richtung zur Etablierung einer höheren Sicherheitsstufe, um das Risiko von erfolgreichen Angriffen immer weiter zu senken.

Aber egal, wie weit Sie gehen wollen: Bitte seien Sie sich bewusst, dass es nicht ausreicht, ein Konzept zu erstellen und umzusetzen – man muss sich auch auf Dauer daran halten. Wenn eine Security Policy definiert wird, muss sie für alle gelten. Es gibt dann keine Ausnahmen – und schon gar nicht für „VIP-User“, die (bzw. deren Daten) ein ganz besonders lohnendes Angriffsziel sind. Das muss bereits in der Designphase berücksichtigt und mit dem Management abgestimmt werden. Im Betrieb muss die IT entsprechende Rückendeckung durch das Management erhalten, um sich gegen Sonderwünsche wehren zu können, die oft eine ganze Reihe von mühsam etablierten Maßnahmen aushebeln können. Es ist besser, nur Teile des TIER Modells zu implementieren und sich strikt an die bis dorthin erforderlichen Regeln zu halten, als ein mühsam aufgebautes Gesamtwerk durch „Praktikabilitäts-Shortcuts“ ad absurdum zu führen.

Ist es ein Vogel? Ist es ein Flugzeug? Nein, es ist das MDVM!

Hallo Allerseits,

gefühlt jeden Monat kommt ein neues Microsoft Defender Produkt auf den Markt. Da fällt es mitunter schwer, dieses technisch und fachlich zuordnen bzw. einschätzen zu können. Darüber hinaus kommt dann noch die Komplexität des Lizenz-Dschungels hinzu. In Sachen Lizenzen halte ich mich raus, hier müsst ihr die Machete selbst schärfen und euch durchkämpfen. Eine grobe Orientierung zum Lizenzthema beim Microsoft Defender Vulnerability Management (MDVM) findet ihr hier: Compare Microsoft Defender Vulnerability Management plans and capabilities | Microsoft Learn

Intro

Kommen wir zu den technischen Features. Das Microsoft 365 Defender Portal (https://security.microsoft.com/) ist die zentrale Security-Instanz für Unternehmen, welche Produkte aus dem Microsoft Defender Kosmos einsetzen. In diesem Portal werden die Daten von vielen Defender-Produkten angezeigt und miteinander verzahnt (MDI, MDE, MDO, MDCA, MDAV, um nur einige Produkt-Abkürzungen zu nennen). Früher mussten wir dazu viele verschiedene Portale übereinanderlegen und gegen das Licht halten, um die Zusammenhänge verschiedener Defender Produkte zu erahnen, heute wird dies zum Glück korreliert angeboten. Die jetzige Herausforderung liegt allerdings darin, in der schieren Menge an Informationen nicht unterzugehen.

Microsoft Defender Vulnerability Management (MDVM) ist eine Erweiterung für Microsoft Defender for Endpoint (MDE). Die neuen MDVM-Optionen integrierten sich in die altbekannte MDE-Optik. Die integrierte Verzahnung wird auch in der Lizenz-Vergleichsliste eindeutig (siehe Link). Ist keine Lizenz vorhanden, dann bemerkt man die nicht vorhandenen MDVM Features bei Betrachtung eines Computers (Registerkarte „Advanced features“) im „Device Inventory“:

Ist die Lizenz hingegen vorhanden, dann kommen verschiedene neue Features hinzu, welche ich hier kurz vorstellen mag. Zwingende Voraussetzung für MDVM ist das Onboarding der Endpoints (Clients + Server) in MDE.

MDVM Features

  1. Hardware + Firmwarebewertung
    Verschiedene Hardware-Faktoren (Laptop-, Desktop-, Servermodell-, Prozessor- und BIOS-Bestand) werden eingesammelt und seitens MDVM bewertet. Der Bestand und die Bewertungen können dann im Security Portal unter „Endpoints -> Inventories“ eingesehen werden. Durch die Bewertungen können Empfehlungen abgeleitet werden, wie z.B. Firmware- oder Treiberupdates einzuleiten. Die Notwendigkeit BIOS Firmware Updates durchzuführen, wurde uns in jüngster Vergangenheit wieder eindrucksvoll klargemacht.

2. Bewertung von Browsererweiterungen
Browsererweiterungen können ohne administrativen Kontext installiert werden. Sollte die Installation von Browsererweiterungen nicht zentral unterbunden werden, dann können Endanwender aus einem riesigen Portfolio an Erweiterungen frei wählen. Leider gibt es in diesem Umfeld auch ein paar schwarze Schafe. Hier hilft die Bewertung seitens MDVM, welches die Browsererweiterungen nach Kritikalität bewertet. Die zentrale Steuerung der erwünschten oder nicht erwünschten Browsererweiterungen ist somit die logische Konsequenz aus dieser Bewertung.


3. Bewertung durch Security Baselines
Security Baselines werden dazu verwendet, um den eigenen Gerätezoo mit branchenspezifischen Sicherheitsvergleichstests abzugleichen. Hierzu werden sogenannte Baselines verwendet, welche mit den Unternehmensrechnern (Clients + Server) verglichen werden. Abweichungen von diesen Baselines werden dann durch einen Konformitätsstatus dargestellt. Diese Baseline Bewertungen sind eine spannende Angelegenheit, wichtig sind natürlich die daraus resultierenden Umsetzungen von aufgezeigten Verbesserungsmöglichkeiten.

4. Bewertung des Zertifikatsbestands
Durch die Inventur des im Unternehmen vorhandenen Zertifikatsbestands können abgelaufene oder bald ablaufende Zertifikate identifiziert werden. Darüber hinaus können Sicherheitsrisiken z.B. aufgrund schwacher Signaturalgorithmen erkannt werden. Der daraus entstehende Arbeitsablauf ist aus meiner Sicht nicht zu unterschätzen, da hierfür gegebenenfalls verschiedene Zertifikatsspeicher bereinigt und erneuert werden müssen.


5. Anfällige Anwendungen blockieren
Das Blocken von anfälligen Anwendungen kann als Sofortmaßnahme verstanden werden. Damit kann den zuständigen Teams Zeit gegeben werden, potenziell anfällige Anwendungen zu patchen oder zu ersetzen. Hierzu wird eine Wartungsanforderung im Security Portal erstellt, welche dann z.B. die betroffene Anwendung auf eine Block-Liste setzt. Sobald die Wartungsarbeiten dann erledigt worden sind, kann die Anwendung wieder freigegeben werden.

6. Netzwerkfreigabeanalyse
Mit der Netzwerkfreigabeanalyse können sicherheitsanfällige Netzwerkfreigaben einfach identifiziert werden. Allein der Wildwuchs an Netzwerkfreigaben in größeren Netzwerkumgebungen ist häufig schon katastrophal. Wenn diese dann auch noch von Haus aus Schwachstellen aufweisen, ist dies ein gefundenes Fressen für Angreifer. Klasse sind die Sicherheitsempfehlungen, welche die Korrekturmaßnahmen direkt mitliefern.


7. Authentifizierter Scan für Windows
Ähnlich wie bei Defender for IoT oder der Netzwerkgeräteerkennung kommt hier ein zu installierender Scanner zum Einsatz. Dieser kann auf speziell dafür auserwählten Clients oder Servern installiert werden. Dieser Scanner wird dann dazu verwendet, um ungemanagte Geräte zu scannen und auf Softwarerisiken zu überprüfen. Die bessere Idee wäre natürlich, die betroffenen Geräte in einen gemanagten Zustand zu bringen.

Fazit

MDVM bringt aus meiner Sicht ein paar interessante Betrachtungen mit. Meine persönlichen Highlights sind die Kritikalitäts-Bewertungen der Browsererweiterungen, sowie der eingesetzten Firmwareversionen. Für sehr hilfreich halte ich auch die Netzwerkfreigabeanalyse, die wertvolle Ergebnisse und die dazugehörigen Korrekturmaßnahmen liefert.

Machen wir uns aber nichts vor: die Informationsmenge wird durch die MDVM Erweiterung noch weiter erhöht. Wer mit den Microsoft 365 Defender Produkten arbeiten will, der sollte gut organisiert sein, um den Benefit der aufgearbeiteten Daten auch gewinnbringend umsetzen zu können.

Die IT-Security-Szene ist gerade in den letzten Jahren auf Grund diverser Umstände sehr stark in Bewegung. Microsoft beweist durch die stetige Weiterentwicklung seiner Defender Produkte, hier durchaus mithalten zu können.

Produktwebseite: https://www.microsoft.com/en-us/security/business/threat-protection/microsoft-defender-vulnerability-management




Start-Reihenfolge von VMs unter Hyper-V: PowerShell to the rescue!

Wer heutzutage eine IT-Infrastruktur in den eigenen Räumlichkeiten (on-premises) betreibt, wird in den meisten Fällen auf die Virtualisierung setzen. Wenn wir hierbei auf das Microsoft-Produktportfolio blicken, lockt die Virtualisierung mit Hyper-V-Technologie. In vielen Fällen werden dann zur Erhöhung von Redundanz und Verwaltbarkeit Windows Failover Cluster mit Hyper-V eingesetzt.

Bei der Konkurrenz ist zum Beispiel VMware vSphere mit ESXi als Virtualisierer weit verbreitet – ebenfalls meist hochverfügbar ausgelegt (High Availability, HA).

Beim Betrieb von virtuellen Maschinen (VMs) besteht in der Betriebspraxis oftmals ein Interesse daran, Kontrolle darüber zu haben, in welcher Reihenfolge VMs starten (oder "failovern"). Weil es eben oft Abhängigkeiten der VMs untereinander gibt: Die Funktion eines SQL-Datenbank-Servers zum Beispiel hängt von einem betriebsbereiten Domain Controller (DC) ab. Ein Applikationsserver mag wiederum von SQL-Servern abhängen.

Unter Hyper-V gibt es in der grafischen Verwaltungsoberfläche (Failover Cluster Manager, FCM bzw. Hyper-V Manager) ein paar Möglichkeiten, Einfluss auf den Start von VMs bzw. im Falle eines Failovers auf einen anderen Knoten (Node) im Cluster zu nehmen.

Diese "Start Priority" bietet aber in der GUI nur recht wenige Optionen zur Ausgestaltung. Entweder stuft man die Start-Prio der VM als High, Medium oder Low ein oder man verzichtet auf den automatischen Start der VM gänzlich. Über die PowerShell kann man zwar hier die Abstufung der Priorität auch granularer wählen – aber welche VMs nun Voraussetzung für den erfolgreichen Betrieb anderer VMs sind, lässt sich auch damit bei mehr als einer Hand voll VMs kaum sinnvoll regeln.

Bei der VMware-Konkurrenz bieten sich in der entsprechenden GUI (vCenter) da mehr Möglichkeiten, um auch Abhängigkeiten von VMs untereinander zu modellieren.

Selbst in den neueren Versionen des Windows Servers bleiben den Administratoren in der GUI solcherlei weitergehende Eingriffsmöglichkeiten verwehrt. Und neidisch schielt man auf die Konkurrenz. Es gibt aber durchaus eine – u. a. durch Nicht-Sichtbarkeit in der GUI wenig beachtete – Möglichkeit, hier präzisere Stellschrauben zu benutzen: Schon seit Windows Server 2016 gibt die PowerShell da ein logisches Konstrukt her, mit dem man dem Hyper-V-Cluster in Bezug auf diese Modellierung auf die Sprünge helfen kann. Das Stichwort heißt hier: ClusterGroupSet.

Die Dokumentation dazu ist dürftig, die Logik etwas sperrig und die Nomenklatur eigenwillig. Wenn man die vor allem zu Beginn so störenden Hürden aber überwindet, hat man durchaus ein nützliches Werkzeug an der Hand.

Wie funktioniert das also nun? Die Idee basiert auf den ClusterGroupSets und der ClusterGroupSetDependency. Im Kommandozeilen-Cluster-Sprech sind VMs (bzw. das, was VMs im Cluster ausmacht) eigentlich ClusterGroups. Da hier der Begriff der Group im Cluster also schon reserviert ist, heißen die Gruppierungen, die wir hier und jetzt betrachten eben ClusterGroupSets. Diese Sets beinhalten die ClusterGroups (die VMs) als Mitglieder. So gesehen steckt man nun also VMs in diese Sets. Mit den zugehörigen Dependencies lassen sich nun die Abhängigkeiten abbilden. Dazu gibt man bei der ClusterGroupSetDependency für ein ClusterGroupSet einen "Provider" an. Mit Provider ist hier konkret dasjenige ClusterGroupSet gemeint, von dem das mittels Provider konfigurierte nun denn abhängen soll. Am besten ein Beispiel: Sieben VMs, nämlich drei DCs (DC01 bis DC03), zwei SQL-Server (SQL01, SQL02), zwei AppServer (AppSrv01 und AppSrv02). Die beiden App-Server hängen von den SQL-Server-VMs ab und diese wiederum von mindestens zwei der drei DC-VMs.

Im Bild die zugehörigen PowerShell-Befehle:

Wir erstellen zuerst die "Gruppierungen", also die ClusterGroupSets, wie zum Beispiel die DomainControllers. Dann stecken wir die VMs, repräsentiert durch die "Group", in das jeweils passende Set hinein.

Zuletzt geben wir an, dass das Set für die AppServers von dem Set für die SQLServers abhängt und dieses wiederum von den DomainControllers. Die Abhängigkeiten und die logische Verschachtelung sind damit gebaut.

Nun noch ein paar Details: StartupDelayTrigger und StartupCount. Die Option "Delay" beim Trigger bedeutet, dass auf den Heartbeat gewartet wird – und dann erst die Zeit für den Delay (StartupDelay) zum Start abhängiger Sets losläuft. Die Option "online" beim Trigger bedeutet, dass es bereits dann weitergehen darf, wenn die VM-Rollen überhaupt erfolgreich gestartet wurden, aber ebenfalls erst nach Ablauf eines StartupDelay.  Beim ein oder anderen mag das nicht dem ersten Instinkt zur Bedeutung der Optionen entsprechen.
Die Anzahl beim StartupCount gibt für das Set an, wie viele der enthaltenen VMs zur Erfüllung der Regeln laufen müssen.

Hier im Beispiel also sollen zwei der drei DCs laufen, um als ausreichend vollständig laufendes Set zu gelten. Es empfiehlt sich, zumindest für das letzte Set in der Kette der Abhängigkeiten diesen Wert auf die Anzahl der enthaltenen VMs zu setzen, um das recht eigenwillige Verhalten beim Starten der zweiten AppServers-VM zu vermeiden. Die genaue Logik dahinter wird bestimmt wohlbegründbar sein, scheint aber wohl anfangs schwer zu durchschauen.

Für eigene Tests sei empfohlen, auf dem Beispiel aufzubauen.

Nun das Resultat im einfachsten Szenario also im Bild: Wenn alles ausgeschaltet ist und wir schalten über den FCM eine der AppServers-VMs (z. B. AppSrv01) ein, dann startet diese zunächst nicht direkt, sondern wirft zuerst das Set am Ende der Abhängigkeitskette mit den DCs an. Noch laufen ja nicht ausreichend viele.  Da das ganze Set gestartet wird, werden kurz danach im Allgemeinen also drei DCs laufen. Das sind genug zur Erfüllung der Regeln für dieses Set. Dann starten, nach einem (einstellbaren) Verzug von 20 Sekunden (so der Default für den StartupDelay) auch die SQL-Server-VMs. Wenn beide laufen, darf dann auch der AppSrv01 wirklich starten... so soll es sein.

Fazit:

Microsoft sorgt durch Weglassen eines GUI-Zugriffs und bestenfalls mäßige Dokumentation durchaus selbst dafür, dass die ClusterGroupSets weniger bekannt oder in Vergessenheit geraten sind. Ob das Zeichen für technische Schwierigkeiten MS-seitig bei der Umsetzung sind oder man gar überhaupt auf das Feature setzen sollte, mag sicherlich kontrovers diskutiert werden. Wer auf eine genauere Regelung der Startreihenfolge von VMs im Cluster Wert legt, sollte sich aber ruhig einmal mit den Möglichkeiten rund um dieses Feature durch Testing beschäftigen und entscheiden, ob dies zur produktiven Nutzung in der eigenen Hyper-V-Welt in Frage kommt.

Wer das zum Einsatz vorsieht, sollte aber über etwas Frustrationstoleranz verfügen und die Admin-Kollegen mit einbeziehen: Wenn man VMs im Cluster starten möchte, und stattdessen starten andere (nur manchmal genau diejenige nicht, die man wollte), rauft man sich schnell die Haare, wenn man so gar nicht ahnt, wo das Verhalten herkommt.

Viel Erfolg bei eigenen Experimenten!