Qué activos propios la tienen

Pasar de un CVE publicado a un activo propio en riesgo exige tres comprobaciones, en este orden: si tienes el producto, si la versión está en el rango afectado que declara el boletín del fabricante y si el servicio es alcanzable desde fuera. La tercera es la que más pesa cuando el informe habla de campañas contra servicios expuestos: un servidor afectado pero aislado en una red interna espera su turno; uno afectado y expuesto está en la línea de fuego.

Lo mismo con las versiones: estar fuera del rango (por ejemplo, una rama anterior que el boletín no cubre) no es lo mismo que estar corregido.

El boletín de Nodolab declara afectadas las versiones de la 5.0.0 a la 5.2.0, ambas incluidas, y la 5.2.1 como corregida; la rama 4.x no está afectada. El inventario de Santa Rita tiene varios activos con el producto. Para decidir dónde se concentra el riesgo hay que contar solo los que reúnen las dos condiciones a la vez: versión dentro del rango y exposición a internet.

El inventario viene de la gestión de activos; el informe de hallazgos viene del escáner. No son la misma lista. Un activo que consta en el inventario y que el escáner nunca ha visto es una brecha de visibilidad: un informe construido solo con el escáner lo omitiría y el riesgo se subestimaría. La inteligencia obliga a cruzar las dos listas porque un adversario no distingue entre lo que el escáner cubre y lo que no.

El informe del CSIRT trae indicadores para buscar en los registros propios: una dirección de origen y un patrón de petición. Se usan en una sola dirección: se miran los registros que ya existen para ver si esa actividad ya pasó por la casa. No se hace ninguna conexión hacia esas direcciones ni se prueba nada contra ellas.

Una petición rechazada (403) y una atendida (200) significan cosas distintas: la primera es un intento que el servidor frenó; la segunda es una respuesta real.

El servidor msr-transfer-01 atendió peticiones del indicador el 25 de septiembre, con una salida de 412 MB, y sigue en la versión 5.1.4: el parche de la versión 5.2.1 estaba disponible desde el 14 de septiembre. Aplicar el parche cierra el fallo hacia adelante, pero no dice nada de lo que ya ocurrió. El catálogo KEV tiene un campo que lo refleja, forensicTriage, que pide comprobar si hubo un compromiso previo además de arreglar el fallo.