Systemhärtung bezeichnet die sichere Konfiguration eines IT-Systems mit dem Ziel, dessen Angriffsfläche gezielt zu verkleinern, etwa durch das Deaktivieren nicht benötigter oder veralteter Funktionen und Komponenten des Systems.
Auf einen Blick
Zusätzliche Software-Komponenten bieten zusätzliche Angriffsfläche; deshalb sollten nur benötigte Anwendungen und Betriebssystemkomponenten installiert sein.
Welche Funktionen benötigt werden, ist individuell nach dem Einsatzzweck zu entscheiden.
Die Delegierte Verordnung (EU) 2024/1774 zu DORA verlangt von Finanzunternehmen die Ermittlung von Mindestanforderungen an eine sichere Konfigurationsbasis für IKT-Assets.
Was ist Systemhärtung?
Bei der Systemhärtung wird ein System so konfiguriert, dass seine Angriffsfläche kleiner wird. Die BSI-Studie SiSyPHuS nennt als Ziel ein umfassendes Härtungskonzept für die Konfiguration von Komponenten von Windows 10. Nach dieser Studie sollten nur Anwendungen und Betriebssystemkomponenten installiert werden, die für die tatsächliche Tätigkeit des Benutzers oder für den Betrieb des Systems benötigt werden; welche das sind, muss individuell nach Einsatzzweck entschieden werden. Nicht benötigte Module, Programme, Dienste, Aufgaben und Firmwarefunktionen sollten nach dem IT-Grundschutz-Baustein SYS.2.1 für allgemeine Clients deaktiviert oder ganz deinstalliert werden.
Systemhärtung kann bei einem unter DORA fallenden Versicherer zur Umsetzung der Anforderungen an eine sichere Konfigurationsbasis beitragen, die er nach Artikel 11 Absatz 2 Buchstabe b der delegierten DORA-Verordnung für seine IKT-Assets ermittelt, um deren Exposition gegenüber Cyberbedrohungen zu minimieren; dazu werden etwa nicht benötigte Dienste deaktiviert. Mit zusätzlichen Anwendungen steigen außerdem nach dem Baustein nicht nur Rechen- und Speicherlast eines Clients, sondern auch die Wahrscheinlichkeit für darin verborgene Schwachstellen. Die Auswahl der Maßnahmen richtet sich also nach dem Einsatzzweck des Systems.
Wie funktioniert Systemhärtung?
Zusätzliche Software-Komponenten bieten zusätzliche Angriffsfläche; Härtung verringert diese Fläche, etwa indem nicht benötigte oder veraltete Funktionen und Komponenten deaktiviert werden. Die Studie bezieht sich auf das Betriebssystem Windows 10, der Baustein SYS.2.1 auf allgemeine Clients. Um zu verhindern, dass ein Angreifer nach der Kompromittierung eines Benutzerkontos direkt weitreichende Kontrolle über ein System erlangt, sollten nach der Windows-10-Studie mindestens zwei unterschiedliche Konten angelegt werden. Dabei sollte das Konto ohne besondere Berechtigungen für die Anmeldung und unprivilegierte Tätigkeiten dienen, das administrative Konto nur für Aufgaben, die höhere Berechtigungen erfordern.
Für Finanzunternehmen umfasst Artikel 11 Absatz 2 Buchstabe b der delegierten DORA-Verordnung die Ermittlung von Mindestanforderungen an eine sichere Konfigurationsbasis für IKT-Assets, durch die deren Exposition gegenüber Cyberbedrohungen minimiert wird, sowie Maßnahmen zur regelmäßigen Überprüfung, ob diese Mindestanforderungen wirksam verwendet werden. Für die Zwecke von Buchstabe b werden dabei die führenden Praktiken und geeigneten Techniken berücksichtigt, die in Normen im Sinne des Artikels 2 Nummer 1 der Verordnung (EU) Nr. 1025/2012 festgelegt sind (Artikel 11 Absatz 2, Unterabsatz nach Buchstabe k).
Systemhärtung im Vergleich
| Kriterium | Systemhärtung | Patch-Management | Vulnerability Management |
|---|---|---|---|
| Aufgabe | Verringert die Angriffsfläche, etwa durch Deaktivierung nicht benötigter oder veralteter Funktionen und Komponenten | Aktualisiert Software, etwa durch Sicherheitskorrekturen, Service Packs und Hot Fixes | Ermittelt und bewertet Schwachstellen, etwa mit automatisierten Schwachstellenbewertungen und -scans |
| Beitrag zu den Schwachstellen | Nicht benötigte Software unterliegt nach SYS.2.1 häufig keinem regelmäßigen Patch-Management, sodass bekannte Sicherheitslücken nicht zeitnah geschlossen werden | Die Einführung von Patches und anderen Abhilfemaßnahmen wird priorisiert, um ermittelte Schwachstellen zu beheben | Bei Finanzunternehmen entsprechen Häufigkeit und Umfang der Scans nach der delegierten DORA-Verordnung der Klassifizierung und dem Gesamtrisikoprofil des IKT-Assets |
| Verankerung für Finanzunternehmen | Mindestanforderungen an eine sichere Konfigurationsbasis (Artikel 11 Absatz 2 Buchstabe b der delegierten DORA-Verordnung) | Eigene Verfahren für das Patch-Management (Artikel 10 Absatz 3 der delegierten DORA-Verordnung); die priorisierte Einführung von Patches gehört zudem zum Schwachstellen-Management | Verfahren für das Schwachstellen-Management (Artikel 10 der delegierten DORA-Verordnung) |
Welche Maßnahmen gehören zur Systemhärtung?
| Maßnahme | Worauf es ankommt |
|---|---|
| Sichere Konfigurationsbasis bei Finanzunternehmen | Finanzunternehmen berücksichtigen bei der sicheren Konfigurationsbasis die führenden Praktiken und geeigneten Techniken aus den Normen im Sinne des Artikels 2 Nummer 1 der Verordnung (EU) Nr. 1025/2012 (Artikel 11 Absatz 2 der delegierten DORA-Verordnung). |
| Einsatzzweck beachten | Welche Anwendungen oder Funktionalitäten benötigt werden und deshalb installiert und aktiv sein müssen, muss individuell nach Einsatzzweck entschieden werden (BSI-Studie SiSyPHuS zu Windows 10). |
| Nicht benötigte Kennungen | Nicht benötigte Kennungen sollten deaktiviert oder gelöscht werden (Baustein SYS.2.1 für allgemeine Clients). |
Schutz im Ernstfall
Vorbeugen
- Ein unter DORA fallender Versicherer entwickelt, dokumentiert und implementiert im Rahmen seiner IKT-Sicherheitsrichtlinien ein Verfahren für die Daten- und Systemsicherheit (Artikel 11 Absatz 1 der delegierten DORA-Verordnung).
- Die Installation und Konfiguration der IT-Systeme sollte nach dem Baustein SYS.2.1 für allgemeine Clients nur von autorisierten Personen nach einem definierten Prozess in einer Installationsumgebung durchgeführt werden.
- Nach der Installation sollte überprüft werden, welche Komponenten der Firmware sowie des Betriebssystems und welche Anwendungen und weiteren Tools auf den Clients installiert und aktiviert sind.
Beispiele aus der Praxis
- Wird bei einem Penetrationstest als Prüftiefe ein technisches Sicherheitsaudit vereinbart, lässt sich der Prüfer von einem Administrator vor Ort zeigen, welche Versionen in welcher Konfiguration eingesetzt werden und welche Härtungsmaßnahmen getroffen wurden (Praxis-Leitfaden für IS-Penetrationstests des BSI).
- Auf einem Client wird das Trusted Platform Module (TPM) deaktiviert, sofern es nicht benötigt wird (Baustein SYS.2.1).
- Ein Versicherer könnte für seine IKT-Assets eine sichere Konfigurationsbasis festlegen, in der nicht benötigte Dienste deaktiviert sind, und prüfen, ob die Mindestanforderungen wirksam verwendet werden.
