Excepciones criptográficas en ISO 27001: guía de evidencias y CER

La conversación de auditoría que David más temía llegó tres semanas antes de lo previsto. InnovatePay acababa de adquirir una empresa más pequeña, QuickAcquire. La operación era una victoria estratégica, pero en el fondo de la pila tecnológica había un módulo heredado de transferencia de datos que utilizaba una biblioteca criptográfica no alineada con los estándares aprobados por InnovatePay. Sustituirlo requería un proyecto de seis meses. El auditor externo llegaría la semana siguiente.

En la mente de David, la escena era dolorosamente clara. El auditor, sereno y metódico, se detendría en la desviación y formularía la pregunta que convierte sabemos que es arriesgado en una no conformidad: muéstrame las evidencias de la excepción criptográfica y cómo decidisteis que era aceptable.

En ese momento, la intención no importa; el control sí. Sin un proceso de excepciones documentado, aceptación del riesgo por la dirección, controles compensatorios, registros de gestión de claves y un plan de remediación limitado en el tiempo, es probable que un auditor trate el asunto como un fallo de control o como una gobernanza débil del SGSI. Esta guía de referencia muestra cómo convertir ese momento en una demostración de madurez, utilizando los kits de herramientas y políticas de Clarysec, el control A.8.24 Uso de la criptografía de ISO/IEC 27001:2022 y una perspectiva de cumplimiento transversal que abarca NIS2, DORA, GDPR, NIST y COBIT 2019.

Por qué las excepciones criptográficas son inevitables y cómo las evalúan los auditores

Las excepciones criptográficas existen por motivos previsibles. En los trabajos de Clarysec observamos patrones recurrentes:

• Restricciones de tecnología heredada, por ejemplo algoritmos, suites de cifrado o longitudes de clave no admitidos.
• Dependencia de proveedores y retrasos de certificación que bloquean actualizaciones oportunas a criptografía aprobada.
• Realidades operativas en respuesta a incidentes o análisis forense que requieren desviaciones temporales para recopilar evidencias o mantener la continuidad del servicio.
• Periodos de migración, donde la interoperabilidad transitoria obliga a aplicar configuraciones más débiles durante un tiempo limitado.
• Restricciones de socios o clientes que impiden aplicar la configuración de referencia preferida.

Los auditores de ISO/IEC 27001:2022 no exigen perfección; exigen control. Evalúan si el cifrado es adecuado y coherente, si la gestión de claves está gobernada y registrada, y si la organización identifica y gestiona activamente algoritmos obsoletos en su parque tecnológico. El primer paso es alinear la forma en que gestionas las excepciones con lo que los auditores esperan ver.

Ancla la excepción en la política y en la gobernanza del riesgo

Un SGSI maduro trata las excepciones como decisiones de tratamiento del riesgo, no como deuda técnica. El mecanismo formal es una Solicitud de Excepción Criptográfica, y la cláusula de la política que la exige es el punto de enlace entre una excepción gestionada y un hallazgo.

La Política de Controles Criptográficos empresarial de Clarysec exige: El uso de algoritmos criptográficos no estándar o la desviación temporal de prácticas de ciclo de vida aprobadas requiere una Solicitud de Excepción Criptográfica documentada. Esta familia de políticas se vincula directamente con el tratamiento del riesgo. La Política de gestión de riesgos complementaria respalda la evaluación de riesgos de controles criptográficos y documenta la estrategia de tratamiento del riesgo para excepciones, obsolescencia de algoritmos o escenarios de compromiso de claves.

Una vez que el requisito existe en la política, toda excepción debe ser trazable a un CER con aceptación del riesgo por la dirección, una entrada vinculada en el registro de riesgos, controles compensatorios y un plan de salida. Presenta estos artefactos antes de que nadie los solicite, guiando al auditor primero por tu gobernanza y después por el estado técnico, mediante el enfoque de entrevistas y muestreo establecido en el Zenith Blueprint.

Construye el CER como un registro de control preparado para auditoría

Los comentarios en tickets no son registros de excepciones. Un CER debe estar estructurado, sujeto a control de versiones y disponible para muestreo como cualquier otro control. Ya se implemente en una herramienta GRC o en una plantilla controlada, un CER sólido incluye:

• Resumen de la excepción, qué no cumple y dónde.
• Alcance, tipos de datos y si la excepción afecta a datos en reposo, datos en tránsito o ambos.
• Justificación de negocio, el motivo vinculado a restricciones del servicio o de la organización.
• Evaluación del impacto en la seguridad, escenarios de amenaza realistas como riesgo de degradación, ataque de intermediario, algoritmos hash débiles o compromiso de claves.
• Controles compensatorios, por ejemplo segmentación, certificados de cliente, vida de sesión corta, reglas de WAF, autenticación adicional y supervisión reforzada.
• Calificación del riesgo antes y después de los controles compensatorios, alineada con la matriz de riesgos.
• Responsable, un propietario del riesgo con responsabilidad asignada en la organización.
• Aprobaciones, seguridad, propietario del sistema y aceptación del riesgo por la dirección.
• Fecha de vencimiento y frecuencia de revisión, no abiertas indefinidamente.
• Plan de salida, hoja de ruta, dependencias, hitos y fechas límite.
• Referencias a evidencias, enlaces a configuraciones, registros, resultados de las pruebas, declaraciones de proveedores y aprobaciones de cambios.

