Escaneos de seguridad: comprueba el permiso antes de probar

El alcance de un escaneo de seguridad define qué sistemas, servicios y técnicas puede probar una evaluación y en qué condiciones. Un nombre de host descubierto o una dirección IP obtenida por resolución DNS demuestra una relación técnica. Antes de enviar tráfico de prueba, aclara quién puede autorizar esa evaluación concreta, qué exclusiones se aplican y quién puede detenerla si cambia el destino o el permiso.

La distinción importa cuando el nombre de tu empresa aparece en tráfico que llega al servidor de otra persona. Una herramienta puede descubrir una relación real y, aun así, delimitar mal las pruebas que has encargado.

El 13 de septiembre, el operador voluntario de un servidor horario informó de tráfico inesperado de pruebas de seguridad que incluía un nombre de host de Tesla e identificadores relacionados con Assetnote. El operador planteó que un alias DNS hacia un conjunto compartido de servidores horarios podría explicar la selección del destino, y dejó claro que era una hipótesis. La página indica ahora que Assetnote contactó con él y que el asunto se resolvió. No acredita una causa raíz confirmada por el proveedor ni una intrusión efectiva.

Para tu equipo, la pregunta va más allá de ese relato: ¿qué pruebas justifican que un activo descubierto pase a ser un destino autorizado para el escaneo? El método que proponemos a continuación es una recomendación operativa propia, ilustrada con activos ficticios. Sirve para revisar tu proceso; no constituye una evaluación de los controles internos de ninguna de las dos empresas.

¿Qué abarca realmente el alcance de un escaneo de seguridad?

Una evaluación necesita límites tanto para el servicio que se prueba como para las acciones permitidas. Una lista de activos, por sí sola, no aclara qué se puede hacer.

Imagina una empresa ficticia, Example Works, con una aplicación en app.example.com. Tu equipo de aplicaciones puede controlar el código y la configuración del cliente mientras un proveedor opera la red subyacente. El permiso para probar la aplicación no resuelve si la evaluación puede examinar otros servicios en esa misma dirección, probar el entorno de otro cliente o utilizar técnicas que interrumpan el servicio.

Redacta el alcance de modo que quien evalúa pueda responder a tres preguntas sin hacer suposiciones: qué puede recibir tráfico, qué acciones se permiten y qué circunstancia obliga a parar. Incluye el entorno y la identidad de la cuenta. Una aplicación de producción y su copia de preproducción pueden tener responsables, datos y restricciones de funcionamiento distintos, aunque sus nombres se parezcan.

La sección 6.5 de NIST SP 800-115 describe la planificación de evaluaciones: sistemas permitidos y excluidos, actividades de prueba, logística, tratamiento de datos y procedimientos ante incidentes. También contempla el consentimiento de terceros y quién puede autorizar la reanudación de las pruebas. Son orientaciones publicadas en 2008, no un requisito nuevo de 2026.

Aplica ese principio con el nivel de detalle que requiera el encargo. Una revisión limitada a una aplicación quizá solo requiera un documento breve. Una evaluación recurrente de una infraestructura cambiante necesita un registro actualizado y un mecanismo para comprobar los cambios antes de ejecutar pruebas. En ambos casos, alguien debería poder explicar por qué la siguiente petición está dentro del alcance.

¿Adónde puede llevar un nombre de host descubierto?

Un nombre de host puede identificar un servicio que utilizas sin demostrar que controlas todo lo que hay detrás. Conserva los datos del descubrimiento, pero investiga la relación con el servicio antes de permitir pruebas activas.

Los ejemplos siguientes son ficticios. Plantean preguntas que hay que resolver, no reglas para aprobar o rechazar automáticamente un destino.

Una infraestructura compartida no queda automáticamente excluida. Puedes tener autorización válida para evaluar tu aplicación a través de la red perimetral de un proveedor. El límite se rompe cuando ese permiso se amplía, sin una decisión expresa, a otros clientes, puertos o servicios por el mero hecho de compartir dirección.

