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.
Zero Trust y detección avanzada
Los enfoques avanzados de seguridad de red y detección: acceso Zero Trust (no confiar por defecto), análisis de comportamiento (UEBA) e ingeniería de detección propia.
Del catálogo de evidencias de Sekit
En la práctica
Los principios de arquitectura segura son fáciles de enunciar y difíciles de mantener actualizados. Una pyme puede documentar una lista de verificación de seguridad desde el diseño para sistemas nuevos, pero esa lista cubre solo aplicaciones web, no la nueva línea de sensores IoT ni una integración de CRM alojada por un proveedor. Los valores predeterminados de privacidad, recolección mínima de datos, retención limitada, se incorporan en el producto estrella pero no en el panel interno que alguien armó en un fin de semana, que exporta todo por defecto porque esa fue la opción más fácil bajo presión de plazos, y nadie volvió después a aplicarle los mismos principios de ingeniería.
Brechas habituales
Los principios de diseño seguro están documentados para el producto principal pero no se extienden a herramientas internas, adquisiciones o plataformas de proveedores recién adoptadas.
Los valores predeterminados de privacidad existen en la aplicación principal, pero los sistemas internos nuevos recolectan por defecto más datos de los necesarios.
La validación de seguridad para cambios en tecnología operativa es informal, así que se han desplegado controles de seguridad sin confirmar que no puedan interrumpir los procesos de producción.
Preguntas que hará tu auditor
¿Los principios de seguridad se aplican solo a sistemas nuevos o también a cambios importantes?
Ambos: las amenazas se identifican y documentan antes de iniciar el desarrollo de aplicaciones nuevas y antes de cambios importantes en las existentes.
¿Qué significa privacidad desde el diseño en la práctica aquí?
Los sistemas recolectan por defecto lo mínimo y retienen los datos por tiempo limitado, y cualquier uso compartido más amplio requiere un opt-in explícito en lugar de estar activado por defecto.
¿Cómo se confirma que un nuevo control de seguridad no romperá un proceso operativo crítico?
Los controles técnicos en sistemas de producción se diseñan y prueban para verificar que no interfieran con funciones críticas de seguridad antes de entrar en vivo.
Dónde lo exige la regulación
El artículo 21 de NIS2 exige ingeniería segura desde el diseño como parte de la obligación de ciclo de vida de desarrollo seguro (6.2).
El ENS mp.sw.1 exige que el desarrollo de aplicaciones incorpore controles de seguridad desde el diseño hasta la aceptación, no que se añadan después del lanzamiento.
Controles relacionados
Vía el tema compartido del Sekit CSF, no el índice del propio marco.