Ejecuta una regla en relación con los datos en vivo
Cuando creas una regla, esta no busca detecciones en función de los eventos recibidos en tu cuenta de Operaciones de seguridad de Google en tiempo real. Sin embargo, debes establecer para buscar detecciones en tiempo real estableciendo el botón de activación Live Rule habilitar.
Para activar una regla, completa los siguientes 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 genera una regla activa, selecciona 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 publicadas en todos los tipos de reglas y la cantidad máxima de reglas que se pueden habilitar como publicadas.
Obtén más información sobre los diferentes tipos de reglas aquí.
Ejecuciones de reglas
Las ejecuciones de reglas en vivo para un bucket de tiempo del evento determinado se activarán con una frecuencia decreciente. Se realizará una ejecución de limpieza final, después de la cual no se iniciará ninguna ejecución más.
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 de transferencia
- Uniones contextuales
- Datos enriquecidos del UDM
- 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 de 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 más corta y una ventana de coincidencia más pequeña. 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 enriquecidos del UDM
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 del SIEM de Google SecOps es UTC. Si los datos originales tienen una marca de tiempo de evento configurada 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 verifican la no existencia (por ejemplo, las reglas que contienen !$e o #e=0) se ejecutan con al menos una hora de retraso 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, te recomendamos que hagas lo siguiente:
- Enviar los datos de registro a Google Security Operations en cuanto se produce 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 de recursos anormalmente alto. Las reglas limitadas están aisladas de las otras reglas activas del sistema para mantener la estabilidad de Google Security Operations.
En el caso de las reglas en vivo limitadas, no se garantiza que se ejecuten correctamente. Sin embargo, si la ejecución de la regla se realiza correctamente, las detecciones se retienen y están disponibles para que las revises. Las reglas en vivo limitadas siempre generan un mensaje de error, que incluye información para mejorar el rendimiento de la regla.
Si el rendimiento de una regla Limitada no mejora en un plazo de 3 días, su estado cambiará a Detenida.
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 en volver a alcanzar 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 a través de la API de Detection Engine. Los errores generados por reglas en el estado Limited o Paused están disponibles con el método de API de ListErrors. El error indicará que la regla está en el estado Limitada o Detenida y te dirigirá a la documentación para resolver el problema.