Ejecuta una regla en relación con datos en vivo
Cuando crea una regla, al principio no busca detecciones según eventos recibidos en tu cuenta de Google Security Operations en tiempo real. Sin embargo, debes establecer para buscar detecciones en tiempo real estableciendo el botón de activación Live Rule habilitar.
Para establecer una regla como activa, sigue estos pasos:
Navega al panel de reglas.
Haz clic en el ícono de opción Reglas para una regla y activa la Regla activa (Live Rule).
Reglas vigentes
Para ver las detecciones que generó una regla activa, elige Ver detecciones de reglas.
Cuota de reglas
Haz clic en el botón de capacidad para mostrar los límites de la cantidad de reglas que se pueden habilitar como activas. Se encuentra en la esquina superior derecha del panel de reglas.
Google Security Operations impone los siguientes límites de reglas:
- Cuota de reglas de varios eventos: Muestra el recuento actual de reglas de varios eventos habilitadas como publicadas y la cantidad máxima de reglas que se pueden habilitar como publicadas. Obtén más información sobre la diferencia entre las reglas de un evento y las reglas de varios eventos aquí.
- Cuota total de reglas: Muestra el recuento total actual de reglas habilitadas como activas en todos los tipos de reglas, así como la cantidad máxima de reglas que se pueden habilitar como activas.
Aquí encontrarás más información sobre los diferentes tipos de reglas.
Ejecuciones de reglas
Las ejecuciones de reglas en vivo para un bucket de tiempo del evento determinado se activarán con una frecuencia decreciente. Habrá una ejecución de limpieza final, después de la cual no se iniciará más ejecución.
Cada ejecución se ejecuta en las versiones más recientes de las listas de referencia que se usan en las reglas, así como en el enriquecimiento de datos de entidades y eventos más reciente.
Esto significa que algunas detecciones se pueden generar de forma retrospectiva si solo se detectan en ejecuciones posteriores. Por ejemplo, la última ejecución podría usar la versión más reciente de la lista de referencia, que ahora detecta más eventos, y los eventos y los datos de la entidad se pueden volver a procesar debido a los nuevos enriquecimientos.
Latencias de detección
Varios factores determinan cuánto tiempo tarda en generarse una detección a partir de una regla activa. En la siguiente lista, se incluyen los diferentes factores que contribuyen a las demoras en la detección:
- Tipos de reglas
- Frecuencia de ejecución
- Retraso en la transferencia
- Uniones contextuales
- Datos de UDM enriquecidos
- Problemas con la zona horaria
- Listas de referencia
Tipos de reglas
- Las reglas de evento único se ejecutan casi en tiempo real en forma de transmisión. Usa estas reglas, cuando sea posible, para minimizar la latencia.
- Las reglas para varios eventos se ejecutan de forma programada, lo que genera una latencia más alta debido al tiempo entre las ejecuciones programadas.
Frecuencia de ejecución
Para lograr detecciones más rápidas, usa una frecuencia de ejecución y una ventana de coincidencia más cortas. Usar ventanas de coincidencia más cortas (de menos de una hora) permite ejecuciones más frecuentes.
Retraso en la transferencia
Asegúrate de que los datos se envíen a Google Security Operations en cuanto ocurra el evento. Cuando revises una detección, presta mucha atención al evento de UDM y a las marcas de tiempo de la transferencia.
Uniones contextuales
Las reglas de varios eventos que con datos contextuales, como UEBA o Entity Graph, podrían tener mayores retrasos. Primero, Google SecOps debe generar los datos contextuales.
Datos de UDM enriquecidos
Google SecOps enriquece los eventos con datos de otros eventos. Para identificar si una regla está evaluando un campo enriquecido, revisa el Visor de eventos. Si la regla evalúa un campo enriquecido, es posible que la detección se retrase.
Problemas con la zona horaria
Las reglas se ejecutan con más frecuencia para los datos en tiempo real. Los datos pueden llegar en tiempo real, pero Google SecOps podría tratarlos como datos tardíos si la hora del evento es incorrecta debido a problemas de zona horaria. La zona horaria predeterminada de la SIEM de Google SecOps es UTC. Si los datos originales tienen una marca de tiempo de evento establecida en otra zona horaria además de UTC, actualiza la zona horaria de los datos. Si no es posible actualizar la zona horaria en la fuente del registro, comunícate con el equipo de asistencia para que se pueda anular la zona horaria.
Reglas de inexistencia
Las reglas que comprueban la inexistencia (por ejemplo, las que contienen !$e o #e=0) se ejecutan con un retraso de al menos una hora para garantizar que los datos tengan tiempo de llegar.
Listas de referencia
Las ejecuciones de reglas siempre usan la versión más actualizada de una lista de referencia. Si la lista de referencia se actualizó recientemente, es posible que una nueva detección aparezca tarde porque es posible que la detección se incluya con el nuevo contenido de la lista actualizada durante ejecuciones posteriores de la regla programada.
Para lograr latencias de detección más bajas, recomendamos hacer lo siguiente:
- Envía datos de registro a Google Security Operations en cuanto ocurra el evento.
- Audita las reglas para ver si es necesario usar datos inexistentes o enriquecidos.
- Configura una frecuencia de ejecución menor.
Estado de la regla
Las reglas activas pueden tener uno de los siguientes estados:
Habilitada: la regla está activa y funciona con normalidad como una regla activa.
Inhabilitada: La regla está inhabilitada.
Limitada: Las reglas activas pueden tener este estado cuando muestran un uso anormalmente alto de los recursos. Las reglas limitadas están aisladas de las demás reglas activas. reglas del sistema para mantener la estabilidad de Google Security Operations.
En el caso de las reglas activas limitadas, no se garantiza la ejecución correcta de estas. Sin embargo, si la ejecución de la regla se ejecuta correctamente, las detecciones se conservan y están disponibles. para que los revises. Las reglas activas limitadas siempre generan un mensaje de error. que incluye información sobre cómo mejorar el rendimiento de la regla.
Si el rendimiento de una regla limitada no mejora en un plazo de tres días, el estado cambiará a Detenido.
Detenida: Las reglas en tiempo real ingresan este estado cuando han estado en Limitada. estado durante 3 días y no mostraron ninguna mejora en el rendimiento. Ejecuciones de esta regla se detuvo y hay mensajes de error con información sobre mejorar el rendimiento de la regla.
Para que cualquier regla activa vuelva al estado Habilitada, sigue Prácticas recomendadas de YARA-L para mejorar el rendimiento de su regla y guardarla. Después de guardar la regla, se restablecerá al estado Habilitada y tardará al menos una hora. antes de que la regla vuelva a obtener el estado Limitada.
Puedes resolver potencialmente los problemas de rendimiento con una regla si la configuras se ejecute con menos frecuencia. Por ejemplo, podrías volver a configurar una regla para que no se ejecute cada 10 minutos a ejecutarse una vez por hora o una vez cada 24 horas. Sin embargo, cambiar la frecuencia de ejecución de una regla no cambiará su estado a Habilitada. Si hace una pequeña modificación en la regla y la guarda, puede restablece automáticamente su estado Enabled.
Los estados de las reglas se muestran en el Panel de reglas y también se puede acceder a ellos con la API de Detection Engine. Errores generados por las reglas en la categoría Limitado o Detenido están disponibles mediante el Método de la API de ListErrors. El error indicará que la regla se encuentra en el estado Limitada o Detenida. y te dirige a la documentación sobre cómo resolver el problema.