Für die meisten IT- und E- software -Anbieter ist die Zertifizierung nach ISO 27001 längst nicht mehr nur ein nettes Extra. Sie ist zu einer Voraussetzung für die Geschäftstätigkeit geworden. In Sicherheitsfragebögen für Kunden, Ausschreibungen und Risikobewertungen von Lieferanten wird zunehmend eine aktuelle Zertifizierung verlangt, bevor ein Geschäft abgeschlossen werden kann. Das bedeutet, dass ein abgelaufenes Zertifikat nicht mehr nur ein Compliance-Problem darstellt, sondern ein Umsatzrisiko.
Die Kryptografie steht im Mittelpunkt dieses Wandels. Mit der Überarbeitung des Standards im Jahr 2022 wurden Kryptografie und Schlüsselverwaltung in einer einzigen, klar definierten Kontrollmaßnahme zusammengefasst: Anhang A 8.24, „Einsatz von Kryptografie“. Dieser Leitfaden erläutert, was sich in der Überarbeitung von 2022 geändert hat, was die Kontrollmaßnahme 8.24 konkret verlangt und wie Sie dies einem Auditor vor Ihrem nächsten Überwachungsbesuch nachweisen können.
Was hat sich in ISO/IEC 27001:2022 geändert?
Im Rahmen der Überarbeitung von 2022 wurde Anhang A neu strukturiert und in 93 Kontrollmaßnahmen unterteilt, die vier Themenbereichen zugeordnet sind. Im Bereich Kryptografie besteht die wichtigste Änderung in einer Zusammenführung: Die beiden separaten Kontrollmaßnahmen der Ausgabe von 2013 (A.10.1.1, „Richtlinie zur Verwendung kryptografischer Kontrollmaßnahmen“, und A.10.1.2, „Schlüsselverwaltung“) wurden zu einer einzigen Kontrollmaßnahme zusammengefasst: 8.24, „Verwendung von Kryptografie“.
Diese Konsolidierung ist entscheidend dafür, wie Teams ihr Kryptografieprogramm dokumentieren und nachweisen. Anstatt Richtlinien und Schlüsselverwaltung als zwei lose miteinander verbundene Anforderungen zu behandeln, erwartet Abschnitt 8.24 ein einheitliches Gesamtkonzept: einen definierten Ansatz für die Kryptografie und einen verwalteten Lebenszyklus für die dahinterstehenden Schlüssel, die miteinander verknüpft und durch Nachweise untermauert sind.
Was die Vorschrift 8.24 tatsächlich vorschreibt
Die Vorschrift 8.24 stützt sich auf zwei Säulen.
Zum einen handelt es sich um eine dokumentierte, risikobasierte Kryptografie-Richtlinie, in der zugelassene Algorithmen und Mindestanforderungen an die Schlüsselstärke festgelegt sind. Zum anderen geht es um einen kontrollierten Schlüssellebenszyklus, der die gesamte Lebensdauer eines Schlüssels abdeckt: Generierung, Verteilung, Sperrung, Umgang mit kompromittierten Schlüsseln, Wiederherstellung verlorener Schlüssel, Speicherung, Rotation, Sicherung und Vernichtung.
Der entscheidende Punkt für IT- und „ software “-Unternehmen ist, wie Auditoren dies überprüfen. Sie verifizieren 8.24 anhand von betrieblichen Nachweisen und nicht allein anhand von Richtlinienerklärungen. In der Praxis bedeutet dies: das Zertifikats- und Schlüsselinventar, Rotationsprotokolle, aus denen hervorgeht, dass das in der Richtlinie festgelegte Intervall tatsächlich eingehalten wurde, Ausgabedaten zu „ TLS “ und zur Verschlüsselungskonfiguration, HSM- oder KMS-Zugriffsprotokolle sowie Vernichtungsprotokolle mit Unterschrift. Eine gut formulierte Richtlinie, deren Einhaltung niemand nachweisen kann, wird einen Prüfer nicht zufriedenstellen. Und da sich 8.24 auf das Produkt bezieht, umfasst sein Geltungsbereich routinemäßig auch die im Produkt selbst eingebettete Kryptografie, nicht nur die interne IT-Umgebung.
Warum die Einhaltung der Kryptografie-Vorgaben der ISO 27001 für IT-Anbieter wichtig ist
Die Zertifizierung nach ISO 27001 ist technisch gesehen freiwillig. In der Praxis ist sie für Anbieter von IT- und „ software “-Lösungen jedoch zu einer de facto geschäftlichen Voraussetzung geworden. Sicherheitsfragebögen, Ausschreibungen und Lieferantenrisikobewertungen verlangen zunehmend eine aktuelle Zertifizierung als Voraussetzung für eine Geschäftsbeziehung. Daher können Lücken in Ihren kryptografischen Kontrollmaßnahmen die Beschaffung verzögern und Geschäfte kosten; dies wirkt sich auf zwei Arten auf die Beschaffung aus: Entweder taucht es direkt in einer Antwort auf einen Sicherheitsfragebogen auf, die Sie nicht belegen können, oder es wird zu einer Nichtkonformität, die das Zertifikat selbst gefährdet.
Hinzu kommt noch die zeitliche Dimension. Da es sich bei ISO 27001 um eine Norm für Managementsysteme handelt, wird 8.24 nicht nur einmal geprüft und dann vergessen. Bei Überwachungsaudits wird das ISMS stichprobenartig geprüft, anstatt jede einzelne Kontrollmaßnahme zu testen; daher kann 8.24 in einem bestimmten Jahr zur Sprache kommen oder auch nicht. Bei der Rezertifizierung verhält es sich anders: Hier wird bestätigt, dass das System alle Anforderungen der Norm erfüllt, nicht nur die Bereiche, die bei den Überwachungsaudits stichprobenartig geprüft wurden. In der Praxis lässt sich nicht vorhersagen, in welchem Jahr die Kryptografie geprüft wird. Dieser Rhythmus belohnt Organisationen, die eine kontinuierliche, nachweisbare Kontrolle über die Kryptografie aufrechterhalten, anstatt vor jedem Audit hastig versuchen zu müssen, diese nachzurüsten.
Es ist wichtig zu wissen, wie es tatsächlich zum Verlust eines Zertifikats kommt: Eine schwerwiegende Nichtkonformität führt nicht sofort zum Erlöschen des Zertifikats. Zertifizierungsstellen legen eine bestimmte Frist fest, innerhalb derer der Mangel behoben werden muss, und eine Aussetzung oder ein Entzug erfolgt erst, wenn dieser nicht behoben wird. Das geschäftliche Risiko besteht weniger darin, dass „wir ein Audit nicht bestanden haben“, als vielmehr darin, dass „wir ein Quartal lang eine offene schwerwiegende Nichtkonformität hatten, die wir offenlegen mussten“.
Wie sich 8.24 auf konkrete kryptografische Kontrollmaßnahmen abbilden lässt
Kontrollpunkt 8.24 steht nicht für sich allein. Er steht in Zusammenhang mit einer Reihe praktischer Kontrollbereiche, von denen die Gutachter erwarten, dass sie im gesamten zertifizierten Geltungsbereich zusammenwirken.
Eine dokumentierte Richtlinie zur Kryptografie und Schlüsselverwaltung (Anhang A 8.24)
Im Kern fordert 8.24 eine themenspezifische Richtlinie, die zugelassene Algorithmen, Mindestschlüssellängen und Regeln für den Lebenszyklus festlegt. Diese Richtlinie sollte direkt mit der ISMS-Risikobewertung verknüpft sein, sodass jede kryptografische Entscheidung auf ein dokumentiertes Risiko zurückzuführen ist und nicht auf eine Präferenz.
Der Lebenszyklus kryptografischer Schlüssel (Anhang A 8.24)
Der Lebenszyklus ist der Bereich, in dem starke Kryptografie am häufigsten versagt. Prüfer erwarten eine zentralisierte Erstellung, Verteilung, Rotation und Vernichtung von Schlüsseln und Zertifikaten, einschließlich derer, die in ausgelieferten „ software “ eingebettet sind, und zwar gestützt durch einen lückenlosen Prüfpfad. Die Sperrung, der Umgang mit kompromittierten Schlüsseln, die Wiederherstellung verlorener Schlüssel, die sichere Speicherung und die Datensicherung runden das Bild ab.
Vertraulichkeit und Integrität von Daten (Anhang A 5.14, 8.20, 8.21; personenbezogene Daten gemäß 5.34)
Kryptografie dient dem Schutz von Daten. Gemäß Abschnitt 8.24 ist die Kryptografie der Mechanismus; die Kontrollmaßnahmen, die die Verpflichtung begründen, sind an anderer Stelle zu finden. Anhang A, Abschnitt 5.34 (Informationsübertragung) sowie die Abschnitte 8.20–8.21 (Netzwerksicherheit und Sicherheit von Netzwerkdiensten) regeln die Verschlüsselung während der Übertragung. Von der PKI ausgestellte Zertifikate sichern Kundendaten sowohl im Ruhezustand als auch während der Übertragung innerhalb des zertifizierten Geltungsbereichs. Für Anbieter von „ software “-Lösungen erstreckt sich dieser Geltungsbereich üblicherweise auf Multi-Tenant-SaaS-Umgebungen, in denen sich viele Kunden dieselbe Infrastruktur teilen.
Produktkryptografie (Anhang A 8.25, 8.26, 8.28)
Wenn Kryptografie in Ihren Produkten integriert ist, prüfen die Prüfer anhand des sicheren Entwicklungslebenszyklus (8.25), der Anforderungen an die Anwendungssicherheit (8.26) und der sicheren Programmierung (8.28), ob die in Ihrer Richtlinie 8.24 festgelegten Entscheidungen bezüglich Algorithmen und Schlüssellängen tatsächlich in den Quellcode einfließen. Die Lieferantenkontrollen beziehen sich auf importierte Bibliotheken; diese wiederum beziehen sich auf Ihren eigenen Code.
Sichere Authentifizierung (Anhang A 8.5)
Anhang A 8.5 bringt das Thema Authentifizierung in die Diskussion um Kryptografie ein. Die zertifikatsbasierte Authentifizierung verringert die Abhängigkeit von gemeinsamen Geheimnissen und statischen Passwörtern sowohl beim Kundenzugang als auch beim administrativen Zugriff und ersetzt Anmeldedaten, die leicht offengelegt werden können, durch Identitäten, die weitaus schwieriger zu missbrauchen sind.
Anbieter und vererbte Kryptografie (Anhang A 5.21, 8.8)
Moderne software nutzen Kryptografie, die aus Bibliotheken und von Drittanbietern stammt. Anhang A 8.24 schreibt vor, dass ein Schlüsselverwaltungssystem vorhanden sein muss, um die Sperrung von Schlüsseln und kompromittierte Schlüssel zu handhaben. Jede dieser Pflichten gilt pro Schlüssel, und eine schlüsselspezifische Pflicht setzt voraus, dass bekannt ist, welche Schlüssel existieren. Für Anhang A 8.8 ist ein genaues Bestandsverzeichnis der IKT-Ressourcen eine Voraussetzung für ein wirksames Schwachstellenmanagement. Anhang A 5.21 weitet die Frage auf die IKT-Lieferkette aus, in der es sich bei den Komponenten um den Code anderer handelt. Im Gesamtkontext betrachtet ist das Bestandsverzeichnis keine ausdrücklich genannte Anforderung; es ist jedoch der einzige praktische Weg, um vier der genannten Anforderungen nachzuweisen.
Erklärung zur Rückverfolgbarkeit der Anwendbarkeit (Abschnitt 6.1.3)
Schließlich führt Abschnitt 6.1.3 alles wieder auf die Governance zurück. Eine zentralisierte Berichterstattung, die kryptografische Kontrollen mit dokumentierten Entscheidungen zur Risikobehandlung verknüpft, bietet den Prüfern einen klaren, nachvollziehbaren Zusammenhang zwischen einer Kontrolle und dem damit verbundenen Risiko.
Vorbereitung auf die Prüfung: Was die Prüfer untersuchen
Wenn ein Gutachter die Stufe 8.24 erreicht, sucht er nach Beweisen und nicht nach Absichten. Die folgenden Bereiche werden von ihm systematisch untersucht:
- Eine dokumentierte Kryptografie-Richtlinie, die sowohl interne Systeme als auch ausgelieferte Produkte abdeckt und in der zugelassene Algorithmen, Mindestschlüssellängen sowie die Bedingungen, unter denen eine Verschlüsselung vorgeschrieben ist, festgelegt sind.
- Nachweise zum Lebenszyklus von Schlüsseln: Aufzeichnungen, keine Verfahren: Rotationsprotokolle, aus denen hervorgeht, dass das in der Richtlinie festgelegte Intervall eingehalten wurde, Vernichtungsprotokolle mit Unterschrift, Aktivitätsprotokolle für jeden einzelnen Schlüssel sowie Aktivierungs- und Deaktivierungsdaten.
- Erklärung zur Rückverfolgbarkeit der Anwendbarkeit, die die Einbeziehung von 8.24 begründet und diese mit der zugrunde liegenden Risikobewertung verknüpft.
- Einhaltung gesetzlicher und gerichtlicher Vorschriften, einschließlich Exportkontrollen und Überlegungen zur Datenlokalisierung.
- Eine aktuelle Übersicht über Zertifikate und Schlüssel mit Angabe der jeweiligen Inhaber und Ablaufdaten, einschließlich der in den Versionen von „ software “ eingebetteten Schlüssel.
- Prüfung der 8.24-Kontrollen durch die interne Revision, wobei die Ergebnisse im Rahmen des ISMS-Zyklus von der Geschäftsleitung überprüft werden.
- Richtlinie zur Konfigurationsübereinstimmung. Die Prüfer vergleichen die in Ihrer Richtlinie zugelassenen Algorithmen und Schlüssellängen mit den tatsächlich eingesetzten. Eine Abweichung zwischen Richtlinie und tatsächlicher Situation gilt als Nichtkonformität, selbst wenn sowohl die Richtlinie als auch die Konfiguration für sich genommen vertretbar sind.
Der rote Faden ist Eigentumsrecht und Rückverfolgbarkeit. Jede Aussage, die Sie zur Kryptografie treffen, sollte durch ein Artefakt untermauert werden, das ein Prüfer untersuchen kann.
Wie Keyfactor helfen Keyfactor
Bei Meeting 8.24 geht es letztlich um Transparenz, festgelegte Regeln und eine disziplinierte Schlüsselverwaltung in großem Maßstab. Die Plattform von Keyfactordeckt sich direkt mit den oben genannten Kontrollbereichen.
- AgileSec erstellt ein Verzeichnis der kryptografischen Komponenten, das die Lieferantenüberprüfung unterstützt, und erstellt Nachweise in Form von Anwendbarkeitserklärungen für eingebettete oder Komponenten von Drittanbietern.
- EJBCA stellt die PKI bereit, die die durch Zertifikate gesicherte Vertraulichkeit und Integrität der Daten gewährleistet, sowie ein zentralisiertes Schlüssellebenszyklusmanagement, einschließlich der in ausgelieferten „ software “ eingebetteten Schlüssel.
- Keyfactor Command sorgt für die Einhaltung der Richtlinien, bietet Transparenz über den gesamten Lebenszyklus der Schlüssel, verwaltet ein Zertifikats- und Schlüsselinventar und erstellt Rückverfolgbarkeitsberichte gemäß der „Statement of Applicability“.
Zusammen bilden diese Funktionen ein einheitliches Referenzsystem für die Kryptografie, das genau die Nachweise liefert, die ein ISO 27001-Auditor verlangt, anstatt die Teams dazu zu zwingen, diese manuell zusammenzustellen.
Fazit und nächste Schritte
Die Botschaft, die sich durch die Version 8.24 zieht, ist einheitlich: Die Kontrolle legt mehr Wert auf Eigentumsverhältnisse, Rückverfolgbarkeit und Nachweise als auf Grundsatzerklärungen. Die Zertifizierung hängt weniger davon ab, ob ein Dokument die richtigen Formulierungen enthält, sondern vielmehr davon, ob auf Anfrage nachgewiesen werden kann, wie die Kryptografie geregelt ist und wie die Schlüssel verwaltet werden.
Der nächste praktische Schritt ist ganz einfach: Überprüfen Sie vor Ihrem nächsten Audit Ihre aktuelle Kryptografie-Richtlinie und Ihren Schlüsselbestand anhand von Abschnitt 8.24 und zentralisieren Sie die entsprechenden Nachweise, anstatt sie in verstreuten Tabellenkalkulationen zu erfassen.
Möchten Sie erfahren, wie automatisierte Kryptografie und das Schlüssellebenszyklusmanagement mit Anhang A 8.24 in Einklang stehen? Fordern Sie eine Demo an.
Haben Sie Fragen zur Kryptografie im Zusammenhang mit der Norm ISO 27001? Wir haben die Antworten.
Was ist ISO/IEC 27001 Anhang A 8.24?
Anhang A 8.24, „Einsatz von Kryptografie“, ist die Kontrollmaßnahme der Norm ISO 27001:2022, die regelt, wie eine Organisation Kryptografie einsetzt. Sie verlangt eine dokumentierte, risikobasierte Kryptografie-Richtlinie und einen verwalteten Schlüssellebenszyklus, der durch operative Nachweise und nicht allein durch Richtlinienerklärungen belegt wird. Anhang A selbst fasst die Kontrollmaßnahme in einem einzigen Satz zusammen; die detaillierten Anforderungen sind in der Norm ISO/IEC 27002:2022 festgelegt, die Auditoren als Maßstab heranziehen.
Was hat sich bei der Kryptografie in der Überarbeitung von 2022 geändert?
Mit der Überarbeitung von 2022 wurde Anhang A neu strukturiert und umfasst nun 93 Kontrollmaßnahmen, die sich auf vier Themenbereiche verteilen. Die in der Ausgabe von 2013 getrennt aufgeführten Kontrollmaßnahmen für Kryptografie und Schlüsselverwaltung wurden zu einer einzigen Kontrollmaßnahme (8.24) zusammengefasst.
Bezieht sich 8.24 auch auf Kryptografie in den von uns ausgelieferten Produkten?
Ja. Für Unternehmen aus den Bereichen „ software “ und IT-Dienstleistungen umfasst der Geltungsbereich von 8.24 routinemäßig auch die im Produkt selbst integrierte Kryptografie und nicht nur die interne IT-Umgebung.
Was muss eine vorschriftsmäßige Kryptografie-Richtlinie beinhalten?
Es sollte sich um eine themenspezifische Richtlinie handeln, in der zugelassene Algorithmen, Mindestschlüssellängen und die Bedingungen, unter denen eine Verschlüsselung vorgeschrieben ist, festgelegt sind. Sie muss mit der ISMS-Risikobewertung verknüpft sein und sowohl interne Systeme als auch ausgelieferte Produkte abdecken.
Welche wesentlichen Nachweise zum Lebenszyklus erwarten Prüfer?
Prüfer erwarten nachweisbare Verfahren zur Schlüsselgenerierung, sicheren Speicherung, Rotation und Vernichtung – nicht nur eine schriftliche Richtlinie. Ein aktuelles Zertifikats- und Schlüsselverzeichnis mit namentlich genannten Verantwortlichen und Ablaufdaten untermauert dies.
Wie oft wird 8.24 geprüft?
Da es sich bei ISO 27001 um eine Norm für Managementsysteme handelt, wird 8.24 bei den jährlichen Überwachungsaudits geprüft und bei der alle drei Jahre stattfindenden Rezertifizierung vollständig überprüft.
Warum ist die Zertifizierung nach ISO 27001 aus geschäftlicher Sicht wichtig?
Die Zertifizierung ist für Anbieter von IT- und E- software -Lösungen mittlerweile zu einer de-facto geschäftlichen Voraussetzung geworden. In Sicherheitsfragebögen, Ausschreibungen und Lieferanten-Risikobewertungen wird zunehmend eine aktuelle Zertifizierung verlangt, sodass ein abgelaufenes Zertifikat den Umsatz direkt gefährden kann.
In welchem Zusammenhang steht 8.24 mit der Erklärung zur Anwendbarkeit?
Die Erklärung zur Anwendbarkeit muss die Einbeziehung von 8.24 begründen und einen Bezug zur zugrunde liegenden Risikobewertung herstellen. Eine zentralisierte Berichterstattung, in der kryptografische Kontrollmaßnahmen den dokumentierten Entscheidungen zur Risikobehandlung zugeordnet werden, unterstützt die Prüfung durch den Auditor gemäß Abschnitt 6.1.3.
