Poder hacerlo no significa estar autorizado
Una aplicación responde en Internet. Una credencial permite entrar. Un hostname coincide con el wildcard incluido en un programa de divulgación. Ninguno de estos hechos demuestra por sí solo que una persona esté autorizada para realizar cualquier prueba técnicamente posible.
La autorización es una condición previa de la investigación, no una explicación que se improvisa después. Debe proceder de quien posee autoridad suficiente sobre el activo y delimitar sujetos, objetivos, sistemas, métodos, datos, tiempo y salvaguardas. La capacidad técnica puede ser mucho más amplia que el permiso.
Este capítulo estudia cómo convertir «evalúa nuestra seguridad» en una autoridad operativa verificable. No ofrece asesoría jurídica. Leyes, contratos, regulación, empleo, privacidad y jurisdicción pueden imponer obligaciones adicionales; cuando existe duda material, corresponde detener la acción afectada y obtener orientación competente.
Cinco capas que no deben colapsarse
Capacidad técnica significa que una acción puede ejecutarse: un puerto responde, una API acepta una petición o una cuenta posee privilegios.
Acceso describe una ruta o contexto disponible. Puede ser legítimo, accidental, heredado o concedido para un propósito distinto.
Autorización es el permiso de una autoridad competente para realizar actividades definidas sobre activos concretos.
Condiciones contractuales y operativas limitan cómo se ejerce el permiso: métodos, horarios, datos, carga, comunicación y parada.
Requisitos jurídicos y de terceros pueden seguir aplicándose aunque el propietario directo consienta. Una organización no puede conceder autoridad que no posee ni obligar mediante su permiso a proveedores, personas o jurisdicciones ajenas.
Desliza horizontalmente para leer el diagrama a tamaño completo.
La separación evita dos errores opuestos. El primero es pensar «si el control me deja, puedo». El segundo es suponer que cualquier incertidumbre vuelve imposible investigar. Una autorización bien construida permite actuar con decisión precisamente porque reduce ambigüedad y define qué hacer cuando aparece lo inesperado.
Quién puede autorizar
La firma o mensaje importa sólo si quien lo emite posee autoridad suficiente. Un gerente puede controlar una aplicación y no la infraestructura compartida del proveedor. Un equipo de desarrollo puede autorizar pruebas en staging, pero no sobre datos de clientes. Un cliente puede contratar un servicio sin adquirir derecho a evaluar la plataforma multi-tenant.
Antes de empezar conviene comprobar:
- identidad y rol de quien autoriza;
- entidad propietaria u operadora de cada activo;
- contratos y políticas de proveedores relevantes;
- separación entre sistema propio, arrendado, administrado y compartido;
- autoridad sobre datos, cuentas y personas que podrían verse afectadas;
- aprobaciones adicionales exigidas por regulación o gobierno interno.
Esta comprobación no requiere que el investigador resuelva por sí solo toda cuestión legal. Requiere que detecte límites de autoridad y los eleve a quien corresponda. «El cliente dijo que sí» no sustituye verificar qué controla realmente el cliente.
Scope: una frontera multidimensional
Una lista de dominios o direcciones IP es necesaria en muchas evaluaciones, pero raramente suficiente. El alcance debe responder varias dimensiones a la vez:
Desliza horizontalmente para consultar todas las columnas.
Desliza horizontalmente para leer el diagrama a tamaño completo.
Los identificadores deben ser suficientemente estables y no ambiguos. Un wildcard DNS puede incluir nombres que apuntan a infraestructura ajena. Un bloque IP puede cambiar de propietario o contener servicios multi-tenant. Un nombre de aplicación puede abarcar producción y sandbox. El documento debe expresar precedencia cuando las fuentes difieren: por ejemplo, si el portal muestra un activo que el contrato excluye.
Las exclusiones merecen la misma precisión que las inclusiones. «Sin denegación de servicio» puede dejar dudas sobre pruebas de límite, cargas accidentales o algoritmos costosos. Es mejor definir acciones prohibidas, umbrales, método para pruebas potencialmente disruptivas y aprobación adicional necesaria.
Rules of Engagement: hacer operable el permiso
NIST define las Rules of Engagement (ROE) como directrices y restricciones detalladas, establecidas antes de la prueba, que conceden al equipo autoridad para actividades definidas. NIST, Rules of Engagement
Una ROE madura incluye propósito, scope, supuestos, limitaciones, riesgos, personal, contactos y calendario. NIST SP 800-115, apéndice B También debe cubrir:
- canales y frecuencia de comunicación;
- origen identificable del tráfico cuando corresponda;
- credenciales y datos de prueba;
- coordinación con SOC, operaciones e incident response;
- métodos que requieren aprobación just in time;
- criterios de éxito y evidencia mínima;
- manejo de hallazgos críticos;
- stop conditions y autoridad para reanudar;
- restauración y limpieza de artefactos;
- formato, clasificación, retención y destinatarios del informe.
El objetivo no es producir un contrato interminable. Es resolver por anticipado decisiones que, durante una prueba, podrían tomarse bajo presión y con información incompleta. Las ROE también protegen la calidad de la evidencia: permiten distinguir actividad autorizada de un incidente real y documentar qué ocurrió.
Permitido, condicionado, prohibido y no adjudicado
Un catálogo binario de «sí/no» puede ocultar actividades que requieren condiciones adicionales. Resulta útil clasificar:
- permitido: puede ejecutarse dentro de límites ya definidos;
- condicionado: necesita aviso, ventana, cuenta, entorno o aprobación específica;
- prohibido: no debe realizarse bajo la autorización actual;
- no adjudicado: el documento no permite concluir y se requiere aclaración.
«No adjudicado» no es una invitación a elegir. Si una actividad puede afectar materialmente datos, terceros o disponibilidad, el silencio no equivale a consentimiento. Tampoco debe usarse una acción menos visible para obtener el mismo efecto que una acción prohibida: importa la sustancia, no el nombre de la técnica.
Esta clasificación puede vincular cada método con un propósito. Si el objetivo es verificar aislamiento entre dos cuentas de prueba, leer una fila sintética puede bastar. Descargar una tabla real completa añade daño sin aportar evidencia proporcional.
Minimización: demostrar sin ampliar el daño
La evidencia debe ser suficiente para sostener el hallazgo, no máxima. Cuando una respuesta revela datos no previstos, se puede documentar estructura, identificador controlado, cantidad mínima y condiciones de acceso sin continuar recorriendo registros.
La minimización cubre:
- número de registros consultados;
- categorías de datos observadas;
- contenido incluido en capturas y logs;
- tiempo de retención;
- personas con acceso;
- copias locales y servicios de colaboración;
- saneamiento antes de compartir;
- eliminación y confirmación al cerrar.
Datos personales, secretos, material clínico, financiero o de terceros pueden activar obligaciones adicionales. El investigador no debe suponer que el permiso para evaluar el sistema concede permiso ilimitado para copiar su contenido. La prueba se diseña para usar cuentas y datos sintéticos siempre que sea posible.
Terceros y servicios compartidos
Cloud, CDN, SaaS, DNS gestionado, repositorios y plataformas de identidad crean cadenas de responsabilidad. Una aplicación en scope puede delegar parte de su operación a un tercero que prohíbe pruebas o requiere notificación.
La pregunta no es sólo «¿quién posee el hostname?», sino:
- ¿quién controla el componente donde se ejecutará la acción?
- ¿quién puede verse afectado además del cliente?
- ¿qué términos y políticas gobiernan la infraestructura?
- ¿existe un entorno o método autorizado por el proveedor?
- ¿quién adjudica una duda en tiempo real?
En entornos multi-tenant, demostrar un límite roto con dos tenants de prueba suele ser preferible a acceder a otro cliente real. Si el hallazgo aparece inesperadamente sobre datos ajenos, la prioridad pasa a detener, preservar evidencia mínima y coordinar.
Caso conductor: el subdominio que termina en un SaaS
Una empresa publica *.example.com como scope. El reconocimiento identifica billing.example.com, que es CNAME de un SaaS de facturación. La página acepta una cuenta de prueba, pero una referencia modificada devuelve la factura de un usuario real. Una IP asociada pertenece además a infraestructura compartida.
El wildcard demuestra que la organización quiso incluir nombres bajo su dominio; no demuestra que pueda autorizar pruebas contra todo componente al que apunten. La cuenta de prueba autoriza su uso según propósito; no concede acceso a otros tenants. La primera respuesta inesperada aporta evidencia de un problema potencial y activa restricciones sobre datos reales.
La conducta defendible es:
- no enumerar más identificadores ni descargar facturas;
- conservar solicitud, respuesta mínima, hora y contexto de la cuenta;
- proteger o sanear los datos observados;
- contactar por el canal previsto y explicar la dependencia SaaS;
- pedir adjudicación sobre propiedad, proveedor y pasos adicionales;
- reanudar únicamente si el cambio queda documentado por autoridad competente.
El resultado puede ser que el cliente coordine con el SaaS, proporcione dos tenants de prueba o declare el componente fuera de alcance. Encontrar un límite no otorga permiso para atravesarlo.
Stop conditions: cuándo dejar de actuar
Una stop condition es una circunstancia observable que obliga a suspender una actividad o la prueba completa. Debe definirse antes y asociarse con contacto, evidencia y criterio de reanudación.
Ejemplos:
- degradación no prevista de disponibilidad o integridad;
- acceso a datos o cuentas de terceros;
- salida de activos, región o tenant autorizado;
- coste, carga o propagación por encima del umbral;
- evidencia de incidente activo que requiere deconfliction;
- persistencia o modificación no autorizada;
- pérdida del canal de emergencia;
- discrepancia sobre propiedad o alcance;
- orden del contacto autorizado.
Desliza horizontalmente para leer el diagrama a tamaño completo.
Desliza horizontalmente para leer el diagrama a tamaño completo.
Desliza horizontalmente para leer el diagrama a tamaño completo.
Desliza horizontalmente para leer el diagrama a tamaño completo.
Una parada no autoriza al investigador a «corregir» producción. Una mitigación urgente puede ser necesaria, pero debe ejecutarla o aprobarla quien tenga responsabilidad operacional. Actuar unilateralmente puede destruir evidencia, ampliar impacto o entrar en conflicto con incident response.
La reanudación también necesita condiciones. Un «continúa» informal puede no resolver qué método, activo o dato queda ahora incluido. La aclaración debe registrarse con autor, hora, cambio y límites.
Deconfliction: distinguir prueba e incidente
Una evaluación puede generar señales parecidas a actividad hostil. Deconfliction permite que personas autorizadas determinen si un evento pertenece a la prueba sin revelar innecesariamente todo el plan.
Debe existir un contacto disponible, identificadores de equipo, ventanas, fuentes y un mecanismo de emergencia. Esto no implica avisar a cada defensor si el objetivo requiere una prueba ciega; significa que alguien con autoridad puede adjudicar y detener.
Si aparece actividad que no corresponde a la prueba, el equipo no debe investigarla más allá de su autorización. Preserva lo observado y activa el procedimiento acordado. Una assessment no se convierte automáticamente en respuesta a incidentes.
VDP, bug bounty y assessment contratado
Una Vulnerability Disclosure Policy publica cómo recibir reportes y puede autorizar ciertos métodos sobre sistemas descritos. CISA BOD 20-01 exige políticas de este tipo para un ámbito concreto de agencias federales estadounidenses y destaca que deben indicar sistemas y actividades autorizadas. CISA BOD 20-01
Un bug bounty añade incentivos, elegibilidad y criterios de recompensa. Que un hallazgo sea válido no significa necesariamente que reciba pago; que no reciba recompensa tampoco determina por sí solo que la investigación fuera no autorizada. Hay que leer reglas separadas de autorización y recompensa.
Un assessment contratado posee partes identificadas, objetivos, ROE y entregables negociados. Puede permitir técnicas que una VDP pública prohíbe, pero sólo dentro de su documento. No debe inferirse scope de una campaña anterior ni de una conversación comercial.
Safe harbor y jurisdicción
El safe harbor suele expresar que una organización considera autorizada la investigación de buena fe que cumpla su política y que no iniciará o apoyará determinadas acciones. Es valioso, pero su texto y autoridad tienen límites. Puede no vincular a proveedores, plataformas, clientes o autoridades públicas.
La política del Departamento de Justicia de Estados Unidos sobre CFAA indica a fiscales federales cómo tratar investigación de seguridad de buena fe bajo condiciones definidas. DOJ, CFAA Charging Policy Es una política de acusación en una jurisdicción y materia determinadas; no reescribe contratos, derecho civil, leyes estatales, otras leyes federales ni normas de otros países.
Por ello, «actué de buena fe» no reemplaza autorización. Buena fe influye en ética, políticas y ciertos marcos, pero no garantiza inmunidad universal. Cuando la actividad cruza jurisdicciones, trata datos regulados o afecta infraestructura crítica, debe obtenerse asesoría competente.
Cambios de alcance
Los activos cambian durante una investigación. Aparecen nuevos hosts, adquisiciones, endpoints, cuentas o dependencias. La respuesta correcta no es congelar toda observación ni ampliar el scope mentalmente. Se usa un proceso de cambio:
- describir el descubrimiento sin interacción adicional innecesaria;
- identificar por qué podría ser relevante;
- evaluar riesgos de incluirlo;
- verificar propiedad y terceros;
- registrar aprobación, exclusión o condiciones;
- actualizar ROE, calendario, contactos y evidencia afectada.
Los cambios verbales durante una llamada deben confirmarse por el canal acordado. La documentación protege a todas las partes y evita que equipos diferentes operen con versiones incompatibles del scope.
La autorización también necesita procedencia
Un documento no es suficiente si no puede determinarse quién lo emitió, cuándo entró en vigor y qué versión gobierna. La autorización debe conservar procedencia: identidad y rol del aprobador, fecha, vigencia, artefacto firmado o canal autenticado, anexos aplicables y relación con contratos o políticas superiores.
Cuando existen varias fuentes —contrato, statement of work, portal de bug bounty, correo y ticket— debe definirse cuál prevalece y quién resuelve contradicciones. Una copia local obsoleta puede autorizar un activo que fue retirado; una actualización del portal puede excluir un método durante una prueba en curso. El equipo necesita un snapshot o referencia verificable de las reglas aceptadas al actuar, además de monitorear cambios que deban detener la actividad.
La trazabilidad alcanza las decisiones en tiempo real. Cada excepción o ampliación registra solicitante, aprobador, motivo, límites y expiración. «Aprobado por chat» sólo es útil si ese canal está autorizado, la identidad puede verificarse y el mensaje conserva contexto suficiente. Esta disciplina no es burocracia ornamental: permite reconstruir por qué una acción estaba permitida y evita que una autorización temporal se convierta en precedente indefinido.
Errores recurrentes
«Es público, por tanto puedo probarlo». Publicidad describe accesibilidad, no autorización.
«La credencial funciona». Autenticación demuestra un contexto; no todos los usos permitidos dentro de él.
«El cliente lo pidió». Hay que verificar autoridad sobre activos, datos y terceros.
«No estaba expresamente prohibido». El silencio material se adjudica; no se interpreta siempre a favor de la acción.
«Sólo necesito una captura más». La evidencia adicional debe ser proporcional; continuar puede aumentar daño sin cambiar la conclusión.
«Safe harbor significa inmunidad». Es un compromiso limitado por texto, parte y jurisdicción.
«Si paro, pierdo el hallazgo». Un procedimiento adecuado preserva evidencia mínima y permite coordinar sin seguir causando exposición.
Lista de control antes de actuar
Antes de una prueba, el equipo debería poder responder:
- ¿Quién autoriza y qué autoridad posee?
- ¿Qué combinación de activo, identidad, método, dato y tiempo está permitida?
- ¿Qué proveedores o terceros intervienen?
- ¿Qué acciones son condicionadas, prohibidas o no adjudicadas?
- ¿Qué evidencia mínima demuestra el objetivo?
- ¿Qué datos pueden aparecer y cómo se protegen?
- ¿Qué condiciones obligan a detenerse?
- ¿Quién responde de emergencia y quién autoriza reanudación?
- ¿Cómo se distinguen pruebas de incidentes reales?
- ¿Cómo se cambian, versionan y cierran las ROE?
No poder contestar no demuestra automáticamente ilegalidad; demuestra que la autoridad operativa está incompleta. La acción profesional es completarla antes de realizar el paso afectado.
Síntesis
La autorización no se deduce de la capacidad técnica, el acceso, una credencial ni un activo público. Proviene de una autoridad competente y se vuelve operable mediante un scope multidimensional y Rules of Engagement.
Activos, identidades, métodos, datos, tiempo y terceros deben coincidir. Las pruebas minimizan daño y evidencia. Las stop conditions devuelven decisiones inesperadas al responsable adecuado. VDP, bug bounty, assessment contratado, safe harbor y política de acusación cumplen funciones diferentes y no conceden inmunidad universal.
Una investigación rigurosa no es menos eficaz por tener límites claros. Es más reproducible, más segura y produce evidencia que puede utilizarse sin ocultar cómo fue obtenida.
Un modelo de decisión para el primer minuto
En la práctica, la dificultad no suele ser encontrar una URL, sino decidir qué significa el hallazgo antes de tocarla. Conviene separar cuatro decisiones. Primero, identificación: ¿qué activo, cuenta, tenant y proveedor están implicados? Segundo, autoridad: ¿qué persona o entidad puede permitir la actividad sobre ese activo? Tercero, acción: ¿qué observación mínima está permitida y qué resultado se busca? Cuarto, respuesta: ¿qué se hará si el resultado no coincide con el supuesto? Esta secuencia evita que un indicio técnico se convierta, por inercia, en permiso.
La ficha de decisión puede registrar una referencia de la ROE, el identificador del activo, el sujeto que actuará, el método, la ventana temporal, el dato esperado, el límite de volumen y el contacto de escalado. También debe registrar la incertidumbre: «propietario no confirmado», «tenant no distinguible» o «política vigente no comprobada». Marcar una incertidumbre no es una confesión de incompetencia; es conservar una condición que todavía no permite una decisión.
Un ejemplo aclara la diferencia. El equipo recibe una cuenta de prueba audit-reader y una instrucción de «validar aislamiento». La identidad está definida, pero siguen abiertas dos preguntas: ¿qué tenants de prueba pueden compararse y qué campos de una respuesta pueden conservarse? La primera pregunta pertenece al alcance de identidad y activo; la segunda, a datos y resultado. Hasta que ambas se adjudiquen, la cuenta no convierte una respuesta inesperada en una licencia para recorrer el sistema.
La decisión también tiene una dirección temporal. Una ROE puede autorizar una ventana el martes entre las 22:00 y las 23:00 UTC, pero una sesión iniciada antes puede seguir abierta después. El documento debe decir si la autorización cubre sólo nuevas acciones o también la conservación y cierre de una sesión existente. Del mismo modo, un cambio de proveedor, región o versión puede invalidar una suposición aunque el nombre del endpoint no cambie. La vigencia es una propiedad de la combinación concreta, no sólo del documento original.
Caso conductor: transferir sin sobreinterpretar
Volvamos al SaaS de facturación. El contacto del cliente confirma por correo que billing.example.com es suyo y pide «continuar con normalidad». Esa frase resuelve parte de la propiedad del hostname, pero no adjudica por sí sola al proveedor SaaS, a su API, a los datos de clientes ni a la infraestructura cloud subyacente. El equipo responde con una pregunta acotada: qué tenant y cuentas de prueba quedan autorizados, qué operaciones están permitidas, qué proveedor ha consentido y qué formato de evidencia se acepta. Mientras espera, conserva una única respuesta sintética saneada y detiene la consulta.
El resultado puede tener tres formas. El proveedor confirma un entorno de prueba y una ventana: la actividad pasa a permitida o condicionada con una nueva versión de la ROE. El cliente confirma que el servicio queda fuera: el hallazgo se reporta como dependencia no adjudicada, sin nuevas solicitudes. O nadie puede confirmar autoridad: la acción permanece suspendida. Ninguna de esas salidas transforma el silencio en permiso.
La transferencia debe cambiar el mecanismo, no sólo los nombres. Consideremos ahora una consola de analítica interna, operada por la misma empresa pero con datos de empleados y un conector de un tercero. La lección del SaaS se conserva —autoridad por componente, datos minimizados y parada ante sorpresa—, pero el alcance concreto cambia: la identidad es un rol interno, el tercero controla el conector y el objetivo es verificar separación de informes, no facturas. Si el estudiante aplica mecánicamente la respuesta «wildcard fuera de alcance», no ha transferido el modelo; debe reconstruir las fronteras nuevas.
Contrato de evidencia y cierre
Una evidencia útil permite a otra persona reconstruir la decisión sin recibir material reutilizable. Para cada observación se puede conservar: referencia de la ROE, timestamp y zona, identidad de prueba, activo y tenant, método autorizado, resultado mínimo, hash o identificador de artefacto saneado, decisión tomada y quién la tomó. No se conservan tokens, contraseñas, claves privadas ni cuerpos completos que no sean necesarios. La ausencia de un log no prueba ausencia de una acción; por eso el registro debe declarar qué se observó y qué quedó desconocido.
El cierre no es únicamente «el escáner terminó». Incluye retirar cuentas temporales según el procedimiento del propietario, devolver o destruir datos conforme a la retención acordada, registrar excepciones, notificar hallazgos y confirmar que no quedan tareas condicionadas abiertas. Si una stop condition dejó una investigación en estado suspendido, el expediente debe decir si se cerró, se transfirió a incident response o quedó pendiente de una nueva autorización. La persona que lee el informe debe poder distinguir un resultado negativo de una prueba que nunca pudo ejecutarse.
Tres contrastes para revisar el modelo
Autenticación frente a autorización. Una autenticación responde «qué principal presenta esta credencial»; una autorización responde «qué acción sobre qué recurso permite la autoridad bajo estas condiciones». Una credencial de lectura puede autenticar correctamente y aun así quedar fuera de la acción concreta por tenant, horario o propósito.
No adjudicado frente a prohibido. Prohibido significa que la autoridad actual excluye la actividad. No adjudicado significa que la información no permite concluir. Ambos impiden actuar, pero la remediación es distinta: el primero exige respetar el límite; el segundo exige obtener una decisión. Llamar «ilegal» a todo lo no adjudicado excede la evidencia y convierte una disciplina operativa en una conclusión jurídica.
Deconfliction frente a respuesta a incidentes. Deconfliction ofrece un canal para saber si una señal pertenece a la prueba. No concede capacidad para contener, erradicar o investigar un incidente fuera del objetivo. Si el contacto declara que hay un incidente activo, la ROE debe indicar si la evaluación se detiene y qué equipo asume la siguiente decisión.
Prueba de consistencia antes de firmar
Una revisión cruzada puede recorrer cinco preguntas: ¿cada objetivo tiene una sección que lo enseña? ¿cada mecanismo material tiene un claim atómico y una fuente? ¿cada claim importante aparece en una pregunta, un caso o una figura cuando corresponde? ¿cada figura expresa una relación que el texto necesita? ¿la conclusión es más estrecha que la evidencia, nunca más amplia? El propósito no es convertir el capítulo en checklist, sino detectar saltos de frontera.
En particular, la frase «autorizado para el dominio» debe abrirse en sus componentes. ¿Incluye subdominios gestionados por terceros? ¿producción y staging? ¿cuentas personales y de prueba? ¿lectura y modificación? ¿un límite de tasa? ¿retención de datos? Si el documento no responde, el estado correcto es no adjudicado. Una firma no rellena silenciosamente las celdas vacías.
La revisión también debe buscar contradicciones entre fuentes. Una VDP puede permitir reportar una clase de defecto mientras el proveedor SaaS prohíbe pruebas automatizadas; un contrato puede incluir el servicio, pero una ventana de mantenimiento puede suspenderlo. La ROE debe declarar precedencia o escalar la contradicción. Citar una fuente no resuelve el conflicto si no se explica qué autoridad y alcance tiene cada una.
Finalmente, el lector debe salir con una regla transferible: antes de evaluar una propiedad técnica, identifica la autoridad que puede permitir la observación, delimita la combinación de activo, identidad, método, datos, tiempo y terceros, y prepara una parada observable. Si una de esas piezas falta, el siguiente paso profesional es aclarar, no explorar más profundamente.
Esta regla vale también para los resultados negativos. Si no apareció un dato ajeno, no se concluye que el aislamiento sea perfecto; sólo que la observación autorizada no produjo ese resultado bajo esas condiciones. Si no pudo confirmarse la propiedad del proveedor, no se concluye que el servicio sea ilegal o inseguro; se registra una dependencia no adjudicada. Y si una ventana terminó antes de obtener una respuesta, el resultado correcto es prueba incompleta, no ausencia de defecto. La honestidad del informe empieza en la frontera de lo que estaba permitido observar.
El mismo cuidado aplica al lenguaje de cierre. «Permitido» describe una decisión de alcance; «seguro» sería una conclusión mucho más amplia. «Detenido» describe una transición operativa; no prueba que el impacto haya desaparecido. «Reportado» describe entrega de evidencia; no prueba remediación. Mantener estos verbos separados permite que el capítulo prepare la observación y la inferencia posteriores sin adelantarlas ni mezclarlas con una conclusión jurídica.
Comprobación de comprensión
- ¿Por qué capacidad técnica, acceso y autorización no son equivalentes?
- ¿Qué debe verificarse sobre la persona que concede permiso?
- ¿Por qué un wildcard DNS puede ser insuficiente para definir scope?
- ¿Qué diferencia hay entre scope y Rules of Engagement?
- ¿Cuándo una actividad debería clasificarse como condicionada o no adjudicada?
- ¿Por qué una cuenta de prueba no autoriza acceso a otros tenants?
- ¿Qué debe ocurrir después de activar una stop condition?
- ¿Qué límites posee un safe harbor?
Problema de transferencia
Una consultora recibe autorización escrita para evaluar una aplicación web de producción durante una semana. El documento lista el dominio, pero no menciona la API móvil, el proveedor de pagos, datos personales, límites de carga ni cuentas de prueba. Durante el primer día descubre que la API acepta el token web y que una consulta devuelve datos de otro cliente.
Identifica qué está autorizado, condicionado, no adjudicado o debe detenerse. Redacta las preguntas que enviarías al contacto, la evidencia mínima que conservarías, las stop conditions faltantes y una enmienda de scope que permitiría continuar de forma controlada.
Fuentes principales
- Karen Scarfone et al. NIST SP 800-115: Technical Guide to Information Security Testing and Assessment.
- NIST CSRC Rules of Engagement.
- CISA Binding Operational Directive 20-01.
- CISA Vulnerability Disclosure Policy Template.
- U.S. Department of Justice Justice Manual §9-48.000: Computer Fraud and Abuse Act.
- 18 U.S.C. §1030.