Blog
Informativ, aktuell und spannend - der Oneconsult Cybersecurity Blog.
GPO Hardening: Die wichtigsten GPO-Einstellungen zum Härten

Das Härten von Systemen ist immer wieder ein Thema. Viele, die sich erst neu damit befassen, sind von einem Sicherheitsvorfall betroffen. Oneconsults Incident Response Team hilft Unternehmen dabei, solche Vorfälle, genannt Incidents, zu bewältigen.

Bei diversen solcher Incidents sowie in Kundenprojekten konnten verschiedene Probleme mit dem Härten festgestellt werden. Zum einen ist oft eine Ressourcenknappheit gegeben, um die vielen Leitfäden, Tipps und Standards zu sichten und zu adaptieren. Zum anderen ist die Infrastruktur bereits gewachsen, ohne dass Härten eine Rolle gespielt hat. Dies macht es schwierig, Härtungsmassnahmen «einfach schnell» umzusetzen, da danach – fast garantiert – ein Dienst nicht mehr richtig ausgeführt wird.

Um dem entgegenzuwirken, werden in diesem Artikel die wichtigsten GPO-Einstellungen (Group Policy Object) aus der Perspektive der IT-Sicherheit zusammengefasst. Sie repräsentieren eine Zusammenfassung der aus persönlicher Praxiserfahrung wichtigsten Härtungsmassnahmen, die jeder per GPO verteilen kann bzw. sollte. Zudem wird auf mögliche Auswirkungen eingegangen, die die entsprechenden Richtlinien verursachen könnten. Grundsätzlich gilt immer: Nichts umsetzen, ohne es zu testen. Am besten dafür geeignet sind Testumgebungen. Nicht jeder Admin hat jedoch einen solchen Luxus parat. Auch eine Untergruppe von Geräten und Server, die nicht allzu kritisch sind, können dabei herangezogen werden. Der Vorteil bei GPOs ist, dass sie bei unerwünschtem Verhalten schnell wieder entfernt werden können. Der Nachteil liegt allerdings darin, dass zunächst herausgefunden werden muss, welche der vielen Einstellungen das Fehlverhalten verursacht hat.

Hardening mit GPOs

UAC

Die UAC (User Account Control) schützt vor allem die privilegierten Benutzerkonten. Manchmal wird bei einem Einsatz entdeckt, dass für Administratoren die UAC komplett deaktiviert wurde. Eine Schadsoftware, die durch einen Admin gestartet wurde, konnte sich danach uneingeschränkt auf dem System und meistens auch darüber hinaus ausbreiten. Die UAC verhindert das standardmässige Starten von Programmen mit erhöhten Berechtigungen, indem eine Bestätigung oder eine erneute Eingabe des Passworts angefordert wird. Ausserdem kann die UAC «Lateral Movement» (die Ausbreitung im Netzwerk) unter Umständen verhindern, da sie über das Netzwerk keine Verbindungen von lokalen Administratoren zulässt. Die Bedingung: Sie muss richtig konfiguriert werden.

Die folgenden empfohlenen Einstellungen zur Benutzerkontensteuerung werden in Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options\User Account Control: [verschiedene Einstellungen] vorgenommen:

Einstellung Wert
User Account Control: Admin Approval Mode for the Built-in Administrator account Enabled
User Account Control: Only elevate UIAccess applications that are installed in secure locations Enabled
User Account Control: Behavior of the elevation prompt for administrators in Admin Approval Mode Prompt for consent on the secure desktop
User Account Control: Behavior of the elevation prompt for standard users Automatically deny elevation requests
User Account Control: Detect application installations and prompt for elevation Depending on use case *
User Account Control: Allow UIAccess applications to prompt for elevation without using the secure desktop Disabled
User Account Control: Run all administrators in Admin Approval Mode Enabled
User Account Control: Switch to the secure desktop when prompting for elevation Enabled
User Account Control: Virtualize file and registry write failures to per-user locations Enabled

* Siehe: https://technet.microsoft.com/de-de/library/dd851376(v=ws.11).aspx

LDAP-Signierung

