SOC y MDR como servicio: cuándo tiene sentido

SOC y MDR como servicio tienen sentido cuando la organización necesita detección y respuesta 24x7 pero no tiene escala para mantener un equipo interno maduro. El proveedor entrega monitoreo continuo, triaje y contención; la empresa conserva el contexto de negocio y la decisión final. La elección depende de madurez, volumen y costo total.

Pocos temas de seguridad operativa generan tanta confusión como la diferencia entre armar un SOC interno, contratar un SOC gestionado o suscribir un servicio de MDR. Las tres respuestas resuelven el mismo problema — ver y contener un ataque antes de que se vuelva incidente — pero parten de premisas de costo, escala y madurez muy distintas. Este texto separa los conceptos y muestra cómo decidir sin quedar atrapado en las etiquetas de los proveedores.

¿Qué son SOC y MDR como servicio?

Un SOC (Security Operations Center) es la función de monitorear, detectar y responder a amenazas de forma continua; MDR (Managed Detection and Response) es un servicio que entrega esa función desde afuera, combinando tecnología, telemetría y analistas de guardia. En la práctica, un SOC puede ser interno, tercerizado o híbrido — el MDR es una de las formas de tercerizarlo, enfocada en detección y respuesta activa, no solo en recolectar alertas.

La distinción que más importa no es el nombre, sino lo que cubre cada arreglo:

• SOC interno — la organización arma el equipo, opera las herramientas (SIEM, EDR, análisis de logs) y responde a los incidentes con personal propio.
• SOC gestionado (MSSP clásico) — un tercero monitorea las herramientas y reenvía alertas, pero la respuesta suele quedar del lado del cliente. Se vuelve una fábrica de tickets si el triaje es débil.
• MDR — el proveedor no solo detecta sino que conduce la respuesta: aísla un endpoint, bloquea una cuenta, contiene la amenaza y luego entrega el contexto. Es la evolución del modelo gestionado orientada a reducir el tiempo entre la alerta y la contención.

El punto ciego más común es contratar un servicio que solo genera alertas y esperar de él la madurez de uno que además responde. Detección sin respuesta devuelve el trabajo difícil a quien no tenía equipo para hacerlo.

¿Cuándo tiene sentido contratar en lugar de armar internamente?

Contratar SOC o MDR como servicio tiene sentido cuando el costo y el tiempo de construir la capacidad interna superan el valor de tenerla bajo control directo. Un SOC propio maduro exige turnos 24x7, lo que en la práctica significa contratar de seis a ocho analistas solo para cubrir la escala sin fatiga, más ingeniería de detección, gestión de plataforma y retención de talento — una superficie de costo que pocas empresas fuera del sector financiero sostienen solas.

Las señales de que el modelo como servicio tiende a compensar:

1. La operación necesita cobertura 24x7 y el volumen no justifica un equipo interno completo. El ataque no respeta el horario comercial; un equipo que solo cubre el día deja descubierta la ventana más explotada.
2. Falta ingeniería de detección madura. Comprar un SIEM es fácil; escribir, calibrar y mantener reglas de detección útiles es el trabajo real, y es donde la mayoría de los SOC internos se traba.
3. La rotación de analistas erosiona la capacidad. La seguridad operativa sufre con la alta rotación; un proveedor diluye ese riesgo entre varios clientes.
4. La empresa necesita levantar la capacidad rápido, por exigencia regulatoria, contractual o por un incidente reciente, sin esperar los meses que lleva el armado interno.
5. El costo total del interno no cierra. Sumadas personas, plataformas, capacitación y el costo de oportunidad, el modelo como servicio suele entregar más madurez por unidad invertida en las etapas iniciales.

Por otro lado, armar (o mantener) el SOC interno tiene sentido cuando el contexto de negocio es altamente específico, cuando hay una restricción regulatoria sobre dónde puede procesarse la telemetría, o cuando la organización ya alcanzó suficiente escala para que el equipo propio salga más barato que el servicio. En la mayoría de los casos, el diseño ganador es híbrido: el proveedor sostiene lo continuo y la guardia, y un equipo interno reducido mantiene el contexto, decide sobre acciones de mayor impacto y gobierna al proveedor.

SOC/MDR tercerizado o equipo interno: ¿cómo comparar?

La comparación honesta mira costo total, tiempo de maduración, cobertura y control — no solo el precio de la suscripción. La tabla resume las diferencias estructurales entre los dos extremos; el modelo híbrido, en la práctica el más adoptado, combina las columnas según el riesgo.

Ninguna columna es ganadora universal. El error es comparar solo la mensualidad del servicio con el salario de un analista — la cuenta real incluye los turnos que garantizan la escala, la plataforma, la capacitación continua y el tiempo hasta que la operación de hecho detecta algo relevante.

¿Qué exigir a un proveedor de SOC/MDR?

Exija transparencia operativa, respuesta contratada y propiedad de sus datos — sin esos tres pilares, el servicio se vuelve una caja negra que usted no puede auditar ni llevarse. La calidad de un proveedor está menos en el marketing y más en lo que acepta poner por escrito. El checklist mínimo antes de firmar:

