ISO 27001 A.8.1-8.8: Technologische Controls für sichere Systeme

Die technische Basis im Annex A

Die Controls A.8.1 bis A.8.8 gehören zur Gruppe der technologischen Controls in der ISO 27001:2022. Sie adressieren die grundlegenden technischen Maßnahmen, die jedes Unternehmen umsetzen muss, unabhängig von Branche oder Größe. Für ein Unternehmen mit rund 100 Mitarbeitenden sind diese Controls besonders relevant, weil sie oft den Bereich betreffen, in dem die IT-Abteilung ohnehin arbeitet, der aber nicht immer systematisch dokumentiert und gesteuert wird.

Der Unterschied zwischen „wir machen das schon irgendwie" und „wir haben einen dokumentierten Prozess" ist genau der Unterschied, den ein Auditor sucht.

A.8.1: User Endpoint Devices

Was der Standard fordert

Informationen, die auf Endgeräten gespeichert, verarbeitet oder über Endgeräte zugänglich sind, müssen geschützt werden.

Umsetzung

Endgeräte sind Laptops, Desktops, Smartphones und Tablets, die von Mitarbeitenden genutzt werden. Sie sind die Schnittstelle zwischen Mensch und System und damit einer der häufigsten Angriffsvektoren.

Gerätestandards definieren: Erstelle einen Standard für die Konfiguration von Endgeräten. Dieser umfasst mindestens: Betriebssystem-Version, Festplattenverschlüsselung (BitLocker, FileVault), Endpoint Protection (Antivirus/EDR), automatische Updates, lokale Firewall, Bildschirmsperre nach Inaktivität.

Mobile Device Management (MDM): Für Unternehmen mit rund 100 Mitarbeitenden ist ein MDM-System sinnvoll, das die Einhaltung der Standards erzwingt und die zentrale Verwaltung der Geräte ermöglicht. Microsoft Intune, Jamf oder ähnliche Lösungen sind für diese Größe angemessen.

BYOD-Regelung: Wenn Mitarbeitende private Geräte für die Arbeit nutzen dürfen, brauchst du eine BYOD-Richtlinie, die Mindestanforderungen definiert (Betriebssystem-Version, Verschlüsselung, Bildschirmsperre) und die Möglichkeit einer Fernlöschung der Unternehmensdaten vorsieht.

Verlust und Diebstahl: Ein dokumentierter Prozess für den Fall, dass ein Endgerät verloren geht oder gestohlen wird. Der Prozess umfasst: Meldung an die IT, Fernsperre und ggf. Fernlöschung, Prüfung welche Daten auf dem Gerät waren, ggf. Meldung als Sicherheitsvorfall.

A.8.2: Privileged Access Rights

Was der Standard fordert

Die Zuweisung und Nutzung von privilegierten Zugriffsrechten muss eingeschränkt und gesteuert werden.

Warum dieses Control so wichtig ist

Privilegierte Accounts (Domain Admin, Root, Datenbankadministrator, Cloud-Admin) haben weitreichende Rechte. Ein kompromittierter Admin-Account kann das gesamte Netzwerk kontrollieren. Ransomware-Gruppen suchen gezielt nach privilegierten Accounts, weil ein einziger kompromittierter Admin-Account den Zugang zu allen Systemen öffnet.

Umsetzung für rund 100 Mitarbeitende

Separate Admin-Accounts: Administratoren nutzen für ihre alltägliche Arbeit (E-Mail, Browser, Dokumentenbearbeitung) einen normalen Benutzer-Account. Den Admin-Account verwenden sie nur, wenn sie tatsächlich administrative Tätigkeiten durchführen. Das klingt selbstverständlich, ist aber in der Praxis bei vielen Unternehmen nicht umgesetzt.

Minimalprinzip (Least Privilege): Jeder Account erhält nur die Rechte, die er für seine Aufgabe tatsächlich braucht. Ein Backup-Administrator braucht keine Domain-Admin-Rechte. Ein Datenbankadministrator braucht keinen Zugriff auf die Firewall.