Ist LDAP Signing eingeschaltet, werden alle LDAP-Pakete signiert versendet. Das bedeutet: Der Empfänger der LDAP-Pakete kann sicherstellen, dass die Kommunikation mit der richtigen Stelle erfolgt. Ein Client kann somit überprüfen, ob die LDAP-Antworten vom Domänencontroller stammen, nicht verändert wurden und vice versa. Das erschwert vor allem Replay-Attacken, wobei ein Angreifer versucht, alte, aufgezeichnete Kommunikation wiederzuverwenden oder aber Man-in-the-Middle-Attacken, wobei sich ein Angreifer zwischen Client und Server in die Kommunikation einklinkt.

Weiter sollten «LDAP Channel Binding Token» verwendet werden. Dieses verstärkt die Sicherheit bei der Authentifizierung am Active Directory per LDAPs.

Mögliche Auswirkungen kann es vor allem bei alten Systemen geben, die nicht mit LDAP Signing umgehen können. An solchen können sich Domänenbenutzer nicht mehr anmelden und Dienste können nicht mehr richtig funktionieren oder starten, wenn sie unter einem Domänenkonto gestartet wurden. Um herauszufinden, ob es solche Systeme im Netzwerk gibt, kann ein Log konfiguriert werden, welches simple LDAP-Anfragen erkennt und rapportiert. Dazu muss in der Registry auf dem Domänencontroller unter dem Schlüssel HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics folgender Wert eingestellt werden:

  • «16 LDAP Interface Events», Wert: 2

Somit wird die Event ID 2889 im Event Viewer angezeigt, wenn ein Client LDAP Signing nicht unterstützt.

Beim Channel Token unterstützen OS-Versionen wie Windows Server 2008 oder ältere Versionen LDAP Signing nicht. Für die 2008er-Linie gibt es Updates, welche die Funktion nachrüsten.

Die empfohlene Einstellung für Server und Client:

  • Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > Security Options > Domain controller: LDAP server signing requirements

Setzen auf: Require signing

  • Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > Security Options > Network security: LDAP client signing requirements

Setzen auf: Require signing

  • Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > Security Options > Domain controller: LDAP server channel binding token requirements

Setzen auf: Always

SMB-Signierung

SMB Signing hat im Prinzip dasselbe Ziel wie LDAP Signing. Es soll verhindert werden, dass ein Angreifer sich in die Kommunikation zwischen Client und Server schalten oder die aufgezeichnete Kommunikation später für einen Angriff wiederverwenden kann. Auch hier wird es zu Problemen kommen, wenn alte Systeme SMB Signing nicht unterstützen. Ein weiteres Problem könnte die Performance betreffen. Bei normalem 1GB-Ethernet und moderner CPU werden Benutzer kaum etwas merken. Wird hingegen eine 10GB-Leitung mit entsprechend hohem Durchsatz eingesetzt, können Performance-Einbussen durch SMB Signing spürbar sein.

Die empfohlenen Einstellungen für Server und Clients:

  • Computer Configuration > Windows Settings > Security Settings > Local Policies > Security Options > Microsoft network client: Digitally sign communications (always)

Setzen auf: Enabled

  • Computer Configuration > Windows Settings > Security Settings > Local Policies > Security Options > Microsoft network server: Digitally sign communications (always)

Setzen auf: Enabled

Alternativ könnte folgende Einstellung bevorzugt werden, wenn mindestens teilweise unsignierte Kommunikation benötigt wird:

  • Computer Configuration > Windows Settings > Security Settings > Local Policies > Security Options > Microsoft network client: Digitally sign communications (if server agrees)

Setzen auf: Enabled

  • Computer Configuration > Windows Settings > Security Settings > Local Policies > Security Options > Microsoft network server: Digitally sign communications (if client agrees)

Setzen auf: Enabled

SChannel-Signierung

Die SChannel (Secure Channel) werden verwendet, wenn Domänencontroller untereinander replizieren sowie bei der Kommunikation mit Clients, wenn sicherheitsrelevante Vorgänge, wie etwa Authentisierung, durchgeführt werden. Um Angriffe darauf zu verhindern, kann die Kommunikation verschlüsselt und/oder signiert übertragen werden. Dabei gibt es, wie bei SMB Signing, die Option, Verschlüsselung und/oder Signierung nur wenn möglich einzusetzen. Alte Betriebssysteme oder Nicht-Microsoft-Clients können unter Umständen beim Forcieren der Einstellung nicht mit dem Domänencontroller oder dem gewünschten Dienst kommunizieren.

