Creación de reglas de análisis personalizadas para detectar amenazas

Después de conectar los orígenes de datos a Microsoft Sentinel, cree reglas de análisis personalizadas que le ayuden a detectar las amenazas y los comportamientos anómalos de su entorno.

Las reglas de análisis buscan eventos o conjuntos de eventos específicos en el entorno, le avisan cuando se alcanzan determinados umbrales de eventos o condiciones, generan incidentes para que el SOC evalúe e investigue, y responden a las amenazas con procesos de seguimiento y corrección automatizados.

Sugerencia

Cuando cree reglas personalizadas, use las reglas existentes como plantillas o referencias. El uso de reglas existentes como base de referencia ayuda al crear la mayor parte de la lógica antes de realizar los cambios necesarios.

• Creación de reglas de análisis
• Definición de la forma en que se procesan los eventos y las alertas
• Definición de la forma en que se generan las alertas y los incidentes
• Elección de respuestas a amenazas automatizadas para las reglas

Creación de una regla de análisis personalizada con una consulta programada

1. En el menú de navegación de Microsoft Sentinel, seleccione Análisis.

2. En la barra de acciones de la parte superior, seleccione + Crear y elija Regla de consulta programada. Así se abre el Asistente para reglas de Analytics.

   

Asistente para reglas de análisis: pestaña General

• Proporcione un Nombre único y una Descripción.

• En el campo Tactics and techniques (Táctica y técnicas), puede elegir cualquiera de las categorías de ataques por las que se clasifica la regla. Se basan en las tácticas y técnicas del marco MITRE ATT&CK.

  Los incidentes creados a partir de alertas detectadas por reglas asignadas a las tácticas y técnicas de MITRE ATT&CK heredan automáticamente la asignación de la regla.

• Establezca la Gravedad de la alerta según sea necesario.

• Cuando cree la regla, el valor predeterminado del campo Status (Estado) es Enabled (Habilitado), lo que significa que se ejecutará inmediatamente después de que termine de crearla. Si no desea ejecutarla de inmediato, seleccione Disabled (Deshabilitado) para agregar la regla a la pestaña Active rules (Reglas activas), desde donde podrá habilitarla cuando sea necesario.

  

Definición de la lógica de consulta de regla y configuración de los valores

En la pestaña Establecer la lógica de la regla, puede escribir una consulta directamente en el campo Consulta de la regla, o bien crearla en Log Analytics y, después, copiarla y pegarla aquí.

• Las consultas se escriben en el lenguaje de consulta de Kusto (KQL). Obtenga más información sobre los conceptos y las consultas de KQL, y vea esta práctica guía de referencia rápida.

• En el ejemplo que se muestra en esta captura de pantalla se consulta la tabla SecurityEvent para mostrar un tipo de eventos de inicio de sesión de Windows con errores.

  

• Aquí tiene otra consulta de ejemplo que le alertará cuando se cree una cantidad anómala de recursos en Azure Activity.

  AzureActivity
  | where OperationName == "Create or Update Virtual Machine" or OperationName =="Create Deployment"
  | where ActivityStatus == "Succeeded"
  | make-series dcount(ResourceId)  default=0 on EventSubmissionTimestamp in range(ago(7d), now(), 1d) by Caller
  

  Importante

  Le recomendamos que la consulta use un analizador del Modelo avanzado de información de seguridad (ASIM) y no una tabla nativa. Esto garantizará que la consulta admita cualquier origen de datos relevante, actual o futuro, en lugar de un origen de datos único.

  Nota

  Procedimientos recomendados de consulta de reglas:

  • La longitud de la consulta debe ser de entre 1 y 10 000 caracteres y no puede contener "search *" ni "union *". Puede usar funciones definidas por el usuario para superar la limitación de longitud de consulta.

  • No se admite el uso de funciones ADX para crear consultas de Azure Data Explorer en la ventana de consulta de Log Analytics.

  • Al usar la función bag_unpack en una consulta, si se proyectan las columnas como campos mediante "project field1" y la columna no existe, se producirá un error en la consulta. Para evitar que esto suceda, debe proyectar la columna de la siguiente manera:

    • project field1 = column_ifexists("field1","")

Enriquecimiento de alertas

• Use la sección de configuración de asignación de entidades para asignar parámetros de los resultados de las consultas a entidades reconocidas por Microsoft Sentinel. Las entidades enriquecen la salida de las reglas (alertas e incidentes) con datos esenciales que actúan como bloques de creación de cualquier proceso de investigación y de las acciones de corrección posteriores. También son los criterios por los que puede agrupar las alertas en incidentes en la pestaña Configuración de los incidentes.

  Obtenga más información sobre las entidades en Microsoft Sentinel.

  Consulte Asignación de campos de datos a entidades en Microsoft Sentinel para obtener instrucciones completas de asignación de entidades, junto con información importante sobre las limitaciones y la compatibilidad con versiones anteriores.