Regelmäßige Überprüfung: Privilegierte Zugriffsrechte werden mindestens vierteljährlich überprüft – ISMS Lite unterstützt diese Reviews mit automatischen Erinnerungen und einem dokumentierten Genehmigungsworkflow. Wer hat welche Rechte? Braucht er sie noch? Hat sich die Rolle geändert?

Multi-Faktor-Authentifizierung: Für alle privilegierten Accounts ist MFA Pflicht. Keine Ausnahme.

Protokollierung: Alle Aktionen privilegierter Accounts werden protokolliert und regelmäßig ausgewertet.

Passwortrichtlinie für Admin-Accounts: Strengere Anforderungen als für normale Accounts: längere Passwörter, häufigere Rotation (oder besser: Passwort-Manager mit langen, zufälligen Passwörtern).

Just-in-Time-Zugriff: Idealerweise werden privilegierte Rechte nicht dauerhaft vergeben, sondern nur dann aktiviert, wenn sie benötigt werden, und nach Ablauf automatisch wieder entzogen. Für ein Unternehmen mit rund 100 Mitarbeitenden ist das je nach Infrastruktur möglicherweise noch Zukunftsmusik, aber es sollte als Ziel definiert sein.

A.8.3: Information Access Restriction

Was der Standard fordert

Der Zugang zu Informationen und anderen verbundenen Assets muss gemäß der festgelegten themenspezifischen Richtlinie zur Zugangskontrolle eingeschränkt werden.

Umsetzung

Dieses Control setzt die Zugangskontrollrichtlinie (siehe A.5.1) technisch um. Es geht darum, dass Mitarbeitende nur auf die Informationen zugreifen können, die sie für ihre Arbeit benötigen.

Rollenbasierte Zugriffskontrolle (RBAC): Definiere Rollen basierend auf Jobfunktionen und weise ihnen Zugriffsrechte zu. Ein Vertriebsmitarbeiter hat Zugriff auf das CRM, aber nicht auf die Buchhaltung. Ein Personalreferent hat Zugriff auf das HR-System, aber nicht auf den Quellcode.

Dateisystem-Berechtigungen: Netzlaufwerke und Fileshares sind nach Abteilungen oder Projekten strukturiert, und der Zugriff ist auf die berechtigten Gruppen beschränkt. Keine „Jeder hat Vollzugriff auf alles"-Freigaben.

Anwendungsberechtigungen: In Business-Anwendungen (ERP, CRM, HR-System) sind die Berechtigungen auf die für die Rolle notwendigen Funktionen beschränkt.

Regelmäßige Access Reviews: Mindestens jährlich werden die Zugriffsrechte aller Mitarbeitenden überprüft. Berechtigungen, die nicht mehr benötigt werden, werden entzogen.

A.8.4: Access to Source Code

Was der Standard fordert

Der Zugang zu Quellcode, Entwicklungstools und Software-Bibliotheken muss angemessen gesteuert werden.

Relevanz für ein Unternehmen mit rund 100 Mitarbeitenden

Wenn dein Unternehmen eigene Software entwickelt oder Individualsoftware im Einsatz hat, ist dieses Control relevant. Wenn du ausschließlich Standardsoftware nutzt, hat es geringere Bedeutung, muss aber im Statement of Applicability (SoA) trotzdem adressiert werden.

Zugriffskontrolle auf Repositories: Quellcode liegt in einem Versionskontrollsystem (Git) und der Zugang ist auf die Entwickler beschränkt, die ihn brauchen.

Branch-Schutz: Kritische Branches (main, production) sind geschützt. Änderungen erfordern Code Reviews und Approvals.

Keine Zugangsdaten im Quellcode: Passwörter, API-Keys und andere Secrets gehören in einen Secrets Manager, nicht in den Quellcode.

A.8.5: Secure Authentication

Was der Standard fordert

Sichere Authentifizierungstechnologien und -verfahren müssen gemäß den Informationszugangsbeschränkungen und der themenspezifischen Richtlinie zur Zugangskontrolle implementiert werden.

Umsetzung

