Los equipos de seguridad nunca han tenido mayor visibilidad de sus entornos y nunca ha sido más difícil garantizar que lo que reparan permanezca fijo.
El informe M-Trends 2026 de Mandiant estima que el tiempo promedio de uso es de -7 días. Verizon 2025 DBIR afirma que el tiempo medio para solucionar las vulnerabilidades en los dispositivos perimetrales es de 32 días. Es comprensible que estas cifras hayan llevado a la industria a una respuesta clara: priorizar mejor y parchear más rápidamente. Necesito ese consejo. También está incompleto. Porque cuando aplicas un parche, la cuestión de cómo puedes estar seguro de que funcionó todavía no recibe suficiente atención.
Los mitos no cambiaron el problema. La velocidad y facilidad de explotación ha cambiado.
Las discusiones sobre el impacto de la IA se centran en la velocidad. El desarrollo de exploits se está volviendo más barato, más rápido y menos dependiente de la habilidad humana de élite.
En el caso de la restauración, esto cambia lo que está en juego. Muchas correcciones se marcan como «reparadas» cuando lo que realmente sucedió fue un parche del proveedor que resultó ser evitable o una solución alternativa que dependía del comportamiento específico del atacante. Antes eran una apuesta bastante segura. Ya no existen. El problema ya no es la velocidad de reparación. La pregunta es: ¿la corrección realmente eliminó la exposición o simplemente movió el ticket a «completado»?
El parche es perfecto pero aún vulnerable.
No todas las exposiciones se pueden parchear. Por ejemplo, unas reglas de firewall débiles pueden dejar puertas abiertas. Se descubrió que las reglas políticas habían sido reescritas y aplicadas. ¿Pero lo fue? Se mostrará una confirmación una vez que se haya aplicado el parche. Si se establecen permisos o se configuran políticas EDR o configuraciones SIEM, las pruebas deben garantizar que sean válidas.
Costuras de tejido que desaparecen después de unas semanas.
Incluso con hallazgos validados de alta señal, los retrasos desde la identificación hasta la remediación son principalmente organizativos. Descubres riesgos. No eres propietario de las modificaciones. El equipo que realmente lo posee opera en diferentes cronogramas con diferentes prioridades. Debido a que los hallazgos no se integran en las acciones que la ingeniería puede tomar, la señal se pierde una vez más.
En entornos híbridos y nativos de la nube, la propiedad se vuelve más confusa. Las vulnerabilidades pueden existir en la capa de aplicación, la capa de infraestructura o dependencias de terceros. Y cuando un problema llega a alguna parte, la solución se ejecuta a través de cualquier proceso que los equipos ya estén usando, cambiando las ventanas de TI y DevOps y acelerando los esfuerzos de ingeniería. Sus resultados de seguridad entrarán en conflicto con lo que ya está en su agenda y, por lo general, perderá. Los atacantes impulsados por IA no están esperando la siguiente ventana de cambio o el próximo sprint.
Requiere integración y automatización. Eso no es suficiente.
Existen soluciones prácticas para la resistencia operativa. Consolide los hallazgos relacionados para que varios problemas verificados rastreados hasta el mismo balanceador de carga mal configurado se conviertan en un único ticket con un único propietario. Automatice el enrutamiento, la asignación, el cumplimiento de SLA y las rutas de escalamiento. Obtenga flujos de trabajo de hojas de cálculo y mensajes de Slack.
Sin embargo, el rendimiento y la velocidad indican qué tan rápido está funcionando el sistema, no si está funcionando. Puede enrutar tickets consolidados a propietarios verificados en minutos, hacer cumplir SLA, escalar según un cronograma y cerrar tickets que no puedan verse comprometidos. Quizás la solución alternativa no se aplicó después del cambio de configuración, o quizás la solución se aplicó a tres de los cuatro sistemas afectados, o quizás el parche se aplicó exitosamente pero la mala configuración circundante permaneció.
El ticket está marcado como «solucionado». La vía del ataque sigue abierta. Como ha demostrado Mythos, cuando la IA es capaz de derivar y volver a derivar de forma autónoma cadenas de exploits, la falsa confianza se convierte en la parte más costosa de un programa de seguridad.
El reexamen es la disciplina que falta
La revalidación debería significar que el riesgo ya no existe. Volver a realizar la prueba sólo verifica que el ataque original no existe. Se debe verificar que el riesgo en sí no existe.
Una vez que se vuelven a probar todas las correcciones y los resultados son visibles para los líderes de seguridad e ingeniería, las correcciones parciales y las soluciones alternativas se marcan inmediatamente en lugar de permanecer en el panel. Cree un circuito de retroalimentación que haga que todo el sistema se autocorrija.
Flujo de trabajo de remediación que permanece como está: los resultados validados se integran en las acciones de remediación, se envían a los propietarios confirmados, se realiza un seguimiento hasta el cierre y luego se revalidan para garantizar que el riesgo subyacente, así como el vector de ataque original, desaparezca. La plataforma de Pentera está diseñada para ese modelo operativo, conectando flujos de trabajo de remediación y validación posterior a la corrección para permitir a los equipos medir si el riesgo realmente se elimina.
Tres preguntas que separan al sistema de la esperanza
¿Cuál es el tiempo medio que lleva arreglar un descubrimiento explotable validado? Si no puede responder esto, está midiendo la actividad, no los resultados. Si se aplica una solución, ¿cómo sabes que funcionó? Si la respuesta es «El ingeniero cerró el ticket», pregúntese cuántos de los resultados fijos sobrevivirán a la nueva prueba. ¿Estás midiendo si los tickets están cerrados o los riesgos están cerrados? El rendimiento de los tickets muestra que su equipo está ocupado. No es que la exposición haya desaparecido. Integrar los hallazgos en el riesgo subyacente y rastrear si ese riesgo realmente desaparece mejorará su programa.
Las organizaciones que hagan esto bien dejarán de tratar la remediación como algo que sucede después de que se realiza el trabajo de seguridad y comenzarán a tratarla como si fuera el lugar donde realmente se mide el trabajo de seguridad.
Nota: Este artículo fue escrito y contribuido profesionalmente por Nimrod Zantkern Lavi, director de producto de Pentera.
Source link
