Cuándo se pueden esperar los resultados en Security Command Center

En esta página se ofrece una descripción general del proceso de activación que se lleva a cabo cuando habilitas Security Command Center. Su objetivo es responder a preguntas frecuentes:

  • ¿Qué ocurre cuando se habilita Security Command Center?
  • ¿Por qué hay un retraso antes de que empiecen los primeros análisis?
  • ¿Cuál es el tiempo de ejecución previsto para los primeros análisis y los análisis continuos?
  • ¿Cómo afectará al rendimiento el cambio de recursos y ajustes?

Información general

Cuando habilitas Security Command Center por primera vez, debe completarse un proceso de activación para que pueda empezar a analizar tus recursos. Los análisis deben completarse para que puedas ver un conjunto completo de resultados de tu entornoGoogle Cloud .

El tiempo que tardan en completarse el proceso de activación y los análisis depende de varios factores, como el número de recursos y activos de tu entorno y si Security Command Center está activado a nivel de organización o de proyecto.

Con las activaciones a nivel de organización, Security Command Center debe repetir ciertos pasos del proceso de activación en cada proyecto de la organización. En función del número de proyectos de una organización, el proceso de activación puede tardar entre unos minutos y unas horas. En el caso de las organizaciones con más de 100.000 proyectos, muchos recursos en cada proyecto y otros factores que complican el proceso, la habilitación y los análisis iniciales pueden tardar 24 horas o más en completarse.

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

En las siguientes secciones se describen los factores que pueden introducir latencia al iniciar análisis, procesar cambios en la configuración y en el tiempo de ejecución de los análisis.

Topología

En la siguiente figura se muestra una ilustración general del proceso de incorporación y habilitación.

Ilustración de la incorporación a Security Command Center (haga clic para ampliar)
Ilustración del proceso de incorporación de Security Command Center (haz clic en la imagen para ampliarla)

Latencia en la incorporación

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

Entre los servicios indexados se incluyen App Engine, BigQuery, Cloud SQL, Cloud Storage, Compute Engine, Gestión de Identidades y Accesos y Google Kubernetes Engine.

En el caso de las activaciones de Security Command Center a nivel de proyecto, la detección y la indexación se limitan al proyecto en el que se activa Security Command Center.

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

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

Análisis de recursos

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

Activación de la API

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

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

Con las activaciones a nivel de organización, Security Command Center itera en todos los proyectos que selecciones para analizarlos y habilita las APIs necesarias.

El número de proyectos de una organización determina en gran medida la duración de los procesos de incorporación y habilitación. Como las APIs deben activarse en los proyectos una a una, esta tarea suele ser la que más tiempo lleva, sobre todo en las organizaciones con más de 100.000 proyectos.

El tiempo necesario para habilitar los servicios en los proyectos se escala de forma lineal. Por lo general, se tarda el doble en habilitar los servicios y la configuración de seguridad en una organización con 30.000 proyectos que en una con 15.000.

En el caso de una organización con 100.000 proyectos, la incorporación y la habilitación del nivel Premium deberían completarse en menos de cinco horas. El tiempo puede variar en función de muchos factores, como el número de proyectos o contenedores que utilices y el número de servicios de Security Command Center que decidas habilitar.

Latencia de análisis

Cuando configuras Security Command Center, decides qué servicios integrados y predefinidos quieres habilitar y seleccionas los Google Cloud recursos que quieres que se analicen o se escaneen en busca de amenazas y vulnerabilidades. Cuando se activan las APIs en los proyectos, los servicios seleccionados empiezan a realizar análisis. La duración de estos análisis también depende del número de proyectos de una organización.

Los resultados de los servicios integrados están disponibles a medida que se completan los análisis iniciales. Los servicios experimentan latencia, tal como se describe en las siguientes secciones.

  • Container Threat Detection tiene las siguientes latencias:
    • Latencia de activación de hasta 3,5 horas en proyectos u organizaciones recién incorporados.
    • Latencia de activación de minutos para los clústeres recién creados.
    • Latencia de detección de minutos para las amenazas en los clústeres que se han activado.
  • Detección de amenazas de Cloud Run usa un proceso de observador para recoger información sobre contenedores y eventos durante toda la duración de una carga de trabajo de Cloud Run. El proceso de monitorización puede tardar hasta un minuto en iniciarse y recoger información.
  • La activación de Event Threat Detection se produce en cuestión de segundos en el caso de 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 se encuentra un resultado en Security Command Center.

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

  • Detección de amenazas en máquinas virtuales tiene una latencia de activación de hasta 48 horas para las organizaciones que se incorporan recientemente. En el caso de los proyectos, la latencia de activación es de hasta 15 minutos.

  • Vulnerability Assessment for Amazon Web Services (AWS) empieza a analizar los recursos de una cuenta de AWS aproximadamente 15 minutos después de que se implemente por primera vez en la cuenta la plantilla de CloudFormation necesaria. Cuando se detecta una vulnerabilidad de software en la cuenta de AWS, el hallazgo correspondiente está disponible en Security Command Center aproximadamente 10 minutos después.

    El tiempo que se tarda en completar un análisis depende del número de instancias de EC2. Normalmente, el análisis de una sola instancia EC2 tarda menos de 5 minutos.

  • Los análisis de Web Security Scanner pueden tardar hasta 24 horas en iniciarse después de habilitar el servicio y se ejecutan semanalmente después del primer análisis.

  • Las comprobaciones de gestión de la posición de seguridad de los datos (DSPM) (vista previa) pueden tardar hasta 24 horas en iniciarse después de habilitar el servicio.

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

