Compartir a través de

Desarrollo de analizadores del Modelo avanzado de información de seguridad (ASIM) (versión preliminar pública)

  • Artículo

Los usuarios del Modelo avanzado de información de seguridad (ASIM) usan analizadores unificadores, en lugar de nombres de tabla, en sus consultas a fin de ver los datos en un formato normalizado e incluir todos los datos pertinentes para el esquema en una consulta. Los analizadores unificadores, a su vez, 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 de 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 este envía eventos en un método o un formato diferente al que esperan los analizadores de ASIM. Por ejemplo:

    • El dispositivo de origen puede configurarse para enviar eventos de forma no estándar.

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

    • Un sistema intermediario podría recopilar, modificar y reenviar los eventos.

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

Importante

ASIM está actualmente en versión preliminar. En la página Términos de uso complementarios para las Versiones preliminares de Microsoft Azure se incluyen términos legales adicionales que se aplican a las características de Azure que se encuentran en versión beta, versión preliminar o que todavía no se han publicado para su disponibilidad general.

Proceso de desarrollo del analizador sintáctico ASIM personalizado

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

  1. Recopilación de registros de ejemplo.

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

  3. Asignación de los campos de evento de origen al esquema o esquemas identificados.

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

  5. Probar el analizador.

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

  7. Actualizar el analizador unificador de ASIM pertinente para hacer referencia al analizador personalizado nuevo. Vea Administración de los analizadores de ASIM para obtener más información.

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

En este artículo se le guiará por los pasos necesarios para desarrollar, probar e implementar el proceso.

Sugerencia

Vea también el seminario web de profundización sobre los analizadores de normalización de Microsoft Sentinel y el contenido normalizado o revise las diapositivas relacionadas. Para más información, consulte la sección Pasos siguientes.

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á la configuración del sistema de origen y la conexión 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 desarrollo y 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 de formato de registro.

Un conjunto representativo de registros debe incluir lo siguiente:

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

Sugerencia

Inicie un analizador personalizado nuevo mediante un analizador existente para el mismo esquema. El uso de un analizador existente es especialmente importante para filtrar los analizadores a fin de asegurarse de que aceptan todos los parámetros que requiere el esquema.

Asignación de planificación

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

  • Asigne todos los campos obligatorios y, preferiblemente, también los campos recomendados.
  • Intente asignar cualquier información disponible desde el 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 valores para 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 Microsoft Sentinel. La consulta del analizador tiene tres partes:

Filtro>Análisis>Preparación de campos

Filtrado

Filtrado de los registros pertinentes

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

  • La tabla de 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 usando el operador where. Por ejemplo, el evento 1 de Sysmon notifica la creación de un proceso y, por lo tanto, se normaliza en el esquema ProcessEvent. El evento 1 de Sysmon forma parte de la tabla Event, por lo que se debería usar el siguiente filtro:

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

Importante

Un analizador no debe filtrar por tiempo. La consulta que usa el analizador aplicará un intervalo de tiempo.

Filtrado por tipo de origen mediante una lista de seguimiento

En algunos casos, el propio evento no contiene información que permita filtrar por 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 desde otros orígenes. En tales casos, el analizador se basa en una lista de orígenes donde se definen los eventos pertinentes. Esta lista se mantiene en la lista de seguimiento Sources_by_SourceType.

Para usar la lista de seguimiento ASimSourceType en los analizadores, use la función _ASIM_GetSourceBySourceType en la sección de filtrado del analizador. Por ejemplo, el analizador de 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 Computer por el nombre del campo que incluye la información de origen para su origen. Puede mantener esto como Computer para cualquier analizador basado en Syslog.

  • Reemplace el token InfobloxNIOS el valor que prefiera para el analizador. Informe a los usuarios del analizador de que deben actualizar la lista de seguimiento ASimSourceType con el valor seleccionado, así como la lista de los orígenes que envían eventos de este tipo.

Filtrado basado en parámetros del analizador

Cuando desarrolle analizadores de filtrado, asegúrese de que el analizador acepta los parámetros de filtrado para el esquema correspondiente, tal 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 la función correcta. En la mayoría de los casos, el código de filtrado real también es similar para el filtrado de analizadores del mismo esquema.

Al filtrar, asegúrese de que:

  • Filtra 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 optimización del filtrado.
  • No filtrar 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, en el que el valor predeterminado suele ser "*", y para un parámetro de lista, en el que 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)

Optimización del filtrado

Para garantizar el rendimiento del analizador, tenga presentes 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 con campos analizados, afecta considerablemente al rendimiento.
  • Use operadores que proporcionen un rendimiento optimizado, en concreto, ==, has y startswith. El uso de operadores como contains o matches regex también afecta drásticamente al rendimiento.

