El SOC puede ver los puntos finales, el tráfico de red y la postura de la nube en tiempo real, pero históricamente, la seguridad de la identidad ha sido un punto ciego. Silverfort La integración con Google Security Operations ayuda a cambiar eso.
Los usuarios de Operaciones de Seguridad de Google pueden obtener datos en tiempo real. Silverfort identificar el riesgo en sus manuales de procedimientos, impulsar las actualizaciones de riesgo de vuelta a Silverfort desde cualquier detección externa y operar Silverfort Políticas de autenticación y cuentas de servicio directamente desde un caso de respuesta. Esto incluye la aplicación de las mismas. protocolos heredados como NTLM, Kerberos y LDAP, que pueden ser difíciles de proteger sin reescribir las aplicaciones o realizar cambios en la implementación.
La integración abarca tres Silverfort Las API (Riesgo, Cuentas de servicio, Políticas) se distribuyen a través del catálogo de integraciones de socios de Google Cloud para Google Security Operations.
Por qué la identidad es el problema más difícil del SOC
El robo de credenciales y el abuso de identidad se sitúan a la cabeza de todos los informes de brechas creíbles como el principal vector de ataque inicial. La mayoría de los entornos empresariales siguen funcionando con miles de cuentas de servicio de la que ningún propietario individual es responsable.
El SOC suele tener una visibilidad profunda de casi todo, excepto de la capa de identidad por la que el atacante se mueve. EDR cubre el punto final. SSE cubre la red. CSPM cubre la postura en la nube. Pero la identidad llega al final y suele ser la menos estructurada. Los eventos Kerberos y NTLM sin procesar llegan al SIEM sin contexto de riesgo. El comportamiento de la cuenta de servicio se encuentra detrás de una consola separada. Cuando se activa una detección, el analista recurre a un producto de identidad para comprobar si el usuario ya es de riesgo, y luego vuelve a cambiar de política para aplicar una modificación que puede residir en otro proveedor de identidad completamente distinto.
Esta integración ayuda a eliminar ambos puntos de pivote. En vivo. Silverfort El estado de la política de autenticación, que incluye información sobre riesgos, riesgos de terceros y otros factores, está disponible dentro del flujo de trabajo de respuesta, junto con los datos con los que ya trabaja el analista.
Qué datos fluyen y cómo
Esta es una integración del lado de la respuesta. El equipo de Operaciones de Seguridad de Google inicia las llamadas; Silverfort Responde con los datos solicitados o aplica el cambio solicitado.
Lee las acciones en directo Silverfort Contexto del caso del flujo de trabajo de respuesta:
- Obtenga el riesgo de la entidad Devuelve la puntuación de riesgo actual, la gravedad y los factores de riesgo para un nombre principal de usuario o un nombre de recurso.
- Obtener cuenta de servicio y Lista de cuentas de servicio Devuelve registros de cuentas de servicio protegidos con filtrado de campos opcional.
- Obtener póliza y Políticas de lista volvemos Silverfort Políticas de autenticación para su revisión dentro del caso del flujo de trabajo de respuesta.
Las acciones de escritura aplican la aplicación de nuevo a Silverfort:
- Actualizar el riesgo de la entidad Establece un indicador de riesgo de usuario (actividad, malware, filtración de datos o personalizado) en un rango de gravedad y validez elegido, a partir del resultado de un plan de respuesta. Silverfort Posteriormente, las políticas imponen la nueva postura en cada autenticación posterior para ese usuario.
- Actualizar la política de SA Actualiza parcialmente la política de la cuenta de servicio: umbrales de riesgo, alcance del protocolo y listas de origen y destino permitidos. Esto le otorga al SOC un control directo sobre la población que históricamente ha sido la más difícil de gestionar.
- Política de actualización y Cambio de política de estado Modificar la pertenencia a una póliza o activar o desactivar una póliza durante la respuesta a un incidente.
Cada Silverfort La familia de API utiliza su propio par de credenciales, por lo que los permisos se gestionan de forma independiente para las operaciones de Riesgo, Cuentas de Servicio y Políticas. Un playbook exclusivo para riesgos puede ejecutarse con credenciales específicas para riesgos y nada más, lo que limita el alcance y mantiene un registro de auditoría limpio.
Casos de uso
Enriquezca las alertas basadas en la identidad con información en tiempo real. Silverfort asumir riesgos antes de decidir qué hacer. Se activa una detección desde el EDR o SIEM en una cuenta de usuario. El playbook llama a Obtener riesgo de entidad para ese usuario. Si Silverfort ya muestra una puntuación alta con factores de riesgo como kerberastingEn caso de movimiento lateral o comportamiento anómalo de la cuenta de servicio, el caso se prioriza automáticamente y el analista abre un incidente con la información completa de la identidad ya disponible. El contexto que antes tardaba minutos ahora está disponible en segundos.
Aumentar el riesgo del usuario en Silverfort Tras una detección externa, las políticas aplican automáticamente medidas de contención. La detonación de malware o el compromiso de un dispositivo llega a la cola SOAR. El playbook llama a Actualizar riesgo de entidad para aumentar el indicador de riesgo del usuario en Silverfort con un rango de gravedad y validez definido. Silverfort Luego, se aplican controles más estrictos a cada intento de autenticación del usuario, incluso en protocolos heredados como NTLM y Kerberos, donde la autenticación multifactor (MFA) históricamente ha sido imposible. Según la política, esto podría implicar una solicitud de MFA, una denegación en la autenticación heredada o un bloqueo total. Un paso del manual cierra el ciclo desde la detección hasta la aplicación de la política.
Bloquear una cuenta de servicio sospechosa desde dentro del caso SOAR. Un analista observa que una cuenta de servicio opera fuera de su patrón normal. El manual de procedimientos llama a Actualizar la política de SA para ajustar la lista de fuentes permitidas, reducir el alcance del protocolo o aumentar el umbral de riesgo. El cambio se aplica en Silverforty el caso registra la acción. Las cuentas de servicio suelen ser el punto ciego más grande en el SOC. Para muchos equipos, esta es la primera vez que tendrán algún tipo de control sobre ellas desde dentro de SOAR.
Cambiar las políticas de autenticación durante la respuesta activa. Cuando la contención requiere activar o desactivar una política (por ejemplo, denegar temporalmente toda la autenticación NTLM durante una intrusión activa), la función Cambiar estado de la política aplica el cambio desde dentro del playbook. No es necesario cambiar de consola. El cambio de estado de la política se registra en la línea de tiempo del caso como evidencia.
Primeros Pasos
Instale la Silverfort integración a través de su proceso estándar de implementación de contenido de Google Security Operations y configure la conexión desde la página de instancia de integración. La configuración mínima es la Silverfort Clave raíz de API, clave API externa y un par de credenciales de usuario de la aplicación para la familia de API que desea automatizar primero. Ejecute Ping para validar y, a continuación, integre las acciones en los playbooks. Un único paso de enriquecimiento de riesgos añadido a un playbook de alerta de identidad existente cambia la forma en que se clasifican los casos desde el primer día.
Los parámetros de configuración completos, los ejemplos de entrada de acciones y las funciones compatibles se encuentran en el Silverfort guía de integraciónLa página de integraciones de Google Security Operations para el conector se encuentra en https://docs.cloud.google.com/chronicle/docs/reference/partner-hosted-siem-integrationsPara preguntas o para solicitar una demostración, contáctenos en ecosistema@silverfort.com.
