Casos reales que un ASM habría evitado

La superficie de ataque es el conjunto de todos los puntos por los que un adversario puede intentar entrar en una organización: dominios, subdominios, direcciones IP, puertos abiertos, aplicaciones, API, credenciales filtradas y servicios de terceros que operan en su nombre. La superficie cambia cada semana, y casi siempre crece sin que nadie registre el cambio.

En el escenario digital de hoy, su empresa es como un castillo. Pero, a diferencia de un castillo medieval con una única puerta y un foso, la empresa moderna tiene miles de puntos de entrada. Cada nuevo servicio en la nube, cada notebook de un empleado en home office, cada API conectada a un socio e incluso aquel servidor de pruebas olvidado en el rincón de una subred es una puerta o ventana en potencia.

¿El problema? No se puede proteger lo que no se sabe que existe.

Aquí es donde entra uno de los conceptos más críticos de la ciberseguridad moderna: Attack Surface Management (ASM), o Gestión de la Superficie de Ataque.

La definición formal es clara: el Attack Surface Management (ASM) es el proceso continuo de descubrir, analizar, monitorear y remediar los vectores de ataque de una organización.

Pero ¿qué significa esto en la práctica? Significa adoptar la visión de un atacante para encontrar y cerrar sus propias brechas antes de que ellos lo hagan.

Superficie de ataque y ASM: qué es cada cosa

Antes de gestionar, necesitamos entender qué es la "superficie de ataque".

Superficie de Ataque (Attack Surface): es la suma de todos los puntos de entrada potenciales donde un atacante puede intentar extraer datos u obtener acceso no autorizado a un sistema.

Esto incluye diversos tipos de activos que muchas veces pasan inadvertidos para los equipos de seguridad. Los activos conocidos son aquellos que están en el radar de TI: sus sitios web corporativos, servidores de correo electrónico, VPNs y aplicaciones expuestas al público. Estos son relativamente fáciles de monitorear porque forman parte del inventario oficial de la organización.

Sin embargo, el verdadero peligro muchas veces reside en los activos desconocidos, también llamados Shadow IT. Imagine aquel servidor que el equipo de marketing levantó en AWS para un proyecto temporal y olvidó apagar después de que terminó la campaña. O el subdominio de una prueba antigua que sigue en línea, ejecutando una versión desactualizada de software con vulnerabilidades conocidas. Estos activos "fantasma" son objetivos preferidos de los atacantes porque con frecuencia no reciben parches de seguridad ni monitoreo adecuado.

Están también los activos de terceros, que su organización usa pero no controla: código de socios, APIs externas, bibliotecas de código abierto como Log4j. Cada uno es un vector de ataque en potencia. Cuando aparece una vulnerabilidad crítica en una de esas dependencias, la pregunta que importa es dónde está corriendo en su infraestructura, y hay que responderla el mismo día.

Por último, tenemos las exposiciones de datos, que pueden no ser activos técnicos tradicionales, pero representan riesgos significativos. Credenciales filtradas en sitios de paste, buckets de almacenamiento en la nube mal configurados que cualquiera puede acceder, bases de datos abiertas a internet sin autenticación: todos estos son puntos de entrada que los atacantes buscan activamente.

La Gestión (ASM) es el proceso activo de mapear, analizar y reducir esa superficie. Funciona como un ciclo continuo, en cuatro etapas.

La primera etapa es Descubrir. Aquí, herramientas automatizadas escanean continuamente internet de la misma forma en que lo haría un atacante para encontrar todos los activos conectados a su organización, sean conocidos o no. Este no es un proceso puntual, sino un rastreo continuo que identifica nuevos activos apenas aparecen en línea. La plataforma de ASM actúa como un hacker ético, buscando dominios, subdominios, direcciones IP, certificados SSL y cualquier otro rastro digital que conduzca de vuelta a su organización.

La segunda etapa es Analizar y Priorizar. No basta con simplemente encontrar activos; es necesario entender el riesgo que cada uno representa. Un servidor web que ejecuta una aplicación crítica de negocio con una vulnerabilidad crítica conocida (CVE) es infinitamente más peligroso que un blog estático desactualizado. El ASM clasifica los activos descubiertos, identifica vulnerabilidades a través de scanners automatizados y bases de datos de CVE, y luego prioriza lo que debe corregirse primero basándose en múltiples factores: criticidad de la vulnerabilidad, exposición del activo, valor de los datos que procesa y si hay exploits activos circulando.