Las recomendaciones de filtrado relacionadas con el rendimiento pueden no ser siempre fáciles de seguir. Por ejemplo, el uso de has es menos preciso que contains. En otros casos, buscar una coincidencia del campo integrado, como SyslogMessage, es menos preciso que comparar un campo extraído, como DvcAction. En tales casos, se recomienda seguir filtrando previamente con un operador de optimización del rendimiento sobre un campo integrado y repetir el filtrado mediante condiciones más precisas después del análisis.

Para obtener un ejemplo, consulte el siguiente fragmento de código del analizador de DNS de Infoblox. El analizador comprueba primero que el campo SyslogMessage has la palabra client. Pero el término podría usarse en un lugar diferente del mensaje, por lo que después de analizar el campo Log_Type, 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"

Nota

Los analizadores no deben filtrar por hora, puesto que ya lo hace la consulta que usa el analizador.

Análisis

Una vez que la consulta selecciona los registros pertinentes, puede que tenga que analizarlos. Normalmente, es necesario analizar si se transmiten varios campos del evento en un solo campo de texto.

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

Operador Descripción
split Analiza una cadena de valores delimitados.
parse_csv Analiza una cadena de valores con formato de línea CSV (valores separados por comas).
parse-kv Extrae información estructurada de una expresión de cadena y representa la información en formato de clave-valor.
parse Analiza varios valores de una cadena arbitraria usando un patrón, que puede ser un patrón simplificado con un mejor rendimiento, o una expresión regular.
extract_all Analiza valores únicos de una cadena arbitraria usando una expresión regular. extract_all tiene un rendimiento similar a parse si este último usa una expresión regular.
extract Analiza un valor único de una cadena arbitraria usando una expresión regular.

extract proporciona un mejor rendimiento que parse o extract_all si se necesita un valor único. Sin embargo, usar varias activaciones de extract en la misma cadena de origen es menos eficaz que hacerlo con un solo operador parse o extract_all, por lo que debe evitarse hacerlo.
parse_json Analiza los valores de una cadena con formato JSON. Si solo se necesitan algunos valores del código JSON, el uso de parse, extract o extract_all proporciona un mejor rendimiento.
parse_xml Analiza los valores de una cadena con formato XML. Si solo se necesitan algunos valores del código XML, el uso de parse, extract o extract_all proporciona un mejor rendimiento.

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. Para ello, use el operador project-rename. El uso de project-rename garantiza que el campo se siga administrando como un campo físico y que la manipulación del campo sea 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 KQL de cadena, numéricas y de fecha.

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, puede que tenga que convertir una cadena que representa la fecha y hora en un campo datetime. En estos casos resultan útiles funciones como todatetime y tohex.

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 amplia compatibilidad 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

Una vez extraído el valor del campo de origen, es posible que deba asignarse al conjunto de valores especificado para el campo de esquema de destino. Las funciones iff, case y lookup pueden ser útiles para asignar los datos disponibles a los valores de destino.

Por ejemplo, el analizador de DNS de Microsoft asigna el campo EventResult en función del Id. de evento y el código de respuesta usando una instrucción iff, tal y como se muestra a continuación:

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

Para asignar varios valores, defina la asignación mediante el operador datatable y use lookup para realizar la asignación. Por ejemplo, algunos orígenes informan de los códigos de respuesta DNS numéricos y del protocolo de red, mientras que el esquema impone 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, case y lookup. En el ejemplo siguiente se muestra cómo combinar lookup y case. En el ejemplo lookup anterior se devuelve un valor vacío en el campo DnsResponseCodeName si no se encuentra el valor de búsqueda. En el ejemplo case siguiente se aumenta mediante el resultado de la operación lookup si está disponible y se especifican 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 búsqueda DnsResponseCodeName 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 permite elegir el campo de salida, por lo que es útil como función general de búsqueda. 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 las funciones de ASIM

Campos de enriquecimiento

Además de los campos disponibles en 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 campos de tipo, que designan el tipo del valor almacenado en un campo relacionado. Por ejemplo, el campo SrcUsernameType designa el tipo de valor almacenado en el campo SrcUsername. 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, SrcDomain, SrcDomainType y SrcFQDN en función del valor del campo Computer.

  | invoke _ASIM_ResolveSrcFQDN('Computer')

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

Campo de proceso Campos de salida
server1 SrcHostname: server1
SrcDomain, SrcDomainType, SrcFQDN all empty
server1.microsoft.com SrcHostname: server1
SrcDomain: microsoft.com
SrcDomainType: FQDN
SrcFQDN:server1.microsoft.com

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

