Qué es un pentest y cuándo conviene hacerlo

Un pentest —prueba de penetración— es un ejercicio ofensivo controlado: un especialista intenta entrar a tus sistemas usando las mismas técnicas que usaría un atacante real, dentro de un alcance acordado, en una ventana de tiempo definida y con autorización formal por escrito. Al final entrega un informe con lo que consiguió y cómo lo consiguió.

La diferencia con todo lo que se le parece está en la pregunta que responde. Un escáner responde qué debilidades tienes. Un pentest responde algo distinto y más incómodo: cuáles de esas debilidades alguien puede encadenar, una detrás de otra, hasta llegar a un dato o un sistema que te importa.

Qué lo distingue de un escaneo

Un escaneo de vulnerabilidades es automático: compara versiones y configuraciones contra bases de fallas conocidas y devuelve una lista larga, ordenada por severidad técnica. Es barato, se puede repetir todas las semanas y es la base de cualquier programa serio.

Un pentest es manual y creativo. El valor no está en encontrar la falla —eso ya lo hizo el escáner— sino en demostrar el camino: una contraseña débil en un servicio secundario, que da acceso a una red donde nadie segmentó, donde hay una credencial guardada en un archivo, que abre el sistema que factura. Ninguna de esas tres cosas es crítica por separado; juntas son un incidente.

Qué se puede probar

Perímetro externo

Lo que se ve desde internet sin credenciales: sitios, correo, VPN, servicios expuestos. Suele ser el punto de partida porque es la superficie que cualquiera puede intentar, todos los días, sin que te enteres.

Red interna

Simula a alguien que ya está adentro: un equipo comprometido por phishing, un contratista con acceso, un notebook robado. Responde qué tan lejos llega alguien desde una posición que en la práctica no es difícil de conseguir.

Aplicación web o API

Prueba la lógica del software, no la infraestructura: permisos que no se validan en el servidor, un identificador que se cambia en la URL para ver datos de otro cliente, campos que aceptan lo que no deberían. Es justamente lo que un escáner peor detecta.

Ingeniería social

Correos de phishing dirigidos o llamadas al soporte para intentar un cambio de contraseña. Prueba a las personas y a los procedimientos, y obliga a acordar antes cómo se informa el resultado sin exponer a nadie.

Caja negra, gris y blanca: cuánta información se entrega

La otra mitad de la definición del alcance es cuánto se le cuenta al especialista antes de empezar. Es la decisión que más mueve el precio y el resultado, y viene con tres nombres que van a aparecer en cualquier propuesta.

Caja negra

Parte sin información, como un atacante cualquiera: solo el nombre de la empresa o un rango de direcciones. Es el escenario más realista, pero buena parte del tiempo contratado se va en reconocimiento, y puede terminar sin llegar a lo que más te importa.

Caja gris

Parte con información parcial: credenciales de un usuario común, un diagrama de red o la documentación de una API. Es la opción más frecuente en empresas medianas, porque concentra las horas en probar en vez de en descubrir lo que igual le habrías podido decir.

Caja blanca

Acceso completo: código fuente, configuraciones, credenciales de administrador. Encuentra más y más hondo, sobre todo en aplicaciones propias, pero se parece menos a un ataque real. Sirve cuando lo que se busca es cobertura, no realismo.

Cómo elegir entre las tres

Más ciego no significa más riguroso, que es la confusión más común al comparar propuestas. Cambiar de caja no cambia qué tan exigente es la prueba: cambia qué pregunta responde. La caja negra mide qué tan expuesto estás ante alguien sin ventaja; la blanca mide cuántos problemas tienes en total.

Con presupuesto acotado —que es el caso de casi toda mediana empresa— la caja gris suele rendir más: se paga por explotación y no por reconocimiento. La caja negra tiene sentido cuando la pregunta es exactamente esa, qué tan fácil es entrar desde afuera. La blanca, cuando se prueba una aplicación propia y se quiere encontrar todo lo posible antes de exponerla.