La guía de NTP Pool para proveedores describe las condiciones para los productos que utilizan el conjunto de servidores como servicio horario predeterminado, incluidos los nombres de host específicos para proveedores. Esas condiciones regulan el uso del servicio horario. Por sí solas, no autorizan pruebas de seguridad sobre las máquinas de los voluntarios que lo prestan.

Mantén las dependencias excluidas en el inventario. Tu equipo de seguridad puede seguir necesitando revisar su configuración, hablar con el proveedor sobre sus garantías o hacer seguimiento de una sustitución. Retirar un servicio de las pruebas activas no debe hacer desaparecer del inventario esa dependencia del negocio.

¿Qué conviene registrar antes de activar las pruebas?

Mantén un registro breve de autorizaciones junto al inventario de activos. Vincula cada activo con la documentación del permiso, las restricciones de las pruebas y la persona responsable de la evaluación.

Proponemos los siguientes campos. Adáptalos al encargo; no los trates como un formulario de cumplimiento obligatorio:

• Identidad del servicio: nombre de host, entorno e identificador pertinente del cliente, la cuenta o el recurso.
• Personas responsables: responsable de negocio, operador real y responsable de la evaluación.
• Datos del descubrimiento: cómo encontraste el activo y qué relación demuestran esos datos.
• Documentación del permiso: encargo aprobado, política aplicable del proveedor o acuerdo específico, con sus límites.
• Trabajo permitido: tipos de técnicas, exclusiones, cuentas permitidas y criterios de tratamiento de datos.
• Condiciones de validez: periodo o circunstancias que cubre el permiso y cambios que obligan a revisarlo.
• Referencia de ejecución: configuración del escáner o tarea de evaluación que aplica los límites aprobados.
• Contacto para detener las pruebas: quién puede parar el trabajo y quién puede autorizar su reanudación.

No exijas un nuevo correo de autorización para cada registro. Una política pública del proveedor puede permitir ya determinadas pruebas bajo ciertas condiciones. Por ejemplo, la política de pruebas de penetración de AWS distingue entre evaluar la infraestructura propia del cliente que admite estas pruebas y evaluar la infraestructura o los servicios de AWS en sí. Importan el servicio concreto y sus condiciones; una referencia genérica a un proveedor de nube no basta.

Utiliza estados claros para que el descubrimiento no desemboque en ejecución sin una decisión expresa. Proponemos descubierto, pendiente de verificar; verificado, sin autorización para esta evaluación; autorizado con restricciones; y pausado, pendiente de revisión. Son estados propuestos para tu proceso, no estados de activos incorporados en Kit.

Para el entorno ficticio de asistencia de Example Works, el registro podría permanecer verificado pero sin autorización mientras el responsable consulta la política del proveedor. La relación está confirmada y el inventario sigue siendo útil. Lo que falta es una base para incluirlo en la evaluación activa. Es un resultado normal, no una tarea administrativa pendiente que alguien deba quitarse de encima pulsando un botón de aprobación.

¿Cómo se conserva el alcance autorizado durante un escaneo?

La evaluación en curso debe respetar los límites del servicio aprobado. Revisa cómo convierten tus herramientas los nombres de host, las redirecciones y los nuevos descubrimientos en tareas ejecutables.

Empieza por el paso del inventario al escáner. Si apruebas el nombre de host de una aplicación, comprueba si la siguiente fase prueba esa aplicación o amplía el trabajo a las direcciones IP a las que resuelve. Convertir un nombre de host en una dirección puede ser necesario para establecer una conexión. Interpretarlo como permiso para probar todos los servicios de esa dirección es otra decisión.

Hazte la misma pregunta sobre las redirecciones y la exploración automatizada. Un enlace a la página de acceso de un proveedor puede aportar información útil sin ampliar la evaluación a ese proveedor. Decide si la herramienta se detiene, registra el destino para su revisión o continúa porque una autorización existente ya lo cubre. Quien apruebe la ejecución debe conocer ese comportamiento.

Revisa los cambios de infraestructura de forma proporcionada. Una instancia de sustitución dentro de la misma cuenta y los mismos límites autorizados puede estar ya cubierta. Un nuevo destino fuera de esos límites requiere una decisión. No impongas una aprobación manual para cada cambio rutinario de dirección; define qué condiciones de identidad y titularidad deben mantenerse.

