Automatización de la respuesta a amenazas en Microsoft Sentinel con las reglas de automatización

En este artículo se explica qué son las reglas de automatización de Microsoft Sentinel y cómo usarlas para implementar las operaciones de orquestación de seguridad, automatización y respuesta (SOAR), con el fin de aumentar la eficacia de su centro de operaciones de seguridad y ahorrar tiempo y recursos.

Importante

Microsoft Sentinel está disponible como parte de la versión preliminar pública de la plataforma unificada de operaciones de seguridad en el portal de Microsoft Defender. Para obtener más información, consulte Microsoft Sentinel en el portal de Microsoft Defender.

¿Qué son las reglas de automatización?

Las reglas de automatización son una manera de administrar de forma centralizada la automatización en Microsoft Sentinel, ya que permite definir y coordinar un pequeño conjunto de reglas que se pueden aplicar en diferentes escenarios.

Las reglas de automatización se aplican a las siguientes categorías de casos de uso:

  • Realizar tareas básicas de automatización para el control de incidentes sin usar cuadernos de estrategias. Por ejemplo:

    • Adición de tareas de incidentes para que los analistas las sigan.
    • Suprimir incidentes ruidosos.
    • Evaluar nuevos incidentes cambiando su estado de Nuevo a Activo y asignando un propietario.
    • Etiquetar los incidentes para clasificarlos.
    • Escalar un incidente mediante la asignación de un nuevo propietario.
    • Cerrar los incidentes resueltos, especificando un motivo y agregando comentarios.
  • Automatizar las respuestas de varias reglas de análisis a la vez.

  • Controlar el orden de las acciones que se ejecutan.

  • Inspeccionar el contenido de un incidente (alertas, entidades y otras propiedades) y realizar más acciones llamando a un cuaderno de estrategias.

  • Las reglas de automatización también pueden ser el mecanismo por el que se ejecuta un cuaderno de estrategias en respuesta a una alertano asociada a un incidente.

En resumen, las reglas de automatización agilizan el uso de la automatización en Microsoft Sentinel y le permiten simplificar flujos de trabajo complejos de los procesos de orquestación de respuesta a amenazas.

Componentes

Las reglas de automatización están conformadas por varios componentes:

  • Desencadenadores que definen qué tipo de evento de incidente hará que la regla se ejecute, en base a...
  • Condiciones que determinarán las circunstancias exactas en las que se ejecutará y realizará la regla...
  • Acciones para cambiar el incidente de alguna manera o llamar a un cuaderno de estrategias.

Desencadenadores

Las reglas de automatización se desencadenan cuando se crea o actualiza un incidente o cuando se crea una alerta. Recuerde que los incidentes incluyen alertas, y las reglas de análisis pueden crear tanto los incidentes como las alertas. Hay varios tipos de reglas de análisis, como se explica en Detección de amenazas con reglas de análisis integradas en Microsoft Sentinel.

En la tabla siguiente se muestran los distintos escenarios posibles que harán que se ejecute una regla de automatización.

