Para la mayoría de los proveedores de TI y de servicios de « software », la certificación ISO 27001 ha dejado de ser, sin que nadie se haya dado cuenta, un simple extra. Se ha convertido en una condición imprescindible para hacer negocios. Los cuestionarios de seguridad de los clientes, las solicitudes de propuestas y las evaluaciones de riesgo de los proveedores exigen cada vez más que se disponga de una certificación vigente antes de que un acuerdo pueda seguir adelante, lo que significa que un certificado caducado ya no es solo un problema de cumplimiento normativo. Es un riesgo para los ingresos.
La criptografía ocupa un lugar central en ese cambio. La revisión de 2022 de la norma agrupó la criptografía y la gestión de claves en un único control claramente definido: el anexo A, apartado 8.24, «Uso de la criptografía». Esta guía desglosa qué ha cambiado en la revisión de 2022, qué exige realmente el control 8.24 y cómo demostrarlo ante un auditor antes de tu próxima visita de supervisión.
¿Qué ha cambiado en la norma ISO/IEC 27001:2022?
La revisión de 2022 reestructuró el Anexo A en 93 controles organizados en cuatro temas. En lo que respecta a la criptografía, el cambio más importante es la consolidación: los dos controles independientes de la edición de 2013 (A.10.1.1, «Política sobre el uso de controles criptográficos», y A.10.1.2, «Gestión de claves») se fusionaron en un único control: 8.24, «Uso de la criptografía».
Esa consolidación es importante para la forma en que los equipos documentan y acreditan su programa criptográfico. En lugar de tratar la gestión de políticas y claves como dos requisitos vagamente relacionados entre sí, la sección 8.24 exige una visión coherente: un enfoque definido de la criptografía y un ciclo de vida gestionado para las claves que la sustentan, ambos vinculados entre sí y respaldados por pruebas.
Qué exige realmente la norma 8.24
La norma 8.24 se sustenta en dos pilares.
La primera es una política de criptografía documentada y basada en el riesgo que define los algoritmos autorizados y los niveles mínimos de seguridad de las claves. La segunda es una gestión del ciclo de vida de las claves que abarca toda la vida útil de una clave: generación, distribución, revocación, gestión de claves comprometidas, recuperación de claves perdidas, almacenamiento, rotación, copia de seguridad y destrucción.
El punto crítico para las empresas de TI y de « software » es cómo comprueban esto los auditores. Estos verifican el apartado 8.24 mediante pruebas operativas, no solo a través de declaraciones de políticas. En la práctica, esto significa el inventario de certificados y claves, los registros de rotación que demuestren que se ha cumplido efectivamente el intervalo establecido en la política, los resultados de la configuración de « TLS » y del cifrado, los registros de acceso al HSM o al KMS, y los registros de destrucción con firma de verificación. Una política bien redactada de la que nadie pueda demostrar que se está cumpliendo no satisfará a un evaluador. Y dado que la cláusula 8.24 se aplica al producto, su alcance incluye habitualmente la criptografía integrada en el propio producto, no solo el entorno informático interno.
Por qué es importante el cumplimiento de la norma ISO 27001 en materia de criptografía para los proveedores de TI
La certificación ISO 27001 es, técnicamente, voluntaria. En la práctica, para los proveedores de TI y de « software », se ha convertido en un requisito comercial de facto. Los cuestionarios de seguridad, las solicitudes de propuestas (RFP) y las evaluaciones de riesgo de los proveedores exigen cada vez más contar con una certificación vigente como condición para hacer negocios, por lo que una deficiencia en sus controles criptográficos puede paralizar el proceso de adquisición y costarle contratos; esto llega al departamento de compras por una de estas dos vías: o bien sale a la luz directamente en una respuesta a un cuestionario de seguridad que no puede justificar, o bien se convierte en un incumplimiento que pone en riesgo el propio certificado.
También hay que tener en cuenta la dimensión temporal. Dado que la norma ISO 27001 es una norma de sistemas de gestión, el apartado 8.24 no se comprueba una sola vez y luego se olvida. Las auditorías de vigilancia examinan el SGSI por muestreo, en lugar de comprobar todos y cada uno de los controles, por lo que el punto 8.24 puede aparecer o no en un año determinado. La recertificación es diferente: confirma que el sistema cumple todos los requisitos de la norma, no solo las áreas sometidas a muestreo durante la vigilancia. En la práctica, no se puede predecir en qué año se examinará la criptografía. Esa periodicidad recompensa a las organizaciones que mantienen un control continuo y con pruebas disponibles sobre la criptografía, en lugar de tener que apresurarse a reconstruirlo antes de cada auditoría.
Vale la pena saber cómo se pierde realmente un certificado: una no conformidad grave no lo invalida de inmediato. Los organismos de certificación establecen un plazo determinado para subsanar la no conformidad, y la suspensión o retirada solo se produce si no se subsana. El riesgo comercial no radica tanto en «no hemos superado una auditoría» como en «hemos pasado un trimestre con una no conformidad grave pendiente que hemos tenido que comunicar».
Cómo se corresponde la sección 8.24 con los controles criptográficos reales
El control 8.24 no existe de forma aislada. Está vinculado a un conjunto de áreas de control prácticas que los evaluadores esperan que funcionen de forma coordinada en todo el ámbito de la certificación.
Una política documentada sobre criptografía y gestión de claves (Anexo A, 8.24)
En esencia, la norma 8.24 exige una política específica para cada tema que defina los algoritmos autorizados, las longitudes mínimas de las claves y las normas relativas al ciclo de vida. Dicha política debería estar directamente vinculada a la evaluación de riesgos del SGSI, de modo que cada decisión criptográfica se remonte a un riesgo documentado y no a una mera preferencia.
El ciclo de vida de las claves criptográficas (Anexo A, apartado 8.24)
El ciclo de vida es el punto en el que la criptografía sólida suele fallar con mayor frecuencia. Los auditores esperan que la generación, distribución, rotación y destrucción de claves y certificados —incluidos los integrados en los dispositivos « software » que se suministran— se realicen de forma centralizada, todo ello respaldado por un registro de auditoría completo. La revocación, la gestión de claves comprometidas, la recuperación de claves perdidas, el almacenamiento seguro y las copias de seguridad completan el panorama.
Confidencialidad e integridad de los datos (Anexo A, apartados 5.14, 8.20 y 8.21; datos personales, según el apartado 5.34)
La criptografía existe para proteger los datos. Según el apartado 8.24, la criptografía es el mecanismo; los controles que establecen la obligación se encuentran en otros apartados. El anexo A, apartados 5.34 (transferencia de información) y 8.20-8.21 (seguridad de las redes y de los servicios de red), regulan el cifrado en tránsito. Los certificados emitidos por la PKI protegen los datos de los clientes tanto en reposo como en tránsito dentro del ámbito certificado. En el caso de los proveedores de « software », ese ámbito suele extenderse a entornos SaaS multitenant, en los que muchos clientes comparten la misma infraestructura.
Criptografía de productos (Anexo A, apartados 8.25, 8.26 y 8.28)
Si la tecnología criptográfica forma parte de lo que vendes, el ciclo de vida de desarrollo seguro (8.25), los requisitos de seguridad de las aplicaciones (8.26) y la programación segura (8.28) son los aspectos en los que los auditores comprueban si las decisiones sobre algoritmos y longitud de claves establecidas en tu política 8.24 se reflejan realmente en el código fuente. Los controles de proveedores abarcan las bibliotecas heredadas; estos, por su parte, abarcan tu propio código.
Autenticación segura (Anexo A, apartado 8.5)
El apartado 8.5 del anexo A introduce la autenticación en el contexto de la criptografía. La autenticación basada en certificados reduce la dependencia de secretos compartidos y contraseñas estáticas, tanto en el acceso de los clientes como en el administrativo, sustituyendo las credenciales, que pueden filtrarse fácilmente, por identidades que son mucho más difíciles de utilizar indebidamente.
Criptografía de proveedores y heredada (Anexo A, 5.21 y 8.8)
El software moderno software hereda la criptografía de bibliotecas y terceros. El Anexo A, 8.24, exige que un sistema de gestión de claves se encargue de la revocación de claves y de las claves comprometidas. Cada una de estas obligaciones se aplica por clave, y una obligación por clave presupone saber qué claves existen. En cuanto al anexo A, apartado 8.8, un inventario preciso de activos es un requisito previo para una gestión eficaz de las vulnerabilidades. El anexo A, apartado 5.21, amplía la cuestión a la cadena de suministro de las TIC, donde los componentes son código de terceros. Leídos en su conjunto, el inventario no es un requisito explícito; es la única forma práctica de demostrar el cumplimiento de los cuatro que sí lo son.
Declaración de trazabilidad de la aplicabilidad (cláusula 6.1.3)
Por último, la cláusula 6.1.3 vincula todo ello con la gobernanza. La presentación de informes centralizada, que establece una correspondencia entre los controles criptográficos y las decisiones documentadas sobre el tratamiento de los riesgos, proporciona a los auditores una línea clara y trazable desde un control hasta el riesgo al que se dirige.
Prepararse para la auditoría: qué es lo que examinan los auditores
Cuando un evaluador llega al punto 8.24, busca pruebas, no intenciones. Las siguientes áreas son las que analiza sistemáticamente:
- Una política de criptografía documentada que abarque tanto los sistemas internos como los productos comercializados, en la que se definan los algoritmos autorizados, las longitudes mínimas de las claves y las condiciones en las que el cifrado es obligatorio.
- Pruebas del ciclo de vida de las llaves: registros, no procedimientos: registros de rotación que demuestren que se ha cumplido el intervalo establecido en la política, registros de destrucción con firma de verificación, registros de actividad por llave y fechas de activación y desactivación.
- Declaración de trazabilidad de la aplicabilidad que justifica la inclusión del punto 8.24 y la vincula a la evaluación de riesgos subyacente.
- Cumplimiento normativo y jurisdiccional, incluidos los controles de exportación y las consideraciones relativas a la residencia de los datos.
- Un inventario actualizado de certificados y claves con los nombres de los titulares y las fechas de caducidad, incluidas las claves integradas en las versiones de software .
- Pruebas de auditoría interna de los controles 8.24, cuyos resultados son revisados por la dirección dentro del ciclo del SGSI.
- Política de conformidad de la configuración. Los evaluadores comparan los algoritmos y las longitudes de clave que aprueba la política con lo que realmente se ha implementado. La discrepancia entre la política y la realidad constituye un incumplimiento, incluso cuando tanto la política como la configuración sean defendibles por separado.
El denominador común es la propiedad y la trazabilidad. Cada afirmación que se haga sobre la criptografía debe estar respaldada por un elemento que un auditor pueda examinar.
Cómo Keyfactor ayudarte Keyfactor
La reunión 8.24 se centra en la visibilidad, las normas establecidas y una gestión disciplinada de las claves a gran escala. La plataforma de Keyfactorse ajusta perfectamente a las áreas de control mencionadas anteriormente.
- AgileSec elabora el inventario de componentes criptográficos que respalda la garantía de los proveedores y genera pruebas de la Declaración de aplicabilidad para componentes integrados o de terceros.
- EJBCA proporciona la infraestructura de clave pública (PKI) que garantiza la confidencialidad y la integridad de los datos protegidos por certificados, junto con una gestión centralizada del ciclo de vida de las claves, incluidas las claves integradas en los dispositivos « software » que se suministran.
- Keyfactor Command aplica la política, ofrece visibilidad sobre el ciclo de vida de las claves, gestiona el inventario de certificados y claves, y elabora informes de trazabilidad de la Declaración de aplicabilidad.
En conjunto, estas capacidades crean un único sistema de registro para la criptografía, que genera exactamente la documentación que solicita un auditor de la norma ISO 27001, en lugar de obligar a los equipos a recopilarla manualmente.
Conclusión y próximos pasos
El mensaje que se desprende de la versión 8.24 es coherente: el control prima la titularidad, la trazabilidad y las pruebas frente a las declaraciones de política. La certificación depende menos de que un documento contenga las palabras adecuadas y más de la capacidad de demostrar, cuando se solicite, cómo se rige la criptografía y cómo se gestionan las claves.
El siguiente paso práctico es muy sencillo. Evalúa tu política de criptografía actual y tu inventario de claves a la luz del apartado 8.24 antes de tu próxima auditoría, y centraliza la documentación en lugar de tenerla dispersa en distintas hojas de cálculo.
¿Estás listo para ver cómo se ajusta la criptografía automatizada y la gestión del ciclo de vida de las claves a lo establecido en el anexo A, apartado 8.24? Solicitar una demo.
¿Tienes dudas sobre la criptografía en la norma ISO 27001? Tenemos las respuestas.
¿Qué es el punto 8.24 del Anexo A de la norma ISO/IEC 27001?
El punto 8.24 del Anexo A, «Uso de la criptografía», es el control de la norma ISO 27001:2022 que regula cómo una organización utiliza la criptografía. Exige una política de criptografía documentada y basada en el riesgo, así como una gestión del ciclo de vida de las claves, verificada mediante pruebas operativas y no solo a través de declaraciones de política. El propio Anexo A establece el control en una sola frase; las expectativas detalladas se recogen en la norma ISO/IEC 27002:2022, que los auditores utilizan como referencia.
¿Qué cambios se introdujeron en materia de criptografía en la revisión de 2022?
La revisión de 2022 reestructuró el anexo A en 93 controles distribuidos en cuatro temas. Consolidó los controles independientes de criptografía y gestión de claves de la edición de 2013 en un único control, el 8.24.
¿Abarca la cláusula 8.24 la criptografía integrada en los productos que comercializamos?
Sí. En el caso de las empresas de « software » y de servicios de TI, el ámbito de aplicación de la cláusula 8.24 incluye habitualmente la criptografía integrada en el propio producto, y no solo en el entorno informático interno.
¿Qué debe incluir una política de criptografía que cumpla con la normativa?
Debe ser una política específica para cada ámbito que defina los algoritmos aprobados, las longitudes mínimas de las claves y las condiciones en las que el cifrado es obligatorio. Debe estar vinculada a la evaluación de riesgos del SGSI y abarcar tanto los sistemas internos como los productos comercializados.
¿Qué pruebas clave sobre el ciclo de vida esperan los auditores?
Los auditores esperan que se demuestren los procedimientos para la generación de claves, el almacenamiento seguro, la rotación y la destrucción, y no solo una política por escrito. Un inventario actualizado de certificados y claves, en el que figuren los propietarios y las fechas de caducidad, sirve de respaldo a ello.
¿Con qué frecuencia se comprueba el punto 8.24?
Dado que la norma ISO 27001 es una norma de sistemas de gestión, el punto 8.24 se comprueba en las auditorías de vigilancia anuales y, en su totalidad, en la recertificación trienal.
¿Por qué es importante la certificación ISO 27001 desde el punto de vista comercial?
La certificación se ha convertido en un requisito comercial de facto para los proveedores de TI y de servicios de « software ». Los cuestionarios de seguridad, las solicitudes de propuestas (RFP) y las evaluaciones de riesgo de los proveedores exigen cada vez más una certificación vigente, por lo que un certificado caducado puede suponer una amenaza directa para los ingresos.
¿Cómo se relaciona el apartado 8.24 con la Declaración de aplicabilidad?
La Declaración de aplicabilidad debe justificar la inclusión del apartado 8.24 y vincularlo a la evaluación de riesgos subyacente. La presentación de informes centralizada que relacione los controles criptográficos con las decisiones documentadas sobre el tratamiento de riesgos respalda la revisión del auditor conforme a la cláusula 6.1.3.
