ESTRATEGIA · DETECCIÓN Y RESPUESTA · DECISIONES TI
En TechCorp Latam, el ransomware llevaba operando dentro de la red varios días antes de que el equipo de TI lo detectara. No porque nadie estuviera prestando atención: porque no existía ningún proceso activo diseñado para detectar ese tipo de actividad. Los logs estaban, en algunos sistemas. Nadie los revisaba con criterio de seguridad. Las alertas no existían. El descubrimiento del incidente no fue el resultado de una detección: fue el resultado de que los sistemas ya no funcionaban.
Esa es la situación de una fracción significativa de las organizaciones medianas de la región: tienen infraestructura, tienen logs en alguna forma, y no tienen detección. La diferencia entre esas dos cosas es exactamente el tema de esta semana.
LA ILUSIÓN DE TENER LOGS
Casi toda organización con infraestructura de red genera logs. Los firewalls Fortinet, Cisco, WatchGuard generan registros de tráfico. Los sistemas operativos generan logs de eventos. Las aplicaciones generan logs de acceso. En entornos cloud como el que quedó en TechCorp Latam post-incidente, Azure genera logs de actividad sobre cada recurso.
Esa disponibilidad de logs crea la impresión de que la organización tiene visibilidad sobre lo que ocurre en su entorno. Y esa impresión es parcialmente correcta: los datos están. El problema es que datos sin análisis no son detección. Son un archivo. Un atacante que opera durante días o semanas en un entorno con logs pero sin análisis activo es un atacante que opera con plena impunidad técnica, sabiendo que nadie está mirando los datos que registran sus movimientos.
La detección requiere tres cosas que los logs solos no proveen: correlación (conectar eventos de distintas fuentes para identificar patrones), criterio (saber qué patrones son normales y cuáles son anómalos para este entorno específico), y proceso de respuesta (qué hace alguien cuando un patrón anómalo aparece).
EL PROBLEMA DEL TIEMPO
El tiempo entre que un incidente ocurre y que la organización lo detecta es la métrica que más directamente determina el impacto del incidente. Cada día que un atacante opera dentro de la red sin ser detectado es un día en que puede moverse lateralmente, escalar privilegios, exfiltrar datos, o preparar el despliegue del payload final. El daño de un ransomware que se detecta en 4 horas es cualitativamente distinto al daño de uno que se detecta en 21 días.
Los reportes de la industria muestran tiempos promedio de detección que en organizaciones sin programas de detección activa superan las dos o tres semanas. Para organizaciones medianas sin equipo de seguridad dedicado, ese número puede ser mayor. Y el descubrimiento frecuentemente no ocurre por detección interna: ocurre porque un tercero notifica, porque el impacto ya es visible para los usuarios, o porque el atacante decidió activar la fase final del ataque.
Ese tiempo de exposición no solo determina el alcance del daño técnico. Determina el alcance de la investigación forense posterior, que necesita cubrir todo el período en que el atacante estuvo presente. Determina la posible exposición de datos durante ese período. Y determina el costo de la remediación, que crece con cada día adicional de compromiso.
LA TRAMPA DE LA ALERTA SIN PROCESO
El otro extremo del espectro es igualmente problemático: organizaciones que implementan herramientas de detección sin el proceso de respuesta que hace que esas herramientas sean útiles. El FortiAnalyzer con cientos de alertas diarias sin nadie que las revise con criterio no es detección: es ruido. Un SIEM que genera 500 alertas por día y donde el equipo no tiene capacidad de triagear más de 20 no está produciendo detección: está produciendo fatiga de alertas.
La fatiga de alertas es tan peligrosa como la ausencia de alertas porque produce el mismo resultado práctico: las alertas se ignoran. La diferencia es que con la fatiga de alertas la organización cree que tiene detección porque tiene una herramienta que genera alertas. Esa creencia falsa puede ser más peligrosa que saber que no se tiene detección, porque reduce la urgencia de resolver el problema.
LO QUE ESTA SEMANA ANALIZO
El martes voy a ver qué capacidades mínimas de detección son alcanzables para una organización mediana sin un SOC dedicado: qué herramientas nativas de la infraestructura Fortinet, Cisco y de entornos Azure pueden usarse sin inversión adicional significativa. El miércoles, cómo construir un proceso de respuesta básico que funcione con el equipo que ya existe. El jueves, el caso TechCorp Latam: cuándo se detectó realmente el ransomware, qué lo habría detectado antes, y qué capacidades de detección se implementaron post-incidente. El viernes, cómo presentar la inversión en detección a una gerencia que lo percibe como gasto y no como reducción de riesgo medible.
DECISIÓN QUE DEBE TOMAR EL CIO
¿Cuánto tiempo tardaría la organización en detectar que hay un atacante activo en su red hoy? Si la respuesta honesta es "no lo sabemos" o "cuando algo dejara de funcionar", ese es el diagnóstico de partida. La semana comienza con esa pregunta porque su respuesta define si el programa de detección es una prioridad o una aspiración.
Tener logs no es tener detección. Tener alertas no es tener respuesta. La diferencia entre esas condiciones no es tecnológica: es de proceso y de decisión sobre qué se hace cuando el sistema genera una señal. Esta semana analizo cómo construir esa capacidad con lo que una organización mediana tiene disponible.
Esta semana en el blog: cinco días analizando detección y respuesta como decisión organizacional. Mañana: capacidades mínimas de detección sin SOC dedicado.
#DetecciónDeIncidentes #IncidentResponse #Ciberseguridad #CIO #ITManager #GestiónDeRiesgos #Fortinet #Cisco #WatchGuard #Azure #TechCorpLatam #CyberLeadership #Liderazgo #Chile #NISTCSF #ISO27001 #SOC
Comentarios
Publicar un comentario