• SLA de detección y de respuesta, no solo de disponibilidad. Pregunte el tiempo medio hasta el triaje y hasta la contención, y qué pasa cuando se incumple. "Uptime de la plataforma" no protege a nadie.
• Cobertura de técnicas mapeada en MITRE ATT&CK. Un proveedor serio muestra qué tácticas y técnicas detecta y dónde están las brechas, en vez de prometer detectar "todo".
• Respuesta activa definida. Deje claro qué puede hacer el proveedor por sí solo (aislar un endpoint, bloquear una cuenta) y qué exige aprobación. La ambigüedad aquí cuesta minutos preciosos durante un incidente.
• Threat intelligence accionable y regionalizada. La inteligencia genérica genera ruido; la que importa está contextualizada para su sector y para el escenario de amenazas que de hecho golpea operaciones en Brasil y América Latina.
• Modelo cogestionado y sin aprisionamiento. Usted debe conservar acceso a los datos crudos, a las reglas de detección y al historial. Si salir del contrato significa perder todo, el costo de cambio se vuelve una jaula.
• Propiedad y residencia de los datos. Defina por contrato dónde se almacena y procesa la telemetría y quién puede acceder — punto crítico para la protección de datos y para datos bajo regulación sectorial.
• Reportes que sostienen decisiones, no vanidad. Métricas de tiempo de respuesta, incidentes contenidos y evolución de cobertura valen más que un conteo de alertas.
• Integración con su proceso de respuesta. El proveedor debe encajar en su plan de respuesta a incidentes y en sus canales, no imponer un flujo aislado que nadie internamente sigue.

¿Cómo se conecta SOC/MDR con compliance y regulación?

La detección y respuesta continuas son, cada vez más, un requisito regulatorio — no solo buena práctica. Las instituciones bajo supervisión del sector financiero deben demostrar capacidad de monitoreo y respuesta a incidentes cibernéticos; las resoluciones del BACEN/CMN sobre seguridad cibernética, incluida la 4.893, establecen exigencias de política, detección y comunicación de incidentes que un SOC/MDR ayuda a sostener. Lo mismo aplica a las operaciones de pago y a quien procesa datos bajo regulación de protección de datos, donde el tiempo de detección influye directamente en la capacidad de contener la fuga y de comunicar dentro del plazo.

Un servicio de detección bien diseñado alimenta el resto del programa de seguridad. Aporta evidencia de monitoreo para auditorías de adecuación a ISO 27001, sostiene los requisitos de respuesta a incidentes exigidos por PCI DSS, y refuerza la gobernanza de datos personales en el trabajo de adecuación a la LGPD. Para organizaciones con exposición europea, los mismos controles conversan con las obligaciones de reporte de incidentes de la directiva NIS2. El SOC no es una isla operativa — es la capa que genera la evidencia viva de que los controles de las normas realmente funcionan en el día a día.

Cómo lo ejecuta Berghem

Berghem trata la detección y respuesta como una capacidad que debe ser inteligente, no solo continua. El punto de partida de nuestro servicio de threat intelligence y detección no es el volumen de alertas, sino el modelo de amenaza de cada cliente: qué adversarios tienen motivo para atacar esa operación, qué técnicas usan y dónde una falla tendría el mayor impacto en el negocio. A partir de ahí, la ingeniería de detección se calibra para lo que importa — porque un panel que grita ante cada evento es un panel que el equipo aprende a ignorar.

El trabajo se apoya en tres principios. El primero es la inteligencia regionalizada: mapeamos las técnicas en MITRE ATT&CK y priorizamos las amenazas que de hecho golpean operaciones en Brasil y América Latina, en vez de importar escenarios genéricos. El segundo es la integración con el resto del programa de seguridad — la detección conversa con los ejercicios de Red Team que validan si los controles realmente disparan, con el pentest de red y el pentest de cloud que reducen la superficie monitoreada, y con la línea de compliance cuando hay una norma en juego. El tercero es la transparencia: usted conserva acceso al contexto, a las reglas y a las evidencias, sin caja negra.

Somos una empresa de seguridad de la información en São Paulo, y el servicio se conecta al portafolio según el riesgo lo justifique, del pentest de API a la seguridad en Open Finance. Cada entrega prioriza el impacto al negocio sobre el conteo de alertas, con una metodología reconocida sosteniendo cada etapa.

Preguntas frecuentes

¿Cuál es la diferencia entre SOC gestionado y MDR?

Un SOC gestionado clásico monitorea sus herramientas y reenvía alertas, dejándole la respuesta a usted; el MDR va más allá y conduce la contención — aísla un endpoint, bloquea una cuenta, contiene la amenaza — antes de entregar el contexto. La diferencia práctica está en el tiempo entre la alerta y la acción.

¿SOC como servicio sustituye al equipo interno de seguridad?

No lo sustituye, lo complementa. El proveedor sostiene la guardia 24x7 y la ingeniería de detección que exigen escala, pero el contexto de negocio, la decisión sobre acciones de mayor impacto y la gobernanza del propio proveedor deben quedar del lado de la organización. El diseño más eficaz suele ser híbrido.

¿Cómo evitar el aprisionamiento (lock-in) a un proveedor de MDR?

Defina en el contrato, antes de firmar, que usted conserva acceso a los datos crudos, a las reglas de detección y al historial, además de residencia de datos compatible con la regulación. Exija que la telemetría y las detecciones sean exportables. Si terminar el contrato significa perder todo, el cambio se vuelve una jaula.

Para diseñar detección y respuesta calibradas a su modelo de amenaza, conozca el servicio de threat intelligence y detección de Berghem.