ISO 27001 A.8.24-8.34: Kryptografie, Entwicklung und Änderungsmanagement

Die letzten Bausteine im technologischen Puzzle

Die Controls A.8.24 bis A.8.34 schließen den Bereich der technologischen Controls in der ISO 27001:2022 ab. Sie decken Themen ab, die konzeptionell anspruchsvoller sind als die operativen Basics aus A.8.1-A.8.16, aber für die Gesamtsicherheit ebenso wichtig.

Für ein Unternehmen mit rund 100 Mitarbeitenden ist die gute Nachricht: Nicht alle diese Controls haben die gleiche Relevanz. Wenn du keine eigene Software entwickelst, sind die Entwicklungs-Controls (A.8.25-A.8.31) weniger umfangreich umzusetzen. Aber auch dann musst du sie im Statement of Applicability (SoA) adressieren und begründen, warum sie in deinem Kontext eingeschränkt anwendbar sind.

A.8.24: Use of Cryptography

Was der Standard fordert

Regeln für den effektiven Einsatz von Kryptografie, einschließlich des Managements kryptografischer Schlüssel, müssen definiert und implementiert werden.

Die Kryptografie-Richtlinie

A.8.24 erfordert eine dokumentierte Kryptografie-Richtlinie. Die wesentlichen Inhalte:

Zugelassene Algorithmen: Definiere, welche Algorithmen für welche Zwecke eingesetzt werden dürfen. Orientierung bieten die BSI TR-02102 und die NIST-Empfehlungen.

Verbotene Algorithmen: DES, 3DES, RC4, MD5, SHA-1 dürfen nicht mehr eingesetzt werden. Bestandssysteme, die diese Algorithmen noch verwenden, brauchen einen dokumentierten Migrationsplan.

Schlüsselmanagement-Lifecycle: Für kryptografische Schlüssel muss ein Lifecycle definiert sein.

Erzeugung: Schlüssel werden mit kryptografisch sicheren Zufallsgeneratoren erzeugt, nicht manuell oder mit schwachen Zufallsquellen.

Speicherung: Private Schlüssel werden geschützt aufbewahrt: in Hardware Security Modules (HSM), in geschützten Schlüsselspeichern des Betriebssystems (Windows Certificate Store, macOS Keychain) oder in dedizierten Key Management Services (AWS KMS, Azure Key Vault). Auf keinen Fall im Klartext in Konfigurationsdateien oder im Quellcode.

Verteilung: Schlüssel werden über sichere Kanäle verteilt. Öffentliche Schlüssel über Zertifikate mit vertrauenswürdiger CA. Private Schlüssel werden niemals per E-Mail oder Messenger übertragen.

