Seguridad desde el diseño en el CRA: trabajo de producto

«Seguridad desde el diseño» no es una política que firmar. Para productos con elementos digitales debe verse en decisiones de diseño, reducción de superficie de ataque, configuraciones seguras por defecto, actualizaciones, pruebas y gestión de vulnerabilidades durante todo el ciclo de vida.

Un modelo práctico es sencillo: riesgo → requisito → decisión de diseño → acción → prueba → resultado → evidencia → revisión.

Convierte requisitos esenciales en trabajo de producto

El anexo I CRA contiene requisitos esenciales de ciberseguridad. En el trabajo práctico, el equipo debe abordar áreas como:

diseñar con nivel de ciberseguridad adecuado al riesgo;
protección contra acceso no autorizado;
confidencialidad, integridad y disponibilidad de datos y funciones;
reducción de superficie de ataque;
mecanismos que reduzcan el impacto de incidentes;
registro y monitorización de actividad pertinente de seguridad;
eliminación segura de datos y configuración;
distribución segura de actualizaciones;
pruebas y revisiones regulares de seguridad;
divulgación coordinada de vulnerabilidades.

Una lista es un punto de partida. No es evidencia de ejecución.

Ejemplo: «proteger contra acceso no autorizado»

Un registro débil dice:

«El sistema tiene autenticación».

Un registro operativo puede mostrar:

Riesgo: comprometer una cuenta administrativa puede modificar configuración crítica para seguridad.
Decisión: funciones privilegiadas necesitan mecanismo definido de autenticación y control de sesión.
Responsable: persona o equipo identificados.
Implantación: vínculo al cambio de ingeniería.
Prueba: escenario que verifica comportamiento requerido.
Resultado: PASS/FAIL con versión del producto y fecha.
Evidencia: informe, registro, captura o artefacto de prueba.
Revisión: repetir evaluación tras cambios de autenticación o perfil de riesgo.

Meses después, la organización muestra no solo qué pretendía hacer, sino qué verificó realmente.

Seguridad por defecto

La configuración predeterminada importa porque muchos usuarios no cambian seguridad tras instalar. CRA aborda configuración segura, actualizaciones y mecanismos protectores, entre otras áreas.

Para cada función importante de seguridad, pregunta:

qué configuración recibe un nuevo usuario por defecto;
por qué es adecuada al uso normal;
qué protecciones pueden debilitarse o desactivarse;
si los cambios arriesgados son comprensibles;
si el producto puede volver a estado seguro;
qué prueba verifica comportamiento tras instalar y actualizar.

Integra seguridad en la publicación de versiones, no en documentación posterior

Una revisión de versión comprueba al menos:

si cambió el modelo de amenazas o perfil de riesgo;
si se introdujeron nuevas dependencias;
si las pruebas de seguridad cubren el cambio;
si hay decisiones documentadas para vulnerabilidades conocidas;
si sigue correcta la información de seguridad al usuario;
si supuestos y dependencias del soporte son realistas;
si se adjuntaron evidencias a la versión correcta.

Si se pregunta por primera vez al auditar, la organización tiene un proceso documental en vez de seguridad desde el diseño.

ENISA: acciones repetibles en vez de lemas

ENISA publicó «Secure by Design and Default Playbook» para pymes el 30 de julio de 2026. Se centra en convertir principios en acciones repetibles dentro de ingeniería, producto y publicación existentes. Funciona igual para CRA: usa el proceso real de entrega del equipo y explicita responsabilidades y evidencias.

Cómo apoya Pulsar un flujo basado en evidencias

Riesgos, controles, tareas, documentos, evidencias, auditorías e informes de Pulsar pueden conectar una decisión de diseño con implantación, verificación y revisión.

La IA debe seguir como asistente de borradores. No debe aprobar autónomamente evaluación de riesgo, excepción de seguridad ni decisión de conformidad del producto.

Consulta Pulsar GRC en un flujo de requisito a evidencia

Orientaciones relacionadas

Método propuesto: revisar un cambio de diseño antes de publicarlo

Considera un producto hipotético que añade una función de administración remota. La mejora facilita soporte, pero también modifica quién puede acceder, desde dónde y con qué permisos. La revisión de seguridad debe empezar cuando se propone la función, antes de que ingeniería haya comprometido toda la implementación. El objetivo no es bloquear el cambio: es identificar decisiones que después resultarían costosas de corregir.

El responsable de producto describe el uso previsto y los límites del nuevo acceso. Ingeniería documenta las interfaces, los datos tratados y la relación con componentes remotos. Seguridad propone escenarios de abuso: reutilización de una sesión, pérdida de credenciales, escalada de privilegios o acceso a otra organización. El equipo distingue riesgos plausibles de posibilidades que no corresponden a su arquitectura. Esta selección necesita una explicación, no una lista importada sin contexto.

Cada riesgo elegido se traduce en un comportamiento verificable. Por ejemplo, una cuenta sin permisos administrativos no puede cambiar parámetros protegidos, ni siquiera llamando directamente a la API. La prueba debe comprobar el comportamiento real y no solo la visibilidad de un botón. Registra el entorno, la versión y el resultado. Si la evidencia corresponde a una versión anterior, señala qué cambió y qué prueba debe repetirse.

Crea criterios que ingeniería pueda ejecutar

Un criterio como «el acceso será seguro» no permite evaluar una entrega. Escribe qué actor intenta realizar qué acción, bajo qué condición y qué resultado debe observarse. Incluye un caso autorizado y otro no autorizado. Para una operación de borrado, comprueba también los registros relacionados, la restauración cuando corresponda y la información que conserva el sistema. Las pruebas deben ajustarse a las funciones del producto y a su evaluación de riesgo.

