Seguir Las operaciones de detección multi-inquilino son la práctica de gestionar una fuente de lógica de detección independiente del proveedor, traducida y ajustada por inquilino, para que un conjunto de clientes que ejecutan diferentes plataformas SIEM se mantenga consistente, ajustable y reportable desde una única fuente gobernada.
Un MSSP que ejecuta la detección para docenas de inquilinos enfrenta una cuestión estructural: ¿cada cliente obtiene su propia bifurcación de cada regla de detección, o una única fuente gobernada se traduce y ajusta por inquilino? La respuesta determina el costo operativo, la precisión del reporte de cobertura y si un cambio en la lógica compartida se propaga de inmediato o se queda en una lista de parches manuales.
Esta página cubre la capa de contenido de detección de ese modelo: una fuente de lógica de detección independiente del proveedor, gestionada centralmente, traducida y ajustada por inquilino. Hunters opera en la capa de análisis y operaciones, una plataforma alternativa a SOC y SIEM para proveedores MSSP y MDR. ContraForce opera en la capa de gestión de casos y flujo de entrega, orientada al conjunto de seguridad de Microsoft (Microsoft Sentinel y Defender XDR). La fuente de contenido de detección descrita aquí se sitúa aguas arriba, suministrando la lógica de detección independiente del proveedor que consumen las capas de ejecución, investigación y reporte.
Alcance: plataformas SIEM (Splunk, Microsoft Sentinel, Google SecOps, Elastic Security, CrowdStrike). EDR como objetivo de implementación está fuera de alcance hasta que se verifique el soporte por plataforma.
Un MSSP también es una entidad regulada por derecho propio. Reglamento de Ejecución de la Comisión (UE) 2024/2690, en vigor desde el 7 de noviembre de 2024, establece requisitos de monitoreo y registro (sección 3.2 del Anexo) para proveedores de servicios de seguridad gestionada bajo NIS2. La obligación de evidencia del propio MSSP, no solo la de sus inquilinos, impulsa el modo en que el contenido de detección es gobernado y reportado.
¿Cómo puede un SOC multi-inquilino mantener la lógica de detección consistente en entornos de clientes que ejecutan diferentes plataformas SIEM?
Escribe la lógica de detección una vez en un formato independiente del proveedor (Sigma). Tradúcelo según el SIEM de cada inquilino. Gestiona la fuente centralmente.
El artefacto base compartido
La base es un único artefacto de lógica de detección. Su condición lógica se evalúa contra un esquema común y normalizado en lugar de contra los campos de registro en bruto de cualquier inquilino. Esto es lo que hace que la misma regla sea portátil a través de Splunk, Microsoft Sentinel, Google SecOps, Elastic y CrowdStrike sin reescribir la propia lógica de detección.
La normalización asigna campos específicos de la fuente a ese esquema compartido mientras preserva su semántica. Una regla escrita contra el campo normalizado auth.result significa lo mismo independientemente de qué proveedor de identidad produjo el evento: auth.result se resuelve en {éxito, fracaso, desafío} según un contrato semántico nombrado, no según lo que el IdP del cliente llame al campo.
La superposición por inquilino
Cada inquilino obtiene una superposición. La superposición lleva el mapeo de campos que traduce los campos de origen en bruto de ese inquilino al esquema normalizado compartido, y los parámetros de ajuste (umbrales, ventanas de tiempo, exclusiones de ruido) adaptados al entorno de ese inquilino. La base y la superposición son versionadas por separado.
Una actualización lógica en la base se propaga a cada inquilino cuya superposición mapea los campos requeridos. Un cambio de ajuste en la superposición de un inquilino afecta solo a ese inquilino.
Compartido versus específico del inquilino
Qué permanece compartido: la condición de la lógica de detección, las definiciones de contrato semántico de las que la lógica depende, el etiqueta de técnica de MITRE ATT&CK , y el historial de versiones y cambios.
Qué es específico del inquilino: el mapeo de campo de crudo a normalizado, el estado de validación de contrato en tiempo de ejecución (pasar o fallar evaluado por el flujo de eventos real del inquilino, no una propiedad estática de la regla), la traducción objetivo de la plataforma, y los parámetros de ajuste.
¿Cómo manejas el contenido de detección en docenas de entornos de clientes sin bifurcarlo por cliente?
Un artefacto gobernado por detección, no una bifurcación por cliente.
Bifurcar el archivo de reglas por cliente significa mantener copias independientes de lo que debería ser un artefacto gobernado. Una corrección lógica o una nueva actualización de técnica de evasión debe ser aplicada manualmente a cada bifurcación. Las bifurcaciones se desvían y la única historia de cambios versionada desaparece.
Cuando un auditor o un cliente pregunta quién cambió esta regla, cuándo y por qué, la respuesta debe trazarse a una sola línea de tiempo. Las copias divergentes que pueden o no reflejar la misma corrección dejan esa pregunta sin respuesta. Eso es un fallo de gobernanza y control de cambios, y socava directamente la evidencia de la que dependen los auditores.
El modelo de base más superposición mantiene un artefacto gobernado:
| Capa | Contiene | Ámbito |
|---|---|---|
| Base (compartida) | Condición de lógica de detección, definiciones de contrato semántico/temporal/de correlación, etiqueta de técnica MITRE ATT&CK, versión e historial de cambios | Todos los inquilinos |
| Superposición (por inquilino) | Mapeo de campo de crudo a normalizado, traducción objetiva de plataforma, umbrales, ventanas de tiempo, exclusiones de ruido | Un inquilino |
Un cambio en la lógica base se propaga por construcción. Solo el mapeo y ajuste permanecen locales. Esto es Disciplina de Detección-como-Código aplicada a operaciones multi-inquilino: los cambios en las reglas se versionan, revisan y rastrean como artefactos de código. La automatización de despliegue lleva la base actualizada a cada inquilino cuya superposición lo soporta.
La versionación de contratos gobierna la base. Los cambios deben ser versionados y los cambios disruptivos requieren un nuevo ID de contrato, por lo que cada inquilino obtiene una ruta de actualización reconcilable en lugar de una ruptura silenciosa.
SOC Prime trabaja con MDRs para diseñar operaciones de ingeniería de detección desde detecciones SIEM hasta la reducción de volumen SIEM con Prime Detect.
¿Cómo ajustas por cliente sin romper la regla compartida?
Ajusta en la superposición. La regla base permanece fija.
La superposición lleva la configuración específica del inquilino en dos partes.
Mapeo de campos. Los productos de origen de cada inquilino nombran un mismo hecho de manera diferente en el registro en bruto, por lo que la superposición traduce esos campos en bruto al esquema normalizado compartido. El mapeo debe satisfacer independientemente el mismo contrato semántico que comparten todos los demás inquilinos.
Un fallo concreto muestra por qué esto es importante. La superposición de un inquilino mapea el resultado «MFA pendiente» de su proveedor de identidad al valor normalizado «fracaso» en lugar de «desafío». La lógica compartida de detección de omisión de MFA, que busca un inicio de sesión exitoso sin evento de desafío previo, nunca ve un valor de «desafío» para ese inquilino. Cada inicio de sesión exitoso se marca como una omisión: un falso positivo masivo para ese inquilino, mientras que la regla idéntica es correcta para cada otro inquilino cuya superposición mapea el enum correctamente.
La regla nunca cambió. El fallo está completamente en la superposición, un error de superposición que se disfraza de un error de regla.
Parámetros de ajuste. Tolerancias de tiempo de correlación para vincular eventos relacionados, ventanas de tiempo de espera de sesión y de gracia para secuencias de autenticación, y exclusiones de ruido. Una tolerancia demasiado ajustada pierde correlaciones reales. Demasiado suelta, une eventos no relacionados. Estas ventanas pueden necesitar ajuste por inquilino para las características de sincronización de reloj y latencia de ese inquilino.
La condición de lógica de detección de la regla base, evaluada contra campos normalizados, nunca cambia para un solo inquilino. El estado de validación de contrato debe ser evaluado por inquilino en tiempo de ejecución, no asumido de la regla o el tipo de fuente.
¿Cómo informo la cobertura de detección MITRE ATT&CK a cada cliente cuando cada cliente nos envía diferentes fuentes de registro?
Calcula la cobertura por inquilino contra el conjunto de técnicas priorizadas propio de ese inquilino. Nunca reportes un número de biblioteca común entre los inquilinos. El método completo de medición se describe en la página complementaria sobre la medición de la cobertura de detección MITRE ATT&CK.
Plantilla de cobertura:
Cobertura (inquilino) = técnicas donde [telemetría válida Y regla desplegada Y regla probada que dispara] dividido por el conteo de técnicas priorizadas de ese inquilino.
Cuándo una técnica cuenta como cubierta
Una técnica cuenta como cubierta solo cuando todas estas condiciones se cumplen conjuntivamente:
- Telemetría válida para este inquilino. La fuente de datos requerida es recolectada, se ingiere activamente, pasa los contratos semántico, temporal y de correlación, y cumple con los SLOs de calidad (tasa de nulos, frescura). Todos estos se evalúan contra el flujo de eventos real de este inquilino, no un valor predeterminado del tipo de fuente.
- Regla desplegada y mapeada a la técnica. Un hecho de inventario de Detección-como-Código: qué regla existe, qué etiqueta MITRE ATT&CK lleva, su versión.
- La regla tiene prueba de disparo. Establecimiento de tasa de disparo, eventos canarios o validación de prueba atómica que muestra que la regla produce alertas ante actividad real o emulada. Una etiqueta de técnica sin un registro de disparo es solo una etiqueta, no una prueba.
El denominador es el propio subconjunto nombrado y priorizado de técnicas ATT&CKde ese inquilino. Nunca la matriz completa de ATT&CK . Nunca el tamaño de la biblioteca de reglas del proveedor.
Reportando estados de brecha
Informa los estados de brecha distintivamente, nunca como un número colapsado único:
| Estado | Significado | Remediación |
|---|---|---|
| VÁLIDO | Todas las puertas pasan, regla desplegada, prueba disparada en archivo | Cubierto a partir de la fecha del informe |
| INVÁLIDO | Fuente requerida no recolectada o no ingiriendo | Activación de fuente o reparación de ingestión |
| DEGRADADO | Fuente recolectada pero contrato o SLO de calidad fallando | Arreglo de mapeo, analizador o esquema |
| Brecha de contenido | Telemetría válida, ninguna regla mapeada a la técnica | Desarrollo de contenido |
No colapse INVÁLIDO y DEGRADADO en un solo número de «brecha». Diferentes modos de fallo requieren diferentes remediaciones y producen diferentes conversaciones con clientes.
Informe con una fecha. La cobertura es puntual.
¿Qué hace la reutilización de contenido al margen y la carga de entrenamiento de analistas?
La reutilización de contenido entre inquilinos convierte el costo de ingeniería de detección por cliente en un costo compartido y amortizado. Cuando la lógica base de detección se redacta una vez y se traduce por inquilino, el costo de ingeniería se distribuye a través del libro de clientes.
Margen. Cada inquilino que ejecuta la base compartida evita horas incrementales de ingeniería de detección. La mejora del margen es estructural. El programa de socios MDR de SOC Prime sitúa el ahorro en 4 mil horas al año en investigación de amenazas y codificación de contenido de detección. pone el ahorro en 4000 horas por año en investigación de amenazas y codificación de contenido de detección.
Carga de entrenamiento. Una metodología de Detección-como-Código. Un esquema normalizado. Un conjunto de semánticas de contrato. Los analistas se incorporan contra el modelo compartido en lugar de contra bibliotecas de reglas por cliente con nombres, estructura e intenciones diferentes. Cuando un analista se mueve de la cola de un inquilino a otro, la lógica de detección, el esquema y los contratos ya son familiares.
La objeción honesta. El contenido de detección compartido no borra la diferenciación del MSSP. La diferenciación se traslada al ajuste, la respuesta y el reporte. Las superposiciones específicas de cada inquilino, los libros de ejecución de respuestas y los informes de cara al cliente son donde se muestra el valor del MSSP. Un prospecto que escucha «contenido compartido» y piensa «mercancía» necesita ver exactamente dónde vive el trabajo personalizado.
Impulsor regulatorio. La propia obligación de evidencia del MSSP bajo NIS2, vía el Reglamento de Ejecución de la Comisión (UE) 2024/2690, requiere evidencia de monitoreo y registro del propio MSSP, no solo de sus inquilinos. El modelo compartido amortiza esa producción de evidencia.
Donde esto no se sostiene
El modelo base más superposición asume que la regla base está escrita contra un esquema normalizado que cada producto de fuente del inquilino puede satisfacer. El modelo se rompe bajo las siguientes condiciones.
- Productos de fuente que no emiten datos requeridos. Productos de fuente diferentes, o diferentes versiones del mismo producto, pueden no emitir un componente de datos requerido en absoluto. Ninguna superposición corrige un campo estructuralmente ausente. Esto es una brecha INVÁLIDA, remediada por habilitación de fuente o actualización.
- Disponibilidad de fuente. Un inquilino no ha incorporado una fuente de registro requerida, o su ingestión se ha apagado. La regla, mapeo y ajuste pueden ser correctos, y las técnicas afectadas aún quedan sin cubrir hasta que la fuente fluya de nuevo.
- Desajuste de tolerancia de correlación. La tolerancia de tiempo predeterminada compartida puede perder correlaciones reales para un inquilino con sincronización de reloj o latencia inusual. El ajuste por inquilino de ventanas de correlación es requerido, no opcional.
- Modelos de amenaza únicos o restricciones de residencia de datos. Un inquilino con un perfil de amenaza realmente único puede necesitar lógica de detección personalizada que la base compartida no contenga. Una restricción que prohíbe compartir artefactos de lógica de detección a través de límites organizacionales tiene el mismo efecto.
- El aislamiento del inquilino no es negociable. El modelo comparte la LÓGICA de detección entre inquilinos (texto de regla, definiciones de contrato). Nunca comparte datos del inquilino, caché de enriquecimiento, estado de alerta o resultados de validación a través de la frontera de inquilinos. Cualquier arquitectura donde las búsquedas de enriquecimiento o la cola de alertas de un inquilino se filtren a la de otro es un incidente de prioridad uno por diseño. Compartir lógica y compartir datos son afirmaciones diferentes.
Lista de verificación del modelo operativo multi-inquilino
Autor y gobierna la regla base
- Lógica de detección redactada en un formato independiente del proveedor (Sigma) contra un esquema definido por contrato normalizado
- Regla base separada de la superposición de inquilinos: lógica de detección, definiciones de contrato, etiqueta MITRE ATT&CK e historial de versiones permanecen compartidos
- Superposición por inquilino lleva mapeo de campos, traducción de plataforma y solo parámetros de ajuste, versionados por separado de la base
- Los cambios en la regla base se propagan a cada inquilino por construcción
- El historial de cambios se rastrea a una línea de tiempo gobernada por cada regla base, con cambios de superposición rastreados por inquilino
- Versionado de contrato aplicado: los cambios disruptivos llevan un nuevo ID de contrato
Valida mapeo y traducción de plataforma
- Los mapeos de campos satisfacen el mismo contrato semántico por inquilino, con validación de contrato ejecutada en tiempo de ejecución contra el flujo de eventos real de cada inquilino
- Traducción de plataforma validada por SIEM objetivo (Splunk, Microsoft Sentinel, Google SecOps, Elastic Security, CrowdStrike)
Calcula la cobertura por inquilino
- Cobertura calculada por inquilino contra el conjunto de técnicas ATT&CK priorizado propio de ese inquilino
- El numerador de cobertura requiere telemetría válida, regla desplegada y regla probada para disparar, todo verdadero en conjunto
- Estados de brecha distinguidos: VÁLIDO, INVÁLIDO (fuente faltante), DEGRADADO (fuente presente, validación fallando), y Brecha de contenido (telemetría válida, ninguna regla mapeada)
Ajusta, aísla, e informa
- Tolerancias de tiempo de correlación revisadas por inquilino para ajuste de sincronización de reloj y latencia
- Ajuste revisado en la superposición, nunca bifurcando la regla base
- Aislamiento del inquilino aplicado: sin compartición de datos, caché de enriquecimiento, estado de alerta o resultados de validación a través de límites de inquilinos
- Cobertura reportada con una fecha, por inquilino, nunca como un único número de biblioteca a través del libro
- La propia obligación de evidencia regulatoria del MSSP (Reglamento de Ejecución NIS2 2024/2690) atendida junto con las obligaciones de los inquilinos
- La formación de analistas alineada con la metodología compartida de Detección-como-Código, el esquema normalizado y las semánticas de contrato
FAQ
¿Cómo puede un SOC multi-inquilino mantener la lógica de detección consistente en entornos de clientes que ejecutan diferentes plataformas SIEM?
Escribe la lógica de detección una vez en Sigma, un formato independiente del proveedor, y tradúcelo según el SIEM de cada inquilino. Un modelo de base-más-superposición mantiene la lógica de detección compartida y el mapeo de técnicas MITRE ATT&CK en un artefacto gobernado, mientras que cada superposición de inquilino lleva el mapeo de campos, la traducción de plataforma y los parámetros de ajuste para ese entorno. Esto se enfoca en plataformas SIEM (Splunk, Microsoft Sentinel, Google SecOps, Elastic, CrowdStrike). EDR como objetivo de implementación está fuera de alcance hasta que se verifique el soporte por plataforma.
¿Cómo informo la cobertura de detección ATT&CK de MITRE a cada cliente cuando cada cliente nos envía diferentes fuentes de registro?
Calcula la cobertura por inquilino contra el conjunto de técnicas ATT&CK priorizado propio de ese inquilino, nunca como un único número de biblioteca a través del libro. Una técnica cuenta como cubierta solo cuando la telemetría es válida para ese inquilino, una regla está desplegada y mapeada a la técnica, y la regla tiene prueba de disparo. Reporta cuatro estados de brecha distintos: VÁLIDO, INVÁLIDO (fuente faltante), DEGRADADO (fuente recolectada pero validación fallando), y Brecha de contenido (telemetría válida, ninguna regla mapeada). Cada informe de cobertura lleva una fecha.
¿El contenido de detección compartido borra la diferenciación del MSSP?
El contenido de detección compartido desplaza donde vive la diferenciación. El valor distintivo del MSSP se traslada al ajuste específico del inquilino, los libros de ejecución de respuestas y el reporte de cobertura de cara al cliente. Las superposiciones de inquilino, los libros de respuesta y el análisis de cobertura por inquilino son donde la experiencia del MSSP se muestra a cada cliente.