La tercera etapa es Monitorear. La superficie de ataque no es estática; cambia diariamente, a veces cada hora. Se abren nuevos puertos para pruebas y se olvidan abiertos. Se aplican parches en algunos servidores pero no en otros. Se crean nuevos subdominios para proyectos temporales. Los certificados SSL expiran. El ASM monitorea esos cambios en tiempo real, alertando inmediatamente cuando algo cambia de una forma que pueda introducir riesgo. Es como tener un vigía 24/7 observando cada alteración en su presencia digital.

La cuarta y última etapa es Remediar. Este es el objetivo final de todo el proceso. Un informe bonito no corrige nada. Las plataformas que sirven se integran directo con el sistema de tickets (Jira, ServiceNow) y con las herramientas de gestión de vulnerabilidades, para que la falla de mayor riesgo salga de la lista y entre en la cola de alguien, con nombre y plazo. La remediación se rastrea, se mide y se reporta, creando un ciclo de mejora continua.

Por qué el ASM se volvió urgente ahora

La transformación digital, la adopción masiva de la nube y el cambio abrupto hacia el trabajo remoto hicieron explotar la superficie de ataque de las organizaciones modernas. Antes, la seguridad se concentraba en el perímetro, el famoso foso del castillo. Había un firewall en el borde de la red, un IDS mirando el tráfico que entraba y salía, y todo lo que estaba adentro se consideraba razonablemente seguro. Ese modelo se acabó. El perímetro ya no existe.

Los empleados acceden a los sistemas corporativos desde casa, desde cafeterías, desde aeropuertos. Aplicaciones críticas de negocio se ejecutan en múltiples nubes públicas (AWS, Azure, Google Cloud) que usted no controla físicamente. Los socios de negocio tienen acceso directo a APIs y sistemas internos. Dispositivos IoT se conectan a la red sin pasar por ningún proceso formal de aprobación de TI. Cada uno de estos puntos es una extensión de su superficie de ataque.

Gartner ha sido enfático sobre la importancia del ASM en los últimos años. En sus previsiones de tendencias de seguridad, el instituto de investigación destaca que la Gestión de la Superficie de Ataque Externa (EASM) es una de las principales prioridades estratégicas para los CISOs. Gartner prevé que, para 2026, las organizaciones que prioricen sus inversiones en seguridad con base en un programa de ASM continuo sufrirán dos tercios menos violaciones que las que no lo hacen. Esta no es una mejora marginal; es una diferencia transformadora.

Sin ASM, el equipo de seguridad trabaja a ciegas. Arregla las fallas que conoce, parcha los sistemas inventariados, contrata un pentest para la aplicación documentada. Mientras tanto, el atacante explota lo que le entregó el reconocimiento automatizado: el servidor olvidado, la API mal configurada, el subdominio vulnerable que nadie sabía que existía. Un lado ve el campo entero y el otro ve una parte.

Qué habilita el ASM

Adoptar una plataforma de ASM cambia lo que el equipo ve y, después, lo que puede hacer con eso.

Anticipación real de amenazas

El ASM cambia completamente el juego de reactivo a proactivo. En el modelo tradicional, la secuencia es dolorosamente familiar: usted es atacado, detecta el incidente (si tiene suerte, rápidamente), responde al ataque, contiene el daño y entonces finalmente corrige la vulnerabilidad que fue explotada. Es un ciclo de "Fuimos atacados, ahora necesitamos corregir". Con ASM, la narrativa cambia radicalmente a "Encontramos una falla expuesta que sabemos que está siendo activamente escaneada por grupos de ransomware, vamos a corregirla antes de que ocurra cualquier ataque".

Usted pasa a ver su infraestructura con los ojos del adversario. Una plataforma ASM robusta replica la perspectiva de un atacante, escaneando continuamente su presencia digital externa de la misma forma en que lo haría un atacante: identificando puertos abiertos, servicios expuestos, certificados SSL, subdominios y tecnologías en uso. La diferencia crítica es que usted descubre y corrige las vulnerabilidades antes de que los atacantes las exploten. Es seguridad proactiva, no reactiva.

Bajar el MTTR (Mean Time to Remediation)

El MTTR, o Tiempo Medio para Remediación, es una métrica vital que mide cuánto tiempo transcurre desde la identificación de una vulnerabilidad hasta su corrección efectiva. El problema de muchos equipos de seguridad no es la falta de voluntad o capacidad de corregir vulnerabilidades; es la falta de priorización eficaz frente a un volumen abrumador de alertas.

