Crear y publicar reglas de análisis para soluciones de Microsoft Sentinel

Las reglas de análisis de Microsoft Sentinel son conjuntos de criterios. Definen cómo se supervisan los datos, qué se detectan y qué acciones se realizan cuando se cumplen condiciones específicas. Estas reglas ayudan a identificar comportamientos sospechosos, anomalías y posibles amenazas de seguridad mediante el análisis de registros y señales de varios orígenes de datos.

Las reglas de análisis de Microsoft Sentinel son herramientas eficaces para mejorar la posición de seguridad de una organización porque detectan y responden proactivamente a posibles amenazas. Siguiendo un enfoque estructurado para crear y administrar estas reglas, las organizaciones pueden usar las funcionalidades de Microsoft Sentinel para proteger sus recursos digitales y mantener una infraestructura de seguridad sólida. Para obtener más información, consulte Detección de amenazas en Microsoft Sentinel.

Este artículo le guía por el proceso de creación y publicación de reglas de análisis en soluciones de Microsoft Sentinel.

Casos de uso para reglas de análisis de Microsoft Sentinel

Las reglas de análisis de Microsoft Sentinel se pueden aplicar a una amplia gama de escenarios para mejorar la supervisión de la seguridad y la detección de amenazas. Entre los casos de uso comunes se incluye:

• Detección de intrusiones: identifique intentos de acceso no autorizados o actividades de inicio de sesión sospechosas que podrían indicar una posible infracción.
• Detección de malware: supervisar firmas de malware conocidas o un comportamiento inusual que podría sugerir la presencia de software malintencionado.
• Filtración de datos: detecte transferencias de datos grandes o inusuales que podrían indicar que los datos se filtran desde la red.
• Amenazas internas: identifique el comportamiento anómalo de los usuarios internos, como el acceso a datos confidenciales fuera de las horas normales o los patrones.
• Supervisión de cumplimiento: garantice el cumplimiento de los requisitos normativos mediante la supervisión de actividades específicas o patrones de acceso.
• Búsqueda de amenazas: busque de forma proactiva indicadores de riesgo u otros signos de actividad malintencionada dentro de la red.
• Cuenta en peligro: detecte signos de que las cuentas de usuario podrían estar en peligro, como patrones de inicio de sesión geográfico inusuales o varios intentos de inicio de sesión erróneos.
• Anomalías de red: identifique patrones de tráfico de red inusuales que podrían indicar la presencia de una amenaza o una configuración incorrecta.
• Escalado de privilegios: supervise los intentos de obtener privilegios elevados dentro de la red, lo que puede ser un precursor de una actividad malintencionada adicional.
• Seguridad del punto de conexión: asegúrese de que los puntos de conexión son seguros mediante la detección de desviaciones del comportamiento normal o la presencia de software no autorizado.

Crear y publicar reglas de análisis

Las reglas de análisis se crean en formato YAML. Puede usar este ejemplo de una regla de análisis como referencia para crear sus propias consultas: regla de análisis de ejemplo en GitHub.

En las secciones siguientes se proporciona un tutorial detallado de varios atributos de una regla de análisis.

ID

El atributo id consta de un identificador único global (GUID) estándar. Generarlo mediante cualquier herramienta de desarrollo, un generador en línea o el nuevo cmdlet de PowerShell New-GUID. Debe ser único entre otros GUID.

Este campo es obligatorio.

Variante

El atributo kind representa el tipo de regla.

Hay dos valores aceptados: scheduled y NRT (casi en tiempo real). El valor de scheduled requiere que defina otras propiedades, como queryFrequency, queryPeriod, triggerThresholdy triggerOperator.

Este campo es obligatorio.

Nombre

El atributo name proporciona una etiqueta breve que resume la detección. Asegúrese de que la etiqueta esté clara y concisa para ayudar a los usuarios a comprender el propósito de la regla. Use alertDetailsOverride para generar nombres dinámicos para ayudar a los analistas a comprender la alerta. Este atributo:

• Usa mayúsculas de mayúsculas de mayúsculas y minúsculas de frase.
• No termina en un período.
• Tiene una longitud máxima de 50 caracteres (siempre que sea posible).

Este campo es obligatorio.

Descripción

El atributo description proporciona una descripción detallada de la detección. La descripción incluye información sobre el comportamiento que se detecta, el posible efecto y las acciones recomendadas. Este atributo:

