Combattre l’évolution de la chaîne de destruction SaaS : comment garder une longueur d’avance sur les acteurs de la menace

La chaîne de destruction moderne échappe aux entreprises car elles ne protègent pas l’infrastructure des activités modernes : SaaS.

Le SaaS continue de dominer l’adoption des logicielset représente la plus grande part des dépenses du cloud public. Mais les entreprises et les PME n’ont pas révisé leurs programmes de sécurité ni adopté d’outils de sécurité conçus pour le SaaS.

Les équipes de sécurité continuent d’insérer des piquets sur site dans les failles de sécurité SaaS

Les contrôles de sécurité matures sur lesquels les RSSI et leurs équipes comptaient à l’ère de la domination sur site ont disparu. Les pare-feu protègent désormais un périmètre restreint, la visibilité est limitée et même si les fournisseurs SaaS proposent des journaux, les équipes de sécurité ont besoin d’un middleware développé en interne pour les assimiler et les intégrer à leur SIEM.

Les fournisseurs SaaS ont des périmètres de sécurité bien définis pour leurs produits, mais leurs clients doivent gérer la conformité SaaS et la gouvernance des données, la gestion des identités et des accès (IAM) et les contrôles des applications, soit les domaines où se produisent la plupart des incidents. Bien que ce modèle de responsabilité partagée SaaS soit universel parmi les applications SaaS, aucune application SaaS n’a des paramètres de sécurité identiques.

Figure 1. Dans le contexte des problèmes de sécurité SaaS, le fournisseur d’applications est responsable de toute l’infrastructure physique, ainsi que du réseau, du système d’exploitation et de l’application. Le client est responsable de la sécurité des données et de la gestion des identités. Le modèle de responsabilité partagée SaaS exige que les clients SaaS assument la propriété des composants que les acteurs malveillants attaquent le plus souvent. Illustration gracieuseté d’AppOmni.

Les recherches d’AppOmni indiquent qu’en moyenne, une seule instance de SaaS a 256 connexions SaaS à SaaSdont beaucoup ne sont plus utilisés, mais disposent toujours d’autorisations excessives dans les applications commerciales principales telles que Salesforce, Okta et GitHub, entre autres.

Entre la multitude de paramètres de sécurité SaaS différents et les mises à jour constantes qui les modifient, les équipes de sécurité ne peuvent pas surveiller efficacement ces connexions. Le nombre de points d’entrée se multiplie de façon exponentielle lorsque les employés activent les connexions SaaS à SaaS (également appelées « tiers » ou « machine »). Les identités des machines peuvent utiliser des clés API, des secrets, des sessions, des certificats numériques, des clés d’accès au cloud et d’autres informations d’identification pour permettre aux machines de communiquer entre elles.

À mesure que la surface d’attaque a migré en dehors du périmètre du réseau, la chaîne de destruction a également migré — la manière dont les acteurs de la menace orchestrent les différentes phases de leurs attaques.

La chaîne de destruction SaaS moderne implique généralement :

1. Compromettre une identité dans l’IdP via une campagne de phishing réussie, acheter des informations d’identification volées sur le dark web, des chaînes d’informations d’identification, du credential stuffing, tirer parti de locataires SaaS mal configurés ou des méthodes similaires.
2. Réalisation d’une phase de reconnaissance post-authentification. Cette étape rappelle les attaquants qui s’introduisaient dans les réseaux d’entreprise d’autrefois. Mais aujourd’hui, ils passent au peigne fin les référentiels de documents, les référentiels de codes sources, les coffres-forts de mots de passe, Slack, Teams et autres environnements similaires pour trouver des points d’entrée d’escalade privilégiés.
3. Tirer parti de leurs découvertes pour migrer latéralement vers d’autres locataires SaaS, PaaS ou IaaS, et parfois dans l’infrastructure de l’entreprise, partout où ils peuvent trouver les données les plus précieuses pour l’organisation cible.
4. Crypter les joyaux de la couronne ou délivrer leur demande de rançon, et tenter d’échapper à la détection.

