Un NOC (Network Operations Center, centro de operaciones de red) es el equipo que vigila que la infraestructura funcione: la red, los enlaces, los servidores, los servicios en la nube, la capacidad, los respaldos y todo lo que tiene que estar encendido para que la empresa trabaje. Su pregunta de cada día es una sola: ¿está todo arriba? Un SOC vigila otra cosa muy distinta dentro de esa misma infraestructura: si alguien está haciendo algo que no debería.
Dicho más corto: el NOC cuida que la red funcione y el SOC cuida que nadie se meta en ella.
Confundirlos no cuesta nada hasta el día que cuesta muchísimo. Casi siempre pasa lo mismo: la empresa contrata monitoreo, ve gráficas verdes durante meses y da por hecho que está cubierta. Lo que compró vigila caídas. El ataque no es una caída.
¿Qué hace exactamente un NOC?
Un NOC opera la disponibilidad. Es el turno permanente que mira los tableros de la infraestructura y actúa cuando algo se degrada o se detiene. En la práctica, se ocupa de esto:
- Disponibilidad de servidores, aplicaciones, enlaces de internet y enlaces entre sedes.
- Capacidad y rendimiento: discos que se llenan, memoria al límite, latencia que sube, un enlace saturado a la hora pico.
- Trabajos programados que fallan en silencio, empezando por los respaldos, que es el clásico que nadie nota hasta que hace falta restaurar.
- Hardware con síntomas: una fuente redundante que se murió, un disco con errores, un switch a temperatura rara.
- Certificados y licencias que vencen, actualizaciones y ventanas de mantenimiento.
- Escalamiento con proveedores: cuando el problema es del operador de telecomunicaciones, alguien tiene que abrir el ticket y perseguirlo.
El marco de referencia del que salen casi todos estos procesos no es de ciberseguridad, es de gestión de servicios de TI. Es ITIL, con su vocabulario de incidentes, problemas, cambios y niveles de servicio. Vale la pena saberlo, porque explica por qué un NOC y un SOC hablan distinto aunque miren las mismas máquinas.
¿Y qué hace un SOC que el NOC no hace?
El SOC parte de una suposición incómoda que el NOC no necesita hacer: que hay alguien del otro lado. No un componente que falló, sino una persona con un objetivo, que se esconde, que aprende de lo que le bloqueas y que prefiere que todo se vea normal.
Por eso el SOC no mira si el servidor responde. Mira quién entró, desde dónde, a qué hora, con qué cuenta, si esa cuenta suele hacer eso, si el volumen de datos que salió tiene sentido. Para eso usa SIEM, EDR, inteligencia de amenazas y caza de amenazas, y se mide con métricas propias: MTTD y MTTR, cuánto tardó en detectar y cuánto en responder.
Hay una diferencia de fondo entre las dos alarmas. La del NOC dice “algo se rompió”. La del SOC dice “puede que alguien lo haya roto a propósito, y puede que siga dentro”.
¿Cuál es la diferencia entre un NOC y un SOC?
Puestos uno al lado del otro, se ve mejor. Comparten pantallas, horarios y hasta proveedor, pero casi nada más:
| NOC | SOC | |
|---|---|---|
| Qué vigila | Que la infraestructura esté disponible y rinda | Que nadie haga algo indebido dentro de ella |
| Contra qué juega | Fallas, saturación, errores humanos, cortes del proveedor | Un adversario que decide, se adapta y se esconde |
| Qué pregunta ante una alerta | ¿Qué se rompió y cómo lo levanto? | ¿Quién hizo esto, desde cuándo y hasta dónde llegó? |
| Herramientas típicas | Monitoreo de red, gestión de tickets, herramientas de administración remota | SIEM, EDR y XDR, SOAR, inteligencia de amenazas |
| Métrica principal | Disponibilidad y tiempo de restablecimiento del servicio | Tiempo de detección y de respuesta ante un incidente |
| Primer reflejo | Restablecer el servicio cuanto antes | Contener sin destruir la evidencia |
| Cuándo termina el trabajo | Cuando el servicio vuelve a estar arriba | Cuando se confirma que el atacante ya no tiene ningún acceso |
| Perfil del equipo | Ingenieros de redes, sistemas y nube | Analistas de seguridad, forenses, cazadores de amenazas |
Las dos filas del final son las que más discusiones producen dentro de las empresas, y son las que valen la conversación.
¿Por qué los dos pueden ver la misma alerta y hacer cosas contrarias?
Imagina un servidor que a las 3:14 de la madrugada se pone lentísimo y empieza a consumir CPU sin explicación.
El NOC hace lo correcto según su oficio: aísla el síntoma, reinicia el servicio, y si no cede, reinicia el servidor. A las 3:31 el tablero vuelve a estar verde, el ticket se cierra con la nota “resuelto, se reinició el servicio” y nadie pierde el sueño. Es una buena noche de trabajo.
El SOC habría hecho lo contrario. Antes de tocar nada habría capturado la memoria del equipo, mirado qué proceso disparó el consumo, con qué cuenta se lanzó y a qué dirección de internet estaba hablando. Porque ese consumo raro es también el aspecto que tiene un proceso de cifrado empezando, o un minero, o un canal de salida de datos.
Al reiniciar, el servicio vuelve y la evidencia se va. Y si lo que había era un acceso persistente, vuelve también, solo que ahora sin rastro de cómo llegó. Las guías de respuesta a incidentes insisten en ese orden por algo: el NIST SP 800-61 pone la preservación de evidencia dentro de la contención, no después.
Ninguno de los dos equipos se equivocó. Cada uno cumplió su procedimiento. El problema es que solo había un procedimiento en la empresa, y era el de disponibilidad.
¿Se pueden juntar los dos en un solo equipo?
Se puede, y cada vez más empresas lo hacen. La convergencia tiene ventajas reales: un solo inventario de activos, una sola guardia a la que llamar de madrugada y, sobre todo, el final de esa discusión de “eso es de redes” contra “eso es de seguridad” mientras el reloj corre.
Pero juntar los dos escritorios no es juntar las dos funciones. Para que funcione hacen falta tres cosas: procesos separados para disponibilidad y para incidentes de seguridad, un criterio claro de cuándo una alerta deja de tratarse como falla y pasa a tratarse como ataque, y personas con formación en las dos cosas o al menos un puente entre ambos turnos.
Lo que no funciona, y se ve seguido, es ponerle una herramienta de seguridad encima al NOC y renombrarlo. La herramienta genera alertas que nadie está entrenado para investigar, la cola crece, y al mes se filtran las alertas ruidosas para poder trabajar. Es exactamente la alerta que después aparece subrayada en el informe forense.
¿Cuál de los dos te está faltando?
Señales de que te falta NOC: te enteras de las caídas porque llama un usuario, no sabes cuánto estuviste abajo el mes pasado, nadie revisa que los respaldos terminen bien, los enlaces se saturan siempre a la misma hora y nadie lo ha medido.
Señales de que te falta SOC: nadie mira los registros de acceso salvo cuando hay un problema, no sabrías decir si una cuenta de administrador se usó anoche, las alertas del antivirus las revisa quien tenga tiempo, y si te preguntaran hoy cuánto tardarías en detectar un intruso, la respuesta honesta sería que depende de la suerte.
¿Cuál necesita mi empresa primero?
Depende de qué te duela más, y conviene contestarlo sin épica.
Si tu operación se detiene cuando se detiene la red, si vendes o produces con sistemas que tienen que estar arriba en horario, el NOC es lo primero. Sin disponibilidad no hay negocio que defender.
Si manejas datos personales, información financiera o algo regulado, si ya tuviste un incidente o si un cliente grande empezó a preguntarte por tus controles, el SOC deja de ser opcional. Y hay un matiz que casi nadie ve: la mayoría de las empresas medianas ya tiene un NOC informal, que es su propio equipo de TI resolviendo caídas todo el día. Lo que casi ninguna tiene es a alguien mirando en la madrugada con la pregunta del SOC en la cabeza. Ese vacío es el que sale caro, porque no se nota hasta que ya pasó.
Preguntas frecuentes
¿Un NOC puede detectar un ciberataque?
¿Es lo mismo un NOC que una mesa de ayuda?
¿Qué es NOC as a Service?
¿Puede mi equipo de TI hacer de NOC y de SOC a la vez?
¿Qué le debo exigir por escrito a cada uno?
Dos centros, dos preguntas distintas
La forma más rápida de saber cuál de los dos estás mirando es escuchar qué pregunta cuando algo pasa. Si pregunta cuánto tardamos en levantarlo, es un NOC. Si pregunta desde cuándo estaba ahí, es un SOC. Las dos preguntas son necesarias y ninguna contesta la otra.
En ZetTateK administramos las dos capas: la infraestructura de red, con monitoreo continuo, segmentación y firewalls gestionados, y el SOC 24/7 gestionado que vigila lo que ocurre dentro de ella. Si no tienes claro cuál de las dos te falta hoy, el diagnóstico de seguridad sin costo es la manera más corta de averiguarlo. Los demás términos de este artículo están explicados en nuestro glosario de ciberseguridad.
Que todo esté arriba no significa que todo esté bien. Son dos preguntas, y hacen falta las dos.