Un scanner de vulnerabilidades tradicional ejecutado en la red interna puede fácilmente generar 50.000 alertas. ¿Cuál corrige primero? Muchos equipos terminan priorizando por CVSS score (Common Vulnerability Scoring System), pero eso falla en la raíz, porque el CVSS no toma en cuenta el contexto específico de su organización. Una vulnerabilidad con CVSS 9.8 en un servidor de desarrollo interno sin acceso a internet es mucho menos urgente que una vulnerabilidad CVSS 7.5 en un servidor web público que procesa transacciones financieras.

Una plataforma de ASM resuelve este problema de priorización de forma elegante. Dirá: "De estas 50.000 vulnerabilidades identificadas, estas 15 específicas están en servidores expuestos a internet, tienen exploits públicos disponibles en Metasploit, están siendo activamente escaneadas por grupos de ransomware conocidos (basado en inteligencia de amenazas), y afectan sistemas que procesan datos críticos de clientes. Corríjalas ahora, en este orden". El resultado es una reducción dramática del MTTR para las vulnerabilidades que realmente importan.

Higiene cibernética básica (CIS Controls)

El ASM es la base de la higiene cibernética, el conjunto de prácticas que toda organización debería tener antes que cualquier otra cosa. Los CIS Controls v8 (y la versión más reciente v8.1) son un conjunto ampliamente reconocido de mejores prácticas de defensa cibernética, desarrollado por especialistas de seguridad de todo el mundo. Estos controles están organizados en tres Implementation Groups (IG1, IG2, IG3) basados en el tamaño y la sofisticación de la organización.

El Implementation Group 1 (IG1) es lo que CIS llama higiene cibernética básica: el mínimo que cualquier empresa, sin importar tamaño ni sector, debería implementar. Es el equivalente cibernético de lavarse las manos.

Los dos primeros controles de CIS, que forman la base de todo el framework, son:

CIS Control 1: Inventario y Control de Activos Empresariales. Usted necesita saber qué dispositivos y sistemas existen en su red.

CIS Control 2: Inventario y Control de Activos de Software. Usted necesita saber qué aplicaciones y software están ejecutándose en esos sistemas.

El ASM automatiza y valida esos dos controles para los activos expuestos a internet. No hay IG1 sin saber qué activos y qué software están expuestos ahí afuera. El ASM descubre esos activos y mantiene el inventario vivo, actualizado solo. A mano, en una organización moderna, eso no aguanta un trimestre.

El costo de la falta de visibilidad: lecciones de 7 incidentes reales

La ausencia de una plataforma de monitoreo continuo de la superficie de ataque puede tener consecuencias significativas. Los casos a continuación ilustran situaciones donde la falta de visibilidad completa de los activos externos resultó en incidentes de alto impacto. Todos involucraban vulnerabilidades en aplicaciones expuestas a internet: exactamente el tipo de exposición que una plataforma ASM completa está diseñada para identificar proactivamente.

Incidentes internacionales

Equifax (2017)

La violación de datos de Equifax ilustra los desafíos de mantener visibilidad completa de activos en grandes organizaciones.

El desafío: una vulnerabilidad crítica (CVE-2017-5638) existía en el framework de aplicación web Apache Struts, utilizado en un portal público. Aunque el parche de corrección estaba disponible, la complejidad de rastrear todos los activos y sus dependencias dificultó la identificación y remediación en tiempo hábil.

El perjuicio: la filtración expuso datos personales sensibles de más de 147 millones de personas, incluyendo números de seguro social, fechas de nacimiento, direcciones y, en algunos casos, números de licencia de conducir. El costo total para Equifax, incluyendo multas regulatorias, acuerdos judiciales, costos de remediación y pérdida de valor de mercado, superó los $1.4 bilhão. El CEO renunció, y la reputación de la empresa quedó permanentemente manchada.

¿Cómo ayudaría el ASM? Una plataforma de ASM habría ejecutado tres funciones críticas: (1) Descubrir el portal público e identificar que formaba parte de la infraestructura de Equifax, aunque fuera un activo "olvidado" o mal documentado. (2) Identificar que el portal usaba Apache Struts y qué versión específica estaba ejecutándose. (3) En el momento en que la CVE-2017-5638 fue divulgada públicamente, la plataforma habría cruzado esa información con el inventario de activos y priorizado la aplicación del parche como "crítica" de inmediato, mucho antes de que los atacantes explotaran la vulnerabilidad meses después.