En el caso de David, la excepción de QuickAcquire pasó de ser una responsabilidad oculta a una decisión auditable cuando presentó el CER en la reunión de apertura, ofreció el paquete de evidencias e invitó al auditor a realizar el muestreo.

El paquete mínimo viable de evidencias para una excepción criptográfica

Los auditores esperan algo más que una instantánea técnica. Para las excepciones, buscan prueba de gobernanza y de funcionamiento operativo. Un paquete de evidencias práctico incluye:

1. El CER completado, con aprobaciones y fecha de vencimiento.
2. La evaluación de riesgos vinculada y la decisión de tratamiento.
3. Procedimientos de gestión de claves para el sistema afectado, con registros de generación, distribución, rotación, acceso y destrucción de claves.
4. Registros de cambios de los ajustes criptográficos y evidencias de pruebas que demuestren que los cambios se validaron o que las restricciones se verificaron.
5. Evidencias de supervisión y detección de los controles compensatorios, incluidas reglas de SIEM y pruebas de alertas.
6. Registros de comunicaciones que demuestren que el personal afectado fue informado y formado sobre la desviación y las expectativas de supervisión.
7. Un plan de salida limitado en el tiempo, con hitos, fechas, presupuesto cuando aplique y responsables.
8. Historial de revisión de la política que demuestre el mantenimiento de la configuración de referencia criptográfica y la gestión del ciclo de vida de los algoritmos.

Estos tipos de evidencias se alinean con la guía de ISO/IEC 27002:2022 sobre criptografía y control de cambios.

Usa el Zenith Blueprint para recopilar y presentar evidencias

El método de evidencias del Zenith Blueprint es directo y adecuado para auditoría: entrevistar, revisar, observar y muestrear. Aplícalo a las excepciones:

• Entrevistar al propietario del sistema y al responsable de seguridad. Por qué es necesaria la excepción, qué ha cambiado desde la última revisión y cuál es el siguiente paso del plan de salida.
• Revisar el CER, el registro de riesgos, la cláusula de la política y las restricciones del proveedor o del socio. Confirmar las fechas de vencimiento y revisión.
• Observar el estado técnico, es decir, la configuración exacta y dónde se aplica la excepción, y verificar dónde se aplican los controles compensatorios.
• Muestrear varias excepciones, normalmente entre tres y cinco, para demostrar la coherencia de la estructura, aprobaciones, revisiones, registro de eventos y gestión de vencimientos.

Ejemplo práctico: cómo hacer auditable una excepción TLS heredada

Escenario: Una integración B2B crítica para los ingresos requiere una suite de cifrado TLS antigua porque el punto de conexión del socio no puede negociar los ajustes aprobados. Interrumpir la conexión no es viable.

Hazla auditable en cuatro pasos:

1. Crea el CER y vincúlalo al riesgo. Establece una vigencia de 90 días con revisiones cada 30 días, adjunta la correspondencia con el socio y vincúlalo a una entrada del registro de riesgos propiedad de la organización.
2. Elige controles compensatorios que generen evidencias. Restringe las IP de origen a los rangos del socio mediante registros de cambios de cortafuegos. Exige TLS mutuo si es posible y conserva los registros de emisión de certificados. Incrementa la supervisión de anomalías en la negociación TLS y conserva las definiciones de reglas de SIEM y las pruebas de alertas.
3. Demuestra disciplina en la gestión de claves. Muestra registros de acceso a KMS, asignaciones de RBAC, registros de acceso de emergencia y actas de revisiones periódicas de derechos de acceso. Para programas más pequeños, el requisito de referencia es explícito en la Política de Controles Criptográficos para pymes: Todo acceso a claves criptográficas debe registrarse y conservarse para revisión de auditoría, con revisiones de acceso periódicas.
4. Empaqueta la excepción. Prepara una única carpeta de evidencias o PDF que incluya el CER, el registro de riesgos, la instantánea de configuración de la pasarela, los tickets de cambio del cortafuegos, los registros de KMS, la regla de SIEM y muestras de eventos, registros de prueba y comunicaciones a operaciones.

Agilidad criptográfica: demostrar que las excepciones son temporales por diseño

ISO/IEC 27002:2022 promueve la agilidad criptográfica, es decir, la capacidad de actualizar algoritmos y suites sin reconstruir sistemas completos. Los auditores buscan evidencias de agilidad, no promesas:

• Cadencia de revisión de políticas que actualiza algoritmos y prácticas aceptables con registros de cambios versionados.
• Registros de pruebas de actualización criptográfica que demuestran rutas de despliegue seguras.
• Comunicaciones que notifican al personal los cambios criptográficos y sus impactos operativos.
• Elementos del backlog de desarrollo con avance de entrega vinculado a las fechas de vencimiento de las excepciones.