• Usa mayúsculas de mayúsculas de mayúsculas y minúsculas de oración.
• Comienza con "Esta consulta busca" o "Identifica".
• Es diferente de y más descriptivo que el campo de nombre.
• Tiene una longitud máxima de 255 caracteres.
• Es cinco oraciones o menos.
• No describe el origen de datos (conector o tipo de datos).
• No proporciona una explicación técnica del lenguaje de consulta.

Este campo es obligatorio.

Gravedad

El atributo severity define el nivel de gravedad de la detección. La gravedad refleja el posible efecto del comportamiento que se detecta y la urgencia de la respuesta.

• Informativo: es posible que el incidente no represente directamente una amenaza de seguridad, pero puede ser de interés para la investigación de seguimiento, o para agregar reconocimiento de contexto o situación a un analista.
• Bajo: el efecto inmediato es mínimo y un actor de amenazas tendría que llevar a cabo varios pasos antes de lograr un efecto en un entorno.
• Medio: el actor de amenazas podría lograr algún efecto en el entorno con esta actividad, pero el efecto se limitaría en el ámbito o requeriría actividad adicional.
• Alto: la actividad identificada proporciona al actor de amenazas acceso amplio para realizar acciones en el entorno.

Nota:

Los valores predeterminados del nivel de gravedad no son una garantía del nivel de impacto actual o del entorno. El nivel de gravedad solo se aplica a las plantillas de análisis de Microsoft Sentinel. De lo contrario, el servicio de seguridad que emitió la alerta controla el atributo severity en la tabla Alertas. Puede usar alertDetailsOverride para proporcionar un atributo dinámico severity que depende del resultado real de la consulta.

Conectores de datos necesarios

El atributo requiredDataConnectors representa la lista de conectores de datos que la regla necesita para funcionar correctamente, incluidos los orígenes de datos en los que la regla consulta. Si no hay ninguna asignación de conector de datos actual, debe usar una llave abierta: requiredDataConnectors: [].

El atributo connectorId especifica el identificador del conector de datos que necesita para que la consulta funcione correctamente. Si la consulta de detección depende de los datos capturados desde un conector específico, debe especificar el identificador del conector aquí. Por ejemplo, si la regla de análisis depende de los datos de este conector, debe especificar el connectorID como 1PasswordCCPDefinition.

El atributo dataTypes representa los tipos de datos de los que depende la regla de análisis y menciona el nombre del tipo de datos al que se hace referencia en la sección dataTypes del conector. Por ejemplo, si la consulta de búsqueda depende de los datos de este conector, debe especificar el tipo de datos como OnePasswordEventLogs_CL. Si la consulta de búsqueda funciona en una función o analizador de Kusto en lugar de en la tabla (como Syslog, CommonEventFormat o _CL), dataTypes es el nombre de función o analizador de Kusto y no el nombre de la tabla.

Período de consulta

El atributo queryPeriod representa un período especificado durante el cual se ejecuta la consulta. Por ejemplo: los últimos 3 días. Para este atributo:

• Use el formato del lenguaje de consulta Kusto (KQL) TimeSpan (por ejemplo, 3 días es 3d, 2 horas es 2h).
• Asegúrese de que cualquier período de aprendizaje o referencia esté dentro de este período de tiempo.
• No use un valor mayor que el valor máximo admitido, que es 14d.

Este campo es obligatorio para las reglas de análisis programadas.

Frecuencia de consulta

El atributo queryFrequency representa la frecuencia con la que se ejecuta la consulta. Para este atributo:

• Use el formato de TimeSpan KQL (por ejemplo, 3 días es 3d, 2 horas es 2h).
• Use un queryFrequency que sea menor o igual que el queryPeriod.
• Siga esta regla: si el queryPeriod es mayor o igual que 2 días (2d), el valor de queryFrequency no puede ser inferior a 1 hora (1h) y solo se usa para las detecciones de gravedad alta.

Este campo es obligatorio para las reglas de análisis programadas.

Operador del desencadenador

El atributo triggerOperator indica el mecanismo que desencadena la alerta. Por ejemplo: mayor que (gt) el número establecido en el atributo triggerThreshold (consulte Umbral de desencadenador).

• gt: mayor que.
• lt: menor que.
• eq: igual a.

Este campo es obligatorio para las reglas de análisis programadas.

Umbral de desencadenador

El atributo triggerThreshold representa el umbral que desencadena la alerta. Umbral es el valor al que hace referencia el triggerOperator. Los valores admitidos incluyen cualquier entero entre 0 y 10 000.

Por ejemplo, si el triggerOperator se establece en gt y el triggerThreshold es 1, la alerta se desencadena cuando un valor es mayor que 1.

