Pentesting caja negra, gris y blanca: cuál contratar según el objetivo

Respuesta rápida: la diferencia no es de dificultad sino de información entregada al equipo de pruebas, y eso determina qué compras. Caja negra compra realismo: simula a un atacante externo sin información previa. Caja blanca compra cobertura: con código fuente y credenciales se encuentra mucho más en el mismo tiempo. Caja gris es el punto medio y es lo correcto en la mayoría de los casos. Para una aplicación web con usuarios autenticados, caja gris. Para validar el perímetro expuesto, caja negra. Para código propio antes de salir a producción, caja blanca.

Las tres modalidades

El malentendido más caro

Muchas empresas contratan caja negra creyendo que es "la prueba más exigente" y terminan pagando porque un consultor dedique la primera semana a descubrir información que la propia empresa podría haberle entregado en una reunión de una hora.

En un proyecto de 10 días hábiles en caja negra, entre 3 y 4 días se consumen en reconocimiento. En caja gris esos días se invierten en profundidad. Con el mismo presupuesto, la caja gris encuentra consistentemente más hallazgos explotables.

El realismo de la caja negra tiene un valor específico y acotado: responder la pregunta "¿qué puede lograr alguien que solo conoce nuestro nombre?". Es la pregunta correcta para el perímetro. No es la pregunta correcta para una aplicación de negocio donde el escenario realista es un usuario con cuenta válida.

Cuándo corresponde cada una

Caja negra

• Validación del perímetro externo: qué está expuesto a internet y qué se puede hacer con ello
• Verificación de la superficie de ataque antes de un ejercicio de Red Team
• Requisitos contractuales o de cliente que exigen simulación sin información previa
• Evaluación de un proveedor o de un activo recién adquirido

Caja gris

• Aplicaciones web y móviles con usuarios autenticados: es el caso por defecto
• APIs, donde el escenario realista implica una credencial o token válido
• Pruebas internas desde la perspectiva de un empleado o de un equipo comprometido
• Cuando hay múltiples roles y hay que verificar control de acceso entre ellos

Este último punto es clave: los fallos de autorización — un usuario accediendo a datos de otro cambiando un identificador — son de los más frecuentes y de mayor impacto, y solo se detectan con credenciales de al menos dos perfiles distintos. En caja negra pasan desapercibidos.

Caja blanca

• Software desarrollado internamente antes de salir a producción
• Sistemas donde una falla tiene consecuencia regulatoria, financiera o física severa
• Cuando ya hubo un incidente y se necesita certeza, no muestreo
• Combinada con análisis estático de código para cobertura máxima

Lo que no cambia entre modalidades

Independiente de la modalidad, un pentesting serio incluye:

• Alcance escrito y firmado con activos, ventanas horarias, contactos de emergencia y qué está explícitamente fuera
• Explotación real, no solo escaneo. Si el informe es la salida de un escáner reordenada, no fue un pentesting
• Evidencia reproducible por hallazgo: pasos, capturas, solicitudes y respuestas
• Priorización por impacto de negocio, no por puntaje CVSS aislado
• Retest incluido después de la remediación, dentro de un plazo definido
• Comunicación inmediata de hallazgos críticos, sin esperar el informe final

Ese último punto es un buen filtro al momento de elegir proveedor: si encuentra un acceso administrativo el día 2, ¿avisa ese día o lo guarda para el informe del día 15?

Cómo lo recomendamos en la práctica

Para una empresa que nunca ha hecho pruebas:

1. Primer año: caja negra al perímetro externo + caja gris a la aplicación principal
2. Segundo año: caja gris a todas las aplicaciones críticas + prueba interna
3. Tercer año: ejercicio de Red Team con objetivos definidos

Empezar por Red Team cuando no se ha hecho nunca un pentesting es gastar bien en el momento equivocado: el ejercicio va a encontrar los mismos problemas básicos que un pentesting habría encontrado por una fracción del costo.

Más detalle sobre el alcance de nuestros servicios ofensivos en Red Team y sobre qué contiene una evaluación completa en qué incluye una auditoría de ciberseguridad.

Preguntas frecuentes

¿Cuál modalidad es "más segura" para mi sistema?

Ninguna es intrínsecamente más riesgosa. El riesgo lo controla el alcance acordado, la ventana de ejecución y las reglas de compromiso, no la cantidad de información entregada.

¿Caja blanca significa entregar mi código fuente?

Sí, bajo acuerdo de confidencialidad y con manejo controlado del repositorio. Si eso no es viable, la caja gris con documentación de arquitectura cubre buena parte del beneficio.

¿Cuánto dura un pentesting típico?

Entre 5 y 15 días hábiles según cantidad de activos, complejidad de la aplicación y modalidad. Los alcances de menos de 5 días rara vez permiten explotación real.

¿Con qué frecuencia debería hacerse?

Al menos anual para sistemas críticos, y adicionalmente ante cambios arquitectónicos relevantes o nuevas integraciones. El pentesting valida un momento, no un estado permanente.

¿Sirve como evidencia de cumplimiento?

Sí. Aporta respaldo para el proceso de gestión de riesgos de la Ley 21.663, para el principio de seguridad de la Ley 21.719 y para los controles de ISO 27001 relacionados con evaluación técnica.

¿Qué pasa si no encuentran nada?

Es poco frecuente, y cuando ocurre el informe debe explicar qué se probó y cómo, para que la ausencia de hallazgos sea una afirmación verificable y no una omisión.