SekitCrosswalk
ISO/IEC 27001:2022 · destino de mapeo derivado

A.8.26Application security requirements

Identify and apply the security requirements an application must meet, covering how it is designed, built and run.

Mapeado desde el Sekit CSF

Los controles de Sekit que cubren este requisito, lente a lente.

Correspondencias en NIST CSF 2.0

Alcanzadas a través de los controles del Sekit CSF que ambos mapean: un mapeo, no una equivalencia formal.

Correspondencias en ISO/IEC 42001:2023 — Annex A

Evidencia que demuestra este control

Lo que pide un auditor, o el motor de evidencias de Sekit.

Política de desarrollo seguro
Las reglas que sigue el equipo de desarrollo para crear software de forma segura: requisitos de seguridad, revisión de código y modelado de amenazas.
Evidencia de pruebas de seguridad de aplicaciones
La prueba de que el código y las aplicaciones se analizan automáticamente en busca de fallos (SAST/DAST), incluidas las dependencias y las APIs.
Del catálogo de evidencias de Sekit

En la práctica

Los requisitos de seguridad de aplicaciones existen para el producto estrella pero rara vez llegan a las herramientas internas o a las API de proveedores. Un consultor suele encontrar un estándar documentado de seguridad de API que cubre autenticación y autorización, pero ningún documento de requisitos equivalente para una nueva app interna de reportes porque se trata como algo interno. El límite de tasa está configurado en el gateway público de la API, pero la API de administración detrás de él no tiene ninguno. Los requisitos reunidos durante el diseño se pierden al lanzar porque nadie compara lo construido con la lista original de requisitos antes de la salida a producción.

Brechas habituales

Los requisitos de seguridad están documentados para las aplicaciones orientadas al cliente pero se omiten en las herramientas internas, dejando esos sistemas sin una línea base definida.
La autenticación de API y el límite de tasa existen en el gateway principal, pero las API internas o expuestas a socios eluden los mismos requisitos.
Los requisitos capturados en el momento del diseño nunca se comparan con lo que se entregó, así que la aplicación construida se desvía de lo especificado.

Preguntas que hará tu auditor

¿Los requisitos de seguridad se definen antes de construir una aplicación, o se descubren después?
Las amenazas y los requisitos de seguridad, incluidas las reglas de autenticación y manejo de datos, se documentan antes de iniciar el desarrollo y luego se verifican contra lo entregado.
¿En qué se diferencian los requisitos específicos de API de los requisitos generales de aplicación?
Las API tienen sus propias reglas documentadas de autenticación, autorización y manejo de datos, probadas antes del lanzamiento y monitoreadas una vez en producción.
¿Qué impide que un endpoint de API se despliegue sin autenticación?
La autenticación, la autorización por endpoint y el límite de tasa se aplican técnicamente en el gateway de la API, sin depender de que cada desarrollador lo recuerde.
¿Quién decide qué requisitos de seguridad debe cumplir una aplicación?
La política documentada asigna el paso de definir requisitos a un rol designado antes de que cierre la fase de diseño del proyecto.

Dónde lo exige la regulación

El artículo 21 de NIS2 vincula los requisitos de seguridad de aplicaciones con la obligación de ciclo de vida de desarrollo seguro (6.2) y con los controles de autenticación (11.6).
El ENS mp.s.2 exige proteger los servicios y aplicaciones web, la expresión operativa de los requisitos de A.8.26.

Controles relacionados

Vía el tema compartido del Sekit CSF, no el índice del propio marco.

Pregúntale a Sekura: «¿Qué evidencia demuestra A.8.26?»
También vía MCP, gratis con cuenta