Passwortrichtlinie durchsetzen: Mindestlänge (12+ Zeichen für normale Accounts, 16+ für Admin-Accounts), Komplexitätsanforderungen oder besser: Passphrasen erlauben und fördern.

Multi-Faktor-Authentifizierung: MFA für alle extern erreichbaren Dienste (VPN, Webmail, Cloud-Dienste) und für alle privilegierten Zugänge. Idealerweise FIDO2/WebAuthn (Hardware-Tokens) oder TOTP (Authenticator-Apps). SMS als zweiter Faktor ist besser als nichts, aber als unsicher einzustufen.

Single Sign-On (SSO): Wo möglich, ein zentrales Identity Management mit SSO. Das reduziert die Anzahl der Passwörter, die Mitarbeitende verwalten müssen, und ermöglicht zentrale Steuerung der Authentifizierung.

Account-Lockout: Nach einer definierten Anzahl fehlgeschlagener Anmeldeversuche wird der Account vorübergehend gesperrt. Das verhindert Brute-Force-Angriffe.

Keine geteilten Accounts: Jeder Mitarbeitende hat seine eigenen Zugangsdaten. Geteilte Accounts (z.B. „admin" mit einem Passwort, das drei Leute kennen) sind ein klarer Verstoß gegen das Prinzip der Zurechenbarkeit.

A.8.6: Capacity Management

A.8.6 fordert, dass die Nutzung von Ressourcen überwacht und an aktuelle und erwartete Kapazitätsanforderungen angepasst wird. Dieses Control wird im Artikel zu A.8.9-8.16 ausführlich behandelt.

A.8.7: Protection Against Malware

Was der Standard fordert

Schutz gegen Malware muss implementiert und durch angemessene Awareness der Benutzer unterstützt werden.

Mehr als nur ein Virenscanner

Malware-Schutz ist ein mehrschichtiges Thema. Ein Virenscanner allein reicht 2026 nicht mehr aus. Moderne Angreifer verwenden Techniken, die klassische signaturbasierte Scanner nicht erkennen: dateilose Malware, Living-off-the-Land-Angriffe, polymorphe Schadsoftware.

Endpoint Detection and Response (EDR): Statt eines klassischen Virenscanners sollte ein EDR-System eingesetzt werden, das Verhaltensanalysen durchführt und verdächtige Aktivitäten erkennt. Für ein Unternehmen mit rund 100 Mitarbeitenden gibt es passende Lösungen wie Microsoft Defender for Endpoint, CrowdStrike Falcon Go oder SentinelOne.

E-Mail-Filterung: Ein E-Mail-Gateway, das Anhänge auf Malware prüft, Links in E-Mails umschreibt und verdächtige E-Mails in die Quarantäne verschiebt. Phishing-E-Mails sind nach wie vor der häufigste Angriffsvektor.

Webfilter: Zugriff auf bekannte Malware-Verteilseiten und Phishing-Domains blockieren.

Application Whitelisting: Auf kritischen Systemen (z.B. Servern) nur die Ausführung zugelassener Software erlauben. Auf Endgeräten ist das schwieriger umzusetzen, aber zumindest die Installation von Software sollte auf Administratoren beschränkt sein.

USB-Kontrolle: Die Nutzung von USB-Speichergeräten einschränken oder technisch unterbinden, zumindest auf Systemen mit erhöhtem Schutzbedarf.

Awareness: Die technischen Maßnahmen werden durch Schulung der Mitarbeitenden ergänzt. Jeder Mitarbeitende muss wissen, wie er verdächtige E-Mails erkennt und was er tun soll, wenn er versehentlich auf einen verdächtigen Link geklickt hat.

A.8.8: Management of Technical Vulnerabilities

Was der Standard fordert

Informationen über technische Schwachstellen der eingesetzten Informationssysteme müssen zeitnah beschafft, die Exposition der Organisation gegenüber diesen Schwachstellen bewertet und angemessene Maßnahmen ergriffen werden.

Der Schwachstellenmanagement-Prozess

Schritt 1: Inventar der Systeme: Du kannst nur Schwachstellen in Systemen bewerten, die du kennst. Ein aktuelles Inventar aller IT-Systeme (Server, Netzwerkgeräte, Anwendungen, Cloud-Dienste) ist die Voraussetzung.

Schritt 2: Schwachstellen identifizieren: Verfolge die Veröffentlichung von Schwachstellen für deine eingesetzten Systeme und Software. Quellen: Herstellermeldungen, CERT-Warnungen (BSI CERT-Bund), CVE-Datenbanken. Für Unternehmen mit rund 100 Mitarbeitenden ist ein automatisierter Vulnerability Scanner sinnvoll, der das Netzwerk regelmäßig auf bekannte Schwachstellen prüft (z.B. OpenVAS, Tenable Nessus, Qualys).

Schritt 3: Schwachstellen bewerten: Nicht jede Schwachstelle ist gleich kritisch. Die Bewertung berücksichtigt den CVSS-Score, die Exponierung des betroffenen Systems (intern vs. extern erreichbar), die Verfügbarkeit von Exploits und den Schutzbedarf der Daten auf dem System.

Schritt 4: Maßnahmen ergreifen: Patches einspielen, Workarounds implementieren oder das Risiko akzeptieren (dokumentiert). Definiere SLAs für die Patch-Zeiten basierend auf der Kritikalität:

• Kritische Schwachstellen (CVSS 9.0+, extern exponiert, Exploit verfügbar): 24-72 Stunden
• Hohe Schwachstellen (CVSS 7.0-8.9): 7 Tage
• Mittlere Schwachstellen (CVSS 4.0-6.9): 30 Tage
• Niedrige Schwachstellen (CVSS < 4.0): Nächster regulärer Patch-Zyklus

Schritt 5: Verifizieren und dokumentieren: Nach dem Patching prüfen, ob die Schwachstelle tatsächlich behoben ist. Den gesamten Prozess dokumentieren.

Typische Audit-Findings bei A.8.1-A.8.8

Finding 1: Administratoren arbeiten dauerhaft mit Admin-Accounts

Die IT-Administratoren nutzen ihren Admin-Account auch für alltägliche Tätigkeiten wie E-Mail und Browsen. Ein kompromittierter Admin-Account hätte sofortigen Vollzugriff auf alle Systeme.

Vermeidung: Richte für jeden Administrator einen separaten Admin-Account ein, der nur für administrative Tätigkeiten verwendet wird. Der Admin-Account hat ein anderes Passwort und wird nur bei Bedarf genutzt. Die alltägliche Arbeit erfolgt mit einem normalen Benutzer-Account.

Finding 2: Keine dokumentierte Schwachstellenbewertung

Patches werden eingespielt, aber es gibt keinen dokumentierten Prozess für die Bewertung von Schwachstellen. Es ist unklar, nach welchen Kriterien die Priorisierung erfolgt und ob kritische Schwachstellen zeitnah adressiert werden.

Vermeidung: Erstelle einen dokumentierten Schwachstellenmanagement-Prozess mit klaren Rollen, Bewertungskriterien und SLAs für die Patch-Zeiten. Nutze einen Vulnerability Scanner, der regelmäßig das Netzwerk scannt und Berichte erzeugt.

Finding 3: Endgeräte nicht einheitlich konfiguriert

Es gibt keinen definierten Standard für die Konfiguration von Endgeräten. Einige Laptops haben Festplattenverschlüsselung, andere nicht. Die Patch-Stände variieren. Kein MDM-System im Einsatz.

Vermeidung: Definiere eine Basiskonfiguration für jeden Endgerätetyp und setze sie über ein MDM-System durch. Regelmäßige Compliance-Checks identifizieren Geräte, die vom Standard abweichen.

Finding 4: Privilegierte Zugriffsrechte nicht regelmäßig überprüft

Es gibt keine dokumentierte Überprüfung der Admin-Rechte. Ehemalige Administratoren haben noch Admin-Zugang, obwohl sie die Rolle gewechselt haben.

Vermeidung: Führe mindestens vierteljährlich ein dokumentiertes Review aller privilegierten Accounts durch. Prüfe für jeden Account: Ist der Inhaber noch im Unternehmen? Braucht er die Rechte noch? Sind die Rechte angemessen? Dokumentiere das Ergebnis und die getroffenen Entscheidungen.

Finding 5: Kein Prozess für den Umgang mit Zero-Day-Schwachstellen

Es gibt keinen definierten Eskalationsprozess, wenn eine kritische Schwachstelle bekannt wird, für die noch kein Patch existiert (Zero-Day). Workarounds und Mitigationsmaßnahmen werden ad hoc entschieden.

Vermeidung: Definiere einen Eskalationsprozess für Zero-Day-Schwachstellen, der festlegt, wer informiert wird, wer die Risikobewertung durchführt, welche Mitigationsmaßnahmen in Betracht kommen (z.B. Netzwerksegmentierung, Deaktivierung betroffener Dienste, zusätzliches Monitoring) und wer die Entscheidung über Sofortmaßnahmen trifft.

Zusammenspiel der Controls A.8.1-A.8.8

Die technologischen Controls A.8.1 bis A.8.8 greifen eng ineinander und sollten nicht isoliert betrachtet werden. Ein Beispiel: Die Endgerätesicherheit (A.8.1) erfordert Malware-Schutz (A.8.7), der wiederum regelmäßige Updates braucht, die durch das Schwachstellenmanagement (A.8.8) gesteuert werden. Die sichere Authentifizierung (A.8.5) ist die Grundlage für die Zugriffsrestriktion (A.8.3), die wiederum die privilegierten Zugriffsrechte (A.8.2) regelt.

Wenn du diese Controls als zusammenhängendes System betrachtest und nicht als isolierte Checklisten-Punkte, wird die Umsetzung konsistenter und die Lücken zwischen den einzelnen Maßnahmen werden sichtbar. Der Auditor wird genau diese Konsistenz prüfen: Passt die Malware-Schutzstrategie zur Endgeräte-Policy? Passt die Schwachstellenbewertung zu den definierten Patch-SLAs? Passen die privilegierten Zugriffsrechte zum Least-Privilege-Prinzip der Zugangskontrollrichtlinie?

Für ein Unternehmen mit rund 100 Mitarbeitenden empfiehlt sich ein pragmatischer Ansatz: Beginne mit einem Inventar deiner IT-Systeme (ohne das kein Control funktioniert), definiere dann die Basiskonfigurationen (A.8.9, das formal in A.8.9-A.8.16 fällt, aber konzeptionell hierher gehört), implementiere die Zugangskontrolle und privilegierten Zugriffsrechte, rolle den Malware-Schutz aus und baue das Schwachstellenmanagement auf. In dieser Reihenfolge baust du ein solides Fundament, auf dem die weiteren technologischen Controls aufsetzen können.

Wie ISMS Lite den Nachweis unterstützt

Konfigurationsstandards: Dokumentiere deine Standards für die Endgerätekonfiguration und weise sie den entsprechenden Geräten im Asset-Inventar zu.

Schwachstellenmanagement-Tracker: Erfasse Schwachstellen, ordne sie Systemen zu, dokumentiere die Bewertung und verfolge den Behebungsstatus. SLA-Überschreitungen werden auf dem Dashboard angezeigt.

Privileged-Access-Register: Dokumentiere alle privilegierten Accounts, deren Inhaber und die regelmäßigen Review-Ergebnisse.

Access-Review-Workflow: Geplante Access Reviews mit Benachrichtigung, Bestätigung oder Entzug durch den Verantwortlichen und Audit-Trail.

Maßnahmenverfolgung: Alle aus den Controls abgeleiteten Maßnahmen werden zentral erfasst und auf Wiedervorlage gesetzt.

Weiterführende Artikel

• Schwachstellenmanagement aufbauen: Von der Erkennung bis zum Patch
• Patch Management im Mittelstand: Prozess, Priorisierung und Automatisierung
• Berechtigungskonzept erstellen: Rollen, Rechte und Rezertifizierung
• MFA einführen im Unternehmen: Strategie, Tools und Rollout
• Netzwerksegmentierung für KMU: Schutz vor lateraler Bewegung