Capital One (2019)

El caso de Capital One destaca la complejidad de gestionar configuraciones de seguridad en entornos de nube dinámicos.

El desafío: una configuración inadecuada en un Web Application Firewall (WAF) en los servidores de nube AWS creó una vulnerabilidad. La configuración permitía que comandos especialmente formateados fueran ejecutados por el servidor, posibilitando acceso no autorizado a buckets S3 que contenían datos de clientes.

El perjuicio: el atacante logró acceder y extraer datos de más de 100 millones de clientes y solicitantes de tarjeta de crédito. Capital One fue multada en $190 millones por reguladores federales, sumado a costos altos de recuperación, notificación de clientes y monitoreo de crédito.

¿Cómo ayudaría el ASM? Las plataformas de ASM descubren activos en la nube y siguen mirando su configuración, en busca de errores de configuración conocidos y de desvíos de la buena práctica. El ASM habría detectado la configuración insegura del WAF y la exposición inadecuada de los buckets S3 como un riesgo de alta prioridad, generando alertas para el equipo de seguridad con recomendaciones específicas de remediación, permitiendo la corrección antes de que ocurriera cualquier violación.

Kronos (UKG) (2021)

El incidente de Kronos demuestra el desafío de rastrear dependencias de software en aplicaciones complejas.

El desafío: la vulnerabilidad Log4j (CVE-2021-44228) afectó a una biblioteca de logging Java presente en miles de aplicaciones globalmente. Conocida como "Log4Shell", esta falla crítica de ejecución remota de código representó un desafío sin precedentes para los equipos de seguridad que necesitaban identificar rápidamente dónde estaba siendo utilizada la biblioteca.

El perjuicio: un ataque de ransomware que explotó la vulnerabilidad Log4j paralizó completamente los servicios de nómina en la nube de Kronos durante semanas, afectando a miles de clientes globales, incluyendo empresas masivas como Tesla y Pepsico. Los empleados no lograban registrar horas, las empresas no lograban procesar nóminas. La empresa matriz UKG reportó pérdidas directas de más de $30 milhões, sin contar los daños a los clientes.

¿Cómo ayudaría el ASM? El caso Log4j fue un momento definitorio para el ASM. En el "Día Cero" de la divulgación de la vulnerabilidad, cuando organizaciones de todo el mundo entraron en pánico intentando descubrir dónde estaban usando Log4j, las plataformas de ASM fueron las herramientas más eficaces disponibles. Escanearon rápidamente toda la superficie de ataque externa en busca de señales de la biblioteca vulnerable (mediante técnicas como análisis de respuestas HTTP, fingerprinting de aplicaciones y detección de comportamiento), permitiendo que los equipos identificaran y priorizaran la corrección de sistemas críticos en horas, no en semanas.

Incidentes en Brasil

Banco Inter (2018)

El caso de Banco Inter evidencia los desafíos de seguridad en APIs, especialmente en entornos de rápida innovación digital.

El desafío: una API (Interfaz de Programación de Aplicaciones) presentaba una vulnerabilidad de autorización. Un investigador de seguridad identificó que era posible acceder a datos de otros titulares de cuenta alterando parámetros en la llamada de API. Esta falla, conocida como Insecure Direct Object Reference (IDOR) o Broken Object Level Authorization (BOLA), está entre las vulnerabilidades más comunes en APIs modernas, listada en el OWASP API Security Top 10. La API exponía datos sensibles, incluyendo información personal identificable (PII) y detalles de transacciones financieras.

El perjuicio: el banco sufrió una multa de R$ 1,5 milhão aplicada por el MPDFT (Ministério Público do Distrito Federal e Territórios) y enfrentó un daño reputacional significativo en un momento crítico de crecimiento. Para un banco digital que se posicionaba como tecnológicamente avanzado, el incidente fue particularmente perjudicial para la marca.

