Desarrollo de analizadores del modelo de información de seguridad avanzada (ASIM)

Los usuarios del modelo de información de seguridad avanzada (ASIM) usan analizadores de unificación en lugar de nombres de tabla en sus consultas, para ver los datos en un formato normalizado e incluir todos los datos relevantes para el esquema en la consulta. A su vez, al unificar analizadores, se usan analizadores específicos del origen para controlar los detalles específicos de cada origen.

Microsoft Sentinel proporciona analizadores integrados específicos del origen para muchos orígenes de datos. Es posible que quiera modificar o desarrollar estos analizadores específicos del origen en las situaciones siguientes:

• Cuando el dispositivo proporciona eventos que se ajustan a un esquema ASIM, pero un analizador específico del origen para el dispositivo y el esquema correspondiente no está disponible en Microsoft Sentinel.

• Cuando los analizadores específicos del origen de ASIM están disponibles para el dispositivo, pero el dispositivo envía eventos en un método o en un formato diferente del esperado por los analizadores de ASIM. Por ejemplo:

  • Es posible que el dispositivo de origen esté configurado para enviar eventos de forma no estándar.

  • El dispositivo puede tener una versión diferente a la que admite el analizador de ASIM.

  • Los eventos pueden ser recopilados, modificados y reenviados por un sistema intermediario.

Para comprender cómo encajan los analizadores dentro de la arquitectura de ASIM, consulte el diagrama de arquitectura de ASIM.

Proceso de desarrollo del analizador de ASIM personalizado

En el flujo de trabajo siguiente se describen los pasos de alto nivel para desarrollar un analizador personalizado de ASIM específico del origen:

1. Recopilar registros de ejemplo.

2. Identifique los esquemas o esquemas que representan los eventos enviados desde el origen. Para obtener más información, vea Información general del esquema.

3. Asigne los campos de evento de origen al esquema o esquemas identificados.

4. Desarrolle uno o varios analizadores de ASIM para el origen. Tendrá que desarrollar un analizador de filtrado y un analizador sin parámetros para cada esquema relevante para el origen.

5. Pruebe el analizador.

6. Implemente los analizadores en las áreas de trabajo de Microsoft Sentinel.

7. Actualice el analizador de unificación de ASIM correspondiente para hacer referencia al nuevo analizador personalizado. Para obtener más información, consulte Administración de analizadores de ASIM.

8. Es posible que también quiera contribuir con los analizadores a la distribución de ASIM principal. Los analizadores aportados también pueden estar disponibles en todas las áreas de trabajo como analizadores integrados.

Este artículo le guía por los pasos de desarrollo, pruebas e implementación del proceso.

Recopilación de registros de ejemplo

Para crear analizadores de ASIM eficaces, necesita un conjunto representativo de registros, que en la mayoría de los casos requerirá configurar el sistema de origen y conectarlo a Microsoft Sentinel. Si no tiene el dispositivo de origen disponible, los servicios de pago por uso en la nube le permiten implementar muchos dispositivos para el desarrollo y las pruebas.

Además, encontrar la documentación del proveedor y los ejemplos de los registros puede ayudar a acelerar el desarrollo y reducir los errores al garantizar una amplia cobertura del formato de registro.

Un conjunto representativo de registros debe incluir:

• Eventos con resultados de eventos diferentes.
• Eventos con diferentes acciones de respuesta.
• Diferentes formatos para el nombre de usuario, el nombre de host y los identificadores, y otros campos que requieren normalización de valores.

Planeamiento de la asignación

Antes de desarrollar un analizador, asigne la información disponible en el evento o eventos de origen al esquema identificado:

• Asigne todos los campos obligatorios y, preferiblemente, también los campos recomendados.
• Intente asignar cualquier información disponible del origen a los campos normalizados. Si no está disponible como parte del esquema seleccionado, considere la posibilidad de asignar a los campos disponibles en otros esquemas.
• Asigne los valores de los campos del origen a los valores normalizados permitidos por ASIM. El valor original se almacena en un campo independiente, como EventOriginalResultDetails.

Desarrollo de analizadores

Desarrolle un filtrado y un analizador sin parámetros para cada esquema pertinente.

Un analizador personalizado es una consulta KQL desarrollada en la página registros de Microsoft Sentinel. La consulta del analizador tiene tres partes:

Filtro>> AnálisisPreparar campos

Filtrado

Filtrado de los registros pertinentes