La calidad de un criterio depende de su capacidad para detectar un fallo. Si cualquier implementación puede declararse válida, el criterio necesita revisión. Evita que el mismo documento que propone una solución se utilice como prueba de que funciona. Una especificación es entrada; un resultado de ensayo es evidencia. Vincular ambos permite explicar la decisión sin confundir sus papeles.

Para un defecto encontrado antes de publicar, define el tratamiento. La opción puede ser corregir, reducir el alcance de una función o retrasar la entrega. Si se plantea aceptar un riesgo, una persona con autoridad debe revisar las consecuencias y la compatibilidad con requisitos aplicables. Registrar una aceptación interna no elimina una obligación legal. Tampoco convierte un riesgo conocido en un requisito satisfecho.

Comprueba instalación, actualización y recuperación por separado

Una configuración segura en una instalación nueva puede no conservarse al actualizar desde versiones anteriores. Diseña una prueba para cada recorrido que el producto soporte. Registra las condiciones iniciales, la versión de origen, la versión final y los cambios de configuración. Cuando exista migración de datos, revisa si modifica permisos, expone información o elimina ajustes protectores.

La recuperación merece su propio escenario. Un corte durante una actualización puede dejar un producto inutilizable o en un estado parcialmente actualizado. El equipo debe decidir qué estados admite, cómo informa al usuario y cómo vuelve a una versión segura. Estas decisiones dependen del producto; no todos permiten el mismo mecanismo. Lo importante es conservar la justificación y demostrar el comportamiento elegido mediante ensayos pertinentes.

También revisa el primer uso. Una guía que pide al usuario activar manualmente todas las protecciones puede revelar una configuración inicial insuficiente. Identifica qué ajustes llegan activados, cuáles requieren una decisión consciente y qué advertencias permiten entender sus consecuencias. La información debe ser comprensible para el usuario previsto, no solo para quien programó la función.

Una excepción temporal necesita salida

Imagina que una dependencia externa impide cerrar una mejora antes de la fecha prevista. Registra la limitación, los productos afectados, las medidas disponibles y el responsable de seguimiento. Una fecha de revisión ayuda a evitar que «temporal» se convierta en indefinido. El expediente debe mostrar qué condiciones obligan a detener distribución, restringir una función o reconsiderar la decisión.

Comprueba que las medidas propuestas actúan sobre el riesgo real. Un aviso en documentación puede informar al usuario, pero no sustituye necesariamente un control técnico. Una restricción de acceso puede reducir exposición, pero debe ensayarse. Separa mitigaciones verificadas de actividades todavía planificadas. Una tarea abierta nunca debería presentarse como protección ya implantada.

Revisión de publicación con evidencias suficientes

Propón una reunión breve ligada al cambio, no una aprobación genérica de toda la empresa. Quien revisa debe poder localizar el requisito, el riesgo, la implementación y la prueba. Las brechas abiertas se identifican por su efecto y por la decisión adoptada. Si falta una evidencia material, la reunión determina qué se necesita y quién puede decidir sobre la entrega; no maquilla el estado del registro.

Al terminar, conserva la decisión y su alcance. Una aprobación para la versión de prueba no autoriza automáticamente publicar otra compilación. Una aprobación para un mercado o función tampoco cubre cambios posteriores. Esta precisión resulta especialmente útil cuando varias ramas de desarrollo reciben correcciones diferentes.

Para comprobar el método, selecciona un cambio ya publicado y pide a otra persona reconstruirlo. Debe explicar por qué la protección elegida era adecuada, qué prueba se ejecutó y dónde está el resultado. Si el recorrido depende de memoria, existe una carencia documental. Si la prueba no cubre el riesgo, existe una carencia técnica. Cada una necesita una acción distinta.

Qué conservar en Pulsar y qué debe seguir en ingeniería

Pulsar puede enlazar decisiones, riesgos, tareas y evidencias aportadas por la organización. Los ensayos, el análisis del código y las compilaciones se realizan con las herramientas de ingeniería adecuadas. Mantén identificadores que conecten esos resultados con el registro de cumplimiento. No atribuyas a un vínculo documental la ejecución de una prueba ni supongas una recopilación automática desde la nube.

Cuando la IA proponga criterios o un resumen, una persona los compara con la arquitectura y las fuentes. Acepta solo contenido que pueda defender mediante evidencia. El resultado útil es una decisión verificable sobre un cambio real. Una política extensa sin aplicación concreta deja intacto el problema que intentaba resolver.

Incluye entradas inesperadas cuando la función pueda recibir información de otro componente. Un permiso correctamente comprobado no evita necesariamente un fallo causado por un mensaje mal formado o por un estado que el diseño no contempló. Ingeniería selecciona condiciones pertinentes y verifica qué ocurre: rechazo, registro, recuperación o interrupción controlada según el producto. Estos resultados deben corresponder al riesgo evaluado; no existe una respuesta única adecuada para cualquier arquitectura.

Después, revisa qué ve el usuario cuando el producto rechaza la operación. Un mensaje puede explicar cómo recuperar una sesión sin revelar información que facilite abuso. Comprueba también si la repetición de errores altera disponibilidad o genera registros innecesariamente sensibles. La evidencia identifica configuración y versión ensayadas. Si el comportamiento depende de un componente externo, conserva esa dependencia y su fundamento. El cierre requiere una conclusión sobre el caso probado y sus límites, evitando extender el resultado a todas las interfaces o a versiones que no participaron en el ensayo.

Fuentes

Fuentes comprobadas: 12 de septiembre de 2026.

Pulsar GRC — acceso, aislamiento de datos y exportación (polaco)