Comprende la disponibilidad de datos para la búsqueda

Compatible con:

Google SecOps

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

Transfiere y procesa datos en Google SecOps

En esta sección, se describe cómo Google SecOps transfiere, 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 lleva estos datos a la plataforma con uno de sus métodos de transferencia seguros.

Los métodos de transferencia principales 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 tu organización Google Cloud, 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 con sus APIs de transferencia REST públicas. Usa este método para integraciones personalizadas o para enviar datos como registros no estructurados o eventos del Modelo de datos unificados (UDM) con formato previo.

• Agente de Bindplane

  Puedes implementar el agente versátil 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, puedes configurar feeds de datos para extraer registros de fuentes de terceros, como buckets de almacenamiento en la nube específicos de terceros (como Amazon S3) o APIs de terceros (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

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

2. Indexación

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

3. Creación de alias y enriquecimiento de UDM

   • Google SecOps realiza la creación de alias y el enriquecimiento de UDM para enriquecer los eventos de UDM con contexto valioso, mediante la identificación y la adición de datos de contexto y de indicadores para las entidades de registro. Por ejemplo, conecta el login name de un usuario con sus diversas IP addresses, hostnames y MAC addresses.
   • Geolocalización: Google SecOps enriquece las direcciones IP con datos de geolocalización.

4. Enriquecimiento de ECG

   • Google SecOps realiza la creación de alias de ECG que combina el contexto de varias fuentes (como IdPs, CMDBs y la inteligencia contra amenazas) para crear un perfil de entidad consolidado en el gráfico de contexto de la entidad.

   • Inteligencia contra amenazas: Google SecOps compara automáticamente los datos de eventos con la vasta inteligencia contra 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 datos para el análisis

Después de procesarse y enriquecerse, los datos de 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 reglas en vivo 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) y para investigar 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. Como 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 productos diferentes (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 y sin analizar que 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 original y sin procesar de los registros antes de que se analizaran y normalizaran. Esto es útil para encontrar cadenas específicas, argumentos de línea de comandos o cualquier otro artefacto que no sean campos de UDM indexados.
• Cómo funciona: Usas el prefijo raw =. Puede ser más lento que la búsqueda de UDM porque no busca campos indexados.
• Ejemplo (cadena): raw = "PsExec.exe"
• Ejemplo (expresión regular): raw = /admin\$/

Búsqueda de estadísticas

Usa la búsqueda de estadísticas para obtener tendencias a largo plazo que agreguen millones de filas de datos. Como la plataforma debe realizar análisis estadísticos y agrupaciones, espera tiempos de carga más largos para estas consultas.

Búsqueda en lenguaje natural (Gemini)

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

• Qué busca: Proporciona una interfaz conversacional para consultar datos de UDM.
• Cómo funciona: Escribes una pregunta y Gemini genera la consulta de búsqueda de UDM subyacente por ti, que luego puedes ejecutar o definir mejor.
• Ejemplo: "Show me all failed logins from user 'bob' in the last 24 hours"

Búsqueda de SOAR

La búsqueda de SOAR es específica de 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, activos, direcciones IP) dentro de la plataforma 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 a disponibilidad de búsqueda

La disponibilidad de datos de extremo a extremo es el tiempo total que transcurre entre el momento en que ocurre 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. Este retraso depende de la arquitectura, el procesamiento, el procesamiento por lotes y los programas de publicación de la API del sistema fuente. Google SecOps no puede influir en este retraso. Entre los ejemplos, se incluyen los retrasos 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 requiere Google SecOps para procesar los datos después de recibirlos. Esta duración incluye 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 resuelvas problemas de cronogramas de visibilidad de datos.

Retrasos que se originan en la fuente de datos

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

• Procesamiento por lotes: Algunos sistemas generan registros en lotes en intervalos establecidos (por ejemplo, por hora).
• Latencia de la API: La API de origen puede tener retrasos 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.
• Limitación: Los límites de frecuencia de la API del lado de la fuente pueden ralentizar la recuperación de datos.
• Relleno inicial: La publicación 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. En la referencia de la API de administración de feeds, se describen consideraciones específicas para tipos de registros como Microsoft Graph, SentinelOne, Okta y CrowdStrike.

Tiempo de procesamiento de Google SecOps

El sistema procesa los datos transferidos recientemente en varios pasos. La duración de estos pasos determina cuándo los datos transferidos recientemente estarán disponibles para la consulta y el análisis.

En la siguiente tabla, se desglosan los pasos de procesamiento de los datos transferidos recientemente por método de búsqueda. Los datos transferidos recientemente se pueden buscar después de que se completan 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 de UDM. Indexación (UDM): El registro de UDM normalizado se indexa para una búsqueda rápida y estructurada. Enriquecimiento: Se agrega contexto (inteligencia contra amenazas, geolocalización, datos de usuarios o activos).
Búsqueda de registros sin procesar	Texto de registro original y sin analizar	Transferencia: El registro llega al punto de transferencia de Google SecOps.
Motor de detección (reglas)	Eventos normalizados	Disponibilidad de eventos de UDM: Los mismos pasos que se indican para la búsqueda de UDM. Evaluación de detección: El motor de reglas evalúa los registros en "micro-lotes" y, por lo general, activa las detecciones entre 5 y 10 minutos después de la llegada del evento.
Búsqueda de SOAR	Casos y entidades	Este es un ciclo de vida diferente, ya que busca alertas y casos, no registros. El tiempo se basa en lo siguiente: Disponibilidad de eventos de UDM: Usa los mismos pasos de procesamiento que se indican para la "búsqueda de UDM". Detección: Una regla del motor de detección debe coincidir con los eventos de UDM. Generación de alertas: El sistema crea una alerta formal a partir de la detección. Creación de casos: La plataforma 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, lo que los pone a disposición para las búsquedas y el análisis adicional.

Ejemplo de pasos de procesamiento de datos

1. Recupera datos de seguridad de servicios en la nube como Amazon S3 o de la Google 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 el desarrollo, el mantenimiento y la asistencia 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 e indexados 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 Contexto de VT para ver la información de Google Threat Intelligence. Google SecOps no comparte tus datos de seguridad con Google Threat Intelligence.

Ejemplos del tiempo esperado hasta la disponibilidad de la búsqueda

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

Por ejemplo, un 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 del 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 a Servicio de reenvío de datos	Transmite registros de seguridad de 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 de UDM.	Menos de 3 minutos
Analizar y validar a Indexar	Indexa los datos de UDM analizados para realizar búsquedas rápidas.	N/A
Indexar a Datos del cliente analizados	Pone a disposición los datos indexados como datos del cliente analizados para el análisis.	Menos de 2 minutos

Soluciona problemas

En esta sección, se proporcionan instrucciones para solucionar 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 de 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: Para los períodos de búsqueda de más de 30 días, los eventos transferidos recientemente pueden tardar más en aparecer. Para obtener resultados casi en tiempo real, selecciona un período de 30 días o menos.

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 Google SecOps.

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 para la búsqueda o hace 10 minutos para las reglas, es probable que los datos aún estén 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.