Autor: Osiris

  • Una investigación detecta exposición de datos en más de 16,000 bases de datos de Supabase

    Una investigación detecta exposición de datos en más de 16,000 bases de datos de Supabase

    Investigadores de UpGuard afirman haber identificado más de 16,000 bases de datos de Supabase con tablas de lectura pública que exponían información personal, contraseñas, tokens de autenticación u otros datos de aplicaciones. Los hallazgos apuntan a fallos de configuración recurrentes en proyectos creados sobre la popular plataforma backend, y no a una única brecha de Supabase.

    Las claves del lado del cliente pueden dejar al descubierto controles de acceso débiles

    Las aplicaciones de Supabase suelen incluir una clave anónima pública para que los navegadores y clientes móviles puedan acceder a los datos autorizados. La seguridad depende de que las políticas de seguridad a nivel de fila y los permisos de la base de datos limiten lo que esa clave puede recuperar. La investigación encontró aplicaciones en las que esos controles no existían o estaban incompletos, lo que permitía que consultas no autenticadas devolvieran registros sensibles.

    UpGuard vinculó la magnitud de la exposición, en parte, al rápido desarrollo de aplicaciones y a la programación asistida por IA, en los que los equipos pueden desplegar un backend funcional antes de validar las reglas de autorización. Las aplicaciones afectadas abarcaban múltiples sectores y tipos de datos, por lo que el riesgo debe evaluarse proyecto por proyecto.

    Las pruebas deben adoptar la perspectiva de un atacante externo

    Los desarrolladores deben inventariar los proyectos de Supabase, habilitar la seguridad a nivel de fila y probar cada tabla expuesta con las mismas credenciales anónimas distribuidas a los clientes. Los secretos nunca deben almacenarse en tablas de aplicaciones legibles, y los tokens expuestos deben revocarse en lugar de limitarse a ocultarlos. SectechMedia sigue los riesgos de la nube y las aplicaciones en su cobertura de ciberseguridad.

    Fuentes

  • Un solo paquete malformado puede bloquear servidores de bases de datos industriales TDengine

    Un solo paquete malformado puede bloquear servidores de bases de datos industriales TDengine

    Investigadores de seguridad han revelado una vulnerabilidad previa a la autenticación en TDengine que puede permitir a un atacante no autenticado bloquear la base de datos de series temporales con un solo paquete malformado. El problema, identificado como CVE-2026-42542, es relevante para entornos industriales, energéticos, de IoT, automatización de edificios y vehículos conectados que dependen de telemetría continua.

    La vulnerabilidad afecta a una capa de datos operativos

    Ridge Security afirma que la debilidad se produce mientras el servidor procesa datos de red antes de la autenticación. Un paquete especialmente diseñado puede desencadenar una condición de desbordamiento inferior de enteros y finalizar el proceso de la base de datos. Incluso sin robo de datos ni ejecución de código, los bloqueos repetidos pueden interrumpir paneles de control, alarmas, análisis y otros servicios que dependen de datos actuales de series temporales.

    Las bases de datos industriales suelen tratarse como infraestructura interna, pero las rutas de acceso remoto, las redes planas y los servicios de administración expuestos pueden hacer que sean accesibles desde zonas menos confiables. La pérdida de disponibilidad también puede obstaculizar a los operadores durante otro incidente físico o cibernético.

    La segmentación y las pruebas de recuperación son importantes

    Los propietarios de activos deben identificar los despliegues de TDengine, revisar las directrices de corrección del proveedor y restringir los puertos de la base de datos a los sistemas necesarios. La supervisión debe alertar sobre la finalización repetida de procesos y los paquetes anómalos, mientras que los ejercicios de recuperación deben verificar que las aplicaciones dependientes se reconecten de forma segura. SectechMedia aborda controles relacionados en su cobertura de seguridad de OT y ciberfísica.

    Fuentes

  • Microsoft detalla el malware NeedyMantis utilizado para mantener acceso prolongado a redes

    Microsoft detalla el malware NeedyMantis utilizado para mantener acceso prolongado a redes

    Microsoft Threat Intelligence ha documentado una familia de malware posterior al compromiso denominada NeedyMantis que los atacantes han utilizado para conservar acceso prolongado dentro de organizaciones seleccionadas. La actividad ha afectado a un pequeño número de proveedores de telecomunicaciones, universidades, organizaciones médicas sin ánimo de lucro, organismos intergubernamentales y contratistas gubernamentales.

    El malware permite actividades modulares posteriores

    Microsoft afirma que NeedyMantis se observa al menos desde 2023 y se despliega después de que un atacante ya haya obtenido acceso. Sus componentes pueden recopilar información del sistema, ejecutar comandos y mantener comunicaciones que respaldan objetivos posteriores. Esa función convierte al malware en una herramienta de persistencia y acceso operativo, en lugar del vector de intrusión inicial.

    Los objetivos reportados abarcan sectores con datos valiosos de comunicaciones, investigación y políticas. Por tanto, los defensores deben investigar cómo se produjo el compromiso inicial y, al mismo tiempo, buscar los artefactos del malware, las credenciales relacionadas y el movimiento lateral en el entorno.

    La eliminación exige más que borrar una carga maliciosa

    Los equipos de respuesta a incidentes deben delimitar las identidades, tareas programadas, servicios y rutas de administración remota afectados, y después rotar las credenciales desde un sistema cuya integridad esté confirmada. La telemetría histórica de terminales y redes puede ayudar a establecer el tiempo de permanencia e identificar sistemas que ya no muestran un implante activo. SectechMedia sigue las medidas de defensa relacionadas en su cobertura de ciberseguridad.

    Fuentes

  • Apple corrige una vulnerabilidad de día cero en CoreGraphics utilizada en ataques dirigidos

    Apple corrige una vulnerabilidad de día cero en CoreGraphics utilizada en ataques dirigidos

    Apple ha publicado actualizaciones de seguridad para versiones anteriores del software de iPhone, iPad y Mac con el fin de corregir una vulnerabilidad de CoreGraphics que, según la empresa, podría haberse explotado en un ataque extremadamente sofisticado contra personas concretas. El problema está identificado como CVE-2026-86950 y afecta al código de procesamiento de imágenes utilizado en las plataformas de Apple.

    Un archivo manipulado podría provocar la ejecución de código

    Apple describe la vulnerabilidad como una escritura fuera de límites en CoreGraphics. El procesamiento de un archivo creado de forma maliciosa podría permitir la ejecución de código arbitrario. La empresa atribuyó el reporte del problema a los investigadores de Google Threat Analysis Group Benoît Sevens y Clément Lecigne, un detalle coherente con la advertencia de que la explotación fue dirigida y no ampliamente oportunista.

    Las correcciones se publicaron para iOS y iPadOS 26.7.1 y para versiones compatibles de macOS, incluidas Tahoe 26.7.1 y Sequoia 15.8.1. Las organizaciones deben verificar la compatibilidad de los dispositivos y el estado de despliegue, en lugar de asumir que los terminales administrados más antiguos recibieron una actualización automáticamente.

    Los analizadores de imágenes siguen siendo un límite de alto riesgo

    Los equipos de seguridad deben priorizar las actualizaciones para los usuarios expuestos a documentos no confiables, archivos adjuntos de mensajería y contenido web. Los informes de gestión de dispositivos móviles y terminales deben revisarse para detectar fallos de instalación y hardware no compatible. SectechMedia realiza un seguimiento de los riesgos relacionados con la aplicación de parches y los terminales en su cobertura de seguridad ciberfísica.

    Fuentes

  • Pruebas de aceptación de clasificación de eventos DAS y control de deriva del modelo

    Pruebas de aceptación de clasificación de eventos DAS y control de deriva del modelo

    La detección acústica distribuida puede monitorizar rutas largas de fibra, pero la aceptación debe evaluar algo más que si el interrogador detecta vibraciones. El sistema debe distinguir las clases de eventos acordadas, localizarlas de forma útil y seguir siendo manejable a medida que cambia el entorno.

    Definir las clases de eventos y las pruebas

    Enumere los eventos que se espera que el sistema identifique, como alteraciones de vallas, excavaciones, movimiento de vehículos o actividad cerca de una tubería. Defina cada clase en términos operativos e indique qué eventos requieren una alarma, una investigación o solo un registro.

    Acuerde los métodos de prueba, los tramos de la ruta, las repeticiones y las métricas de aceptación antes de realizar las pruebas. Evite adoptar una demostración genérica del proveedor como requisito del emplazamiento. El suelo, el acoplamiento del cable, la construcción de la valla y la actividad de fondo afectan considerablemente a la señal.

    Crear un conjunto de pruebas representativo

    Genere eventos a distintas distancias de la fibra y en varios puntos de la ruta. Incluya ejemplos fuertes y débiles, ubicaciones limítrofes y actividad de fondo simultánea. Registre las condiciones meteorológicas, la hora, las condiciones operativas y el personal o los equipos utilizados.

    Recopile fuentes de molestias como trabajos de mantenimiento, tráfico, animales y movimientos provocados por las condiciones meteorológicas. Un clasificador que funciona bien únicamente en condiciones tranquilas no ha demostrado su preparación operativa.

    Medir por separado la detección y la clasificación

    Registre si el sistema detectó un evento, cómo lo clasificó, la ubicación comunicada y el tiempo hasta la alarma. Un evento detectado con una clase incorrecta puede desencadenar una respuesta equivocada; un evento correctamente clasificado pero mal localizado puede seguir haciendo perder tiempo al operador.

    Revise la confusión entre clases en lugar de basarse en una única cifra de precisión combinada. Confirme cómo se presentan los resultados de baja confianza y si los operadores pueden examinar las trazas de apoyo.

    Controlar los cambios de modelo y umbral

    Realice una copia de seguridad de la configuración aceptada, la versión del modelo y los supuestos de entrenamiento. Cualquier reentrenamiento o cambio de umbral debe probarse frente a un conjunto fijo de regresión antes del despliegue. Siga la evolución de las alarmas molestas y los eventos omitidos a lo largo de las estaciones.

    Este control del ciclo de vida forma parte de la gobernanza de detección por fibra óptica. Es especialmente importante después de trabajos en la ruta, reparaciones de cables, cambios en la vegetación o la instalación de nueva maquinaria cercana.

    Supervisar la deriva

    Compare las distribuciones de alarmas en directo con la línea base de aceptación e investigue los cambios sostenidos por ubicación, clase o confianza. Mantenga estructurados los comentarios de los operadores; el reetiquetado improvisado puede contaminar futuros datos de entrenamiento. Repita periódicamente los eventos de campo controlados y documente si el rendimiento se mantiene dentro del intervalo aprobado. Cuando no sea así, trate el reentrenamiento como un cambio de ingeniería controlado, con reversión y revisión independiente.

    Definir la revisión operativa y la reversión

    Especifique quién puede aprobar cambios de modelo o umbral y qué pruebas se requieren. Conserve el modelo y la configuración anteriores para poder restaurar el sistema si aumentan las alarmas molestas o las detecciones omitidas después del despliegue.

    Revise los comentarios de campo por tramo de la ruta, clase de evento y confianza, en lugar de hacerlo como un único total para todo el emplazamiento. Confirme que los operadores reciban clasificaciones comprensibles y trazas de apoyo. Un informe del ciclo de vida debe diferenciar el estado del sensor, el rendimiento de detección, el rendimiento de clasificación y el flujo de trabajo de respuesta.

    Fuentes de referencia

  • Validación del mapa de clutter de radares perimetrales y nueva puesta en servicio estacional

    Validación del mapa de clutter de radares perimetrales y nueva puesta en servicio estacional

    El radar perimetral aprende o utiliza un mapa de reflejos estacionarios para poder distinguir los objetivos en movimiento de edificios, vallas y terreno. Las obras, la vegetación y las condiciones estacionales pueden hacer que ese mapa sea inexacto incluso cuando el sensor sigue en línea.

    Registrar el modelo de cobertura aceptado

    Conserve la ubicación, la altura y la orientación del radar, la versión del software, los sectores de alcance y las zonas de exclusión. Mantenga un plano del emplazamiento con los objetos reflectantes importantes y el límite de detección aprobado. Registre las clases de objetivos, velocidades y secciones transversales utilizadas durante la aceptación.

    Documente las áreas donde la geometría limita el rendimiento. Una zona ciega detrás de un edificio debe tratarse como una limitación de diseño con cobertura compensatoria, no ocultarse mediante una afirmación general de rendimiento.

    Revisar el clutter y los cambios ambientales

    Compare la escena actual con el mapa aceptado. Las nuevas estructuras metálicas, la maquinaria estacionada, las vallas, las grúas y la vegetación en crecimiento pueden modificar los reflejos. La lluvia, el agua estancada y la nieve también pueden alterar el comportamiento del fondo o las trayectorias de los objetivos.

    Examine las alarmas molestas por ubicación y condiciones meteorológicas. Una agrupación repetida puede identificar una rama en movimiento, un elemento de drenaje o una instalación mecánica. La corrección física puede resultar más fiable que reducir la sensibilidad en todo un sector.

    Realizar pruebas de trayectorias controladas

    Desplace personas y vehículos representativos por las zonas de cobertura cercana, intermedia y lejana en distintas direcciones y a diferentes velocidades. Cruce los límites de los sectores y acérquese siguiendo trayectorias radiales y tangenciales. Registre el tiempo de detección, la continuidad de la trayectoria, la clasificación y el error de ubicación.

    Incluya varios objetivos cuando sea necesario. Confirme que las trayectorias no se fusionen ni intercambien identidades cerca del clutter y que las zonas de exclusión no creen un corredor sin probar.

    Verificar la transferencia y el encaminamiento de alarmas

    Compruebe la orientación de las cámaras, la precisión de las posiciones preestablecidas y la presentación en la sala de control para cada ruta de prueba. Mida el tiempo transcurrido desde la detección por radar hasta disponer de un contexto visual útil. Confirme que las coordenadas del mapa, la sincronización horaria y la orientación del emplazamiento sigan alineadas entre los sistemas.

    Las pruebas de radar deben integrarse en un aseguramiento más amplio de intrusión y seguridad perimetral, en lugar de terminar en la consola del sensor.

    Gobernar la reasignación del mapa

    Realice una copia de seguridad de la configuración actual antes de generar o editar un mapa de clutter. Compare el rendimiento de detección antes y después del cambio y conserve una copia de reversión. Vuelva a poner el sistema en servicio después de obras, reubicaciones del sensor, trabajos importantes en la vegetación, cambios de software o alarmas repetidas relacionadas con las condiciones meteorológicas. El registro final debe indicar tanto el rendimiento relativo a las alarmas molestas como los resultados aprobados de detección de objetivos.

    Revisar el rendimiento con el personal de operaciones

    Incluya a los operadores de la sala de control en la revisión, porque las trayectorias repetidas de escaso valor pueden generar carga de trabajo incluso cuando la detección técnica se mantiene dentro de las especificaciones. Compare los resultados de reconocimiento, clasificación y despacho con el registro del sensor.

    Mantenga un registro por zonas de las limitaciones conocidas, las cámaras compensatorias y los ajustes estacionales. Si la reasignación del mapa mejora una ruta pero debilita otra, el cambio no ha superado la aceptación. Exija una nueva prueba presenciada y conserve las trayectorias sin procesar o las grabaciones de pantalla para futuras comparaciones.

    Revise el mapa aceptado con los equipos de mantenimiento y registre quién es responsable de cada obstrucción física o condición ambiental recurrente.

    Fuentes de referencia

  • Geometría de zonas de analítica de vídeo y nueva puesta en servicio de cámaras

    Geometría de zonas de analítica de vídeo y nueva puesta en servicio de cámaras

    La analítica de vídeo puede seguir indicando un servicio correcto después de que una cámara se haya movido lo suficiente como para invalidar sus zonas de detección. La nueva puesta en servicio debe verificar la geometría de la escena, el tamaño del objetivo, la oclusión y el encaminamiento de eventos siempre que cambien la vista o el entorno.

    Conservar la vista aceptada

    Conserve una imagen de referencia que muestre el campo de visión aprobado, el horizonte, los puntos de referencia y los límites de las zonas. Registre los ajustes del objetivo, la altura de montaje, el ángulo de la cámara, la resolución, la frecuencia de fotogramas y la versión de la analítica. Estos valores permiten a un técnico distinguir un cambio de escena de un cambio de algoritmo.

    Utilice la detección de manipulación como alerta, no como único control. Los pequeños desplazamientos, los cambios de zoom o los ajustes de enfoque pueden quedar por debajo de un umbral de manipulación y, aun así, modificar de forma sustancial los píxeles del objetivo.

    Reconstruir la geometría a partir de la escena

    Confirme que las líneas de calibración, los mapas de perspectiva y las zonas de exclusión coinciden con las características físicas actuales. Recorra las partes cercana, intermedia y lejana de cada zona siguiendo trayectorias representativas de los objetivos. Verifique que la analítica mantiene el tamaño de objeto y la confianza de clasificación requeridos.

    Compruebe las entradas, las esquinas y los límites de zona donde una trayectoria puede aparecer tarde o desaparecer antes de tiempo. La vegetación, los vehículos estacionados y las estructuras nuevas pueden crear oclusiones que no existían durante la aceptación.

    Probar escenarios operativos

    Realice pruebas aprobadas de intrusión, merodeo, dirección y cruce de línea a distintas velocidades y ángulos. Incluya más de una persona o vehículo cuando se espere que el sistema separe los objetivos. Pruebe las transiciones de luz diurna, poca luz e iluminación de la escena.

    Registre tanto los eventos omitidos como las alarmas molestas. Un cambio de ajuste que suprima las sombras pero también omita una aproximación lenta no constituye una mejora aceptable.

    Verificar la cadena de eventos

    Confirme que cada detección aceptada llega al sistema de gestión de vídeo y al flujo de trabajo de la sala de control con la cámara, la zona, la marca de tiempo y el clip correctos. Mida la latencia de aviso y visualización. Si la cámara activa iluminación, audio u otro sensor, verifique esas acciones sin suponer que una alarma de analítica local demuestra el éxito de la integración.

    La nueva puesta en servicio debe seguir formando parte del plan de mantenimiento general de videovigilancia e imagen, con una responsabilidad clara sobre los cambios de escena.

    Controlar y revisar los cambios

    Almacene capturas de pantalla anteriores y posteriores, exportaciones de ajustes, rutas de prueba y resultados. Exija aprobación para reducciones importantes de sensibilidad o de zonas y conserve una copia de reversión. Repita una prueba representativa después de actualizaciones de firmware, modelo, VMS o red, y programe comprobaciones periódicas para las cámaras expuestas a vibraciones, obras o vegetación estacional.

    Medir la estabilidad posterior al cambio

    Observe la cámara durante periodos de funcionamiento representativos después de la nueva puesta en servicio. Compare el volumen de alarmas, la combinación de clasificaciones y las decisiones de los operadores con la línea base aceptada. Una breve prueba de recorrido no puede revelar todas las sombras en movimiento, reflejos de faros u obstrucciones recurrentes.

    Asigne las zonas ciegas y las fuentes de molestias no resueltas a responsables identificados. Cuando no pueda corregirse la geometría, documente la cobertura compensatoria y sus limitaciones. Cierre el registro de nueva puesta en servicio únicamente después de superar tanto las pruebas de detección controladas como un periodo de observación definido.

    Documente el campo de visión final y la fecha de prueba aprobada.

    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

  • Validación de referencias de cámaras térmicas y pruebas de deriva de medición

    Validación de referencias de cámaras térmicas y pruebas de deriva de medición

    Una cámara térmica puede producir una imagen estable mientras las temperaturas que comunica se alejan gradualmente de la referencia aceptada. Por tanto, la puesta en servicio y el mantenimiento deben comprobar la cadena de medición completa, en lugar de evaluar únicamente la calidad de imagen.

    Definir la tarea de medición prevista

    Comience documentando si la cámara se utiliza para la detección relativa de puntos calientes, alarmas de umbral o medición trazable de temperatura. Son tareas diferentes. Un sistema destinado únicamente a destacar objetos más calientes puede no necesitar el mismo procedimiento de referencia que una alarma de protección de procesos.

    Registre el modelo de cámara, el objetivo, la distancia de montaje, el campo de visión, el firmware, el intervalo de medición y las reglas de alarma. Conserve los ajustes aprobados de emisividad, temperatura reflejada y condiciones atmosféricas. Un parámetro modificado puede alterar las lecturas sin que se produzca ningún cambio físico en el objetivo.

    Utilizar una referencia controlada

    Coloque una referencia de temperatura adecuada en la escena y permita que se estabilice. La referencia debe abarcar las temperaturas importantes para la aplicación y ocupar suficientes píxeles para obtener una medición repetible. Compare el resultado de la cámara con el valor de referencia en varios puntos, en lugar de depender de un único umbral.

    Cuando se requiera trazabilidad formal, utilice equipos calibrados y conserve su certificado, incertidumbre y fecha de vencimiento. Un objeto caliente conveniente resulta útil para una comprobación funcional, pero no es una referencia de calibración.

    Controlar las variables ambientales

    Mida la temperatura ambiente, el ángulo de visión, la distancia y cualquier ventana o cerramiento protector situado entre la cámara y el objetivo. El polvo, la humedad, la carga solar y los reflejos pueden alterar la temperatura aparente. Verifique que los ajustes automáticos de ganancia o mejora de imagen no afecten al canal de medición radiométrica.

    Repita las pruebas después de que el cerramiento alcance la temperatura de funcionamiento y en condiciones diurnas y nocturnas representativas. En sistemas exteriores, incluya extremos estacionales y compruebe si los reflejos del entorno desplazan el punto de alarma.

    Analizar la deriva y el rendimiento de las alarmas

    Registre el error de referencia, la ubicación en la imagen, el tiempo de respuesta de la alarma y los límites de aprobación. Analice la evolución de los resultados entre las visitas de mantenimiento para que la deriva gradual sea visible antes de provocar alarmas omitidas o molestas. Cuando el error supere la tolerancia aprobada, investigue los ajustes y el entorno antes de aplicar compensaciones de software.

    Después de una intervención o sustitución, repita la secuencia completa de alarmas, el registro de eventos y la notificación a la sala de control. El aseguramiento de las cámaras térmicas forma parte de una gobernanza más amplia de videovigilancia e imagen, con registros independientes para la calidad de imagen y el rendimiento térmico.

    Mantener la reproducibilidad de la prueba

    Almacene los planos de colocación de las referencias, las capturas de pantalla de las cámaras, las lecturas sin procesar, las observaciones meteorológicas y los identificadores de los instrumentos. Indique si el resultado corresponde a una verificación de campo o a una calibración formal. Esta distinción evita que los equipos futuros atribuyan a la medición una confianza mayor de la que respaldan las pruebas.

    Clasificar y cerrar las desviaciones

    Separe los errores de configuración, la incertidumbre de la referencia, los efectos ambientales y la posible deriva del sensor. Asigne el trabajo correctivo al responsable correspondiente y repita los mismos puntos de referencia después de la intervención. No cierre una desviación únicamente porque se haya ampliado un umbral de alarma.

    Revise los errores recurrentes en cámaras y ubicaciones similares. Una desviación común puede indicar un problema compartido de cerramiento, firmware o puesta en servicio. Mantenga los límites de aceptación vinculados al riesgo operativo para que los equipos de mantenimiento sepan cuándo una cámara puede seguir en servicio y cuándo debe retirarse para su evaluación en laboratorio.

    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