We’re Tracking the Future of Security

Etiqueta: Access Control

  • Noblis patenta un sistema de autenticación continua que utiliza biometría y sensores ambientales

    Noblis patenta un sistema de autenticación continua que utiliza biometría y sensores ambientales

    Noblis ha anunciado una patente estadounidense para un sistema electrónico de control de acceso diseñado para verificar de forma continua la identidad y las condiciones ambientales, en lugar de depender únicamente de una comprobación al iniciar sesión. La patente estadounidense n.º 12,682,086 combina detección biométrica, supervisión ambiental y análisis mediante aprendizaje automático, según la organización de investigación.

    La identidad y el contexto se evalúan conjuntamente

    El sistema descrito combina reconocimiento facial, seguimiento de la mirada y detección del parpadeo con señales sobre seguridad espacial, condiciones electromagnéticas e integridad de la red. Esas entradas contribuyen a una puntuación dinámica de prueba de vida destinada a identificar ataques de presentación, como fotografías o deepfakes, mientras se comprueba si la persona autorizada sigue presente. Según los criterios configurados, el sistema puede mantener el acceso, restringir determinadas funciones o bloquear el acceso cuando cambian las condiciones.

    Una patente no constituye una prueba de despliegue

    El anuncio documenta una arquitectura patentada y las capacidades previstas; por sí solo, no demuestra la adopción en producción, resultados independientes de rendimiento ni una certificación para un despliegue concreto. Los equipos de seguridad que evalúen la autenticación continua aún deben considerar la privacidad, la gobernanza de los datos biométricos, la gestión de fallos, la accesibilidad, la fiabilidad de los sensores y el impacto operativo de las decisiones erróneas. El enfoque es pertinente para escenarios de acceso remoto y de alta garantía en los que una comprobación puntual de credenciales puede no ofrecer garantías suficientes durante toda una sesión. Se hace un seguimiento de más avances en identidad y control de acceso en el archivo de noticias tecnológicas de SectechMedia.

    Fuentes

  • Validación de copias de seguridad y restauración de controladores de acceso

    Validación de copias de seguridad y restauración de controladores de acceso

    Las plataformas de control de acceso suelen informar de que una copia de seguridad se ha completado correctamente, pero ese mensaje no demuestra que un controlador pueda restaurarse tras un fallo de hardware, una corrupción o una actualización fallida. Un programa de recuperación útil valida todo el estado operativo: identidades, credenciales, configuración de puertas, horarios, lógica de alarmas, integraciones, material criptográfico y evidencias de auditoría.

    Definir la configuración recuperable

    Comience con un inventario de controladores, módulos de expansión, lectores, interfaces y versiones de software. Registre qué información reside de forma centralizada y cuál permanece únicamente en el hardware de campo. Algunos sistemas realizan copias de seguridad de la base de datos del servidor, pero omiten archivos específicos del controlador, certificados, scripts personalizados o secretos de integración. Documente los componentes exactos necesarios para reconstruir cada clase de controlador.

    Establezca objetivos de recuperación que reflejen el riesgo operativo. La entrada de una sede central y un armario remoto de servicios públicos pueden requerir distintos tiempos de recuperación y tolerancias de pérdida de datos. Las directrices de planificación de contingencias del NIST recomiendan vincular los procedimientos técnicos de recuperación con el impacto empresarial en lugar de depender de un único calendario genérico de copias de seguridad.

    Proteger las copias de seguridad como activos de seguridad

    Las copias de seguridad de controladores pueden contener datos de titulares de credenciales, direcciones de red, claves de cifrado y configuración privilegiada. Almacénelas con cifrado, acceso basado en roles, comprobaciones de integridad y controles de retención. Mantenga al menos una copia fuera del entorno de gestión de producción para que el ransomware o un error administrativo no puedan eliminar tanto el sistema activo como su material de recuperación.

    Cada copia de seguridad debe tener un dispositivo de origen identificable, una versión de software, una hora de creación y un propietario aprobado. Los hashes y el almacenamiento inmutable pueden ayudar a detectar cambios no intencionados. Las credenciales de restauración deben controlarse por separado de las cuentas rutinarias de los operadores.

    Restaurar en un entorno de prueba representativo

    Utilice hardware de repuesto o aislado que coincida con un controlador de producción. Restaure la copia de seguridad y verifique que el dispositivo arranca, establece comunicaciones seguras y recibe la configuración prevista. Compare los recuentos de titulares de tarjetas, niveles de acceso, horarios, festivos, parámetros de puertas, lógica de entrada/salida y enrutamiento de eventos con la línea base.

    No basta con que una base de datos se abra sin errores. Pruebe una credencial válida, una credencial denegada, una alarma de puerta forzada, una interrupción de las comunicaciones y una decisión local mientras el dispositivo está desconectado del servidor. La guía de SectechMedia sobre pruebas de eventos y reloj del control de acceso ofrece comprobaciones complementarias para la fiabilidad de la auditoría.

    Tener en cuenta las dependencias de versiones y claves

    La recuperación puede fallar cuando el hardware de sustitución ejecuta una rama de firmware diferente o cuando los certificados y las claves de cifrado no están disponibles. Pruebe las rutas compatibles de actualización y reversión, los procedimientos de importación de claves y la restauración de licencias. Si una copia de seguridad solo puede restaurarse mediante una versión intermedia del software, conserve ese instalador y documente la secuencia.

    Las integraciones con sistemas de identidad, plataformas de vídeo y gestión de visitantes deben probarse con terminales que no sean de producción. Confirme que los conectores restaurados no envíen comandos accidentalmente ni dupliquen registros en los sistemas activos.

    Cerrar la prueba con evidencias

    Registre la duración de la recuperación, el alcance de los datos restaurados, las excepciones y las acciones correctivas. Actualice el procedimiento operativo después de cada cambio de arquitectura o firmware y repita las pruebas según un calendario basado en el riesgo. Un programa maduro de copias de seguridad demuestra la capacidad de recuperación mediante resultados observados, no solo mediante la existencia de archivos.

    Fuentes de referencia

  • Una encuesta de Mercury detecta mayores deficiencias de ciberseguridad en los controladores de acceso físico

    Una encuesta de Mercury detecta mayores deficiencias de ciberseguridad en los controladores de acceso físico

    Una nueva encuesta de Mercury Security indica que los requisitos de ciberseguridad están avanzando más rápido que algunas partes de la base instalada de controladores de acceso físico. El informe 2026 Trends in Access Controllers Report de la empresa encuestó a 561 profesionales de la seguridad física y la ciberseguridad, entre ellos administradores, integradores, instaladores y usuarios finales.

    Las deficiencias de ciberseguridad notificadas aumentaron interanualmente

    El treinta y dos por ciento de los encuestados afirmó que sus sistemas de controladores actuales carecían de funciones de ciberseguridad, frente al 21% en la encuesta de 2025. Mercury también informó de que al 74% le resultaba más difícil gestionar la coordinación entre la ciberseguridad y TI, aunque el 86% afirmó que sus organizaciones se esfuerzan por mantenerse al día con los cambiantes requisitos de seguridad y protección de datos.

    La interoperabilidad siguió siendo fundamental en las decisiones de compra. El sesenta y nueve por ciento la describió como esencial, mientras que el 82% consideró importante para la planificación futura la compatibilidad con versiones anteriores y posteriores. El interés por la conectividad en la nube también superó su despliegue: el 56% la citó como un factor de compra, pero el 41% informó de controladores habilitados para la nube.

    La modernización necesita controles verificables

    Los resultados de la encuesta describen las percepciones de los encuestados, no una auditoría independiente de los sistemas instalados. Aun así, refuerzan la necesidad de verificar el arranque seguro, las comunicaciones cifradas, la protección de credenciales, la disponibilidad de parches, los registros y la segmentación de red durante la selección de controladores. SectechMedia realiza un seguimiento de la arquitectura relacionada en su cobertura de control de acceso e identidad.

    Fuentes

  • 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

  • Pruebas de marcas de tiempo de eventos y sincronización de relojes en el control de acceso

    Pruebas de marcas de tiempo de eventos y sincronización de relojes en el control de acceso

    Las investigaciones de control de acceso dependen de saber qué evento ocurrió primero. Una transacción de puerta, un vídeo de alarma y un registro de intrusión pueden describir el mismo incidente con distintas marcas de tiempo cuando los relojes de los controladores derivan o los sistemas aplican las zonas horarias de forma incoherente.

    Identificar todos los relojes de la cadena de eventos

    Identifique la fuente horaria utilizada por el servidor de gestión, la base de datos, los controladores de campo, los lectores, el sistema de vídeo y la plataforma de operaciones de seguridad. Registre si cada dispositivo almacena la hora local o la hora universal coordinada y dónde se realiza la conversión del horario de verano.

    Defina el desfase aceptado para la visualización operativa y la correlación forense. Unos pocos segundos pueden ser aceptables para el acceso rutinario, mientras que un flujo de trabajo de vídeo o enclavamiento estrechamente integrado puede exigir una tolerancia menor.

    Crear un evento de referencia repetible

    Utilice una credencial de prueba aprobada en una puerta seleccionada mientras registra una referencia horaria independiente y fiable. Genere un acceso concedido, un acceso denegado, una alarma de puerta forzada y una alarma de puerta mantenida abierta. Capture las marcas de tiempo en el controlador, el servidor, la base de datos de auditoría y la pantalla del operador.

    Repita la prueba en un controlador remoto y en un dispositivo que se haya reiniciado recientemente. Compare la hora de creación del evento con la hora de recepción para no confundir el retardo de red con un error del reloj.

    Probar las interrupciones y la resincronización

    Desconecte un controlador siguiendo un plan controlado, permita que registre transacciones locales y después restablezca las comunicaciones. Confirme que los eventos almacenados en búfer conservan sus horas de ocurrencia originales y aparecen en el orden correcto tras la carga.

    Reinicie los servicios horarios y pruebe un límite de horario de verano o de zona horaria en un entorno que no sea de producción siempre que sea posible. Verifique que las marcas de tiempo duplicadas o imposibles se gestionen de forma clara, en lugar de reordenarse silenciosamente.

    Verificar la correlación entre sistemas

    Compare los eventos de acceso con los marcadores de vídeo, las alarmas de intrusión y los registros de visitantes. Confirme que un operador que seleccione un evento de acceso reciba el intervalo de cámara correcto. Si las integraciones añaden su propia marca de tiempo, documente qué valor es el oficial.

    El aseguramiento horario debe formar parte de una gobernanza más amplia de control de acceso e identidad, especialmente cuando los registros respaldan investigaciones o informes de cumplimiento.

    Supervisar la deriva durante el ciclo de vida

    Registre el desfase por dispositivo y analice su evolución a lo largo del tiempo. Genere alertas ante fallos de sincronización, grandes saltos o controladores que pierdan repetidamente la hora tras una interrupción de la alimentación. Repita las pruebas después de cambios de firmware, red, directorio o servicio horario.

    Conserve las capturas de pantalla, los registros sin procesar y la referencia fiable utilizada durante las pruebas. Clasifique las desviaciones como errores del reloj del dispositivo, de conversión, de transporte o de visualización. Corrija la causa raíz y vuelva a ejecutar la misma secuencia de eventos antes de cerrar la incidencia.

    Definir la responsabilidad y el escalado

    Asigne responsabilidades sobre las fuentes horarias empresariales, la configuración de controladores y el mapeo de integraciones. Cuando aparezca una alerta de deriva, los operadores necesitan una vía de escalado documentada, no un reajuste informal del reloj. Registre la causa, el intervalo afectado y cualquier prueba cuya cronología pueda requerir una salvedad.

    Incluya la integridad horaria en los informes rutinarios de estado. Un servidor sincronizado no puede compensar un controlador que ha dejado de aceptar actualizaciones, y un reloj correcto del controlador no impide que una plataforma receptora aplique la zona horaria equivocada. Cierre las incidencias únicamente después de repetir satisfactoriamente un evento de extremo a extremo.

    Fuentes de referencia

  • Pruebas de antipassback en el control de acceso y gestión de excepciones

    Pruebas de antipassback en el control de acceso y gestión de excepciones

    El antipassback utiliza el historial de acceso para impedir que una credencial entre o salga siguiendo una secuencia imposible. Puede reducir el uso compartido de credenciales y mejorar los registros de ocupación, pero una regla mal probada también puede bloquear a usuarios legítimos o generar una lista de evacuación engañosa.

    Mapear la secuencia controlada

    Identifique todos los lectores que cambian la ubicación lógica de una persona. El mapa debe incluir puertas principales, torniquetes, accesos para vehículos, rutas accesibles, salidas de emergencia y entradas de servicio. Una puerta sin lector de salida puede necesitar una política diferente a la de un punto de acceso totalmente controlado.

    Defina si el sistema utiliza antipassback estricto, que deniega una secuencia no válida, o antipassback flexible, que registra un evento pero permite el acceso. El comportamiento seleccionado debe reflejar los requisitos de seguridad, continuidad del negocio y supervisión.

    Probar recorridos normales y anómalos

    Haga pasar una credencial por secuencias válidas de entrada y salida y, después, pruebe entradas repetidas, salidas repetidas y desplazamientos entre zonas anidadas. Confirme que el mensaje del evento identifica la credencial, el lector, el estado anterior y la decisión de la política. Pruebe la misma secuencia después de reiniciar un controlador y tras una interrupción temporal de la red.

    Incluya situaciones de acceso por seguimiento en las que el paso físico no coincida con el evento de la credencial. El antipassback no puede detectar de forma fiable la ocupación cuando las personas eluden los lectores, por lo que las puertas, los torniquetes y los procedimientos deben respaldar el modelo lógico.

    Controlar excepciones y restablecimientos

    Documente quién puede restablecer el estado de una credencial, con qué pruebas y con qué registro de auditoría. El personal de recepción, los supervisores de seguridad y los administradores del sistema pueden necesitar permisos diferentes. Un restablecimiento masivo después de una interrupción debe requerir aprobación y no debe borrar las alarmas originales.

    Defina excepciones para visitantes, acompañantes, repartidores y servicios de emergencia. Las anulaciones temporales necesitan una fecha de caducidad. La salida de emergencia nunca debe depender de una secuencia de credenciales satisfactoria, y los requisitos de seguridad de las personas tienen prioridad sobre la precisión de la ocupación.

    Verificar integraciones e informes

    Compruebe cómo aparecen los eventos de antipassback en la consola de operaciones de seguridad, el sistema de visitantes y los informes de evacuación. Si los controladores de acceso siguen funcionando sin conexión, verifique cómo se concilian las transacciones cuando se restablece la comunicación y si se resaltan los estados en conflicto.

    Analice las tendencias de denegaciones y restablecimientos manuales por lector y hora. Un aumento repentino puede indicar un lector de salida averiado, un flujo de usuarios deficiente o un abuso de la política. Las pruebas de antipassback deben formar parte de la garantía rutinaria de control de acceso e identidad y repetirse después de cambios en lectores, controladores, topología o reglas.

    Mantener una referencia operativa

    Mantenga una matriz aprobada de lectores, zonas, tipos de reglas y responsables de las excepciones. Compare mensualmente las tasas de denegación, anulación y restablecimiento con la referencia para que los defectos recurrentes sean visibles. Una ubicación con frecuentes restablecimientos manuales necesita una investigación, no una regla permanentemente relajada.

    Después de cambios de firmware, base de datos o integración, repita una secuencia representativa de entrada y salida, una recuperación del controlador sin conexión y una excepción supervisada. Conserve capturas de pantalla o exportaciones de eventos junto con el registro de la prueba. Estas pruebas ayudan a distinguir un defecto de configuración de un error normal del usuario y facilitan una reversión controlada.

    Fuentes de referencia