En muchos casos, una tabla de Microsoft Sentinel incluye varios tipos de eventos. Por ejemplo:

• La tabla Syslog tiene datos de varios orígenes.
• Las tablas personalizadas pueden incluir información de un único origen que proporciona más de un tipo de evento y puede ajustarse a varios esquemas.

Por lo tanto, un analizador debe filtrar primero solo los registros pertinentes para el esquema de destino.

El filtrado en KQL se realiza mediante el where operador . Por ejemplo, el evento 1 de Sysmon informa de la creación de procesos y, por lo tanto, se normaliza al esquema ProcessEvent . El evento 1 del evento Sysmon forma parte de la Event tabla, por lo que usaría el siguiente filtro:

Event | where Source == "Microsoft-Windows-Sysmon" and EventID == 1

Filtrado por tipo de origen mediante una lista de seguimiento

En algunos casos, el propio evento no contiene información que permita el filtrado de tipos de origen específicos.

Por ejemplo, los eventos DNS de Infoblox se envían como mensajes de Syslog y son difíciles de distinguir de los mensajes de Syslog enviados de otros orígenes. En tales casos, el analizador se basa en una lista de orígenes que define los eventos pertinentes. Esta lista se mantiene en la lista de seguimiento de Sources_by_SourceType .

Para usar la lista de reproducción ASimSourceType en los analizadores, use la _ASIM_GetSourceBySourceType función en la sección de filtrado del analizador. Por ejemplo, el analizador dns de Infoblox incluye lo siguiente en la sección de filtrado:

  | where Computer in (_ASIM_GetSourceBySourceType('InfobloxNIOS'))

Para usar este ejemplo en el analizador:

• Reemplace por Computer el nombre del campo que incluye la información de origen del origen. Puede conservar esto como Computer para cualquier analizador basado en Syslog.

• Reemplace el InfobloxNIOS token por un valor de su elección para el analizador. Informe a los usuarios del analizador de que deben actualizar la lista de reproducción con el ASimSourceType valor seleccionado, así como la lista de orígenes que envían eventos de este tipo.

Filtrado basado en parámetros del analizador

Al desarrollar analizadores de filtrado, asegúrese de que el analizador acepta los parámetros de filtrado para el esquema correspondiente, como se documenta en el artículo de referencia de ese esquema. El uso de un analizador existente como punto de partida garantiza que el analizador incluya la firma de función correcta. En la mayoría de los casos, el código de filtrado real también es similar para filtrar analizadores para el mismo esquema.

Al filtrar, asegúrese de que:

• Filtre antes de analizar mediante campos físicos. Si los resultados filtrados no son lo suficientemente precisos, repita la prueba después del análisis para ajustar los resultados. Para obtener más información, vea Filtrado de optimización.
• No filtre si el parámetro no está definido y sigue teniendo el valor predeterminado.

En los ejemplos siguientes se muestra cómo implementar el filtrado para un parámetro de cadena, donde el valor predeterminado suele ser "*" y para un parámetro de lista, donde el valor predeterminado suele ser una lista vacía.

srcipaddr=='*' or ClientIP==srcipaddr
array_length(domain_has_any) == 0 or Name has_any (domain_has_any)

Vea más información sobre los siguientes elementos en la documentación de Kusto:

• función array_length
• operador has_any

Optimización de filtrado

Para garantizar el rendimiento del analizador, tenga en cuenta las siguientes recomendaciones de filtrado:

• Filtre siempre por campos integrados en lugar de por campos analizados. Aunque a veces es más fácil filtrar mediante campos analizados, afecta considerablemente al rendimiento.
• Use operadores que proporcionen un rendimiento optimizado. En concreto, ==, hasy startswith. El uso de operadores como contains o matches regex también afecta considerablemente al rendimiento.

Es posible que las recomendaciones de filtrado para el rendimiento no siempre sean fáciles de seguir. Por ejemplo, el uso has es menos preciso que contains. En otros casos, la coincidencia del campo integrado, como SyslogMessage, es menos precisa que comparar un campo extraído, como DvcAction. En tales casos, se recomienda seguir filtrando previamente mediante un operador de optimización del rendimiento en un campo integrado y repetir el filtro con condiciones más precisas después del análisis.

