Información sobre la disponibilidad de los datos para la búsqueda

Se admite en los siguientes sistemas operativos:

Google SecOps

En este documento, se detalla el ciclo de vida de la transferencia de datos, incluido el flujo y la latencia de los datos de extremo a extremo, y cómo estos factores afectan la disponibilidad de los datos transferidos recientemente para las consultas y el análisis.

Transfiere y procesa datos en Google SecOps

En esta sección, se describe cómo Google SecOps ingiere, procesa y analiza los datos de seguridad.

Transferencia de datos

La canalización de transferencia de datos comienza con la recopilación de tus datos de seguridad sin procesar de fuentes como las siguientes:

• Registros de seguridad de tus sistemas internos
• Datos almacenados en Cloud Storage
• Tu centro de operaciones de seguridad (SOC) y otros sistemas internos

Google SecOps incorpora estos datos a la plataforma con uno de sus métodos de transferencia seguros.

Los principales métodos de transferencia son los siguientes:

• Transferencia Google Cloud directa

  Google SecOps usa la transferencia Google Cloud directa para extraer automáticamente los registros y los datos de telemetría de los Google Cloudde tu organización, incluidos Cloud Logging, los metadatos de Cloud Asset Inventory y los resultados de Security Command Center Premium.

• APIs de transferencia

  Envía datos directamente a Google SecOps a través de sus APIs de transferencia públicas de REST. Puedes usar este método para las integraciones personalizadas o para enviar datos como registros no estructurados o eventos con formato previo del modelo de datos unificados (UDM).

• Agente de Bindplane

  Puedes implementar el versátil agente de Bindplane en tu entorno (local o en otras nubes) para recopilar registros de una amplia variedad de fuentes y reenviarlos a Google SecOps.

• Feeds de datos

  En Google SecOps, configuras feeds de datos para extraer registros de fuentes externas, como buckets de almacenamiento en la nube externos específicos (como Amazon S3) o APIs externas (como Okta o Microsoft 365).

Normalización y enriquecimiento de datos

Una vez que los datos llegan a Google SecOps, la plataforma los procesa en las siguientes etapas:

1. Análisis y normalización

   Primero, un analizador procesa los datos de registro sin procesar para validar, extraer y transformar los datos de su formato original en el UDM estandarizado. La normalización y el análisis te permiten analizar diversas fuentes de datos (por ejemplo, registros de firewall, datos de extremos, registros de la nube) con un esquema único y coherente. El registro sin procesar original se almacena junto con el evento del UDM.

2. Indexación

   Después de la normalización, Google SecOps indexa los datos del UDM para ofrecer velocidades de consulta rápidas en conjuntos de datos masivos, lo que permite buscar los eventos del UDM.

3. Creación de alias y enriquecimiento del UDM

   • Google SecOps realiza alias y enriquecimiento del UDM para enriquecer los eventos del UDM con contexto valioso, ya que identifica y agrega datos de contexto e indicadores para las entidades de registro. Por ejemplo, conecta el login name de un usuario con sus diferentes IP addresses, hostnames y MAC addresses.
   • Geolocalización: Google SecOps enriquece las direcciones IP con datos de geolocalización.

4. Enriquecimiento del ECG

   • Google SecOps realiza un alias de ECG que combina el contexto de varias fuentes (como IdP, CMDB y la inteligencia sobre amenazas) para crear un perfil de entidad consolidado en el gráfico de contexto de la entidad.

   • Inteligencia sobre amenazas: Google SecOps compara automáticamente los datos de eventos con la vasta inteligencia sobre amenazas de Google, incluidas fuentes como Google Threat Intelligence y Navegación Segura, para identificar amenazas maliciosas conocidas, como domains, IP addresses y file hashes.

   • WHOIS: Google SecOps enriquece los nombres de dominio con su información pública de registro de WHOIS.

Disponibilidad de los datos para el análisis

Después de procesarse y enriquecerse, los datos del UDM están disponibles de inmediato para el análisis:

• Detección en tiempo real

  El Motor de detección ejecuta automáticamente reglas personalizadas y creadas por Google habilitadas para Live Rule en los datos entrantes en vivo para identificar amenazas y generar alertas.

• Búsqueda e investigación

  Un analista puede usar los métodos de búsqueda para buscar en todos estos datos normalizados y enriquecidos. Por ejemplo, usar la búsqueda de UDM para cambiar entre entidades relacionadas (como un user, su asset y un domain malicioso) y, luego, investigar las alertas

Métodos de búsqueda

Google SecOps proporciona varios métodos distintos para buscar tus datos, y cada uno tiene un propósito diferente.

Búsqueda de UDM

La búsqueda de UDM es el método de búsqueda principal y más rápido, que se usa para la mayoría de las investigaciones.

• Qué busca: Consulta los eventos de UDM normalizados e indexados. Dado que todos los datos se analizan en este formato estándar, puedes escribir una consulta para encontrar la misma actividad (como un acceso) en todos tus diferentes productos (por ejemplo, Windows, Okta, Linux).
• Cómo funciona: Usas una sintaxis específica para consultar campos, operadores y valores.

• Ejemplo: principal.hostname = "win-server" AND target.ip = "10.1.2.3"

  Por lo general, los resultados están disponibles entre 2 y 15 minutos después de la transferencia.

Búsqueda de registros sin procesar

Usa la búsqueda de registros sin procesar para encontrar algo en el mensaje de registro original sin analizar que tal vez no se haya asignado a un campo de UDM. Este método de búsqueda está optimizado para búsquedas de alta velocidad y, por lo general, muestra resultados en menos de 2 segundos para indicadores específicos, como hashes de archivos o direcciones IP.

• Qué busca: Analiza el texto sin procesar original de los registros antes de que se analizaran y normalizaran. Esto es útil para encontrar cadenas, argumentos de línea de comandos o artefactos específicos que no son campos de UDM indexados.
• Cómo funciona: Usas el prefijo raw =. Puede ser más lenta que la búsqueda en UDM porque no busca en los campos indexados.
• Ejemplo (cadena): raw = "PsExec.exe"
• Ejemplo (regex): raw = /admin\$/

Búsqueda de estadísticas

Usa la Búsqueda de estadísticas para ver las tendencias a largo plazo que agregan millones de filas de datos. Debido a que la plataforma debe realizar análisis estadísticos y agrupaciones, es posible que estas consultas tarden más en cargarse.

Búsqueda en lenguaje natural (Gemini)

La búsqueda en lenguaje natural (Gemini) te permite hacer preguntas en inglés simple, que Gemini luego traduce a una consulta formal de UDM.

• Qué busca: Proporciona una interfaz conversacional para consultar datos del UDM.
• Cómo funciona: Escribes una pregunta y Gemini genera la búsqueda subyacente de UDM por ti, que luego puedes ejecutar o definir mejor.
• Ejemplo: "Muéstrame todos los inicios de sesión fallidos del usuario "bob" en las últimas 24 horas".

Búsqueda de SOAR

La búsqueda de SOAR es específica para los componentes de SOAR. La usas para administrar incidentes de seguridad, no para buscar en los registros.

• Qué busca: Busca casos y entidades (como usuarios, recursos, direcciones IP) dentro de la plataforma de SOAR.
• Cómo funciona: Puedes usar filtros de texto libre o basados en campos para encontrar casos por, por ejemplo, su ID, nombre de alerta, estado y usuario asignado.
• Ejemplo: Busca CaseIds:180 o AlertName:Brute Force.

Canalización de transferencia de datos para buscar disponibilidad

La disponibilidad de datos de extremo a extremo es el tiempo total que transcurre entre el momento en que se produce un evento y el momento en que está disponible para la búsqueda o la ejecución de reglas en Google SecOps. Esta latencia es la suma de los siguientes dos componentes:

