Descripción general de la latencia de Security Command Center

En esta página, se brinda una descripción general del proceso de activación se realiza 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 para que Security Command Center comience a analizar tus recursos. Luego, los escaneos debes completar antes de ver un conjunto completo de hallazgos para tu entorno de Google Cloud.

El tiempo que tardan en completarse los análisis y el proceso de activación depende de un de factores, como la cantidad de recursos y recursos en tu entorno y si Security Command Center está activado en el a nivel de la organización o a nivel de 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 en el para que se adapten a las necesidades de tu organización. Según la cantidad de proyectos en una organización, el tiempo requerido para el proceso de activación puede variar desde minutos horas. Para 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 de proyecto de Security Command Center, la activación el proceso es mucho más rápido, porque se limita a un único proyecto en el que Security Command Center se activa.

Los factores que pueden generar latencia en el inicio de análisis, procesamiento cambios en la configuración y el tiempo de ejecución de los análisis se analizan en la siguiente sección secciones.

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 comiencen 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.

Para las activaciones a nivel de proyecto de Security Command Center, el descubrimiento y la indexación de red se limita al único proyecto en el que Security Command Center esté activado.

Para las activaciones a nivel de la organización, Security Command Center descubre y indexa recursos en toda 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 de 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 en todos los proyectos que selecciones para analizar a fin de 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 incorporación y habilitación del El nivel Premium debe completarse en menos de cinco horas. Tu tiempo puede ser varían en función de muchos factores, incluida la cantidad de proyectos o contenedores que usas y la cantidad de servicios de Security Command Center que elegir 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 proyectos recién incorporados o organizaciones.
    • 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 la integración de detección de intrusiones. Para los detectores personalizados nuevos o actualizados, puede tardar hasta 15 minutos. para que se apliquen los cambios. En la práctica, por lo general, se requieren menos de 5 minutos.

    Para los detectores integrados y personalizados, la detección las latencias suelen ser de menos de 15 minutos, desde el momento en que se escribe un registro cuando un hallazgo 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 los servicios organizaciones incorporadas. Para 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 La plantilla de CloudFormation está primero implementada en la cuenta. Cuando se detecta una vulnerabilidad de software en la cuenta de AWS, el hallazgo correspondiente estará disponible Security Command Center aproximadamente 10 minutos después.

    El tiempo que se tarda en completar un análisis depende de la cantidad de EC2. individuales. Por lo general, un análisis de una única instancia EC2 toma 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 para Security Command Center se pueden otorgar a nivel de la organización, a nivel de carpeta o proyecto. Tu capacidad para ver, editar, crear o actualizar resultados, recursos, y las fuentes de seguridad dependen del nivel al que se te otorgue acceso. Para aprender para obtener más información sobre los roles de Security Command Center, consulta Control de acceso.

Resultados preliminares

Es posible que veas algunos hallazgos en la consola de Google Cloud análisis se realizan, pero antes de que se complete el proceso de incorporació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

Cambios realizados en tu organización o proyecto, como el traslado de recursos o, en el caso de las activaciones a nivel de la organización, agregar carpetas y proyectos nuevos por lo general, no afecta significativamente el tiempo de descubrimiento de los recursos o el tiempo 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: para el análisis de memoria, VM Threat Detection analiza cada instancia de VM. inmediatamente después de se crea una instancia de VM. 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 uno por proceso, por VM y por día. Cada hallazgo incluye solo las amenazas asociadas con el proceso identificado por el hallazgo. Si VM Threat Detection encuentra amenazas, pero no puede asociarla con cualquier proceso, luego, para cada VM, VM Threat Detection agrupa todas las amenazas no asociadas en un único hallazgo que emite una vez cada 24 horas. Para las amenazas que duran más de 24 horas, VM Threat Detection genera nuevos hallazgos una vez cada 24 horas.
    • Para la detección de rootkit en modo kernel, que se encuentra en versión preliminar, VM Threat Detection genera uno hallazgo por categoría, por VM, cada tres días.

    Para el 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 se tarda en completar un análisis depende de la cantidad de EC2. individuales. Por lo general, un análisis de una única instancia EC2 toma 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 semanalmente, en el en el mismo día que la analizarlo. Como se ejecuta semanalmente, Web Security Scanner no detecta 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. Como La organización de Google Cloud 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 usar un conjunto predeterminado de recursos de alto valor, que incluye todos los tipos de recursos admitidos en tu organización.

Cuando comiences a definir tu propio conjunto de recursos de alto valor creando un la configuración del valor del recurso, es posible que veas el tiempo entre si la cantidad de instancias de recursos en tu archivo es considerablemente menor que el conjunto predeterminado.

¿Qué sigue?