Evaluación del riesgo cibernético de los productos: ¿Por qué la mayoría de los análisis de seguridad son aparentemente correctos, pero en la práctica inútiles?

En la gran mayoría de las empresas tecnológicas ya existe un proceso conocido como evaluación del riesgo ciber. Por lo general adopta la forma de una tabla extensa, una matriz compleja o una hoja de cálculo dominada por los valores «low», «medium» y «high». Este documento incluye una larga lista de amenazas genéricas, descripciones breves de posibles vulnerabilidades y un conjunto de medidas de control estándar. Desde un punto de vista formal, todo encaja: el documento está completo, firmado por la dirección y archivado de forma segura.

El problema es que, en la práctica de ingeniería, ese documento no cambia absolutamente nada.

No influye en la arquitectura del dispositivo que se está diseñando. No condiciona la decisión sobre cómo se entregarán las actualizaciones. No modifica el modelo de soporte posventa ni revisa la relación con los proveedores de componentes. Es un documento correcto desde el punto de vista del compliance, pero totalmente indiferente para la ciberseguridad real de los productos. Y no se debe a una falta de competencias en los equipos de ingeniería o de seguridad. Es un problema de un punto de partida fundamentalmente equivocado.

La mayoría de los análisis de riesgo tradicionales empiezan con la pregunta: «¿Qué amenazas pueden producirse?». Sin embargo, el nuevo enfoque regulatorio de la Unión Europea —claramente visible en textos como el Cyber Resilience Act (CRA), las directivas médicas (MDR) o el nuevo reglamento de máquinas 2023/1230— obliga a adoptar una perspectiva completamente distinta. Esta comienza con la pregunta:

¿En qué condiciones de uso el producto puede convertirse en un portador de riesgo para el usuario, el sistema o el mercado, y si el fabricante es capaz de controlar ese riesgo durante todo su ciclo de vida?

Se trata de un cambio de paradigma fundamental. La evaluación del riesgo ciber en el contexto del producto no es simplemente otro análisis de amenazas de la infraestructura TI. Tampoco es una prueba de penetración ni una aplicación mecánica de las directrices de la norma ISO 27001. Es un análisis en profundidad de la capacidad tanto del propio producto como de su fabricante para mantener la seguridad a lo largo del tiempo, en un entorno operativo real.

Vulnerabilidad técnica y riesgo del producto: una distinción en ciberseguridad

Para que la evaluación del riesgo deje de ser solo una tabla burocrática y se convierta en una herramienta de decisión para ingeniería, debemos separar con precisión dos conceptos que en el mercado se confunden de manera habitual. Recordemos: una vulnerabilidad no es lo mismo que el riesgo del producto.

• Vulnerabilidad técnica es un fallo concreto e identificable en el software, en la configuración del hardware o en el propio diseño. Puede ser una validación incorrecta de datos, una biblioteca de programación obsoleta o una brecha en el mecanismo de autenticación. Este tipo de fallos se registran en bases como el sistema CVE (Common Vulnerabilities and Exposures). Pero sigue siendo una evaluación exclusivamente a nivel técnico.
• Riesgo del producto aparece únicamente cuando esa vulnerabilidad (o incluso su ausencia temporal) se sitúa en la dura realidad del uso.

Ese contexto incluye una serie de variables: el entorno de trabajo (red abierta o aislada), la forma de integración con otros sistemas, el comportamiento de los usuarios, la disponibilidad de actualizaciones de seguridad (el llamado patch management) y la capacidad organizativa del fabricante para responder ante incidentes.

Un producto puede no tener ninguna vulnerabilidad conocida el día de su lanzamiento y, aun así, generar un riesgo crítico si su creador no dispone de procesos de soporte a largo plazo. Comprender esta diferencia ordena todo el trabajo de ingeniería. Precisamente en esto se basa el enfoque basado en el riesgo (risk-based approach). Las medidas de seguridad deben ser proporcionales a los escenarios de abuso previsibles, y no a una lista abstracta sacada de internet.

La paradoja de las protecciones: cuando la seguridad aumenta el riesgo en TI y OT

En el diseño de la ciberseguridad a menudo se asume que añadir un nuevo «candado» siempre reduce el riesgo. La práctica demuestra que puede ocurrir exactamente lo contrario. Una medida implantada sin comprender el contexto crea nuevos vectores de amenaza.

1. Autenticación robusta en un entorno industrial (OT)

Imaginemos la implantación de autenticación multifactor (MFA) en una máquina industrial. Desde el punto de vista de TI es un paso ejemplar, pero la ciberseguridad en la automatización industrial es una realidad completamente distinta. En un entorno de fábrica, el equipo funciona 24/7 y las intervenciones de servicio se realizan bajo presión de tiempo. Cuando la red falla, el técnico no puede autorizar el token en línea. La producción se detiene. ¿El resultado? Un cliente frustrado desactiva este mecanismo de forma permanente, eludiendo por completo la protección. La medida que debía proteger generó un enorme riesgo operativo.

2. Actualizaciones automáticas en dispositivos médicos (IoMT)

La corrección rápida de vulnerabilidades reduce la exposición a ataques, lo cual en el mundo de TI es lo habitual. Sin embargo, en el ámbito del equipamiento médico, una actualización forzada durante un procedimiento puede alterar el comportamiento del sistema o romper la comunicación con la red hospitalaria. En este caso, una protección tecnológica genera un riesgo clínico y regulatorio crítico (incumplimiento de la certificación MDR).

