Circular CNBS 025/2022: qué pide sobre pruebas de intrusión en Honduras

El Art. 24 se titula "Evaluaciones de seguridad y pruebas de intrusión por terceros". El texto completo dice: "Las Instituciones Supervisadas deben realizar evaluaciones de seguridad y pruebas de intrusión a su plataforma tecnológica, ejecutadas por terceros. La periodicidad y el alcance de estas evaluaciones debe definirse con base en un análisis y considerando el perfil de riesgo de los procesos a revisar."

Son dos frases cortas, pero dejan varias decisiones en manos de la institución. Leídas con cuidado, piden lo siguiente:

La CNBS no fija una frecuencia. En El Salvador, la NRP-23 pide la prueba al menos una vez al año. En Guatemala, la JM-98-2025 habla de una frecuencia mínima anual. En Honduras la frecuencia sale de su propio análisis, y eso cambia la conversación con el supervisor: no basta con tener un informe del año pasado. Hay que poder explicar por qué se probó eso y con esa frecuencia.

• Dos actividades distintas: evaluaciones de seguridad y pruebas de intrusión. Un reporte de escaneo automático difícilmente pasa por prueba de intrusión.
• Las ejecuta un tercero. Para este artículo, el área de TI no se prueba a sí misma.
• El objeto es "su plataforma tecnológica". La circular no define el término, así que su análisis debe decir qué incluye: canales digitales, aplicaciones, red externa, red interna.
• Periodicidad y alcance salen de un análisis documentado del perfil de riesgo de los procesos a revisar, no de una costumbre.

El Art. 2 es breve: "Las presentes Normas son aplicables a las Instituciones Supervisadas por la Comisión, así como a los Grupos Financieros conformados por estas." El Art. 1 agrega que se aplican "en función de su tamaño, naturaleza, complejidad de operaciones y perfil de riesgos". Un banco grande y una casa de cambio pequeña siguen la misma norma, pero no con la misma profundidad.

La definición de Grupo Financiero (Art. 3, numeral 16) muestra el abanico: además de bancos y financieras, puede incluir casas de cambio, instituciones de seguros y reaseguros, emisoras o administradoras de tarjetas de crédito, arrendadoras, casas de bolsa, remesadoras y sociedades administradoras de fondos. La resolución se comunicó a la Superintendencia de Bancos y Otras Instituciones Financieras, la Superintendencia de Seguros y la Superintendencia de Pensiones y Valores.

Los proveedores no están en el alcance directo, pero lo sienten. Los Arts. 10 a 16 obligan a la institución a gestionar a sus proveedores de TI según su criticidad. El Art. 16 a) pide contratos que permitan que la actividad del proveedor sea auditada por la institución y por la Comisión. El Art. 14 exige que el procesamiento de datos tercerizado de forma significativa se someta periódicamente a un examen de auditoría independiente del proveedor, "realizada por entes especializados". Un procesador, un centro de datos o una fintech que atiende a un banco hondureño debe esperar que le pidan evidencia.

Las cooperativas de ahorro y crédito responden a CONSUCOOP, no a la CNBS. No hemos confirmado si CONSUCOOP tiene una norma equivalente sobre pruebas de intrusión. Si su cooperativa usa la circular como referencia, la lógica del Art. 24 le sirve igual, pero no la cite como obligación propia.

El Art. 20 pide una función de seguridad de la información y ciberseguridad que "debe contar con independencia funcional y operativa respecto al área encargada de TI y del resto de las áreas usuarias". La dirige "un ejecutivo especializado con formación académica y experiencia comprobada". La institución puede tercerizar esa función, siempre bajo las reglas de tercerización de la misma norma.

Para el pentest esto tiene un efecto práctico. Quien pide la prueba, aprueba el alcance y recibe el informe debería ser la función de seguridad, no TI. TI es la parte probada y la que corrige. Mezclar los dos papeles es lo primero que una auditoría interna va a notar.

El Art. 13 considera tercerización significativa la auditoría de sistemas, la gestión de seguridad de la información, la gestión de riesgo tecnológico y la infraestructura de TI. Esa tercerización se notifica a la Comisión 30 días calendario antes de firmar el contrato. Un pentest puntual no es lo mismo que tercerizar toda la función de seguridad o de auditoría, pero confirme con su área de cumplimiento cómo encaja su contrato.

La tercera línea es auditoría interna. El Art. 39 pide, dentro de la Unidad de Auditoría Interna, un área o responsable especializado en auditoría de sistemas, con independencia de las funciones operativas y capacidad de reportar al Órgano de Administración y al Comité de Auditoría. Esa área revisará después si el pentest respondió al análisis de riesgo y si las correcciones se cerraron.

