Kryptografie-Richtlinie erstellen: Algorithmen, Schlüssellängen und Lifecycle

Warum Kryptografie eine eigene Richtlinie braucht

Verschlüsselung ist überall: in der E-Mail-Kommunikation, bei der Übertragung von Daten zwischen Systemen, auf Festplatten, in VPN-Tunneln, bei der Authentifizierung. Trotzdem regeln die meisten Unternehmen kryptografische Verfahren bestenfalls implizit. Der Webserver nutzt TLS, weil der Admin das so eingerichtet hat. Die Festplattenverschlüsselung läuft mit BitLocker, weil Microsoft das mitliefert. Und die Passwörter werden gehasht, weil das Framework das automatisch macht.

Das funktioniert, solange niemand fragt: Welche Algorithmen genau? Mit welchen Schlüssellängen? Wer hat die Schlüssel erzeugt, und wo liegen sie? Was passiert, wenn ein Algorithmus als unsicher eingestuft wird? Wie oft werden Schlüssel rotiert?

Genau hier setzt die Kryptografie-Richtlinie an. Sie beantwortet diese Fragen verbindlich für das gesamte Unternehmen und stellt sicher, dass kryptografische Entscheidungen nicht dem Zufall oder der individuellen Präferenz einzelner Administratoren überlassen bleiben.

NIS2 Mindestmaßnahme Nr. 8: Was das Gesetz fordert

Artikel 21 Absatz 2 der NIS2-Richtlinie listet zehn Mindestmaßnahmen auf, die betroffene Unternehmen umsetzen müssen. Nummer 8 lautet: „Konzepte und Verfahren für den Einsatz von Kryptografie und gegebenenfalls Verschlüsselung."

Das klingt knapp, hat es aber in sich. Die Formulierung „Konzepte und Verfahren" bedeutet, dass du nicht nur technisch verschlüsseln musst, sondern auch dokumentiert haben musst, nach welchen Grundsätzen du das tust. Ein Auditor wird nach der Richtlinie fragen, nicht nach der technischen Konfiguration. Letztere muss natürlich auch stimmen, aber ohne dokumentierte Richtlinie fehlt der Nachweis, dass du systematisch und nicht zufällig die richtigen Entscheidungen triffst.

Auch ISO 27001 adressiert das Thema. Control A.8.24 „Use of cryptography" verlangt Regeln für den effektiven Einsatz von Kryptografie, einschließlich des Managements kryptografischer Schlüssel. Wenn du ein ISMS nach ISO 27001 betreibst und gleichzeitig NIS2 erfüllen willst, deckst du mit einer sauberen Kryptografie-Richtlinie beide Anforderungen ab.

Was die Kryptografie-Richtlinie regeln muss

Bevor du losschreibst, hilft ein Blick auf die Bereiche, die eine vollständige Kryptografie-Richtlinie abdecken sollte. Jeder dieser Bereiche wird im Folgenden detailliert behandelt.

Geltungsbereich und Klassifizierung: Für welche Daten und Systeme gilt die Richtlinie? Welche Daten müssen verschlüsselt werden?

Zugelassene Algorithmen: Welche symmetrischen und asymmetrischen Verfahren sind erlaubt? Welche Hash-Funktionen dürfen eingesetzt werden?

Verbotene Algorithmen: Welche Verfahren dürfen nicht mehr verwendet werden? Was ist der Umgang mit Bestandssystemen?

Mindest-Schlüssellängen: Welche Schlüssellängen sind für welchen Algorithmus vorgeschrieben?

Schlüsselmanagement: Wie werden Schlüssel erzeugt, gespeichert, verteilt, rotiert und vernichtet?

Transportverschlüsselung: Welche TLS-Version ist Minimum? Welche Cipher Suites sind erlaubt?

Speicherverschlüsselung: Wie werden Daten at rest geschützt?

Verantwortlichkeiten: Wer entscheidet über kryptografische Standards? Wer setzt sie um?

