Categoría: Seguridad ciberfísica

Seguridad ciberfísica

  • 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 estudio comparativo de OT de Honeywell revela que la visibilidad de activos va por detrás de la confianza en la seguridad

    El estudio comparativo de OT de Honeywell revela que la visibilidad de activos va por detrás de la confianza en la seguridad

    Una encuesta comparativa de Honeywell ha detectado una brecha entre la confianza de las organizaciones industriales en sus programas de ciberseguridad de tecnología operacional y los registros de activos y controles de monitorización que afirman tener implantados. Security Today publicó las conclusiones el 28 de septiembre.

    Los inventarios completos siguen siendo poco habituales

    El informe encuestó a más de 600 responsables de riesgo de ciberseguridad, cumplimiento u operaciones en los sectores de la energía, el petróleo y el gas, la sanidad, el transporte marítimo y la fabricación. Security Today informó de que el 88% describió sus programas como maduros, mientras que el 21% afirmó mantener registros completos de activos OT.

    Solo un tercio de las organizaciones encuestadas informó de una integración completa de OT con centros de operaciones de seguridad centralizados. La supervisión continua de cámaras, sensores y otros dispositivos IoT conectados era menos habitual, lo que ilustra cómo la tecnología física y operacional puede quedar fuera de la monitorización empresarial.

    La confianza debe contrastarse con pruebas

    La madurez autoevaluada solo resulta útil cuando está respaldada por inventarios actualizados, una responsabilidad documentada, visibilidad de red y procedimientos de incidentes probados. Las estaciones de trabajo de ingeniería desconocidas, los enlaces remotos no gestionados y los controladores sin soporte pueden menoscabar la segmentación y la respuesta incluso cuando los marcos de gobernanza parecen completos.

    Los operadores pueden comenzar conciliando los datos de descubrimiento con los registros de activos aprobados, asignando un responsable de negocio a cada dispositivo y registrando las dependencias de software, soporte y recuperación. El estudio refuerza un tema recurrente en seguridad ciberfísica: la resiliencia depende de saber qué sistemas existen, cómo se comunican y qué consecuencias operativas se producen cuando fallan.

    Fuentes

  • El FBI y la CISA advierten a los operadores de infraestructuras críticas sobre el acceso de integradores de ICS

    El FBI y la CISA advierten a los operadores de infraestructuras críticas sobre el acceso de integradores de ICS

    El FBI y la Agencia de Seguridad de Infraestructuras y Ciberseguridad emitieron el 23 de septiembre directrices sobre los riesgos de ciberseguridad que surgen cuando integradores externos de sistemas de control industrial obtienen acceso a entornos de infraestructuras críticas. Las agencias instaron a los operadores a tratar las conexiones de los integradores como vías de acceso reguladas y supervisadas, en lugar de como enlaces de confianza permanentes.

    Una brecha en un proveedor expuso información de clientes

    Según las directrices resumidas por Security Today, una brecha ocurrida en 2025 en un proveedor estadounidense de automatización industrial afectó a una organización que prestaba servicio a clientes de los sectores eléctrico y del transporte. Actores extranjeros buscaron en la red del proveedor material de clientes y de control supervisor y adquisición de datos, y después colocaron cientos de elementos en archivos comprimidos.

    El episodio ilustra cómo una intrusión en una empresa de ingeniería o soporte puede dar visibilidad sobre múltiples operadores. Los planos, la información de dispositivos y los datos SCADA de los clientes pueden ayudar a los atacantes a comprender los entornos industriales incluso cuando todavía no han llegado a una red operativa.

    El acceso debe ser limitado y observable

    Las agencias recomendaron limitar a cada integrador al acceso necesario para su trabajo, grabar las sesiones remotas y documentar la tecnología suministrada. Los contratos deben definir las obligaciones de ciberseguridad, mientras que los operadores deben mantener copias sin conexión del software necesario para operar los equipos y prepararse para una posible indisponibilidad del proveedor.

    Las organizaciones también deben revisar las cuentas inactivas, las credenciales compartidas, las pasarelas de acceso remoto y las vías de soporte una vez finalizados los proyectos. Estos controles alinean la gobernanza de proveedores con la segmentación técnica y la resiliencia operativa. La advertencia es especialmente pertinente para los lectores de SectechMedia responsables de seguridad y monitorización industrial, donde el acceso de mantenimiento puede cruzar la frontera entre los sistemas empresariales y los procesos esenciales.

    Fuentes

  • La botnet Carbonato despliega un agente de IA controlado por Telegram en hosts Docker expuestos

    La botnet Carbonato despliega un agente de IA controlado por Telegram en hosts Docker expuestos

    Investigadores de ThreatDown han documentado una botnet llamada Carbonato que ataca demonios Docker expuestos sin autenticación y despliega un marco de agentes de IA de código abierto para realizar actividades controladas por sus operadores. La investigación se publicó por primera vez el 22 de septiembre, y el 28 de septiembre aparecieron informes técnicos adicionales.

    Las API de Docker expuestas proporcionan el punto de entrada

    La operación busca servicios Docker accesibles en el puerto 2375 sin autenticación. Tras encontrar uno, el malware inicia un contenedor con privilegios, monta el sistema de archivos del host y utiliza el contenedor para ejecutar comandos en el host subyacente. A continuación, establece persistencia y analiza las redes cercanas en busca de más demonios expuestos.

    ThreatDown rastreó la infraestructura a través de un registro sin autenticación que exponía repositorios, etiquetas de imágenes y datos de configuración. Los investigadores afirmaron que el mismo entorno respaldaba una operación independiente relacionada con aplicaciones troyanizadas de monederos de criptomonedas.

    Hermes Agent se convierte en la interfaz del operador

    Carbonato instala Hermes Agent sin modificar el propio marco y después sustituye su archivo de personalidad por instrucciones que priorizan la persistencia, la ejecución de comandos y la recopilación de credenciales. Los operadores envían tareas mediante Telegram, mientras el agente se conecta a una pasarela de modelos y convierte esas instrucciones en actividad de terminal.

    La investigación pone de relieve un fallo práctico de seguridad en la nube, no una vulnerabilidad nueva de Docker: las API administrativas no deben exponerse directamente sin autenticación. Las organizaciones pueden reducir el riesgo restringiendo el acceso a los demonios, autenticando los registros, revisando los contenedores con privilegios y supervisando la persistencia inesperada. El incidente añade otro ejemplo a la cobertura de SectechMedia sobre seguridad ciberfísica, a medida que las herramientas de IA pasan a formar parte de cadenas de ataque reales.

    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

  • Una agencia sanitaria de DC afirma que datos ocultos en informes expusieron casi 400,000 registros de beneficiarios

    Una agencia sanitaria de DC afirma que datos ocultos en informes expusieron casi 400,000 registros de beneficiarios

    El Departamento de Financiación de la Atención Sanitaria del Distrito de Columbia está notificando a casi 400,000 beneficiarios de Medicaid y DC Healthcare Alliance tras descubrir que dos informes de su sitio web público contenían información personal oculta. El incidente no se describió como una intrusión en la red; la exposición procedía de datos subyacentes de los informes a los que usuarios no autorizados podían acceder potencialmente.

    Los informes resumidos contenían registros de respaldo accesibles

    Los informes estaban destinados a mostrar los totales de afiliación y otras estadísticas agregadas. DHCF afirmó que las páginas visibles no mostraban datos personales, pero que la información de respaldo podría haber estado accesible entre 2023 y julio de 2026. La población afectada incluye a los beneficiarios inscritos durante ese periodo.

    Los campos expuestos variaban según el registro e incluían identificadores de Medicaid y otra información personal. DHCF retiró los informes, investigó el problema y comenzó a notificar a las personas afectadas. El aviso de la agencia ofrece información actualizada y datos sobre asistencia.

    Los flujos de publicación necesitan pruebas de datos ocultos

    Las organizaciones que publiquen paneles, hojas de cálculo o informes generados deben inspeccionar los archivos fuente, los conjuntos de datos integrados, los metadatos y los puntos finales de exportación antes de su publicación. Las pruebas de acceso deben verificar qué puede recuperar un usuario no autenticado, no solo lo que muestra la página. SectechMedia sigue controles relacionados en su cobertura sobre ciberseguridad.

    Fuentes

  • Un exsoldado de Estados Unidos, condenado a 70 meses por una trama de piratería y extorsión

    Un exsoldado de Estados Unidos, condenado a 70 meses por una trama de piratería y extorsión

    Un exsoldado del Ejército de Estados Unidos ha sido condenado a 70 meses de prisión por participar en una trama de piratería y extorsión dirigida contra al menos diez empresas tecnológicas y de telecomunicaciones de Estados Unidos. El Departamento de Justicia de Estados Unidos afirmó que Cameron John Wagenius y sus cómplices robaron credenciales, accedieron a sistemas corporativos y amenazaron con publicar o vender los datos robados.

    El acceso robado facilitó la extorsión y el fraude

    Según los expedientes judiciales, el grupo utilizó credenciales obtenidas de las redes de las víctimas y se coordinó a través de canales en línea. Los fiscales afirmaron que los conspiradores intentaron extorsionar al menos $1 millón a los propietarios de los datos, anunciaron información robada en foros de ciberdelincuencia y utilizaron algunos registros para cometer otros fraudes, incluido el intercambio de SIM.

    Wagenius se había declarado anteriormente culpable de cargos que incluían conspiración para cometer fraude electrónico, robo de identidad agravado y extorsión relacionada con fraude informático. La sentencia también incluyó $294,978 en concepto de restitución. El caso abarca conductas comprendidas entre abril de 2023 y diciembre de 2024.

    El acceso a las telecomunicaciones exige controles por capas

    Los proveedores de telecomunicaciones deben aplicar una autenticación resistente al phishing, aislar las interfaces administrativas, supervisar la reutilización de credenciales y exigir una aprobación independiente para los cambios sensibles en las cuentas. Las pruebas de los incidentes deben vincular los registros de acceso, las consultas de registros de clientes y las comunicaciones de extorsión. SectechMedia sigue estos controles en su cobertura sobre ciberseguridad.

    Fuentes

  • Un jurado de Nuevo México declara a Facebook responsable de engañar a los usuarios sobre la protección de la privacidad

    Un jurado de Nuevo México declara a Facebook responsable de engañar a los usuarios sobre la protección de la privacidad

    Un jurado de Nuevo México ha declarado a Facebook responsable de engañar a los usuarios sobre la protección de la privacidad conforme a la ley estatal de protección del consumidor. El veredicto se produjo tras un juicio de dos semanas centrado en declaraciones sobre las salvaguardas de los datos de los usuarios y la supervisión de las aplicaciones de terceros por parte de la empresa. El juez determinará las sanciones por separado.

    El veredicto abarca más de 43 millones de infracciones

    El Departamento de Justicia de Nuevo México afirmó que los miembros del jurado constataron más de 43 millones de infracciones. El estado argumentó que Facebook tergiversó las protecciones de los datos recopilados mediante aplicaciones de terceros, incluidas conductas asociadas al escándalo de Cambridge Analytica. El jurado también determinó que la empresa engañó al público sobre las revisiones de desarrolladores externos que accedían a información de los usuarios.

    Meta cuestionó el veredicto y afirmó que seguiría defendiendo su historial en materia de privacidad. El jurado no aceptó todas las acusaciones del estado, y la consecuencia económica definitiva sigue sin resolverse hasta la fase de determinación de la sanción. Por tanto, la información publicada debe distinguir la declaración de responsabilidad de cualquier futura indemnización.

    Las afirmaciones sobre privacidad necesitan controles verificables

    Las plataformas digitales deben poder demostrar cómo se revisa el acceso de terceros, cómo se detectan las infracciones y cómo se corresponden las declaraciones públicas sobre privacidad con los controles operativos. Las pruebas de auditoría deben abarcar los flujos de datos, los permisos de los desarrolladores y la corrección de deficiencias. SectechMedia sigue cuestiones relacionadas en su cobertura sobre ciberseguridad.

    Fuentes

  • Atacantes de JADEPUFFER usaron principales de servicio comprometidos para eliminar recursos de Azure

    Atacantes de JADEPUFFER usaron principales de servicio comprometidos para eliminar recursos de Azure

    Microsoft ha documentado una intrusión destructiva en Azure vinculada al actor de amenazas que identifica como Storm-3168, también conocido como JADEPUFFER. Los atacantes utilizaron dos principales de servicio comprometidos dentro de un inquilino para enumerar recursos, recopilar credenciales e intentar eliminar servicios en la nube. Microsoft afirmó que la actividad tuvo lugar a principios de junio de 2026 y se desarrolló durante aproximadamente 18 horas.

    Las identidades en la nube permitieron amplias acciones destructivas

    Un principal de servicio realizó un reconocimiento prolongado, mientras que otro llevó a cabo más de 150 operaciones destructivas o relacionadas con credenciales en unos 35 minutos. Entre los objetivos se encontraban cuentas de almacenamiento, máquinas virtuales, Key Vault, Function Apps, App Services y bases de datos de Azure SQL. La mayoría de las cuentas de almacenamiento atacadas fueron eliminadas, mientras que los bloqueos de recursos y la protección contra eliminación impidieron algunos intentos.

    Microsoft descubrió que las credenciales de uno de los principales de servicio habían quedado expuestas anteriormente en una incidencia pública de GitHub. Aunque el secreto se eliminó posteriormente, seguía visible en el historial de la incidencia. La empresa evaluó la operación como vinculada al ransomware, pero no informó de ninguna nota de rescate ni de exfiltración de datos confirmada.

    Los controles de recuperación independientes limitaron los daños

    Las organizaciones deben rotar los secretos de aplicaciones expuestos, restringir los privilegios de los principales de servicio y generar alertas ante una enumeración o eliminación inusual de recursos. Las salvaguardas de recuperación deben ser administrativamente independientes de las identidades que gestionan los recursos de producción. SectechMedia sigue riesgos relacionados en su cobertura sobre ciberseguridad.

    Fuentes

  • Las API de notificación de archivos pueden filtrar la actividad del usuario en Windows, Linux y Android

    Las API de notificación de archivos pueden filtrar la actividad del usuario en Windows, Linux y Android

    Investigadores de la Universidad Tecnológica de Graz han demostrado que las funciones de notificación de archivos de los sistemas operativos pueden actuar como canales laterales para la actividad de usuarios y aplicaciones. Los mecanismos están diseñados para avisar al software cuando cambian los archivos, pero la información sobre el momento de los eventos y las rutas puede revelar comportamientos incluso cuando un atacante no puede leer el contenido de los archivos.

    La exposición varía según el sistema operativo

    Las demostraciones incluyeron la temporización de pulsaciones de teclas y la identificación de sitios web en Linux, la visibilidad de rutas entre usuarios en Windows y eventos multimedia de WhatsApp en Android. La mayoría de los escenarios requieren que un atacante ejecute código localmente, a menudo con otra cuenta; la prueba en Android utilizó una aplicación que no solicitaba permisos. El trabajo no demuestra por sí mismo un compromiso remoto, y los investigadores afirmaron no tener conocimiento de explotación en entornos reales.

    Linux ha reforzado parcialmente los eventos de archivos de dispositivo asociados a una de las vías más graves. Microsoft indicó a los investigadores que el comportamiento de Windows es intencionado y subrayó que expone rutas, no el contenido de los archivos. El proyecto no indica una solución general para varios de los demás escenarios.

    El aislamiento local sigue siendo importante

    Los administradores deben limitar el código local no fiable, separar las cargas de trabajo sensibles y supervisar el uso inusual de las API de vigilancia de archivos cuando haya telemetría disponible. Los desarrolladores de aplicaciones deben reducir al mínimo la información sensible en los nombres de archivos y las rutas temporales. SectechMedia sigue los riesgos para los terminales en su cobertura sobre ciberseguridad.

    Fuentes