Descripción general de la latencia de Security Command Center

En esta página, se proporciona una descripción general del proceso de activación que se produce cuando habilitas Security Command Center. Su objetivo es responder preguntas comunes:

  • ¿Qué sucede cuando se habilita Security Command Center?
  • ¿Por qué hay un retraso antes de que comiencen los primeros análisis?
  • ¿Cuál es el entorno de ejecución esperado para el primer análisis y los análisis continuos?
  • ¿Cómo afectarán el cambio de los recursos y de la configuración al rendimiento?

Descripción general

Cuando habilitas Security Command Center por primera vez, se debe completar un proceso de activación antes de que Security Command Center pueda comenzar a analizar tus recursos. Luego, los análisis deben completarse antes de que veas un conjunto completo de resultados para tu entorno de Google Cloud.

El tiempo que tardan en completarse el proceso de activación y los análisis depende de varios factores, como la cantidad de recursos y elementos de tu entorno, y si Security Command Center se activa a nivel de la organización o del proyecto.

Con las activaciones a nivel de la organización, Security Command Center debe repetir ciertos pasos del proceso de activación para cada proyecto de la organización. Según la cantidad de proyectos de una organización, el tiempo requerido para el proceso de activación puede variar de minutos a horas. En el caso de las organizaciones con más de 100,000 proyectos, muchos recursos en cada proyecto y otros factores complicados, la habilitación y los análisis iniciales pueden tardar hasta 24 horas o más en completarse.

Con las activaciones a nivel del proyecto de Security Command Center, el proceso de activación es mucho más rápido, ya que se limita al único proyecto en el que se activa Security Command Center.

En las siguientes secciones, se analizan los factores que pueden introducir latencia en el inicio del análisis, el procesamiento de cambios en la configuración y el tiempo de ejecución de los análisis.

Topología

En la siguiente figura, se muestra una ilustración de alto nivel del proceso de integración y habilitación.

Ilustración de la integración de Security Command Center (haz clic para ampliar)
Ilustración de la integración de Security Command Center (haz clic para agrandar)
.

Latencia en la integración

Antes de que se inicien los análisis, Security Command Center descubre e indexa tus recursos.

Los servicios indexados incluyen App Engine, BigQuery, Cloud SQL, Cloud Storage, Compute Engine, Identity and Access Management, y Google Kubernetes Engine.

En el caso de las activaciones a nivel del proyecto de Security Command Center, el descubrimiento y el indexado se limitan al único proyecto en el que se activa Security Command Center.

En el caso de las activaciones a nivel de la organización, Security Command Center descubre y indexa los recursos de tu organización.

Durante este proceso de integración, se llevan a cabo dos pasos fundamentales.

Análisis de recursos

Security Command Center realiza un análisis inicial de recursos para identificar la cantidad total, la ubicación y el estado de los proyectos, las carpetas, los archivos, los clústeres, las políticas de identidad y acceso, los usuarios inscritos y otros recursos. Este proceso suele completarse en unos minutos.

Activación de la API

A medida que se descubren los recursos, Security Command Center habilita las partes de Google Cloud necesarias para Security Health Analytics, Event Threat Detection, Container Threat Detection y Web Security Scanner para operar. Algunos servicios de detección requieren que se habiliten las API específicas en proyectos protegidos para funcionar.

Cuando activas Security Command Center a nivel del proyecto, la activación de la API suele tardar menos de un minuto.

Con las activaciones a nivel de la organización, Security Command Center itera a través de todos los proyectos que seleccionas para el análisis para habilitar las APIs necesarias.

La cantidad de proyectos en una organización determina en gran medida la longitud de los procesos de integración y habilitación. Debido a que las API deben activarse para los proyectos uno por uno, la activación de la API suele ser la tarea más lenta, en especial para organizaciones con más de 100,000 proyectos.

El tiempo necesario para habilitar los servicios entre proyectos se escala de manera lineal. Esto significa que, por lo general, la habilitación de servicios y seguridad en una organización puede tardar el doble de tiempo con una empresa con 30,000 proyectos que una con 15,000.

Para una organización con 100,000 proyectos, la integración y la habilitación del nivel Premium deben completarse en menos de cinco horas. El tiempo puede variar según muchos factores, como la cantidad de proyectos o contenedores que usas y la cantidad de servicios de Security Command Center que eliges habilitar.

Latencia de análisis

