Pentest de red externa para bancos, cooperativas y fintech en Centroamérica

El punto de partida es el inventario de IP públicas y dominios que usted nos entrega. Con frecuencia aparece algo que no estaba en la lista: un servidor de pruebas publicado hace años, un panel de administración de un firewall, un subdominio de un proveedor. Esos hallazgos solos ya justifican la prueba.

Sobre cada servicio que responde buscamos versiones con fallas conocidas, configuraciones débiles, credenciales por defecto y accesos que no deberían estar abiertos al público. Cuando algo parece explotable, lo intentamos dentro de los límites acordados y documentamos hasta dónde se llega.

• VPN y accesos remotos de empleados y proveedores.
• Correo, webmail y autenticación expuesta.
• Portales de clientes y sitios publicados, a nivel de servidor y configuración.
• Servicios de administración que no deberían verse desde internet.
• Configuración TLS de los servicios publicados y cabeceras de seguridad.
• Registros DNS y subdominios que apuntan a servicios olvidados o de terceros.

En Honduras, el Art. 24 de la Circular CNBS 025/2022 pide evaluaciones de seguridad y pruebas de intrusión a la plataforma tecnológica, ejecutadas por terceros. La periodicidad y el alcance se definen con base en un análisis y considerando el perfil de riesgo de los procesos a revisar. La circular no dice cuántas IP probar. Su análisis de riesgo sí debe decirlo, y conviene que el alcance del pentest lo refleje.

En El Salvador, la NRP-23 (Art. 20 i) pide pruebas de vulnerabilidad e intrusión sobre los componentes de infraestructura de tecnología, al menos una vez al año y cuando cambia esa infraestructura, y permite que las hagan proveedores. La NRP-32 (Art. 5) agrega que deben remediarse todas las brechas, empezando por las críticas y de alto riesgo.

En Guatemala, el Art. 18 de la JM-98-2025 pide pentest interno y externo con informe técnico, como mínimo una vez al año o según la exposición al riesgo tecnológico. Un pentest externo cubre una de las dos mitades. En Costa Rica, el Acuerdo CONASSIF 5-24 (Art. 33) pide a las entidades supervisadas programas anuales de análisis de vulnerabilidades y pruebas, con alcance según el riesgo. Fuera de ese sector, la prueba externa suele pedirla un cliente, un banco o PCI DSS 11.4.3.

La unidad es la IP pública con al menos un servicio respondiendo. Una IP sin puertos abiertos casi no consume tiempo. Una IP con VPN, correo y un portal sí. Por eso contamos IP activas y no el rango completo que tiene asignado.

El paquete de red externa de Toukan cubre hasta 16 IP públicas activas con 4 días de prueba manual, desde USD 3,000, con una verificación de las correcciones dentro de 90 días. Si tiene más IP, o si hay aplicaciones web que deben probarse en profundidad y no solo a nivel de servidor, se cotiza aparte o con el paquete de auditoría, que suma una aplicación web por USD 5,500.

Antes de pedir propuestas, arme una lista con cada IP o dominio, qué servicio corre, quién es el responsable y si está dentro o fuera. Envíe la misma lista a todos los proveedores. Si un servicio lo opera un tercero, como un proveedor de nube, correo o core bancario, necesita su autorización escrita antes de incluirlo.

Antes de la primera prueba se firma la autorización con las IP en alcance, las IP desde donde probaremos, la ventana horaria y un contacto que puede detener la prueba. Así su centro de monitoreo sabe qué tráfico esperar y puede distinguirlo de un ataque real.

No hacemos pruebas de denegación de servicio. Acuerde por escrito si se probarán contraseñas y con qué límite, para no bloquear cuentas reales. Si un sistema de producción responde de forma inesperada, el contacto acordado puede pausar la prueba.

Su monitoreo puede detectar la prueba, y eso también es un resultado. Si quiere medir si la detectan, avise solo a quien deba saberlo. Si prefiere evitar falsas alarmas, avise al equipo de monitoreo completo.

De la firma al informe pasan entre 2 y 4 semanas. Recibe un informe ejecutivo para la gerencia y el comité, y un informe técnico para TI. Los firma la persona que acordó el alcance con usted y dirigió la prueba.

Cada hallazgo del informe técnico dice qué IP y qué servicio, qué encontramos, la evidencia, cómo reproducirlo, el impacto y la corrección sugerida. Todos se confirman a mano. Un hallazgo sin evidencia reproducible no se puede defender ante auditoría, y no lo incluimos.

Cuando su equipo corrija, volvemos a probar dentro de los 90 días y actualizamos cada hallazgo a corregido o pendiente. La NRP-32 pide remediar todas las brechas y PCI DSS 11.4.4 pide repetir la prueba para verificar las correcciones. La verificación deja por escrito qué se corrigió de verdad.

La mayoría de los problemas aparecen antes de la prueba, no durante.

• Contratar un escaneo y llamarlo pentest. Si la propuesta no explica qué se valida a mano, pregunte.
• Dejar fuera la VPN o el correo porque los opera un proveedor. Pida la autorización del proveedor, o anote la exclusión en el informe para que auditoría la vea.
• Probar en una ventana tan corta que no alcanza. Cuatro días de prueba necesitan cuatro días hábiles de acceso.
• Recibir el informe y archivarlo. Sin seguimiento ni verificación, el siguiente pentest encuentra lo mismo.
• Asumir que la nube del proveedor está fuera. Lo que usted publica en ella sigue siendo su superficie externa.