Para obtener un ejemplo, vea el siguiente fragmento de código del analizador dns de Infoblox . El analizador comprueba primero que el campo has SyslogMessage sea la palabra client. Sin embargo, el término podría usarse en un lugar diferente del mensaje, por lo que después de analizar el Log_Type campo, el analizador comprueba de nuevo que la palabra client era realmente el valor del campo.

Syslog | where ProcessName == "named" and SyslogMessage has "client"
…
      | extend Log_Type = tostring(Parser[1]),
      | where Log_Type == "client"

Análisis

Una vez que la consulta selecciona los registros pertinentes, es posible que tenga que analizarlos. Normalmente, el análisis es necesario si se transmiten varios campos de evento en un único campo de texto.

Los operadores KQL que realizan el análisis se enumeran a continuación, ordenados por su optimización de rendimiento. El primero proporciona el rendimiento más optimizado, mientras que el último proporciona el rendimiento menos optimizado.

Normalización

Asignación de nombres de campo

La forma más sencilla de normalización es cambiar el nombre de un campo original a su nombre normalizado. Use el operador project-rename para eso. El uso de project-rename garantiza que el campo se sigue administrando como un campo físico y controlar el campo es más eficaz. Por ejemplo:

 | project-rename
    ActorUserId = InitiatingProcessAccountSid,
    ActorUserAadId = InitiatingProcessAccountObjectId,
    ActorUserUpn = InitiatingProcessAccountUpn,

Normalización del formato y el tipo de campos

En muchos casos, el valor original extraído debe normalizarse. Por ejemplo, en ASIM, una dirección MAC usa dos puntos como separador, mientras que el origen puede enviar una dirección MAC delimitada por guiones. El operador principal para transformar valores es extend, junto con un amplio conjunto de funciones de cadena, numérica y de fecha de KQL.

Además, asegurarse de que los campos de salida del analizador coincidan con el tipo definido en el esquema es fundamental para que los analizadores funcionen. Por ejemplo, es posible que tenga que convertir una cadena que represente la fecha y hora en un campo datetime. Las funciones como todatetime y tohex son útiles en estos casos.

Por ejemplo, el identificador de evento único original se puede enviar como un entero, pero ASIM requiere que el valor sea una cadena para garantizar una compatibilidad amplia entre los orígenes de datos. Por lo tanto, al asignar el campo de origen, use extend y tostring en lugar de project-rename:

  | extend EventOriginalUid = tostring(ReportId),

Campos y valores derivados

Es posible que el valor del campo de origen, una vez extraído, tenga que asignarse al conjunto de valores especificado para el campo de esquema de destino. Las funciones iff, casey lookup pueden ser útiles para asignar los datos disponibles a los valores de destino.

Por ejemplo, el analizador DE DNS de Microsoft asigna el EventResult campo en función del identificador de evento y el código de respuesta mediante una iff instrucción, como se indica a continuación:

   extend EventResult = iff(EventId==257 and ResponseCode==0 ,'Success','Failure')

Para asignar varios valores, defina la asignación mediante el datatable operador y use lookup para realizar la asignación. Por ejemplo, algunos orígenes notifican códigos de respuesta DNS numéricos y el protocolo de red, mientras que el esquema exige la representación de etiquetas de texto más comunes para ambos. En el ejemplo siguiente se muestra cómo derivar los valores necesarios mediante datatable y lookup:

   let NetworkProtocolLookup = datatable(Proto:real, NetworkProtocol:string)[
        6, 'TCP',
        17, 'UDP'
   ];
    let DnsResponseCodeLookup=datatable(DnsResponseCode:int,DnsResponseCodeName:string)[
      0,'NOERROR',
      1,'FORMERR',
      2,'SERVFAIL',
      3,'NXDOMAIN',
      ...
   ];
   ...
   | lookup DnsResponseCodeLookup on DnsResponseCode
   | lookup NetworkProtocolLookup on Proto

Observe que la búsqueda es útil y eficaz también cuando la asignación solo tiene dos valores posibles.

Cuando las condiciones de asignación son más complejas, combine iff, casey lookup. En el ejemplo siguiente se muestra cómo combinar lookup y case. El lookup ejemplo anterior devuelve un valor vacío en el campo DnsResponseCodeName si no se encuentra el valor de búsqueda. En el ejemplo siguiente se case aumenta mediante el resultado de la lookup operación si está disponible y especificando condiciones adicionales en caso contrario.

   | extend DnsResponseCodeName = 
      case (
        DnsResponseCodeName != "", DnsResponseCodeName,
        DnsResponseCode between (3841 .. 4095), 'Reserved for Private Use',
        'Unassigned'
      )

