Saber contra qué protege tu detección, técnica por técnica

Una red de unidades de salud había cambiado su solución de endpoint por una bien evaluada en el mercado y mantenía un equipo tercerizado monitoreando alertas. La pregunta que la dirección clínica hacía era simple y nunca se respondía: si apareciera un secuestro de datos como los que se anuncian en el sector, la empresa se daría cuenta antes o después de que las historias clínicas se detuvieran.

Recortamos las técnicas más asociadas a grupos con historial de ataque a prestadores de salud y medimos la cobertura de cada una en el ambiente real, ejecutando cada comportamiento de forma controlada y verificando qué mostraba el tablero después. Nada se aceptó por constar en documentación del proveedor.

Ejecución de código y persistencia aparecieron bien cubiertas, que era lo esperado de una buena herramienta de endpoint. Acceso a credenciales y movimiento lateral entre servidores pasaron casi enteros sin alerta, porque el registro de autenticación de los servidores nunca se había enviado a ningún lado. La corrección más valiosa del proyecto fue encender una fuente de log que ya existía.

Después de un incidente contenido a las apuradas, la empresa tenía dos informes del mismo evento: uno escrito por la seguridad corporativa, en vocabulario de alerta y firma, y otro escrito por automatización, en vocabulario de proceso y parada. Las dos versiones no se encontraban, y la discusión sobre qué invertir se trabó durante meses.

Reescribimos la línea de tiempo del incidente una sola vez, con cada paso amarrado a una técnica, usando la matriz corporativa para el tramo de oficina y la matriz industrial para el tramo de automatización. Donde la evidencia no sostenía un paso, registramos la brecha como brecha en lugar de rellenarla con una hipótesis.

La narrativa única mostró que el paso entre los dos ambientes había ocurrido por una estación de ingeniería con acceso a los dos lados, y que ninguno de los dos equipos la monitoreaba, cada uno considerándola responsabilidad del otro. La decisión de inversión salió en la reunión siguiente, y el modelo de informe se volvió estándar para los incidentes posteriores.

La institución contrataba prueba de intrusión todos los años y recibía siempre el mismo formato: una lista de hallazgos con nota de severidad. El área de tecnología corregía los ítems críticos, los medios rodaban de un año al otro, y el rectorado nunca entendió por qué aquello importaba, porque ningún ítem aislado parecía grave.

Condujimos la prueba siguiente con cada paso mapeado a una técnica, desde el primer acceso hasta el objetivo acordado, y registramos, paso a paso, qué vio la detección, qué solo guardó en log y qué ignoró por completo. El informe pasó a tener un camino, con los puntos en que podría haber sido interrumpido.

El camino hasta la base académica pasaba por tres hallazgos de severidad media que venían siendo postergados desde hacía dos ciclos. Puestos en secuencia, dejaron de ser ítems de lista y se volvieron un guion, y el rectorado aprobó la corrección de los tres en la misma semana en que leyó el informe.