Cuando una empresa comienza a mapear su superficie de ataque, una de las primeras sorpresas suele ser bastante simple: aparecen cosas que nadie recordaba que todavía estaban publicadas.
Un subdominio creado para una campaña antigua. Una aplicación de pruebas que terminó permaneciendo accesible. Una dirección IP asociada a un servicio que ya debería haber sido desactivado. Una API utilizada por una integración que cambió hace meses.
No siempre existe una vulnerabilidad en esos activos. Ese no es necesariamente el problema.
El primer problema es descubrir que todavía existen — y que alguien desde fuera de la organización puede encontrarlos.
Ese es un buen punto de partida para entender lo que llamamos superficie de ataque.
¿Qué forma parte de la superficie de ataque?
En términos generales, la superficie de ataque es el conjunto de activos, sistemas, aplicaciones, servicios, interfaces y otros puntos que un atacante puede alcanzar o utilizar para intentar acceder a sistemas, obtener datos sensibles o comprometer una organización.
NIST define attack surface a partir de los puntos de un sistema o entorno en los que un atacante puede intentar entrar, causar algún efecto o extraer datos.
En la práctica, esto puede incluir sitios y aplicaciones web, direcciones IP, puertos y servicios publicados, APIs, entornos cloud, aplicaciones móviles, repositorios públicos y diferentes componentes que terminan conectando una organización con Internet.
Pero la superficie de ataque no se resume a una lista de esos activos.
Imaginemos que una empresa tiene 200 subdominios.
El número, por sí solo, dice muy poco.
Algunos pueden apuntar a aplicaciones importantes y bien administradas. Otros pueden no responder. Uno quizá sea un entorno legado olvidado. Otro puede exponer una tecnología vulnerable. Incluso puede existir un subdominio que ni siquiera figure en el inventario oficial de la empresa.
Todos aparecen durante el discovery. Pero no necesariamente representan lo mismo desde el punto de vista de seguridad.
Aquí es donde empezamos a salir de un simple inventario y a observar cómo están expuestos esos activos.
La dificultad es que ese inventario no se queda quieto
Si la superficie de ataque fuera relativamente estática, bastaría con realizar un buen relevamiento algunas veces al año y mantener una planilla actualizada.
En la realidad, cambia todo el tiempo.
Nuevas aplicaciones pasan a producción. Se crean entornos para proyectos temporales. Se publican servicios cloud. Aparecen APIs para nuevas integraciones. Proveedores comienzan a operar componentes del entorno. Cambian direcciones IP. Se migran aplicaciones.
Y también existe el camino contrario: sistemas que deberían desaparecer, pero nunca desaparecen por completo.
Este último caso es especialmente interesante porque, internamente, el sistema puede haber dejado de formar parte de la operación. El equipo cambió, el proyecto terminó, la aplicación fue reemplazada.
Sin embargo, para quien mira desde afuera, basta con que siga siendo accesible.
El problema del activo olvidado es que, normalmente, el atacante no lo olvidó.
No porque alguien esté siguiendo específicamente ese activo, sino porque Internet puede ser continuamente investigada, indexada y analizada. Un servicio antiguo no necesita estar en el inventario oficial para ser encontrado.
OWASP, por ejemplo, incluye la identificación de la superficie de ataque entre las actividades de recopilación de información en pruebas de seguridad de aplicaciones web. La lógica es bastante directa: antes de buscar formas de comprometer un entorno, es necesario entender qué existe y dónde están sus posibles puntos de entrada.
Y justamente por eso la visión externa suele revelar situaciones interesantes.
No parte necesariamente de lo que la organización cree que posee. Parte de aquello que puede encontrarse.
No todos los cambios tienen que ocurrir en el activo
Hay otro aspecto de la superficie de ataque que a veces pasa desapercibido.
Un activo puede permanecer exactamente igual que ayer y, aun así, requerir más atención hoy.
Imaginemos un servicio publicado en Internet desde hace meses. No cambió ninguna configuración. La dirección sigue siendo la misma, el puerto continúa abierto y la versión del software tampoco cambió.
Entonces se divulga una nueva vulnerabilidad para esa versión.
Algunos días después aparece un exploit público.
Más adelante comienzan a surgir evidencias de explotación en el mundo real.
Desde el punto de vista del inventario, prácticamente no ocurrió nada.
Desde el punto de vista del riesgo, ocurrió bastante.
Por eso, acompañar la superficie de ataque no significa únicamente descubrir cuándo aparecen nuevos activos. También significa observar cuándo cambia el contexto de algo que ya estaba expuesto.
Esta es una de las razones por las que una fotografía puntual del entorno envejece relativamente rápido.
Superficie de ataque no es lo mismo que vector de ataque
Los dos conceptos aparecen juntos con frecuencia y es fácil confundirlos.
La superficie de ataque representa los puntos que un atacante puede alcanzar o utilizar.
El vector de ataque es el camino o método utilizado para intentar explotar uno de esos puntos.
Una aplicación web pública, por ejemplo, forma parte de la superficie de ataque. Una vulnerabilidad en esa aplicación puede hacer que forme parte de un vector de ataque.
Pero un vector también puede comenzar de otra manera.
Una credencial corporativa filtrada puede permitir acceso a un servicio remoto. Un secret expuesto en un repositorio puede dar acceso a una API. Un servicio sensible publicado en Internet puede permitir un intento directo de compromiso.
En la práctica, es común que un vector involucre más de una etapa.
Y ahí es donde simplemente saber que un activo existe comienza a ser insuficiente. Queremos entender qué puede hacerse a partir de él.
Volveremos sobre este tema con más profundidad en otro Insight, porque el vector de ataque merece una discusión propia.
¿Una superficie mayor significa necesariamente más riesgo?
No.
Una organización global con miles de activos puede tener una superficie de ataque mucho mayor que una empresa pequeña y, aun así, administrar sus exposiciones de forma bastante más eficiente.
De la misma manera, una empresa con pocos activos puede mantener justamente un servicio crítico en una condición de exposición inadecuada.
Contar activos ayuda a entender la dimensión del entorno. Por sí solo, no determina el riesgo.
Cuando analizamos una superficie de ataque, algunas cosas terminan siendo más útiles que el número absoluto: qué activos son accesibles, qué servicios están publicados, qué tecnologías se utilizan, qué exposiciones existen y si alguna de ellas ofrece condiciones interesantes para un atacante.
A veces un solo activo merece más atención que cientos de otros.
Esta distinción es importante porque existe una tendencia natural a transformar visibilidad en volumen: más dominios encontrados, más IPs, más puertos, más findings.
Pero encontrar más cosas no significa necesariamente comprender mejor el riesgo.
¿Dónde entra Attack Surface Management?
Es en este contexto donde aparece Attack Surface Management (ASM).
La idea no es simplemente ejecutar un discovery de activos una vez y considerar el trabajo terminado. El objetivo es mantener visibilidad sobre una superficie que continúa cambiando, identificar exposiciones y acompañar lo que ocurre con ellas a lo largo del tiempo.
Esto acerca ASM a la visión que podría tener un atacante del entorno: mirar desde afuera hacia adentro, buscar qué está accesible e intentar entender qué oportunidades pueden ofrecer esas exposiciones.
Hay una diferencia importante.
El inventario interno normalmente responde:
“¿Qué sabemos que tenemos?”
El análisis de la superficie de ataque también intenta responder:
“¿Qué puede encontrar alguien desde fuera de la organización?”
Cuando las dos respuestas son diferentes, normalmente hay algo que vale la pena investigar.
A veces será simplemente un activo que debía incorporarse al inventario. En otras situaciones puede aparecer un servicio sensible, una aplicación antigua, una credencial filtrada, un repositorio expuesto o alguna configuración que merece análisis.
No todo descubrimiento representará un riesgo relevante.
Y quizá ese sea justamente el punto.
El objetivo de conocer la superficie de ataque no debería ser producir la mayor cantidad posible de findings. Debería ser poder separar aquello que simplemente existe de aquello que realmente merece atención.
Porque descubrir es solo el comienzo.
Referencias
Continúa explorando
- ¿Qué es CTEM y cómo funciona Continuous Threat Exposure Management?
- Gestión de Vulnerabilidades: por qué la severidad no es suficiente para definir prioridades
- ¿Qué es un vector de ataque? Entiende su relación con la superficie de ataque
¿Quieres llevar esta visión a tu superficie de ataque?
Conoce cómo Lion Focus ayuda a descubrir, monitorear, validar y priorizar exposiciones cibernéticas.
Leonnes Cybersecurity
Cyber Exposure Platform