Folgende Einstellung wird empfohlen:

  • Computer Configuration > Windows Settings > Security Settings > Local Policies > Security Options > Domain member: Digitally encrypt or sign secure channel data (always)

Setzen auf: Enabled

Alternative Einstellung:

  • Computer Configuration > Windows Settings > Security Settings > Local Policies > Security Options > Domain member: Digitally encrypt or sign secure channel data (if client agrees)

Setzen auf: Enabled

NTLMv2 ohne alte Protokolle

In einer Domäne wird zur Authentisierung standardmässig Kerberos verwendet. In einigen Fällen ist dies nicht möglich oder es wird wegen einer falschen Konfiguration nicht verwendet. In solchen Fällen wird LM (LAN Manager), NTLM (New Technology LAN Manager) oder NTLMv2 (New Technology LAN Manager Version 2) verwendet. NTLMv2 wird seit Windows 2000 nativ unterstützt. Die älteren Protokolle, vor allem LM, haben Schwachstellen in ihrer Konstruktion, weshalb davon abgeraten wird, sie weiter zu verwenden. Da NTLMv2 weit verbreitet ist und seit längerer Zeit unterstützt wird, sollte es keine grossen Probleme bei der Umsetzung geben.

Folgende Einstellung wird empfohlen:

  • Computer Configuration > Windows Settings > Security Settings > Local Policies > Security Options > Network security: LAN Manager authentication level

Setzen auf: Send NTLMv2 responses only. Refuse LM & NTLM

CPasswords entfernen

In den GPPs, den Group Policy Preferences, können Passwörter hinterlegt werden. GPPs sind der Teil der GPOs, in denen Laufwerkszuordnungen, Kopieren von Dateien, Setzen von Umgebungsvariablen usw. aber auch Benutzer inkl. Passwörter angelegt werden können. In der Group Policy gespeicherte Passwörter können von einem Angreifer einfach ausgelesen werden. Die Geheimnisse stehen zwar nicht im Klartext zur Verfügung, jedoch ist der Schlüssel, den Microsoft zum Schutz der Daten einprogrammiert hat, allgemein bekannt. Meistens gibt es andere Lösungen, die zum Ziel führen, ohne dass ein Passwort in den GPPs gespeichert werden muss.

Ein weit verbreitetes Problem ist die Verwaltung der lokalen Administratoren auf den Servern und Clients. Oft wird per Voreinstellung überall dasselbe Passwort verwendet oder es wird ein Benutzer per GPP angelegt, was zum selben Resultat führt. Besser wäre die Verwaltung der lokalen Administratoren per LAPS (Local Admin Passwort Solution). LAPS ist ein kleines Tool von Microsoft genau für diesen Zweck. Man kann damit per GPO steuern, welches lokale Admin-Konto gemäss den ebenfalls definierbaren Regeln verwaltet werden soll. Dabei wird der Client für den entsprechenden Account ein Passwort generieren und dieses auf dem Domänencontroller in ein neues Feld des jeweiligen Computerobjekts schreiben. Dieses Feld können nur Domänenadministratoren lesen. So erhält jedes lokale Administratorenkonto ein eigenes, sicheres Passwort. Bei Verwendung kann ein Domänen-Admin, am einfachsten per PowerShell, das Passwort aus dem Active Directory auslesen.

Für die Verwendung von LAPS ist die Installation der Management Tools auf dem AD-Server, einer Schemaerweiterung für die neuen Felder sowie neuer GPO-Vorlagen nötig. Auf den Clients wird eine GPO Extension installiert. Bei der nächsten Synchronisation der Richtlinien wird der Client die Einstellungen zu LAPS lesen und umsetzen.

Die genaue Installationsanleitung, Dokumentation und der Download sind bei Microsoft zu finden.

Oneconsult empfiehlt, keine Passwörter in den GPPs und GPOs zu speichern, sondern eine andere Lösung zu finden.