Figure 2. Les chaînes de destruction SaaS réussies impliquent généralement quatre étapes principales : l’accès initial, la reconnaissance, le mouvement latéral et la persistance, ainsi que l’exécution du ransomware et l’évasion de la sécurité. Illustration reproduite avec l’aimable autorisation d’AppOmni.

Briser une chaîne de destruction SaaS du monde réel : Scattered Spider/Starfraud

Le dernier webinaire d’information sur les menaces du leader de la sécurité SaaS AppOmni a décrit la chaîne de destruction de l’attaque réussie des groupes d’acteurs de la menace Scattered Spider/Starfraud (affiliés à ALPHV) contre une cible non divulguée en septembre 2023 :

• Un utilisateur a ouvert un e-mail de phishing contenant des liens vers une page de connexion IdP usurpée et s’est connecté sans le savoir à la fausse page IdP.
• Les groupes d’acteurs malveillants ont immédiatement appelé cet utilisateur et l’ont convaincu, grâce à l’ingénierie sociale, de fournir son jeton de mot de passe à usage unique (TOTP) temporel.
• Après avoir obtenu les informations de connexion de l’utilisateur et le jeton TOTP, les acteurs de la menace ont trompé le protocole MFA en lui faisant croire qu’ils étaient l’utilisateur légitime.
• En mode reconnaissance, les acteurs de la menace ont eu accès à une escalade privilégiée, leur permettant d’obtenir des informations d’identification dans Amazon S3, puis Azure AD et enfin Citrix VDI (infrastructure de bureau virtuel).
• Les auteurs de la menace ont ensuite déployé leur propre serveur malveillant dans l’environnement IaaS, dans lequel ils ont exécuté une attaque par escalade privilégiée Azure AD.
• Les attaquants ont chiffré toutes les données à leur portée et ont envoyé une demande de rançon.

Figure 3. La chaîne de destruction utilisée par les groupes d’acteurs malveillants Scattered Spider/Starfraud. Illustration reproduite avec l’aimable autorisation d’AppOmni.

Scattered Spider/Starfraud a probablement accompli cette série d’événements sur plusieurs jours. Lorsque le SaaS sert de point d’entrée, une attaque grave peut inclure le réseau et l’infrastructure de l’entreprise. Cette connectivité SaaS/sur site est courante dans les surfaces d’attaque des entreprises d’aujourd’hui.

L’activité d’attaque SaaS provenant d’acteurs connus et inconnus est en augmentation

La plupart des violations de SaaS ne font pas la une des journaux, mais leurs conséquences sont importantes. IBM rapporte que les violations de données en 2023 ont coûté en moyenne 4,45 millions de dollars par exemple, ce qui représente une augmentation de 15 % sur trois ans.

Les acteurs malveillants s’appuient continuellement sur les mêmes TTP et le même playbook de la kill chain Scattered Spider/Starfraud pour obtenir un accès non autorisé et analyser les locataires SaaS, y compris Salesforce et M365, où les problèmes de configuration peuvent être manipulés pour fournir un accès ultérieur.

D’autres attaquants obtiennent un accès initial grâce au détournement de session et à des déplacements impossibles. Une fois la session détournée transférée vers un autre hôte, leur mouvement latéral implique souvent des plateformes de communication telles que SharePoint, JIRA, DocuSign et Slack, ainsi que des référentiels de documents tels que Confluence. S’ils peuvent accéder à GitHub ou à d’autres référentiels de code source, les acteurs malveillants extrairont ce code source et l’analyseront pour détecter les vulnérabilités d’une application ciblée. Ils tenteront d’exploiter ces vulnérabilités pour exfiltrer les données de l’application ciblée.

Le rapport d’information sur les menaces d’AppOmni indique également que l’exfiltration de données via le partage d’autorisations reste un problème de sécurité SaaS sérieux. Cela se produit, par exemple, dans Google Workspace lorsque l’utilisateur non autorisé modifie les répertoires pour un niveau d’autorisations très ouvert. L’attaquant peut les partager avec une autre entité externe via le transfert d’e-mails ou la modification de règles conditionnelles afin que les attaquants soient inclus comme destinataires BCC dans une liste de distribution.