1. Retraso de disponibilidad del lado de la fuente: Es el tiempo que transcurre entre el momento en que ocurre un evento y el momento en que el sistema fuente pone a disposición los datos de registro para la transferencia. Esta demora depende de la arquitectura, el procesamiento, la agrupación por lotes y los programas de publicación de la API del sistema fuente. Google SecOps no puede influir en esta demora. Entre los ejemplos, se incluyen las demoras cuando un sistema escribe registros en un bucket de almacenamiento o los publica en un extremo de API.

2. Tiempo de procesamiento de Google SecOps: Es el tiempo que Google SecOps necesita para procesar los datos después de recibirlos. Esta duración incluye las etapas internas de la canalización, como la transferencia, el análisis, la normalización, la indexación y el enriquecimiento.

Debes tener en cuenta ambos componentes cuando soluciones problemas relacionados con los cronogramas de visibilidad de los datos.

Demoras originadas en la fuente de datos

Los siguientes factores pueden influir en la demora de disponibilidad del lado de la fuente:

• Procesamiento por lotes: Algunos sistemas generan registros en lotes en intervalos establecidos (por ejemplo, cada hora).
• Latencia de la API: La API de origen puede tener demoras inherentes para que se puedan consultar los eventos nuevos.
• Hora de creación y publicación del evento: La marca de tiempo de un evento en un registro puede ser mucho anterior a la marca de tiempo en la que se finaliza el registro y está disponible para la recopilación.
• Regulación: Los límites de frecuencia de la API del lado de la fuente pueden ralentizar la recuperación de datos.
• Reabastecimiento inicial: La entrega y la transferencia de grandes volúmenes de datos históricos lleva tiempo.

Estos retrasos varían según la fuente de datos y el tipo de registro. Para obtener más detalles sobre los métodos de transferencia, consulta Descripción general de la transferencia de datos. La referencia de la API de Feed Management describe consideraciones específicas para los tipos de registros, como Microsoft Graph, SentinelOne, Okta y CrowdStrike.

Tiempo de procesamiento de Google SecOps

El sistema procesa los datos recién transferidos en varios pasos. La duración de estos pasos determina cuándo los datos recién transferidos estarán disponibles para las consultas y el análisis.

En la siguiente tabla, se desglosan los pasos de procesamiento de los datos recién incorporados por método de búsqueda. Los datos recién incorporados se pueden buscar después de completar estos pasos.

Método de búsqueda	Datos que se buscan	Pasos de procesamiento que contribuyen al tiempo de disponibilidad
Búsqueda de UDM Búsqueda en lenguaje natural (Gemini)	Eventos de UDM normalizados y enriquecidos	Transferencia: El registro llega al punto de transferencia de Google SecOps. Análisis: El analizador específico identifica y procesa el registro sin procesar. Normalización: Los datos se extraen y se asignan al esquema del UDM. Indexación (UDM): El registro UDM normalizado se indexa para una búsqueda rápida y estructurada. Enriquecimiento: Se agrega contexto (inteligencia sobre amenazas, geolocalización, datos de usuarios o recursos).
Búsqueda de registros sin procesar	Texto de registro original sin analizar	Transferencia: El registro llega al punto de transferencia de Google SecOps.
Detection Engine (Rules)	Eventos normalizados	Disponibilidad de eventos de UDM: Sigue los mismos pasos que se indican para la búsqueda de UDM. Evaluación de la detección: El motor de reglas evalúa los registros en "microbatches" y, por lo general, activa las detecciones entre 5 y 10 minutos después de que llega el evento.
Búsqueda de SOAR	Casos y entidades	Este es un ciclo de vida diferente, ya que busca alertas y casos, no registros. La hora se basa en lo siguiente: Disponibilidad de eventos del UDM: Utiliza los mismos pasos de procesamiento que se indican para la "búsqueda del UDM". Detección: Una regla del motor de detección debe coincidir con los eventos del UDM. Generación de alertas: El sistema crea una alerta formal a partir de la detección. Creación de casos: La plataforma de SOAR transfiere la alerta y crea un caso.

Ejemplo de flujo de datos