Tipo de desencadenador Eventos que hacen que se ejecute la regla
Al crear un incidente Plataforma de operaciones de seguridad unificada en Microsoft Defender:
  • Se crea un nuevo incidente en el portal de Microsoft Defender.

    Microsoft Sentinel no incorporado a la plataforma unificada:
  • Una regla de análisis crea un nuevo incidente.
  • Se ingiere un incidente de Microsoft Defender XDR.
  • Se crea un incidente manualmente.
  • Al actualizar un incidente
  • Se cambia el estado de un incidente (cerrado, reabierto o evaluación de prioridades).
  • Se asigna o cambia el propietario de un incidente.
  • Se aumenta o reduce la gravedad de un incidente.
  • Se agregan alertas a un incidente.
  • Se agregan comentarios, etiquetas o tácticas a un incidente.
  • Cuándo se crea la alerta
  • Una alerta se crea mediante una regla de análisis Programada de Microsoft Sentinel o NRT.
  • ¿Automatización basada en incidentes o basada en alertas?

    Ahora que tanto la automatización de incidentes como la automatización de alertas se controlan de forma centralizada mediante reglas de automatización, así como con los cuadernos de estrategias, ¿cómo debe elegir cuándo usar cada opción?

    En la mayoría de los casos de uso, la automatización desencadenada por incidentes es el enfoque preferible. En Microsoft Sentinel, un incidente es un "archivo de casos", es decir, una agregación de todas las pruebas pertinentes para una investigación específica. Es un contenedor de alertas, entidades, comentarios, colaboración y otros artefactos. A diferencia de las alertas que son elementos únicos de prueba, los incidentes son modificables, tienen el estado más actualizado y se pueden enriquecer con comentarios, etiquetas y marcadores. El incidente le permite realizar un seguimiento de la historia de ataque que sigue evolucionando con la adición de nuevas alertas.

    Por estos motivos, tiene más sentido crear la automatización en torno a incidentes. Por lo tanto, la manera más adecuada de crear cuadernos de estrategias es basarlos en el desencadenador de incidentes de Microsoft Sentinel en Azure Logic Apps.

    La razón principal para usar la automatización desencadenada por alertas es responder a las alertas generadas por reglas de análisis que no crean incidentes (es decir, donde la creación de incidentes se ha deshabilitado en la pestaña Configuración de incidentes del Asistente para reglas de análisis).

    Este motivo es especialmente relevante cuando el área de trabajo de Microsoft Sentinel se incorpora a la plataforma unificada de operaciones de seguridad, ya que toda la creación de incidentes se produce en XDR de Microsoft Defender y, por tanto, las reglas de creación de incidentes en Microsoft Sentinel deben deshabilitarse.

    Incluso aunque no se incorpore al portal unificado, puede decidir usar la automatización desencadenada por alertas si quiere usar otra lógica externa para determinar si y cómo se crean incidentes a partir de alertas, así como si y cómo se agrupan las alertas en incidentes. Por ejemplo:

    • Un cuaderno de estrategias se puede desencadenar mediante una alerta que no tiene un incidente asociado, enriquecer la alerta con información de otros orígenes y, en función de alguna lógica externa, decidir si se va a crear un incidente o no.

    • Un cuaderno de estrategias se puede desencadenar mediante una alerta y, en lugar de crear un incidente, busque un incidente existente adecuado al que agregar la alerta. Obtenga más información sobre la expansión de incidentes.

    • Un cuaderno de estrategias se puede desencadenar mediante una alerta y notificar al personal de SOC de la alerta, para que el equipo pueda decidir si va a crear o no un incidente.

    • Un cuaderno de estrategias se puede desencadenar mediante una alerta y enviar la alerta a un sistema externo de vales para la creación y administración de incidentes, creando un nuevo vale para cada alerta.

    Nota:

    Condiciones

    Se pueden definir conjuntos complejos de condiciones para controlar cuándo se deberían ejecutarse las acciones (véase a continuación). Estas condiciones incluyen el evento que desencadena la regla (incidente creado o actualizado, o bien alerta creada), los estados o valores de las propiedades y las propiedades de entidad del incidente (solo para el desencadenador de incidentes), así como la regla o reglas de análisis que generaron el incidente o la alerta.

    Cuando se desencadena una regla de automatización, comprueba la alerta o el incidente desencadenadores en las condiciones definidas en la regla. Para los incidentes, las condiciones basadas en propiedades se evalúan según el estado actual de la propiedad en el momento en que se produce la evaluación, o según los cambios en el estado de la propiedad (consulte a continuación para obtener más información). Dado que un único evento de creación o actualización de incidentes podría desencadenar varias reglas de automatización, el orden en el que se ejecutan (ver a continuación) hace una diferencia en determinar el resultado de la evaluación de las condiciones. Las acciones definidas en la regla solo se ejecutarán si se cumplen todas las condiciones.

    Desencadenador de creación de incidentes

    En el caso de las reglas definidas mediante el desencadenador Cuando se crea un incidente, puede definir condiciones que comprueben el estado actual de los valores de una lista determinada de propiedades de incidentes mediante uno o varios de los operadores siguientes:

    Valor de una propiedad de incidente

    • es igual o no es igual al valor definido en la condición.
    • contiene o no contiene el valor definido en la condición.
    • empieza o no empieza con el valor definido en la condición.
    • termina o no termina con el valor definido en la condición.

    El estado actual de este contexto hace referencia al momento en que se evalúa la condición; es decir, el momento en que se ejecuta la regla de automatización. Si se define más de una regla de automatización para ejecutarse en respuesta a la creación de este incidente, los cambios realizados en el incidente por una regla de automatización de ejecución anterior se consideran el estado actual de las reglas de ejecución posterior.

    Desencadenador de actualización de incidentes

    Las condiciones evaluadas en las reglas definidas mediante el desencadenador Cuando se actualiza un incidente incluyen todas las enumeradas para el desencadenador de creación de incidentes. Pero el desencadenador de actualización incluye más propiedades que se pueden evaluar.

    Una de estas propiedades es Actualizado por. Esta propiedad permite realizar un seguimiento del tipo de origen que realizó el cambio en el incidente. Puede crear una condición que evalúe si el incidente se actualizó mediante uno de los siguientes valores, en función de si ha incorporado el área de trabajo a la plataforma unificada de operaciones de seguridad:

    • Una aplicación, incluidas las aplicaciones en los portales de Azure y Defender.
    • Un usuario, incluidos los cambios realizados por los usuarios en los portales de Azure y Defender.
    • AIR, para las actualizaciones de investigación y respuesta automatizadas en Microsoft Defender for Office 365
    • Agrupación de alertas (que agregó alertas al incidente), incluidas agrupaciones de alertas realizadas tanto por reglas de análisis como por lógica de correlación XDR integrada de Microsoft Defender
    • Un cuaderno de estrategias
    • Una regla de automatización
    • Otros, si ninguno de los valores anteriores se aplica

    Con esta condición, por ejemplo, puede indicar a esta regla de automatización que se ejecute en cualquier cambio realizado en un incidente, excepto si lo realizó otra regla de automatización.

    Además, el desencadenador de actualización también usa otros operadores que comprueban los cambios de estado en los valores de las propiedades del incidente, así como su estado actual. Se cumpliría una condición de cambio de estado si:

    El valor de la propiedad de un incidente se ha

    • cambiado (independientemente del valor real antes o después).
    • cambiado del valor definido en la condición.
    • cambiado al valor definido en la condición.
    • agregado a (esto se aplica a las propiedades con una lista de valores).

    Propiedad Etiqueta: individual frente a colección

    La propiedad de incidente Etiqueta es una colección de elementos individuales donde un único incidente puede tener varias etiquetas aplicadas. Puede definir condiciones que comprueben cada etiqueta de la colección individualmentey condiciones que comprueben la colección de etiquetas como una unidad.

    • Los operadores de Cualquier etiqueta individual comprueban la condición en cada etiqueta de la colección. La evaluación es true cuando al menos una etiqueta satisface la condición.
    • Los operadores de Colección de todas las etiquetas comprueban la condición en la colección de etiquetas como una sola unidad. La evaluación es true solo si la colección en su conjunto satisface la condición.

    Esta distinción es importante cuando la condición es negativa (no contiene) y algunas etiquetas de la colección cumplen la condición y otras no.

    Veamos un ejemplo en el que la condición es Etiquetas no contiene "2024", y tiene dos incidentes, cada uno con dos etiquetas:

    \ Incidentes ▶
    Condición ▼ \
    Incidente 1
    Etiqueta 1: 2024
    Etiqueta 2: 2023
    Incidente 2
    Etiqueta 1: 2023
    Etiqueta 2: 2022
    Cualquier etiqueta individual
    no contiene
    "2024"
    VERDADERO VERDADERO
    Colección de todas las etiquetas
    no contiene
    "2024"
    FALSO VERDADERO

    En este ejemplo, en Incidente 1:

    • Si la condición comprueba individualmente cada etiqueta, puesto que hay al menos una etiqueta que satisface la condición (que no contiene "2024"), la condición general es true.
    • Si la condición comprueba todas las etiquetas del incidente como una sola unidad, puesto que hay al menos una etiqueta que no cumple la condición (que contiene "2024"), la condición general es false.

    En Incidente 2, el resultado será el mismo, independientemente del tipo de condición definido.

    Desencadenador de creación de alertas

    Actualmente, la única condición que se puede configurar para el desencadenador de creación de alertas es el conjunto de reglas de análisis para las que se ejecutará la regla de automatización.

    Acciones

    Se pueden definir acciones para que se ejecuten cuando se cumplan las condiciones (véase más arriba). Puede definir muchas acciones en una regla y puede elegir el orden en el que se ejecutarán (véase a continuación). Las siguientes acciones se pueden definir mediante reglas de automatización, sin necesidad de la funcionalidad avanzada de un cuaderno de estrategias:

    • Adición de una tarea a un incidente: puede crear una lista de comprobación de tareas para que los analistas la sigan a lo largo de los procesos de evaluación de prioridades, investigación y corrección del incidente, y garantizar que no se omitan pasos críticos.

    • Cambiar el estado de un incidente para mantener el flujo de trabajo actualizado.

      • Al cambiar a "closed", especifique el motivo de cierre y agregue un comentario. Esto le ayudará a realizar un seguimiento del rendimiento y la eficacia, y a realizar ajustes para reducir los falsos positivos.
    • Cambiar la gravedad de un incidente: puede volver a evaluar y cambiar la prioridad en función de la presencia, la ausencia, los valores o los atributos de las entidades implicadas en el incidente.

    • Asignar un incidente a un propietario: esto le ayuda a dirigir los tipos de incidentes al personal más adecuado para que los solucionen, o al que esté más disponible.

    • Agregar una etiqueta a un incidente: útil para clasificar incidentes por asunto, atacante o cualquier otro denominador común.

    Además, puede definir una acción para ejecutar un cuaderno de estrategias con el fin de realizar acciones de respuesta más complejas, incluidas las que impliquen sistemas externos. Los cuadernos de estrategias disponibles para usarse en una regla de automatización dependen del desencadenador en el que se basan los cuadernos de estrategias y la regla de automatización: solo se pueden ejecutar cuadernos de estrategias desencadenadores de incidentes a partir de reglas de automatización de desencadenadores de incidentes y solo se pueden ejecutar cuadernos de estrategias de desencadenador de alertas a partir de reglas de automatización de desencadenadores de alertas. Puede definir varias acciones que llamen a cuadernos de estrategias o combinaciones de cuadernos de estrategias y otras acciones. Las acciones se ejecutarán en el orden en que se muestran en la regla.

    Los cuadernos de estrategias que usan la versión de Azure Logic Apps (estándar o consumo) estarán disponibles para ejecutarse a partir de reglas de automatización.

    Fecha de expiración

    Puede definir una fecha de expiración para una regla de automatización. La regla se deshabilitará después de esa fecha. Esto resulta útil para controlar (es decir, cerrar) los incidentes "irrelevantes" causados por las actividades planeadas de tiempo limitado, como las pruebas de penetración.

    Pedido

    Puede definir el orden en el que se ejecutarán las reglas de automatización. Las reglas de automatización posteriores evaluarán las condiciones del incidente en función de su estado después de que las reglas de automatización anteriores hayan actuado.

    Por ejemplo, si la "Primera regla de automatización" cambió la gravedad de un incidente de Media a Baja y se definió una "Segunda regla de automatización" para que se ejecute solo en incidentes con una gravedad Media o superior, la segunda no se ejecutará en dicho incidente.

    El orden de las reglas de automatización que agregan tareas de incidentes determina el orden en que las tareas aparecerán en un incidente determinado.

    Las reglas basadas en el desencadenador de actualización tienen su propia cola de pedidos independiente. Si estas reglas se desencadenan para ejecutarse en un incidente recién creado (mediante un cambio realizado por otra regla de automatización), solo se ejecutarán después de que se hayan ejecutado todas las reglas aplicables basadas en el desencadenador de creación.

    Notas sobre el orden de ejecución y la prioridad

    • Establecer el número de orden en las reglas de automatización determina su orden de ejecución.
    • Cada tipo de desencadenador mantiene su propia cola.
    • En el caso de las reglas creadas en Azure Portal, el campo de orden se rellenará automáticamente con el número que sigue al número más alto que usan las reglas existentes del mismo tipo de desencadenador.
    • Sin embargo, para las reglas creadas de otras maneras (línea de comandos, API, etc.), el número de pedido debe asignarse manualmente.
    • No hay ningún mecanismo de validación que impida que varias reglas tengan el mismo número de pedido, incluso dentro del mismo tipo de desencadenador.
    • Puede permitir que dos o más reglas del mismo tipo de desencadenador tengan el mismo número de orden, si no le importa el orden en el que se ejecutan.
    • Para las reglas del mismo tipo de desencadenador con el mismo número de orden, el motor de ejecución selecciona aleatoriamente qué reglas se ejecutarán en qué orden.
    • Para las reglas de diferentes tipos de desencadenador de incidentes, todas las reglas aplicables con el tipo de desencadenador de creación de incidentes se ejecutarán primero (según sus números de orden), y solo entonces lo harán las reglas con el tipo de desencadenador de actualización de incidentes (según sus números de orden).
    • Las reglas siempre se ejecutan secuencialmente, nunca en paralelo.

    Nota:

    Después de la incorporación a la plataforma unificada de operaciones de seguridad, si se realizan varios cambios en el mismo incidente en un período de cinco a diez minutos, se envía una única actualización a Microsoft Sentinel, con solo el cambio más reciente.

    Casos de uso y escenarios comunes

    Tareas de incidentes

    Las reglas de automatización permiten estandarizar y formalizar los pasos necesarios para la evaluación, investigación y corrección de incidentes mediante la creación de tareas que se pueden aplicar a un único incidente, a grupos de incidentes o a todos los incidentes, según las condiciones establecidas en la regla de automatización y la lógica de detección de amenazas en las reglas de análisis subyacentes. Las tareas que se aplican a un incidente aparecen en la página del incidente, de modo que los analistas tienen a la vista una lista completa de acciones que deben realizar y no omitirán ningún paso crítico.

    Automatización desencadenada por incidentes y alertas

    Las reglas de automatización se pueden desencadenar mediante la creación o actualización de incidentes y también mediante la creación de alertas. Estas repeticiones pueden desencadenar cadenas de respuesta automatizadas, que pueden incluir cuadernos de estrategias (se requieren permisos especiales).

    Desencadenamiento de cuadernos de estrategias para proveedores de Microsoft

    Las reglas de automatización proporcionan una forma de automatizar el control de las alertas de seguridad de Microsoft mediante la aplicación de estas reglas a los incidentes creados a partir de alertas. Las reglas de automatización pueden llamar a los cuadernos de estrategias (se requieren permisos especiales) y pasarles los incidentes junto con todos sus detalles, incluidas las alertas y entidades. En general, los procedimientos recomendados de Microsoft Sentinel dictan el uso de la cola de incidentes como punto crucial de las operaciones de seguridad.

    Las siguientes son algunas alertas de seguridad de Microsoft:

    • Protección de Microsoft Entra ID
    • Microsoft Defender for Cloud
    • Microsoft Defender for Cloud Apps
    • Microsoft Defender para Office 365
    • Microsoft Defender para punto de conexión
    • Microsoft Defender for Identity
    • Microsoft Defender para IoT

    Secuencia de varios cuadernos de estrategias o acciones en una sola regla

    Ahora puede tener un control casi completo sobre el orden de ejecución de las acciones y cuadernos de estrategias en una única regla de automatización. También puede controlar el orden de ejecución de las reglas de automatización. Esto le permite simplificar en gran medida los cuadernos de estrategias, ya que puede reducirlos a una sola tarea o a una secuencia de tareas sencilla y directa, así como combinar estos pequeños cuadernos de estrategias de distintas maneras en reglas de automatización diferentes.

    Asignación de un cuaderno de estrategias a varias reglas de análisis a la vez

    Si tiene una tarea que quiere automatizar en todas las reglas de análisis (por ejemplo, la creación de una incidencia de soporte técnico en un sistema externo de incidencias), puede aplicar de una sola vez un cuaderno de estrategias a cualquiera de las reglas de análisis, incluidas todas las reglas futuras. Esto hace menos frustrantes las tareas de mantenimiento que son sencillas, pero repetitivas.

    Asignación automática de incidentes

    Puede asignar incidentes al propietario adecuado automáticamente. Si el centro de operaciones de seguridad tiene un analista que se especializa en una plataforma determinada, todos los incidentes relacionados con esa plataforma se pueden asignar automáticamente a dicho analista.

    Eliminación de incidentes

    Puede usar reglas para resolver automáticamente los incidentes que son falsos positivos o positivos inofensivos sin usar los cuadernos de estrategias. Por ejemplo, al ejecutar pruebas de penetración, realizar actualizaciones o mantenimiento programados, o probar procedimientos de automatización, es posible que se creen muchos incidentes falsos positivos que el SOC quiere omitir. Una regla de automatización de tiempo limitado puede cerrar automáticamente estos incidentes a medida que se crean, a la vez que los etiqueta con un descriptor de la causa de su origen.

    Automatización de tiempo limitado

    Puede agregar fechas de expiración a las reglas de automatización. Puede haber casos distintos de la supresión de incidentes que justifiquen la automatización limitada del tiempo. Es posible que quiera asignar un tipo de incidente específico a un usuario determinado (por ejemplo, un empleado en prácticas o un consultor) durante un período de tiempo concreto. Si se conoce de antemano el período de tiempo, puede hacer que la regla se deshabilite cuando deje de ser relevante sin necesidad de recordar que debe hacerlo.

    Etiquetado automático de incidentes

    Puede agregar automáticamente etiquetas de texto libre a los incidentes para agruparlos o clasificarlos según los criterios que elija.

    Casos de uso agregados por desencadenador de actualización

    Ahora que los cambios realizados en incidentes pueden desencadenar reglas de automatización, hay más escenarios abiertos a la automatización.

    Ampliar la automatización cuando evoluciona el incidente

    Puede usar el desencadenador de actualización para aplicar muchos de los casos de uso anteriores a incidentes a medida que avanza su investigación y los analistas agregan alertas, comentarios y etiquetas. Controlar la agrupación de alertas en incidentes.

    Actualizar la orquestación y notificación

    Notificar a los distintos equipos y a otro personal cuando se realicen cambios en incidentes, por lo que no perderán ninguna actualización crítica. Escalar incidentes asignándolos a nuevos propietarios e informando a los nuevos propietarios de sus asignaciones. Controlar cuándo y cómo se vuelven a abrir los incidentes.

    Mantener la sincronización con sistemas externos

    Si ha utilizado cuadernos de estrategias para crear tickets en sistemas externos cuando se crean incidentes, puede utilizar una regla de automatización de activación de actualización para llamar a un cuaderno de estrategias que actualice esos tickets.

    Ejecución de reglas de automatización

    Las reglas de automatización se ejecutan secuencialmente, según el orden que se determine. Cada regla de automatización se ejecuta na vez finalizada la ejecución de la anterior. Dentro de una regla de automatización, todas las acciones se ejecutan de manera secuencial en el orden en que se definieron.

    En una regla de automatización, las acciones del cuaderno de estrategias se pueden tratar de forma diferente en algunas circunstancias, según los criterios siguientes:

    Tiempo de ejecución del cuaderno de estrategias La regla de automatización pasa a la siguiente acción...
    Menos de un segundo Inmediatamente después de que se completa el cuaderno de estrategias
    Menos de dos minutos Hasta dos minutos después de que el cuaderno de estrategias haya empezado a ejecutarse,
    pero no más de diez segundos después de que se complete el cuaderno de estrategias
    Más de dos minutos Dos minutos después de que el cuaderno de estrategias haya empezado a ejecutarse,
    independientemente de si se completó o no

    Permisos para que las reglas de automatización ejecuten cuadernos de estrategias

    Cuando una regla de automatización ejecuta un cuaderno de estrategias, usa una cuenta de servicio especial de Microsoft Sentinel que está autorizada específicamente para ello. El uso de esta cuenta (en lugar de su cuenta de usuario) aumenta el nivel de seguridad del servicio.

    Para que una regla de automatización ejecute un cuaderno de estrategias, se deben conceder a esta cuenta permisos explícitos para acceder al grupo de recursos en el que se encuentra el cuaderno. En ese momento, cualquier regla de automatización podrá ejecutar cualquier cuaderno de estrategias de ese grupo de recursos.

    Al configurar una regla de automatización y agregar una acción para ejecutar un cuaderno de estrategias, aparecerá una lista desplegable de cuadernos. Los cuadernos de estrategias en los que Microsoft Sentinel no tiene permisos se mostrarán como no disponibles ("atenuados"). Para conceder permiso de Microsoft Sentinel con el fin de acceder a los grupos de recursos de los cuadernos de estrategias en ese momento, seleccione el vínculo Administrar permisos del cuaderno de estrategias. Para conceder esos permisos, necesitará permisos de Propietario en esos grupos de recursos. Consulte los requisitos de permisos completos.

    Permisos en una arquitectura multiinquilino

    Las reglas de automatización son totalmente compatibles con las implementaciones multiinquilino (mediante Azure Lighthouse) y en varias áreas de trabajo.

    Por tanto, si la implementación de Microsoft Sentinel usa una arquitectura multiinquilino, puede hacer que una regla de automatización de un solo inquilino ejecute un cuaderno de estrategias que se encuentre en otro inquilino. Sin embargo, los permisos de Sentinel para ejecutar el cuaderno de estrategias deben definirse en el inquilino donde se encuentre el cuaderno, no en el que se definan las reglas.

    En el caso específico de un proveedor de servicios de seguridad administrada (MSSP), cuando un inquilino del proveedor de servicios administra un área de trabajo de Microsoft Sentinel en un inquilino de un cliente, hay dos escenarios concretos que requieren atención:

    • Una regla de automatización creada en el inquilino del cliente se configura para ejecutar un cuaderno de estrategias que se encuentra en el inquilino del proveedor de servicios.

      Este enfoque se usa, normalmente, para proteger la propiedad intelectual del cuaderno de estrategias. No se requiere nada especial para que este escenario funcione. Cuando defina una acción de un cuaderno de estrategias en una regla de automatización y llegue a la fase en la que concede permisos de Microsoft Sentinel al grupo de recursos correspondiente donde se encuentra el cuaderno (mediante el panel Administrar permisos del cuaderno de estrategias), verá los grupos de recursos que pertenecen al inquilino del proveedor de servicios entre los que puede elegir. Aquí puede ver una breve explicación de todo el proceso.

    • Una regla de automatización creada en el área de trabajo del cliente (mientras está conectado al inquilino del proveedor de servicios) se configura para ejecutar un cuaderno de estrategias que se encuentra en el inquilino del cliente.

      Esta configuración se usa cuando no es necesario proteger la propiedad intelectual. Para que este escenario funcione, es necesario conceder permisos a Microsoft Sentinel para ejecutar el cuaderno de estrategias en ambos inquilinos. En el inquilino del cliente, se conceden en el panel Administrar permisos de cuaderno de estrategias, como en el escenario anterior. Para conceder los permisos pertinentes en el inquilino del proveedor de servicios, debe agregar una delegación de Azure Lighthouse adicional que conceda derechos de acceso a la aplicación Azure Security Insights, con el rol Colaborador de automatización de Microsoft Sentinel, en el grupo de recursos donde reside el cuaderno de estrategias.

      El escenario se parecería a este:

      Arquitectura de reglas de automatización multiinquilino

      Consulte las instrucciones de configuración.

    Creación y administración de reglas de automatización

    Puede crear y administrar reglas de automatización desde diferentes áreas de Microsoft Sentinel o la plataforma unificada de operaciones de seguridad, en función de sus necesidades y casos de uso concretos.

    • Página de Automatización

      Las reglas de automatización se pueden administrar de forma centralizada en la página Automatización, en la pestaña Reglas de Automatización. Desde aquí puede crear nuevas reglas de automatización, así como editar las existentes. También puede arrastrar las reglas de automatización para cambiar el orden de ejecución, además de habilitarlas o deshabilitarlas.

      En la página Automatización, verá todas las reglas que están definidas en el área de trabajo, junto con su estado (Habilitada/Deshabilitada) y a qué reglas de análisis se aplican.

      Cuando necesite una regla de automatización que se aplique a incidentes desde Microsoft Defender XDR o desde muchas reglas de análisis de Microsoft Sentinel, créela directamente en la página Automatización.

    • Asistente para reglas de análisis

      En la pestaña Respuesta automática del Asistente para reglas de análisis de Microsoft Sentinel, en Reglas de automatización, puede visualizar, editar y crear reglas de automatización que se aplican a la regla de análisis específica que se está creando o editando en el Asistente.

      Notará que, al crear una regla de automatización desde aquí, el panel Creación de una regla de automatización muestra la condición de la regla de análisis como no disponible, ya que esta regla está configurada para aplicarse solo a la regla de análisis que está editando en el asistente. Todas las demás opciones de configuración siguen disponibles.

    • Página de incidentes

      También puede crear una regla de automatización desde la página Incidentes con el fin de responder a un único incidente repetitivo. Esto resulta útil cuando se crean reglas de eliminación para cerrar automáticamente los incidentes «irrelevantes».

      Observará que cuando crea una norma de automatización desde aquí, el panel Crear nueva regla de automatización ha rellenado todos los campos con los valores del incidente. Asigna a la regla el mismo nombre que el incidente, la aplica a la regla de análisis que generó el incidente y usa todas las entidades disponibles en el incidente como condiciones de la regla. También sugiere una acción de eliminación (cierre) de manera predeterminada y sugiere una fecha de expiración para la regla. Puede agregar o quitar condiciones y acciones, así como cambiar la fecha de expiración como desee.

    Pasos siguientes

    En este documento, ha aprendido cómo las reglas de automatización pueden ayudarle a administrar de forma centralizada la automatización de respuestas para incidentes y alertas de Microsoft Sentinel.