Ir al contenido

Cierre de la evaluación

Por

Madurezreviewed
Última revisión
Publicado
Última actualización

El cierre empieza antes de terminar la última prueba. Las notas, la lista de cambios y las evidencias se preparan durante toda la evaluación para poder retirar artefactos, explicar limitaciones y entregar un informe defendible.

Un cierre apresurado deja dos clases de deuda. La primera vive en el entorno, como una cuenta, un túnel o una regla que nadie retiró. La segunda vive en el conocimiento, cuando una captura ya no puede relacionarse con el activo o una limitación desaparece del informe. Ambas se evitan manteniendo estado durante la ejecución.

Antes de enviar la notificación de fin, confirma que se han recuperado las salidas necesarias de sistemas del cliente, que cada hallazgo tiene evidencia suficiente y que las limitaciones están registradas. Una vez cerrado el acceso puede ser imposible reconstruir una petición, una versión o una ruta.

El fin de las pruebas debe tener una hora clara. Las acciones posteriores se limitan a lo acordado, como limpieza, aclaraciones o retest.

Revisa el inventario de cambios y retira:

  • herramientas, scripts y payloads subidos
  • cuentas, claves y credenciales creadas para la prueba
  • tareas, servicios, procesos y mecanismos de persistencia
  • archivos temporales y datos sintéticos
  • cambios de configuración autorizados
  • túneles, listeners y recursos de infraestructura auxiliares

Registra el resultado de cada acción. Si un sistema ya no es accesible o retirar algo podría causar más riesgo, informa al cliente con la ubicación y el procedimiento recomendado. Incluso los cambios revertidos aparecen en el apéndice correspondiente para que una alerta posterior pueda atribuirse a la evaluación.

La limpieza puede fallar por propagación o por pérdida de la posición que creó el cambio. Marcarla como verified exige observar el estado final desde la perspectiva adecuada. Si esa comprobación no es posible, la tarea queda blocked y se transfiere con propietario, evidencia y procedimiento.

El primer entregable suele ser un borrador. Debe permitir que el cliente compruebe hechos, propietarios y contexto sin negociar la evidencia técnica. Un informe útil incluye:

  • alcance, fechas, metodología y limitaciones
  • resumen ejecutivo comprensible sin detalle de explotación
  • hallazgos con riesgo contextual, evidencia y causa
  • pasos de reproducción proporcionados
  • recomendaciones verificables y priorizadas
  • cadena de ataque cuando exista
  • apéndices de activos, servicios, cuentas, cambios y artefactos relevantes

La reunión de revisión no consiste en leer el documento. Se utiliza para resolver preguntas, explicar encadenamientos, corregir errores factuales y confirmar el siguiente paso. Después se emite la versión final conforme al proceso de aceptación acordado.

El pentester debe mantener independencia respecto a la evaluación. Esto no obliga a escribir recomendaciones vagas. Puede explicar el control que falta, alternativas razonables y cómo verificar la corrección. Lo que no debe hacer es modificar en silencio el entorno evaluado o certificar como imparcial un cambio que él mismo implementó sin una separación de funciones acordada.

La remediación pertenece al cliente o a un servicio contratado por separado. El informe conserva la causa, no solo el payload que funcionó.

El retest comprueba los hallazgos acordados después de la remediación. Empieza revisando qué cambió y qué evidencia proporciona el cliente. Para cada hallazgo debe registrar:

  • estado original
  • corrección declarada
  • prueba realizada
  • resultado actual
  • estado final y limitaciones

Que la PoC original falle no siempre demuestra remediación. Hay que comprobar que la condición subyacente desapareció y que no existe una variante equivalente dentro del alcance del retest.

Los periodos y métodos proceden del contrato, la política de la empresa y las obligaciones aplicables. La evidencia retenida permanece cifrada, con acceso limitado y una finalidad concreta. Los datos del cliente no se conservan como material personal de estudio.

Al finalizar el periodo:

  1. se destruyen copias y entornos conforme al procedimiento
  2. se registra la eliminación
  3. se conservan solo los entregables o metadatos permitidos
  4. se confirma que servicios auxiliares y accesos han sido revocados

PCI SSC recomienda acordar antes de la prueba los procedimientos de retención y destrucción, minimizar datos de tarjetas y eliminar de forma segura esos datos al concluir el encargo.

Una retrospectiva interna separa problemas técnicos, comunicación y proceso. Las cadenas de explotación importan, pero el cliente también evalúa si recibió avisos a tiempo, si entendió el informe y si el equipo trató sus sistemas y datos con cuidado.

La práctica de estas habilidades comienza en Organización y toma de notas y Cómo practicar. No se deja para el primer encargo real.