À mesure que les cybermenaces gagnent en complexité et en fréquence, le besoin d'une sécurité robuste des identités n'a jamais été aussi critique. Les attaques basées sur l'identité, telles que les informations d'identification compromises et l'accès non autorisé, présentent des risques importants pour les organisations. La protection contre ces menaces nécessite une approche proactive et intelligente qui détecte et répond aux activités suspectes et s'intègre de manière transparente aux mesures de sécurité existantes.
Découvrez Okta Identity Threat Protection avec Okta AI, une solution de pointe conçue pour renforcer la sécurité de l'identité de votre organisation. En combinant la puissance de l'intelligence artificielle (IA) avec une protection complète de l'identité, Okta Identity Threat Protection offre des capacités de détection et de réponse aux menaces en temps réel et continues, adaptées aux défis uniques de la cybersécurité moderne.
L'une des fonctionnalités les plus puissantes d'Okta Identity Threat Protection avec Okta AI est son intégration avec Okta Workflows. Ces workflows servent à créer de l'automatisation et à permettre à votre infrastructure de sécurité de répondre de manière dynamique et efficace aux menaces. Grâce à des actions personnalisables et basées sur des politiques, Okta Workflows peut être utilisé pour désactiver ou mettre en quarantaine les comptes compromis, appliquer l'authentification multifacteur (MFA) pour les activités à haut risque et alerter les équipes de sécurité en cas de violations potentielles, contribuant ainsi à rendre vos défenses actives et réactives.
Voyons comment Okta Identity Threat Protection avec Okta AI et Okta Workflows, notre plateforme d'automatisation low-code, peut vous aider à mieux atteindre vos objectifs de sécurité et commerciaux.
Automatisation sur mesure pour Okta Identity Threat Protection
Voici une vue simplifiée d'Okta Identity Threat Protection avec Okta AI. Les signaux et les événements provenant d'Okta et de ses partenaires sont constamment transmis à Okta, et le moteur de risque Identity Threat Protection détermine les risques et exécute les politiques associées.
Ces politiques peuvent déclencher des actions correctives, telles que l'exécution d'une Déconnexion Universelle ou l'appel d'un flux délégué dans Okta Workflows. Dans cet article, nous appellerons ces flux de travail initiés par une politique.
L'évaluation des risques peut également déclencher des actions au sein d'Okta, telles que l'augmentation du niveau de risque de l'utilisateur (appelé niveau de risque de l'entité). Une modification du niveau de risque de l'utilisateur n'est qu'un des nombreux événements liés à Identity Threat Protection qui seront consignés dans les journaux système Okta, ainsi que des éléments tels que la réévaluation des politiques, les modifications du contexte de session, la réception d'un signal de risque d'un fournisseur tiers, et bien plus encore. Presque toute activité au sein d'Okta est consignée dans le journal système. Il est courant de déclencher des workflows à partir d'événements éligibles à l'aide de hooks d'événements ou du connecteur Okta intégré dans Workflows. Dans cet article, nous appellerons ces workflows déclenchés par des événements.
Workflows déclenchés par des politiques
Depuis la documentation produit: lorsque Identity Threat Protection with Okta AI découvre un risque et que l'événement de correction nécessite des actions supplémentaires au-delà de la déconnexion universelle, vous pouvez exécuter automatiquement un workflow délégué.
Les applications et services tiers fournis par le biais des connecteurs Okta Workflows offrent de nombreuses actions correctives possibles.
- Notifier les utilisateurs ou les administrateurs via Slack ou par e-mail
- Désactiver un utilisateur
- Supprimer un utilisateur d'un groupe privilégié
- Déplacer un utilisateur vers un nouveau groupe restreint
- Mettre un appareil en quarantaine
- Soumettre un ticket d'incident à une file d'attente
- Configurer différents flux pour différents scénarios de risque en fonction de vos besoins
De plus, vous pouvez utiliser les cartes Action API personnalisée incluses dans presque tous les connecteurs pour créer des actions personnalisées qui peuvent s'interfacer avec n'importe quel point de terminaison API tiers.
La documentation Okta Identity Threat Protection illustre plusieurs exemples de Workflow qui pourraient être lancés à partir de politiques spécifiques, telles que :
- Envoyer un message Slack pour signaler une violation de politique
- Effacer les sessions utilisateur et envoyer une notification par courriel pour réduire le risque
- Supprimer l'utilisateur de toutes les appartenances et désactiver son compte
Ainsi, les flux de travail initiés par des politiques sont utiles pour l'automatisation liée à des risques spécifiques générés par Identity Threat Protection, car les flux de travail sont liés à des politiques spécifiques. Si vous souhaitez automatiser des situations plus générales, telles qu'un changement de niveau de risque d'un utilisateur, les flux de travail déclenchés par des événements sont plus appropriés.
Exemples de flux de travail déclenchés par des événements
Vous trouverez ci-dessous trois exemples de déclenchement de workflows à partir d'événements dans le journal système Okta et couvrant différents cas d'utilisation.
- Une modification du niveau de risque de l'utilisateur déclenche un ticket dans ServiceNow et l'attribution à un groupe à haut risque dans Okta.
- Lorsqu'un utilisateur est affecté à une application à haut risque, un workflow vérifie le risque de l'utilisateur et autorise ou annule le nouvel accès.
- Lorsqu'un utilisateur est affecté à une application à haut risque, un flux de travail vérifie le risque de l'utilisateur et autorise ou déclenche une revue d'accès utilisateur dans Okta Identity Governance.
1. Enregistrement d'un ticket ServiceNow et affectation d'un utilisateur à un groupe à haut risque
Dans cet exemple, nous utilisons un hook d'événement abonné à user.risk.detect des événements pour déclencher un workflow. Dans ce scénario, nous informons notre équipe de sécurité de l'événement dans Slack avec des détails utiles et envoyons un e-mail au responsable de l'utilisateur dont le niveau de risque a changé.
Dans les cas où le niveau de risque d'un utilisateur est ÉLEVÉ, nous créons également un incident ServiceNow, ajoutons l'utilisateur à un groupe à haut risque dans Okta, enrichissons notre notification avec un lien vers l'incident ServiceNow et indiquons que l'utilisateur a été ajouté au groupe. Lorsque le niveau de risque de l'utilisateur diminue, il est retiré du groupe à haut risque.
Le flux de travail :
- Être déclenché par l'événement user.risk.detect événement dans le journal système Okta. Nous utiliserons un hook d'événement pointant vers un flux d'API Endpoint. (Voir Traitement des hooks d'événement Okta avec Workflows pour plus d'informations.)
- Analyser les détails de l'événement
- Lire l’utilisateur par ID pour renvoyer des informations de son profil et générer un lien vers une requête de journal système liée à l’événement
- Déterminer le niveau de risque de l'utilisateur :
- Si c'est maintenant "ÉLEVÉ"
- Créer un incident ServiceNow
- Ajouter l'utilisateur à un groupe Okta à haut risque.
- Envoyer un e-mail au responsable de l'utilisateur
- Enrichir les notifications de chat avec le contexte des actions ci-dessus
- S'il a diminué de « ÉLEVÉ » :
- Supprimer l’utilisateur du groupe Okta à haut risque
- Enrichir les notifications de chat avec le contexte des actions ci-dessus
- Si c'est maintenant "ÉLEVÉ"
- Envoyer des notifications sur tous les événements user.risk.detect événements :
- Message Slack (ou Teams) à un canal de sécurité pour tous les user.risk.detect événements
- Ajouter des informations sur l'ajout/suppression de groupe et un lien vers l'incident ServiceNow le cas échéant.
Parcourons le flux. Tout d'abord, nous analysons la charge utile de l'événement user.risk.detect et nous attribuons certaines valeurs que nous utiliserons plus tard dans notre flux. Nous fermons ensuite la connexion au hook d'événement avec un code d'état 200.
Ensuite, nous allons appeler des flux d'assistance. L'un nous aidera à analyser davantage l'événement debugData.risk pour obtenir les niveaux de risque actuels et précédents. L'autre récupérera des informations de profil sur l'utilisateur dont le niveau de risque a augmenté et construira un lien vers une requête de journal système concernant l'événement.
Si le risque de l’utilisateur est maintenant « ÉLEVÉ », nous allons
- Ajouter l'utilisateur au groupe Okta à haut risque
- Envoyer un e-mail au responsable de l'utilisateur
- Créer un incident dans ServiceNow
- Personnalisez notre notification Slack envoyée à chaque modification du niveau de risque pour informer notre équipe que l'utilisateur a été ajouté au groupe et inclure un lien vers l'incident ServiceNow. Le message indiquera également si l'action « Créer un incident » de ServiceNow échoue.
Enfin, nous prendrons les messages construits dynamiquement, indiquant
- L’utilisateur a été ajouté ou supprimé du groupe Okta à haut risque
- Incident et lien ServiceNow (ou lien pour enquêter si la création de l'incident a échoué)
Nous combinerons ces éléments avec le reste des détails de l'événement de risque que nous envoyons par défaut avec chaque événement user.risk.detect événement, et envoyer notre notification.
La mise en œuvre d’un flux comme celui-ci exploite la puissance de Workflows et d’Okta Identity Threat Protection pour donner à votre équipe une visibilité continue en temps réel sur les signaux de risque détectés dans votre tenant Okta. Il vous permet d’intégrer différentes plateformes que vous utilisez pour envoyer des notifications, créer des tickets et automatiser les réponses, comme mettre en quarantaine l’utilisateur dans un groupe à haut risque ou déclencher un incident avec un contrat de niveau de service (SLA) pour la réponse dans une autre plateforme. Le groupe Okta « High Risk » pourrait être soumis à des politiques strictes qui limitent l’accès d’un utilisateur jusqu’à ce que votre équipe ait eu l’occasion d’enquêter. L’ajout d’utilisateurs au groupe pourrait déclencher d’autres flux, ou vous pourriez même avoir des politiques plus strictes au sein d’Identity Threat Protection qui s’appliquent au groupe.
2. Vérification du risque utilisateur lors de l’attribution d’une application à haut risque
Dans cet exemple, nous avons une application à haut risque dans Okta (telle que le produit PAM, Okta Advanced Server Access), et lorsqu'un utilisateur est affecté à cette application, nous voulons vérifier son niveau de risque. Si l'utilisateur a un niveau de risque faible, l'accès à l'application est autorisé. L'accès est autorisé si le risque est moyen, mais un message Slack est envoyé pour le signaler. Si le risque est élevé, l'accès à l'application est annulé.
Le flux de travail :
- Être déclenché par l'événement application.user_membership.add dans le journal système Okta. Il s'agit d'un événement standard intégré au connecteur Okta Workflows
- Recherchez l'utilisateur par ID pour obtenir des détails au cas où un message Slack serait nécessaire
- Déterminer le risque utilisateur. Dans ce cas, il effectue une recherche dans les groupes de l'utilisateur pour voir s'il appartient à un groupe à risque élevé ou moyen, puis
- Si le risque utilisateur est faible, il autorise l’accès à l’application (c’est-à-dire qu’il ne fait rien)
- Si le risque utilisateur est moyen, il autorise l'accès à l'application, mais formate et envoie un message Slack à l'équipe d'administration
- Si le risque utilisateur est élevé, cela supprime l'attribution de l'utilisateur à l'application.
Parcourons le flux. Tout d'abord, nous avons un événement pour indiquer qu'un utilisateur, John Smith, a été ajouté à l'application Okta Advanced Server Access.
Il recherche les détails de John et les groupes auxquels il appartient afin de déterminer son risque.
Si John présente un risque moyen et se trouve donc dans le groupe de risque Moyen correspondant (attribué par Workflows lorsque son risque est passé de faible à moyen suite à un événement Identity Threat Protection), un message sera écrit sur Slack.
Si John présente un risque élevé et se trouve dans le groupe à haut risque correspondant, son affectation sera annulée en utilisant une autre action Okta.
Cela peut être vu dans les événements du journal système Okta pour l'application (ou l'utilisateur).
Il s'agit d'un exemple assez simple (et très puissant) d'utilisation du risque utilisateur pour gérer le risque applicatif.
3. Vérification du risque utilisateur lors de l'attribution d'une application à haut risque avec l'examen de l'accès utilisateur
Ensuite, nous allons étendre le scénario précédent. Plutôt que de révoquer automatiquement l'accès lorsqu'un utilisateur à haut risque accède à une application à haut risque, nous allons maintenant soulever un examen d'accès utilisateur dans Okta Identity Governance.
Le flux est fondamentalement le même qu'avant, mais au lieu de supprimer l'accès à l'application à la dernière étape, le flux de travail créera et lancera une revue d'accès utilisateur (certification d'accès) à l'aide de l'API Campaigns dans Okta Identity Governance et de la carte d'action Custom API sur le connecteur Okta (les détails sont enfouis dans un flux d'assistance).
Comme précédemment, lorsque l'utilisateur est affecté à l'application, le niveau de risque de l'utilisateur (élevé) achemine le workflow vers un flux d'assistance qui construit l'URL relative et le corps de la requête nécessaires pour créer et lancer la campagne Access Certification.
Il est affecté au responsable de l'utilisateur pour examen, et lorsque le responsable se connecte à Okta, il constate qu'il existe une campagne à examiner.
Lors de la vérification des détails, ils voient toutes les applications attribuées à John Smith.
Ils examinent l'accès, décident que John n'a pas besoin de l'application Okta Advanced Server Access, et cliquent sur le bouton Révoquer.
Cela entraîne la suppression de l'application, comme le montrent les événements du journal système.
Cette approche offre plus de flexibilité. Les utilisateurs peuvent avoir une raison légitime d'accéder à une application à haut risque. Par conséquent, faire examiner l'accès utilisateur par leur responsable est un moyen convivial pour l'audit de le gérer (bien sûr, vous pouvez appliquer les flux de demande d'accès, mais c'est une conversation pour un autre article).
Garder une longueur d'avance sur le paysage des menaces
En tirant parti de ces capacités Okta, vous pouvez atteindre une sécurité et une efficacité opérationnelle accrues, en alignant vos protocoles de sécurité sur vos objectifs commerciaux. Qu'il s'agisse d'appliquer l'authentification multifacteur (MFA) pour les activités suspectes, de désactiver ou de mettre en quarantaine les comptes compromis, ou d'informer les équipes de sécurité des violations potentielles, Okta Identity Threat Protection et Workflows permettent à votre organisation de rester résiliente face aux attaques basées sur l'identité.
Alors que nous naviguons dans les complexités de la cybersécurité moderne, Okta Identity Threat Protection avec Okta AI se distingue comme un outil essentiel dans votre arsenal de sécurité. Il protège mieux votre organisation et améliore votre capacité à réagir rapidement et efficacement aux menaces. En intégrant ces services, vous ne vous contentez pas de suivre l'évolution du paysage des menaces, vous la devancez.
Adoptez l'avenir de la sécurité de l'identité avec Okta et permettez à votre organisation de relever les défis d'aujourd'hui et de demain. Avec Okta Identity Threat Protection et Okta Workflows, vous pouvez mieux sécuriser votre paysage numérique, aider à protéger vos précieux actifs et poursuivre en toute confiance vos objectifs commerciaux.
En savoir plus sur Okta Identity Threat Protection with Okta AI et Okta Workflows.
Le contenu de ce document revêt un caractère purement informatif et ne constitue pas des conseils juridiques, commerciaux ou en matière de confidentialité, sécurité ou conformité.
