SIEM y Wazuh para bancos, aseguradoras y fintech en Honduras, El Salvador, Guatemala y Costa Rica

Un SIEM recibe los registros de sus servidores, equipos de red, firewalls, aplicaciones y servicios en la nube, los guarda en un solo lugar y los compara contra reglas. Cuando un patrón coincide, por ejemplo veinte intentos fallidos de inicio de sesión seguidos de uno exitoso, genera una alerta. El valor está en juntar fuentes que por separado no dicen nada.

El NIST describe la gestión de bitácoras en la publicación SP 800-92 como el proceso de generar, transmitir, almacenar, analizar y desechar los registros de seguridad. El mismo documento señala el problema que casi todas las organizaciones tienen: pocos recursos frente a un flujo de datos que no se detiene, y la dificultad de que alguien revise esos datos con regularidad. Un SIEM ayuda con el almacenamiento y la correlación. La revisión sigue siendo trabajo de personas.

Otra recomendación del NIST que se olvida con frecuencia es sincronizar los relojes de todos los equipos contra una misma fuente de tiempo. Sin eso, reconstruir un incidente con registros de cinco equipos distintos se vuelve adivinanza.

Ninguna de estas normas exige un producto. Piden registros, monitoreo y alguien que lo revise. Este es el resumen por país, con el artículo que puede citar en su informe interno:

Wazuh se define en su documentación como una plataforma de seguridad gratuita y de código abierto que une capacidades de XDR y SIEM. Tiene cuatro piezas: el agente que se instala en cada equipo, el servidor que analiza los eventos, el indexador que los guarda y el tablero web donde su equipo los consulta.

Además de recolectar bitácoras de equipos, aplicaciones, mensajes syslog de dispositivos de red e integraciones por API con servicios en la nube, Wazuh trae módulos de detección de vulnerabilidades, monitoreo de integridad de archivos, evaluación de configuración, detección de malware y búsqueda de amenazas. Para una cooperativa o una aseguradora mediana que hoy no tiene nada centralizado, eso es mucho por el costo de los servidores y las horas de configuración.

La evaluación de configuración conecta bien con el trabajo de hardening: Wazuh puede revisar los equipos contra una línea base y avisar cuando alguien cambia un parámetro. No sustituye la revisión inicial, pero ayuda a que la configuración segura no se pierda con el tiempo.

La guía rápida de Wazuh pone todo en un solo servidor y alcanza para unos 100 equipos con 90 días de alertas consultables. Para 1 a 25 agentes recomienda 4 vCPU, 8 GiB de RAM y 50 GB de disco. Para 51 a 100 agentes, 8 vCPU, 8 GiB y 200 GB. Más allá de eso recomienda una instalación distribuida en varios nodos. El servidor central corre sobre Linux de 64 bits.

Ese cálculo de 90 días es de alertas, no de todas las bitácoras. Por defecto Wazuh guarda solo los eventos que disparan una regla. El archivo completo de registros (las opciones logall y logall_json) viene apagado porque crece sin límite, y la propia documentación advierte sobre el consumo de disco. El borrado automático de índices tampoco viene configurado: usted define la política de retención.

Por eso conviene responder estas preguntas antes de comprar servidores. Cuántos equipos y fuentes va a conectar. Qué retención le pide su norma y dónde se va a cumplir, porque los cinco años de transacciones de la CNBS quizás ya viven en el core bancario y no tienen por qué duplicarse en el SIEM. Quién va a leer las alertas cada día. Y qué pasa con el disco cuando se active el archivo completo.

La herramienta es gratuita. El trabajo alrededor de ella no lo es, y ahí fallan muchas instalaciones.

• No lee las alertas. Si nadie las revisa, el registro de doce meses que pide la JM-98-2025 queda vacío aunque el servidor esté encendido.
• No detecta lo que no recibe. Un firewall o un servidor de base de datos que no envía registros es un punto ciego.
• Las reglas de fábrica generan ruido. Sin ajuste, el equipo deja de mirar el tablero en pocas semanas.
• No guarda todas las bitácoras por defecto ni define la retención por usted.
• No responde incidentes. Avisa. La contención, el análisis forense y el informe al supervisor siguen siendo su proceso.
• No prueba que sus controles funcionan. Para saber si una alerta salta ante un ataque real, alguien tiene que ejecutar ese ataque.

La JM-98-2025 permite expresamente un SOC interno o contratado. CONASSIF 5-24 admite centros de operaciones tercerizados. En Honduras, la Circular 025/2022 permite tercerizar la función de seguridad de la información, pero el Art. 13 la trata como tercerización significativa: hay que notificar a la CNBS 30 días calendario antes de firmar el contrato.

Un SOC 24/7 es un negocio de turnos y personal. En la región al menos cinco empresas lo venden con operación continua. Si su entidad necesita vigilancia de noche y fines de semana, compare esas ofertas por lo que entregan: qué fuentes conectan, en cuánto tiempo le avisan, quién decide la contención y qué informe recibe cada mes.

Si prefiere montar el monitoreo en casa con Wazuh, el trabajo es acotado: definir las fuentes, instalar, ajustar reglas, fijar la retención y entrenar a quien va a revisar. Toukan hace la revisión de cobertura de bitácoras y la configuración inicial, y no opera monitoreo 24/7. También puede hacer algo que un proveedor de SOC no hace sobre sí mismo: lanzar un ataque controlado durante un pentest y revisar con usted qué vio su SOC y qué no. El precio se fija después de la llamada de alcance y la entrega toma de 2 a 6 semanas según el tamaño.

Use esta lista antes de la próxima visita del supervisor o de la auditoría interna:

• Tiene un inventario de fuentes de bitácoras y sabe cuáles envían registros al SIEM y cuáles no.
• Los firewalls, el directorio activo, el correo y el core bancario están entre esas fuentes.
• Los registros identifican persona, lugar, hora y acción, como pide la CNBS en Honduras.
• Todos los equipos sincronizan la hora contra una misma fuente.
• La retención está escrita por tipo de registro y coincide con su norma local.
• Sabe dónde se guarda cada registro que pide la norma, aunque no sea en el SIEM.
• Hay una persona asignada a revisar alertas cada día hábil y un respaldo para sus ausencias.
• Las reglas se revisaron en el último trimestre para bajar falsos positivos.
• Lleva un registro de incidentes y amenazas detectados de al menos doce meses (Guatemala).
• Las acciones de los proveedores externos en sus sistemas quedan registradas.
• Probó en el último año si el SIEM detecta un ataque simulado.