3. Cierre de interfaces en equipos de consumo (IoT)

El fabricante elimina físicamente los puertos de diagnóstico locales de un dispositivo de hogar inteligente para dificultar el acceso a los hackers. En la práctica, los servicios autorizados empiezan a diagnosticar fallos a través de interfaces inestables, omitiendo el cifrado, y los usuarios avanzados instalan de forma masiva software modificado (custom firmware). El resultado es la pérdida total de control del propio ecosistema por parte del fabricante.

Un verdadero análisis de riesgo ciber pregunta: «¿Cómo cambiarán la estabilidad, la usabilidad y la seguridad de todo el ecosistema al añadir este mecanismo concreto?».

Los 5 errores más frecuentes en el análisis de riesgos de productos tecnológicos

Al evaluar procesos en empresas que lanzan al mercado electrónica y software, los expertos en ciberseguridad observan patrones que se repiten.

1. Copiar el modelo corporativo de TI al mundo del producto. Un producto no es un centro de datos. Funciona en un entorno desconocido, a menudo sin conexión, y lo configuran personas sin conocimientos técnicos. Aplicar herramientas de TI al análisis del producto acaba ignorando problemas clave: el ciclo de vida del dispositivo y la ausencia de actualizaciones forzadas.
2. Analizar amenazas abstractas en lugar de escenarios reales. Rellenar una tabla con frases como «acceso no autorizado» es analíticamente inútil. El análisis debe basarse en hechos concretos: ¿Quién? ¿A través de qué interfaz? ¿Con qué objetivo? ¿Con qué consecuencia?
3. Ignorar el ciclo de vida del producto (End-of-Life). El análisis de riesgos suele centrarse en el momento del lanzamiento. Mientras tanto, el riesgo crece con el tiempo: las bibliotecas open-source envejecen y los proveedores de componentes dejan de dar soporte. Sin contemplar el modelo de mantenimiento, el análisis es engañoso.
4. Aislamiento del equipo de diseño (R&D). Tratar la evaluación de riesgos como una checklist previa a una auditoría es el camino directo al desastre. Los resultados deben volver a los ingenieros como requisitos arquitectónicos vinculantes (Secure by Design).
5. Fetichizar la tecnología a costa de los procedimientos. Las empresas invierten una fortuna en criptografía avanzada, pero no saben quién dentro de la organización es responsable de publicar un parche de seguridad tras la notificación de una vulnerabilidad por parte de un investigador (Vulnerability Disclosure Program).

¿Cómo realizar un análisis conforme al Cyber Resilience Act? 7 pasos de ingeniería

La evaluación del riesgo ciber debe dejar de ser una carga burocrática. A continuación se presenta un modelo operativo de mercado, alineado con el enfoque de la UE (entre otros, con los requisitos de la CRA).

1. Define los límites del producto. Un producto no es solo hardware. También incluye la app móvil, la nube, los servidores OTA y las interfaces API.
2. Describe la cruda realidad del entorno de uso. No describas un entorno de laboratorio. Responde a preguntas sobre la conectividad real a internet, las competencias de los usuarios y las posibilidades de acceso físico al dispositivo.
3. Identifica escenarios de abuso (Threat Modeling). Descarta listas genéricas. Utiliza métodos y herramientas de ingeniería contrastados de estimación del riesgo para centrarte en vectores de ataque precisos, adaptados a tu sector.
4. Cuantifica las consecuencias no financieras. Evalúa el riesgo de paradas de producción, amenazas para la salud o incumplimientos de obligaciones regulatorias.
5. Plantea la pregunta sobre el control. ¿Como fabricante, puedes prevenir, detectar y responder con rapidez al escenario de abuso identificado?
6. Diseña mecanismos de protección proporcionales. Las decisiones sobre cifrado o segmentación de red deben derivarse directamente de las respuestas dadas en los pasos anteriores.
7. Diseña el proceso de mantenimiento (Lifecycle). Documenta la política de entrega de parches de seguridad, el periodo de soporte y los canales de comunicación con el cliente.

Resumen: ¿Qué debería quedar tras una evaluación de riesgos rigurosa?

El resultado de una evaluación del riesgo de ciberseguridad del producto bien hecha nunca debería ser un poema denso en texto para el auditor. De este trabajo deben salir artefactos tangibles: un mapa claro de los límites del sistema, decisiones arquitectónicas vinculantes en R&D, un presupuesto aprobado para la política de actualizaciones y una trazabilidad de auditoría coherente que demuestre el cumplimiento de las directivas de la UE.

Una organización tecnológicamente madura ya no pregunta: «¿Somos 100% seguros?». En su lugar pregunta: «¿Dónde exactamente estamos expuestos y somos capaces de gestionarlo en el tiempo?».

¿Tu producto está listo para las nuevas regulaciones?

La seguridad es un proceso, no un certificado puntual. Si no quieres que la evaluación de riesgos en tu empresa se quede en mera «burocracia», conviene actuar de forma proactiva. Mira cómo preparar de verdad tu producto para el Cyber Resilience Act (CRA) en los años 2026-2027, antes de que aparezcan las normas armonizadas oficiales.