Selección de campos en el conjunto de resultados

Opcionalmente, el analizador puede seleccionar campos en el conjunto de resultados. La eliminación de campos innecesarios puede mejorar el rendimiento y agregar claridad evitando confusión entre los campos normalizados y los campos de origen restantes.

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

Operador Descripción Cuándo se debe usar en un analizador
project-away Elimina campos. Use project-away para campos específicos que desee eliminar del conjunto de resultados. Se recomienda no quitar los campos originales que no se normalizan del conjunto de resultados, a menos que creen confusión o sean muy grandes y puedan tener implicaciones en el rendimiento.
project Selecciona los campos que ya existían antes o que se han creado como parte de la instrucción, y quita el resto de campos. No se recomienda su uso en un analizador, ya que este no debe eliminar otros campos que no estén normalizados.

Si necesita eliminar campos específicos, como valores temporales usados durante el análisis, use project-away para eliminarlos de los resultados.

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

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

Control de variantes de análisis

Importante

Las distintas variantes representan diferentes tipos de eventos, normalmente asignados a esquemas diferentes, desarrollan analizadores diferentes.

En muchos casos, los eventos de una secuencia 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 case, o use 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 de unión 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 comience filtrando, mediante el uso de campos nativos, solo los eventos que pretende analizar. Además, si es necesario, use project-away en cada rama, antes de la unión.

Implementación de analizadores

Para implementar analizadores manualmente, cópielos en la página Registro de Azure Monitor y guarde la consulta como una función. Este método es útil para realizar pruebas. Para obtener más información, consulte Creación de una función.

Para implementar una gran cantidad de analizadores, se recomienda usar plantillas de ARM del analizador, tal como se muestra a continuación:

  1. Cree un archivo YAML basado en la plantilla correspondiente para cada esquema e incluya la consulta en él. Comience con la plantilla YAML pertinente para el esquema y el tipo de 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 desde Azure Portal, o bien desde la herramienta de PowerShell de eliminación de funciones.

  4. Implemente la plantilla mediante Azure Portal o PowerShell.

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

Sugerencia

Las plantillas de ARM pueden combinar diferentes recursos, por lo que los analizadores se pueden implementar junto con conectores, reglas de análisis o listas de seguimiento, por nombrar algunas opciones útiles. Por ejemplo, el analizador puede hacer referencia a una lista de seguimiento que se implementará de forma conjunta.

Prueba de analizadores

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

Instalación de herramientas de prueba de ASIM

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

  • El analizador está implementado.
  • La tabla de origen que utiliza el analizador está disponible.
  • La tabla de origen que utiliza 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 evaluador de esquemas de ASIM ejecutando la consulta siguiente en la página Registros de Microsoft Sentinel:

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

Controle los resultados de la siguiente manera:

Error Acción
Missing mandatory field [<Field>] Agregue el campo al analizador. En muchos casos, este sería un valor derivado o un valor constante, y no un campo ya disponible desde el origen.
Missing field [<Field>] is mandatory when mandatory column [<Field>] exists Agregue el campo al analizador. En muchos casos, este campo indica los tipos de la columna existente a la que hace referencia.
Missing field [<Field>] is mandatory when column [<Field>] exists Agregue el campo al analizador. En muchos casos, este campo indica los tipos de la columna existente a la que hace referencia.
Missing mandatory alias [<Field>] aliasing existing column [<Field>] Agregue el alias al analizador.
Missing recommended alias [<Field>] aliasing existing column [<Field>] Agregue el alias al analizador.
Missing optional alias [<Field>] aliasing existing column [<Field>] Agregue el alias al analizador.
Missing mandatory alias [<Field>] aliasing missing column [<Field>] Este error acompaña a un error similar para el campo con alias. Corrija el error del campo con alias y agregue este alias al analizador.
Type mismatch for field [<Field>]. It is currently [<Type>] and should be [<Type>] Asegúrese de que el tipo de campo normalizado es correcto, normalmente mediante una función de conversión como tostring.
Información Acción
Missing recommended field [<Field>] Considere la posibilidad de agregar este campo al analizador.
Información Acción
Missing recommended alias [<Field>] aliasing non-existent column [<Field>] Si agrega el campo con alias al analizador, asegúrese de agregar también este alias.
Missing optional alias [<Field>] aliasing non-existent column [<Field>] Si agrega el campo con alias al analizador, asegúrese de agregar también este alias.
Missing optional field [<Field>] Aunque a menudo faltan campos opcionales, merece la pena revisar la lista para determinar si alguno de los campos opcionales se puede asignar desde el origen.
Extra unnormalized field [<Field>] Aunque los campos no normalizados son válidos, merece la pena revisar la lista para determinar si alguno de los valores no normalizados se puede asignar a un campo opcional.

