ASM (Attack Surface Management): por qué mirar tu sitio como un atacante
ASM es la disciplina que mapea todo lo que tu empresa expone a internet — conocido u olvidado — y mide el riesgo antes que el atacante. Qué es, qué NO es, y por dónde empezar.
La mayoría de las empresas sabe defender lo que recuerda que tiene. El problema vive en lo que olvidó: el subdominio de 2021, el bucket S3 público de cuando alguien probó un backup, el .env que volvió por error en un commit, el panel admin de staging que quedó en internet.
Estas cosas nacen y desaparecen sin que seguridad las vea. ASM existe para cerrar ese ángulo.
Qué es ASM
Attack Surface Management (gestión de superficie de ataque) es la disciplina que:
- Descubre continuamente todo lo que tu empresa expone a internet.
- Inventaria cada ítem con fingerprint (tecnología, versión, función).
- Evalúa el riesgo de cada uno (CVE, configuración, headers, certificado).
- Alerta cuando aparece algo nuevo, cuando algo conocido empeora, cuando algo crítico se vuelve público.
El ángulo importa: ASM es observación externa, sin agente, sin login. Ve lo que ve el atacante.
ASM ≠ pentest, ≠ EDR, ≠ vulnerability scanner
La confusión más común es ASM con vulnerability scanner. El scanner pide la lista de IPs. ASM descubre la lista. Es la diferencia entre recibir inventario hecho y construirlo.
Lo que entra en la "superficie de ataque"
La superficie externa típica de una empresa:
Capa DNS
- Dominio principal y variantes registradas (
.com,.io,.app) - Subdominios (descubiertos vía brute force + Certificate Transparency + zone transfer + scraping pasivo)
- Registros DNS sospechosos (MX huérfanos, CNAMEs apuntando a servicios muertos — vector de subdomain takeover)
Capa TLS
- Certificados en todos los dominios
- Fechas de expiración
- Cadena y algoritmos
- Versiones de TLS habilitadas
Capa HTTP
- Tecnologías detectadas (servidor web, framework, CMS, CDN, analytics)
- Versiones expuestas (banner,
?ver=, meta generator) - Headers de seguridad presentes/ausentes
- Endpoints sensibles abiertos (
/admin,/.git/,/.env,/wp-json/wp/v2/users)
Capa de puertos
- Puertos TCP/UDP abiertos en IPs públicas
- Banners de servicio (SSH, FTP, SMTP, RDP, base de datos expuesta)
Capa de email
- Configuración de SPF, DKIM, DMARC
- Reputación del IP de envío
- DMARC con
p=noneen dominio que envía email
Capa de identidad
- Paneles de login expuestos (
/wp-admin,/admin,/login) - ¿Brute-force posible? ¿Funciona el rate-limit?
- SSO mal configurado, OAuth callback abierto
Capa de código (cuando conectás el repo)
- Secrets filtrados (
AWS_SECRET, tokens, .env commiteado) - Vulnerabilidades en dependencias (SCA)
- Patrones inseguros en tu código (SAST)
El ciclo de ASM
Corre 24/7:
Descubrimiento → Inventario → Evaluación → Priorización → Alerta → Remediación → (vuelta)
La parte más descuidada es el descubrimiento. Empresas que hacen ASM "manual" siempre encuentran 60% de lo que tienen, se olvidan el resto, y es exactamente en ese 40% olvidado donde ocurre el incidente.
Por qué ASM es lo primero, no lo último
La pirámide que veo en cliente nuevo:
- Compró EDR para endpoints corporativos.
- Compró WAF para el sitio principal.
- Compró SIEM para correlacionar logs.
- Nunca mapeó lo que está expuesto en internet.
Cuando corremos el primer scan de ASM, en cliente mediano aparecen en promedio 3–7 sorpresas: subdominio huérfano, bucket público, panel staging en internet, backup .sql en carpeta servida, repo con secret. Ninguna de esas sería atrapada por EDR o WAF — porque el atacante ni necesita pasar por esa capa.
Sin mapa, la defensa es ilusión.
Cómo empezar (en el orden correcto)
- Inventario externo bruto: todos los dominios de la empresa (finanzas tiene el WHOIS), todas las IPs públicas (ASN de la empresa, rangos de cloud), todos los subdominios vía crt.sh.
- Triage por tipo: sitio institucional, app, API, panel interno expuesto, microservicio olvidado. Cada uno pide atención distinta.
- Evaluación técnica: TLS, headers, puertos, fingerprint, CVE matching.
- Priorización por impacto: panel admin público > sitio institucional sin header. No trates todo igual.
- Automatización continua: el paso 1 no es evento único. Es proceso. Cada semana nace subdominio nuevo.
Dónde entra Sentinela
Somos ASM con nota A–F. Pegás el dominio y:
- Descubrimos subdominios (DNS + CT logs + brute)
- Mapeamos tecnologías, versiones, headers, certificados, puertos
- Cruzamos con base de CVE pública y EPSS para priorizar
- Alertamos drift (apareció servicio nuevo, desapareció HSTS, certificado por vencer)
- Conectamos con repo para correr SAST y secret scanning
- Mostramos evolución del score en el tiempo
Para entender la relación entre ASM continuo y pentest puntual, vale leer pentest anual o auditoría continua — se complementan, pero ASM cubre el tiempo entre pentests.
La regla simple
No podés defender lo que no ves. ASM es el acto de ver primero. Antes del firewall, antes del EDR, antes del SIEM — antes de todo: mapeá tu superficie externa, y mantené el mapa fresco.
El atacante ya está haciendo esto contra vos. La pregunta es si vos también lo estás haciendo.
Descubre en 30 segundos lo que tu dominio está mostrando.
Comprobación pasiva, sin tocar tu servidor. Sale una nota y una lista de hallazgos por gravedad — y tú decides si quieres seguirlo cada mes.