¿Cómo ayudaría el ASM? El ASM está específicamente diseñado para descubrir todos los activos expuestos, incluyendo "Shadow APIs": APIs que el equipo de TI central puede no saber que están en línea, frecuentemente creadas por equipos de desarrollo para proyectos específicos y luego olvidadas. Una plataforma de ASM habría: (1) Descubierto el endpoint de la API, ya sea por haber identificado documentación (swagger/openapi) relacionada o a través de integración directa con la nube (lectura de las rutas de los api gateways). (2) Analizado su comportamiento mediante pruebas automatizadas e identificado la falta de controles de autorización adecuados. (3) Señalado esta API como un riesgo crítico, permitiendo que el equipo de seguridad corrigiera la falla antes de cualquier explotación maliciosa.

Atento (2020)

El caso de Atento ilustra los riesgos de una visibilidad inadecuada de activos en infraestructuras complejas.

El desafío: una base de datos Elasticsearch que contenía 14TB de datos quedó accesible por internet sin autenticación adecuada. Esta base contenía datos sensibles de clientes de Atento —incluyendo grandes bancos brasileños, empresas de telecomunicaciones y minoristas— con información personal identificable (PII), registros de llamadas de call center y detalles de servicios prestados.

El perjuicio: exposición de datos de millones de brasileños y de clientes corporativos de Atento. El incidente ocurrió justo después de la entrada en vigor de la LGPD (Lei Geral de Proteção de Dados), resultando en investigaciones regulatorias y un perjuicio de imagen incalculable para una empresa cuyo negocio principal es justamente la gestión segura de datos de terceros. La confianza de los clientes corporativos quedó severamente afectada.

¿Cómo ayudaría el ASM? Este es un caso de libro de texto de falla en el CIS Control 1 (Inventario de Activos). Una herramienta de ASM habría escaneado continuamente los rangos de IP y entornos de nube de Atento, descubriendo instantáneamente: (1) Un servicio (Elasticsearch) ejecutándose en un puerto público accesible desde internet. (2) La configuración errónea crítica: la ausencia completa de autenticación o controles de acceso. (3) La alerta generada habría tenido prioridad máxima, ya que las bases de datos expuestas se consideran "frutas bajas" (objetivos extremadamente fáciles) para los atacantes y son escaneadas por bots automatizados las 24 horas del día, los 7 días de la semana. La corrección podría haberse hecho en minutos, simplemente cerrando el acceso público o implementando autenticación.

Prefeitura do Rio de Janeiro y MOVEit (2023)

El incidente de MOVEit en la Prefeitura do Rio demuestra el desafío de responder rápidamente a vulnerabilidades de día cero en software de terceros.

El incidente: en 2023, la Prefeitura do Rio de Janeiro fue afectada por una campaña de ataque global que explotó una vulnerabilidad en el software MOVEit Transfer. Datos sensibles de contribuyentes, incluyendo información de IPTU (Imposto Predial e Territorial Urbano) e ISS (Imposto Sobre Serviços), fueron expuestos. El incidente formó parte de una campaña masiva del grupo de ransomware Cl0p que afectó a cientos de organizaciones globalmente.

El desafío: la vulnerabilidad CVE-2023-34362 en MOVEit Transfer —un software de transferencia de archivos ampliamente utilizado por organizaciones gubernamentales y empresas— permitía inyección de SQL. La ventana entre la divulgación pública y la explotación activa fue extremadamente corta, creando un desafío significativo para la identificación y remediación.

El perjuicio: exposición de datos sensibles de ciudadanos cariocas y empresas. La Prefeitura fue notificada por el Laboratório de Segurança Cibernética (LAB-DEF/MJSP) sobre la explotación, pero el daño ya estaba hecho. Globalmente, esta única CVE costó miles de millones de dólares a cientos de empresas (como British Airways, BBC, Shell, Siemens) y expuso datos personales de más de 60 millones de personas en todo el mundo. El grupo Cl0p publicó listas de víctimas y exigió rescates masivos.

¿Cómo ayudaría el ASM? Este es un ejemplo perfecto de cómo funciona el ASM en una situación de crisis real. Descubrimiento: la plataforma de ASM habría identificado que la Prefeitura utilizaba un servidor MOVEit Transfer expuesto en internet, catalogándolo en el inventario de activos externos. Análisis: el inventario del ASM guarda activo, software y versión. El día en que Progress Software (dueña de MOVEit) y CISA (Agencia de Ciberseguridad de EE. UU.) anunciaron públicamente el CVE-2023-34362, la plataforma de ASM habría cruzado automáticamente esa información con el inventario. Priorización: el sistema generaría una alerta de prioridad "Crítica" o "Urgente", indicando: "Usted tiene un software (MOVEit Transfer) con una vulnerabilidad de ejecución remota de código (RCE) que está siendo activamente explotada ahora por grupos de ransomware conocidos. Desconecte el servidor de internet o aplique el parche de emergencia de inmediato." Con esa alerta, la Prefeitura habría tenido horas, no días, para actuar antes de que ocurriera el ataque.