Un detalle que conviene fijar en el contrato: qué pasa si la caja negra se atasca. Lo razonable es acordar de antemano que, pasado cierto punto, se entrega información y el ejercicio continúa en caja gris — así el presupuesto no se agota en la puerta de entrada.

Cuándo conviene y cuándo es plata mal gastada

Un pentest rinde cuando ya existe el proceso que va a recibir los hallazgos: inventario de activos actualizado, escaneos corriendo y parchado con dueños y plazos. Sin eso, el informe va a listar cosas que un escáner básico habría dicho por una fracción del costo, y va a quedar archivado porque nadie tiene cómo cerrarlas.

Los momentos en que sí conviene son concretos: antes de una certificación o de la auditoría de un cliente grande; después de un cambio de arquitectura relevante, como publicar una aplicación nueva o migrar a la nube; cuando un contrato lo exige de forma explícita; o cuando la gerencia necesita saber si los controles que ya paga resisten a alguien que se esfuerza.

Y hay un caso en que directamente no conviene: contratarlo para tener el informe. Un pentest que no se cierra deja a la empresa igual de expuesta, pero con un registro escrito de que lo sabía.

Qué exigir en la propuesta y en el informe

En la propuesta: el alcance exacto —qué direcciones, qué aplicaciones, qué queda fuera—, la ventana de ejecución, las reglas de enfrentamiento (hasta dónde puede llegar el especialista y qué no puede tocar), un contacto de emergencia por si algo se cae y la autorización firmada. Sin ese documento no es un pentest: es un acceso no autorizado.

En el informe: para cada hallazgo, el camino reproducible que se siguió, la evidencia de que funcionó y el impacto en términos de negocio, no solo un puntaje técnico. Un resumen ejecutivo que la gerencia pueda leer sin traducción, y una priorización que distinga lo urgente de lo que puede esperar al trimestre.

Y el punto que más se olvida al firmar: el retest. Verificar que lo remediado quedó cerrado, incluido en el precio y con fecha comprometida. Si no está, el ciclo termina en una lista de tareas sin comprobación.

Cómo se conecta con la norma chilena

Ni la Ley 21.719 ni la Ley 21.663 exigen un pentest con ese nombre. Lo que la Ley 21.719 exige son medidas de seguridad proporcionales al riesgo del tratamiento, y para una empresa que trata volúmenes grandes de datos personales o datos sensibles, probar los controles en vez de solo declararlos es parte de sostener esa proporcionalidad.

Donde el pentest aparece con nombre propio es en los contratos. Los cuestionarios de seguridad de clientes corporativos, las bases de licitación y los procesos de certificación ISO 27001 preguntan por pruebas de seguridad periódicas y por la evidencia de que los hallazgos se cerraron. Ahí lo que se presenta no es el informe: es el informe más el registro de remediación y el retest.

Preguntas frecuentes

¿Cada cuánto hay que hacer uno?

No hay una frecuencia universal, y anualizarlo por costumbre es un error común. Lo que manda es el cambio: una aplicación nueva expuesta a internet, una migración o un requisito contractual justifican uno; doce meses sin cambios relevantes, con escaneo y parchado corriendo, probablemente no. Lo que sí conviene mantener anual es la conversación sobre si corresponde.

¿Sirve para acreditar cumplimiento ante un cliente o un regulador?

Como parte de la evidencia, no como la evidencia completa. Lo que convence a un auditor o a un cliente corporativo es el conjunto: el informe, el registro de qué se remedió y cuándo, y el retest que confirma el cierre. Un informe con hallazgos críticos abiertos hace más daño que no tenerlo.

¿Brumaz ejecuta el pentest?

No. Brumaz dirige, define y verifica con evidencia; la ejecución la hace un tercero especializado bajo su dirección. Quien decide qué probar y quien evalúa el resultado no debería ser el mismo que vende la ejecución.