• Use la sección configuración de Detalles personalizados para extraer elementos de datos de eventos de la consulta y mostrarlos en las alertas generadas por esta regla, lo que le proporciona visibilidad inmediata del contenido del evento en sus alertas e incidentes.

  Obtenga más información sobre la exposición de detalles personalizados en alertas y consulte las instrucciones completas.

• Use la sección de configuración de Detalles de alertas para invalidar los valores predeterminados de las propiedades de la alerta con detalles de los resultados de la consulta subyacente. Los detalles de la alerta le permiten mostrar, por ejemplo, la dirección IP o el nombre de cuenta de un atacante en el título de la propia alerta, por lo que aparecerá en la cola de incidentes. Esto ofrece una imagen mucho más completa y clara del panorama de las amenazas.

  Consulte las instrucciones completas sobre cómo personalizar los detalles de la alerta.

Nota

El límite de tamaño de una alerta completa es de 64 KB.

• Las alertas que crezcan más de 64 KB se truncarán. A medida que se identifican las entidades, se agregan a la alerta una por una hasta que el tamaño de la alerta alcanza los 64 KB y las entidades restantes se descartan de la alerta.

• Los demás enriquecimientos de alertas también contribuyen al tamaño de la alerta.

• Para reducir el tamaño de la alerta, use el operador project-away de la consulta para quitar los campos innecesarios. (Considere también el operador project si solo hay algunos campos que necesite guardar).

Programación de consultas y umbral de alertas

• En la sección Query scheduling (Programación de consultas), establezca los siguientes parámetros:

  

  • Establezca la opción Ejecutar consulta cada para controlar la frecuencia de ejecución de la consulta (puede establecer frecuencias de 5 minutos o de una vez cada 14 días).

  • Establezca Buscar datos del último para determinar el periodo de los datos que cubre la consulta (por ejemplo, puede consultar los 10 últimos minutos de datos o las 6 últimas horas de datos). El máximo es de 14 días.

  • Para la nueva opción Iniciar ejecución (en versión preliminar):

    • Déjela establecida en Automáticamente para continuar con el comportamiento original: la regla se ejecutará por primera vez inmediatamente después de crearse y después de eso en el intervalo establecido en la opción Ejecutar la consulta cada.

    • Cambie el modificador a En un momento específico si quiere determinar cuándo se ejecuta la regla por primera vez, en lugar de que se ejecute inmediatamente. A continuación, elija la fecha con el selector de calendario y especifique la hora en el formato del ejemplo que se muestra.

      

      Las ejecuciones futuras de la regla se producirán en el intervalo especificado después de la primera ejecución.

    La línea de texto de la opción Iniciar ejecución (con el icono de información a la izquierda) resume la programación de consultas actual y la configuración de búsqueda.

    Nota

    Intervalos de consulta y período de retrospectiva

    Estos dos valores son independientes entre sí, hasta cierto punto. Puede ejecutar una consulta a un intervalo corto que abarque un periodo mayor que el intervalo (teniendo en efecto consultas que se solapan), pero no puede ejecutar una consulta a un intervalo que supere el periodo de cobertura, ya que, de lo contrario tendrá lagunas en la cobertura general de la consulta.

    Retraso de la ingesta

    Para tener en cuenta la latencia que puede producirse entre la generación de un evento en el origen y su ingesta en Microsoft Sentinel, y para garantizar una cobertura completa sin duplicación de datos, Microsoft Sentinel ejecuta reglas de análisis programadas con un retraso de cinco minutos desde su hora programada.

    Para más información, consulte Control del retraso de ingesta en las reglas de análisis programadas.

• Use la sección Umbral de alerta para definir el nivel de confidencialidad de la regla. Por ejemplo, en Generar alerta cuando el número de resultados de consulta, seleccione Es mayor que y escriba el número 1000 si desea que la regla genere una alerta solo si la consulta genera más de 1000 resultados cada vez que se ejecuta. Este es un campo obligatorio, por lo que si no desea establecer un umbral (es decir, si desea que su alerta registre todos los eventos), escriba 0 en el campo numérico.

Simulación de resultados

En el área Simulación de resultados de la derecha del asistente, seleccione Probar con los datos actuales y Microsoft Sentinel mostrará un gráfico de los resultados (eventos de registro) que la consulta habría generado en las últimas 50 ejecuciones, según la programación definida actualmente. Si modifica la consulta, vuelva a seleccionar Probar con los datos actuales para actualizar el gráfico. El gráfico muestra el número de resultados en un periodo definido, lo que determina la configuración de la sección Query scheduling (Programación de consultas).