Microsoft Sentinel proporciona funciones útiles para los valores de búsqueda comunes. Por ejemplo, la DnsResponseCodeName búsqueda anterior se puede implementar mediante una de las siguientes funciones:

| extend DnsResponseCodeName = _ASIM_LookupDnsResponseCode(DnsResponseCode)

| invoke _ASIM_ResolveDnsResponseCode('DnsResponseCode')

La primera opción acepta como parámetro el valor que se va a buscar y le permite elegir el campo de salida y, por tanto, resulta útil como una función de búsqueda general. La segunda opción está más orientada a los analizadores, toma como entrada el nombre del campo de origen y actualiza el campo ASIM necesario, en este caso DnsResponseCodeName.

Para obtener una lista completa de las funciones de ayuda de ASIM, consulte Funciones de ASIM.

Campos de enriquecimiento

Además de los campos disponibles desde el origen, un evento ASIM resultante incluye campos de enriquecimiento que el analizador debe generar. En muchos casos, los analizadores pueden asignar un valor constante a los campos, por ejemplo:

  | extend                  
     EventCount = int(1),
     EventProduct = 'M365 Defender for Endpoint',
     EventVendor = 'Microsoft',
     EventSchemaVersion = '0.1.0',
     EventSchema = 'ProcessEvent'

Otro tipo de campos de enriquecimiento que los analizadores deben establecer son los campos de tipo, que designan el tipo del valor almacenado en un campo relacionado. Por ejemplo, el SrcUsernameType campo designa el tipo de valor almacenado en el SrcUsername campo. Puede encontrar más información sobre los campos de tipo en la descripción de las entidades.

En la mayoría de los casos, a los tipos también se les asigna un valor constante. Sin embargo, en algunos casos, el tipo debe determinarse en función del valor real, por ejemplo:

   DomainType = iif (array_length(SplitHostname) > 1, 'FQDN', '')

Microsoft Sentinel proporciona funciones útiles para controlar el enriquecimiento. Por ejemplo, use la siguiente función para asignar automáticamente los campos SrcHostname, SrcDomainSrcDomainType y SrcFQDN en función del valor del campo Computer.

  | invoke _ASIM_ResolveSrcFQDN('Computer')

Esta función establecerá los campos de la siguiente manera:

Las funciones _ASIM_ResolveDstFQDN y _ASIM_ResolveDvcFQDN realizan una tarea similar rellenando los campos relacionados Dst y Dvc . Para obtener una lista completa de las funciones de ayuda de ASIM, consulte Funciones de ASIM.

Selección de campos en el conjunto de resultados

El analizador puede seleccionar opcionalmente campos en el conjunto de resultados. La eliminación de campos innecesarios puede mejorar el rendimiento y aumentar la claridad evitando la confusión entre los campos normalizados y los restantes campos de origen.

Los siguientes operadores de KQL se usan para seleccionar campos en el conjunto de resultados:

Por ejemplo, al analizar una tabla de registro personalizada, use lo siguiente para quitar los campos originales restantes que todavía tienen un descriptor de tipo:

    | project-away
        *_d, *_s, *_b, *_g

Controlar variantes de análisis

En muchos casos, los eventos de una secuencia de eventos incluyen variantes que requieren una lógica de análisis diferente. Para analizar diferentes variantes en un único analizador, use instrucciones condicionales como iff y o caseuse una estructura de unión.

Para usar union para controlar varias variantes, cree una función independiente para cada variante y use la instrucción union para combinar los resultados:

let AzureFirewallNetworkRuleLogs = AzureDiagnostics
    | where Category == "AzureFirewallNetworkRule"
    | where isnotempty(msg_s);
let parseLogs = AzureFirewallNetworkRuleLogs
    | where msg_s has_any("TCP", "UDP")
    | parse-where
        msg_s with           networkProtocol:string 
        " request from "     srcIpAddr:string
        ":"                  srcPortNumber:int
    …
    | project-away msg_s;
let parseLogsWithUrls = AzureFirewallNetworkRuleLogs
    | where msg_s has_all ("Url:","ThreatIntel:")
    | parse-where
        msg_s with           networkProtocol:string 
        " request from "     srcIpAddr:string
        " to "               dstIpAddr:string
    ...
union parseLogs,  parseLogsWithUrls…