El trabajo en cola merece una comprobación aparte. Eliminar un destino de la siguiente exportación del inventario no demuestra qué ocurre con las tareas ya programadas o en ejecución. Verifica cómo cancelan tus herramientas las tareas pendientes, gestionan los reintentos y aplican las exclusiones en los distintos procesos de ejecución. Son cuestiones de implementación y configuración del escáner, no garantías que aporte un documento de alcance.

Conserva la versión del alcance utilizada en cada ejecución y suficientes registros para relacionar una petición comunicada con su evaluación. Restringe el acceso a las muestras sensibles. El objetivo es responder después a una pregunta concreta: ¿qué servicio aprobado creía estar probando esta tarea y en qué permiso se basaba? Una captura de la configuración actual no explica una petición enviada con la configuración de ayer.

¿Cómo debe detenerse el trabajo ante un aviso de destino incorrecto?

Ofrece una vía directa para que los avisos de tráfico de evaluación no deseado lleguen a alguien que pueda detenerlo. Tu equipo debería comprobar el destino aunque quien escriba no tenga una vulnerabilidad con derecho a recompensa que comunicar.

Un contacto de divulgación facilita que te encuentren. La sección 5.5 de RFC 9116 aclara que la presencia o ausencia de security.txt no implica permiso para realizar pruebas. Trata el mecanismo de contacto y la política de autorización como elementos distintos y explica ambos con claridad.

Para el equipo que encarga la evaluación, recomendamos esta secuencia:

1. Pausa el trabajo implicado. Identifica la evaluación o el destino con suficiente precisión para detener el tráfico comunicado mientras investigas.
2. Conserva una muestra mínima. Pide marcas de tiempo e identificadores de petición pertinentes. Evita difundir cuerpos de petición sensibles o credenciales en notificaciones generales.
3. Localiza al responsable de la evaluación. Pon el aviso en manos de quien encargó la tarea y puede modificar su alcance.
4. Contrasta el destino. Comprueba la identidad del servicio, su operador real y la documentación del permiso frente a la tarea ejecutada.
5. Actualiza la ejecución y los registros. Corrige el destino o la exclusión y revisa las peticiones en cola, los reintentos y las programaciones recurrentes.
6. Verifica que el tráfico ha cesado. Compruébalo en los registros de ejecución. Cuando proceda, pregunta al operador que dio el aviso si sus observaciones coinciden.
7. Comunica el resultado. Explica qué se ha pausado o corregido y reanuda únicamente el trabajo cuya autorización esté acreditada.

No anuncies una causa raíz antes de comprobarla. Una primera respuesta útil puede confirmar la recepción del aviso, identificar a la persona responsable de investigarlo e indicar que la evaluación pertinente está pausada. Una respuesta posterior puede separar las conclusiones confirmadas de lo que aún se desconoce.

Esto guarda relación con la coordinación de una vulnerabilidad entre varios proveedores, pero ocurre antes. Aquí la tarea inmediata es establecer adónde debe dirigirse el tráfico que has encargado. La investigación de una vulnerabilidad puede continuar con un alcance adecuado y definido por separado.

¿Cómo puedes comprobar los límites sin sondear sistemas públicos?

Haz un simulacro de procedimiento con registros de inventario ficticios y una cola de pruebas que no genere tráfico de red. Comprueba cómo se decide y se pausa el trabajo antes de involucrar destinos externos reales.

En el ejercicio que proponemos, asigna a una persona el papel de evaluador y a otra el de responsable del servicio. Que trabajen con los registros que utiliza realmente tu equipo. No completes de palabra la información que falte; anota dónde necesitan inventarse una respuesta.

Cambia el operador. Empieza con una aplicación ficticia aprobada y modifica después su registro para que corresponda a un entorno de cliente alojado por un proveedor. Comprueba si la autorización existente cubre esa relación. La prueba se supera si el equipo demuestra el permiso aplicable o deja el nuevo destino pendiente de revisión.

Retira trabajo en cola. Añade un destino ficticio a la cola de pruebas y retira después su autorización. Revisa las tareas pendientes y los reintentos, además del siguiente descubrimiento programado. Documenta qué mecanismo impide ejecutar el trabajo cuyo permiso se ha retirado.

