Una entidad financiera puede tener un perímetro bien protegido y, aun así, mantener rutas internas capaces de comprometer cuentas, pagos o datos sensibles. Por eso, plantear el pentesting externo vs interno como una elección excluyente suele llevar a una evaluación incompleta. La cuestión relevante es qué escenarios de amenaza deben comprobarse primero, con qué alcance y cómo se traducirán los hallazgos en decisiones de riesgo, remediación y control.

En banca, crédito y fintech, una prueba de intrusión no es una demostración técnica aislada. Debe producir evidencia útil sobre la exposición real de los sistemas, la eficacia de los controles y la capacidad de limitar el impacto cuando un atacante obtiene un punto de apoyo. Esto exige combinar conocimiento técnico, entendimiento del negocio financiero y una ejecución cuidadosamente gobernada.

Qué evalúa un pentesting externo

El pentesting externo simula las acciones de un atacante que opera desde Internet sin acceso previo a la red corporativa. Su objetivo es identificar qué activos están expuestos y determinar si pueden utilizarse para obtener acceso no autorizado, elevar privilegios, extraer información o interrumpir servicios.

El alcance habitual incluye portales de banca digital, aplicaciones móviles y sus API, servicios de acceso remoto, VPN, correo electrónico, dominios, infraestructura en la nube, interfaces de proveedores y cualquier activo accesible públicamente. No basta con detectar un servidor o una versión desactualizada: la prueba debe validar si una debilidad es explotable en el contexto concreto de la organización y cuál sería su consecuencia operativa.

Para una institución financiera, este enfoque es especialmente relevante porque la superficie expuesta cambia con rapidez. Un nuevo proveedor de identidad, una API para integrar un servicio de pagos, una configuración incorrecta en cloud o un subdominio olvidado pueden crear una vía de entrada. Los atacantes no necesitan comprometer el sistema principal en el primer intento. Les basta con encontrar una pieza periférica que les permita avanzar.

Un buen ejercicio externo presta atención a vulnerabilidades de autenticación, fallos de control de acceso, exposición de información, configuraciones inseguras, errores de lógica de negocio y posibilidades de abuso en flujos transaccionales. También debe revisar la cadena de dependencias: servicios heredados, integraciones de terceros y entornos que, aunque no procesen transacciones, comparten identidades o conectividad con sistemas de mayor criticidad.

Lo que el enfoque externo puede no mostrar

Su principal limitación es que empieza con los privilegios de un desconocido. Si los controles perimetrales funcionan correctamente, el resultado puede reflejar una exposición externa reducida sin responder a una pregunta decisiva: ¿qué ocurriría si un empleado cae en una campaña de phishing, se compromete una cuenta legítima o un proveedor accede de forma indebida?

Además, el alcance externo no siempre permite observar la segmentación interna, el movimiento lateral entre redes, los permisos excesivos o las relaciones de confianza entre aplicaciones. Son aspectos que, en entornos regulados, determinan con frecuencia la magnitud final de un incidente.

Qué revela un pentesting interno

El pentesting interno parte de una posición ya situada dentro de la organización. Esa posición puede representar un equipo corporativo comprometido, una cuenta de usuario con privilegios limitados, un acceso de tercero, una conexión desde una sede o una carga de trabajo en cloud que ha sido vulnerada.

La prueba busca determinar hasta dónde puede avanzar un atacante desde ese punto inicial. Se evalúan, entre otros factores, la gestión de identidades, la segregación de funciones, la configuración de directorios, las relaciones de confianza, la segmentación de red, los privilegios locales, la exposición de credenciales y la capacidad de alcanzar activos críticos.

En el sector financiero, este escenario responde a riesgos muy concretos. Un atacante puede intentar acceder a repositorios con datos de clientes, plataformas de tesorería, entornos de desarrollo, sistemas de atención, herramientas de administración o consolas de seguridad. También puede perseguir el control de cuentas privilegiadas para modificar configuraciones, desactivar defensas o preparar un fraude con apariencia legítima.

La prueba interna permite comprobar si los controles limitan el impacto de una intrusión inicial. Por ejemplo, una cuenta de oficina no debería permitir el acceso directo a sistemas que procesan pagos. Una credencial de soporte no debería facilitar la administración de infraestructura crítica. Y una red de usuario no debería ofrecer una ruta sencilla hacia bases de datos sensibles o herramientas de gestión.

El valor de simular el movimiento lateral

Muchos incidentes graves no empiezan con una explotación sofisticada. Comienzan con credenciales válidas, configuraciones débiles o permisos acumulados con el tiempo. El pentesting interno identifica estas rutas de escalado y movimiento lateral antes de que las aproveche un adversario.

Esta evaluación es también una prueba de madurez operativa. Permite verificar si la detección responde a comportamientos sospechosos, no solo a malware conocido; si la gestión de accesos sigue el principio de mínimo privilegio; y si los equipos pueden contener una actividad anómala dentro de un segmento antes de que afecte a procesos críticos.