Passwortrichtlinie

Zum Thema Passwortrichtlinie gibt es im Internet genügend Ressourcen. Sie beziehen sich jedoch nicht immer auf dieselbe Ausgangslage. So wird zum Beispiel empfohlen, keine Komplexitätsanforderungen an Benutzerpasswörter zu stellen, aber sie dafür gegen eine möglichst umfassende Blacklist zu prüfen. Auf einem On-Premises-Domänencontroller können die Passwörter nicht gegen eine Blacklist geprüft werden. In einer Cloud hingegen können solche neuen Ansätze verfolgt werden. Manchmal sind die Empfehlungen für einen Webshop oder andere Websites gedacht und entsprechen nicht den Anforderungen und Gegebenheiten einer Active Directory-Umgebung. Weiter gilt Vorsicht, wenn aus einer Empfehlung nur einzelne Punkte herausgesucht und umgesetzt werden. Dieses Vorgehen kann die Passwortrichtlinie schwächen.

Eine gute Orientierung bietet der CIS (Center for Internet Security) Password Policy Guide. Er beschreibt verschiedene Sachverhalte verständlich und klärt über verschiedene Angriffsszenarien auf. Entgegen der Passwortrichtlinie von CIS empfiehlt Oneconsult für normale Benutzer (mit 2FA) eine Passwortlänge von mind. 10 Zeichen anstatt 8.

Neben dem Link zum CIS Password Policy Guide empfiehlt sich der Beitrag meines Kollegen, der die gesamten Passwort-Hashes eines Unternehmens erhalten hatte, um sie zu knacken – also um die Passwörter im Klartext herauszufinden. Es ist lehrreich und interessant zugleich, zu welchen Resultaten das Audit führte:

Remote Credential Guard

In modernen Umgebungen mit Windows 10 und Server 2016 oder höher kann für RDP-Verbindungen Remote Credential Guard aktiviert werden. Bei Verbindungen zum RDP Host werden die Credentials oder Teile davon nicht mehr an den Host gesendet, welcher sie lokal im Cache ablegen würde. Ein Angreifer, der einen Host kompromittieren konnte, kann so nicht weitere Benutzerkonten abgreifen, nur weil sie sich auf das System verbinden. Vor allem dort, wo Support per RDP geleistet oder RDP auch für Verbindungen zu DMZ-Servern benutzt wird, ist Remote Credential Guard sinnvoll.

Microsoft hat dokumentiert, wie Remote Credential Guard eingerichtet werden kann und welche Voraussetzungen erfüllt werden müssen.

Werden die Anforderungen von Microsoft erfüllt und wird der Einsatz von Credential Guard vor dem Ausrollen getestet, sollten keine Probleme auftauchen. Wichtig bei der Umsetzung ist das genaue Studieren der Dokumentation von Microsoft, um alle Bedingungen zu erfassen.

NLA einschalten

Wird NLA (Network Level Authentication) eingesetzt, findet die Authentisierung bei RDP bereits beim Verbindungsaufbau statt anstatt erst danach. Eine Verbindung kommt nur dann zustande, wenn sich der Benutzer entsprechend erfolgreich anmelden kann. Auf diese Weise können Angreifer und Viren Sicherheitslücken weniger gut ausnutzen und nicht unberechtigt Informationen abgreifen, die auch vor einem Login verfügbar sind (etwa angemeldete Benutzer). So konnte z.B. der Befall durch den Computerwurm Bluekeep [1] per NLA verhindert werden. Bei einer Umsetzung sollten in den seltensten Fällen Probleme auftauchen. Unterstützt wird NLA seit Windows XP SP3 und Server 2008. Zu beachten wäre, dass Benutzer, die ihr Passwort ändern müssen, sich nicht wie gewohnt per RDP anmelden und dann ihr Passwort ändern können. Die Verbindung würde beim Einsatz von NLA fehlschlagen. Weiter ist die Authentisierung mit Smartcard bei domänenübergreifenden Verbindungen nicht möglich.

Folgende Einstellung wird empfohlen:

  • Computer Configuration > Administrative Templates > Windows Components > Remote Desktop Services > Remote Desktop Session Host > Security > Require user authentication for remote connections by using Network Level Authentication