En el siguiente ejemplo, se muestra cómo Google SecOps transfiere, procesa, mejora y analiza tus datos de seguridad, y los pone a disposición para búsquedas y análisis adicionales.

Ejemplo de pasos de procesamiento de datos

1. Recupera datos de seguridad de servicios en la nube, como Amazon S3, o deGoogle Cloud. Google SecOps encripta estos datos en tránsito.
2. Separa y almacena tus datos de seguridad encriptados en tu cuenta. El acceso se limita a ti y a una pequeña cantidad de personal de Google para brindar asistencia, desarrollo y mantenimiento del producto.
3. Analiza y valida los datos de seguridad sin procesar, lo que facilita su procesamiento y visualización.
4. Normaliza e indexa los datos para realizar búsquedas rápidas.
5. Almacena los datos analizados y los indexa en tu cuenta.
6. Enriquece con datos de contexto.
7. Ofrece acceso seguro para que los usuarios busquen y revisen sus datos de seguridad.
8. Compara tus datos de seguridad con la base de datos de software malicioso de Google Threat Intelligence para identificar coincidencias. En una vista de eventos de Google SecOps, como la vista de activos, haz clic en VT Context para ver la información de Google Threat Intelligence. Google SecOps no comparte tus datos de seguridad con la Inteligencia contra amenazas de Google.

Ejemplos del tiempo esperado hasta que esté disponible la Búsqueda

El tiempo esperado hasta que los datos recién incorporados estén disponibles para la Búsqueda es la suma de las duraciones del flujo a lo largo del flujo de datos.

Por ejemplo, el tiempo promedio típico para la disponibilidad de datos en la búsqueda de UDM es de aproximadamente 5 minutos y 30 segundos desde que se envían los datos al servicio de transferencia de Google SecOps.

Paso de flujo de datos	Descripción	Duración del flujo
Cloud Storage a Registros sin procesar	Transfiere registros sin procesar desde Cloud Storage.	Menos de 30 segundos
Registros de seguridad al Servicio de reenvío de datos	Transmite registros de seguridad de los sistemas internos a la plataforma.	N/A
Servicio de reenvío de datos a Registros sin procesar	Envía datos de seguridad sin procesar recibidos de varias fuentes a la canalización de transferencia.	Menos de 30 segundos
Registros sin procesar a Analizar y validar	Analiza y valida los registros sin procesar en el formato del UDM.	Menos de 3 minutos
Analizar y validar a Index	Indexa los datos del UDM analizados para realizar búsquedas rápidas.	N/A
Índice a Datos del cliente analizados	Pone a disposición los datos indexados como datos del cliente analizados para su análisis.	Menos de 2 minutos

Soluciona problemas

En esta sección, se proporciona orientación para la solución de problemas.

Latencia y límites

Los retrasos en el procesamiento y la visualización dentro de la plataforma de Google SecOps están sujetos a los siguientes límites de arquitectura después de que Google SecOps recibe los datos:

• Visibilidad en la búsqueda: De 2 a 15 minutos después de la transferencia.
• Ejecución de reglas: De 5 a 10 minutos después de la llegada del evento
• Visualización de la IU: Para mantener el rendimiento del navegador, los datos de registro de gran volumen están sujetos a un límite de visualización de 10,000 filas.

Nota: Estos tiempos comienzan después de que Google SecOps recibe los datos. La disponibilidad de datos de extremo a extremo también depende de los retrasos que se originan en la fuente de datos y que ocurren antes de que los datos ingresen en la canalización de SecOps de Google.

Precaución: Si un cambio no aparece de inmediato en la IU, no necesariamente indica una falla de sincronización. Si el evento ocurrió hace menos de 15 minutos en el caso de la búsqueda o hace menos de 10 minutos en el caso de las reglas, es probable que los datos aún se encuentren en la canalización de procesamiento estándar. El retraso no indica una falla del sistema.

¿Necesitas más ayuda? Obtén respuestas de miembros de la comunidad y profesionales de Google SecOps.