Comment le modèle de responsabilité partagée a contribué à la faille de sécurité d'AT&T

par | 23 juillet 2024

Les clients de Snowflake, un service américain de stockage et d'analyse de données en nuage, ont récemment été victimes d'une crise financière. violation massive et très médiatisée de données qui, selon certains, pourrait être la plus importante de l'histoire. La violation a touché près de 170 organisations, dont "la quasi-totalité" des clients de l'opérateur de téléphonie mobile AT&T, ainsi que des clients d'autres entreprises telles que Ticketmaster et LendingTree.

Mais cette violation n'est pas seulement dévastatrice pour les clients et les entreprises concernés. C'est aussi un excellent exemple de ce qui peut se produire lorsque le modèle de responsabilité partagée du nuage s'effondre. Voyons comment.

Table des matières

Transfert sécurisé de fichiers dans le nuage

MASV est un service de transfert de fichiers sécurisé certifié ISO 27001/SOC 2 et vérifié par TPN (statut Gold Shield).

Qu'est-ce que le modèle de responsabilité partagée ?

Définissons d'abord ce dont nous parlons ici : Le modèle de responsabilité partagée, ou modèle de responsabilité de sécurité partagée, est un cadre de sécurité utilisé par de nombreux fournisseurs de clouds publics, notamment Flocon de neigeIl s'agit d'un système qui répartit les responsabilités en matière de sécurité des données entre le fournisseur et ses utilisateurs finaux.

📣Le modèle de responsabilité partagée prévoit généralement une démarcation claire des responsabilités en matière de protection des données et de gestion des vulnérabilités entre le client, d'une part, et le fournisseur, d'autre part.

La responsabilité du fournisseur combinée à la responsabilité du client. Cela semble assez simple, n'est-ce pas ?

Le problème se pose toutefois lorsque les utilisateurs supposent que leur fournisseur d'informatique dématérialisée se chargera d'une responsabilité en matière de sécurité des données qui n'incombe pas au fournisseur, ou lorsqu'ils ne tirent pas parti des outils proposés par ce dernier (comme l'application de l'authentification multifactorielle, par exemple).

Lorsque cela se produit, le modèle de responsabilité partagée en matière de sécurité s'effondre. Et les risques de violation de données augmentent considérablement.

La violation de données d'AT&T : Comment cela s'est-il produit ?

Cette violation de données semble être le résultat direct de ce type de défaillance du modèle de responsabilité partagée de l'informatique dématérialisée.

Conformément à ce modèle, et comme de nombreux services en nuage, Snowflake a traditionnellement fourni des outils et des capacités de cybersécurité, mais a permis aux utilisateurs de gérer eux-mêmes leur posture de sécurité. Par exemple, Snowflake fournissait des outils de gestion d'accès tels que le MFA, mais n'exigeait pas de ses utilisateurs qu'ils les appliquent.

Image de remplacement

SOURCE : Verdict.co.uk

A brève déclaration publié par le fournisseur de services en nuage reconnaît que la violation était une "campagne ciblée sur les utilisateurs disposant d'une authentification à facteur unique (SFA)", ajoutant que les mots de passe des comptes Snowflake disposant d'une SFA étaient soit "achetés précédemment, soit obtenus à l'aide d'un logiciel malveillant de vol d'informations".