Setzen auf: Enabled

Log-Grösse des «Security Log»

Die Security Log-Grösse, insbesondere auf Domänencontrollern, ist standardmässig viel zu klein eingestellt. Bei Incidents mussten wir oft erfahren, dass wir zur Aufklärung des Vorfalls nur spärliche Log-Daten haben, die zwei bis vier Stunden in die Vergangenheit reichen. Auch schon bei kleineren Unternehmen fallen auf dem Domänencontroller viele Log-Daten an, die bei Erreichen der eingestellten Log-Grösse wieder überschrieben werden. Wie gross das Security Log nun sein sollte, ist je nach Unternehmen, Anforderungen und Audit Policy individuell. Ein Anfang wäre, die Log-Daten vom Security Log auf allen Servern und Clients für drei Monate verfügbar zu machen.

Daher wird folgendes Vorgehen empfohlen:

  1. Security Log öffnen, momentane Grösse notieren.
  2. Den ältesten verfügbaren Log-Eintrag suchen.
  3. Per Dreisatz ausrechnen, wie gross das Log sein müsste, um mindestens drei Monate in die Vergangenheit zu reichen
  4. Geschätzte Log-Grösse per GPO einstellen: Computer Configuration > Windows Settings > Security Settings > Local Policies > Security Options > Security: Specify the maximum log file size (KB)
  5. Nach drei Monaten kontrollieren, ob das Datum des ältesten Log-Eintrags der Erwartung entspricht.

PowerShell Script Block Logging einschalten

PowerShell ist ein mächtiges Werkzeug, das gerne von Admins sowie auch von Angreifern verwendet wird. Um nachvollziehen zu können, wer wann welchen Befehl oder welches Script ausgeführt hat, sollten alle ausgeführten Befehle geloggt werden. Probleme oder aber Angriffe, bei denen PowerShell eine Rolle spielt, können so entdeckt und nachvollzogen werden.

PowerShell Script Block Logging kann per GPO eingestellt werden:

  • Computer Configuration > Administrative Templates > Windows Components > Windows PowerShell > Turn on PowerShell Script Block Logging

Auf Enabled setzen und «Log script block invocation start/stop events» auswählen.

Audit-Policy erstellen

Bei vielen Incidents wird festgestellt, dass neben der kurzen Speicherzeit der Log-Daten die vorhandenen Daten eher spärlich ausfallen. Um einen Vorfall aufzuklären, müssen zum Teil die verschiedensten Logs herangezogen und korreliert werden. Ein grosser Teil wird unter Windows standardmässig nicht aufgezeichnet und muss erst konfiguriert werden. Eine gute Empfehlung ist, im Unternehmen zunächst zu überlegen, was man wissen möchte. Folgend ein paar Fragen zur Anregung:

  • Will man sehen können, wer sich wann wo eingeloggt hat?
  • Wer hat wann auf die wichtigen Firmengeheimnisse auf der Freigabe zugegriffen?
  • Wer hat welche Änderungen im Active Directory vorgenommen?
  • Welche PowerShell-Befehle wurden ausgeführt?
  • Welche Prozesse wurden gestartet? Wann und von wem?

Wie man sieht, gibt es viele interessante Fragen. Auf der darauf basierenden Audit Policy kann später eine einfache Auswertung, ein SIEM (Security Information and Event Management) oder gar ein SOC (Security Operation Center) aufgebaut werden. Bei den Einstellungen gibt es grundsätzlich kein richtig oder falsch. Es ist ein Abwägen zwischen dem, was man wissen möchte, und der Log-Grösse bzw. Anzahl der Log-Einträge, die beachtliche Ausmasse erreichen können. Schlecht ist nur, sich darüber nie Gedanken zu machen. Am Anfang muss es nicht gleich ein SOC sein. Bei Incidents sind die Forensiker und Incident Responder bereits froh, wenn überhaupt Log-Daten vorhanden sind.

Die verschiedenen Einstellungsmöglichkeiten sind unter folgendem Pfad zu finden:

  • Computer Configuration\Policies\Windows Settings\Security Settings\Advanced Audit Policy Configuration\Audit Policies

