Modelos de evaluación

Expresiones como interno, black box o red team describen decisiones diferentes. Combinarlas como si fueran una sola clasificación produce encargos ambiguos. Una evaluación se define mejor separando qué se quiere comprobar, desde dónde comienza y qué información recibe el equipo.

Por ejemplo, «Red Team interno de caja negra» todavía deja sin responder si el objetivo es alcanzar una base de datos, medir la detección o validar segmentación. Tampoco indica si existe una posición de brecha asumida, si el blue team conoce el ejercicio ni qué efectos puede demostrar el operador. Las etiquetas orientan. El diseño aparece al separar cada dimensión.

Actividad	Pregunta que intenta responder	Resultado habitual
Evaluación de vulnerabilidades	¿Qué debilidades potenciales existen y cómo deben priorizarse?	Inventario analizado, cobertura, falsos positivos descartados y prioridades
Pentest	¿Qué debilidades pueden explotarse y qué impacto permiten dentro del alcance?	Hallazgos validados, cadenas de ataque y recomendaciones
Red team	¿Puede un adversario plausible alcanzar un objetivo y cómo responde la organización?	Operación reconstruida, controles superados y oportunidades de detección y respuesta
Purple team	¿Cómo pueden ofensiva y defensa mejorar juntos un conjunto de controles?	Pruebas observables, ajustes defensivos y nueva validación

Una evaluación de vulnerabilidades puede combinar escáneres, revisión de configuración y validación manual. No se define por ser automática. El pentest añade una validación controlada de explotabilidad e impacto, pero tampoco promete descubrir todos los fallos posibles. Un red team prioriza objetivos y realismo del adversario, no cobertura exhaustiva.

Una auditoría parte de criterios definidos y reúne evidencia para determinar conformidad. Puede consumir resultados de una evaluación técnica, pero no se convierte en pentest por incluir pruebas. Requisitos y estándares de evaluación separa obligación, marco, metodología y estándar técnico.

Un programa de divulgación de vulnerabilidades (vulnerability disclosure) establece cómo puede comunicarse una vulnerabilidad. Un programa de bug bounty añade normalmente recompensas y reglas de elegibilidad. Ambos mantienen alcance, canales y técnicas permitidas. La participación abierta tampoco convierte la actividad en una evaluación ilimitada. Cada investigador observa una parte de la superficie y el propietario conserva la clasificación inicial, la coordinación y la remediación.

Estas formas de trabajo pueden complementarse. Una evaluación recurrente aporta cobertura conocida. Un pentest valida rutas e impacto. Un bug bounty extiende la observación a investigadores con enfoques distintos. Una auditoría comprueba criterios. Ninguna hereda automáticamente las garantías de otra.

Una evaluación externa comienza desde una posición equivalente a Internet o a otra red no confiable. Examina la superficie expuesta y las rutas que podrían conducir hacia activos internos.

Una evaluación interna comienza dentro de una red o zona concreta. Puede usar un equipo entregado por el cliente, una VPN o una posición de brecha asumida. Su objetivo no tiene por qué ser continuar un pentest externo. También puede medir segmentación, identidad, controles de endpoint o exposición entre redes internas.

La ubicación no determina el sigilo. Un pentest externo puede ser conocido por el equipo defensor y uno interno puede pedir evasión controlada. Tampoco determina qué activos están permitidos. Una dirección alcanzable sigue fuera de alcance si no aparece en la autorización.

Los términos de caja describen cuánto conoce el equipo al comenzar, no la calidad ni la agresividad de la prueba.

Modelo	Información inicial posible	Utilidad
Black box	Dominios, rangos o un punto de entrada mínimo	Observar qué puede descubrirse con poco contexto previo
Grey box	Cuentas, roles, diagramas parciales o activos seleccionados	Dedicar más tiempo a controles y rutas relevantes
White box	Arquitectura, configuraciones, código, credenciales y responsables	Aumentar cobertura y revisar condiciones difíciles de observar desde fuera

Más información no hace la evaluación menos real. Cambia dónde se invierte el tiempo. Una prueba white box puede descubrir fallos profundos que una ventana black box no alcanzaría. Una prueba black box puede revelar problemas en el inventario o en la exposición pública que los equipos internos daban por resueltos.

El nivel de evasión es otra decisión independiente.

• Una prueba no evasiva favorece cobertura y velocidad, aunque genere alertas.
• Una prueba híbrida comienza con un perfil acordado y aumenta de forma controlada la visibilidad de las acciones.
• Una prueba evasiva intenta cumplir objetivos sin activar determinados controles y mide qué telemetría permite reconstruir la operación.

Deconfliction conecta operadores, infraestructura, identidades y marcas temporales con un grupo de control. Permite distinguir el ejercicio de un incidente real y coordinar la respuesta ante efectos inesperados.

“Pentest interno de caja gris” sigue siendo insuficiente. Faltan al menos los objetivos, los activos, las identidades, el nivel de evasión, las técnicas excluidas, la ventana y la profundidad de explotación. Alcance y reglas de enfrentamiento convierte esas decisiones en límites verificables.

El modelo también tiene límites. Dos encargos con la misma etiqueta pueden producir coberturas distintas por tiempo, madurez del entorno o acceso disponible. El informe debe describir esas condiciones y evitar comparar resultados como si la clasificación garantizara una prueba idéntica.

• ¿Por qué interno y white box no describen la misma dimensión?
• ¿Qué gana una evaluación al recibir más información del cliente?
• ¿Por qué una evaluación de vulnerabilidades no debe definirse como un simple escaneo?

• NIST SP 800-115: Technical Guide to Information Security Testing and Assessment
• OWASP Web Security Testing Guide: Introduction and Objectives
• MITRE ATT&CK: Adversary Emulation Plans