Del plan de referencia a la preparación para auditorías: dominar los requisitos de seguridad de las aplicaciones para ISO 27001, DORA y NIS2

La tensión previa a la auditoría era palpable. Para María, CISO de una fintech de tamaño medio, la próxima evaluación de cumplimiento de DORA se percibía menos como una revisión y más como un ajuste de cuentas. Su equipo era competente y su infraestructura estaba endurecida, pero una vulnerabilidad persistente le quitaba el sueño: el ecosistema amplio y caótico de sus aplicaciones.

La preocupación más reciente era un nuevo portal de pagos orientado al cliente, lanzado con prisa para cumplir los objetivos trimestrales. El equipo de desarrollo, trabajando bajo un modelo ágil exigente, había cubierto todos los requisitos funcionales. Pero cuando el equipo de María ejecutó un escaneo preliminar, los resultados confirmaron sus temores.

El portal carecía de controles robustos de tiempo de espera de sesión, sus campos de entrada eran susceptibles a ataques básicos de inyección y los mensajes de error exponían información sensible del sistema. No se trataba de exploits sofisticados de día cero; eran defectos fundamentales de diseño. La causa raíz era dolorosamente clara. Los requisitos de seguridad nunca se habían definido, documentado ni integrado formalmente en los sprints de desarrollo. El equipo tenía el mandato impreciso de “hacerlo seguro”, pero sin un plan de referencia concreto la seguridad seguía siendo una consideración ambigua, tardía y a menudo ignorada.

Este escenario no es excepcional. Pone de manifiesto la brecha crítica a la que se enfrentan muchos CISO y responsables de cumplimiento: convertir la intención de “hacemos seguridad” en requisitos de seguridad de las aplicaciones explícitos y verificables, alineados con normas fundamentales como ISO/IEC 27001:2022 y regulaciones relevantes como NIS2, DORA y el RGPD de la UE.

El alto coste de la ambigüedad: qué espera realmente el cumplimiento

El núcleo del problema de María reside en un fallo organizativo común: tratar la seguridad como un atributo de calidad en lugar de como un conjunto de requisitos no negociables. Un requisito de seguridad eficaz es específico, medible y verificable. “La aplicación debe ser segura” es una aspiración. “La aplicación debe aplicar tiempos de espera de sesión por inactividad de 15 minutos, validar toda entrada proporcionada por el usuario frente a un conjunto de caracteres predefinido y cifrar todos los datos en tránsito mediante TLS 1.3” es un requisito. Esta claridad es lo que buscan los auditores y lo que necesitan los desarrolladores para crear software seguro.

Sin ella, se desencadena una cascada de fallos:

• Implantación incoherente: distintos desarrolladores interpretan “seguro” de formas diferentes, generando un mosaico de controles con brechas impredecibles.
• Aumento de los costes de remediación: encontrar y corregir un defecto de diseño en producción es exponencialmente más caro que abordarlo en la fase de diseño.
• No conformidades de auditoría: los auditores identificarán rápidamente la ausencia de un proceso estructurado para definir requisitos de seguridad, lo que dará lugar a hallazgos significativos.
• Riesgo para la organización: cada requisito no definido es un vector potencial de ataque, que expone a la organización a brechas de seguridad de los datos, pérdidas financieras y daño reputacional.

En las normas modernas, la expectativa es coherente: la seguridad debe definirse como requisitos desde el inicio y vincularse al riesgo y a la normativa aplicable. La guía de ISO/IEC 27002:2022 sobre el control 8.26, Requisitos de seguridad de las aplicaciones, espera que las organizaciones determinen, documenten y aprueben de forma sistemática los requisitos de seguridad con base en una evaluación de riesgos formal y en exigencias regulatorias.

Este principio único es la pieza central de una amplia variedad de mandatos de cumplimiento. El mapeo de cumplimiento cruzado de Clarysec dentro de Zenith Controls: The Cross-Compliance Guide Zenith Controls muestra cómo este concepto aparece en todas partes:

• RGPD de la UE, artículos 25 y 32, exige “protección de datos desde el diseño” y “seguridad del tratamiento”.
• NIS2, artículo 21(2)(d)-(e), enfatiza el desarrollo seguro y la seguridad de la cadena de suministro.
• DORA, artículos 6(4), 8, 10 y 11, exige gestión del riesgo de las TIC y seguridad desde el diseño para entidades financieras.
• NIST SP 800-53 Rev.5, en los controles SA-4 y SA-15, exige requisitos definidos de seguridad del sistema y prácticas de desarrollo seguro.
• COBIT 2019, en los procesos BAI03 y DSS05, requiere que los requisitos relacionados con la seguridad se alineen con el negocio y el cumplimiento antes de crear una solución.

El objetivo es definir, en palabras de Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint, “qué significa la seguridad para sus aplicaciones antes de escribir una sola línea de código.”

Por qué fallan los enfoques tradicionales: listas de verificación, pruebas tardías y teatro de seguridad

La mayoría de las organizaciones ya realizan algún tipo de seguridad de aplicaciones. El problema es que rara vez está estructurada de forma que resista una certificación ISO/IEC 27001:2022 o el escrutinio regulatorio.

Los patrones de fallo habituales incluyen:

1. Listas de verificación genéricas: los equipos reutilizan una “lista de verificación de programación segura” de una página para todos los proyectos. No está vinculada a los riesgos específicos de la aplicación, a la sensibilidad de los datos ni al contexto regulatorio. Cuando un auditor pregunta cómo se mapea la lista con el artículo 25 del RGPD de la UE, no existe una respuesta clara.
2. Seguridad como hito de control tardío: los requisitos de seguridad no se incorporan al diseño ni a las historias de usuario. Aparecen al final como una solicitud de pruebas de penetración. Zenith Blueprint advierte que “apoyarse en una lista de verificación de seguridad al final del proyecto no funciona; esos requisitos deben modelar la arquitectura, influir en la selección de bibliotecas y guiar la priorización de funcionalidades desde el primer día.”
3. Sin trazabilidad del requisito a la prueba: puede existir un requisito para “cifrar datos en tránsito”, pero no hay un caso de prueba vinculado que verifique la aplicación de la versión de TLS, la validez del certificado y la fortaleza de los cifrados. Zenith Blueprint insiste en que las expectativas deben ser medibles y verificables, con pruebas de seguridad mapeadas directamente a sus requisitos correspondientes.
4. Gestión ad hoc del código de terceros: las aplicaciones modernas suelen estar “ensambladas a partir de código interno, bibliotecas de terceros, interfaces de programación de aplicaciones y servicios nativos en la nube”, como señala Zenith Blueprint. Sin requisitos explícitos para proveedores y componentes de código abierto, el riesgo de la cadena de suministro sigue siendo un punto ciego enorme y sin control.

El resultado es teatro de seguridad: existen documentos y se ejecutan pruebas, pero cuando un auditor o regulador serio busca una historia coherente de requisitos, todo el proceso se desmorona.

Construir la base: de la política a la práctica

Un enfoque disciplinado de la seguridad de las aplicaciones empieza por una gobernanza clara. La política no es mera burocracia; es la fuente oficial de referencia que faculta a los equipos y proporciona a los auditores una declaración clara de intenciones. En Clarysec diseñamos políticas que son, a la vez, autorizadas y prácticas.

Nuestra Política de requisitos de seguridad de las aplicaciones Política de requisitos de seguridad de las aplicaciones establece reglas básicas no negociables. Por ejemplo, la cláusula 5.2, dentro de “Requisitos de gobernanza”, exige:

Todas las aplicaciones deben someterse a validación de requisitos de seguridad durante la planificación o adquisición, con aprobación documentada del equipo de Seguridad de Aplicaciones.

Esta directriz sencilla evita la mentalidad de “construir primero y asegurar después”. La política también asigna responsabilidades claras. La cláusula 4.3.1, dentro de “Roles y responsabilidades”, establece que se espera que los desarrolladores:

Implementen aplicaciones conforme a los requisitos y estándares de seguridad definidos.

Esto desplaza la responsabilidad de la seguridad desde un equipo de seguridad separado, a menudo percibido como adversarial, hacia los propios creadores del software. Además, la política conecta los distintos dominios de seguridad. La cláusula 10.2 referencia su integración con otros controles clave:

P4 – Política de control de acceso. Define los estándares de gestión de identidades y sesiones que deben aplicar todas las aplicaciones, incluidos autenticación fuerte, privilegio mínimo y requisitos de revisiones de acceso.

Para organizaciones más pequeñas, una política adaptada como nuestra Política de requisitos de seguridad de las aplicaciones - pyme Política de requisitos de seguridad de las aplicaciones - pyme asegura que estos principios sean escalables. Reconoce que, aunque los riesgos son similares, la implantación debe ser pragmática. Ambas versiones persiguen en última instancia el mismo resultado: asegurar que la seguridad de las aplicaciones esté plenamente integrada en el SGSI y preparada para auditorías.

Hoja de ruta práctica: construir requisitos de seguridad de aplicaciones preparados para auditorías

La política establece el “qué” y el “por qué”, pero desarrolladores y responsables de proyecto necesitan el “cómo”. Una guía de implantación estructurada es indispensable para traducir controles de alto nivel en pasos accionables. El paso 21 de Zenith Blueprint, centrado en el control 8.26 de ISO/IEC 27002:2022, proporciona una metodología clara de seis pasos.

Recorramos este proceso utilizando el portal de pagos de María como ejemplo.

Paso 1: partir del contexto de riesgo y regulatorio

Utilizando resultados de evaluación de riesgos alineados con ISO/IEC 27005:2024 (Tratamiento de riesgos), primero se identifica el contexto:

• Aplicación: portal de pagos de autoservicio para clientes.
• Datos: datos personales identificables (PII), credenciales, tokens de pago.
• Jurisdicciones: UE, servicios financieros, alojado en la nube.
• Regulaciones: RGPD de la UE, DORA, PCI DSS.

Con base en la guía del control 8.26 en Zenith Controls y sus normas ISO relacionadas (27034-1, 27017, 27701), las categorías iniciales de requisitos deben incluir identificación y autenticación, autorización, clasificación de datos, validación de entradas, registro de eventos y protección de datos en tránsito y en reposo.

Paso 2: crear o adoptar una plantilla de requisitos de seguridad

Zenith Blueprint recomienda crear una plantilla estandarizada para asegurar que cada proyecto responda a las mismas preguntas fundamentales de seguridad. Este documento debe formar parte del kit de herramientas de inicio de proyecto.

Las secciones mínimas deben incluir:

• Nombre de la aplicación, propietario y criticidad.
• Categorías de datos y niveles de sensibilidad.
• Obligaciones regulatorias y contractuales aplicables (RGPD de la UE, DORA, etc.).
• Entradas sobre el panorama de amenazas (derivadas del control 5.7 Inteligencia de amenazas).
• Requisitos de seguridad específicos por categoría (autenticación, registro de eventos, etc.).
• Vínculos con historias de usuario y criterios de aceptación.
• Vínculos con casos de prueba (funcionales, de seguridad, de penetración).
• Requisitos para proveedores y componentes de terceros.

Paso 3: incorporar los requisitos a los artefactos ágiles

Los requisitos de seguridad deben integrarse directamente en las historias de usuario y los criterios de aceptación. Para la épica de “registro de clientes” en el proyecto del portal de María, esto significa transformar una historia funcional sencilla en una historia consciente de la seguridad.