Ausnahmen und Migration: Wie geht ihr mit Altsystemen um, die die Standards nicht erfüllen können?

Empfohlene Algorithmen und Schlüssellängen

Hier wird es konkret. Die folgende Übersicht orientiert sich an den Empfehlungen des BSI (Technische Richtlinie TR-02102) und des NIST.

Symmetrische Verschlüsselung

AES (Advanced Encryption Standard) ist der Standard für symmetrische Verschlüsselung und wird das auch auf absehbare Zeit bleiben. In der Richtlinie sollte AES-256 als Standardvorgabe stehen. AES-128 ist technisch gesehen ebenfalls sicher und darf für Anwendungsfälle mit geringerem Schutzbedarf zugelassen werden, aber AES-256 gibt dir einen komfortablen Sicherheitspuffer und ist mit moderner Hardware kaum langsamer.

Beim Betriebsmodus ist GCM (Galois/Counter Mode) die bevorzugte Wahl, weil er gleichzeitig Vertraulichkeit und Integrität sicherstellt (Authenticated Encryption). CBC (Cipher Block Chaining) ist weiterhin akzeptabel, muss aber mit einem separaten MAC kombiniert werden. ECB (Electronic Codebook) ist grundsätzlich verboten, weil er identische Klartextblöcke zu identischen Chiffretextblöcken verschlüsselt und damit Muster im Klartext sichtbar lässt.

ChaCha20-Poly1305 ist eine gute Alternative zu AES-GCM, insbesondere auf Geräten ohne AES-Hardware-Beschleunigung (ältere Mobilgeräte, IoT-Devices).

Asymmetrische Verschlüsselung und Schlüsselaustausch

RSA bleibt ein breit unterstützter Standard. Die Mindest-Schlüssellänge sollte bei 2048 Bit liegen, für Schlüssel mit einer Laufzeit über 2025 hinaus empfiehlt das BSI mindestens 3072 Bit. RSA-4096 bietet zusätzlichen Spielraum und ist bei den meisten Implementierungen unproblematisch.

Beim Padding ist RSA-OAEP (Optimal Asymmetric Encryption Padding) Pflicht. Das ältere PKCS#1 v1.5 Padding hat bekannte Schwachstellen (Bleichenbacher-Angriff) und darf nicht mehr verwendet werden.

Elliptische Kurven (ECC) bieten bei kürzeren Schlüssellängen ein vergleichbares Sicherheitsniveau wie RSA. Curve25519 (X25519 für Schlüsselaustausch, Ed25519 für Signaturen) ist die empfohlene Kurve, weil sie von einem unabhängigen Kryptografen (Daniel Bernstein) entwickelt wurde, seitenkanalresistent designiert ist und breite Unterstützung in modernen Bibliotheken hat.

Die NIST-Kurven P-256, P-384 und P-521 sind ebenfalls zugelassen und in manchen regulierten Umgebungen sogar vorgeschrieben. P-256 entspricht in der Sicherheit ungefähr RSA-3072.

Für den Schlüsselaustausch sollte ECDH (Elliptic-Curve Diffie-Hellman) mit ephemeren Schlüsseln zum Einsatz kommen. Ephemere Schlüssel stellen Forward Secrecy sicher: Selbst wenn der langfristige private Schlüssel kompromittiert wird, können vergangene Sitzungen nicht entschlüsselt werden.

Hash-Funktionen

SHA-256 ist der Mindeststandard für alle Hash-Anwendungen. SHA-384 und SHA-512 sind ebenfalls zugelassen und bieten sich bei hohem Schutzbedarf an. SHA-3 (Keccak) ist eine Alternative, die auf einem völlig anderen mathematischen Prinzip basiert als SHA-2, in der Praxis aber noch weniger verbreitet ist.