Traduction : Un logiciel malveillant d'enregistrement de frappe (ou similaire) a recueilli les mots de passe des utilisateurs, qui ont ensuite été utilisés pour s'introduire dans des comptes Snowflake non sécurisés et (comme on pouvait s'y attendre) faire des ravages dans les données qui s'y trouvaient. Mais la triste réalité est que si les administrateurs des comptes Snowflake ayant fait l'objet d'une violation avaient appliqué le contrôle d'accès MFA à leurs utilisateurs - une exigence relativement simple - cette violation n'aurait presque certainement pas eu lieu.

(TechCrunch a récemment indiqué qu'elle avait vu des "centaines" d'informations d'identification de clients Snowflake, comme celles qui ont été utilisées dans cette attaque, toujours disponibles en ligne).

Sans surprise, depuis que la faille a été rendue publique, Snowflake a annoncé un plan d'action pour la protection de l'environnement. nouvelle politique d'authentification qui permet aux administrateurs de forcer tous les utilisateurs de Snowflake à utiliser le MFA.

Qui est responsable en cas de responsabilité partagée ?

Dans ce scénario, Snowflake est-il réellement responsable de cette violation de données ?

  • Snowflake recommande aux administrateurs de comptes d'appliquer les règles suivantes des mots de passe forts sur l'inscription.
  • Snowflake proposait en option une gestion de l'accès MFA pour sécuriser davantage les comptes de leurs utilisateurs, mais certains administrateurs de comptes ont choisi de ne pas la mettre en place.
  • Snowflake ne permettait pas aux administrateurs d'appliquer l'AMF avant la violation.

Alors que le dernier est définitivement imputable à Snowflake, les deux premiers pourraient être perçus comme une défaillance soit du fournisseur de services en nuage, soit du côté de l'utilisateur. En réalité, il s'agit probablement d'un peu des deux (le partage des responsabilités signifie également le partage des responsabilités lorsque les choses tournent mal).

L'incident a mis en évidence l'une des principales faiblesses du modèle de responsabilité partagée.

D'après nos observations, et peut-être sans surprise, le sentiment du secteur évolue lentement vers la mise en œuvre par les fournisseurs de contrôles de sécurité plus stricts afin d'éviter que les clients ne se tirent une balle dans le pied (comme dans cette situation) : Un modèle de responsabilité partagée, avec simplement un peu plus de responsabilité en matière de gestion de la vulnérabilité pour le vendeur que pour l'utilisateur.

Leçons pour les entreprises (et les utilisateurs) dans le nuage

Il est important pour nous tous d'apprendre de nos erreurs, et les services de cloud public et leurs utilisateurs ne sont pas différents.

Outre le fait que les fournisseurs permettent aux administrateurs d'appliquer des mesures de cybersécurité raisonnables telles que l'AMF, d'autres enseignements précieux en matière de protection des données peuvent être tirés de cet incident :

Appliquer le MFA/2FA et d'autres paramètres de sécurité par défaut raisonnables

Violations de données sont devenus si courants que même la plupart des utilisateurs professionnels sont conscients de l'importance du contrôle d'accès avec MFA ou authentification à deux facteurs (2FA). Les administrateurs devraient toujours l'imposer et les fournisseurs de services en nuage devraient toujours proposer cette option.

Même si l'AMF provoque quelques frictions chez les employés - j'ai récemment changé d'ordinateur et j'ai dû procéder à une centaine de vérifications de l'AMF en quelques heures lors de la mise en place - elle est capable d'arrêter de nombreuses cyberattaques dans leur élan. C'est une raison suffisante pour qu'elle ne soit pas négociable. 

Un service en nuage doit également fournir une formation et une assistance aux clients qui activent l'AMF sur des comptes anciens liés à des processus automatisés, car l'étape de l'AMF risque d'interrompre ces processus si la migration n'est pas gérée avec soin.

D'autres paramètres de sécurité par défaut, comme la configuration automatique de toutes les nouvelles ressources (telles que les baquets de stockage, les bases de données ou les machines virtuelles) pour bloquer tout accès public (au lieu d'être ouvertes au public par défaut), devraient également être mis en œuvre par les fournisseurs d'informatique en nuage.

Si ces mesures ajoutent un peu de friction pour l'utilisateur final, elles l'obligent également à s'engager sur la voie d'une plus grande sécurité, plutôt que l'inverse.

Recueillir des renseignements sur les menaces ouvertes (OSINT)

Surveiller en permanence les menaces sur le dark web et l'internet classique pour le compte des clients et réagir à tout indicateur d'une violation potentielle. Les utilisateurs négligents ont pris l'habitude d'exposer accidentellement des clés d'API sur des référentiels de code ouvert, par exemple, comme lorsque cet utilisateur a posté son Clé API Stripe sur GitHub (oups).

Les entreprises d'informatique en nuage doivent surveiller les dépôts de code source ouvert pour détecter les fuites de clés et contacter les clients concernés s'ils en découvrent. Les fournisseurs peuvent utiliser des outils automatisés tels que CrowdStrike.

Proposer des outils pour rester à l'affût des menaces potentielles

Les fournisseurs de cloud devraient également proposer des outils et une intégration avec les principales plateformes de cybersécurité afin d'évaluer les équipes DevSecOps, de rester à l'affût des menaces potentielles et de donner aux utilisateurs plus de flexibilité pour suivre les meilleures pratiques en matière de cybersécurité. Si les fournisseurs de cloud ne proposent pas de tels contrôles de sécurité, les administrateurs doivent tout de même rechercher ces outils.

  • Un exemple concret : Des services tels que Splunk ou Wiz peuvent effectuer une surveillance passive de toutes les actions au sein d'une infrastructure en nuage, en repérant automatiquement les anomalies d'utilisation qui peuvent être un signe avant-coureur d'une violation, mais qui risquent autrement de passer inaperçues.
  • Autre exemple : La rotation des clés API. Si un utilisateur souhaite changer sa clé API tous les trois mois, par exemple, le fournisseur doit lui fournir un mécanisme qui lui permette de le faire sans que cela n'entraîne de temps d'arrêt important du système. Cela signifie qu'il doit être en mesure de générer plusieurs clés d'API en même temps.

Ne pas considérer les choses comme acquises

Enfin, en particulier en tant que client, ne jamais considérer le modèle de responsabilité partagée comme acquis ou se reposer sur ses lauriers. Il est parfois facile de tomber dans la mentalité du "c'est la responsabilité de l'autre entreprise" ou de supposer que si un outil de sécurité n'est pas obligatoire, il n'est pas important.

Les fournisseurs d'informatique en nuage devraient fournir autant d'informations et de documentation que possible pour guider les utilisateurs vers une posture de sécurité responsable, tout en formant leurs propres employés aux dernières menaces de sécurité et aux meilleures pratiques.

En tant qu'utilisateur, vous devez toujours suivre les meilleures pratiques, lire la documentation et ne jamais supposer que votre fournisseur d'infrastructure en nuage va s'occuper de quelque chose tant que vous ne l'avez pas vu par écrit.

 

MASV : une approche de la sécurité par couches

En plus de s'appuyer sur la sécurité d'AWS avec un cryptage puissant TLS 1.2 et AES-256 et des contrôles d'accès stricts, MASV assure la sécurité de toutes les données stockées et transférées grâce à un système d'authentification des données de l'entreprise. approche de la sécurité en couches qui comprennent

  • Formation de sensibilisation des employés à la sécurité et des générateurs de mots de passe internes puissants.
  • Sécurité des produits y compris l'analyse régulière des codes et les alertes automatisées pour les connexions d'administrateurs.
  • Protections des clients comme l'application obligatoire de mots de passe forts et l'encouragement de l'utilisation obligatoire de l'AFM et des générateurs de mots de passe.
  • Validation par le biais d'audits de cybersécurité effectués par des tiers et de la conformité aux réglementations.

S'inscrire à MASV et commencez gratuitement dès aujourd'hui.

Infrastructure en nuage de première qualité

MASV fonctionne sur une infrastructure en nuage AWS hautement sécurisée, de sorte que vos fichiers sont toujours en sécurité.