Las herramientas de operaciones de seguridad son las tecnologías que utiliza un centro de operaciones de seguridad (SOC) para recopilar datos de telemetría, detectar amenazas, investigar incidentes y responder en los terminales, la red, la identidad y cloud. Todas las listas de herramientas para SOC abarcan más o menos las mismas categorías. Casi ninguna responde a las dos preguntas que determinan los resultados: ¿detecta realmente la herramienta los ataques una vez implementada? y ¿sigue funcionando cuando un atacante intenta desactivarla? Ambas preguntas cuentan ahora con datos que las respaldan. Estudios recientes sobre detección muestran una brecha persistente entre lo que registran las herramientas y aquello sobre lo que alertan. Y en abril de 2026, MITRE ATT&CK incluyó la manipulación de herramientas como una táctica propia. Esta guía describe las categorías principales, las pruebas de lo que realmente funciona y cómo elegir herramientas de operaciones de seguridad que resistan el contacto con un atacante.
Las herramientas de operaciones de seguridad son las tecnologías integradas que utiliza un SOC para recopilar datos de telemetría, detectar amenazas, investigar alertas y responder a incidentes en los terminales, la red, la gestión de identidades y cloud. Un SOC combina estas herramientas con el personal y los procesos para llevar a cabo la supervisión, la clasificación, la investigación y la respuesta como un único sistema; ninguna herramienta por sí sola puede cubrir todas estas funciones.
Antes de nada, una aclaración. En esta guía, «SOC» significa «centro de operaciones de seguridad». No se refiere a «SOC 2», el marco de auditoría de cumplimiento, ni a la línea de productos industriales «SOC Tools», que no tiene nada que ver con este tema y que comparte el mismo nombre en los resultados de búsqueda. Los términos «herramientas SOC», «herramientas de operaciones de seguridad» y «herramientas para centros de operaciones de seguridad» se refieren aquí a lo mismo: el software que utiliza un equipo de seguridad.
Las categorías principales son la gestión de información y eventos de seguridad (SIEM), la detección y respuesta en terminales y ampliada (EDR/XDR), la detección y respuesta en red (NDR), la orquestación, automatización y respuesta de seguridad (SOAR) y las plataformas de inteligencia sobre amenazas (TIP), además de la gestión de vulnerabilidades, el análisis de identidades y cloud . Todas ellas tienen como objetivo común un único resultado: la detección y respuesta fiables ante las amenazas. Sin embargo, las herramientas no constituyen por sí solas un SOC, sino que lo equipan. La práctica más amplia de las operaciones de seguridad abarca a las personas y los procesos que las rodean; esta página se centra en la capa tecnológica.
Esa perspectiva es importante porque a la mayoría de las empresas no les faltan herramientas, sino pruebas de que dichas herramientas detectan. La taxonomía de categorías que se muestra a continuación es lo mínimo imprescindible; casi todas las guías de Internet cuentan con una. Lo que la mayoría omite son las pruebas: datos sobre la satisfacción de los profesionales, la cuestión de la resistencia a la manipulación y la eficacia de detección medida. Esos tres hilos conductores recorren el resto de esta guía. El objetivo final es práctico: saber qué categorías necesita realmente tu equipo, cuánto costará poner en marcha cada una de ellas y cómo comprobar si las que ya tienes son eficaces.
La taxonomía que se muestra a continuación está ordenada según la opinión de los profesionales, y no según las estrategias de marketing de los proveedores. En la encuesta SOC 2025 de SANS —patrocinada por Elastic, un dato que conviene conocer—, EDR/XDR fue la única categoría de herramientas que obtuvo una puntuación superior a 3 en la escala de satisfacción de 4 puntos de la encuesta, mientras que las herramientas basadas en IA/ML ocuparon los últimos puestos. Este orden difiere del de la mayoría de las listas elaboradas por los proveedores, y precisamente por eso resulta útil.
Tabla: Las principales categorías de herramientas de operaciones de seguridad, ordenadas de forma que EDR/XDR ocupen los primeros puestos y los análisis basados en IA/ML los últimos, siguiendo el modelo de satisfacción de SANS para 2025.
La detección y respuesta en terminales (EDR) supervisa los procesos y el comportamiento de los terminales y, a continuación, contiene las amenazas en el propio host. La detección y respuesta ampliadas (XDR) extiende ese modelo a fuentes de telemetría adicionales. Categoría mejor valorada por los profesionales, según SANS 2025. Inconveniente: todo aquello que no pueda ejecutar un agente —dispositivos no gestionados, IoT, aparatos— queda fuera de su campo de visión. Vulnerabilidad ante la manipulación: los agentes EDR son el objetivo principal de las herramientas de desactivación de EDR que se tratan en la siguiente sección.
La detección y respuesta de red (NDR) detecta el comportamiento de los atacantes a partir del tráfico de red, operando fuera de banda. Su estatus de primer orden se basa en pruebas, no en su posicionamiento: completa la tríada de visibilidad del SOC junto con SIEM y EDR, y la telemetría de red sigue fluyendo incluso cuando se desactiva un agente de terminal. Inconveniente: no puede poner en cuarentena un host por sí sola, y la ubicación de los sensores y el tráfico cifrado requieren atención por parte de los ingenieros. Exposición a la manipulación: la categoría más difícil de silenciar desde un host comprometido.
El SIEM agrupa los registros de todo el entorno, los correlaciona y genera alertas. Es la columna vertebral habitual de un SOC —habitual, no obligatoria—. Los equipos pueden gestionar un SOC sin él —y, de hecho, a veces lo hacen—, centrándose en su lugar en XDR o en un lago de datos con «detección como código». Inconveniente: el coste de la ingesta varía en función del volumen de datos, y las reglas de correlación exigen un ajuste continuo. Vulnerabilidad ante la manipulación: la manipulación de los registros en las fases previas deja al SIEM completamente ciego, y su plano de gestión es en sí mismo un objetivo.
SOAR ejecuta guiones que coordinan las acciones de clasificación, enriquecimiento y respuesta en toda la pila. Inconveniente: automatiza la calidad de los datos que se le proporcionan; las pruebas revisadas por expertos que se presentan más adelante en esta guía revelan que la precisión puede disminuir incluso a medida que mejora la velocidad. Para obtener información detallada sobre la estrategia de automatización, consulta «Automatización del SOC». Riesgo de manipulación: una plataforma SOAR comprometida pone en manos del atacante tu propio mecanismo de respuesta.
Las herramientas y plataformas de inteligencia sobre amenazas (TIP) recopilan indicadores y contexto sobre los adversarios, y luego envían la información enriquecida al SIEM y al flujo de trabajo de clasificación. Inconveniente: el volumen de datos sin filtrar añade ruido en lugar de contexto, y el valor depende por completo de la integración posterior. Riesgo de manipulación: una TIP no está diseñada para detectar su propia vulnerabilidad ni un canal de datos contaminado; son los controles que la rodean los que deben hacerlo.
La gestión de vulnerabilidades detecta activos, analiza en busca de puntos débiles y prioriza su corrección. Inconveniente: es preventiva más que detectiva; encuentra la ventana abierta, pero no ve a nadie que se cuele por ella. Riesgo de manipulación: es fácil reducir discretamente el alcance del análisis, y los activos no analizados se consideran «limpios» en lugar de «desconocidos».
La gestión del estado Cloud (CSPM) comprueba que cloud se ajusten a las políticas, mientras que cloud y respuestacloud (CDR) supervisa la actividad en tiempo de ejecución en los planos cloud y las cargas de trabajo cloud . Inconveniente:cloud genera lagunas de cobertura, y los resultados sobre el estado de seguridad suelen carecer de contexto en tiempo de ejecución. Riesgo de manipulación: los atacantes desactivan el registro cloud para engañar a estas herramientas; la manipulación cloud ocupa un lugar específico dentro de la técnica ATT&CK que se tratará a continuación.
La gestión de identidades y accesos (IAM) regula quién puede acceder a qué, mientras que el análisis del comportamiento de usuarios y entidades (UEBA) establece perfiles de referencia del comportamiento de las identidades para detectar accesos anómalos. Inconveniente: los perfiles de referencia del comportamiento exigen un ajuste continuo y una responsabilidad clara, lo que supone una carga operativa que muchos equipos subestiman. Riesgo de manipulación: el UEBA hereda la integridad de las fuentes de registros que lo alimentan; unos registros manipulados implican un perfil de referencia manipulado.
Durante años, los equipos de seguridad consideraron la manipulación de herramientas como un caso aislado. MITRE ATT&CK v19, publicada el 28 de abril de 2026, la convirtió en una táctica de primer orden: el marco dividió la antigua táctica «Evasión de la defensa» en «Sigilo» (TA0005) y «Deterioro de la defensa» (TA0112). La nueva táctica describe a los adversarios que «rompen los mecanismos de seguridad, los flujos de trabajo y las herramientas para que los defensores no puedan ver ni confiar en lo que está sucediendo»: toda una táctica de ATT&CK dedicada a atacar las herramientas de operaciones de seguridad.
Dentro de TA0112 se encuentra T1685, «Desactivar o modificar herramientas» —la técnica principal que abarca la desactivación de herramientas y agentes—, con seis subtécnicas que abarcan cloud manipulación cloud Windows, Linux y cloud , la suplantación de interfaces de herramientas y el borrado de registros. La tabla de exposición que figura a continuación establece una correspondencia entre las categorías de herramientas y dichas subtécnicas.
Nada de esto es teórico. En 2025, los investigadores documentaron una única herramienta de desactivación de EDR utilizada por ocho grupos de ransomware diferentes, en la que «cada ataque utilizaba una versión diferente», según el informe. El protocolo de ataque del ransomware ahora suele comenzar desactivando el agente del terminal antes de que comience el cifrado.
El método de ejecución preferido es «trae tu propio controlador vulnerable» (BYOVD): el uso malintencionado de un controlador firmado pero vulnerable para obtener los privilegios necesarios para detener los procesos de seguridad. El proyecto «Living Off The Land Drivers» recoge actualmente más de 1.700 controladores vulnerables, y los investigadores de ESET han observado un «fuerte aumento» en su uso malintencionado durante 2025. Para un análisis en profundidad de las técnicas defensivas contra esta táctica, consulta «Evasión de EDR».
Esta técnica se generalizó en 2026. El análisis realizado por ESET de un marco de trabajo diseñado para eludir los sistemas EDR documentó ocho variantes dirigidas a más de 400 procesos de 48 productos de seguridad, que se distribuían mediante el uso indebido del controlador BYOVD. El ransomware también ha comenzado a integrar el controlador vulnerable directamente en la carga útil (2026), lo que elimina la necesidad de descargarlo en tiempo de ejecución.
Los planos de gestión de las herramientas también están siendo objeto de ataques. En 2026, una plataforma SIEM líder en el mercado reveló una vulnerabilidad con una puntuación CVSS de 9,8 que permitía a atacantes no autenticados crear o truncar archivos arbitrarios; esta vulnerabilidad fue explotada activamente y se incluyó en el catálogo de vulnerabilidades explotadas conocidas de la CISA. Ese mismo año, una plataforma líder de SOAR/SIEM reveló una vulnerabilidad crítica de control de acceso con una puntuación CVSS de 9,1. Las propias herramientas destinadas a detectar ataques constituyen, a su vez, una superficie de ataque.
La defensa se articula en varias capas y es estrictamente defensiva: habilitar la protección contra manipulaciones siempre que el agente lo permita, aplicar listas de bloqueo de controladores vulnerables, supervisar el estado de la ingesta para que una fuente de registros silenciada active una alarma y mantener una telemetría de red fuera de banda que un host comprometido no pueda desactivar. Además, añade una pregunta de evaluación directa que pocas listas de comprobación incluyen: ¿sobrevivirá esta herramienta al contacto con un adversario? Y, si no lo hace, ¿alguien se dará cuenta?
Tabla: Exposición de las categorías de herramientas a la vulnerabilidad «Defense Impairment», según MITRE ATT&CK (abril de 2026).
El conjunto de datos más preocupante en las operaciones de seguridad procede de las simulaciones de brechas y ataques (BAS). En el «Picus Blue Report 2025» —publicado por un proveedor de BAS, elaborado a partir de los entornos de sus propios clientes y basado en ataques simulados en lugar de reales—, el 54 % de la actividad de ataque sometida a prueba quedó registrada, pero solo el 14 % generó una alerta. El mismo conjunto de datos registró una caída de la eficacia de la prevención del 69 % en 2024 al 62 % en 2025. Aunque se tenga en cuenta este sesgo, la conclusión sigue siendo válida: una herramienta que registra sin alertar es un archivo forense, no un control de detección. Y las simulaciones son el caso más benigno: los adversarios reales pueden ser mucho más creativos.
Los datos de los profesionales apuntan en la misma dirección. La encuesta de SANS de 2025 reveló que el 42 % de los SOC envían todos los datos entrantes a un SIEM sin ningún plan de recuperación ni gestión. Tal y como señala la encuesta: «Recopilar datos es fácil; lo difícil es utilizarlos de forma inteligente».
Los datos sobre resultados aportan los matices necesarios —en ambos sentidos a la vez—. El informe «M-Trends 2026» de Mandiant, basado en más de 500 000 horas de investigaciones de incidentes, señala que la mediana global del tiempo de permanencia aumentó de 11 a 14 días, mientras que el porcentaje de intrusiones detectadas internamente mejoró del 43 % al 52 %. Cada vez son más las organizaciones que detectan por sí mismas a los atacantes, en lugar de enterarse por terceros, y esos atacantes siguen permaneciendo más tiempo en el sistema. Hay que tener en cuenta la muestra: el volumen de casos de un proveedor de respuesta a incidentes se inclina necesariamente hacia las organizaciones que han sufrido una intrusión. No hay que dejarse llevar por una narrativa simplista; la interpretación honesta es que la capacidad de detección está mejorando y la velocidad de expulsión no, y ambas cosas ocurren simultáneamente.
La conclusión práctica es un cambio de perspectiva. La mayoría de los equipos de SOC ya cuentan con las categorías adecuadas; la cuestión pendiente es si esos controles se activan cuando se someten a prueba. La detección es una propiedad que se mide, no una característica que se compra: a través de la medición de la cobertura frente a ATT&CK, ejercicios de «purple team» que prueban la pila de extremo a extremo y la ingeniería de detección que convierte los registros en alertas. La validación también es continua, no anual: hay que volver a realizar pruebas tras cambios importantes en la configuración, hacer un seguimiento de la fidelidad de las alertas y observar la proporción de técnicas que la pila detecta de forma demostrable. Adquirir otra categoría añade cobertura sobre el papel; solo la medición lo demuestra en producción.
Las listas de verificación por categorías hacen que la compra parezca sencilla. Los datos anteriores abogan por criterios más exigentes, que comprueben si una herramienta generará alertas en tu entorno y resistirá el escrutinio de un atacante. Las mejores herramientas de SOC para tu equipo superan esta secuencia:
Realiza las compras por fases según la madurez, en lugar de por catálogo: primero la visibilidad (cobertura de terminales y redes), luego la correlación (SIEM o lago de datos) y, por último, la automatización; el SOAR multiplica la calidad de detección que ya exista. Match compra a la plantilla, ya que un equipo reducido no puede gestionar bien todas las categorías a la vez.
La selección también tiene lugar en el marco de una realidad fragmentada. Una encuesta realizada en 2026 por Panaseer entre 400 responsables de seguridad sitúa la media de herramientas de seguridad por empresa en 61. Otros estudios ofrecen cifras diferentes —la tabla siguiente muestra la variación— y las diferencias dicen más sobre las muestras y las definiciones que sobre cualquier tendencia. En lo que coinciden los estudios es en la consecuencia: las herramientas están ahí, pero a menudo falta la integración que las hace útiles en conjunto.
Tabla: Las cifras habituales sobre el número de herramientas empresariales constituyen un rango controvertido, no una serie temporal.
La automatización merece una advertencia especial. El único estudio controlado con usuarios sobre herramientas SOAR comerciales —sometido a revisión por pares, aunque ya tiene más de dos años— contó con 24 participantes que utilizaron seis herramientas diferentes para realizar tareas de investigación realistas (Bridges et al., 2023). La eficiencia mejoró, pero «la precisión y la exhaustividad de los tickets… disminuyeron con el uso de SOAR», y los analistas sénior señalaron la automatización excesiva como un riesgo. Adopta la automatización para agilizar las decisiones y mantén a las personas responsables de la calidad.
Hay dos errores de selección que se repiten con frecuencia. En primer lugar, implementar herramientas para las que no se dispone de recursos: la encuesta de SANS de 2025 es muy clara al afirmar que «si la dirección de la empresa no está dispuesta a comprometer plenamente los recursos..., sería mejor no implementarlas en absoluto». En segundo lugar, adquirir una solución y dar por sentado el resultado. La adquisición cubre las necesidades sobre el papel, pero la respuesta ante incidentes seguirá fallando a las 2 de la madrugada si no se ha activado ninguna alerta.
Por qué confiar en esta guía: ordenamos las categorías según los datos de los profesionales, indicamos la fecha de cada estadística, citamos la fuente de la que procede cada cifra, revelamos el sesgo de los patrocinadores cuando existe (el conjunto de datos de un proveedor de BAS, una encuesta patrocinada por Elastic, el volumen de casos de un proveedor de respuesta a incidentes) y no mencionamos a ningún proveedor comercial. Cuando las pruebas apuntan en dos direcciones, mostramos ambas.
Es posible crear una pila SOC operativa a partir de herramientas SOC de código abierto, y para algunos equipos es lo más recomendable. Wazuh se encarga de las funciones de SIEM/XDR. Security Onion y Graylog se ocupan de la supervisión de la seguridad de la red y la gestión de registros. Suricata y Zeek proporcionan detección de amenazas en la red. TheHive gestiona los casos y las investigaciones, mientras que Velociraptor, osquery y GRR facilitan el análisis de los terminales y el análisis forense. Todas ellas reciben un mantenimiento activo, la mayoría en GitHub, y cuentan con comunidades de profesionales reales que las respaldan.
Tabla: Componentes de código abierto para una pila SOC, agrupados por función.
La contrapartida real merece el mismo protagonismo. Una pila de código abierto puede proporcionarte una cobertura funcional, pero dedicarás tiempo de ingeniería a la integración y el mantenimiento: el coste de la licencia se sustituye por el coste de ingeniería, sin un acuerdo de nivel de servicio (SLA) del proveedor que respalde la asistencia técnica. Presupuesta con honestidad las partes que, de todos modos, la cuota de licencia nunca cubría: el mantenimiento del contenido de detección, las actualizaciones de versión, el ajuste de los sensores y la rotación de guardias que hay detrás de todo ello. Las herramientas gratuitas que no cuentan con tiempo de ingeniería detrás fracasan de la misma manera que el «shelfware»: en silencio. Para obtener una guía más completa función por función, una referencia muy utilizada sobre herramientas de SOC de código abierto describe el ecosistema en profundidad.
A quién va dirigido: equipos con auténtica capacidad de ingeniería y equipos que buscan un entorno de pruebas antes de realizar una inversión comercial. También es adecuado para entornos mixtos: muchos SOC utilizan Zeek o Suricata junto con plataformas comerciales como medida de control independiente y fuera de banda del resto de la pila.
Las herramientas del centro de operaciones de seguridad (SOC) solo son relevantes dentro de un modelo operativo capaz de ponerlas en marcha, y la primera decisión que hay que tomar es quién se encarga de su gestión: tu equipo, un proveedor o ambos. Un SOC interno maximiza el control y el contexto del entorno, pero la dotación de personal es la principal limitación: el 79 % de los SOC funcionan las 24 horas del día, los 7 días de la semana (SANS 2025), y la cobertura ininterrumpida exige múltiples turnos de trabajo por parte de unos analistas que escasean.
Los modelos gestionados —detección y respuesta gestionadas (MDR) y SOC como servicio— permiten obtener cobertura rápidamente y reducir los costes fijos, a cambio de perder contexto y control. Los SOC cogestionados ofrecen un término medio: mantienen las tareas de clasificación de incidencias o ingeniería en la propia empresa, mientras que un proveedor se encarga de la supervisión nocturna. Esta vía intermedia resulta adecuada para equipos reducidos, especialmente aquellos que gestionan la seguridad con menos de cinco empleados a tiempo completo.
Tabla: Compara las ventajas e inconvenientes de los modelos operativos de seguridad interna y de seguridad gestionada.
En cuanto a los tipos de centros de operaciones de seguridad, predominan cuatro modelos: el SOC único y centralizado —que sigue siendo el más habitual, con aproximadamente un 38 % (SANS 2025)—, además de los modelos virtual, cogestionado y SOC como servicio. Match modelo en función del tamaño del equipo, la madurez y el presupuesto, no según las preferencias del proveedor. Y sea cual sea el modelo elegido, mantén la validación de la detección a nivel interno: externalizar la supervisión es viable; externalizar la responsabilidad, no.
Hay tres tendencias que están transformando la forma en que las organizaciones adquieren y gestionan esta pila tecnológica. La consolidación y la convergencia de plataformas, a medida que los compradores se oponen a la proliferación de herramientas. Las herramientas y agentes de SOC basados en IA, que prometen una clasificación automatizada de incidencias. Y un cambio de la adquisición a la validación continua: la ingeniería de detección, los equipos «purple» y la medición de la cobertura como práctica habitual, en lugar de una auditoría anual.
Mantén la IA al día y con los pies en la tierra. Los profesionales sitúan actualmente las herramientas basadas en IA y aprendizaje automático (ML) en los últimos puestos de la lista de satisfacción, y las herramientas de lenguaje generativo obtienen una puntuación de 2 sobre 4 (SANS 2025), en gran parte por razones estructurales, ya que las nuevas herramientas llegan sin una responsabilidad clara, sin presupuesto ni integración. Las categorías con baja valoración ya han madurado en otras ocasiones; en la misma serie de encuestas, la detección de activos pasó de ocupar el último puesto de la lista en 2017 a situarse en la mitad de la tabla. Considera la detección de amenazas mediante IA como un campo emergente y aún inestable: realmente prometedor, pero aún sin demostrar en los datos de los profesionales. Para los analistas que se preguntan qué herramientas deben aprender primero, empezad por las consolas SIEM y EDR que vuestro equipo ya utiliza; la página dedicada a los analistas de SOC ofrece una perspectiva profesional.
Los marcos de cumplimiento normativo dan ahora por sentado el uso de estas herramientas. La norma NIST SP 800-61r3, publicada en abril de 2025 como primera revisión desde 2012, adapta las directrices de respuesta ante incidentes a las funciones «Detectar» y «Responder» del NIST CSF 2.0. MITRE ATT&CK sirve como referencia de trabajo para la cobertura de detección, incluido el TA0112.
Tabla: Marcos de referencia relevantes para la toma de decisiones sobre herramientas para operaciones de seguridad.
Vectra AI los datos anteriores como una lección: la recopilación no es lo mismo que la detección. Cuando un conjunto de datos del BAS de 2025 muestra que se ha registrado el 54 % de la actividad de ataque, pero solo se ha alertado del 14 %, y SANS constata que el 42 % de los SOC almacenan datos sin un plan, el recurso escaso es la señal, no la telemetría. Por lo tanto, la metodología Vectra AI da prioridad a la señal de ataque frente al volumen bruto, con cobertura tanto en la red como en la identidad, las superficies que siguen generando informes cuando un atacante desactiva el agente del terminal.
No. Un SIEM es una herramienta: agrega, correlaciona y genera alertas a partir de datos de registro. Un SOC, o centro de operaciones de seguridad, está formado por el personal, los procesos y el conjunto completo de herramientas que utiliza un SIEM junto con plataformas de EDR/XDR, NDR, SOAR e inteligencia sobre amenazas.
Sí, aunque no es lo habitual. Algunos equipos centran sus operaciones en XDR o en un lago de datos con «detección como código». Un SIEM es una infraestructura común más que un requisito previo, y el estudio SANS 2025 reveló que el 42 % de los SOC envían todos los datos a un SIEM sin un plan de recuperación.
Se pierde la telemetría con la que se contaba, a menudo de forma silenciosa. Los operadores de ransomware utilizan cada vez más los «BYOVD» (bring-your-own-vulnerable-driver), unos «EDR-killers» que desactivan los agentes de los terminales antes del cifrado —un comportamiento MITRE ATT&CK ha formalizado como TA0112 y T1685—. Las medidas de mitigación incluyen la protección contra la manipulación, las listas negras de controladores y la telemetría de red fuera de banda.
EDR/XDR. En la encuesta SANS 2025 SOC, patrocinada por Elastic, fue la única categoría que obtuvo una puntuación superior a 3 en una escala de satisfacción de 4 puntos, mientras que las herramientas de IA/ML ocuparon los últimos puestos y las herramientas de lenguaje generativo obtuvieron una puntuación de 2 sobre 4. Las valoraciones de los profesionales suelen discrepar de las listas elaboradas por los proveedores.
Entre los componentes básicos más habituales se encuentran Wazuh (SIEM/XDR), Security Onion y Graylog (supervisión y gestión de registros), Suricata y Zeek (detección de amenazas en la red), TheHive (gestión de casos) y Velociraptor y osquery (investigación de terminales). El código abierto compensa el coste de las licencias con el tiempo de ingeniería dedicado a la integración y el mantenimiento.
Un SOC interno está formado y dirigido por tu propio equipo, lo que maximiza el control y el contexto del entorno. Un SOC gestionado —MDR o SOC como servicio— externaliza la supervisión y la respuesta a un proveedor. Muchos equipos reducidos optan por una vía intermedia de gestión compartida entre ambas opciones.
Hay cuatro modelos que predominan: centralizado en las propias instalaciones, virtual, cogestionado y SOC como servicio. La encuesta de SANS de 2025 reveló que el SOC único y centralizado sigue siendo el modelo más habitual, con un porcentaje aproximado del 38 %. Match modelo en función del tamaño del equipo, el grado de madurez y el presupuesto, más que por las preferencias del proveedor.