Rotation: Definiere Rotationsintervalle. TLS-Zertifikate typischerweise jährlich (oder kürzer mit Let's Encrypt). Symmetrische Schlüssel basierend auf der Datenmenge und dem Schutzbedarf.

Widerruf: Bei Kompromittierung eines Schlüssels muss dieser sofort widerrufen und ersetzt werden. Für Zertifikate über Certificate Revocation Lists (CRL) oder OCSP.

Vernichtung: Nicht mehr benötigte Schlüssel werden sicher gelöscht, sodass sie nicht wiederherstellbar sind.

Praxisanwendung

Für ein Unternehmen mit rund 100 Mitarbeitenden sind die häufigsten Anwendungsfälle für Kryptografie:

• Transportverschlüsselung: TLS für Webseiten, E-Mail (STARTTLS/SMTPS/IMAPS), VPN (IPsec oder WireGuard)
• Speicherverschlüsselung: BitLocker auf Windows-Endgeräten, FileVault auf macOS, LUKS auf Linux-Servern
• E-Mail-Verschlüsselung: S/MIME oder PGP für vertrauliche E-Mails
• Passwort-Hashing: bcrypt, scrypt oder Argon2 für gespeicherte Passwörter
• Backup-Verschlüsselung: AES-256 für Backups, die extern aufbewahrt werden

A.8.25-A.8.27: Secure Development Lifecycle

A.8.25: Secure Development Life Cycle

Der Standard fordert Regeln für die sichere Entwicklung von Software und Systemen, die den gesamten Entwicklungszyklus abdecken.

A.8.26: Application Security Requirements

Informationssicherheitsanforderungen müssen identifiziert, spezifiziert und genehmigt werden, wenn Anwendungen entwickelt oder beschafft werden.

A.8.27: Secure System Architecture and Engineering Principles

Prinzipien für die sichere Systemarchitektur und -entwicklung müssen festgelegt, dokumentiert, gepflegt und auf alle Aktivitäten der Informationssystementwicklung angewendet werden.

Umsetzung

Wenn dein Unternehmen selbst Software entwickelt (auch interne Tools, Skripte oder Automatisierungen), brauchst du einen Secure Development Lifecycle (SDLC). Für ein Unternehmen mit rund 100 Mitarbeitenden, das typischerweise ein kleines Entwicklerteam hat, reicht ein pragmatischer Ansatz:

Sicherheitsanforderungen in der Anforderungsphase: Bei jedem neuen Feature oder System werden Sicherheitsanforderungen explizit definiert. Welche Daten verarbeitet das System? Welchen Schutzbedarf haben sie? Welche Authentifizierung ist erforderlich? Welche Zugriffsrechte?

Sichere Coding-Richtlinien: Orientiere dich an den OWASP Top 10 und definiere Mindestanforderungen für sicheren Code: Input-Validierung, parametrisierte Datenbankabfragen (gegen SQL Injection), Output-Encoding (gegen XSS), sichere Session-Verwaltung, keine hartcodierten Credentials.

Code Reviews: Jede Änderung am Produktivcode wird vor dem Merge von mindestens einer weiteren Person reviewed. Security-Aspekte sind Teil des Review-Kriteriums.

Automatisierte Sicherheitsprüfungen: Integriere Static Application Security Testing (SAST) und Dependency-Scanning in die CI/CD-Pipeline. Tools wie SonarQube, Snyk oder GitHub Dependabot sind für kleine Teams praktikabel.

Trennung der Umgebungen (A.8.31): Entwicklungs-, Test- und Produktivumgebungen müssen getrennt sein. Code wird in der Entwicklungsumgebung geschrieben, in der Testumgebung geprüft und erst nach Freigabe in die Produktion überführt. Entwickler haben keinen direkten Schreibzugriff auf die Produktivumgebung.

Wenn du keine Software entwickelst

Wenn dein Unternehmen ausschließlich Standardsoftware einsetzt, sind die Entwicklungs-Controls in reduziertem Umfang relevant. Du musst trotzdem sicherstellen, dass Sicherheitsanforderungen bei der Beschaffung von Software definiert werden (A.8.26) und dass Anpassungen (Konfigurationen, Integrationen, Skripte) sicher durchgeführt werden.

A.8.28-A.8.29: Sicheres Coding und Testen

A.8.28: Secure Coding

Sichere Coding-Prinzipien müssen bei der Softwareentwicklung angewendet werden. Der Standard verweist auf etablierte Frameworks wie die OWASP-Richtlinien und betont die Notwendigkeit, Entwickler regelmäßig in sicherer Programmierung zu schulen.

A.8.29: Security Testing in Development and Acceptance

Sicherheitstests müssen im Entwicklungsprozess definiert und durchgeführt werden. Das umfasst:

Unit-Tests für Sicherheitsfunktionen: Authentifizierung, Autorisierung und Eingabevalidierung werden gezielt durch Tests abgedeckt.

Penetrationstests: Für kritische Anwendungen sind Penetrationstests vor dem Go-Live und in regelmäßigen Abständen danach sinnvoll. Für ein Unternehmen mit rund 100 Mitarbeitenden kann das durch einen externen Dienstleister erfolgen.

Abnahmetests mit Sicherheitskriterien: Bei der Abnahme neuer Software oder neuer Releases werden Sicherheitskriterien explizit geprüft.

A.8.30: Outsourced Development

Wenn die Softwareentwicklung an externe Dienstleister ausgelagert wird, muss die Organisation die Informationssicherheitsaktivitäten bei der ausgelagerten Entwicklung steuern und überwachen.

Vertragliche Sicherheitsanforderungen: Der Entwicklungsvertrag muss Sicherheitsanforderungen enthalten: sichere Coding-Richtlinien, Code-Eigentum, Zugang zum Quellcode, Sicherheitstests, Behandlung von Schwachstellen.

Code-Reviews: Auch extern entwickelter Code sollte vor der Übernahme in die Produktion einem Sicherheitsreview unterzogen werden.

Abnahmetests: Die Abnahme umfasst Sicherheitstests, die von deinem Unternehmen oder einem unabhängigen Dritten durchgeführt werden.

A.8.33: Test Information

Was der Standard fordert

Testdaten müssen angemessen ausgewählt, geschützt und verwaltet werden.

Das Problem mit Produktionsdaten in Testumgebungen

Es ist verlockend, Produktionsdaten in die Testumgebung zu kopieren, weil sie realistisch sind und Fehler aufdecken, die mit synthetischen Daten nicht auffallen. Aber Produktionsdaten enthalten oft personenbezogene Daten, vertrauliche Geschäftsdaten und Finanzinformationen. Wenn diese Daten in eine weniger gesicherte Testumgebung kopiert werden, steigt das Risiko einer Kompromittierung.

Umsetzung

Anonymisierung/Pseudonymisierung: Wenn Produktionsdaten in Testumgebungen verwendet werden, müssen sie anonymisiert oder pseudonymisiert werden. Namen, Adressen, Telefonnummern, Bankverbindungen und andere personenbezogene Daten werden durch fiktive Daten ersetzt.

Synthetische Testdaten: Idealerweise werden Testdaten synthetisch generiert. Tools wie Faker (für verschiedene Programmiersprachen) können realistische, aber fiktive Datensätze erzeugen.

Zugriffskontrolle für Testumgebungen: Auch wenn Testumgebungen weniger geschützt sind als Produktivumgebungen, brauchen sie Zugangskontrollen. Nicht jeder Mitarbeitende sollte Zugriff auf Testdaten haben.

Löschung nach dem Test: Testdaten werden nach Abschluss der Tests gelöscht, wenn sie nicht mehr benötigt werden.

Netzsegmentierung und Netzwerkmanagement (A.8.20-A.8.23)

Obwohl formal in einem anderen Nummernbereich, gehören die Netzwerk-Controls thematisch in den Kontext der technologischen Gesamtarchitektur.

A.8.22: Network Segregation

Netzsegmentierung ist eine der effektivsten Maßnahmen gegen laterale Bewegung von Angreifern im Netzwerk. Die Grundidee: Teile das Netzwerk in Segmente auf, sodass ein Angreifer, der in ein Segment eingedrungen ist, nicht automatisch Zugang zu allen anderen Segmenten hat.

Mindest-Segmentierung für rund 100 Mitarbeitende:

• Servernetz: Alle Server in einem eigenen VLAN, getrennt vom Benutzernetz
• Benutzernetz: Endgeräte der Mitarbeitenden
• Gästenetz: WLAN für Besucher, strikt vom internen Netz getrennt
• DMZ: Extern erreichbare Dienste (Webserver, VPN-Gateway) in einer demilitarisierten Zone
• Management-Netz: Für die Administration von Netzwerkgeräten und Servern (optional, aber empfohlen)

Die Segmente werden durch Firewalls oder Access Control Lists (ACLs) auf den Switches voneinander getrennt. Der Datenverkehr zwischen den Segmenten wird gefiltert: Nur die notwendige Kommunikation wird erlaubt.

A.8.23: Web Filtering

A.8.23 ist ein neues Control und fordert, dass der Zugang zu externen Webseiten gesteuert wird, um die Exposition gegenüber bösartigen Inhalten zu reduzieren.

DNS-basiertes Filtering: Ein DNS-Filter (z.B. Cisco Umbrella, Cloudflare Gateway, Pi-hole mit Blocklists) blockiert den Zugriff auf bekannte Malware-Domains, Phishing-Seiten und andere gefährliche Kategorien.

Proxy-basiertes Filtering: Ein Web-Proxy filtert den HTTP/HTTPS-Verkehr und blockiert unerwünschte Kategorien (Malware, Phishing, ggf. weitere Kategorien gemäß Unternehmensrichtlinie).

Kategoriebasierte Richtlinien: Nicht alles muss blockiert werden. Definiere Kategorien, die blockiert werden (Malware, Phishing, Anonymizer), und Kategorien, die erlaubt sind. Vermeide übermäßig restriktive Filter, die die Mitarbeitenden bei der Arbeit behindern.

A.8.32: Change Management

Was der Standard fordert

Änderungen an Informationsverarbeitungseinrichtungen und Informationssystemen müssen einem Change-Management-Verfahren unterliegen.

Der Change-Management-Prozess

Change Management wurde bereits in einem separaten Artikel behandelt. Im Kontext der technologischen Controls hier die Kernpunkte:

Change-Typen: Standard Changes (vorgenehmigt, geringes Risiko, z.B. regelmäßige Patches), Normal Changes (individuelle Bewertung und Genehmigung), Emergency Changes (beschleunigtes Verfahren bei akuter Gefahr).

Risikobewertung: Jede Änderung (außer Standard Changes) wird vor der Umsetzung hinsichtlich ihrer Auswirkungen auf die Informationssicherheit bewertet – ISMS Lite liefert die zugehörigen Controls mit Umsetzungsempfehlungen und unterstützt die Dokumentation durch Versionierung und Freigabe-Workflows. Welche Systeme sind betroffen? Welche Risiken entstehen? Welche Maßnahmen reduzieren die Risiken?

Genehmigung: Normal Changes werden durch einen definierten Genehmiger oder ein Change Advisory Board (CAB) freigegeben. Für ein Unternehmen mit rund 100 Mitarbeitenden kann das CAB aus der IT-Leitung, dem ISB und dem Fachbereichsverantwortlichen bestehen.

Rollback-Plan: Jede Änderung braucht einen Plan B: Was tun wir, wenn die Änderung schiefgeht? Wie stellen wir den vorherigen Zustand wieder her?

Dokumentation: Jede Änderung wird dokumentiert: Was wurde geändert? Warum? Wer hat genehmigt? Wann wurde implementiert? War die Implementierung erfolgreich?

Post-Implementation-Review: Nach der Umsetzung wird geprüft, ob die Änderung den gewünschten Effekt hatte und keine unerwarteten Nebenwirkungen aufgetreten sind.

A.8.34: Protection of Information Systems During Audit Testing

Was der Standard fordert

Audit-Tests und andere Assurance-Aktivitäten, die operative Systeme betreffen, müssen geplant und zwischen dem Tester und dem verantwortlichen Management abgestimmt werden.

Umsetzung

Wenn interne oder externe Audits technische Tests umfassen (Vulnerability Scans, Penetrationstests, Konfigurationsüberprüfungen), müssen diese koordiniert werden, um den laufenden Betrieb nicht zu gefährden.

Zeitplanung: Tests werden außerhalb der Kernarbeitszeiten durchgeführt, wenn sie die Systemverfügbarkeit beeinträchtigen könnten.

Geltungsbereich: Der Geltungsbereich der Tests wird vorab definiert und schriftlich vereinbart. Welche Systeme werden getestet? Welche Testmethoden sind erlaubt? Welche Systeme sind ausgenommen?

Zugriffskontrolle: Tester erhalten nur die für den Test notwendigen Zugriffsrechte, die nach Abschluss wieder entzogen werden.

Dokumentation: Testergebnisse werden vertraulich behandelt und nur an autorisierte Personen weitergegeben.

Typische Audit-Findings bei A.8.24-A.8.34

Finding 1: Keine dokumentierte Kryptografie-Richtlinie

Verschlüsselung wird eingesetzt, aber es gibt keine Richtlinie, die zugelassene Algorithmen, Schlüssellängen und den Schlüssel-Lifecycle definiert. Die kryptografischen Entscheidungen sind implizit und nicht nachvollziehbar.

Finding 2: Keine Trennung von Entwicklung, Test und Produktion

Entwickler haben direkten Zugriff auf die Produktivumgebung. Es gibt keine separate Testumgebung, sodass Änderungen direkt in der Produktion getestet werden.

Finding 3: Produktionsdaten in der Testumgebung

Die Testumgebung enthält eine vollständige Kopie der Produktionsdatenbank, einschließlich personenbezogener Daten und vertraulicher Geschäftsinformationen, ohne Anonymisierung.

Finding 4: Change Management nicht gelebt

Es gibt einen dokumentierten Change-Management-Prozess, aber in der Praxis werden viele Änderungen ohne formale Genehmigung durchgeführt. Emergency Changes werden nachträglich nicht dokumentiert.

Finding 5: Keine Netzsegmentierung

Server, Endgeräte und Gäste-WLAN befinden sich im gleichen Netzwerksegment. Ein kompromittiertes Endgerät hat direkten Netzwerkzugriff auf alle Server.

Wie ISMS Lite den Nachweis unterstützt

Kryptografie-Controls: ISMS Lite enthält die relevanten Kryptografie-Controls mit praxisnahen Umsetzungsempfehlungen für Algorithmen und Schlüssellängen. Mit der integrierten KI-Funktion kannst du daraus eine Kryptografie-Richtlinie als Ausgangsbasis generieren.

Change-Management-Controls: Die Controls zum Change Management liefern konkrete Empfehlungen für Risikobewertung, Genehmigung und Post-Implementation-Review. Erstellte Dokumente werden versioniert und durchlaufen den Freigabe-Workflow.

Entwicklungs-Controls: Controls zu sicherer Entwicklung, Coding-Richtlinien und Testverfahren mit praxisnahen Empfehlungen für jede Phase des Entwicklungsprozesses.

Netzwerk-Controls: Controls zu Netzsegmentierung, Netzwerkmanagement und Web Filtering mit Umsetzungsempfehlungen, die du als Grundlage für deine Netzwerk-Dokumentation nutzen kannst.

SoA-Unterstützung: Alle 583 Controls aus 11 Frameworks sind in ISMS Lite abgebildet. Für Controls, die in deinem Kontext eingeschränkt anwendbar sind, kannst du die Begründung direkt im Statement of Applicability dokumentieren.

Weiterführende Artikel

• Kryptografie-Richtlinie erstellen: Algorithmen, Schlüssellängen und Lifecycle
• Change Management im ISMS: Änderungen sicher steuern
• Netzwerksegmentierung für KMU: Schutz vor lateraler Bewegung
• Schwachstellenmanagement aufbauen: Von der Erkennung bis zum Patch
• Berechtigungskonzept erstellen: Rollen, Rechte und Rezertifizierung