Für das Hashing von Passwörtern gelten andere Regeln. Hier sind spezialisierte Funktionen vorgeschrieben: Argon2id ist die aktuelle Empfehlung (Gewinner des Password Hashing Competition). bcrypt bleibt akzeptabel, wenn Argon2 nicht verfügbar ist. scrypt ist ebenfalls zugelassen. Was dagegen nie für Passwörter verwendet werden darf, auch nicht mit Salt: einfaches SHA-256, MD5 oder SHA-1.

Digitale Signaturen

Für digitale Signaturen gelten dieselben Schlüssellängen wie für die Verschlüsselung. RSA-PSS ist das empfohlene Signaturverfahren (nicht RSA-PKCS#1 v1.5). Ed25519 ist für moderne Anwendungen die bevorzugte Wahl, weil die Signaturen klein sind, die Verifikation schnell ist und die Implementierung robust gegen Seitenkanalangriffe.

Deprecated: Diese Algorithmen müssen raus

Ebenso wichtig wie die Liste der zugelassenen Verfahren ist die explizite Liste der verbotenen Algorithmen. Kryptografie altert, und was vor 15 Jahren sicher war, ist es heute nicht mehr.

DES (Data Encryption Standard): Seit den 1990er Jahren als unsicher bekannt, mit nur 56 Bit Schlüssellänge. Kann mit moderner Hardware in wenigen Stunden gebrochen werden. Muss in jedem System deaktiviert werden.

3DES (Triple DES): War als Übergangsverfahren gedacht und hat seinen Zweck erfüllt. Seit 2023 vom NIST als deprecated eingestuft. Die effektive Sicherheit liegt bei nur 112 Bit (statt der theoretischen 168 Bit), und die Sweet32-Attacke hat gezeigt, dass die kurze Blocklänge ein reales Problem darstellt. Migration auf AES ist Pflicht.

MD5: Kollusionsangriffe sind seit 2004 praktisch durchführbar. MD5 darf weder für digitale Signaturen noch für Integritätsprüfungen sicherheitsrelevanter Daten verwendet werden. Die einzige noch akzeptable Verwendung ist die nicht-kryptografische Deduplizierung, aber selbst dort sollte man besser auf xxHash oder BLAKE3 setzen.

SHA-1: Kollusionsangriffe wurden 2017 von Google (SHAttered) praktisch demonstriert. CAs stellen seit 2016 keine SHA-1-Zertifikate mehr aus. SHA-1 muss aus allen sicherheitsrelevanten Anwendungen entfernt werden.

RC4: Bereits 2015 durch RFC 7465 für TLS verboten. Statistische Schwächen in der Schlüsselstromgenerierung machen RC4 für jede kryptografische Anwendung ungeeignet.

Für Bestandssysteme, die diese Algorithmen noch verwenden, muss die Richtlinie einen Migrationsplan vorsehen. Das bedeutet: eine Inventarisierung aller Systeme mit deprecated Kryptografie, eine Risikobewertung für jedes System und einen Zeitplan für die Migration. Systeme, die nicht migriert werden können, brauchen kompensierende Maßnahmen wie Netzwerksegmentierung oder verstärktes Monitoring.

Schlüsselmanagement: Der gesamte Lifecycle

Die besten Algorithmen nützen wenig, wenn die Schlüssel schlecht verwaltet werden. Ein kompromittierter Schlüssel entwertet die gesamte Verschlüsselung. Das Schlüsselmanagement ist deshalb der Kern jeder Kryptografie-Richtlinie.

Schlüsselerzeugung

Kryptografische Schlüssel müssen mit einem kryptografisch sicheren Zufallsgenerator (CSPRNG) erzeugt werden. Das klingt selbstverständlich, ist aber in der Praxis eine häufige Fehlerquelle. Die Richtlinie sollte festlegen, dass Schlüssel ausschließlich durch zugelassene Werkzeuge und Bibliotheken erzeugt werden. Beispiele sind /dev/urandom unter Linux, CryptGenRandom unter Windows oder die jeweiligen Standardbibliotheken der Programmiersprache (z.B. secrets in Python, crypto/rand in Go).

Manuelle Schlüsselerzeugung durch Eingabe von Passwörtern ist nur dann akzeptabel, wenn eine Key Derivation Function (KDF) wie PBKDF2, scrypt oder Argon2 mit ausreichend Iterationen zum Einsatz kommt.

Für hochkritische Schlüssel, etwa CA-Root-Keys oder Master-Keys eines Key Management Systems, sollte die Erzeugung in einem Hardware Security Module (HSM) oder zumindest auf einem air-gapped System mit Vier-Augen-Prinzip erfolgen.

Schlüsselspeicherung

Der private Schlüssel ist das Kronjuwel. Die Richtlinie muss festlegen, wo und wie Schlüssel gespeichert werden dürfen. Klartext-Schlüssel in Konfigurationsdateien, im Quellcode oder in Datenbanken sind grundsätzlich verboten. Das gilt auch für Environment-Variablen, die oft fälschlich als „sicher" betrachtet werden, aber in Logs, Crash-Dumps und Container-Inspektionen auftauchen können.

Für die Speicherung kommen infrage: Hardware Security Module (HSM), die die Schlüssel nie in Software extrahierbar machen; Key Management Systeme wie HashiCorp Vault, AWS KMS oder Azure Key Vault; verschlüsselte Keystores wie Java KeyStore (JKS) oder PKCS#12, wobei das Passwort für den Keystore selbst wieder sicher verwahrt werden muss.

Der Zugriff auf Schlüssel muss nach dem Least-Privilege-Prinzip geregelt sein. Nur die Dienste und Personen, die einen Schlüssel tatsächlich benötigen, dürfen Zugriff haben. Jeder Zugriff sollte protokolliert werden.

Schlüsselrotation

Schlüssel haben eine begrenzte Lebensdauer. Die Richtlinie sollte Rotationsintervalle festlegen, abgestuft nach Schlüsseltyp und Kritikalität. Eine Orientierung: TLS-Zertifikate werden jährlich erneuert, bei Let's Encrypt sogar alle 90 Tage. API-Keys und Tokens sollten mindestens jährlich rotiert werden, bei hohem Schutzbedarf häufiger. Symmetrische Datenverschlüsselungsschlüssel werden typischerweise jährlich rotiert, wobei Key Wrapping die Migration vereinfacht. Schlüssel für die Festplattenverschlüsselung werden bei Personalwechsel oder Verdacht auf Kompromittierung rotiert.

Automatisierte Rotation ist manueller Rotation vorzuziehen, weil sie zuverlässiger ist und Ausfallzeiten vermeidet. Die Richtlinie sollte festlegen, dass neue Systeme von Anfang an mit automatisierter Schlüsselrotation geplant werden.

Schlüsselvernichtung

Wenn ein Schlüssel nicht mehr benötigt wird oder kompromittiert wurde, muss er sicher vernichtet werden. Sicheres Löschen bedeutet nicht „Datei löschen", sondern Überschreiben des Speicherbereichs mit Zufallsdaten und anschließende Verifikation. Bei HSMs bieten die Geräte eigene Löschfunktionen. Backups des Schlüssels müssen ebenfalls vernichtet werden, auch auf Offline-Medien.

Die Richtlinie sollte auch regeln, wie lange alte Schlüssel für die Entschlüsselung archivierter Daten vorgehalten werden müssen. Wenn verschlüsselte Daten eine Aufbewahrungsfrist von zehn Jahren haben, muss der Entschlüsselungsschlüssel ebenfalls zehn Jahre sicher verwahrt werden, auch wenn er für neue Verschlüsselungen nicht mehr verwendet wird.

Notfallverfahren bei Kompromittierung

Für den Fall, dass ein Schlüssel kompromittiert wird, muss die Richtlinie einen klaren Prozess definieren: sofortige Sperrung des kompromittierten Schlüssels (Revocation), Erzeugung eines neuen Schlüssels, Bewertung des Schadens (welche Daten waren betroffen?), Neuausstellung betroffener Zertifikate und Benachrichtigung betroffener Kommunikationspartner. Diese Schritte sollten nicht erst im Ernstfall erarbeitet, sondern vorher dokumentiert und mindestens einmal jährlich geübt werden.

Transportverschlüsselung: TLS richtig konfigurieren

Die Transportverschlüsselung betrifft praktisch jedes Unternehmen, weil nahezu alle Systeme über HTTPS, SMTPS, IMAPS oder andere TLS-gesicherte Protokolle kommunizieren.

TLS-Minimalversion

TLS 1.2 ist die absolute Minimalversion. TLS 1.0 und 1.1 sind seit RFC 8996 (März 2021) offiziell als deprecated eingestuft und müssen deaktiviert werden. SSL in allen Versionen (SSLv2, SSLv3) ist selbstverständlich verboten.

TLS 1.3 sollte für alle neuen Implementierungen als Standard gesetzt werden. Es bietet signifikante Verbesserungen: Der Handshake ist schneller (1-RTT statt 2-RTT), unsichere Cipher Suites wurden entfernt (kein RSA Key Exchange, kein CBC, kein RC4), und Forward Secrecy ist obligatorisch.

Cipher Suites

Nicht alle Cipher Suites in TLS 1.2 sind gleich sicher. Die Richtlinie sollte eine Positivliste definieren. Empfohlene Cipher Suites für TLS 1.2 beinhalten ECDHE-basierte Suites mit AES-GCM oder ChaCha20-Poly1305, beispielsweise TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 und TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384.

Verboten sind Cipher Suites mit statischem RSA Key Exchange (kein Forward Secrecy), Suites mit NULL-Verschlüsselung, Suites mit DES, 3DES oder RC4, Suites mit MD5, Export-Cipher-Suites (absichtlich geschwächt) und Anonymous-DH-Suites (kein Zertifikat, anfällig für MITM).

In TLS 1.3 ist die Cipher-Suite-Konfiguration weniger komplex, weil das Protokoll nur sichere Optionen zulässt. Die drei standardmäßig verfügbaren Suites (TLS_AES_256_GCM_SHA384, TLS_AES_128_GCM_SHA256, TLS_CHACHA20_POLY1305_SHA256) sind alle empfehlenswert.

Zertifikatmanagement

Die Richtlinie sollte auch das Management von TLS-Zertifikaten regeln: Mindest-Schlüssellänge für Zertifikate (RSA-2048, besser RSA-3072 oder ECDSA P-256), Verwendung vertrauenswürdiger CAs (keine Self-Signed-Zertifikate in Produktionsumgebungen), automatisierte Erneuerung (ACME-Protokoll, Let's Encrypt) und Monitoring der Zertifikatslaufzeiten.

Praxisbeispiel: Gliederung einer Kryptografie-Richtlinie

Zum Abschluss eine Gliederung, die du als Ausgangspunkt für deine eigene Richtlinie verwenden kannst. Die Struktur ist bewusst so aufgebaut, dass sie sowohl NIS2 als auch ISO 27001 A.8.24 abdeckt.

1. Zweck und Geltungsbereich Beschreibt, warum die Richtlinie existiert und für welche Systeme, Daten und Personen sie gilt. Typischerweise gilt sie für alle IT-Systeme und Daten des Unternehmens, einschließlich Cloud-Dienste und Systeme von Drittanbietern, die Unternehmensdaten verarbeiten.

2. Begriffsdefinitionen Erklärt die wichtigsten Fachbegriffe (symmetrische/asymmetrische Verschlüsselung, Hashing, Schlüsselpaar, Forward Secrecy), damit auch Nicht-Kryptografen die Richtlinie verstehen können.

3. Datenklassifizierung und Verschlüsselungspflicht Definiert, welche Datenklassen verschlüsselt werden müssen. Beispielsweise: Vertrauliche und streng vertrauliche Daten müssen bei der Übertragung und Speicherung verschlüsselt werden. Interne Daten müssen bei der Übertragung über öffentliche Netze verschlüsselt werden. Öffentliche Daten unterliegen keiner Verschlüsselungspflicht.

4. Zugelassene Algorithmen und Mindest-Schlüssellängen Tabellarische Übersicht der erlaubten Algorithmen mit Mindest-Schlüssellängen, gegliedert nach symmetrischer Verschlüsselung, asymmetrischer Verschlüsselung, Hashing und Passwort-Hashing.

5. Verbotene Algorithmen Explizite Liste der verbotenen Verfahren mit Begründung und Migrationszeitraum für Bestandssysteme.

6. Schlüsselmanagement Regelungen für den gesamten Lifecycle: Erzeugung, Speicherung, Verteilung, Rotation, Archivierung und Vernichtung. Inklusive Verantwortlichkeiten und Zugriffsregelungen.

7. Transportverschlüsselung TLS-Minimalversion, erlaubte Cipher Suites, Zertifikatmanagement, HSTS-Konfiguration.

8. Speicherverschlüsselung Regelungen für Full Disk Encryption, Datenbankverschlüsselung, Backup-Verschlüsselung und Verschlüsselung in der Cloud.

9. Verantwortlichkeiten Wer pflegt die Richtlinie? Wer genehmigt Ausnahmen? Wer überprüft die Einhaltung? Typischerweise: Der ISB pflegt die Richtlinie, die IT setzt sie um, und interne Audits überprüfen die Einhaltung.

10. Ausnahmen Verfahren für den Umgang mit Systemen, die die Richtlinie nicht erfüllen können. Jede Ausnahme muss dokumentiert, risikobewerted und zeitlich befristet sein.

11. Review und Aktualisierung Die Richtlinie wird mindestens jährlich überprüft und bei neuen Erkenntnissen zu kryptografischen Schwächen anlassbezogen aktualisiert.

Typische Stolperfallen in der Praxis

Aus Audits und Beratungsprojekten tauchen immer wieder dieselben Probleme auf, die du bei der Erstellung deiner Richtlinie direkt adressieren kannst.

Richtlinie ohne Inventar. Du kannst keine Kryptografie-Standards durchsetzen, wenn du nicht weißt, wo Kryptografie eingesetzt wird. Ein aktuelles IT-Asset-Inventar ist die Voraussetzung. Vor der Richtlinie kommt die Bestandsaufnahme: Welche Systeme verschlüsseln was, mit welchen Algorithmen und Schlüssellängen?

Deprecated Algorithmen in Altsystemen. Fast jedes Unternehmen hat irgendwo ein altes System, das noch 3DES oder SHA-1 verwendet. Die Richtlinie muss damit ehrlich umgehen: nicht verbieten und ignorieren, sondern dokumentieren, risikobewerten und einen Migrationsplan erstellen.

Schlüssel im Quellcode. Entwickler committen regelmäßig API-Keys, Zertifikate oder Passwörter in Git-Repositories. Die Richtlinie sollte auf Pre-Commit-Hooks und Secret-Scanning-Tools verweisen, die das automatisiert verhindern.

Fehlende Rotation. Viele Unternehmen erzeugen Schlüssel einmal und vergessen sie dann. Die Richtlinie muss klare Rotationsintervalle definieren und die Einhaltung überwachen, idealerweise automatisiert.

Kein Notfallverfahren. Wenn ein privater Schlüssel kompromittiert wird und niemand weiß, was zu tun ist, gehen wertvolle Stunden verloren. Das Notfallverfahren sollte so konkret sein, dass die zuständige Person nachts um drei danach handeln kann.

Post-Quantum-Kryptografie: Schon jetzt vorbereiten?

Ein Thema, das zunehmend relevant wird, ist die Frage, wie sich Quantencomputer auf die heutigen kryptografischen Verfahren auswirken. RSA und ECC basieren auf mathematischen Problemen (Faktorisierung und diskreter Logarithmus), die ein leistungsfähiger Quantencomputer mit Shors Algorithmus lösen könnte.

Das NIST hat 2024 die ersten Post-Quantum-Algorithmen standardisiert: ML-KEM (ehemals CRYSTALS-Kyber) für Schlüsselkapselung und ML-DSA (ehemals CRYSTALS-Dilithium) für digitale Signaturen. Für die meisten Unternehmen ist eine sofortige Migration nicht notwendig und auch nicht praktikabel, weil die Bibliotheksunterstützung noch lückenhaft ist.

Was du aber jetzt schon tun kannst: Die Kryptografie-Richtlinie sollte einen Abschnitt enthalten, der die Beobachtung der Post-Quantum-Entwicklung zur Aufgabe des ISB macht. Außerdem sollten Daten mit langer Lebensdauer, die heute verschlüsselt gespeichert werden und noch in zehn oder zwanzig Jahren vertraulich sein müssen, besondere Aufmerksamkeit bekommen. Ein Angreifer könnte heute verschlüsselte Daten mitschneiden und in der Zukunft mit einem Quantencomputer entschlüsseln (Harvest now, decrypt later).

Hybride Verfahren, die klassische und Post-Quantum-Algorithmen kombinieren, bieten hier eine Übergangslösung. TLS 1.3 unterstützt bereits hybride Schlüsselaustauschmechanismen wie X25519Kyber768Draft00.

Von der Richtlinie zur Umsetzung

Eine Kryptografie-Richtlinie ist nur so gut wie ihre Umsetzung. Nachdem du die Richtlinie erstellt hast, stehen drei Aufgaben an.

Erstens die Bestandsaufnahme: Inventarisiere alle Systeme, die Kryptografie einsetzen, und gleiche sie mit den Vorgaben der Richtlinie ab. Wo gibt es Abweichungen? Wo werden verbotene Algorithmen eingesetzt? Wo fehlt Schlüsselrotation?

Zweitens die technische Härtung: Setze die Vorgaben auf den Systemen um. TLS-Konfigurationen anpassen, Cipher Suites einschränken, Schlüsselrotation automatisieren, Secret-Scanning einrichten.

Drittens das Monitoring: Überwache die Einhaltung kontinuierlich. Tools wie SSL Labs, testssl.sh oder Mozilla Observatory können die TLS-Konfiguration externer Endpunkte prüfen. Interne Scans sollten regelmäßig durchgeführt und die Ergebnisse dokumentiert werden.

Die Richtlinie selbst sollte mindestens einmal jährlich überprüft und bei Bedarf aktualisiert werden. ISMS Lite erinnert dich automatisch an fällige Richtlinien-Reviews und dokumentiert den gesamten Richtlinien-Lifecycle von der Erstellung bis zur Ablösung. Anlässe für außerplanmäßige Reviews sind neue BSI- oder NIST-Empfehlungen, bekannt gewordene Schwächen in zugelassenen Algorithmen und wesentliche Änderungen an der IT-Infrastruktur.

Kryptografie ist kein Thema, das du einmal regelst und dann vergisst. Es ist ein lebendiger Teil deines ISMS, der kontinuierliche Aufmerksamkeit verdient, weil sich die Bedrohungslandschaft und die technischen Möglichkeiten ständig weiterentwickeln.

Weiterführende Artikel

• Verschlüsselung im Unternehmen: Was du wirklich umsetzen musst
• NIS2 für den Mittelstand: Was du wissen musst und was jetzt zu tun ist
• Informationssicherheitsrichtlinie erstellen: Aufbau, Inhalte und Praxis
• Schutzbedarfsfeststellung: Systematisch bewerten, was schützenswert ist
• ISMS-Dokumentation im Überblick: Was du wirklich brauchst