Casos reales que podrían haberse evitado con el uso de un ASM

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.

Desentrañando los Conceptos: Superficie de Ataque vs. ASM

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.

Además, existen los activos de terceros que su organización utiliza pero no controla directamente. Código de socios, APIs externas, bibliotecas de software de código abierto como Log4j que su aplicación utiliza: todos estos representan vectores de ataque potenciales. Cuando se descubre una vulnerabilidad crítica en una de esas dependencias, usted necesita saber inmediatamente dónde está siendo utilizada en su infraestructura.

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 en un ciclo continuo de cuatro etapas esenciales que transforman la seguridad de reactiva en proactiva.

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. El ASM no se trata solo de generar informes bonitos; se trata de acción. Las mejores plataformas de ASM se integran directamente con los sistemas de tickets (como Jira o ServiceNow) y herramientas de gestión de vulnerabilidades para garantizar que las fallas de mayor riesgo no solo sean identificadas, sino efectivamente corregidas. La remediación se rastrea, se mide y se reporta, creando un ciclo de mejora continua.

¿Por qué el ASM es Tan Crítico 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. Antiguamente, la seguridad se concentraba en el perímetro: el famoso "foso" del castillo. Se tenía un firewall robusto en el borde de la red, sistemas de detección de intrusiones monitoreando el tráfico que entraba y salía, y todo lo que estaba dentro del perímetro se consideraba relativamente seguro. Hoy, ese modelo está completamente obsoleto. El perímetro simplemente 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 el ASM, los equipos de seguridad están esencialmente trabajando a ciegas. Intentan arreglar las fallas que conocen, aplicando parches en sistemas inventariados, realizando pruebas de penetración en aplicaciones documentadas. Mientras tanto, los atacantes están explotando las fallas que descubrieron a través de reconocimiento automatizado: aquel servidor olvidado, aquella API mal configurada, aquel subdominio vulnerable que nadie sabía que existía. Es una batalla desigual donde el atacante tiene visibilidad completa y el defensor está parcialmente ciego.

Estrategias de Seguridad Desbloqueadas por el ASM

Adoptar una plataforma de ASM no es solo comprar una herramienta e instalarla; es habilitar una estrategia de seguridad fundamentalmente diferente y más eficaz.

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.

Reducción Drástica del 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 esto es fundamentalmente defectuoso 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, poseen exploits públicos conocidos 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.

Habilitación de la Higiene Cibernética Esencial (CIS Controls)

El ASM es la base fundamental de la "higiene cibernética": las prácticas básicas de seguridad que toda organización debe tener. 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) se define como la "higiene cibernética esencial": el estándar mínimo absoluto de seguridad que todas las empresas, independientemente del tamaño o sector, deben implementar. Es el equivalente cibernético de lavarse las manos y usar el cinturón de seguridad.

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 precisamente estos dos controles fundamentales para los activos externos expuestos a internet. Es simplemente imposible tener una higiene cibernética básica (IG1) si no se sabe qué activos y software están expuestos en internet. El ASM no solo descubre esos activos, sino que mantiene un inventario vivo y actualizado automáticamente, algo que es prácticamente imposible de hacer manualmente en una organización moderna.

El Costo de la Falta de Visibilidad Continua: 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 milhões por reguladores federales, además de enfrentar costos masivos de recuperación, notificación de clientes y monitoreo de crédito.

¿Cómo Ayudaría el ASM? Las plataformas modernas de ASM no solo descubren activos en la nube, sino que también monitorean continuamente sus configuraciones en busca de configuraciones erróneas conocidas y desviaciones de las mejores prácticas. 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 - 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 ASM mantiene un inventario no solo de activos, sino también de software y versiones. 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 Basada en 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: el ASM No es Costo, es Ahorro

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.

Pero el informe de IBM va más allá de solo presentar el costo medio; detalla los factores que aumentan o disminuyen esos costos. Y aquí está la parte crucial: las organizaciones que implementaron tecnologías de Attack Surface Management ahorraron en promedio USD 186.000 por incidente de violación de datos en comparación con las organizaciones que no lo hicieron. Este no es un ahorro teórico o proyectado; es un ahorro real, medido y documentado en miles de incidentes analizados.

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.