Los roles de gestión de identidades y accesos de Security Command Center se pueden conceder a nivel de organización, carpeta o proyecto. La posibilidad de ver, editar, crear o actualizar hallazgos, recursos y fuentes de seguridad depende del nivel de acceso que se te haya concedido. Para obtener más información sobre los roles de Security Command Center, consulta Control de acceso.

Resultados preliminares

Es posible que vea algunos resultados en la consola Google Cloud mientras se realizan las comprobaciones iniciales, pero antes de que se complete el proceso de incorporación.

Los resultados preliminares son precisos y útiles, pero no exhaustivos. No se recomienda usar estos resultados para realizar una evaluación del cumplimiento en las primeras 24 horas.

Análisis posteriores

Los cambios que se realicen en tu organización o proyecto, como mover recursos o, en el caso de las activaciones a nivel de organización, añadir carpetas y proyectos, no suelen influir significativamente en el tiempo de detección de recursos ni en el tiempo de ejecución de los análisis. Sin embargo, algunas comprobaciones se realizan según una programación establecida, que determina la rapidez con la que Security Command Center detecta los cambios.

  • Event Threat Detection y Container Threat Detection: estos servicios se ejecutan en tiempo real cuando están activados y detectan inmediatamente recursos nuevos o modificados, como clústeres, cubos o registros, en los proyectos habilitados.
  • Security Health Analytics: Security Health Analytics se ejecuta en tiempo real cuando está activado y detecta recursos nuevos o modificados en cuestión de minutos, excepto las detecciones que se indican a continuación.
  • VM Threat Detection: para el análisis de memoria, VM Threat Detection analiza cada instancia de VM inmediatamente después de crearla. Además, Virtual Machine Threat Detection analiza cada instancia de máquina virtual cada 30 minutos.
    • Para la detección de minería de criptomonedas, VM Threat Detection genera un resultado por proceso, por máquina virtual y por día. Cada resultado incluye solo las amenazas asociadas al proceso que se identifica en el resultado. Si Detección de amenazas en VMs encuentra amenazas, pero no puede asociarlas a ningún proceso, agrupará todas las amenazas no asociadas en un único resultado que generará una vez cada periodo de 24 horas por cada VM. En el caso de las amenazas que persistan durante más de 24 horas, Detección de amenazas de VM genera nuevos resultados cada 24 horas.
    • Para detectar rootkits en modo kernel, Detección de amenazas en VMs genera un resultado por categoría y por VM cada tres días.

    En el caso del análisis de discos persistentes, que detecta la presencia de malware conocido, Detección de amenazas en máquinas virtuales analiza cada instancia de máquina virtual al menos una vez al día.

  • Evaluación de vulnerabilidades para AWS realiza análisis tres veces al día.

    El tiempo que se tarda en completar un análisis depende del número de instancias de EC2. Normalmente, el análisis de una sola instancia EC2 tarda menos de 5 minutos.

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

  • Web Security Scanner: Web Security Scanner se ejecuta semanalmente el mismo día que el análisis inicial. Como se ejecuta semanalmente, 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 una semana después. Puedes ejecutar análisis bajo demanda para comprobar los recursos nuevos o modificados entre análisis programados.

  • DSPM (vista previa): los resultados que genera DSPM pueden tardar unas dos horas en aparecer en el explorador del mapa de datos.

Los detectores de errores de Security Command Center se ejecutan periódicamente en modo por lotes. Las frecuencias de análisis por lotes varían en función del detector de errores. Para obtener más información, consulta Errores de Security Command Center.

Latencia de detección de Security Health Analytics

Las detecciones de Security Health Analytics se ejecutan periódicamente en modo de lote después de habilitar el servicio, así como cuando cambia la configuración de un recurso relacionado. Una vez que se haya habilitado Security Health Analytics, cualquier cambio relevante en la configuración de los recursos dará lugar a resultados de errores de configuración actualizados. En algunos casos, las actualizaciones pueden tardar varios minutos, en función del tipo de recurso y del cambio.

Algunos detectores de Security Health Analytics no admiten el modo de análisis inmediato si, por ejemplo, una detección se ejecuta en información que no está incluida en la configuración de un recurso. Estas detecciones, que se indican en la tabla siguiente, se ejecutan periódicamente e identifican errores de configuración en un plazo de 12 horas. Consulta Vulnerabilidades y resultados para obtener más información sobre los detectores de Security Health Analytics.

Detecciones de Security Health Analytics 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 tuGoogle Cloud organización crece en 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 de recursos de alto valor predeterminado, que se centra en un subconjunto de los tipos de recursos admitidos que se encuentran en tu organización. Para obtener más información, consulta la lista de tipos de recursos admitidos.

Cuando empieces a definir tu propio conjunto de recursos de alto valor creando una configuración de valor de recurso, es posible que veas que el tiempo entre los intervalos de simulación se reduce si el número de instancias de recursos de tu conjunto de recursos de alto valor es significativamente inferior al conjunto predeterminado.

Siguientes pasos