Pentesting externo vs interno: diferencias que importan al riesgo

La diferencia no está solo en el punto desde el que se prueba. Cada modalidad responde a una hipótesis de amenaza distinta y genera evidencias diferentes para la gestión de riesgos.

El pentesting externo responde a la pregunta: “¿Puede un atacante sin acceso previo entrar en la organización a través de lo que está expuesto?”. El interno aborda otra: “Si ya ha entrado o dispone de una identidad válida, ¿puede alcanzar activos de alto valor?”. Ambas preguntas son necesarias, pero su prioridad depende de la arquitectura, la exposición digital, el historial de incidentes y los cambios previstos en el negocio.

Una entidad con múltiples canales digitales, API abiertas y una rápida adopción de cloud debería dar especial atención al frente externo. En cambio, una organización con entornos heredados, integración compleja entre redes, un gran volumen de usuarios o acceso frecuente de terceros necesita profundizar con urgencia en la seguridad interna. En la práctica, rara vez hay razones suficientes para limitarse a uno de los dos enfoques de forma permanente.

También cambia la naturaleza de las evidencias. En una prueba externa puede ser prioritario demostrar que un error de autorización permite consultar información de otras cuentas o que una API expone datos no previstos. En una interna, la evidencia más relevante puede ser una cadena de privilegios que permite a un usuario estándar administrar servicios críticos. Ambos hallazgos requieren corrección, pero afectan a propietarios de control, plazos y planes de respuesta distintos.

Cómo decidir qué prueba priorizar

La priorización debe partir de una evaluación de riesgo, no de una lista genérica de vulnerabilidades. El CISO, el responsable de riesgos y los propietarios de procesos críticos deben acordar qué escenarios causarían mayor impacto financiero, regulatorio u operativo.

Conviene empezar por revisar los activos que procesan datos financieros, datos personales, credenciales, decisiones de crédito o transacciones. Después, hay que identificar cómo se accede a ellos desde Internet, desde redes internas, mediante identidades federadas y a través de terceros. Esta visión permite definir un alcance realista y evita pruebas centradas en sistemas de bajo valor mientras quedan fuera las rutas de mayor impacto.

La frecuencia también debe adaptarse al cambio. Un portal estable puede requerir una revisión periódica y pruebas adicionales tras modificaciones significativas. Una fintech que despliega nuevas funcionalidades, integra proveedores o modifica APIs con frecuencia necesita incorporar pruebas de seguridad en cada cambio relevante. La evaluación no sustituye la gestión continua de vulnerabilidades ni el monitoreo, pero valida aquello que un escáner no puede confirmar: la explotabilidad y el impacto de una cadena de fallos.

El alcance debe establecer reglas claras. En instituciones financieras, es esencial definir ventanas de prueba, sistemas excluidos, mecanismos de parada, contactos de escalado, tratamiento de evidencias y límites para no alterar transacciones ni afectar la disponibilidad. La disciplina metodológica protege tanto a la entidad como a sus clientes y hace que los resultados sean defendibles ante auditoría y supervisión.

De los hallazgos a la reducción de riesgo

Un informe de pentesting útil no se limita a asignar una severidad técnica. Debe explicar qué activo se ve afectado, qué prerrequisitos necesita el ataque, qué controles han fallado, qué impacto de negocio es plausible y qué acción debe realizar cada equipo.

La remediación debe priorizar las rutas de ataque completas. Corregir una vulnerabilidad individual sin retirar el permiso excesivo que permite escalar privilegios puede dejar el riesgo sustancialmente intacto. Del mismo modo, cerrar una exposición externa sin revisar las credenciales que quedaron comprometidas no elimina necesariamente la posibilidad de acceso.

Es recomendable validar las correcciones con una prueba de repetición. Esta fase confirma que el fallo se ha resuelto sin introducir regresiones y que la mitigación funciona en las condiciones reales del entorno. Para organizaciones sujetas a exigencias regulatorias, la trazabilidad entre hallazgo, propietario, fecha objetivo, evidencia de corrección y validación posterior es tan importante como el descubrimiento inicial.

AutDefend aborda estas evaluaciones con una perspectiva alineada con la realidad operativa del sector financiero: la prioridad no es acumular hallazgos, sino verificar las vías que podrían afectar a la confidencialidad de los datos, la integridad de las operaciones y la continuidad del servicio.

La decisión más prudente no es escoger entre proteger la puerta de entrada o limitar el avance dentro del edificio. Es diseñar pruebas que reflejen cómo atacaría un adversario a su entidad y convertir sus resultados en controles verificables. Cuando el pentesting se integra en la gestión de riesgos, deja de ser un requisito puntual y se convierte en una fuente concreta de preparación.