Qué debe incluir el alcance de un pentest empresarial
Por Carlos Isidoro De Ayala Diaz ·
Activos, permisos, límites, evidencias y entregables que conviene acordar antes de una prueba de penetración autorizada.
Define la pregunta que necesita responder la prueba
Un pentest simula ataques autorizados y controlados para comprobar vulnerabilidades en un alcance. La pregunta puede referirse a permisos de una aplicación, exposición de un servicio o consecuencias de un acceso limitado. Definirla ayuda a elegir qué activos y condiciones deben incluirse. Una petición genérica de revisar toda la seguridad no permite comparar propuestas con precisión.
El resultado debe interpretarse según lo evaluado. Una prueba sobre una aplicación no acredita el estado de toda la infraestructura. Tampoco garantiza que no existan otros fallos o que no aparezcan después. Es importante que estas limitaciones se expliquen al principio y permanezcan visibles en el informe.
Identifica activos y autorización
El alcance necesita nombres o identificadores de sistemas, responsables y autorización suficiente. Deben aclararse entornos compartidos o de terceros. Que una aplicación utilice un servicio externo no autoriza a probarlo. Si aparece un activo relacionado durante el trabajo, su inclusión requiere una decisión explícita.
También se acuerdan cuentas de prueba, información disponible y restricciones. Las modalidades no se presuponen por utilizar la palabra pentesting. La propuesta especificará las modalidades, el alcance, las actuaciones de corrección y si incluye una segunda comprobación. Esta frase distingue tareas que pueden tener objetivos y costes diferentes.
Prepara reglas de ejecución y comunicación
Fechas, ventanas, contactos y condiciones de parada permiten coordinar la actividad con el negocio. Una actuación que pueda afectar disponibilidad o datos necesita condiciones específicas. Debe existir un canal para comunicar una situación relevante y una persona con capacidad para decidir cómo continuar.
Las evidencias se limitan a lo necesario para acreditar hallazgos. Se acuerdan protección, entrega y conservación, evitando redistribuir secretos o datos personales sin necesidad. El informe debe permitir comprender el problema sin exponer más información de la imprescindible.
Separa informe, corrección y segunda comprobación
El informe identifica hallazgos, impacto, prioridades y recomendaciones. Aplicar una corrección puede corresponder a otro equipo o proveedor. Una segunda comprobación verifica cambios dentro de un alcance acordado; no se da por realizada porque se haya comunicado que el problema está resuelto.
Para una empresa de Murcia o de cualquier otra provincia, la preparación puede comenzar describiendo sistemas y objetivo sin enviar credenciales en la consulta inicial. Después se fija un canal de intercambio y una propuesta concreta. Un alcance claro ayuda a entender qué se contrata y qué conclusiones podrá sostener el resultado.
Acordar profundidad y modalidad evita expectativas incorrectas
Una evaluación externa, una revisión con credenciales y una prueba sobre código disponible ofrecen perspectivas distintas. La modalidad adecuada depende de la pregunta, del estado del sistema y de la información que pueda facilitar el propietario. No debe deducirse que todas están incluidas por defecto. La propuesta especifica qué acceso recibe el equipo, qué funciones o perfiles se revisan y qué limitaciones pueden reducir la cobertura.
El tiempo disponible también condiciona la profundidad. El número de activos no explica por sí solo el esfuerzo: una aplicación con varios roles, integraciones y flujos sensibles puede exigir más trabajo que varios servicios sencillos. Para comparar propuestas conviene pedir el inventario cubierto, las actividades previstas y los entregables, además del número de jornadas o del precio total.
Define tratamiento de datos y escalado de hallazgos críticos
Las pruebas pueden producir capturas, registros o muestras que contienen información sensible. Antes de empezar se determina qué evidencia puede conservarse, cómo se cifra, quién puede acceder y cuándo se elimina. Si basta con demostrar acceso a un registro, no es necesario extraer una base completa. El informe puede anonimizar valores sin perder la capacidad de reproducir el problema.
También se acuerda un canal urgente para hallazgos que no deban esperar al informe final. La comunicación temprana incluye la evidencia imprescindible, el activo y una recomendación inicial, sin ejecutar cambios fuera de alcance. El cliente decide con sus responsables operativos cómo contener el riesgo. Esta coordinación reduce demoras y mantiene la separación entre evaluación autorizada y administración del sistema.
Prepara la corrección para que pueda verificarse
Una recomendación útil identifica la causa y el control esperado, pero su aplicación debe adaptarse a la tecnología y probarse con el proveedor o equipo responsable. Ocultar un mensaje o bloquear una ruta concreta puede no corregir el problema subyacente. Por eso se relaciona cada hallazgo con evidencias, activos afectados y una forma razonable de comprobar el cambio.
En una segunda comprobación se revisan los hallazgos acordados y se registra su estado. Un resultado corregido significa que la prueba correspondiente ya no reproduce el comportamiento en las condiciones revisadas; no certifica todo el entorno ni cubre cambios ajenos. El documento de cierre conserva fecha, versión y límites para que dirección pueda interpretar correctamente la evidencia.