Este campo es obligatorio para las reglas de análisis programadas.

Tácticas

El atributo tactics define el MITRE ATT&CK tactics al que se relaciona la detección. Al definir las tácticas, ayuda a los usuarios a comprender el contexto de la detección y cómo encaja en el panorama general de amenazas. Para este atributo:

• ATT&CK Framework v13 es compatible.
• Los nombres no pueden incluir espacios. Por ejemplo: InitialAccess o LateralMovement.

Este campo es obligatorio.

Técnicas pertinentes

El atributo relevantTechniques define el MITRE ATT&CK techniques al que se relaciona la detección. Al definir las técnicas, ayuda a los usuarios a comprender el contexto de la detección y cómo encaja en el panorama general de amenazas. Para este atributo:

• ATT&CK Framework v13 es compatible.
• El atributo coincide con MITRE tácticas.
• Los nombres no pueden incluir espacios. Por ejemplo: T1078 o T1078.001.

Este campo es obligatorio.

Consultar

El atributo query define la lógica de detección. Se recomienda escribir la consulta en KQL y asegurarse de que está estructurada y fácil de entender. Se recomienda crear una consulta eficaz optimizada para el rendimiento para asegurarse de que se puede ejecutar en conjuntos de datos de gran tamaño sin afectar al rendimiento. Asegúrese de que la consulta cumple los siguientes criterios.

Limite la consulta a 10 000 caracteres. Si la sección de consulta supera este límite, considere la posibilidad de reducir el número de caracteres. Una lista estática de elementos usados para la comparación dentro del cuerpo de la consulta puede hacer que supere el límite. Se recomienda mover estas listas a una de las siguientes opciones:

• Una función de lista de reproducción
• Un JSON/CSV personalizado
• Una función personalizada.

Cada línea del cuerpo de la consulta debe tener al menos un espacio al principio, pero dos espacios son estándar para admitir la legibilidad.

Al enviar una consulta para un tipo de datos que no está presente en la carpeta Detecciones o Consultas de búsqueda, asigne un nombre a la subcarpeta que contiene los archivos YAML después de consultar la tabla. Por ejemplo, si la consulta pertenece a la tabla AzureDevOpsAuditing, cree una carpeta denominada AzureDevOpsAuditing.

Defina nombres legibles para constantes explícitas:

• let FailedLoginEventID = 4625;
• let countThreshold = 6;

Se recomienda encarecidamente usar comentarios para aclarar la consulta. Evite agregar comentarios al final de una línea de instrucción de consulta. En su lugar, agregue los comentarios en una línea independiente. Por ejemplo:

  // Removing noisy processes for an environment, adjust as needed

Si hace referencia a un analizador en lugar de un nombre de tabla, asegúrese de que la descripción incluya un comentario junto a la referencia de la función del analizador. El analizador debe importarse primero en el área de trabajo. De lo contrario, las consultas no lo reconocen como válidos.

Asegúrese de que todos los campos de entidad disponibles se devuelven con fines de asignación. (Consulte la sección Asignaciones de entidades). Sane la tabla devuelta para que proporcione solo las propiedades que necesita investigar más. No necesita un filtro de TimeGenerated cuando se usa un comando simple lookback en toda la consulta. El valor de queryPeriod en los controles YAML controla este proceso.

Para basar o realizar una comparación histórica, como comparar hoy con los siete días anteriores, incluya un filtro limitado por tiempo, como | where TimeGenerated >= ago(lookback), ya que la plantilla YAML no admite actualmente varios valores de queryPeriod. Evite usar períodos de tiempo más cortos de un día a menos que haya una razón específica. No se recomiendan períodos de tiempo de más de 14 días debido a posibles impactos en el rendimiento.

Resumir cuando sea necesario. Asegúrese de incluir el campo de hora (normalmente TimeGenerated) porque lo necesita en el campo de entidad. Incluya los valores min() y max() como se indica a continuación: | summarize StartTime = max(TimeGenerated), EndTime = min(TimeGenerated). Use los términos StartTime y EndTime exclusivamente. No asigne los campos a los nombres StartTimeUtc o EndTimeUtc, ya que estos nombres pueden entrar en conflicto con las preferencias de la experiencia del usuario.

Además, incluya tantos campos como sea posible para ayudar al usuario a comprender el contexto de la alerta. Se recomienda incluir al menos una de las entidades principales: Host, Account o IP.

Este campo es obligatorio.

Configuración de agrupación de eventos

