Etiqueta: Cyber-Physical Security

  • Verificación de la segmentación de red en sistemas de seguridad física

    Verificación de la segmentación de red en sistemas de seguridad física

    Los diagramas de red suelen mostrar los sistemas de seguridad física en zonas cuidadosamente separadas, pero un diagrama no demuestra que los controles funcionen. La deriva de los cortafuegos, las reglas temporales de mantenimiento, los servidores conectados a dos redes y los conmutadores no gestionados pueden volver a conectar redes que debían permanecer aisladas. La verificación de la segmentación prueba las rutas desplegadas en lugar de confiar en el documento de diseño.

    Definir zonas y flujos permitidos

    Comience por zonas funcionales como dispositivos de campo, controladores, grabación, gestión, clientes de operador, servicios de integración y soporte remoto. Para cada par de zonas, documente el origen, destino, protocolo y propósito empresarial exactos permitidos. Todo lo demás debe denegarse de forma predeterminada cuando la arquitectura lo permita.

    Incluya dependencias que es fácil pasar por alto: DNS, NTP, inscripción de certificados, servicios de directorio, repositorios de software, retransmisores de correo electrónico y supervisión. Una lista de permitidos incompleta puede empujar a los equipos a implantar reglas de emergencia amplias que después se vuelven permanentes.

    Verificar desde puntos finales representativos

    Las pruebas deben originarse en clases reales de dispositivos o equivalentes seguros. Un análisis desde la red de TI no puede demostrar a qué puede acceder una cámara o un controlador integrado. Confirme las conexiones previstas y después intente recorrer rutas prohibidas de forma controlada. Revise tanto el resultado del cliente como el registro del cortafuegos o conmutador para poder distinguir entre descartes silenciosos y fallos de enrutamiento.

    Las directrices de NIST sobre seguridad de tecnología operativa recomiendan la segmentación y las rutas de comunicación controladas como medidas centrales de reducción de riesgos. Las redes de seguridad física comparten muchas de las mismas limitaciones: dispositivos de larga vida útil, protocolos de proveedores, requisitos de disponibilidad y protección limitada de los puntos finales.

    Probar por separado el acceso de gestión y de proveedores

    Las rutas administrativas merecen una validación más estricta que el tráfico ordinario de eventos. Confirme que la gestión de dispositivos esté limitada a servidores de salto aprobados, usuarios identificados y sesiones supervisadas. Compruebe si el acceso VPN de proveedores solo puede llegar a los sistemas contratados y si se desactiva fuera de las ventanas aprobadas.

    Compruebe si existen rutas alternativas a través de Wi-Fi, módems celulares, interfaces de red secundarias y portátiles de servicio. Un controlador aislado en la interfaz principal podría seguir exponiendo un servicio de gestión a través de un canal pasado por alto. El artículo de SectechMedia sobre refuerzo de la ciberseguridad del control de acceso aborda controles relacionados con dispositivos y credenciales.

    Incluir estados de fallo y recuperación

    La segmentación puede cambiar durante una conmutación por error. Pruebe cortafuegos redundantes, enlaces de respaldo, sitios de recuperación ante desastres y el enrutamiento temporal utilizado durante el mantenimiento. Confirme que un dispositivo de seguridad averiado no establezca de forma predeterminada una ruta sin restricciones y que las configuraciones restauradas conserven la política aprobada.

    Registre capturas de paquetes o pruebas de los registros para las pruebas críticas. Una simple hoja de trabajo de aprobado o suspenso es insuficiente cuando una regla cambia posteriormente o un equipo de incidentes necesita conocer la accesibilidad histórica.

    Gestionar las excepciones como riesgos con vencimiento

    Cada excepción debe identificar el responsable, el motivo, los controles compensatorios y la fecha de vencimiento. Vuelva a realizar pruebas después de actualizaciones de firmware, migraciones de VMS, sustituciones de controladores y rediseños de red. Haga seguimiento de rutas accesibles inesperadas, reglas obsoletas y activos fuera de su zona asignada. El resultado debe ser un programa de verificación vivo que detecte la deriva arquitectónica antes de que un atacante o una interrupción la ponga de manifiesto.

    Fuentes de referencia

  • Ciclo de vida de los certificados de dispositivos de seguridad y pruebas de caducidad

    Ciclo de vida de los certificados de dispositivos de seguridad y pruebas de caducidad

    Los certificados protegen cada vez más la comunicación entre cámaras, controladores de acceso, grabadores, servidores de gestión y clientes de operador. También pueden convertirse en un punto único de fallo oculto. Un certificado caducado puede bloquear el acceso de gestión, interrumpir la entrega de eventos o alentar a los operadores a omitir la validación durante una interrupción. Por tanto, la gestión del ciclo de vida debe probarse como un control operativo y no tratarse como un ejercicio anual con hojas de cálculo.

    Crear un inventario basado en la responsabilidad

    Registre el sujeto, emisor, número de serie, periodo de validez, uso de la clave, punto final, cadena de confianza y responsable de cada certificado. Incluya dispositivos integrados, proxies inversos, API, credenciales móviles y servicios internos. El inventario debe distinguir los certificados públicos de los certificados de infraestructura de clave pública privada y de los certificados autofirmados generados por los dispositivos.

    La responsabilidad importa porque la renovación puede involucrar a distintos equipos. Un integrador de seguridad puede gestionar las cámaras, la infraestructura corporativa puede operar la autoridad de certificación y un proveedor puede controlar un conector en la nube. Cada certificado necesita una ruta de decisión designada antes de caducar.

    Probar la validación desde los clientes reales

    Un certificado puede parecer correcto en una consola de gestión y, aun así, fallar en un grabador o controlador antiguo que no disponga de la cadena emisora. Realice pruebas desde cada clase de cliente, incluidos puestos de trabajo de operadores, aplicaciones móviles, API y servidores de conmutación por error. Valide la coincidencia del nombre de host, los anclajes de confianza, el comportamiento de revocación y la sincronización horaria. Las directrices de NIST para la gestión de claves subrayan que los controles criptográficos dependen de claves protegidas, ciclos de vida definidos y procesos con responsabilidades claras.

    No desactive la validación para conseguir que una prueba se complete. Si un cliente no puede admitir el modelo de confianza requerido, documente la limitación y aísle el riesgo mientras planifica su sustitución o una pasarela aprobada.

    Ensayar la renovación antes de la fecha límite

    Utilice un punto final que no sea de producción o un dispositivo piloto para ensayar las solicitudes de firma de certificados, la aprobación, la instalación y los requisitos de reinicio del servicio. Confirme si las claves privadas pueden permanecer en el dispositivo y si la renovación cambia las huellas digitales utilizadas por las integraciones. Pruebe periodos de validez superpuestos para poder distribuir una cadena nueva antes de que caduque la anterior.

    La supervisión automatizada debe advertir en varios umbrales, pero las alertas no son suficientes. Un ejercicio de renovación debe demostrar que el equipo puede obtener, desplegar y validar el reemplazo dentro de la ventana disponible. La guía de SectechMedia sobre inventario de activos y gestión de la configuración muestra cómo la responsabilidad y los registros de referencia respaldan este proceso.

    Proteger las claves y el material de recuperación

    Las claves privadas deben generarse y almacenarse según el riesgo y las capacidades del dispositivo. Restrinja la exportación, proteja las credenciales de inscripción y registre los cambios administrativos. Cuando no se disponga de almacenamiento respaldado por hardware, utilice controles compensatorios como el aislamiento de red, la gestión con privilegios mínimos y procedimientos rápidos de revocación.

    Realice copias de seguridad de la configuración de la autoridad de certificación y documente las dependencias de recuperación, pero evite copiar claves privadas en sistemas generales de incidencias o carpetas compartidas. Las pruebas de recuperación deben demostrar que los certificados pueden volver a emitirse sin reutilizar material de claves comprometido.

    Medir el estado del ciclo de vida

    Entre las métricas útiles se incluyen los certificados desconocidos, los certificados sin responsable, las rutas de validación fallidas, las renovaciones completadas antes del umbral y las excepciones de emergencia. Revise el inventario después de sustituir dispositivos, actualizar firmware y modificar la arquitectura. El objetivo no es simplemente que no haya caducidades; es mantener una confianza cifrada que sobreviva al mantenimiento rutinario y a la respuesta ante incidentes.

    Fuentes de referencia