Cuando configuras Security Command Center, debes decidir qué servicios integrados habilitar, y seleccionar los recursos de Google Cloud que deseas analizar en busca de amenazas y vulnerabilidades. A medida que se activan las API para los proyectos, los servicios seleccionados comienzan sus análisis. La duración de estos análisis también depende de la cantidad de proyectos en una organización.

Los resultados de los servicios integrados están disponibles a medida que se completan los análisis iniciales. Los servicios experimentan la latencia como se describe a continuación.

  • Container Threat Detection tiene las siguientes latencias:
    • Latencia de activación de hasta 3.5 horas para organizaciones o proyectos recientemente integrados
    • Latencia de activación de minutos para clústeres nuevos.
    • Latencia de detección de minutos para las amenazas en los clústeres que se activaron
  • La activación de Event Threat Detection se produce en segundos para los detectores integrados. En el caso de los detectores personalizados nuevos o actualizados, los cambios pueden tardar hasta 15 minutos en aplicarse. En la práctica, suele tardar menos de 5 minutos.

    En el caso de los detectores integrados y personalizados, las latencias de detección suelen ser inferiores a 15 minutos desde el momento en que se escribe un registro hasta que un resultado está disponible en Security Command Center.

  • Security Health Analytics de seguridad comienza cerca de una hora después de que se habilita el servicio. Los primeros análisis de Security Health Analytics pueden tardar hasta 12 horas en completarse. Después de eso, la mayoría de las detecciones se ejecutan en tiempo real en relación con los cambios de configuración de los recursos (las excepciones se detallan en Latencia de detección de Security Health Analytics).

  • VM Threat Detection tiene una latencia de activación de hasta 48 horas para las organizaciones recién integradas. En el caso de los proyectos, la latencia de activación es de hasta 15 minutos.

  • La Evaluación de vulnerabilidades para Amazon Web Services (AWS) comienza a analizar los recursos en una cuenta de AWS aproximadamente 15 minutos después de que se implementa la plantilla de CloudFormation requerida por primera vez en la cuenta. Cuando se detecta una vulnerabilidad de software en la cuenta de AWS, el hallazgo correspondiente estará disponible en Security Command Center aproximadamente 10 minutos después.

    El tiempo que tarda en completarse un análisis depende de la cantidad de instancias de EC2. Por lo general, un análisis de una sola instancia de EC2 tarda menos de 5 minutos.

  • Los análisis de Web Security Scanner pueden tomar hasta 24 horas en iniciarse después de que se habilita el servicio y se ejecutan de manera semanal después del primer análisis.

Security Command Center ejecuta detectores de error, que detectan errores de configuración relacionados con Security Command Center y sus servicios. Estos detectores están activados de forma predeterminada y no se pueden desactivar. Las latencias de detección varían según el detector de errores. Para obtener más información, consulta Errores de Security Command Center.

Los roles de IAM de Security Command Center se pueden otorgar a nivel de organización, carpeta o proyecto. Tu capacidad para ver, editar, crear o actualizar resultados, recursos y fuentes de seguridad depende del nivel al que se te otorga acceso. Para obtener más información sobre los roles de Security Command Center, consulta Control de acceso.

Resultados preliminares

Es posible que veas algunos resultados en la consola de Google Cloud mientras se realizan los análisis iniciales, pero antes de que se complete el proceso de integración.

Los resultados preliminares son precisos y prácticos, pero no son completos. No se recomienda usar estos hallazgos para una evaluación de cumplimiento en las primeras 24 horas.

Análisis posteriores

