¿Hasta dónde llegaría un atacante?

Una prueba desde internet responde a preguntas distintas de las de una verificación con una cuenta interna habitual. Definimos juntos qué escenario se va a analizar y qué permisos existen al inicio. De esta situación de partida se deriva el alcance permitido. Los sistemas, las direcciones y las identidades se documentan; los servicios compartidos y los sistemas de terceros requieren una atención especial. Así, la planificación evita que la investigación sobrepase involuntariamente una autorización concedida debido a responsabilidades poco claras.

Las condiciones operativas también forman parte de la preparación. Se definen las personas de contacto, las ventanas de tiempo y los criterios de interrupción. Los cambios en los sistemas, las pruebas de carga u otras medidas adicionales no forman parte implícitamente de cualquier pentest. Deben ajustarse expresamente al procedimiento acordado. Los resultados indican después la posición de partida real y la versión verificada. Esto facilita la interpretación: una vulnerabilidad observada con derechos administrativos existentes tiene un significado distinto al de una evidencia obtenida desde un punto de partida sin privilegios.

La segmentación de red por sí sola no describe todas las posibilidades de acceso. Las cuentas de usuario, las cuentas de servicio y las vías de administración pueden establecer otras conexiones entre sistemas. Por eso, la verificación analiza, dentro del marco autorizado, si los límites técnicos y los roles hacen cumplir realmente el modelo previsto. Los errores de configuración individuales se evalúan en relación con su impacto. Un hallazgo debe mostrar por qué es relevante para su entorno y qué condiciones previas existen para el acceso demostrado.

En los entornos IaaS se añade la delimitación frente al proveedor. Los recursos y la configuración bajo responsabilidad del cliente pueden ser objeto de la investigación; esto no autoriza automáticamente los servicios de plataforma compartidos. Antes de la verificación se aclaran los derechos y los requisitos necesarios. También pueden verse afectados los emplazamientos y las aplicaciones conectados. Por eso, la planificación reúne a los responsables de cloud y de infraestructura, para que la prueba siga siendo trazable y sus efectos puedan controlarse dentro del marco acordado.

El resultado separa los hallazgos confirmados, los indicios y las áreas no verificadas. Las evidencias describen las condiciones previas necesarias y el impacto observado. Su finalidad es permitir la evaluación sin recopilar datos sensibles de forma innecesaria. La dirección y los equipos técnicos reciben una presentación adecuada a cada caso; las observaciones especialmente relevantes se comunican a través de las vías de notificación acordadas. Así, un pentest se convierte en algo más que una exportación de avisos técnicos: los responsables pueden decidir qué medidas se implementan primero.

En la corrección pueden participar varios equipos, por ejemplo, la gestión de identidades, la operación de red y el mantenimiento de aplicaciones. Por eso, las recomendaciones se comentan junto con sus dependencias. El retest se centra en la versión modificada acordada y documenta si la evidencia concreta sigue siendo posible. Para un objetivo adecuado y claramente definido puede acordarse una remuneración en función del éxito a través de Result as a Service. El alcance de prueba permitido sigue siendo vinculante y no se amplía por un incentivo económico.