Visión externa en respuesta a incidentes es el levantamiento, hecho de fuera hacia dentro y sin agente instalado, de todo lo que está publicado en internet a nombre de la organización. Con un incidente abierto sirve para dos cosas: estimar hasta dónde pudo llegar el compromiso y listar por dónde más pudo haber entrado el adversario.
El incidente ya está en marcha cuando suena el teléfono. El equipo interno contiene, la firma de respuesta ha llegado o está llegando, y alguien de dirección ya ha preguntado dos veces qué tamaño tiene esto.
En España esa pregunta viene con un reloj encima. El artículo 23 de la directiva NIS2 obliga a las entidades afectadas a enviar un aviso temprano de incidente significativo en un máximo de 24 horas y una notificación de incidente en un máximo de 72 horas desde que se tiene conocimiento de él. Las dos comunicaciones piden una valoración del alcance, y el alcance es justo lo que peor se conoce en las primeras horas.
La pregunta que atasca la primera hora
La revisión 3 de la NIST SP 800-61, publicada en abril de 2025, dejó de organizar la respuesta a incidentes en cuatro fases y pasó a describirla como un perfil del CSF 2.0. Las actividades de preparación, que viven en las funciones Gobernar, Identificar y Proteger, quedaron fuera de la respuesta propiamente dicha y a la vez reconocidas como lo que la sostiene.
Dentro de ese documento, el elemento RS.AN-08 trata de estimar y validar la magnitud del incidente. La nota que lo acompaña dice que determinar la magnitud suele ser uno de los aspectos más difíciles de la respuesta. La recomendación siguiente explica el porqué: buscar indicadores de compromiso y evidencia de persistencia tanto en los activos que se sabe que fueron objetivo como en otros objetivos potenciales. Y el aviso posterior es la frase más dura del capítulo. Saltarse esa actividad, o hacerla de forma superficial, subestima la magnitud y permite que el incidente continúe indefinidamente en otros objetivos sin que la organización lo sepa.
Dos grupos de objetivo, entonces. Lo que se sabe y lo que aún no. El segundo grupo es precisamente lo que una lista interna de activos no puede dar, porque la lista interna describe lo que la empresa registró, y el adversario nunca se limitó a lo que la empresa registró.
El mismo documento es explícito en otro punto. En la categoría de gestión de activos, la nota dice que la información de inventario ayuda al equipo de respuesta a entender el impacto del incidente, a identificar otros activos que puedan ser objetivo y a ordenar los esfuerzos de respuesta y recuperación. Los elementos ID.AM-01 e ID.AM-02 piden inventarios de hardware y de software mantenidos de forma actualizada y automática, y mencionan por su nombre la identificación de shadow IT como uno de los propósitos.
El cliente que llegó después de que empezara el incidente
Una operación de comercio electrónico llegó a CSURFACE con el incidente ya en curso. La respuesta técnica estaba contratada y funcionando. Faltaba otra cosa. Nadie podía responder, con evidencia, qué activos de la empresa eran alcanzables desde internet en ese momento y por cuáles de ellos se podría haber entrado.
No era desorden. Es la situación normal de cualquier empresa que creció a base de proyectos, campañas e integraciones durante diez años, con el inventario mantenido por quien quedaba de cada una de esas fases.
Lo que recibió el equipo de respuesta fue un mapa levantado desde fuera, sin depender de nada instalado en el entorno, mientras la contención seguía.
Dos listas que se levantan desde fuera en pocas horas
La primera lista es lo que está publicado hoy a nombre de la organización. El descubrimiento parte de un solo dominio y devuelve lo que está publicado a nombre del grupo: subdominios, otras marcas y activos de filiales que no figuran en ninguna lista interna. Los primeros activos aparecen en pocas horas y la cobertura se consolida en los días siguientes. Para un equipo de respuesta, lo más útil de esa lista es el histórico. Como la plataforma guarda primera y última observación de cada activo, servicio y certificado, se puede responder qué existía en la semana del incidente, y no únicamente qué existe ahora.
La segunda lista es la de caminos plausibles. Saber que hay 300 activos no basta. Importa cuáles exponen un servicio administrativo, cuáles ejecutan una versión con un fallo bajo explotación conocida y cuáles concentran alcance, es decir, cuáles sirven de puente hacia el resto. Es el trabajo del grafo de exposición y del cálculo de radio de alcance, y es la diferencia entre entregar un inventario y entregar una hipótesis ordenada.
Tener el mapa completo y siempre al día reduce el espacio de búsqueda a unos pocos puntos posibles, que es lo que necesita el equipo forense con el reloj corriendo.
Una credencial filtrada que todavía funciona es la pista más rápida
Esto se lleva sección propia porque suele ser el hallazgo de mayor valor por hora de trabajo durante un incidente.
Cualquier organización con unos años de vida acumula credenciales filtradas asociadas a su propio dominio. Llegan de brechas en servicios de terceros donde alguien se registró con el correo corporativo, de repositorios en los que se subió una clave y después se borró el archivo sin reescribir el histórico, de colecciones que llevan años circulando y se reempaquetan con nombre nuevo cada temporada. El volumen crece solo y no se detiene.
Buscar el dominio de la empresa en esas fuentes devuelve normalmente cientos o miles de líneas. Ahí empieza el problema, porque la lista en bruto sirve para muy poco. La mayoría está muerta: la contraseña se cambió, la persona se fue, el servicio filtrado ya ni existe, o el par nunca fue válido y entró en la colección como relleno. Un puñado sigue funcionando, y nada en la lista dice cuál.
Durante un incidente eso deja de ser una molestia y pasa a ser un problema de decisión. El equipo tiene horas, no semanas, y necesita saber si una credencial fue la vía de entrada antes de decidir dónde buscar. Una lista de mil líneas no responde a eso. Peor aún, transmite la sensación de que el ángulo de credenciales quedó cubierto cuando no lo está. El equipo mira, no puede actuar, lo archiva y sigue por otra hipótesis, que puede ser la equivocada.
Lo que resolvería esto es un solo dato, y no está en la lista: cuáles de esas credenciales siguen autenticando, ahora mismo, y contra qué servicio. Doce pares que funcionan en este momento no son una versión reducida de la lista de mil. Son otra cosa. Dejan de ser indicio y se convierten en hecho verificado, con titular, con sistema objetivo y con una acción evidente sobre cada uno. El orden del día cambia: esas doce cuentas pasan a ser prioridad de bloqueo y de caza de sesión activa, y el ángulo de credenciales deja de ser una pregunta abierta.
El motivo de que casi nadie entregue esto es que la comprobación resulta incómoda. Probar si una credencial funciona significa intentar autenticarse como su titular, lo que exige autorización explícita, cuidado para no disparar bloqueos de cuenta y un registro de todo lo intentado. Quedarse en el cruce y entregar el CSV es mucho más sencillo. Y el CSV es justamente la parte que no decide nada.
Lo que la visión externa no hace
Esta sección protege a quien va a usar el material, y vale más que la anterior.
La visión externa no sustituye al análisis forense. Los registros de endpoint, la línea temporal de ejecución en el host y la imagen de disco quedan fuera de su alcance por construcción. Nada de lo que está detrás de la VPN aparece, incluidos los permisos excesivos en cuentas de nube, los equipos sin parchear y el uso indebido de credenciales válidas por alguien que ya está dentro.
La validación activa ocurre donde hay cobertura de módulo de prueba. En el resto de la superficie la evaluación es pasiva, basada en versión y comportamiento observado, y un hallazgo pasivo es una hipótesis, no una prueba. Confundir ambas cosas durante una crisis cuesta credibilidad dentro de la empresa, que es la moneda más escasa del equipo de seguridad esa semana.
La plataforma tampoco corrige nada por sí sola ni convierte el riesgo en una cifra financiera. Quien decide qué apagar a las tres de la madrugada sigue siendo una persona.
Dónde encaja esto para quien opera un SOC para terceros
Los proveedores que integran la superficie externa en su propio servicio de SOC la usan en dos momentos distintos, y el segundo es el que menos aparece en las propuestas.
El primero es la llegada. Un cliente nuevo en situación de incidente entrega una lista de activos que no se sostiene, y la discusión sobre alcance se come las primeras horas. Partir de un dominio semilla y levantar la superficie desde fuera resuelve eso sin depender de un acceso al entorno que muchas veces todavía se está restableciendo.
El segundo es la semana posterior a la contención. Es cuando el cliente pregunta si ya ha terminado, y es la pregunta que RS.AN-08 dice que suele responderse de forma superficial. Tener la lista de otros objetivos potenciales, con histórico de cuándo apareció cada uno, convierte esa conversación en algo comprobable.
Para el proveedor, la plataforma funciona multicliente por diseño, con separación por organización, control de acceso por alcance y traza de auditoría. La página de socios describe el modelo.
Después de apagar el fuego
El trabajo descrito aquí termina cuando el incidente se cierra. Lo que empieza en ese punto es otro, con otra métrica y otra cadencia, y decide si habrá un segundo incidente.
La empresa de ese caso mantuvo la superficie monitorizada después de la contención, y el motivo es siempre el mismo. La lista levantada durante el incidente tenía elementos que nadie sabía que existían, y la única forma de asegurarse de que no vuelvan a aparecer es mirar antes de que aparezca el siguiente.
De eso trata por qué la empresa que ya sufrió un ataque suele sufrir otro.
Dónde encaja CSURFACE en todo esto
Todo lo anterior es un problema de mercado y no de producto, y vale igual si lo resuelve con herramienta propia, con scripts o con otro proveedor.
CSURFACE existe porque decidimos resolver tres de esas partes desde fuera: el inventario de lo publicado a nombre del grupo, con histórico de primera y última observación, en descubrimiento continuo; la ordenación por alcance y explotación conocida en lugar de por nota teórica, en priorización; y la comprobación de qué credenciales filtradas siguen autenticando, que es la parte incómoda que casi nadie hace.
Si su equipo opera respuesta para terceros, la conversación que interesa es la de alianza.
Preguntas frecuentes
¿La visión externa sirve durante el incidente o solo después?
En los dos momentos, con usos distintos. Durante, dimensiona el alcance y reduce el espacio de búsqueda forense. Después, se convierte en medición continua de la superficie, que es lo que evita el incidente siguiente.
¿Sustituye a un servicio de respuesta a incidentes?
No. La contención, la erradicación, la recuperación y la pericia forense siguen siendo trabajo de un equipo de respuesta con acceso al entorno. La visión externa aporta a ese equipo la parte de la información que se obtiene desde fuera.
¿En cuánto tiempo es utilizable el mapa en una crisis?
Los primeros activos aparecen en pocas horas a partir de un dominio semilla, sin instalar nada. La cobertura se consolida en los días siguientes, y el histórico de primera y última observación viene con ella, lo que permite reconstruir qué estaba publicado en la fecha del incidente.
¿Qué no va a encontrar la visión externa?
Todo lo que solo existe dentro de la red. Movimiento lateral, abuso de credenciales por alguien ya autenticado, permisos excesivos en la nube y equipos sin parchear en red interna. Esa parte depende de telemetría interna y de trabajo forense en el entorno.