Por lo general, los cambios realizados dentro de tu organización o proyecto, como mover recursos o, en el caso de las activaciones a nivel de la organización, agregar carpetas y proyectos nuevos, no afectarán de manera significativa el tiempo de detección de recursos ni el entorno de ejecución de los análisis. Sin embargo, algunos análisis continúan en los programas establecidos, que determinan la rapidez con la que se detectan los cambios en Security Command Center.

  • Event Threat Detection/Container y Threat Detection: Estos servicios se ejecutan en tiempo real cuando se activan y detectan de inmediato recursos nuevos o modificados, como clústeres, buckets o registros en proyectos habilitados.
  • Estadísticas del estado de la seguridad: Security Health Analytics se ejecuta en tiempo real cuando se activan y se detectan recursos nuevos o modificados en minutos, sin incluir las detecciones que se enumeran a continuación.
  • VM Threat Detection: En el caso del análisis de memoria, VM Threat Detection analiza cada instancia de VM inmediatamente después de su creación. Además, VM Threat Detection analiza cada instancia de VM cada 30 minutos.
    • Para la detección de minería de criptomonedas, VM Threat Detection genera un resultado por proceso, por VM y por día. Cada resultado solo incluye las amenazas asociadas con el proceso que identifica. Si VM Threat Detection encuentra amenazas, pero no puede asociarlas con ningún proceso, para cada VM, VM Threat Detection agrupa todas las amenazas no asociadas en un solo resultado que emite una vez por cada período de 24 horas. En el caso de las amenazas que persisten más de 24 horas, VM Threat Detection genera resultados nuevos una vez cada 24 horas.
    • Para la detección de rootkits en modo kernel, que está en versión preliminar, VM Threat Detection genera un hallazgo por categoría y por VM cada tres días.

    En el caso del análisis de disco persistente, que detecta la presencia de software malicioso conocido, VM Threat Detection analiza cada instancia de VM al menos a diario.

  • La evaluación de vulnerabilidades para AWS ejecuta análisis tres veces al día.

    El tiempo que tarda en completarse un análisis depende de la cantidad de instancias de EC2. Por lo general, un análisis de una sola instancia de EC2 tarda menos de 5 minutos.

    Cuando se detecta una vulnerabilidad de software en una cuenta de AWS, el hallazgo correspondiente estará disponible en Security Command Center aproximadamente 10 minutos después.

  • Web Security Scanner: Web Security Scanner se ejecuta cada semana, el mismo día que el análisis inicial. Debido a que se ejecuta cada semana, Web Security Scanner no detectará los cambios en tiempo real. Si mueves un recurso o modificas una aplicación, es posible que el cambio no se detecte hasta por una semana. Puedes ejecutar análisis a pedido para verificar los recursos nuevos o modificados entre los análisis programados.

Los detectores de errores de Security Command Center se ejecutan de forma periódica en modo por lotes. Las frecuencias de los análisis por lotes varían según el detector de errores. Para obtener más información, consulta Errores de Security Command Center.

Latencia de detección de las estadísticas del estado de la seguridad

Las detecciones de las estadísticas del estado de la seguridad se ejecutan de forma periódica en modo por lotes después de habilitar el servicio y cuando cambia la configuración de un recurso relacionado. Una vez que se habilitan las estadísticas de estado de seguridad, cualquier cambio de configuración de recursos relevante da como resultado resultados de configuración incorrectos actualizados. En algunos casos, las actualizaciones pueden tardar varios minutos, según el tipo de recurso y el cambio.

Algunos detectores de estadísticas del estado de la seguridad no son compatibles con el modo de análisis en tiempo real si, por ejemplo, una detección se ejecuta con información fuera de la configuración de un recurso. Estas detecciones, que se enumeran en la tabla a continuación, se ejecutan de forma periódica y, además, identifican configuraciones incorrectas en un plazo de 12 horas. Lee Vulnerabilidades y resultados para obtener más detalles sobre los detectores de estadísticas del estado de la seguridad.

Detecciones de estadísticas de estado de la seguridad que no admiten el modo de análisis en tiempo real
COMPUTE_PROJECT_WIDE_SSH_KEYS_ALLOWED
MFA_NOT_ENFORCED (antes llamado 2SV_NOT_ENFORCED)
OS_LOGIN_DISABLED
SQL_NO_ROOT_PASSWORD
SQL_WEAK_ROOT_PASSWORD

Simulaciones de rutas de ataque

Las simulaciones de rutas de ataque se ejecutan cada seis horas, aproximadamente. A medida que tu organización de Google Cloud aumenta de tamaño o complejidad, el tiempo entre intervalos puede aumentar.

Cuando activas Security Command Center por primera vez, las simulaciones de rutas de ataque usan un conjunto predeterminado de recursos de alto valor, que incluye todos los tipos de recursos compatibles en tu organización.

Cuando comiences a definir tu propio conjunto de recursos de alto valor creando una configuración de valor de recursos, es posible que veas que el tiempo entre los intervalos de simulación disminuya si la cantidad de instancias de recursos en tu conjunto de recursos de alto valor es significativamente menor que el conjunto predeterminado.

¿Qué sigue?