Einen guten Einstieg bietet dieses Cheat Sheet.

Benutzern das Hinzufügen neuer Geräte zum Active Directory verbieten

Ist bekannt, dass standardmässig jeder Benutzer bis zu fünf Geräte mit seinem normalen Domänenbenutzer der Domäne hinzufügen kann? Neue Geräte in die Domäne aufzunehmen ist kein Privileg von Domänenadministratoren, ausser es wird so konfiguriert. Die durch Benutzer neu hinzugefügten Geräte werden der Sicherheitsstrategie des Unternehmens in den seltensten Fällen entsprechen. So werden sie z.B. nicht über die zentrale Verwaltung des Antivirenprogramms erfasst, haben womöglich keine aktive BitLocker-Verschlüsselung oder sind bereits mit Viren verseucht. Eine Schatten-IT, die sogar der Domäne angehörig ist – davon träumt wohl kein Admin.

Das Hinzufügen von neuen Geräten zur Domäne kann nur für Administratoren erlaubt werden:

  • Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > User Rights Assignment Add workstations to domain

Setzen auf: Administrators

Weiterführende Quellen und Massnahmen

Zum Thema Härten per GPO gibt es im Internet viele Quellen. Folgend zwei Ressourcen, die in der Oneconsult oft Verwendung finden:

Weitere Einstellungen

Zusätzlich zu den in den vorherigen Kapiteln genannten Einstellungen sind die nachfolgenden Massnahmen zu nennen, die sich nicht direkt oder nicht nur per GPO einstellen lassen und dennoch zur Basis beim Härten gehören.

LLMNR und NetBIOS deaktivieren

LLMNR (Link-Local Multicast Name Resolution) und NetBIOS sind Protokolle zur Namensauflösung in Adhoc-Netzwerken, bei denen kein DNS-Server zum Einsatz kommt. Anfragen per LLMNR oder NetBIOS werden an das ganze Netzwerk versendet. Antworten werden nicht auf Authentizität überprüft. Angreifer können diesen Mechanismus ausnutzen, indem sie solche Abfragen abhören und Antworten fälschen – und so das Opfer dazu bringen, bösartigen Servern zu vertrauen.

Falls LLMNR und NetBIOS nicht zum Einsatz kommen, sollten die Protokolle deaktiviert werden:

  • Local Computer Policy > Computer Configuration > Administrative Templates > Network > DNS Client > Turn Off Multicast Name Resolution

Setzen auf: Enabled

NetBIOS kann nicht auf einfachem Weg per GPO deaktiviert werden. Es muss pro Adapter abgeschaltet werden. Wirklich nützlich ist das vor allem bei Servern, bei denen der Adapter nicht wechselt. In der Registry wird folgende Einstellung vorgenommen:

  • HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NetBT\Parameters\Interfaces\\NetbiosOptions

Setzen auf: 2

WPAD deaktivieren

WPAD (Web Proxy Autodiscovery) ist ein Protokoll zur automatischen Proxykonfiguration. Es kann, je nach Netzwerk, Man-in-the-Middle-Attacken begünstigen. Auf Servern, die in der Regel in statischen Netzwerken installiert werden, kann der Proxy fix konfiguriert und WPAD abgeschaltet werden. Auf Clients, die die Funktion nicht benötigen, sollte WPAD ebenfalls deaktiviert werden.

WPAD sollte auf Servern und den Clients, die WPAD nicht benötigen, deaktiviert werden:

  • In der Systemsteuerung muss bei der Einstellung des Proxys «Automatically detect settings» auf «Off» gestellt werden.
  • Zudem muss der folgende Registry Key gesetzt werden:
    • HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WinHttpAutoProxySvc
    • Wert von «Start» von 3 (manuell) auf 4 (deaktiviert)

Fazit

