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

En este artículo se explica cómo tratar determinados 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, es posible que falten resultados de consulta vistos más adelante o que sean diferentes de los esperados. Por ejemplo, puede ver los resultados de una consulta más adelante al investigar un incidente relacionado y, como parte de esa investigación, decide volver a 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 guardan los resultados y no aparece ningún dato al volver a ver los resultados de la consulta.

En los casos en los que hay retraso de ingesta o la consulta no es determinista debido a la agregación, el resultado de la alerta podría 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 Consulta existente y el nuevo campo:

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

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

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

Error transitorio

Se produce un error transitorio debido a una circunstancia que es 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:

• Una consulta de regla tarda demasiado tiempo en ejecutarse y 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.

En caso de error transitorio, Microsoft Sentinel sigue intentando ejecutar la regla de nuevo después de intervalos predeterminados y cada vez mayores, hasta un punto. Después de eso, la regla se volverá a ejecutar solo en su próxima hora programada. Una regla nunca se puede cambiar automáticamente debido a un error transitorio.

Error permanente: regla que se puede usar automáticamente

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

• Se eliminó el área de trabajo de destino (en la que operaba la consulta de regla).
• Se eliminó la tabla de destino (en la que operaba la consulta de regla).
• Microsoft Sentinel se quitó del área de trabajo de destino.
• Una función usada por la consulta de regla ya no es válida; se modificó o se quitó.
• Se cambiaron los permisos para uno de los orígenes de datos de la consulta de regla (vea el ejemplo).
• Se eliminó uno de los orígenes de datos de la consulta de regla.

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 realiza los pasos siguientes:

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

Puede determinar fácilmente la presencia de cualquier regla de identificación automática mediante la ordenación de la lista de reglas por nombre. Las reglas de autodisabled están en la parte superior de la lista o cerca de ella.

Los administradores de SOC deben asegurarse de comprobar periódicamente la lista de reglas para detectar la presencia de reglas que se pueden cambiar 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 informáticos excesivos y corre el riesgo de ser una purga de rendimiento en los sistemas. Cuando Microsoft Sentinel identifica dicha regla, realiza los mismos tres pasos mencionados para los otros tipos de errores permanentes: deshabilita la regla, antepone "AUTO DISABLED" al nombre de la regla y agrega el motivo del error a la descripción.

Para volver a habilitar la regla, debe solucionar los problemas de la consulta que hacen que use demasiados recursos. Para más información, vea:

• Procedimientos recomendados de consulta: documentación de Kusto
• Optimización de consultas de registro en Azure Monitor
• Lenguaje de consulta Kusto recursos de aprendizaje

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 (consulte la lista) se refiere al caso de un proveedor de soluciones de seguridad de Microsoft (MSSP) o a cualquier otro escenario en el que las reglas de análisis consultan entre 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 puede acceder al área de trabajo que contiene las tablas a las que hace referencia la consulta de la regla y que este acceso se mantiene incluso si el creador de la regla pierde el acceso a ese á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 lo que sucede en el caso de un MSSP, Microsoft Sentinel toma medidas de seguridad adicionales para evitar el acceso no autorizado a los datos del cliente. Estos tipos de reglas tienen aplicadas las credenciales del usuario que creó la regla, en lugar de un token de acceso independiente. Cuando el usuario ya no tiene acceso al otro inquilino, la regla deja de funcionar.

Si opera Microsoft Sentinel en un escenario entre suscripciones o entre inquilinos, y si uno de sus analistas o ingenieros pierde el acceso a un área de trabajo determinada, las reglas creadas por ese usuario dejarán de funcionar. Obtendrá un mensaje de supervisión de estado sobre "acceso insuficiente al recurso" y la regla se podrá cambiar automáticamente según el procedimiento descrito anteriormente.

Siguientes pasos

Para más información, vea:

• Tutorial: Investigación de incidentes con Microsoft Sentinel
• Navegació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, aprenda de un ejemplo de uso de reglas de análisis personalizadas al supervisar Zoom con un conector personalizado.