El atributo eventGroupingSettings se relaciona con las alertas. Una regla de alerta puede generar una alerta independiente para cada resultado de la consulta. Por ejemplo, una regla que identifica las alertas que no son de Microsoft en el flujo de eventos podría crear una alerta de Microsoft Sentinel para cada alerta de origen.

• Para generar una sola alerta para todos los resultados de la consulta (valor predeterminado), use:

  eventGroupingSettings:
  aggregationKind: SingleAlert
  

• Para generar una alerta independiente para cada resultado de la consulta, use:

  eventGroupingSettings:
  aggregationKind: AlertPerResult
  

Asignaciones de entidades

El atributo entityMappings es integral al configurar reglas de análisis programadas. Enriquece la salida de la consulta (alertas e incidentes) con información esencial que actúa como bloques de creación de cualquier proceso de investigación y acciones correctivas siguientes.

entityType representa la lista estándar de entidades reconocidas por Microsoft Sentinel. Consulte los valores permitidos en la columna Tipo de entidad de la tabla de asignación de entidades.

Este campo es obligatorio.

Asignaciones de campos

El atributo fieldMappings representa el identificador del campo en la salida de consulta que corresponde al tipo de entidad. Consulte los valores permitidos en el valor de columna de identificadores en la tabla de asignación de entidades. Para este atributo:

• Cada plantilla puede tener hasta 10 asignaciones de entidades.

• Cada asignación de entidades puede tener hasta tres asignaciones de campos (es decir, identificadores).

  entityMappings:
  - entityType: Account
    fieldMappings:
      - identifier: FullName
        columnName: AccountCustomEntity
  - entityType: Host
    fieldMappings:
      - identifier: FullName
        columnName: HostCustomEntity
  - entityType: IP
    fieldMappings:
      - identifier: Address
        columnName: ClientIP
  - entityType: DNS
    fieldMappings:
      - identifier: DomainName
        columnName: Name
  
  

Detalles personalizados

El atributo customDetails integra los datos de eventos en alertas, lo que hace que sea visible en incidentes de seguridad para evaluar, investigar y responder más rápidamente. Los detalles personalizados son pares clave-valor de nombres de propiedad y columna. Para obtener más información, consulte los detalles de eventos personalizados de Surface en alertas de Microsoft Sentinel. Se pueden definir hasta 20 detalles personalizados (es decir, pares clave-valor) por plantilla.

    customDetails:
      Computers: Computer
      IPs: ComputerIP

Invalidación de detalles de alerta

El atributo alertDetailsOverride es un campo dinámico que puede usar para invalidar los detalles de la alerta. Puede usar este atributo para proporcionar más contexto o información al analista cuando se desencadene la alerta. Al usar esta característica, asegúrese de que los analistas reciban información pertinente, incluidos los nombres de entidad pertinentes, para facilitar una comprensión más rápida y precisa del incidente. Entre las limitaciones se incluyen:

• Se puede incluir un máximo de tres parámetros en o namedescription.

• name no debe superar los 256 caracteres, mientras que el description está limitado a 5000 caracteres.

• El nombre de columna dentro de las llaves debe coincidir exactamente con el nombre de columna esperado, sin ningún espacio en blanco inicial o final (por ejemplo, {{columnName}}, no {{ columnName }}). En el ejemplo siguiente, columnName1, columnName2, dynamicTactic y dynamicSeverity son campos de salida de la consulta de alerta programada.

      alertDetailsOverride:
        alertDisplayNameFormat: free text with field names embedded using the format {{columnName}} # Up to 256 chars and 3 placeholders
        alertDescriptionFormat: free text with field names embedded using the format  {{columnName}} # Up to 5000 chars and 3 placeholders
        alertTacticsColumnName: dynamicTacticColumnName
        alertSeverityColumnName: dynamicSeverityColumnName
  
  

      alertDetailsOverride:
        alertDisplayNameFormat: rule {{columnName1}} display name
        alertDescriptionFormat: rule {{columnName2}} display name
        alertTacticsColumnName: dynamicTactic
        alertSeverityColumnName: dynamicSeverity
  

Versión

Cuando un cliente crea una nueva consulta de búsqueda a partir de la plantilla, se guarda la plantilla version. Si se publica una nueva versión de plantilla, se notifica a los clientes en la experiencia de usuario. Las versiones siguen el formato a, b y c, en el que a es la versión principal, b es la versión secundaria y c es la revisión. El campo de versión es la última línea de la plantilla.

Este campo es obligatorio.