Comment protégez-vous vos environnements SaaS ?

1. Focus sur l’hygiène des systèmes SaaS

Établissez un processus d’admission et d’examen SaaS pour déterminer quel SaaS vous autoriserez dans votre entreprise. Ce processus doit nécessiter des réponses à des questions de sécurité telles que :

• Tous les SaaS doivent-ils être certifiés SOC 2 Type 2 ?
• Quelle est la configuration de sécurité optimale pour chaque locataire ?
• Comment votre entreprise évitera-t-elle les dérives de configuration ?
• Comment déterminerez-vous si les mises à jour automatiques du SaaS nécessiteront la modification des paramètres de contrôle de sécurité ?

Assurez-vous que vous pouvez détecter le Shadow IT SaaS (ou applications SaaS non autorisées) et disposer d’un programme de réponse afin que les alertes ne soient pas créées en vain.

Si vous ne surveillez pas vos locataires SaaS et n’ingérez pas tous leurs journaux selon une méthode unifiée, vous ne pourrez jamais détecter les comportements suspects et recevoir des alertes en conséquence.

2. Inventorier et surveiller en permanence les comptes/identités des machines

Les acteurs de la menace ciblent les identités des machines en raison de leur accès privilégié et de leurs normes d’authentification laxistes, nécessitant souvent rarement l’authentification multifacteur.

En 2023, les acteurs malveillants ont ciblé et piraté avec succès les principaux outils CI/CD Travis CI, CircleCI et Heroku, volant les jetons OAuth de tous les clients de ces fournisseurs. Le rayon d’action s’étend considérablement dans ces situations.

Dans une entreprise moyenne, les identités des machines sont de 256, ce qui laisse souvent à désirer. La plupart d’entre elles sont utilisées une ou deux fois, puis restent inutilisées pendant des années.

Inventoriez toutes les identités de vos machines et triez ces risques critiques. Une fois que vous avez atténué ces problèmes, créez des politiques qui prescrivent :

• À quels types de comptes seront attribuées des identités de machine et quelles sont les exigences que ces fournisseurs doivent respecter pour obtenir l’accès.
• La période pendant laquelle leur accès/jetons sont actifs avant qu’ils ne soient révoqués, actualisés ou réattribués.
• Comment vous surveillerez l’utilisation de ces comptes et vous assurerez qu’ils sont toujours nécessaires s’ils connaissent des périodes d’inactivité.

3. Construisez une véritable architecture Zero Trust dans votre parc SaaS

L’architecture Zero Trust s’appuie sur le principe du moindre privilège (PLP) avec une approche « ne jamais faire confiance, toujours vérifier ». Même si le Zero Trust a été établi dans les réseaux traditionnels, il est rarement atteint dans les environnements SaaS.

L’approche réseau centrée sur Zero Trust Network Access (ZTNA) ne peut pas détecter les erreurs de configuration, les intégrations de machines ou les droits d’accès utilisateur indésirables au sein et vers les plates-formes SaaS, qui peuvent permettre à des milliers, voire des millions d’utilisateurs externes d’accéder aux données.

Zero Trust Posture Management (ZTPM), un outil de sécurité SaaS émergent, étend Zero Trust à votre parc SaaS. Il comble le vide de sécurité SaaS créé par SASE en :

• Empêcher le contournement ZTNA non autorisé
• Permettre des décisions d’accès affinées
• Appliquer vos politiques de sécurité avec des boucles de rétroaction continues
• Extension du Zero Trust aux intégrations de machines et aux connexions cloud

Avec SSPM, ZTPM et un Programme de sécurité SaaS une fois sur place, votre équipe bénéficiera de la visibilité et des renseignements dont elle a besoin pour identifier les intrus dans les étapes à faible risque de votre chaîne de destruction — et les arrêter avant qu’une violation ne devienne dévastatrice.