Sal de la aplicación aprobada. Incluye en el ejercicio una redirección ficticia hacia otro nombre de host de ejemplo. Pregunta qué hace después quien evalúa y dónde queda registrada esa decisión. Los límites del encargo deben determinar la respuesta, sea quien sea la persona que supervise en ese momento.

Recibe una queja de un operador. Envía un aviso interno de prueba con una marca de tiempo y un identificador de petición ficticios. Comprueba si el equipo receptor puede localizar al responsable de la evaluación, pausar el trabajo correcto y dar una respuesta clara sin divulgar información sensible.

Convierte los fallos en cambios concretos: un responsable sin asignar, una exclusión que no se aplica a los reintentos o un formulario que envía la queja a la cola equivocada. Después, repite el caso afectado. Superar el ejercicio significa demostrar una respuesta ante esos casos, no probar que se ha eliminado todo posible error de selección de destinos.

¿Qué dudas suelen surgir sobre el permiso para escanear?

La relación técnica, los datos de contacto y la autorización responden a preguntas distintas. Déjalo claro cuando alguien pida ampliar un escaneo.

¿Un CNAME incluye el destino en el alcance?

Establece una relación DNS. No responde a quién opera el destino ni qué pruebas permite tu encargo sobre él. Revisa la identidad del servicio y el permiso aplicable antes de ampliar las pruebas activas. Un acuerdo válido existente puede cubrir el destino; el alias, por sí solo, no demuestra que exista ese acuerdo.

¿Una política pública de divulgación autoriza cualquier prueba?

Lee su alcance y sus condiciones reales. Una invitación a comunicar problemas es útil, pero las condiciones publicadas pueden limitar los activos, las cuentas, las técnicas o el tratamiento de datos. Consulta los límites dudosos con el contacto del programa antes de realizar pruebas activas. Nuestra guía de configuración del programa explica cómo publicar esos límites en Kit.

¿Debe cada proveedor aprobar individualmente cada evaluación?

No hay un proceso de aprobación universal para todos los proveedores. Consulta la política vigente para el servicio y el trabajo propuesto. Algunas pruebas están cubiertas por condiciones publicadas; otras necesitan un acuerdo aparte. Conserva la justificación de tu decisión para que el siguiente evaluador no tenga que reconstruirla a partir de la página principal de un proveedor.

¿Cómo ayuda Kit a definir el alcance y gestionar los informes?

Tu equipo necesita una política pública comprensible y un lugar fiable donde atender las preguntas que genere. El escáner también necesita sus propios controles de ejecución correctamente implementados.

El portal del programa de divulgación de vulnerabilidades (VDP) de Kit publica destinos incluidos en el alcance, categorías excluidas, tipos de vulnerabilidad excluidos y el texto de la política de divulgación. Puede mostrar las cláusulas de puerto seguro (Safe Harbor) de tu programa y permite a los investigadores copiar el alcance en Markdown. Utiliza esas secciones para explicar los límites del servicio permitido y dónde consultar las dudas.

El portal del investigador ofrece una vía de envío y seguimiento de informes. Asegúrate de que quienes los gestionan puedan contactar con la persona responsable de cualquier evaluación que encargue tu empresa. Un informe sobre tráfico no deseado debe llegar a alguien que pueda investigar su origen y coordinar una pausa.

Publicar el alcance en Kit no verifica la titularidad de la infraestructura, ni concede permisos sobre terceros, ni configura tu escáner, ni cancela sus tareas en cola. Los ajustes de alcance tampoco rechazan automáticamente los informes que quedan fuera de los límites publicados. Esas decisiones siguen correspondiendo a las personas y herramientas pertinentes.

Antes de tu próxima evaluación, relaciona el alcance publicado, el registro de permisos, la configuración de ejecución y el contacto para detener las pruebas. Comprueba un cambio de destino ficticio a lo largo de todo el proceso. El resultado útil es sencillo: tu equipo puede explicar por qué está permitido ejecutar una prueba y detenerla cuando esa explicación deja de ser válida.