Lojas Renner (2021)

El ataque a Lojas Renner ilustra los desafíos de proteger entornos corporativos complejos contra grupos de ransomware sofisticados que explotan múltiples vulnerabilidades conocidas.

El incidente: en agosto de 2021, Lojas Renner, una de las mayores cadenas minoristas de Brasil, sufrió un ataque de ransomware que afectó sus operaciones digitales y sistemas internos. El grupo RansomEXX (también conocido como Defray777) asumió la autoría, publicando indicios de compromiso en foros de la dark web. Aunque la empresa informó que no hubo filtración de datos personales de clientes, el episodio destacó la capacidad de los grupos organizados de explotar cadenas de vulnerabilidad y realizar movimiento lateral en grandes corporaciones brasileñas.

El desafío: el grupo RansomEXX es conocido por utilizar múltiples vulnerabilidades conocidas en sus campañas, creando un desafío complejo de defensa. Entre las CVEs históricamente asociadas al grupo y al loader PipeMagic están: CVE-2017-0144 (EternalBlue) para propagación interna en redes Windows mal segmentadas; CVE-2024-23897 (Jenkins LFI) para acceso inicial a servidores Jenkins expuestos; y CVE-2025-31324 (SAP NetWeaver) para ejecución remota de código en entornos SAP corporativos. La diversidad de vectores de ataque hace particularmente desafiante mantener visibilidad y disponibilidad de parche en toda la superficie de ataque.

El perjuicio: la paralización temporal de canales digitales y sistemas de back-office causó impactos financieros y reputacionales significativos, afectando la confianza del mercado y demostrando el potencial destructivo de los ataques dirigidos de ransomware contra el comercio minorista brasileño.

¿Cómo ayudaría el ASM? Una plataforma de ASM como CSURFACE habría proporcionado múltiples capas de protección: (1) Descubrimiento de servicios vulnerables: identificación de servicios críticos expuestos a internet, como SMB, Jenkins y componentes SAP Web, que son objetivos conocidos de grupos de ransomware. (2) Detección de versiones desactualizadas: mapeo continuo de versiones de software y correlación automática con CVEs conocidas explotadas por grupos como RansomEXX. (3) Priorización por inteligencia de amenazas: correlación automática entre exposición de activos, criticidad del sistema y probabilidad real de explotación basada en actividad observada de grupos de amenaza (threat likelihood), permitiendo que el equipo de seguridad priorice remediaciones en los activos que los grupos de ransomware están apuntando activamente.

Conclusión: qué ahorra el ASM

La ausencia de visibilidad continua de la superficie de ataque puede resultar en consecuencias financieras significativas. Los datos del informe "Cost of a Data Breach 2024" de IBM Security son reveladores.

El costo medio de una filtración de datos alcanzó un récord histórico de USD 4.88 milhões, representando un salto del 10% respecto al año anterior. Este no es un aumento gradual; es una aceleración preocupante que muestra que los costos de los incidentes de seguridad están creciendo más rápido que los presupuestos de seguridad de la mayoría de las organizaciones.

El informe detalla también los factores que suben y bajan ese costo, y ahí la cuenta se pone interesante. Las organizaciones que implementaron tecnologías de Attack Surface Management ahorraron en promedio USD 186.000 por incidente de violación de datos, comparadas con las que no lo hicieron. La cifra sale de miles de incidentes analizados, no de una proyección.

Más impresionante aún, el informe muestra que las organizaciones que combinaron ASM con IA de seguridad y automatización ahorraron en promedio USD 2.22 milhões por incidente, casi la mitad del costo medio total de una violación. Piénselo: implementar ASM no es un costo; es una inversión con ROI (Return on Investment) comprobado y medible.

Para poner esto en perspectiva: si su organización sufre una única violación de datos en los próximos 5 años (y las estadísticas sugieren que la probabilidad es alta), la inversión en una plataforma de ASM se paga múltiples veces solo por la reducción del impacto de ese único incidente. Y esto sin contar los incidentes que serán completamente evitados porque las vulnerabilidades fueron descubiertas y corregidas antes de cualquier explotación.