Hay una pregunta que casi ninguna organización puede responder con seguridad: si un atacante entrara hoy a la red, ¿cuánto tiempo pasaría antes de que alguien lo notara? La mayoría asume que sería rápido. La evidencia dice lo contrario. En la práctica, el tiempo entre la intrusión inicial y su detección —lo que la industria llama dwell time— suele medirse en días o semanas, no en minutos [DATO A VALIDAR].
Ese intervalo es, en muchos sentidos, la variable más importante de todo incidente de seguridad. No importa tanto cómo entró el atacante; importa cuánto tiempo tuvo para moverse dentro de la red sin que nadie interviniera. Un ataque detectado en minutos es un incidente. El mismo ataque, sin detectar durante semanas, es una crisis.
Por qué el tiempo importa más que la brecha inicial
Cuando se habla de ciberataques, la atención suele concentrarse en el punto de entrada: el correo de phishing, la credencial filtrada, la vulnerabilidad sin parchar. Pero el punto de entrada rara vez es lo que causa el daño mayor. El daño se construye después, durante el tiempo que el atacante pasa dentro de la red sin ser detectado: explorando la infraestructura, identificando sistemas críticos, escalando privilegios, moviéndose lateralmente hacia la información que realmente busca.
Cada día adicional de dwell time es, literalmente, tiempo de trabajo gratuito para el atacante. Mientras más largo sea ese periodo, más profundo puede llegar, más difícil es reconstruir qué tocó y qué no, y más caro resulta el proceso de contención y remediación. La brecha inicial define cómo empezó el problema; el dwell time define qué tan grande se hizo.
Por qué es tan difícil detectar a un atacante que ya está dentro
La razón por la que el dwell time tiende a ser tan largo no es negligencia: es que un atacante que ya está dentro de la red no se comporta como una alarma que suena. Se comporta, en la mayoría de los casos, como tráfico legítimo. Usa credenciales válidas, se mueve por rutas de red normales, y evita generar el tipo de actividad evidente que dispararía una alerta tradicional basada en firmas conocidas.
Esto expone una limitación estructural de los modelos de seguridad que dependen únicamente de reglas predefinidas o de la revisión manual de logs por parte de un analista. Un ser humano, por más experimentado que sea, no puede revisar en tiempo real el volumen de tráfico que genera una organización mediana. Y una regla escrita para detectar "lo conocido" no sirve de mucho frente a un comportamiento que nunca se había visto antes, pero que igual es anómalo dentro del contexto específico de esa red.
De la detección reactiva a la detección por comportamiento
El cambio de fondo que ha ido ocurriendo en la industria es pasar de una lógica de "¿esto coincide con una amenaza conocida?" a una lógica de "¿esto es normal para esta red en particular?". La primera pregunta depende de que alguien más ya haya visto y catalogado esa amenaza antes. La segunda no depende de eso: se construye entendiendo cómo se comporta habitualmente cada organización, para poder notar cuando algo se desvía, aunque nunca antes se haya documentado como un ataque.
Esa desviación —un usuario que de pronto accede a sistemas que nunca toca, un volumen de tráfico inusual hacia un destino que no tiene historial, un patrón de acceso fuera de horario habitual— es exactamente el tipo de señal que permite acortar el dwell time de semanas a horas. No porque se haya identificado un ataque específico, sino porque se identificó que algo dejó de comportarse como siempre se comportó.
Reducir el dwell time es una decisión de negocio, no solo técnica
Para un CISO, un CIO o un CFO, el dwell time no debería verse como una métrica técnica más. Es, en la práctica, uno de los factores que más determina el costo final de un incidente: cuánto tiempo de operación se pierde, cuántos sistemas hay que revisar, cuánta confianza hay que reconstruir con clientes y reguladores. Reducir ese intervalo no es un lujo de madurez de seguridad; es una de las inversiones con mayor retorno directo sobre el impacto de negocio de cualquier ataque futuro.
En la práctica
Este es precisamente el problema que TBSEK está diseñado para resolver dentro de su operación de detección y respuesta. Como parte de cómo TBSEK opera la ciberseguridad de sus clientes, integra Darktrace para construir un entendimiento continuo del comportamiento normal de cada red específica —no un catálogo genérico de amenazas conocidas, sino un perfil propio de cómo se mueve el tráfico, los usuarios y los sistemas de esa organización en particular. Cuando algo se desvía de ese comportamiento habitual, la señal aparece de inmediato, incluso si se trata de una técnica que nunca se había visto antes en ningún otro cliente. Esto le permite al equipo de TBSEK acortar drásticamente el tiempo entre que ocurre una intrusión y el momento en que se detecta y se actúa, en lugar de depender de que la amenaza coincida con un patrón ya documentado. Para las organizaciones que opera TBSEK, esto se traduce en un cambio concreto: el dwell time deja de medirse en semanas y pasa a medirse en el tiempo que le toma a la operación de TBSEK identificar y contener una desviación real, reduciendo tanto el alcance del daño como el costo de recuperación asociado a cada incidente.
