A medida que las ciberamenazas crecen en complejidad y frecuencia, la necesidad de una seguridad de identidad robusta nunca ha sido más crítica. Los ataques basados en la identidad, como las credenciales comprometidas y el acceso no autorizado, plantean riesgos significativos para las organizaciones. Protegerse contra estas amenazas requiere un enfoque proactivo e inteligente que detecte y responda a actividades sospechosas y se integre perfectamente con las medidas de seguridad existentes.
Ingrese a Okta Identity Threat Protection con Okta AI, una solución de vanguardia diseñada para fortalecer la seguridad de la identidad de su organización. Al combinar el poder de la inteligencia artificial (IA) con una protección de identidad integral, Okta Identity Threat Protection ofrece capacidades de detección y respuesta a amenazas continuas y en tiempo real, diseñadas para abordar los desafíos únicos de la ciberseguridad moderna.
Una de las características más potentes de Okta Identity Threat Protection con Okta AI es su integración con Okta Workflows. Estos flujos de trabajo sirven para crear automatización y permitir que tu infraestructura de seguridad responda de forma dinámica y eficaz a las amenazas. Con acciones personalizables basadas en políticas, Okta Workflows se puede utilizar para desactivar o poner en cuarentena cuentas comprometidas, aplicar la autenticación multifactor (MFA) para actividades de alto riesgo y alertar a los equipos de seguridad sobre posibles infracciones, lo que ayuda a que tus defensas sean activas y receptivas.
Exploremos cómo Okta Identity Threat Protection con Okta AI y Okta Workflows, nuestra plataforma de automatización de bajo código, puede ayudarle a alcanzar mejor sus objetivos de seguridad y de negocio.
Automatización a medida para Okta Identity Threat Protection
A continuación, se muestra una vista simplificada de Okta Identity Threat Protection con Okta AI. Las señales y los eventos tanto de Okta como de los socios se introducen constantemente en Okta, y el motor de riesgo de Identity Threat Protection determina los riesgos y ejecuta las políticas asociadas.
Estas políticas pueden desencadenar acciones correctivas, como realizar un Cierre de Sesión Universal o llamar a un flujo delegado en Okta Workflows. En este artículo, llamaremos a estos flujos de trabajo iniciados por políticas.
La evaluación de riesgos también puede desencadenar acciones dentro de Okta, como aumentar el nivel de riesgo del usuario (denominado nivel de riesgo de la entidad). Un cambio en el nivel de riesgo de un usuario es solo uno de los muchos eventos relacionados con la Protección contra Amenazas de Identidad que se escribirán en los registros del sistema de Okta, junto con elementos como la reevaluación de las políticas, los cambios en el contexto de la sesión, la recepción de una señal de riesgo de un proveedor externo y mucho más. Casi cualquier actividad dentro de Okta se registra en el registro del sistema. Es común activar flujos de trabajo a partir de eventos elegibles mediante enlaces de eventos o el conector Okta integrado en Workflows. En este artículo, llamaremos a estos flujos de trabajo iniciados por eventos.
Flujos de trabajo iniciados por políticas
De la documentación del producto: Cuando Identity Threat Protection con Okta AI descubre un riesgo y el evento de remediación requiere acciones adicionales más allá del cierre de sesión universal, puedes ejecutar automáticamente un flujo de trabajo delegado.
Las aplicaciones y los servicios de terceros que se proporcionan a través de los conectores de Okta Workflows ofrecen numerosas acciones de corrección posibles.
- Notifique a los usuarios o administradores a través de Slack o correo electrónico
- Desactivar un usuario
- Eliminar a un usuario de un grupo con privilegios
- Mover a un usuario a un nuevo grupo restringido
- Poner en cuarentena un dispositivo
- Envíe un ticket de incidente a una cola
- Configura diferentes flujos para diferentes escenarios de riesgo según tus necesidades
Además, puede usar las tarjetas de Acción de API personalizada incluidas en casi todos los conectores para crear acciones personalizadas que puedan interactuar con cualquier punto final de API de terceros.
La documentación de Okta Identity Threat Protection ilustra varios ejemplos de Workflow que podrían iniciarse desde políticas específicas, tales como:
- Envíe un mensaje de Slack para indicar una infracción de la política
- Borre las sesiones de usuario y envíe una notificación por correo electrónico para reducir el riesgo.
- Eliminar al usuario de todas las membresías y desactivar su cuenta
Por lo tanto, los flujos de trabajo iniciados por políticas son útiles para la automatización vinculada a riesgos específicos generados por Identity Threat Protection, ya que los flujos de trabajo están vinculados a políticas específicas. Si deseas impulsar la automatización basada en situaciones más genéricas, como un cambio en el nivel de riesgo del usuario, entonces los flujos de trabajo iniciados por eventos son más apropiados.
Ejemplos de flujos de trabajo iniciados por eventos
A continuación, se muestran tres ejemplos de flujos de trabajo de activación a partir de eventos en el registro del sistema de Okta y que abarcan diferentes casos de uso.
- Un cambio en el nivel de riesgo del usuario activa un ticket en ServiceNow y la asignación a un grupo de alto riesgo en Okta.
- Cuando un usuario está asignado a una aplicación de alto riesgo, un flujo de trabajo verifica el riesgo del usuario y permite o revierte el nuevo acceso.
- Cuando se asigna un usuario a una aplicación de alto riesgo, un flujo de trabajo comprueba el riesgo del usuario y permite o desencadena una Revisión de Acceso de Usuario en Okta Identity Governance.
1. Registrar un ticket de ServiceNow y asignar un usuario a un grupo de alto riesgo
En este ejemplo, utilizamos un enlace de evento suscrito a user.risk.detect eventos para activar un flujo de trabajo. En este escenario, notificamos a nuestro equipo de seguridad sobre el evento en Slack con detalles útiles y enviamos un correo electrónico al gerente del usuario cuyo nivel de riesgo ha cambiado.
En los casos en que el nivel de riesgo de un usuario es ALTO, también creamos un incidente de ServiceNow, agregamos al usuario a un grupo de alto riesgo en Okta, enriquecemos nuestra notificación con un enlace al incidente de ServiceNow e indicamos que el usuario se ha agregado al grupo. Cuando el nivel de riesgo del usuario disminuye, se le elimina del grupo de alto riesgo.
El flujo de trabajo hará lo siguiente:
- Se activará mediante el evento user.risk.detect en el registro del sistema de Okta. Utilizaremos un enlace de evento que apunta a un flujo de API Endpoint. (Consulte Processing Okta Event Hooks with Workflows para obtener más información).
- Analizar los detalles del evento
- Leer el usuario por ID para devolver información de su perfil y generar un enlace a una consulta de registro del sistema relacionada con el evento
- Determinar el nivel de riesgo del usuario:
- Si ahora es “ALTO”
- Crear un incidente de ServiceNow
- Agregar al usuario a un grupo de Okta de alto riesgo
- Enviar un correo electrónico al gerente del usuario
- Enriquezca las notificaciones de chat con el contexto sobre las acciones anteriores
- Si ha disminuido de “ALTO”:
- Eliminar al usuario del grupo de Okta de alto riesgo
- Enriquezca las notificaciones de chat con el contexto sobre las acciones anteriores
- Si ahora es “ALTO”
- Enviar notificaciones en todos los user.risk.detect eventos:
- Mensaje de Slack (o Teams) a un canal de seguridad para todos los user.risk.detect eventos
- Agregue información sobre la adición/eliminación de grupos y enlace al incidente de ServiceNow cuando corresponda.
Repasemos el flujo. Primero, analizamos la carga útil del evento user.risk.detect. evento y asignamos algunos valores que usaremos más adelante en nuestro flujo. Luego cerramos la conexión al enlace de evento con un código de estado 200.
A continuación, llamaremos a algunos flujos auxiliares. Uno nos ayudará a analizar aún más el evento debugData.risk para obtener los niveles de riesgo actuales y anteriores. El otro recuperará información del perfil del usuario cuyo nivel de riesgo se ha elevado y creará un enlace a una consulta de registro del sistema sobre el evento.
Si el riesgo del usuario ahora es “ALTO”, nosotros
- Añadirlos al grupo de alto riesgo de Okta
- Enviar un correo electrónico al gerente del usuario
- Crea un incidente en ServiceNow
- Personalice nuestra notificación de Slack enviada con cada cambio de nivel de riesgo para informar a nuestro equipo que el usuario se agregó al grupo e incluya un enlace al incidente de ServiceNow. El mensaje también indicará si la acción “Crear incidente” de ServiceNow falla.
Finalmente, tomaremos los mensajes creados dinámicamente, indicando
- El usuario ha sido añadido o eliminado del grupo de alto riesgo de Okta
- Incidente de ServiceNow y enlace (o enlace para investigar si la creación del incidente falló)
Combinaremos esos con el resto de los detalles del evento de riesgo que enviamos de forma predeterminada con cada evento user.risk.detect evento, y enviaremos nuestra notificación.
La implementación de un flujo como este aprovecha el poder de Workflows y Okta Identity Threat Protection para brindar a su equipo visibilidad continua en tiempo real de las señales de riesgo detectadas en su inquilino de Okta. Le permite integrar diferentes plataformas que utiliza para enviar notificaciones, crear tickets y automatizar respuestas, como poner en cuarentena al usuario en un grupo de alto riesgo o activar un incidente con un SLA para la respuesta en otra plataforma. El grupo de Okta de “Alto Riesgo” podría estar sujeto a políticas estrictas que limiten el acceso de un usuario hasta que su equipo haya tenido la oportunidad de investigar. Agregar usuarios al grupo podría desencadenar otros flujos, o incluso podría tener políticas más estrictas dentro de Identity Threat Protection que se apliquen al grupo.
2. Comprobación del riesgo del usuario al asignar una aplicación de alto riesgo
En este ejemplo, tenemos una aplicación de alto riesgo en Okta (como el producto PAM, Okta Advanced Server Access), y cuando un usuario es asignado a esta aplicación, queremos verificar el nivel de riesgo del usuario. Si el usuario tiene un nivel de riesgo bajo, se permite el acceso a la aplicación. Se permite el acceso si el riesgo es Medio, pero se escribe un mensaje de Slack para resaltar esto. Si el riesgo es alto, se revierte el acceso a la aplicación.
El flujo de trabajo hará lo siguiente:
- Ser activado por el evento application.user_membership.add en el registro del sistema de Okta. Este es un evento estándar integrado en el conector Okta Workflows
- Busque al usuario por ID para obtener detalles en caso de que se requiera un mensaje de Slack
- Determinar el riesgo del usuario. En este caso, está buscando los grupos del usuario para ver si están en un grupo de riesgo alto o medio, entonces
- Si el riesgo del usuario es Bajo, permite el acceso a la aplicación (es decir, no hace nada)
- Si el riesgo del usuario es Medio, permite el acceso a la aplicación, pero formatea y envía un mensaje de Slack al equipo de administración
- Si el riesgo del usuario es alto, elimina la asignación del usuario a la aplicación.
Repasemos el flujo. Primero, tenemos un evento para indicar que un usuario, John Smith, se ha agregado a la aplicación Okta Advanced Server Access.
Busca los detalles de John y los grupos a los que pertenece para determinar su riesgo.
Si John tiene un riesgo medio y, por lo tanto, está en el grupo de riesgo Medio correspondiente (asignado por Workflows cuando su riesgo cambió a Medio desde algún evento de Identity Threat Protection), se escribirá un mensaje en Slack.
Si John tiene un alto riesgo y está en el grupo de alto riesgo correspondiente, su asignación se revertirá mediante otra acción de Okta.
Esto se puede ver en los eventos del registro del sistema de Okta para la aplicación (o el usuario).
Este es un ejemplo bastante simple, y muy poderoso, de cómo usar el riesgo del usuario para administrar el riesgo de la aplicación.
3. Verificación del riesgo del usuario en la asignación de aplicaciones de alto riesgo con la revisión del acceso del usuario
A continuación, ampliaremos el escenario anterior. En lugar de revocar automáticamente el acceso cuando a un usuario de alto riesgo se le da acceso a una aplicación de alto riesgo, ahora plantearemos una revisión de acceso de usuario en Okta Identity Governance.
El flujo es básicamente el mismo que antes, pero en lugar de eliminar el acceso a la aplicación en el último paso, el flujo de trabajo creará y lanzará una revisión de acceso de usuario (certificación de acceso) utilizando la API de campañas en Okta Identity Governance y la tarjeta de acción de API personalizada en el conector de Okta (los detalles están ocultos en un flujo auxiliar).
Como antes, cuando el usuario es asignado a la aplicación, el nivel de riesgo del usuario (Alto) enruta el flujo de trabajo a un flujo auxiliar que crea la URL relativa y el requestBody necesarios para crear y lanzar la campaña de Access Certification.
Esto se asigna al administrador del usuario para que lo revise, y cuando el administrador inicia sesión en Okta, ve que hay una campaña para revisar.
Al verificar los detalles, ven todas las aplicaciones asignadas a John Smith.
Revisan el acceso, deciden que John no necesita la aplicación Okta Advanced Server Access y hacen clic en el botón Revoke.
Esto provoca la eliminación de la aplicación, como se muestra en los eventos del registro del sistema.
Este enfoque proporciona más flexibilidad. Los usuarios podrían tener una razón legítima para acceder a una aplicación de alto riesgo, por lo que tener una revisión del acceso del usuario por parte de su gerente es una forma amigable para la auditoría de administrarlo (por supuesto, podrías aplicar flujos de Solicitud de Acceso, pero esa es una conversación para otro artículo).
Mantenerse a la vanguardia del panorama de amenazas
Al aprovechar estas capacidades de Okta, puede lograr una mayor seguridad y eficiencia operativa, alineando sus protocolos de seguridad con sus objetivos comerciales. Ya sea aplicando MFA para actividades sospechosas, desactivando o poniendo en cuarentena cuentas comprometidas, o notificando a los equipos de seguridad sobre posibles infracciones, Okta Identity Threat Protection y Workflows permiten que su organización siga siendo resiliente contra los ataques basados en la identidad.
A medida que navegamos por las complejidades de la ciberseguridad moderna, Okta Identity Threat Protection con Okta AI se destaca como una herramienta fundamental en su arsenal de seguridad. Protege mejor a su organización y mejora su capacidad de responder a las amenazas de manera rápida y eficaz. Al integrar estos servicios, no solo se mantiene al día con el panorama de amenazas en evolución, sino que se mantiene a la vanguardia.
Adopte el futuro de la seguridad de la identidad con Okta y permita que su organización gestione los desafíos de hoy y de mañana. Con Okta Identity Threat Protection y Okta Workflows, puede proteger mejor su panorama digital, ayudar a proteger sus valiosos activos y perseguir con confianza sus objetivos comerciales.
Obtén más información sobre Okta Identity Threat Protection con Okta AI y Okta Workflows.
Estos materiales tienen fines informativos generales únicamente y no pretenden ser asesoramiento legal, de privacidad, de seguridad, de cumplimiento normativo o empresarial.