Para evitar eventos duplicados y un procesamiento excesivo, asegúrese de que cada función se inicia filtrando, usando campos nativos, solo los eventos que está pensado para analizar. Además, si es necesario, use project-away en cada rama, antes de la unión.

Implementación de analizadores

Implemente los analizadores manualmente copiándolos en la página Azure Supervisión del registro y guardando la consulta como una función. Este método es útil para las pruebas. Para obtener más información, vea Crear una función.

Para implementar un gran número de analizadores, se recomienda usar plantillas arm del analizador, como se indica a continuación:

1. Cree un archivo YAML basado en la plantilla pertinente para cada esquema e incluya la consulta en él. Comience con la plantilla YAML pertinente para el tipo de esquema y analizador, filtrado o sin parámetros.

2. Use el convertidor de plantillas de ASIM YAML a ARM para convertir el archivo YAML en una plantilla de ARM.

3. Si implementa una actualización, elimine las versiones anteriores de las funciones mediante el portal o la herramienta de eliminación de funciones de PowerShell.

4. Implemente la plantilla mediante el Azure Portal o PowerShell.

También puede combinar varias plantillas en un único proceso de implementación mediante plantillas vinculadas.

Analizadores de pruebas

En esta sección se describe que las herramientas de prueba que proporciona ASIM le permiten probar los analizadores. Dicho esto, los analizadores son código, a veces complejos, y se recomiendan prácticas estándar de control de calidad, como las revisiones de código, además de las pruebas automatizadas.

Instalación de herramientas de pruebas de ASIM

Para probar ASIM, implemente la herramienta de pruebas de ASIM en un área de trabajo de Microsoft Sentinel donde:

• El analizador está implementado.
• La tabla de origen usada por el analizador está disponible.
• La tabla de origen utilizada por el analizador se rellena con una colección variada de eventos pertinentes.

Validación del esquema de salida

Para asegurarse de que el analizador genera un esquema válido, use el probador de esquemas de ASIM ejecutando la siguiente consulta en la página Registros de Microsoft Sentinel:

<parser name> | getschema | invoke ASimSchemaTester('<schema>')

Controle los resultados de la siguiente manera:

Validación de los valores de salida

Para asegurarse de que el analizador genera valores válidos, use el evaluador de datos de ASIM mediante la ejecución de la siguiente consulta en la página Registros de Microsoft Sentinel:

<parser name> | limit <X> | invoke ASimDataTester ('<schema>')

La especificación de un esquema es opcional. Si no se especifica un esquema, el EventSchema campo se usa para identificar el esquema al que debe adherirse el evento. Si un evento no incluye un EventSchema campo, solo se comprobarán los campos comunes. Si se especifica un esquema como parámetro, este esquema se usará para probar todos los registros. Esto es útil para analizadores anteriores que no establecen el EventSchema campo.

Esta prueba consume muchos recursos y puede que no funcione en todo el conjunto de datos. Establezca X en el número más grande para el que la consulta no agotará el tiempo de espera, o establezca el intervalo de tiempo de la consulta mediante el selector de intervalo de tiempo.

Controle los resultados de la siguiente manera:

Muchos de los mensajes también notifican el número de registros que generaron el mensaje y su porcentaje del ejemplo total. Este porcentaje es un buen indicador de la importancia del problema. Por ejemplo, para un campo recomendado:

• Los valores vacíos del 90 % pueden indicar un problema general de análisis.
• El 25 % de los valores vacíos pueden indicar una variante de evento que no se ha analizado correctamente.
• Un puñado de valores vacíos puede ser un problema insignificante.

Analizadores de contribución

Es posible que quiera contribuir con el analizador a la distribución de ASIM principal. Si se aceptan, los analizadores estarán disponibles para todos los clientes como analizadores integrados de ASIM.

Para contribuir con los analizadores:

• Desarrolle un analizador de filtrado y un analizador sin parámetros.
• Cree un archivo YAML para el analizador tal como se describe en Implementación de analizadores anterior.
• Asegúrese de que los analizadores pasan todas las pruebas sin errores. Si se deja alguna advertencia, documentelas en el archivo YAML del analizador.
• Cree una solicitud de incorporación de cambios en el repositorio de GitHub de Microsoft Sentinel, lo que incluye:
  • Los archivos YAML de analizadores en las carpetas del analizador de ASIM (/Parsers/ASim<schema>/Parsers)
  • Datos de ejemplo representativos de acuerdo con las directrices de envío de muestras.
  • Resultados de la prueba de acuerdo con las directrices de envío de resultados de pruebas.

