Definir la decisión antes que la lista de pruebas
Una evaluación necesita un objetivo que pueda discutirse. “Queremos revisar el sistema” deja abiertas preguntas sobre superficie, profundidad y resultado. En cambio, “queremos revisar la separación entre organizaciones antes de ofrecer exportaciones” identifica una función, un límite de acceso y un momento del producto.
Ese objetivo no debe excluir otros problemas por comodidad. Ayuda a explicar por qué ciertos recorridos tienen prioridad y qué información necesita el equipo evaluador. Si la revisión responde a un requisito comercial, conviene pedir al comprador qué documento espera y sobre qué activos.
Construir un inventario inicial
Prepará una lista de aplicaciones, APIs y dominios propios. Para cada uno, anotá entorno, versión y responsable. Separá las dependencias de terceros: una integración puede estar dentro del recorrido del producto sin que exista autorización para probar al proveedor.
Un inventario de pantallas ayuda a reconocer funciones, pero no describe por sí solo la complejidad. Una única pantalla puede permitir consultar, editar, aprobar y exportar información con distintos permisos. Esas operaciones necesitan contexto propio.
Enumerar identidades y recorridos
Listá los roles y las acciones que deberían poder realizar. Cuando el sistema aloja varias organizaciones, prepará cuentas de prueba en al menos dos organizaciones representativas del alcance. Cada una necesita recursos sintéticos propios para contrastar los accesos.
En un ejemplo ficticio de gestión documental, el alcance puede incluir un operador que consulta documentos, un administrador que invita usuarios y una descarga que debe conservar la pertenencia a la organización. La pregunta es qué combinación de identidad, recurso y operación permite el producto.
Acordar condiciones operativas
Antes del trabajo, definí ventanas, restricciones, contactos y criterios para pausar una prueba. Identificá acciones con efectos persistentes, como enviar notificaciones o modificar estados. Un entorno de prueba necesita reflejar los controles relevantes y documentar sus diferencias con producción.
Las cuentas deben funcionar antes de la evaluación. Un acceso incompleto reduce la cobertura y puede consumir la ventana prevista. Compartí documentación de la versión disponible y avisá los cambios que se producirán durante el trabajo.
Dejar explícito el resultado
La propuesta debe indicar qué se entrega: alcance, condiciones, hallazgos validados, evidencia, impacto y recomendaciones. Si se incluye revalidación, especificá qué correcciones se volverán a comprobar y cuándo estarán disponibles.
Descargá la lista de preparación y completala con información general. Los accesos y la documentación confidencial se coordinan por un canal apropiado, separado de la consulta pública.
Referencias y siguiente paso
La OWASP Web Security Testing Guide organiza áreas de prueba de aplicaciones. Para convertir esas áreas en un trabajo concreto, consultá nuestra metodología y el alcance de pentesting web.
Otras lecturas.
- Qué información ayuda a cotizar una evaluación
- Qué revisar en un informe de pentesting
- Evaluación puntual y seguimiento periódico