Este es el aspecto que podría tener la simulación de resultados en la consulta de la captura de pantalla anterior. El lado izquierdo es la vista predeterminada, mientras que el lado derecho es lo que se ve al mantener el mouse sobre un momento dado del gráfico.

Si percibe que la consulta desencadenará alertas excesivas o demasiado frecuentes, puede experimentar con la configuración de las secciones Programación de consultas y Umbral de alerta y seleccionar la opción de volver a Test with current data (Probar con los datos actuales).

Agrupación de eventos y supresión de reglas

• En Agrupación de eventos, elija una de las dos formas de controlar la agrupación de eventos en alertas:

  • Agrupar todos los eventos en una misma alerta (la configuración predeterminada). La regla genera una única alerta cada vez que se ejecuta, siempre y cuando la consulta devuelva más resultados de los especificados en el umbral de alerta anterior. La alerta incluye un resumen de todos los eventos que se devuelven en los resultados.

  • Desencadenar una alerta para cada evento. La regla genera una alerta única para cada evento devuelto por la consulta. Esto resulta útil si quiere que los eventos se muestren individualmente, o si quiere agruparlos según determinados parámetros (por ejemplo, por usuario, nombre de host o cualquier otro elemento). Puede definir estos parámetros en la consulta.

    En la actualidad, el número de alertas que puede generar una regla se limita a 150. Si en una regla determinada, Agrupación de eventos se establece en Desencadenar una alerta para cada evento y la consulta de la regla devuelve más de 150 eventos, cada uno de los primeros 149 eventos generará una alerta única y la 150ª alerta resumirá todo el conjunto de eventos devueltos. En otras palabras, la 150ª alerta es lo que habría generado en la opción Agrupar todos los eventos en una misma alerta.

    Si elige esta opción, Microsoft Sentinel agregará un nuevo 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	Registro comprimido del evento que generó esta instancia de la alerta.	El evento que generó esta instancia de la alerta; limitado a 10240 bytes
    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 normalmente se comporta el campo Query. El resultado de este campo adicional es que se ha resuelto el problema descrito por el primer elemento de la sección Solución de problemas siguiente.

  Nota

  ¿En qué se diferencian los eventos y las alertas?

  • Un evento es una descripción de una única repetición de una acción. Por ejemplo, una sola entrada de un archivo de registro podría contar como un evento. En este contexto, un evento hace referencia a un único resultado devuelto por una consulta en una regla de análisis.

  • Una alerta es una colección de eventos que, en conjunto, son importantes desde el punto de vista de la seguridad. Una alerta podría contener un solo evento si el evento tuviera implicaciones de seguridad importantes (por ejemplo, un inicio de sesión administrativo desde un país o región extranjero fuera de horas de oficina).

  • Por cierto, ¿qué son los incidentes? La lógica interna de Microsoft Sentinel crea incidentes a partir de alertas o de grupos de alertas. La cola de incidentes es el punto focal del trabajo del analista del centro de operaciones de seguridad: evaluación de prioridades, investigación y corrección.

  Microsoft Sentinel ingiere eventos sin procesar de algunos orígenes de datos y alertas ya procesadas de otros usuarios. Es importante tener en cuenta con cuál es el que se está tratando en cualquier momento.

• In the Suppression (Supresión), en el valor Stop running query after alert is generated (Detener la ejecución de la consulta después de que se genere una alerta), seleccione On (Activar) si, una vez que recibe la alerta, desea suspender la operación de esta reglar durante un periodo que supere el intervalo de consulta. Si lo activa, en Stop running query for (Detener la ejecución de la consulta durante), seleccione el periodo durante el que debe detenerse la consulta, con un máximo de 24 horas.

Configuración de la creación de incidentes

En la pestaña Configuración de incidentes, puede elegir si Microsoft Sentinel convierte las alertas en incidentes sobre los que se pueden realizar acciones y cómo lo hace. Si esta pestaña no se modifica, Microsoft Sentinel creará un solo incidente independiente a partir de todas y cada una de las alertas. Puede elegir que no se creen incidentes o agrupar varias alertas en un solo incidente. Para ello, solo debe cambiar el valor de esta pestaña.

Por ejemplo:

Configuración de los incidentes

En la sección Configuración de los incidentes, el valor predeterminado de Crear incidentes a partir de las alertas desencadenadas por esta regla de análisis es Habilitado, lo que significa que Microsoft Sentinel creará un solo incidente independiente para cada una de las alertas que desencadene la regla.

