Categoría: Control de acceso e identidad

Control de acceso e identidad

  • Una propuesta de un proveedor añadiría reconocimiento facial a los datos exportados de cámaras Flock

    Una propuesta de un proveedor añadiría reconocimiento facial a los datos exportados de cámaras Flock

    Un proveedor de software de vigilancia ha propuesto combinar imágenes exportadas de Flock Safety con capacidades de reconocimiento facial en una plataforma de pruebas independiente, según información basada en una propuesta comercial presentada a un departamento de policía de Tennessee. La propuesta destaca cómo los datos pueden adquirir nuevos usos analíticos después de salir del sistema que los recopiló originalmente.

    La integración propuesta no es una función desplegada de Flock

    VIDIZMO describió la incorporación de datos de Flock, grabaciones de cámaras corporales y otras pruebas a su Intelligence Hub para realizar búsquedas y análisis. El director ejecutivo de la empresa declaró a los periodistas que no había utilizado reconocimiento facial en grabaciones de Flock ni había creado la herramienta de exportación específica necesaria para el flujo de trabajo propuesto.

    Flock afirma que sus cámaras no utilizan reconocimiento facial y que su sistema de matrículas busca características de los vehículos en lugar de identidades. Por tanto, el análisis biométrico propuesto se realizaría posteriormente en el entorno de otro proveedor, no dentro de las cámaras Flock ni en el propio proceso de reconocimiento de Flock.

    Los límites de gobernanza de los datos deben mantenerse tras la exportación

    Los organismos que evalúen integraciones de vídeo deben definir los análisis permitidos, la retención, el registro de auditoría y los requisitos de aprobación antes de trasladar pruebas entre plataformas. Los controles de contratación deben abordar tanto el procesamiento posterior como las capacidades del sistema de cámaras original. SectechMedia sigue los avances relacionados en su cobertura de videovigilancia y tecnologías de imagen.

    Fuentes

  • El Reino Unido abre las pruebas del registro de servicios de verificación digital legible por máquina

    El Reino Unido abre las pruebas del registro de servicios de verificación digital legible por máquina

    La Office for Digital Identities and Attributes del Reino Unido ha invitado a los proveedores de servicios de verificación digital a ayudar a probar una infraestructura que hará legible por máquina el registro gubernamental de servicios aprobados. La iniciativa pretende que empresas y autoridades públicas puedan comprobar el estado de registro de forma segura y a escala, en lugar de depender únicamente de consultas manuales.

    Las pruebas abarcan dos modelos técnicos

    OfDIA describió un modelo de API para conexiones directas e intercambio seguro de datos, junto con un modelo de credenciales que permitiría a un servicio presentar pruebas verificables desde una cartera digital. La oficina prevé probar la incorporación de proveedores en octubre de 2026 y entrevistar a los participantes sobre su preparación para las pruebas de integración.

    El Gobierno también ha publicado material técnico de integración. OfDIA afirmó que las pruebas de ambos modelos continuarán más adelante este año; el anuncio es una invitación a participar, no una declaración de que la integración en producción esté completa.

    Las comprobaciones automatizadas de confianza necesitan pruebas controladas

    Los registros legibles por máquina pueden reducir la verificación manual, pero las organizaciones usuarias aún necesitan control de versiones, supervisión de disponibilidad y una respuesta auditable cuando cambia el estado de un proveedor. Los equipos de identidad deben tratar los datos del registro como un control dentro de un proceso de garantía más amplio. SectechMedia sigue los avances relacionados en su cobertura de control de acceso e identidad.

    Fuentes

  • OpenID Foundation anuncia las primeras implementaciones certificadas de OpenID4VP y OpenID4VCI

    OpenID Foundation anuncia las primeras implementaciones certificadas de OpenID4VP y OpenID4VCI

    OpenID Foundation ha anunciado las primeras organizaciones que autocertificaron implementaciones de OpenID for Verifiable Presentations y OpenID for Verifiable Credential Issuance con el High Assurance Interoperability Profile. Este hito proporciona a los proveedores de carteras, emisores y verificadores un registro público de conformidad para protocolos cada vez más utilizados en programas de identidad digital.

    La certificación abarca varias funciones del ecosistema

    OpenID4VCI define cómo se emiten las credenciales verificables, mientras que OpenID4VP permite presentar afirmaciones seleccionadas a un verificador. El perfil HAIP reduce las opciones de implementación para una interoperabilidad de mayor garantía. La Fundación indicó que las primeras implementaciones superaron sus pruebas de conformidad, con resultados disponibles en un registro público.

    Las certificaciones iniciales abarcan las funciones de cartera, emisor y verificador en múltiples proveedores. Informaciones independientes señalaron que las especificaciones ya se están adoptando en iniciativas nacionales y regionales de identidad digital, lo que aumenta la necesidad de pruebas repetibles en lugar de demostraciones bilaterales puntuales.

    La conformidad no sustituye la garantía del despliegue

    Los compradores deben verificar qué función del protocolo, perfil y versión del software cubre un certificado. Los programas de producción siguen necesitando revisión de la privacidad, gestión de claves, controles del ciclo de vida y pruebas en toda la cadena de credenciales. SectechMedia sigue los avances relacionados en su cobertura de control de acceso e identidad.

    Fuentes

  • 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

  • El Departamento de Justicia de EE. UU. selecciona la plataforma ROC para pruebas digitales y analítica de vídeo

    El Departamento de Justicia de EE. UU. selecciona la plataforma ROC para pruebas digitales y analítica de vídeo

    El Departamento de Justicia de EE. UU. ha seleccionado tecnología de ROC para respaldar una plataforma de revisión de pruebas digitales utilizada en investigaciones penales federales, según un informe de Biometric Update del 28 de septiembre. El contrato combina la ingesta y revisión de pruebas con reconocimiento facial y otras capacidades de analítica de vídeo.

    La plataforma está destinada a pruebas digitales de distintos tipos

    El alcance comunicado incluye material de descubrimiento electrónico procedente de fuentes como dispositivos móviles y cuentas de redes sociales. ROC es responsable de desarrollar y dar soporte a la plataforma utilizada para ingerir, revisar y analizar esa información. La empresa describe la adjudicación como un contrato base de un año seguido de prórrogas anuales opcionales.

    Biometric Update informó de un valor base garantizado de $7 millones y de un posible valor de $64.3 millones si se ejercen todas las opciones. Esos años opcionales no constituyen gasto garantizado y no deben tratarse como el valor actual del contrato.

    Los flujos de trabajo de pruebas requieren más que software de reconocimiento

    Los grandes sistemas de investigación necesitan controles de acceso, registros de auditoría, normas de conservación, supervisión del rendimiento de los modelos y exportaciones reproducibles de las pruebas. El reconocimiento facial puede reducir las cargas de trabajo de revisión, pero los resultados de candidatos requieren una evaluación humana cualificada y una gestión documentada, no conclusiones automáticas sobre la identidad.

    Los equipos de compras también deben probar los límites de calidad de imagen, el rendimiento demográfico, la gestión de falsos positivos y los controles de cadena de custodia antes de la aceptación operativa. La adjudicación se sitúa en la intersección de videovigilancia e imagen y la informática forense, donde la analítica debe preservar tanto la integridad probatoria como la velocidad de búsqueda.

    Fuentes

  • Legisladores estadounidenses vuelven a presentar un proyecto de ley de moratoria federal sobre vigilancia biométrica

    Legisladores estadounidenses vuelven a presentar un proyecto de ley de moratoria federal sobre vigilancia biométrica

    Legisladores estadounidenses han vuelto a presentar una iniciativa destinada a restringir el uso federal del reconocimiento facial y otras tecnologías de vigilancia biométrica. El senador Edward Markey anunció el proyecto de ley junto con el senador Jeff Merkley y las representantes Pramila Jayapal, Rashida Tlaib y Ayanna Pressley el 25 de septiembre.

    La propuesta abarca múltiples modalidades biométricas

    Según los patrocinadores y Biometric Update, la propuesta impediría que las agencias federales utilizaran o adquirieran sistemas de reconocimiento facial, reconocimiento de voz y otros sistemas de vigilancia biométrica sin autorización explícita del Congreso. También aborda el acceso a datos biométricos en poder de entidades estatales, locales y privadas.

    La medida recupera una propuesta de moratoria anterior con un lenguaje más amplio. Sus partidarios sostienen que el uso federal debe suspenderse hasta que el Congreso establezca normas aplicables sobre derechos civiles, debido proceso, transparencia y supervisión. El proyecto es una propuesta y no una ley vigente, y sus disposiciones siguen sujetas al proceso legislativo.

    Los equipos de compras afrontan una incertidumbre normativa persistente

    Los programas de seguridad del sector público deben distinguir entre capacidad técnica y autoridad legal. Las agencias que consideren despliegues biométricos necesitan una finalidad documentada, normas de conservación de datos, pruebas de rendimiento, revisión humana y un proceso de apelación, mientras que los proveedores deben evitar presentar los resultados de pruebas piloto como garantías universales de precisión.

    El debate también afecta a la interoperabilidad y a la planificación del ciclo de vida, porque las restricciones pueden influir en qué bases de datos, cámaras y servicios de identidad pueden conectarse. SectechMedia sigue estas cuestiones dentro de control de acceso e identidad, donde la gobernanza de la privacidad y el rendimiento operativo deben evaluarse conjuntamente.

    Fuentes

  • Nvidia lanza una plataforma de seguridad para agentes de IA con un supervisor basado en hardware

    Nvidia lanza una plataforma de seguridad para agentes de IA con un supervisor basado en hardware

    Nvidia ha anunciado Open Agent Safety Platform, una combinación de controles de ejecución de código abierto y un diseño de sistema de referencia destinado a mantener a los agentes autónomos de IA dentro de límites operativos definidos. La plataforma separa la aplicación de políticas del propio agente y está diseñada para utilizarse desde las pruebas hasta el despliegue en producción.

    OpenShell aplica políticas en tiempo de ejecución fuera del agente

    El componente de software, OpenShell, coloca a los agentes en entornos aislados gestionados y dirige las solicitudes salientes a través de un supervisor. Las políticas pueden restringir la actividad de archivos, procesos, redes y API. Los agentes pueden proponer cambios en las políticas, pero no pueden aprobar sus propias solicitudes. Las credenciales reales de API se sustituyen fuera de la carga de trabajo del agente solo para destinos autorizados.

    Nvidia también describe Sentry, un supervisor opcional que se ejecuta en unidades de procesamiento de datos BlueField-4. Como el monitor funciona por separado del host, puede observar la actividad y aplicar las políticas incluso si el entorno del host se ve comprometido. Nvidia afirma que el diseño puede poner en cuarentena a un agente que rebase sus límites.

    La aplicación independiente mejora la auditabilidad

    Las organizaciones que evalúen plataformas de agentes deben probar el comportamiento de cierre seguro ante fallos, el aislamiento de credenciales, la aprobación de cambios de políticas y la integridad de los registros de auditoría. La separación mediante hardware puede aportar resiliencia, pero no sustituye el principio de mínimo privilegio ni la validación en el nivel de la aplicación. SectechMedia sigue estas cuestiones en su cobertura sobre ciberseguridad.

    Fuentes

  • El IRS estudia el triaje con IA para un atasco de robo de identidad cercano a 257,000 casos

    El IRS estudia el triaje con IA para un atasco de robo de identidad cercano a 257,000 casos

    El Servicio de Impuestos Internos de Estados Unidos está estudiando si la inteligencia artificial podría ayudar a evaluar la complejidad de los casos de robo de identidad y derivarlos a empleados con la formación adecuada. La propuesta aparece en la respuesta de la agencia a una auditoría del Inspector General del Tesoro para la Administración Tributaria; el informe no afirma que ya se haya implantado un sistema de triaje con IA.

    La mayor parte de la demora se produce antes de la asignación

    La auditoría determinó que las víctimas de robo de identidad esperaron una media de aproximadamente 20 meses para obtener una resolución durante los ejercicios fiscales de 2023 a 2025, frente al objetivo de 120 días de la agencia. Los casos de la muestra de la auditoría pasaron la mayor parte de ese tiempo en el inventario sin asignar. La carga de trabajo pendiente había descendido desde niveles anteriores, pero todavía se situaba cerca de 257,000 casos en mayo de 2026.

    TIGTA recomendó evaluar la complejidad de los casos antes de asignarlos y trasladar las reclamaciones al procesamiento activo con mayor rapidez. El IRS aceptó estudiar si la IA podría respaldar ese trabajo en lugar de desviar a personal experimentado en robo de identidad para examinar los casos entrantes.

    La automatización necesita salvaguardas auditables

    Cualquier modelo de triaje utilizado para casos de fraude de identidad necesitaría criterios de derivación documentados, revisión humana, pruebas de sesgo y una vía de recurso para las reclamaciones clasificadas erróneamente. El rendimiento debería medirse en función del tiempo de resolución y las tasas de error, no solo del volumen procesado. SectechMedia sigue controles relacionados en su cobertura sobre identidad y acceso.

    Fuentes

  • 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

  • NIST finaliza su guía para proteger la identidad en línea y los tokens de acceso

    NIST finaliza su guía para proteger la identidad en línea y los tokens de acceso

    NIST ha finalizado una guía de implementación para proteger los tokens de identidad y acceso en línea frente al robo, la falsificación y el uso indebido. Los tokens permiten que aplicaciones y servicios reconozcan a usuarios autenticados sin solicitar repetidamente sus credenciales, pero un token robado o falsificado puede permitir que un atacante suplante una cuenta legítima y eluda los controles normales de inicio de sesión.

    La guía utiliza una implementación de referencia en la nube

    La publicación describe una arquitectura de confianza cero construida con tecnologías comerciales y de código abierto. Abarca el descubrimiento, la visibilidad, la validación y la aplicación de políticas sobre tokens en proveedores de identidad, aplicaciones y servicios en la nube. NIST desarrolló la guía práctica con CISA y colaboradores del sector a través del National Cybersecurity Center of Excellence.

    El material final subraya que la protección de tokens no se limita a un solo producto. Las organizaciones necesitan telemetría coordinada y aplicación de políticas en los sistemas que emiten, reciben y validan tokens.

    Las operaciones deben probar la revocación y la detección del uso indebido

    Los equipos de identidad deben inventariar los tipos de tokens, documentar las relaciones de confianza, reducir su duración innecesaria y confirmar que la revocación funciona durante un incidente. La supervisión debe identificar emisiones inusuales, reutilización y uso desde dispositivos o ubicaciones inesperados. Estos controles complementan la autenticación resistente al phishing, pero no la sustituyen. SectechMedia sigue novedades relacionadas en su cobertura de identidad y control de acceso.

    Fuentes