Documentación de advertencias aceptadas

Si las advertencias enumeradas por las herramientas de prueba de ASIM se consideran válidas para un analizador, documente las advertencias aceptadas en el archivo YAML del analizador mediante la sección Excepciones, como se muestra en el ejemplo siguiente.

Exceptions:
- Field: DnsQuery 
  Warning: Invalid value
  Exception: May have values such as "1164-ms-7.1440-9fdc2aab.3b2bd806-978e-11ec-8bb3-aad815b5cd42" which are not valid domains names. Those are related to TKEY RR requests.
- Field: DnsQuery
  Warning: Empty value in mandatory field
  Exception: May be empty for requests for root servers and for requests for RR type DNSKEY

La advertencia especificada en el archivo YAML debe ser una forma corta del mensaje de advertencia que se identifica de forma única. El valor se usa para hacer coincidir los mensajes de advertencia al realizar pruebas automatizadas y omitirlas.

Directrices de envío de ejemplos

Los datos de ejemplo son necesarios al solucionar problemas del analizador y para garantizar que las actualizaciones futuras del analizador se ajusten a muestras anteriores. Los ejemplos que envíe deben incluir cualquier variante de evento compatible con el analizador. Asegúrese de que los eventos de ejemplo incluyen todos los tipos de eventos posibles, formatos de eventos y variaciones, como eventos que representan una actividad correcta y con errores. Asegúrese también de que se representan las variaciones en los formatos de valor. Por ejemplo, si un nombre de host se puede representar como un FQDN o un nombre de host simple, los eventos de ejemplo deben incluir ambos formatos.

Para enviar los ejemplos de eventos, siga estos pasos:

• En la Logs pantalla, ejecute una consulta que extraerá de la tabla de origen solo los eventos seleccionados por el analizador. Por ejemplo, para el analizador DE DNS de Infoblox, use la consulta siguiente:

    Syslog
    | where ProcessName == "named"

• Exporte los resultados mediante la opción Exportar a CSV a un archivo denominado <EventVendor>_<EventProduct>_<EventSchema>_IngestedLogs.csv, Where EventProduct, EventProducty EventSchema son los valores asignados por el analizador a esos campos.

• En la Logs pantalla, ejecute una consulta que genere el esquema o la tabla de entrada del analizador. Por ejemplo, para el mismo analizador dns de Infoblox, la consulta es:

    Syslog
    | getschema

• Exporte los resultados mediante la opción Exportar a CSV a un archivo denominado <TableName>_schema.csv, donde TableName es el nombre de la tabla de origen que usa el analizador.

• Incluya ambos archivos en la solicitud de incorporación de cambios en la carpeta /Sample Data/ASIM. Si el archivo ya existe, agregue el identificador de GitHub al nombre, por ejemplo: <EventVendor>_<EventProduct>_<EventSchema>_SchemaTest_<GitHubHandle>.csv

Directrices de envío de resultados de pruebas

Los resultados de las pruebas son importantes para comprobar la exactitud del analizador y comprender cualquier excepción notificada.

Para enviar los resultados de la prueba, siga estos pasos:

• Ejecute las pruebas del analizador y se describe en la sección de pruebas .

• y exportar los resultados de las pruebas mediante la opción Exportar a CSV a archivos denominados <EventVendor>_<EventProduct>_<EventSchema>_SchemaTest.csv y <EventVendor>_<EventProduct>_<EventSchema>_DataTest.csv respectivamente.

• Incluya ambos archivos en la solicitud de incorporación de cambios en la carpeta /Parsers/ASim<schema>/Tests.

Pasos siguientes

En este artículo se describe el desarrollo de analizadores de ASIM.

Más información sobre los analizadores de ASIM:

• Introducción a los analizadores de ASIM
• Uso de analizadores de ASIM
• Administración de analizadores de ASIM
• Lista de analizadores de ASIM

Obtenga más información sobre ASIM en general:

• Vea el seminario web de profundización sobre Microsoft Sentinel análisis de normalización y contenido normalizado o revise las diapositivas.
• Introducción al modelo de información de seguridad avanzada (ASIM)
• Esquemas del modelo de información de seguridad avanzada (ASIM)
• Contenido del modelo de información de seguridad avanzada (ASIM)