Solución de problemas de reglas de análisis en Microsoft Sentinel

En este artículo se explica cómo tratar ciertos problemas que pueden surgir con la ejecución de reglas de análisis programadas en Microsoft Sentinel.

Problema: no aparece ningún evento en los resultados de la consulta

Cuando se establece la agrupación de eventos para desencadenar una alerta para cada evento, los resultados de la consulta que se ven más adelante pueden parecer que faltan o son diferentes de lo esperado. Por ejemplo, puedes ver los resultados de una consulta más adelante al investigar un incidente relacionado y, como parte de esa investigación, decides volver a dinamizar los resultados anteriores de esta consulta.

Los resultados se guardan automáticamente con las alertas. Sin embargo, si los resultados son demasiado grandes, no se guarda ningún resultado y, a continuación, no aparece ningún dato al volver a ver los resultados de la consulta.

En los casos en los que hay un retraso en la ingesta, o si la consulta no es determinista debido a la agregación, el resultado de la alerta puede ser diferente del resultado que se muestra al ejecutar la consulta manualmente.

Para solucionar este problema, cuando una regla tiene esta configuración de agrupación de eventos, Microsoft Sentinel agrega el campo OriginalQuery a los resultados de la consulta. Esta es una comparación del campo Query existente y el nuevo campo:

Nombre del campo	Contiene	Al ejecutar la consulta en este campo el resultado es...
Consultar	El registro comprimido del evento que generó esta instancia de la alerta.	El evento que generó esta instancia de la alerta; limitado a 10 kilobytes.
OriginalQuery	La consulta original tal como está escrita en la regla de análisis.	El evento más reciente en el período de tiempo en el que se ejecuta la consulta, que se ajusta a los parámetros definidos por la consulta.

En otras palabras, el campo OriginalQuery se comporta como se comporta el campo Query en la configuración de agrupación de eventos predeterminada.

Problema: No se pudo ejecutar una regla programada o aparece con el texto AUTO DISABLED agregado al nombre

Es muy poco frecuente que una regla de consulta programada no se ejecute, pero puede ocurrir. Microsoft Sentinel clasifica los errores como transitorios o permanentes, en función del tipo específico del error y de las circunstancias que condujeron a él.

Error transitorio

Se produce un error transitorio debido a una circunstancia temporal y que pronto vuelve a la normalidad, momento en el que la ejecución de la regla se realiza correctamente. Algunos ejemplos de errores que Microsoft Sentinel clasifica como transitorios son los siguientes:

• Una consulta de regla tarda demasiado tiempo en ejecutarse y se agota el tiempo de espera.
• Problemas de conectividad entre orígenes de datos y Log Analytics, o entre Log Analytics y Microsoft Sentinel.
• Cualquier otro error nuevo y desconocido se considera transitorio.

Cuando se produce un error transitorio, Microsoft Sentinel sigue intentando volver a ejecutar la regla tras intervalos predeterminados y cada vez mayores, hasta un punto determinado. Después, la regla se volverá a ejecutar solo en la siguiente hora programada. Una regla nunca se puede deshabilitar automáticamente debido a un error transitorio.

Error permanente: deshabilitación automática de la regla

El error permanente se produce debido a un cambio en las condiciones que permiten la ejecución de la regla y que, sin intervención humana, no volverán a su estado anterior. A continuación se muestran algunos ejemplos de errores que se clasifican como permanentes:

• El área de trabajo de destino (en la que opera la consulta de regla) se ha eliminado.
• La tabla de destino (en la que opera la consulta de regla) se ha eliminado.
• Se quitó Microsoft Sentinel del área de trabajo de destino.
• Una función usada por la consulta de la regla ya no es válida porque se ha modificado o quitado.
• Se cambiaron los permisos para uno de los orígenes de datos de la consulta de la regla (vea el ejemplo).
• Uno de los orígenes de datos de la consulta de la regla se ha eliminado.

