Autor: Ramón Segarra Clara. Vocal de Formación en la Junta Directiva de AEINSE
Durante muchos años, el diseño de los sistemas de seguridad electrónica se ha apoyado fundamentalmente en criterios funcionales. En videovigilancia analizamos cobertura, resolución, almacenamiento o capacidad analítica; en control de accesos prestamos atención a lectores, credenciales, controladores, disponibilidad e integración; mientras que en intrusión valoramos detectores, comunicaciones y capacidad de respuesta. A todo ello se suman hoy la interfonía IP, los centros de control, las plataformas de gestión y una infraestructura de comunicaciones que conecta un número creciente de dispositivos y servicios.
Todos estos parámetros continúan siendo esenciales, pero ya no son suficientes. Una cámara IP, un controlador de accesos, una central de intrusión, un videoportero o un servidor de gestión no son únicamente elementos destinados a proteger físicamente una instalación. También ejecutan software, utilizan protocolos de comunicación, gestionan credenciales e intercambian información y, con frecuencia, permiten su administración remota o utilizan servicios externos.
Proteger una instalación exige, por tanto, mirar más allá de su funcionamiento físico y considerar también la seguridad digital de los sistemas que utilizamos para hacerlo.
Esta transformación tecnológica coincide con un importante cambio regulatorio. La Directiva (UE) 2022/2555, conocida como NIS2, el Esquema Nacional de Seguridad (ENS), regulado por el Real Decreto 311/2022, y el Reglamento (UE) 2024/2847, conocido como Cyber Resilience Act (CRA) responden a objetivos y ámbitos de aplicación diferentes. Sin embargo, los tres muestran hasta qué punto la ciberseguridad está adquiriendo relevancia desde la definición de requisitos hasta la operación y mantenimiento de productos y sistemas digitales.
¿Puede considerarse seguro un sistema que protege físicamente una instalación pero introduce vulnerabilidades digitales en ella?
Tres normas diferentes ante un mismo cambio tecnológico
Antes de analizar sus consecuencias conviene evitar una simplificación. NIS2, ENS y CRA no son normas equivalentes ni resultan automáticamente aplicables a cualquier instalación de seguridad.
La Directiva NIS2 establece medidas destinadas a alcanzar un elevado nivel común de ciberseguridad en la Unión Europea. Entre otras obligaciones, su artículo 21 exige a las entidades esenciales e importantes comprendidas en su ámbito adoptar medidas técnicas, operativas y organizativas adecuadas y proporcionadas para gestionar sus riesgos de ciberseguridad.
Entre ellas encontramos el análisis de riesgos, la gestión de incidentes, la continuidad de las actividades, la seguridad de la cadena de suministro, la adquisición y mantenimiento de sistemas, la gestión y divulgación de vulnerabilidades, la criptografía y el control de acceso.
En España existe además una circunstancia que requiere especial precisión. El plazo establecido para transponer NIS2 finalizó el 17 de octubre de 2024 y, en el momento de redactar este artículo, continúa pendiente su completa incorporación al ordenamiento español mediante la futura Ley de Coordinación y Gobernanza de la Ciberseguridad. Por tanto, es necesario diferenciar entre lo establecido directamente por la Directiva y lo que finalmente determine la legislación nacional.
Por su parte, el ENS establece los principios básicos y requisitos mínimos necesarios para conseguir una protección adecuada de la información y los servicios dentro de su ámbito de aplicación.
Finalmente, el CRA introduce requisitos horizontales de ciberseguridad para los productos con elementos digitales incluidos en su ámbito, además de obligaciones para fabricantes y otros operadores económicos.
Aunque sus ámbitos y obligaciones son distintos, las tres normas permiten observar el problema desde perspectivas que terminan relacionándose entre sí. NIS2 se ocupa especialmente de cómo gestionan el riesgo las entidades afectadas; el ENS fija condiciones de seguridad para los sistemas comprendidos en su ámbito y el CRA introduce requisitos de ciberseguridad para los productos con elementos digitales a lo largo de su ciclo de vida.
Para la ingeniería de seguridad, lo relevante aparece cuando esas tres perspectivas coinciden en un mismo proyecto: el producto que instalamos, el sistema en el que se integra y la organización que finalmente depende de él.
NIS2, ENS y CRA: tres enfoques complementarios ante un mismo objetivo de seguridad
La seguridad electrónica se ha convertido también en un entorno digital
Una instalación actual puede integrar cámaras y grabadores, controladores y lectores de acceso, centrales de intrusión, interfonos IP, servidores, puestos de operador y plataformas que combinan varios subsistemas. Al mismo tiempo, estos elementos pueden apoyarse sobre switches, routers, firewalls, redes inalámbricas, almacenamiento, aplicaciones móviles y servicios cloud.
En una instalación así, una debilidad difícilmente puede analizarse como un problema aislado del dispositivo en el que aparece.
Un controlador de accesos puede cumplir perfectamente su función física y mantener unas credenciales administrativas inadecuadas. Una central de intrusión podría tener servicios innecesarios habilitados; un servidor de gestión permanecer sin actualizar; un sistema de interfonía utilizar comunicaciones insuficientemente protegidas o un acceso remoto deficientemente configurado facilitar una entrada no autorizada.
Esto cambia también las preguntas que hacemos al seleccionar un equipo. Ya no basta con conocer qué hace: interesa saber cómo se comunica, quién puede administrarlo, qué información intercambia, cómo recibe actualizaciones y durante cuánto tiempo permanecerá soportado.
Sistemas de seguridad conectados: Una debilidad puede afectar al conjunto
El CRA lleva la ciberseguridad hasta el producto
El Cyber Resilience Act supone un cambio especialmente significativo para los productos con elementos digitales incluidos en su ámbito.
Aunque será aplicable con carácter general a partir del 11 de diciembre de 2027, su calendario contiene fechas anteriores. El capítulo IV, relativo a los organismos de evaluación de la conformidad, es aplicable desde el 11 de junio de 2026 y las obligaciones de notificación del artículo 14 lo serán desde el 11 de septiembre de 2026. Por ello, en agosto de 2026 todavía no podemos afirmar que el Reglamento sea plenamente aplicable.
Más allá del calendario de aplicación, el CRA introduce un criterio que interesa especialmente a la ingeniería. Establece requisitos esenciales tanto para las características de ciberseguridad de los productos como para la gestión de sus vulnerabilidades. Entre otras cuestiones, estos deberán diseñarse, desarrollarse y producirse con un nivel de ciberseguridad adecuado al riesgo.
Este planteamiento puede modificar progresivamente nuestra forma de comparar equipos. Dos controladores de accesos, centrales de intrusión, cámaras o dispositivos de comunicaciones pueden proporcionar prestaciones funcionales similares y, sin embargo, diferenciarse considerablemente en la gestión de actualizaciones, tratamiento de vulnerabilidades, autenticación, cifrado, configuración predeterminada o duración del soporte.
El periodo durante el que un producto podrá mantenerse razonablemente protegido deja así de ser un dato secundario y empieza a tener peso en la decisión técnica, igual que otras prestaciones que siempre hemos consultado en una ficha técnica.
NIS2 amplía la mirada hacia la organización y sus proveedores
Mientras el CRA presta especial atención al producto, la Directiva NIS2 obliga a contemplar el riesgo desde la perspectiva de las entidades afectadas.
Esta visión resulta especialmente interesante para nuestro sector porque los sistemas de seguridad electrónica mantienen cada vez más relaciones con otros recursos tecnológicos. Un centro de control puede depender de servidores corporativos; el control de accesos puede intercambiar información con directorios de usuarios; una plataforma de gestión puede utilizar servicios externos y los mantenedores pueden necesitar conexiones remotas.
NIS2 incorpora expresamente la seguridad de la cadena de suministro entre las medidas de gestión de riesgos. Eso obliga a mirar también a quienes están detrás del equipo instalado: fabricantes, proveedores y prestadores de servicios.
Cómo responde un fabricante ante una vulnerabilidad, cuánto tiempo mantiene el soporte o qué seguridad ofrecen los servicios asociados son cuestiones que pueden acabar influyendo directamente en el riesgo asumido por la organización.
El ENS aporta una visión integral del sistema
En España, el Real Decreto 311/2022, por el que se regula el Esquema Nacional de Seguridad, resulta especialmente ilustrativo porque establece la seguridad como un proceso integral y adopta una gestión basada en los riesgos.
Además, su anexo II organiza las medidas de seguridad en marco organizativo, marco operacional y medidas de protección. Dentro de estas últimas aparecen controles relacionados con instalaciones e infraestructuras, personal, equipos, comunicaciones, soportes de información, aplicaciones, información y servicios.
Para los proyectos comprendidos en su ámbito, este planteamiento tiene una consecuencia práctica: determinadas decisiones no pueden posponerse hasta la puesta en servicio.
La segregación de redes, la protección de las comunicaciones, el control de acceso, el registro de actividad o la configuración de los equipos pueden condicionar desde el principio tanto la selección de productos como el diseño de las comunicaciones y los posteriores procedimientos de operación.
La conclusión práctica es clara: estas decisiones deben plantearse ya durante la definición de requisitos, no cuando la instalación está terminada.
La red también forma parte de la seguridad
La progresiva interconexión de los sistemas obliga igualmente a reconsiderar el papel de las comunicaciones. La red ya no es simplemente el medio que transporta vídeo, alarmas, eventos o comandos, porque su configuración influye directamente en la protección del conjunto.
Una segmentación adecuada puede limitar comunicaciones innecesarias y reducir las consecuencias de la vulneración de un dispositivo. Asimismo, los mecanismos de control de acceso permiten restringir conexiones, mientras que los firewalls pueden limitar servicios y la monitorización facilita detectar comportamientos anómalos.
Algo similar sucede con el acceso remoto. Administrar o mantener una instalación a distancia aporta importantes ventajas operativas, pero también introduce un punto adicional de exposición. Por ello, autenticación, autorización, cifrado y registro de las conexiones deben formar parte de su evaluación.
En sistemas que dependen cada vez más de las comunicaciones, separar conceptualmente la red del propio sistema de seguridad resulta difícil de justificar.
Del pliego al fin de vida: ¿qué cambia realmente en un proyecto?
Todo lo anterior se entiende mejor si seguimos el proyecto desde la elección del producto hasta su retirada.
Antes de seleccionar un producto, puede resultar necesario conocer su periodo previsto de soporte, la política del fabricante ante vulnerabilidades, los mecanismos de actualización disponibles y las posibilidades de autenticación y protección de las comunicaciones.
Posteriormente, durante el diseño, habrá que determinar qué dispositivos necesitan comunicarse entre sí, cómo deben segmentarse, quién tendrá privilegios administrativos, cómo se realizará el acceso remoto y qué acontecimientos será necesario registrar.
La puesta en servicio incorpora igualmente nuevas comprobaciones. Verificar las versiones de firmware, sustituir credenciales predeterminadas, revisar los servicios habilitados y conservar las configuraciones relevantes puede ser tan importante como comprobar que cada equipo realiza correctamente su función.
Finalmente, durante la explotación será necesario prestar atención a vulnerabilidades, actualizaciones y cambios de configuración, hasta llegar al momento en que un componente deje de recibir soporte y deba evaluarse su sustitución.
Esta perspectiva resulta especialmente importante en seguridad física, donde determinados equipos permanecen en servicio durante muchos años.
La seguridad debe mantenerse durante todo el ciclo de vida del sistema
Una nueva forma de prescribir y comparar productos
Todo ello puede terminar modificando también nuestros pliegos y especificaciones técnicas.
Tradicionalmente hemos descrito con enorme precisión capacidad, resolución, interfaces, almacenamiento, autonomía, condiciones ambientales o certificaciones. Sin embargo, todavía es frecuente encontrar poca información sobre cómo responderá el producto frente a vulnerabilidades durante su vida útil.
En función del riesgo del proyecto, puede resultar razonable incorporar criterios verificables relacionados con el periodo de soporte, los mecanismos de actualización, las opciones de autenticación y cifrado, la generación de registros, la configuración segura o los procedimientos de divulgación de vulnerabilidades.
Incorporar ciberseguridad al pliego tampoco significa añadir requisitos genéricos de forma indiscriminada. Cada exigencia debería responder a un riesgo concreto y, sobre todo, poder comprobarse técnicamente.
De este modo, cuando comparemos dos productos funcionalmente equivalentes podremos plantearnos no solo cuál ofrece mejores prestaciones, sino también cuál podremos mantener razonablemente protegido durante el periodo previsto de utilización.
Una evolución inevitable para el ingeniero de seguridad
Este cambio no significa que el ingeniero de seguridad deba convertirse en especialista en todas las disciplinas de ciberseguridad. Sin embargo, cada vez resulta más difícil proyectar sistemas conectados sin comprender conceptos como segmentación, autenticación, cifrado, actualización, gestión de vulnerabilidades, registro de eventos o protección del acceso remoto.
La especialización seguirá siendo necesaria. Un ingeniero de seguridad no tiene por qué asumir las funciones del especialista en redes o ciberseguridad, pero sí necesita entenderse con ellos. Una decisión correcta dentro de una disciplina puede generar un problema si se adopta sin considerar sus efectos sobre el resto del sistema.
NIS2, ENS y CRA aceleran esta evolución desde perspectivas diferentes, aunque detrás de las tres normas existe una realidad tecnológica común: los sistemas destinados a proteger instalaciones, bienes y personas son cada vez más digitales, están más conectados y dependen de un mayor número de componentes y proveedores.
El cambio, visto desde la ingeniería de seguridad, va bastante más allá de incorporar un apartado adicional de cumplimiento normativo. También obliga a revisar qué entendemos por un proyecto técnicamente bien resuelto.
Ya no basta con preguntarnos si el sistema detectará una intrusión, permitirá únicamente los accesos autorizados, proporcionará las imágenes necesarias o mantendrá operativo un centro de control. También debemos saber si podremos actualizarlo, controlar quién accede a él, limitar sus comunicaciones, conocer sus vulnerabilidades y mantenerlo protegido durante el tiempo que permanezca en servicio.
En este proceso de transformación, asociaciones profesionales como AEINSE — Asociación Española de Ingenieros de Seguridad desempeña un papel especialmente relevante, impulsando entre los profesionales una visión holística de la ingeniería de seguridad capaz de integrar la protección física y la ciberseguridad como dimensiones inseparables de unos sistemas cada vez más conectados. Promover esa evolución profesional y contribuir a que los criterios técnicos avancen al mismo ritmo que las amenazas y la regulación supone, además, reforzar el papel del ingeniero como garante de una seguridad concebida de manera integral.
Al final, el cumplimiento normativo es una parte de la cuestión, pero no la única.
Si un sistema protege físicamente una instalación, pero introduce una vulnerabilidad digital en ella, ¿podemos seguir considerándolo un buen sistema de seguridad?
#NIS2 #ENS #CyberResilienceAct #Ciberseguridad #IngenieríaDeSeguridad #SeguridadElectrónica #SeguridadFísica #AEINSE
-
- blog de Ramón Segarra Clara
- Inicie sesión para comentar