Nota

Los errores impedirán que el contenido que usa el analizador funcione correctamente. Las advertencias no impedirán que el contenido funcione, pero puede reducir la calidad de los resultados.

Validación de los valores de salida

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

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

Especificar un esquema es opcional. Si no se especifica un esquema, el campo EventSchema sirve para identificar el esquema al que debe adherirse el evento. Si un evento no incluye un campo EventSchema, 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 los analizadores más antiguos que no establecen el campo EventSchema.

Nota

Se necesitan paréntesis vacíos después del nombre de la función aunque no se especifique ningún esquema.

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:

Message Acción
(0) Error: type mismatch for column [<Field>]. It is currently [<Type>] and should be [<Type>] Asegúrese de que el tipo de campo normalizado es correcto, normalmente mediante una función de conversión como tostring.
(0) Error: Invalid value(s) (up to 10 listed) for field [<Field>] of type [<Logical Type>] Asegúrese de que el analizador asigna el campo de origen correcto al campo de salida. Si se asigna correctamente, actualice el analizador para transformar el valor de origen al tipo, valor o formato correctos. Consulte la lista de tipos lógicos para obtener más información sobre los valores y formatos correctos de cada tipo lógico.

Tenga en cuenta que la herramienta de prueba enumera solo una muestra de 10 valores no válidos.
(1) Warning: Empty value in mandatory field [<Field>] Los campos obligatorios deben rellenarse, no solo definirse. Compruebe si el campo se puede rellenar desde otros orígenes para los registros para los que el origen actual está vacío.
(2) Info: Empty value in recommended field [<Field>] Normalmente, los campos recomendados se deben rellenar. Compruebe si el campo se puede rellenar desde otros orígenes para los registros para los que el origen actual está vacío.
(2) Info: Empty value in optional field [<Field>] Compruebe si el campo con alias es obligatorio o recomendado y, de ser así, si se puede rellenar desde otros orígenes.

Muchos de los mensajes también notifican el número de registros que generaron el mensaje y su porcentaje de la muestra 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 de análisis general.
  • Los valores vacíos del 25 % pueden indicar una variante de evento que no se ha analizado correctamente.
  • Un puñado de valores vacíos puede ser un problema insignificante.

Nota

Los errores impedirán que el contenido que usa el analizador funcione correctamente. Las advertencias no impedirán que el contenido funcione, pero puede reducir la calidad de los resultados.

Contribución de analizadores

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

Para contribuir con los analizadores:

Documentación de advertencias aceptadas

Si las advertencias enumeradas por las herramientas de pruebas 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 abreviada del mensaje de advertencia que identifique de forma única. El valor se usa para buscar coincidencias con los mensajes de advertencia al realizar pruebas automatizadas y omitirlos.

Directrices para el envío de muestras

Los datos de muestra son necesarios para solucionar problemas del analizador y para garantizar que las futuras actualizaciones del analizador se ajusten a las muestras anteriores. Las muestras que envíe deben incluir cualquier variante de evento que admita el analizador. Asegúrese de que los eventos de muestra incluyan todos los tipos de eventos posibles, formatos de eventos y variaciones, como eventos que representen actividades exitosas y erróneas. Asegúrese también de que se representan las variaciones en los formatos de los valores. Por ejemplo, si un nombre de host puede representarse como un FQDN o como un simple nombre de host, los eventos de muestra deben incluir ambos formatos.

Para enviar las muestras de eventos, siga estos pasos:

  • En la pantalla Logs, ejecute una consulta que extraerá de la tabla de origen solo los eventos seleccionados por el analizador. Por ejemplo, para el analizador DNS de Infoblox, use la siguiente consulta:
    Syslog
    | where ProcessName == "named"

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

  • En la pantalla Logs, ejecute una consulta que generará el esquema o la tabla de entrada del analizador. Por ejemplo, para el mismo analizador DNS 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 su PR en la carpeta /Sample Data/ASIM. Si el archivo ya existe, agregue su identificador de GitHub al nombre, por ejemplo: <EventVendor>_<EventProduct>_<EventSchema>_SchemaTest_<GitHubHandle>.csv

Directrices para el envío de los resultados de las 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 las pruebas, siga estos pasos:

  • Ejecute las pruebas del analizador descritas en la sección de pruebas.

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

  • Incluya ambos archivos en su PR 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:

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