En el caso de un número predeterminado de errores permanentes consecutivos, del mismo tipo y en la misma regla, Microsoft Sentinel deja de intentar ejecutar la regla y también lleva a cabo los siguientes pasos:

1. Deshabilita la regla.
2. Agrega las palabras "AUTO DISABLED" (deshabilitada automáticamente) al principio del nombre de la regla.
3. Agrega el motivo del error (y la deshabilitación) a la descripción de la regla.

Puedes determinar fácilmente si se ha deshabilitado automáticamente alguna regla si ordenas la lista de reglas por nombre. Las reglas de distribución automática están en o cerca de la parte superior de la lista.

Los administradores de SOC deben asegurarse de comprobar la lista de reglas periódicamente para comprobar si hay reglas deshabilitadas automáticamente.

Error permanente debido a la purga de recursos

Otro tipo de error permanente se produce debido a una consulta compilada incorrectamente que hace que la regla consuma recursos de procesamiento excesivos y riesgos como una purga de rendimiento en los sistemas. Cuando Microsoft Sentinel identifica dicha regla, sigue los mismos tres pasos mencionados para los otros tipos de errores permanentes: deshabilita la regla, antepone "DESHABILITADO AUTOMÁTICAMENTE" al nombre de la regla y agrega el motivo del error a la descripción.

Para volver a habilitar la regla, deberá solucionar los problemas de la consulta que hacen que use demasiados recursos. Consulte los siguientes artículos para obtener procedimientos recomendados para optimizar las consultas de Kusto:

• Procedimientos recomendados de consulta: Azure Data Explorer
• Optimización de las consultas de registro en Azure Monitor

Consulte también Recursos útiles para trabajar con el Lenguaje de consulta Kusto en Microsoft Sentinel para obtener más ayuda.

Error permanente debido a la pérdida de acceso entre suscripciones o inquilinos

Un ejemplo concreto de cuándo podría producirse un error permanente debido a un cambio de permisos en un origen de datos (consulta la lista) sería el caso de un Proveedor de soluciones de Microsoft Security (MSSP), o cualquier otro escenario en el que las reglas de análisis consulten a través de suscripciones o inquilinos.

Al crear una regla de análisis, se aplica un token de permisos de acceso a la regla y se guarda junto con ella. Este token garantiza que la regla pueda acceder al área de trabajo que contiene los tablas referenciadas por la consulta de la regla y que este acceso se mantiene incluso si el creador de la regla pierde el acceso a esa área de trabajo.

Sin embargo, hay una excepción: cuando se crea una regla para acceder a áreas de trabajo de otras suscripciones o inquilinos, como ocurre en el caso de un MSSP, Microsoft Sentinel toma medidas de seguridad adicionales para evitar el acceso no autorizado a los datos de los clientes. Estos tipos de reglas tienen las credenciales del usuario que creó la regla aplicada, en lugar de un token de acceso independiente. Cuando el usuario ya no tiene acceso al otro inquilino, la regla deja de funcionar.

Si utilizas Microsoft Sentinel en un escenario entre suscripciones o inquilinos y uno de los analistas o ingenieros pierde el acceso a un área de trabajo determinada, las reglas creadas por ese usuario dejarán de funcionar. Recibirás un mensaje de seguimiento de estado sobre "acceso insuficiente al recurso" y la regla se deshabilitará automáticamente según el procedimiento descrito anteriormente.

Pasos siguientes

Para más información, consulte:

• Tutorial: Investigación de incidentes con Microsoft Sentinel
• Exploración e investigación de incidentes en Microsoft Sentinel: versión preliminar
• Clasificación y análisis de datos mediante entidades en Microsoft Sentinel
• Tutorial: Uso de cuadernos de estrategias con reglas de automatización en Microsoft Sentinel

Además, obtenga información de un ejemplo del uso de reglas de análisis personalizadas al supervisar Zoom con un conector personalizado.