La gobernanza de excepciones se encuentra con el análisis forense

Las excepciones pueden complicar las investigaciones, especialmente cuando el cifrado o los dispositivos no compatibles bloquean la recopilación de evidencias. La Política de recopilación de evidencias y análisis forense de Clarysec aborda este punto con consideraciones explícitas sobre las evidencias requeridas de dispositivos no compatibles o cifrados. La versión para pymes, la Política de recopilación de evidencias y análisis forense para pymes, anticipa modos de fallo prácticos, por ejemplo cuando no es posible recopilar evidencias conforme a la política debido a una caída del sistema o a soportes dañados.

Planifica esto en tus CER. Incluye el posible impacto forense, custodia las claves necesarias y define requisitos de acceso de emergencia y registro de eventos.

Mapeo de cumplimiento transversal: una excepción, múltiples perspectivas

En entornos regulados o con múltiples marcos, la misma excepción se examinará desde distintas perspectivas. Usa la guía Zenith Controls para mantener coherente el paquete de evidencias.

Cómo indagarán los distintos auditores y cómo responder

Incluso en una misma auditoría, los estilos varían. Prepárate para cada estilo y dirige el relato:

• El auditor de ISO/IEC 27001:2022 preguntará dónde está la política de criptografía, dónde se define el proceso de excepciones, con qué frecuencia se revisan las excepciones y querrá realizar muestreo. Empieza por los CER y un registro controlado.
• El auditor orientado a NIST buscará configuraciones de referencia de suites de cifrado, protecciones frente a degradación, procedimientos de generación y destrucción de claves, y registros con alertas. Presenta registros de KMS, reglas de SIEM y pruebas de validación.
• El auditor COBIT o ISACA se centrará en quién es propietario del riesgo, quién lo aceptó, cuál es la cadencia de revisión y qué métricas muestran la reducción progresiva de excepciones. Presenta actas del comité de dirección e informes de antigüedad de excepciones.
• El revisor con enfoque regulatorio preguntará cómo afecta la excepción a la disponibilidad e integridad de servicios críticos, y si aumentó el riesgo de exposición de datos personales. Ofrece artefactos de planificación de resiliencia y un calendario firme de remediación.

Errores habituales que generan no conformidades

• Excepciones sin fecha de vencimiento, interpretadas como riesgo no gestionado.
• Ausencia de aceptación del riesgo por la dirección, cuando un ingeniero aprobó en un ticket sin una propiedad responsable.
• Controles compensatorios descritos pero no evidenciados, por ejemplo afirmaciones de supervisión sin reglas de SIEM.
• Registros de gestión de claves inexistentes o inaccesibles.
• La política dice una cosa y la práctica otra, por ejemplo los CER son obligatorios pero no se utilizan.

Lista de verificación del día de auditoría para excepciones criptográficas

• Un registro actualizado enumera todas las excepciones criptográficas con identificadores CER, propietarios, aprobaciones, fechas de revisión y vencimientos.
• Toda excepción está vinculada a un registro de riesgos y a una decisión de tratamiento documentada.
• Existen al menos dos controles compensatorios por excepción, con evidencias sólidas.
• El acceso a claves se registra, los registros se conservan y se realizan revisiones de acceso.
• El historial de revisión de la política criptográfica está disponible, con cambios versionados.
• Puedes muestrear tres o más excepciones y presentar un relato coherente.
• Una hoja de ruta muestra la reducción de excepciones a lo largo del tiempo.

Restricciones de proveedores y socios

Muchas excepciones se originan fuera de tu control directo. Los socios imponen suites de cifrado, los proveedores se retrasan en sus hojas de ruta o los sistemas adquiridos arrastran deuda. Trata las restricciones externas como parte de tu gobernanza, no como excusas. Exige declaraciones de proveedores sobre hojas de ruta criptográficas, incluye cláusulas contractuales que establezcan configuraciones de referencia criptográficas e incorpora las dependencias externas en tu registro de riesgos.

Próximos pasos: construye tu programa de excepciones en un sprint

1. Inventaria todas las excepciones criptográficas, incluidas las ocultas en servicios perimetrales.
2. Crea o adapta CER para cada excepción, con aprobaciones, vencimiento y planes de salida.
3. Vincula cada CER a una entrada del registro de riesgos con un propietario responsable.
4. Prepara una plantilla estándar de paquete de evidencias de excepción y ensaya el muestreo de auditoría.
5. Valida la preparación para cumplimiento transversal con la guía Zenith Controls.

Convierte la ansiedad por las excepciones criptográficas en confianza ante la auditoría. Reserva una sesión de trabajo con Clarysec. En un único proyecto, implantamos un flujo de trabajo de CER, un registro de excepciones y una estructura de paquete de evidencias preparada para auditoría. El resultado: auditorías más rápidas, menos hallazgos recurrentes y excepciones criptográficas que demuestran gobernanza en lugar de improvisación.