Pentest de red interna y Active Directory para bancos y cooperativas en Centroamérica

Antes de empezar se acuerda el punto de partida. Lo más común es una cuenta de usuario sin privilegios y un equipo conectado a la red de oficinas, porque representa el caso que más preocupa a un comité: un empleado engañado o un equipo comprometido. También puede partir del acceso remoto de un proveedor o de un segmento de agencia.

Desde ahí se revisa si la separación entre redes funciona como dice el diagrama, si las cuentas tienen más permisos de los que su función necesita y si los sistemas críticos, como el core, las bases de datos de clientes o los servidores de pagos, quedan protegidos frente a ese punto de partida. Cada paso que se logra queda documentado con evidencia.

• Segmentación entre oficinas, agencias, servidores y redes de terceros.
• Configuración de Active Directory: permisos, cuentas de servicio, cuentas privilegiadas y relaciones de confianza.
• Servidores y equipos internos con parches pendientes o configuraciones débiles.
• Credenciales compartidas o reutilizadas entre sistemas.
• Acceso desde la red interna a los sistemas que procesan datos de clientes o dinero.

Guatemala es el caso más explícito. El Art. 18 de la JM-98-2025 pide pruebas de penetración internas y externas, con el resultado en un informe técnico, como mínimo una vez al año o según la exposición al riesgo tecnológico de la institución. Un banco guatemalteco que solo prueba su red externa deja fuera la mitad de lo que la norma nombra.

En El Salvador, la NRP-23 (Art. 20 i) pide pruebas sobre los componentes de infraestructura de tecnología al menos una vez al año, sin limitarlas a la red externa. La misma norma, en su Art. 11, pide procedimientos formales para cuentas privilegiadas y una segregación de funciones adecuada. La NRP-32 (Art. 7) exige autenticación de múltiples factores en las cuentas privilegiadas, incluidas las que poseen relación de confianza. Un pentest interno muestra si esas reglas se ven en la red real.

En Honduras, el Art. 24 de la Circular CNBS 025/2022 pide pruebas de terceros con alcance definido por un análisis de riesgo, y el Art. 20 pide que la función de seguridad sea independiente de TI. PCI DSS v4.0.1 pide en el Requisito 11.4.2 una prueba interna cada 12 meses y después de cambios significativos, desde dentro del entorno de tarjetas y hacia él desde redes internas confiables y no confiables.

La unidad de alcance no es una cifra de IP. Son los segmentos de red, las sedes, los dominios y los sistemas críticos que deben quedar dentro. Una cooperativa con una sede y un dominio no se parece a un banco con agencias en todo el país, y por eso la red interna no tiene un paquete publicado. Toukan la cotiza después de una llamada de alcance, con precio cerrado una vez acordado.

En los precios que publican proveedores de la región y de fuera, la red interna cuesta más que la externa. Hay más sistemas, más caminos posibles y más coordinación con TI. Desconfíe de una prueba interna al mismo precio que un escaneo externo.

La prueba interna toca sistemas que atienden clientes, así que la coordinación pesa más que en la externa. La autorización escrita fija los segmentos, las horas y un contacto de TI que puede pausar la prueba. Si un sistema es frágil, se marca y se prueba con más cuidado o en otra ventana.

No hacemos pruebas de denegación de servicio. Las acciones que pueden afectar cuentas reales, como bloquear usuarios, se acuerdan antes por escrito. Si el acceso es remoto, TI prepara la conexión y la cuenta de partida antes del primer día, porque ese trámite suele ser lo que más retrasa el inicio.

Si su institución tiene un centro de monitoreo propio o contratado, decida antes si quiere medir si detecta la prueba. Las dos opciones son válidas. Lo que no sirve es que nadie sepa y se escale como incidente real.

De la firma al informe pasan entre 2 y 4 semanas, según el tamaño. El informe ejecutivo le cuenta al comité, en palabras de negocio, qué se podría alcanzar desde el punto de partida y qué controles lo impidieron. El informe técnico trae cada hallazgo con el sistema, la evidencia, cómo reproducirlo y la corrección sugerida. Ambos los firma la persona que acordó el alcance y dirigió la prueba.

Todos los hallazgos se confirman a mano. Cuando su equipo corrija, volvemos a probar dentro de 90 días y marcamos cada hallazgo como corregido o pendiente. PCI DSS 11.4.4 pide exactamente eso, repetir la prueba para verificar las correcciones, y la NRP-32 pide remediar todas las brechas, no solo las críticas.

Un consejo para el seguimiento: separe la corrección reportada de la corrección verificada. En los tres países con norma, auditoría interna revisa cada año la gestión de seguridad (Art. 39 de la circular CNBS, Art. 39 de la NRP-32, Art. 7 de la JM-98-2025). La diferencia entre esas dos columnas es lo primero que suele mirar.

Casi todos se evitan en la conversación de alcance.

• Pedir una prueba interna sin decir desde dónde parte. Sin punto de partida, dos propuestas no son comparables.
• Dejar fuera las agencias porque están lejos. Una agencia de muestra suele bastar para ver si la segmentación funciona.
• Excluir Active Directory por miedo a afectarlo. Se puede revisar con cuidado y en horario acordado.
• Tratar los hallazgos de permisos como menores. En la red interna, un permiso de más suele ser el paso que conecta todo lo demás.