Análisis temporal vs. Análisis basado en grupos en Machine Learning de Elastic

La función de Machine Learning de Elastic permite a los usuarios descubrir dos tipos principales de anomalías: las temporales (respecto del tiempo) y las basadas en grupos (respecto de todas las demás). Pero ¿qué diferencias existen entre estos dos tipos y en qué circunstancias usarían uno en lugar del otro? En este blog se analizan los detalles que subyacen a los análisis, sus méritos y las mejores prácticas con base en reglas generales comunes.

En primer lugar, veamos los conceptos de anomalía temporal y anomalía basada en grupos. Para ello, aclaremos algunos datos:

Detección de anomalías temporales

-Es el comportamiento predeterminado de la función de Machine Learning de Elastic, a menos que se determine de forma específica que el análisis se base en grupos. -Es una comparación del comportamiento de una entidad respecto de sí misma con el tiempo. -Puede aprovechar una “división” (a través de by_field_name o partition_field_name) para crear bases de referencia individuales para cada instancia de algo (es decir, una base de referencia única por host o usuario). -No es realmente adecuada para elementos de datos de alta cardinalidad o muy dispersos (por ejemplo, las direcciones IP externas de visitantes de un sitio web pueden ser dispersas y también tener alta cardinalidad, en el orden de los cientos de miles o más). Esto generará problemas de rendimiento si los límites de memoria del trabajo no aumentan respecto del límite predeterminado. Sin embargo, aun cuando esto se hiciera existiría la probabilidad de que el análisis basado en grupos sea un enfoque más apropiado.

Detección de anomalías basadas en grupos

-Solo se invoca cuando se usa over_field_name (o el asistente de trabajo de grupos de Kibana). El campo declarado como over_field_name es lo que define el grupo. -Es un análisis de pares de miembros de un grupo o, dicho en términos más precisos, una comparación de una entidad individual con un modelo colectivo de todos los pares observados con el tiempo. -También puede aprovechar una “división” (a través de by_field_name o partition_field_name) para crear subgrupos. -Generalmente, es bastante apropiada para elementos de datos de alta cardinalidad o dispersos porque los miembros individuales contribuyen a un modelo colectivo de comportamiento.

Caso de uso de ejemplo

Ahora que ya nos encargamos de esa parte, analicemos un caso de uso hipotético que podría servirnos para determinar el enfoque indicado.

Imaginen que queremos rastrear el número de documentos descargados de un servidor de documentos interno y supongamos que el servidor contiene documentos de amplia aplicabilidad para todos los integrantes de la empresa (una empresa grande con más de 50 000 empleados). A su vez, cualquier persona puede acceder a este servidor de documentos en cualquier momento. Por último, supongamos también que el registro de acceso del servidor de documentos hace un seguimiento de cada acceso a un documento y del usuario que hace la descarga en cuestión.

Ejemplo de anomalía temporal

Si elegimos la detección de anomalías temporales y estructuramos un análisis similar a lo siguiente:

    "detectors": [
      {
        "function": "count",
        "partition_field_name": "user"
      }
    ]

Nuestra expectativa, en consecuencia, consistirá en hacer un seguimiento del volumen de descargas, por cada usuario, por nombre y de forma individual con el tiempo. Por lo tanto, si user=”Wilma” normalmente descarga unos 50 documentos por día (forma parte del equipo de ingeniería y usa con mucha frecuencia los documentos del servidor), sería un evento anómalo que Wilma cambiara drásticamente su comportamiento e hiciera muchas menos o más descargas que las habituales (por ejemplo, 5000 documentos por día).

Además, como consideración hecha previamente, necesitaríamos estar al tanto de la cantidad de usuarios diferentes de los que esperaría un seguimiento por parte de la función de Machine Learning. Con 50 000 usuarios únicos, esto podría manejarse si ampliáramos el límite de memoria del trabajo de Machine Learning. Sin embargo, otro aspecto que se debe tener en cuenta es la posibilidad de que un usuario no descargue documentos con regularidad todos los días, con lo cual su actividad podría ser bastante dispersa. Puede descargar algunos un día y luego dejar de hacerlo durante meses. Podría ser difícil establecer una base de referencia precisa por usuario si no hay disponibles observaciones uniformes por cada uno.

Sin embargo, hay un aspecto primordial: ¿qué tal si aparece otra persona (user=”Fred”), descarga 5000 documentos en un día y no vuelve a hacer una descarga? ¿Sería esto inusual? ¿Es Fred una amenaza interna o algún malware de extracción no autorizada de datos usó sus credenciales para robar documentos con el propósito de transmitirlos a un dominio externo al de la organización? Al aplicar la detección de anomalías temporales para el análisis, la respuesta es indeterminada; no sabemos con certeza si se trata de una situación inusual en el caso de “Fred” porque no contamos con un historial de él para hacer comparaciones (solo hemos visto un ejemplo).

Ejemplo de anomalía basada en grupos

De forma alternativa, si enmarcamos el problema usando la detección de anomalías basadas en grupos, como se muestra a continuación:

    "detectors": [
      {
        "function": "count",
        "over_field_name": "user"
      }
    ]

Podemos lograr lo siguiente:

-Podemos usar los usuarios que estén presentes en cada bucket_span (en este caso, un día) para crear un modelo colectivo del recuento de descargas típico para los usuarios, de forma colectiva. -Luego, podemos comparar a cada usuario en cada día respecto de ese modelo colectivo.

Ahora, si Wilma y la mayoría de sus cohortes descargan entre 10 y 75 documentos por día, el modelo “colectivo” global de uso típico se encontrará en ese rango. Si Fred un día descarga 5000 documentos, la situación será anómala porque se comparará su comportamiento con el de Wilma y todas sus cohortes. Fred se destacará como un valor atípico.

Hay, sin embargo, un aspecto fundamental. Si Wilma, en lugar de Fred, descarga 5000 documentos, será ella quien se identifique como un valor atípico anómalo, no precisamente por haber hecho más descargas que las acostumbradas, sino más bien por haber hecho más descargas que las del modelo de uso “típico” que ella misma ayudó a establecer con el tiempo, junto a sus cohortes.

Lo importante es que Wilma se resaltará como valor atípico en esta situación, sin importar si se selecciona la detección de anomalías temporales o basadas en grupos, pero el enfoque de grupos es más flexible en este caso porque:

1. No se ve afectado por la dispersión de datos.
2. Es más eficaz, en términos de memoria, cuando el número de diferentes usuarios se vuelve elevado (porque los modelos individuales por usuario no son necesarios).
3. Permite encontrar valores atípicos con poco historial o sin él, como en el caso de Fred.
4. Identifica, de todos modos, a Wilma como un valor atípico si su comportamiento cambia drásticamente hasta un punto en el que no responde al comportamiento colectivo.

Una sugerencia adicional: si deciden aplicar análisis basado en grupos, lo más coherente será que construyan sus grupos de modo que sean lo más homogéneos posible. En otras palabras, si tienen clusters importantes de tipos de usuarios (es decir, ingenieros vs. personal de RR. HH.), podría ser más efectivo dividir a esos usuarios en grupos separados y hacer dos análisis individuales, en lugar de esperar que se agrupen indiscriminadamente.

Un último comentario: si hay miembros de un grupo que tengan previsto excluir, consideren apartarlos filtrando los datos de entrada o usando reglas para apartar los resultados.

Esperamos que esta explicación les haya resultado útil para comparar los dos enfoques. Si quieren probar el Machine Learning en sus datos, descarguen el Elastic Stack y habiliten la licencia por 30 días, o bien inicien una prueba gratuita en Elastic Cloud.