¿Qué ancho de banda requiere un SOC eficiente?
¿Qué ancho de banda requiere un SOC eficiente?
En un SOC que procesa miles de eventos por segundo, el ancho de banda disponible determina si los analistas reciben alertas en tiempo real o si los datos llegan con retrasos que complican la respuesta a incidentes. La pregunta ¿Qué ancho de banda requiere un SOC eficiente? surge constantemente cuando equipos de seguridad evalúan migrar a arquitecturas híbridas o aumentar la retención de logs.
Arquitectura de un SOC y consumo de red
La mayoría de los SOC modernos combinan sensores locales, agentes en endpoints y conectores hacia plataformas SIEM en la nube o en centros de datos propios. Cada uno de estos elementos genera tráfico continuo: logs de firewall, telemetría de EDR, flujos NetFlow y consultas a bases de datos de inteligencia de amenazas. — Más información: NIST Computer Security Resource Center
El tráfico no se limita a la ingesta inicial. Los analistas ejecutan búsquedas ad-hoc, los playbooks de SOAR consultan APIs externas y los modelos de machine learning descargan actualizaciones de firmas o embeddings. Todo esto suma al ancho de banda total necesario.
Componentes que más datos generan
- Los sensores de red suelen enviar entre 150 y 400 bytes por flujo cuando se usa muestreo de 1:1000, pero en entornos con alta granularidad el volumen puede multiplicarse por diez.
- Los agentes EDR transmiten eventos de proceso y conexión cada pocos segundos; en una flota de 5000 endpoints esto puede superar los 2 GB diarios solo en telemetría cruda.
- Las integraciones con servicios de threat intelligence realizan entre 50 y 300 peticiones por minuto según el número de IOCs que se consultan en tiempo real.
Flujos de datos en plataformas SIEM
Las soluciones SIEM como Splunk Enterprise Security, Elastic SIEM o Microsoft Sentinel manejan la ingesta de forma distinta según la configuración de indexación y parsing. Splunk, por ejemplo, recomienda planificar al menos 1,2 veces el volumen de datos crudos una vez aplicadas las transformaciones y los campos extraídos.
Cuando los datos viajan desde colectores locales hasta un clúster en la nube, la compresión gzip o zstd reduce el tamaño entre un 60 y un 75 %. Aun así, la latencia de red y los reintentos por paquetes perdidos pueden elevar el consumo efectivo de ancho de banda entre un 15 y un 25 %.
Impacto del machine learning y la correlación
Los modelos de detección que se ejecutan de forma continua requieren tanto la transmisión de eventos hacia el motor de inferencia como la devolución de puntuaciones de riesgo. En configuraciones donde el modelo corre en la misma red que el SIEM, el tráfico adicional suele mantenerse por debajo del 8 % del total. Cuando el modelo se aloja en una región distinta, ese porcentaje puede subir hasta el 18 % por la latencia de ida y vuelta.
Las consultas de correlación que cruzan semanas de datos generan picos puntuales. Un analista que ejecuta una búsqueda sobre 30 días de logs de autenticación puede transferir temporalmente entre 400 MB y 1,2 GB en una sola sesión, dependiendo de la selectividad de los filtros.
Estimaciones según tamaño del entorno
Calcular el ancho de banda necesario empieza por estimar el volumen diario de datos que llegará al SIEM. La fórmula más usada en el sector divide el número de eventos por segundo entre la tasa de compresión y luego multiplica por el factor de redundancia que exige la alta disponibilidad.
| Tamaño del SOC | Eventos por segundo | GB diarios crudos | Ancho de banda recomendado |
|---|---|---|---|
| Pequeño (hasta 2000 endpoints) | 800-1500 | 35-65 | 45-70 Mbps sostenido |
| Mediano (5000-12000 endpoints) | 3500-6000 | 150-280 | 180-320 Mbps sostenido |
| Grande (más de 25000 endpoints) | 12000-25000 | 550-1100 | 650-1200 Mbps sostenido |
Estas cifras asumen que se aplica compresión en origen y que solo se reenvían los campos relevantes tras el parsing inicial. Si se decide almacenar los logs completos sin filtrado previo, los valores pueden duplicarse fácilmente.
Consideraciones de latencia y picos
- Durante incidentes graves el volumen de logs puede aumentar entre tres y seis veces por la activación de modo verbose en los sensores.
- Las actualizaciones masivas de firmas de antivirus o la ejecución de escaneos programados generan picos de entre 20 y 40 minutos que hay que absorber sin saturar el enlace.
- La replicación entre nodos de un clúster distribuido añade entre un 12 y un 18 % de tráfico adicional cuando se usa replicación síncrona.
Optimizaciones que reducen el consumo
Una de las decisiones más efectivas consiste en aplicar filtrado y agregación lo más cerca posible de la fuente. Los colectores intermedios basados en syslog-ng o Vector pueden descartar eventos repetitivos antes de que viajen por la red troncal.
El uso de protocolos ligeros como syslog sobre TLS con compresión o el envío directo mediante HTTP/2 con protobuf también ayuda. En entornos donde el enlace principal es limitado, muchos equipos optan por mantener un SIEM local ligero y replicar solo los resúmenes y alertas hacia la nube.
Políticas de retención y muestreo
Definir qué eventos se conservan a resolución completa y cuáles se agregan tras 48 horas reduce drásticamente el tráfico de ingesta continua. Algunas organizaciones aplican muestreo probabilístico del 10 % en flujos de red de baja criticidad sin perder capacidad de detección significativa.
La configuración de índices fríos en Elastic o la política de buckets en S3 de Sentinel permite mover datos antiguos a almacenamiento de menor coste sin que el ancho de banda de consulta se vea afectado de forma permanente.
Casos prácticos reales
Una empresa española del sector energético con 7800 endpoints y 42 sedes distribuidas midió durante tres meses un consumo medio de 195 Mbps para su despliegue de Elastic SIEM con 4800 EPS. Tras activar compresión zstd en los beats y filtrar eventos de baja severidad en los colectores locales, el promedio bajó a 118 Mbps sin que se perdieran detecciones relevantes.
Otro caso corresponde a un banco latinoamericano que migró parte de su SOC a Microsoft Sentinel. El enlace de 1 Gbps que conectaba su centro de datos principal con Azure se saturaba cada noche por la ingesta de logs de transacciones.
La solución consistió en desplegar Azure Arc y procesar localmente los eventos de alta frecuencia, enviando solo resúmenes y alertas. El consumo cayó un 63 % y la latencia de las alertas críticas se redujo de 14 segundos a menos de 3.
Un tercer ejemplo proviene de un proveedor de servicios gestionados que atiende a 140 clientes medianos. Mantienen un clúster Splunk on-premise con 14 indexadores y replican semanalmente los resúmenes hacia una instancia en la nube para auditorías. El enlace de 300 Mbps dedicado soporta sin problemas los 9200 EPS promedio, con picos puntuales de 410 Mbps durante campañas de phishing masivas.
Factores que suelen pasarse por alto
El tráfico de actualizaciones de los propios sensores y la descarga de nuevas reglas de detección pueden sumar varios gigabytes semanales si no se programa fuera de horas punta. Además, las conexiones de los analistas mediante VPN para acceder a la consola del SIEM generan tráfico bidireccional que rara vez se incluye en los cálculos iniciales.
Cuando se implementan modelos de machine learning que requieren reentrenamiento periódico, el envío de datasets de entrenamiento hacia instancias GPU en la nube puede consumir temporalmente decenas de gigabytes. Estos picos deben preverse en la capacidad del enlace o ejecutarse mediante enlaces secundarios de menor prioridad.
¿Qué ancho de banda requiere un SOC eficiente?
La respuesta depende del volumen real de eventos, la estrategia de filtrado y la arquitectura elegida. Un SOC eficiente no busca necesariamente el enlace más rápido, sino el que mantiene márgenes suficientes para absorber picos sin degradar la capacidad de respuesta. Planificar con datos medidos durante al menos cuatro semanas y aplicar compresión y filtrado en origen suele ser la combinación que ofrece mejor relación entre coste y rendimiento.
Revisar periódicamente los patrones de tráfico permite ajustar las políticas de muestreo y retención antes de que el crecimiento orgánico del entorno obligue a contratar más capacidad de red.
Si quieres conocer otros artículos parecidos a ¿Qué ancho de banda requiere un SOC eficiente? puedes visitar la categoría Ciberseguridad.
Entradas Relacionadas