El Art. 21 obliga a notificar a la Comisión los incidentes de seguridad de la información y ciberseguridad que afecten de manera significativa la confidencialidad, integridad o disponibilidad de la información. La notificación tiene tres etapas, con plazos cortos.

El reporte final debe contener al menos "datos detallados del incidente, causa raíz, vulnerabilidades explotadas (en los casos que aplique), plan de acción ejecutado, controles preventivos que se implementarán para evitar una reincidencia, impacto económico, legal y reputacional; participaciones y comunicaciones con terceros, utilización de pólizas de seguros, entre otros."

Aquí el pentest vuelve a aparecer. Si un incidente explota una vulnerabilidad que un informe anterior ya había documentado, el reporte final tendrá que explicar por qué seguía abierta. Un registro de correcciones verificadas es la mejor respuesta a esa pregunta. Aparte, el Art. 37 pide notificar en 2 días hábiles los incidentes que afectan de manera significativa la continuidad del negocio.

La circular no trae una lista de documentos para el Art. 24. Lo que sigue es lo que una supervisión o una auditoría interna puede pedir para reconstruir la decisión y el resultado:

Las bitácoras también cuentan. El Art. 43 pide resguardar cinco años las transacciones y seis meses las consultas. Durante la prueba, anote la ventana y las IP de origen del tercero para que su monitoreo distinga la prueba de un ataque real.

Si su institución sigue presentando el informe semestral de avance del Art. 46, que vence 10 días hábiles después del cierre de cada semestre del plan, el pentest y su seguimiento son evidencia natural para ese informe.

• El análisis que fijó periodicidad y alcance, con fecha y quién lo aprobó.
• El contrato con el tercero y la autorización por escrito, con ventana de prueba y contacto para detenerla.
• El informe ejecutivo y el técnico, fechados y firmados por quien dirigió la prueba.
• El plan de corrección con responsables y fechas.
• La verificación de cada corrección, hecha por alguien distinto de quien corrigió.
• La constancia de que los resultados llegaron a las funciones de vigilancia: Riesgos, Auditoría Interna, Alta Gerencia y el comité que corresponda.

El Art. 24 habla del "perfil de riesgo de los procesos a revisar". Conviene empezar por los procesos y no por una lista de IP. Banca en línea, la aplicación móvil, transferencias, tarjetas, el core: cada uno se apoya en sistemas distintos y tiene un riesgo distinto. El orden práctico es este:

Dos ejemplos del tamaño de prueba que esto produce. Un perímetro externo de hasta 16 IP públicas activas, probado en 4 días. O una aplicación web o API con hasta 2 roles y 20 endpoints, probada en 5 días. Toukan cobra desde USD 3,000 por cualquiera de los dos, con verificación de correcciones dentro de 90 días. Red externa más una aplicación en una sola prueba parte de USD 5,500. De la firma al informe pasan de 2 a 4 semanas.

• Liste los procesos de negocio y ordénelos por riesgo, con la metodología que ya usa para riesgo operativo.
• Para cada proceso, nombre los sistemas que lo soportan: aplicación web, API, red externa, red interna, nube.
• Decida profundidad y frecuencia por sistema y escríbalo. Ese documento es el análisis que pide el artículo.
• Agende una prueba antes de cada cambio grande. El Art. 9 ya exige avisar a la Comisión 30 días antes de pasar a producción un cambio del sistema de información principal, y lo extiende a los sistemas de procesamiento de tarjetas de crédito.
• Registre lo que queda fuera y por qué. Una exclusión explicada se defiende. Una omisión no.

La circular tampoco define el contenido del informe. Por eso conviene pedirlo por escrito antes de firmar. Un informe que resiste auditoría trae el alcance exacto y lo excluido, las fechas, el nombre de quien ejecutó y quien firma, y la declaración de que lo hizo un tercero independiente de su TI.

Cada hallazgo debe decir qué activo, qué rol o acceso se usó, qué evidencia reproducible lo prueba, qué impacto tiene en el proceso de negocio y cómo se corrige. Pida también un resumen ejecutivo que el comité de riesgos pueda leer en una página, y una ronda de verificación incluida.

En Toukan el informe ejecutivo y el técnico los firma la persona que acordó el alcance y dirigió la prueba. Cada hallazgo se confirma a mano antes de entrar al informe. Firmamos acuerdo de confidencialidad cuando la institución lo pide.