• Historia de usuario original: “Como nuevo usuario, puedo crear una cuenta.”
• Historia de usuario segura: “Como nuevo cliente, quiero crear una cuenta segura para que mi información de pago esté protegida.”
• Criterios de aceptación (con seguridad incorporada):
  • El sistema debe aplicar una política de contraseñas robusta conforme a la P4 – Política de control de acceso.
  • El sistema debe exigir verificación de correo electrónico mediante un enlace de un solo uso antes de activar la cuenta.
  • El formulario de creación de cuenta debe estar protegido con CAPTCHA para evitar ataques de bots.
  • Todos los intentos de registro deben registrarse con IP de origen y huella del dispositivo.
  • Todos los datos enviados mediante el formulario deben validarse y sanitizarse para prevenir cross-site scripting (XSS).

No son tareas de seguridad separadas; forman parte integral de la definición de “hecho” de la funcionalidad.

Paso 4: vincular los requisitos con las pruebas de seguridad

Utilizando el control 8.29 Pruebas de seguridad de Zenith Controls, se asegura que cada requisito tenga un caso de prueba asociado. Esto cierra el ciclo y proporciona evidencias auditables de la eficacia del control.

• Requisito: cifrado en tránsito con TLS 1.3. → Prueba: escaneo automatizado para verificar la aplicación de TLS, la validez del certificado y las suites de cifrado aprobadas.
• Requisito: validación de entradas para prevenir inyección SQL. → Prueba: análisis SAST/DAST automatizado y fuzzing manual durante QA.
• Requisito: tiempo de espera de sesión por inactividad de 15 minutos. → Prueba: pruebas automatizadas y manuales para confirmar la invalidación de la sesión en el lado del servidor tras 15 minutos de inactividad.

Paso 5: extender los requisitos a la cadena de suministro

Dado que el control ISO 8.26 está vinculado a la seguridad de proveedores (5.19, 5.20) y al desarrollo externalizado (8.30) en Zenith Controls, el proceso debe considerar el código de terceros. Para pymes muy dependientes de bibliotecas externas, la cláusula de la Política de requisitos de seguridad de las aplicaciones - pyme es crítica:

Cualquier herramienta de terceros, complemento o biblioteca de código externa utilizada en una aplicación debe registrarse y revisarse anualmente en cuanto a su impacto en la seguridad y su estado de parcheado.

Este requisito sencillo y pragmático obliga a adoptar una mentalidad de lista de materiales de software (SBOM), una expectativa clave en regulaciones como NIS2. Para proveedores principales, los mismos requisitos de seguridad de las aplicaciones deben incluirse en los contratos, con referencia a ISO/IEC 27036-1 (seguridad de la cadena de suministro de las TIC).

Paso 6: establecer una reevaluación periódica

A medida que las aplicaciones evolucionan, también lo hacen sus riesgos. La guía de Zenith Blueprint sobre reevaluación periódica es crucial. Cuando se integra una nueva API o se migra a un servicio en la nube distinto, cambia el contexto de riesgo. Esto debe activar una revisión de los requisitos de seguridad existentes para asegurar que siguen siendo adecuados. Esto se alinea con ISO/IEC 27005:2024 (tratamiento continuo de riesgos) y convierte la seguridad de las aplicaciones en una práctica continua, no en un proyecto puntual.

Descomponer el ecosistema de controles

Un control ISO nunca existe en el vacío. La seguridad eficaz se apoya en una red interconectada de medidas. La verdadera potencia del control 8.26 se desbloquea cuando se comprende su relación con otros controles, una perspectiva detallada en Zenith Controls.

El control 8.26 se clasifica como control preventivo, pero actúa como eje central de todo el proceso de desarrollo seguro, conectándose con:

• 8.25 - ciclo de vida de desarrollo seguro: es el marco general. El control 8.26 aporta el qué específico (los requisitos) que debe integrarse en el cómo (el proceso SDLC).
• 8.27 - arquitectura segura de sistemas y principios de ingeniería: los requisitos impulsan las decisiones arquitectónicas, asegurando que la seguridad sea fundacional.
• 8.28 - codificación segura: una vez definidos los requisitos (por ejemplo, “prevenir inyección SQL”), los estándares de programación segura proporcionan a los desarrolladores las técnicas para cumplir ese requisito.
• 8.29 - pruebas de seguridad en desarrollo y aceptación: este control valida que los requisitos definidos en 8.26 se hayan implementado correctamente.
• 5.34 - privacidad y protección de PII: cuando una aplicación trata datos personales, los requisitos de 8.26 deben incorporar los principios de privacidad desde el diseño.
• 5.19 y 5.20 - seguridad de la información en las relaciones con proveedores: para aplicaciones adquiridas o externalizadas, el control 8.26 exige que sus requisitos de seguridad se extiendan a la cadena de suministro.