Am besten funktioniert das Härten von Systemen, wenn der IT-Sicherheitsgedanke bereits von Anfang an in den Prozessen wiederzufinden ist und nicht erst am Schluss oder nach Incidents nachgeholt wird. Werden neue Clients, Dienste und Server ausgerollt und aufgebaut, sollte IT-Sicherheit bereits bei der Konzeptionsphase eine Rolle spielen. Wenn die Vorgaben an die Sicherheit von Anfang an gegeben sind, macht die Umsetzung generell weniger Probleme. Die genannten GPOs können dabei eine gute Grundlage bilden, um ein Basisniveau an Hardening zu erreichen. Natürlich ist das Härten von Systemen nicht nur auf GPOs zu beschränken und auch bei den Richtlinien gibt es unzählige Einstellungen, welche die Sicherheit eines Netzwerks erhöhen können und hier nicht behandelt wurden. Folgt man den weiterführenden Links, sind viele nützliche Informationen und Tools zu finden, die beim Absichern der Clients, Server und der ganzen Umgebung unterstützen können.

Kennen Sie weitere GPOs, die Sie zu den «wichtigsten» zählen? Schreiben Sie mir Ihre Meinung an marco.wohler(at)oneconsult.com.

Über den Autor

Marco Wohler ist seit November 2014 für den reibungslosen Betrieb der unternehmensinternen IT-Infrastruktur der Oneconsult verantwortlich. Er leitet seit Oktober 2016 das IT-Team. In dieser Funktion konzipierte und implementierte Marco Wohler mit seinem Team die verschiedenen Generationen der IT-Infrastruktur. In Kundenprojekten und intern sammelte er umfassende Erfahrungen in der Verteidigung von Systemen und Unternehmen. Als Gegenpol zu den Penetration Testing Teams, die sich auf Angriffsszenarien ausrichten, ist Marco Wohler ein gefragter Spezialist für die Absicherung von IT-Systemen. Er ist GIAC Certified Enterprise Defender (GCED) und zertifizierter OSSTMM Professional Security Tester (OPST).

Über Oneconsult

Die Oneconsult-Unternehmensgruppe ist seit 2003 Ihr renommierter Schweizer Cybersecurity Services Partner mit Büros in der Schweiz und Deutschland und 2000+ weltweit durchgeführten Security-Projekten.

Erhalten Sie kompetente Beratung vom inhabergeführten und herstellerunabhängigen Cybersecurity-Spezialisten mit 40+ hochqualifizierten Cybersecurity Experten, darunter zertifizierte Ethical Hacker / Penetration Tester (OPST, OPSA, OSCP, OSCE, GXPN), IT-Forensiker (GCFA, GCFE, GREM, GNFA), ISO Security Auditoren (ISO 27001 Lead Auditor, ISO 27005 Risk Manager, ISO 27035 Incident Manager) und dedizierte IT Security Researcher, um auch Ihre anspruchsvollsten Herausforderungen im Informationssicherheitsbereich zu bewältigen. Gemeinsam gehen wir Ihre externen und internen Bedrohungen wie Malware-Infektionen, Hacker-Attacken und APT sowie digitalen Betrug und Datenverlust mit Kerndienstleistungen wie Penetration Tests / Ethical Hacking, APT Tests unter Realbedingungen und ISO 27001 Security Audits an. Bei Notfällen können Sie rund um die Uhr (24 h x 365 Tage) auf die Unterstützung des Digital Forensics & Incident Response (DFIR) Expertenteams von Oneconsult zählen.

www.oneconsult.com

Publiziert am: 05.01.2021

Teilen

Nie mehr Aktuelles über Cyber-Security-Themen verpassen? Dann abonnieren Sie jetzt unseren Newsletter

Autor

Keine Beschreibung verfügbar.

Nichts verpassen! Melden Sie sich für unseren kostenlosen Newsletter an.

Ihre Sicherheit hat höchste Priorität – unsere Spezialisten unterstützen Sie kompetent.

Erreichbarkeit von Montag bis Freitag 08.00 – 18.00 Uhr (Ausnahme: Kunden mit SLA – Bitte über die 24/7 IRR-Notfallnummer anrufen).

Privatpersonen wenden sich bitte an Ihren IT-Dienstleister des Vertrauens oder die lokale Polizeidienststelle.

Weitere Informationen zu unseren DFIR-Services finden Sie hier:

QR_CSIRT_2022@2x
CSIRT zu den Kontakten hinzufügen