• Si no desea que esta regla provoque la aparición de incidentes (por ejemplo, si esta regla es solo para recopilar información para su posterior análisis), seleccione Disabled (Deshabilitado).

• Si desea que se cree un solo incidente a partir de un grupo de alertas, en lugar de uno para cada alerta, consulte la sección siguiente.

Agrupación de alertas

En la sección Alert grouping (Agrupación de alertas), si desea que se genere un solo incidente a partir de un grupo de hasta 150 alertas similares o recurrentes (consulte la nota), en Group related alerts, triggered by this analytics rule, into incidents (Agrupar en incidentes alertas relacionadas desencadenadas por esta regla de análisis) seleccione Enabled (Habilitado) y establezca los siguientes parámetros.

• Limite el grupo a las alertas creadas en el período de tiempo seleccionado: Determine el período de tiempo en el que se agruparán las alertas similares o periódicas. Todas las alertas correspondientes que se encuentren dentro de este periodo de tiempo generarán colectivamente un incidente o un conjunto de incidentes (en función de la configuración de agrupación que encontrará a continuación). Las alertas que aparezcan fuera de este periodo de tiempo generarán un incidente, o conjunto de incidentes, independientes.

• Agrupe las alertas desencadenadas por esta regla de análisis en un único incidente por: elija el motivo por el que se agruparán las alertas:

  Opción	Descripción
  Agrupar las alertas en un solo incidente si todas las entidades coinciden	Las alertas se agrupan si comparten los mismos valores entre todas las entidades asignadas, definidas en la pestaña Set rule logic (Establecer lógica de regla) anterior. Esta es la configuración recomendada.
  Agrupar todas las alertas desencadenadas por esta regla en un único incidente	Todas las alertas que genera esta regla se agrupan aunque no compartan valores idénticos.
  Agrupar las alertas en un solo incidente si las entidades seleccionadas y los detalles coinciden	Las alertas se agrupan si comparten valores idénticos para todas las entidades asignadas, los detalles de las alertas y los detalles personalizados seleccionados en las listas desplegables correspondientes. Es posible que quiera usar esta configuración si, por ejemplo, quiere crear incidentes independientes basados en las direcciones IP de origen o de destino, o si desea agrupar las alertas que coincidan con una entidad y gravedad específicas. Nota: Al seleccionar esta opción, debe tener al menos un tipo de entidad o campo seleccionado para la regla. De lo contrario, se producirá un error en la validación de la regla y esta no se creará.

• Vuelva a abrir los incidentes coincidentes cerrados: si se ha resuelto y cerrado un incidente y, posteriormente, se genera otra alerta que habría pertenecido a ese incidente, establezca esta opción en Enabled (Habilitado) si quiere que el incidente cerrado se vuelva a abrir, o bien déjela como Disabled (Deshabilitado) si quiere que la alerta cree un incidente nuevo.

  Nota

  Se pueden agrupar hasta 150 alertas en un solo incidente.

  • El incidente solo se creará después de que se hayan generado todas las alertas. Todas las alertas se agregarán al incidente inmediatamente después de su creación.

  • Si hay más de 150 alertas generadas por una regla que las agrupa en un solo incidente, se generará un nuevo incidente con los mismos detalles del incidente que el original, y las alertas sobrantes se agruparán en el nuevo incidente.

Establecimiento de respuestas automatizadas y creación de la regla

En la pestaña Respuestas automatizadas, puede usar las reglas de automatización para establecer respuestas automatizadas que se produzcan en cualquiera de estos tres tipos de ocasiones:

• Cuando esta regla de análisis genera una alerta.
• Cuando se crea un incidente con alertas generadas por esta regla de análisis.
• Cuando se actualiza un incidente con alertas generadas por esta regla de análisis.

La cuadrícula que se muestra en Reglas de automatización, muestra las reglas de automatización que ya se aplican a esta regla de análisis (asumiendo que cumple las condiciones definidas en esas reglas). Para editar cualquiera de estos puntos suspensivos, seleccione los puntos suspensivos al final de cada fila. O bien, puede crear una nueva regla de automatización.

Use reglas de automatización para realizar evaluaciones de prioridades básicas, asignaciones, flujos de trabajo y cierres de incidentes.

Automatice tareas más complejas e invoque respuestas de sistemas remotos para corregir amenazas mediante una llamada a los cuadernos de estrategias de estas reglas de automatización. Puede hacerlo tanto para incidentes como para alertas individuales.

• Para obtener más información e instrucciones sobre cómo crear cuadernos de estrategias y reglas de automatización, consulte Automatizar las respuestas frente a amenazas.