Ver estos controles como un ecosistema, y no como una lista de verificación, permite construir una postura de seguridad multicapa y defendible.

La mirada del auditor: prepararse para el escrutinio

Los auditores piensan en términos de evidencias. Para prepararse, es necesario comprender las distintas perspectivas que puede adoptar un auditor. La sección de metodología de auditoría de Zenith Controls anticipa estos enfoques variados.

Comprender estas perspectivas permite preparar un portafolio integral de evidencias que demuestre un proceso vivo e integrado en la organización.

La brújula de cumplimiento cruzado: un proceso, muchos marcos

Para una empresa como la de María, satisfacer DORA, el RGPD de la UE y NIS2 es obligatorio. Mapear controles manualmente es una receta para duplicar esfuerzos y generar brechas de cumplimiento. Un enfoque centralizado de cumplimiento cruzado aporta un valor enorme. Definir requisitos de seguridad de las aplicaciones es la implantación práctica del principio de “seguridad desde el diseño” que sustenta todas estas regulaciones modernas.

Al implantar un proceso robusto de requisitos de seguridad de las aplicaciones basado en ISO/IEC 27002:2022, se construyen simultáneamente evidencias para satisfacer una parte significativa de estas otras regulaciones. No se trata solo de “hacer ISO”; se trata de construir un programa de seguridad con cumplimiento transversal.

Del caos al control: su camino a seguir

La historia de María tiene un desenlace positivo. Utilizó el incidente del portal de pagos como catalizador del cambio. Con un marco de políticas claro de Clarysec y una guía práctica de implantación, reunió a sus equipos de desarrollo, seguridad y producto. Usaron la metodología de Zenith Blueprint para definir retrospectivamente los requisitos del portal, priorizando la remediación en función del riesgo.

Más importante aún, establecieron una nueva forma de trabajar. La “lista de verificación de seguridad” fue sustituida por sesiones colaborativas de diseño. Cuando llegaron los auditores de DORA, María no solo pudo mostrarles una aplicación segura, sino también demostrar un proceso maduro, repetible y capaz de asegurar que todas las aplicaciones futuras se construirían sobre una base de seguridad.

Transformar su postura de seguridad de aplicaciones empieza con un único paso estructurado. El camino a seguir es claro:

1. Establezca la gobernanza: implante una política formal para definir requisitos de seguridad de las aplicaciones. Nuestras plantillas, como la Política de requisitos de seguridad de las aplicaciones, proporcionan un punto de partida preparado para auditorías.
2. Adopte un marco práctico: utilice Zenith Blueprint para integrar los requisitos de seguridad directamente en su ciclo de vida del desarrollo, haciéndolos accionables, verificables y trazables.
3. Comprenda el contexto completo: aproveche Zenith Controls para ver cómo este control crítico se conecta con el ecosistema de seguridad más amplio y se mapea con DORA, NIS2, el RGPD de la UE y otros marcos.
4. Escálelo a su portafolio: una vez que el enfoque funcione para una aplicación, escálelo a todo su portafolio integrando la plantilla de requisitos de seguridad en las listas de verificación estándar de inicio de proyecto, plantillas ágiles y procesos de adquisición.

Si desea acelerar esta transformación, Clarysec proporciona políticas preconstruidas, hojas de ruta de implantación y mapeos de cumplimiento cruzado para pasar de esfuerzos fragmentados a un programa demostrablemente maduro y preparado para auditorías. Deje de tratar la seguridad de las aplicaciones como una inspección final en un hito de control. Empiece a incorporarla al plan de referencia de todo lo que crea.