Alerting: Mejores prácticas

Document created by RSA Information Design and Development on Feb 9, 2017
Version 1Show Document
  • View in full screen mode
  

Use estas mejores prácticas como guía para escribir y administrar reglas, implementarlas y mantener el estado del sistema para los servicios de ESA.

Comprender tipos de reglas de Event Stream Analysis

El servicio Security Analytics Event Stream Analysis (ESA) proporciona analítica de flujo avanzada como correlación y procesamiento de eventos complejos a altos rendimientos y baja latencia.  Puede procesar grandes volúmenes de datos de eventos dispares que provienen de Concentrators. Sin embargo, cuando trabaja con Event Stream Analysis, debe tener en cuenta los factores que afectan el uso de recursos para crear reglas eficaces. 

Cada evento que recibe ESA se evalúa para determinar si puede activar una regla. Se pueden implementar tres tipos de reglas para determinar lo que debe hacer el motor de ESA con el evento entrante. Cada uno de estos tipos de reglas tiene distintos impactos en la utilización de recursos del sistema. Los tres tipos de reglas se pueden crear mediante el generador de reglas o reglas de EPL avanzado, o se pueden descargar a través de RSA Live. En la siguiente tabla se indica el tipo de regla y el impacto que puede tener en los recursos del sistema.

                       
Tipo de reglaDescripción

Regla de filtro simple

Esta regla no tiene ninguna correlación con otros eventos. En el momento de la recopilación, esta regla se evalúa con respecto a un conjunto de condiciones y, si esas condiciones se cumplen, se genera una alerta. Si no coincide ninguna condición, el motor deja ir rápidamente el evento para liberar uso de la memoria. Estas reglas no usan memoria puesto que los eventos no se conservan más allá de la evaluación inicial. El uso de recursos de la memoria no aumenta a medida que se implementan más reglas de filtro simple. Sin embargo, si la condición del filtro es demasiado genérica, es posible que esta regla genere demasiadas alertas, las cuales llevarán al límite los recursos del sistema en términos de su almacenamiento y recuperación.
Por ejemplo, podría escribir una regla que genere una alerta cuando llegue actividad de red HTTP a través de un puerto HTTP no estándar.

Regla de ventana de eventos Esta regla evalúa condiciones específicas en un conjunto de eventos durante un periodo. En el momento de la recopilación, la regla se evalúa con respecto a un conjunto de condiciones. Si esas condiciones se cumplen, el evento se conserva en la memoria durante una cantidad de tiempo específica. Cuando transcurre el tiempo especificado, los eventos se eliminan de la ventana de tiempo si la cantidad de eventos recopilados no cumple con el umbral para activar una alerta. El consumo de memoria de estas reglas depende en gran medida de la tasa (tráfico) de eventos entrantes, la cantidad de datos por evento y la cantidad de tiempo especificada en la ventana de eventos. Cada evento coincidente se conserva en la memoria hasta que transcurre la ventana de tiempo. Por lo tanto, mientras más prolongada sea la ventana de tiempo, mayor será el volumen potencial.  Por ejemplo, podría escribir una regla que genere una alerta si un usuario no puede iniciar sesión cinco veces en ningún sistema en un intervalo de tiempo de diez minutos.

Regla Seguido de

Esta regla evalúa una cadena de eventos entrantes para determinar si la secuencia de eventos coincide con una condición específica. En el momento de la recopilación, la regla se evalúa con respecto a un conjunto de condiciones. Si las condiciones se cumplen, se produce una de dos acciones:

  • Si se trata del primer evento de la secuencia, se inicia un nuevo hilo de ejecución de eventos y el evento se conserva como el principal de la secuencia.
  • Si el evento pertenece a un hilo de ejecución de eventos existente, se agrega a esa secuencia.

En ambos casos, el evento se conserva en la memoria. En este tipo de regla, la cantidad de uso de recursos es especialmente sensible al ambiente del cliente. Si la condición del filtro genera muchos hilos de ejecución de eventos, los recursos se consumen para cada hilo de ejecución nuevo (además del evento). Además, si el final del hilo de ejecución de eventos no se alcanza nunca (es decir, nunca se genera una alerta), el evento completo se guarda en la memoria indefinidamente.  Por ejemplo, podría escribir una regla que genere una alerta cuando un usuario no logra iniciar sesión en un servidor, después realiza un inicio de sesión correcto y, a continuación, crea una nueva cuenta.

 

Además del uso de la memoria analizado anteriormente, la generación de la alerta también consume recursos del sistema. Cada alerta que se genera se debe almacenar para su recuperación e Incident Management también debe procesarla. Este proceso usa espacio en disco para almacenamiento, requiere que se consuma memoria de la base de datos y aumenta la utilización del CPU con la ejecución de consultas. 

Cuando escribe e implementa reglas, debe tener en cuenta que cada una de estas acciones le “cuesta” recursos del sistema. Las siguientes secciones están diseñadas para ayudarlo a mantener el uso en un nivel adecuado y a monitorear problemas en caso de sobrecarga de los sistemas. 

Mejores prácticas para escribir reglas