• Para obtener más información sobre cuándo usar el desencadenador creado por el incidente, el desencadenador actualizado por el incidente o el desencadenador creado por la alerta , consulte Uso de desencadenadores y acciones en los cuadernos de estrategias de Microsoft Sentinel.

  

• En Automatización de alertas (clásico) en la parte inferior de la pantalla, verá los cuadernos de estrategias que haya configurado para que se ejecuten automáticamente cuando se genere una alerta mediante el método anterior.

  • A partir de junio de 2023, ya no puede agregar cuadernos de estrategias a esta lista. Los cuadernos de estrategias que ya aparecen aquí seguirán ejecutándose hasta que este método esté en desuso, a partir de marzo de 2026.

  • Si sigue teniendo alguno de los cuaderno de estrategias enumerados aquí, debe crear una regla de automatización basada en el desencadenador creado por la alerta e invocar el cuaderno de estrategias desde allí. Una vez hecho esto, seleccione los puntos suspensivos al final de la línea del cuaderno de estrategias que se muestra aquí y seleccione Quitar. Consulte Migración de cuadernos de estrategias de desencadenamiento de alertas de Microsoft Sentinel a reglas de automatización para ver las instrucciones completas.

Seleccione Revisar y crear para revisar todos los valores de configuración de la nueva regla de análisis. Cuando aparezca el mensaje “Validación superada”, seleccione Crear.

Visualización de la regla y su salida

• Puede encontrar la regla personalizada recién creada (de tipo "Programado") en la tabla en la pestaña Reglas activas de la pantalla Análisis principal. Desde esta lista puede habilitar, deshabilitar o eliminar cada regla.

• Para ver los resultados de las reglas de análisis que cree, vaya a la página Incidentes, donde puede evaluar los incidentes, investigarlos y solucionar las amenazas.

• Puede actualizar la consulta de regla para excluir falsos positivos. Para obtener más información, consulte Control de falsos positivos en Microsoft Sentinel.

Nota

Las alertas generadas en Microsoft Sentinel están disponibles a través de Seguridad de Microsoft Graph. Para obtener más información, vea la documentación sobre alertas de Seguridad de Microsoft Graph.

Exportación de la regla a una plantilla de ARM

Si desea empaquetar la regla para administrarla e implementarla como código, puede exportarla fácilmente a una plantilla de Azure Resource Manager (ARM). También puede importar reglas de archivos de plantilla para verlos y editarlos en la interfaz de usuario.

Solución de problemas

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, puede ver los resultados de una consulta en un momento posterior cuando haya vuelto a los resultados de un incidente relacionado.

• 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 aparecerá 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.

Nota

Este problema se ha resuelto mediante la adición de un nuevo campo, OriginalQuery, a los resultados cuando se selecciona esta opción de agrupación de eventos. Consulte la descripción anterior.

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

El error transitorio se produce debido a una circunstancia que es temporal y pronto volverá a la normalidad, momento en el que la ejecución de la regla se realizará 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 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 siguiente).
• 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:

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

Puede determinar fácilmente si se ha deshabilitado automáticamente alguna regla si ordena la lista de reglas por nombre. Las reglas deshabilitadas automáticamente estarán en la parte superior de la lista o cerca de ella.

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, toma los mismos tres pasos mencionados anteriormente para los otros 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 (consulte la lista anterior) sería el caso de un 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 datos consultados por la regla y que este acceso se mantendrá 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. Para estos tipos de reglas, las credenciales del usuario que crearon la regla se aplican a la regla en lugar de a un token de acceso independiente, de modo que cuando el usuario ya no tenga acceso al otro inquilino, la regla dejará de funcionar.

Si opera Microsoft Sentinel en un escenario entre suscripciones o inquilinos, tenga en cuenta que si 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á 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

Al usar reglas de análisis para detectar amenazas de Microsoft Sentinel, asegúrese de habilitar todas las reglas asociadas a los orígenes de datos conectados con el fin de garantizar la cobertura de seguridad completa para su entorno. La manera más eficaz de habilitar las reglas de análisis es hacerlo directamente en la página del conector de datos, que enumera las reglas relacionadas. Para obtener más información, consulte Conexión con orígenes de datos.

También puede insertar reglas en Microsoft Sentinel mediante API y PowerShell, aunque para ello es necesario un trabajo adicional. Al usar la API o PowerShell, debe exportar las reglas a JSON antes de habilitar las reglas. La API o PowerShell pueden ser útiles al habilitar reglas en varias instancias de Microsoft Sentinel con una configuración idéntica en cada instancia.

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.