Estas son reglas generales para la escritura de reglas.

  • Cree alertas para eventos útiles. El propósito de una alerta debe ser informar sobre un evento que requiere una acción inmediata y específica. Para aquellos eventos que no necesitan ninguna acción o que solo requieren reconocimiento, puede crear un informe. Esto ayuda a impedir la sobrecarga de la base de datos que almacena alertas.
  • Configure reglas nuevas como reglas de prueba para que pueda observar cómo reaccionan en su ambiente. Si implementa reglas nuevas como reglas de prueba, se deshabilitarán si se supera el umbral de memoria configurado. También puede usar la función de instantánea de la memoria para ver cuánta memoria se usó cuando se deshabilitó una regla de prueba. Para obtener más detalles, consulte Trabajar con reglas de prueba.
  • Configure notificaciones de alertas solo después de que se completen las pruebas y el ajuste de las reglas. Con esto puede asegurarse de que no recibirá una gran cantidad de notificaciones si una regla tiene un comportamiento distinto al previsto. 
  • Las reglas deben ser específicas de modo que se limite el uso de recursos. Utilice las siguientes reglas para limitar el uso:
    • Haga que los filtros de la regla excluyan todos los eventos, salvo los necesarios, de modo que la regla se active con exactitud.
    • Haga que el tamaño de las ventanas (tiempo de la ventana para correlación) sea lo más breve posible.
    • Limite los eventos que incluye en la ventana: por ejemplo, si solo desea ver eventos de IDS, asegúrese de incluir únicamente esos eventos en la ventana de tiempo. 
  • Las reglas se deben ajustar a un nivel de alerta que sea administrable. Si recibe una gran cantidad de alertas, su propósito y su utilidad se pierden. Además, es posible que la base de datos que almacena alertas se desborde, lo cual puede impedir que el sistema procese las alertas o hacer que se retrase. Por ejemplo, es posible que desee saber sobre el tráfico cifrado a otros países. Sin embargo, podría limitar la lista a países que constituyen riesgos conocidos. Esto limita el volumen de alertas a un nivel que puede administrar.

Mejores prácticas para trabajar con reglas de RSA Live

Estas son reglas para las reglas de RSA Live.

  • Implemente reglas de RSA Live en lotes pequeños. No todas las reglas son aptas para todos los ambientes. La mejor manera de asegurarse de que las reglas de RSA Live funcionen correctamente es implementarlas en lotes pequeños que permitan probarlas en el ambiente. Si implementa lotes pequeños, es mucho más fácil detectar si una regla específica tiene un problema. 
  • Lea las descripciones de las reglas que se proporcionan con las reglas de RSA Live. Las reglas de ESA no se aplican a todas las situaciones. No todas las reglas funcionarán en su ambiente. Las descripciones de las reglas indican los parámetros que tendrá que modificar para implementar correctamente una regla en su ambiente.
  • Configure sus parámetros.  Las reglas de RSA Live tienen parámetros que se deben modificar. Si no modifica los parámetros, es posible que la regla no funcione o puede agotar la memoria.
  • Implemente las reglas nuevas como reglas de prueba de modo que pueda observar cómo reaccionan en el ambiente. Si implementa reglas nuevas como reglas de prueba, se inhabilitarán si se supera el umbral de la memoria configurado. Para obtener más detalles, consulte Trabajar con reglas de prueba.

Mejores prácticas para implementar reglas

Estas son reglas generales para implementar reglas.

  • Implemente las reglas en lotes pequeños de modo que pueda observar cómo reaccionan en el ambiente. No todos los ambientes son iguales y será necesario ajustar una regla en cuanto al uso de la memoria, el volumen de alertas y la detección eficaz de eventos.
  • Pruebe las reglas antes de configurar notificaciones de alertas. Configure notificaciones de alertas solo después de que se completen las pruebas y el ajuste de las reglas. Con esto puede asegurarse de no recibirá una gran cantidad de alertas si una regla tiene un comportamiento distinto al previsto.
  • Monitoree el estado del sistema como parte del proceso de implementación. Cuando implemente reglas, monitoree el estado del sistema como parte del proceso de implementación. Puede ver la utilización total de la memoria para ESA en la pestaña Estado y condición. Para obtener más información, consulte “Visualización de estadísticas de Estado y condición” en Solucionar problemas de ESA.

Mejores prácticas para el estado del sistema

Estas son reglas generales para el estado del sistema.

  • Configure la base de datos de alertas para mantener un nivel adecuado de alertas. ESA usa MongoDB para almacenar las alertas. Si MongoDB se desborda con alertas, puede retrasar o detener la base de datos. Para asegurarse de que la base de datos mantenga un nivel adecuado de alertas, configure ajustes con el fin de borrar las alertas regularmente. Para hacer esto, consulte “Configurar el almacenamiento de ESA” en la Guía de configuración de Event Stream Analysis (ESA).
  • Configure reglas nuevas como reglas de prueba. Un problema común es que las reglas nuevas pueden causar dificultades relacionadas con la memoria. Para impedir esto, puede configurar las reglas nuevas como reglas de prueba. Si se alcanza el umbral de la memoria configurado, todas las reglas de prueba se inhabilitan para impedir que se agote la memoria del sistema.  Para obtener más información acerca de las reglas de prueba, consulte Trabajar con reglas de prueba.
  • Configure umbrales en el módulo Estado y condición que le informen si el uso de la memoria es demasiado alto. El módulo Estado y condición incluye métricas que rastrean el uso de la memoria. Puede configurar alertas y notificaciones que le informan por correo electrónico si se cruzan esos umbrales.  Para obtener más información acerca de las estadísticas de la memoria que puede ver, consulte “Visualización de estadísticas de Estado y condición” en Solucionar problemas de ESA
  • Monitoree las métricas de memoria para cada regla en el módulo Estado y condición. Ahora puede ver el uso estimado de la memoria para cada regla activa en el módulo Estado y condición. Puede usar esta información para asegurarse de que las reglas no usen demasiada memoria. Para obtener más información acerca de las estadísticas de memoria que puede ver, consulte “Visualización de estadísticas de Estado y condición” en Solucionar problemas de ESA
You are here
Table of Contents > Guía de inicio rápido de ESA > Mejores prácticas

Attachments

    Outcomes