Larkin Ryder, responsable de la sécurité des produits Slack : « Slack a intégré la sécurité dès ses débuts »

Célia Séramour : Quel est exactement le périmètre de votre fonction ?

Larkin Ryder : Je suis directrice principale de la sécurité des produits chez Slack où je travaille depuis plus de six ans. J'ai été embauchée à l'origine en 2016 en tant que directrice des risques et de la conformité. J’ai ensuite cumulé plusieurs fonctions, notamment responsable de la sécurité par intérim avant de prendre mon poste actuel.

CS : Comment la question de la sécurité est-elle devenue aussi prégnante chez Slack ?

LR : Avant la création de l’équipe de sécurité Cal Henderson, co-fondateur et CTO de Slack, avait créé en 2014 un programme de bug bounty. Ensuite, Slack a embauché son premier professionnel de la sécurité et j’ai probablement été la quatrième personne recrutée dans ce domaine.

Le responsable de la sécurité des produits de l’époque a lancé deux projets. Le premier a consisté à s'associer à l’équipe de développement afin de s'assurer que les développeurs prennent bien en compte le sujet et utilisent les meilleures pratiques en la matière, alignées sur le Top 10 de l'OWASP. En 2018, lorsque j’ai pris la direction du programme, j’ai eu l’opportunité de développer ce projet. Six personnes y travaillaient en étroite collaboration avec les développeurs. Nous avons élargi le rôle de l’équipe, en recrutant d’autres personnes, en nous appuyant sur davantage d’outils et en élargissant les capacités des solutions déjà utilisées et en nous concentrant davantage sur les domaines avec un risque identifié.

Le second projet a consisté à intégrer directement une équipe de développeurs au sein du pôle sécurité, ce qui est plutôt inhabituel. La plupart des organisations de sécurité n'ont pas la flexibilité nécessaire pour cela. Cette équipe a écrit les composants les plus sensibles du produit. Ainsi, tandis que les professionnels de la sécurité traitent uniquement de la sécurité, les développeurs de l’offre Slack se concentrent sur les problèmes complexes de fiabilité, d'évolutivité, de convivialité, d'accessibilité et de fonctionnalité dont nos clients ont besoin.

CS : D’un point de vue organisationnel, comment est gérée la sécurité de Slack ?

LR : L'équipe compte environ 70 personnes à l'heure actuelle, elle est divisée en trois activités. Mon équipe s’occupe de toutes les caractéristiques et fonctions de la plateforme qui fonctionnent dans un environnement sécurisé. Elle s’assure aussi de la sécurisation de l’ensemble du code Slack. Cela inclut les services web, ainsi que les applications clientes exécutées sur votre bureau ou votre appareil mobile. L’équipe des opérations de sécurité, la deuxième activité, est responsable de l'infrastructure. Elle gère le système de surveillance et d'alertes et tient un registre des événements de sécurité dans toute notre infrastructure. Ils ont également créé le réseau de chiffrement Nebula que nous utilisons aujourd’hui. C'est une solution que nous avons développée – avant Nitro d’AWS– pour connecter de manière transparente et sécurisée des ordinateurs partout dans le monde. Enfin, la troisième activité est gérée par l'équipe chargée des risques et de la conformité. C'est celle pour laquelle j'ai été initialement embauchée en 2016 afin de la faire évoluer.

CS : En quoi consiste le travail de votre équipe sur la plateforme ?

LR : J'ai toujours dit que le plus facile pour un responsable de la conformité était de s’attribuer le mérite d'un excellent programme de sécurité – dans le cas présent déjà existant. Or, dès ses débuts, Slack a intégré la sécurité dans l'environnement opérationnel à un niveau très fondamental. L’entreprise était extrêmement compétente sur la surveillance et l'alerte des événements de sécurité dans l'environnement d'exploitation. Une fois que c’est acquis et bien traité, tout le reste du programme de sécurité en découle, car vous pouvez voir très rapidement à quoi ressemble une situation normale dans votre environnement. Toute anomalie devient alors un événement qui peut faire l'objet d'une alerte et vous pouvez empêcher l’accès à votre environnement.

Nous menons aussi des évaluations avec des fournisseurs externes. Cela nous a permis d’obtenir différentes certifications, telles que SOC 2, SOC 3 ou les normes ISO 27 001, 27 017 et 27 018. Mais nous devons également intégrer la sécurité dans le produit. Et c'est là qu’intervient réellement mon équipe. Elle s'assure que lorsque les développeurs construisent, ils le font d'une manière qui est conforme. Un des grands changements des deux dernières années, c’est que nous avons commencé à travailler avec les agences gouvernementales américaines, pour qu’elles utilisent Slack, notamment en nous adaptant à certaines des normes de sécurité les plus élevées de l’Etat. La plupart des entreprises comme Slack, fournisseurs de solutions SaaS, doivent se conformer à FedRAMP (Federal Risk and Authorization Management Program) afin de travailler avec ce type d’organisation. Pour ce faire, elles fournissent un environnement séparé et extrêmement sécurisé où elles isolent ces agences, avec un verrouillage renforcé. Les autres clients sont quant à eux dans un environnement plus agile et plus convivial, mais moins protégé. Nous avons cependant décidé d'améliorer cet environnement afin que tous nos clients travaillent dans Slack avec le même niveau de sécurité que les agences gouvernementales.

CS : Aujourd'hui, nous parlons beaucoup de cybersécurité. Quel genre de menaces rencontrez-vous ?

LR : La principale menace que nous observons est celle motivée par des raisons financières. Des personnes cherchent à avoir accès à des données sur des individus pour les faire chanter ou déployer des ransomwares. Certains veulent accéder à la puissance de calcul pour le minage de bitcoins, pour l'utilisation de services pour l'ingénierie sociale afin de lancer des attaques ciblant le personnel directement responsable des transactions financières dans une entreprise, afin de leur faire transférer un million de dollars sur des comptes en Suisse, par exemple.

CS : Le secteur de la santé a particulièrement été touché ces derniers temps, notamment par manque de protection. Est-ce une priorité pour vous ?

LR : Oui. L'un des premiers projets sur lesquels j'ai travaillé quand j'ai rejoint l'équipe de risque et de conformité, concernait la conformité HIPAA, qui protège les informations de santé aux États-Unis. La protection des données de santé est une de nos priorités avec la capacité des professionnels de santé à se concentrer sur les soins sans s'inquiéter de la sécurité des données. Et dans ce secteur qui traite des données très sensibles, nous portons une attention particulière aux ransomwares. En ce sens, le cloud est une véritable valeur ajoutée.

CS : Pouvez-vous revenir sur l’incident du mois de décembre 2022 qui a affecté des référentiels GitHub ?

LR : Il n'y a pas eu de compromission, juste une perte d'intégrité de notre environnement d'exploitation. C’est un fournisseur tiers avec lequel nous travaillons qui a été compromis alors qu’il tentait d'accéder aux données de GitHub afin de nous fournir son service. Nous continuons de travailler avec lui pour nous assurer qu'il a retrouvé l'intégrité de son service. Nous menons une analyse complète de tout événement de ce type pour comprendre l’impact potentiel sur les données de nos clients ou sur l'intégrité future de nos systèmes. Et la conclusion de cette enquête est qu’il n'y a pas d'impact actuel ou à venir sur les données des clients.

CS : Quelles sont les demandes de vos clients en matière de sécurité ?

LR : Tellement de choses différentes ! La plupart du temps, ils veulent tout gratuitement. C'est tout à fait compréhensible et j'aimerais pouvoir leur donner satisfaction. Mais la fourniture de fonctions de sécurité, parfois délicates, comporte des aspects économiques, avec des coûts induits. L’une des premières demandes de nos clients, c'est davantage d'aide. Nous devons les accompagner dans leur travail avec les différents services d'authentification disponibles. Il est intéressant de constater le nombre de fois où les utilisateurs de la plateforme n'utilisent pas l'authentification à deux facteurs. Avec tous les services SaaS qu'ils exploitent, ils devraient s’en servir. Pour réduire le risque de prise de contrôle de compte, par exemple, nous fournissons davantage de journaux d'audit et depuis peu, l’identification de davantage d’événements « anormaux » dans ces audits. Face à ce type de menace, la meilleure réponse réside dans la surveillance permanente des événements de connexion et du comportement des sessions des utilisateurs. Il faut aussi s'assurer de la capacité à réinitialiser les sessions si un événement inhabituel surgit.

Beaucoup de questions reviennent sur la façon de collaborer en toute sécurité dans Slack, à distance et en mode asynchrone. Slack Connect répond en grande partie à ce besoin. Ainsi, ce que beaucoup de nos clients ne savent pas, c’est que nous effectuons déjà certaines vérifications : lorsque vous téléchargez un fichier dans Slack, nous le scannons pour vous. Nous analysons un demi-milliard de fichiers par jour afin de détecter les logiciels malveillants. C’est particulièrement important lorsque vous traitez avec une entreprise extérieure car vous ne maîtrisez pas l'état des équipements qui interagissent avec votre entreprise via Slack Connect. Il n'est pas acceptable que cet outil devienne un jour un vecteur de compromission.

CS : Vous avez évoqué plusieurs fois Slack Connect et ses spécificités, notamment la possibilité de communiquer avec des personnes externes. Qu’est-ce que cela implique d’un point de vue sécurité ?

LR : Nous fournissons beaucoup de fonctions de sécurité supplémentaires pour Slack Connect. Ainsi, un utilisateur propriétaire d’un canal, et qui le partage avec une structure externe, peut gérer en partie la façon dont les données sont échangées dans ce canal. Cela inclut la gouvernance des données, le DLP, les paramètres de rétention, l’eDiscovery, etc., activées dans l’organisation Slack. Ces paramètres s'appliquent à toutes les données partagées dans le canal Slack Connect et Slack émet des notifications sur la façon dont ces données sont utilisées. Concrètement, si vous avez ajouté un fichier à un canal Slack Connect et que ce fichier est en train d'être consulté et téléchargé, vous le téléchargerez et vous aurez également une visibilité sur les actions menées. Cela dépasse largement l'e-mail puisque vous êtes en mesure de maintenir la visibilité et le contrôle sur cette information. Vous pouvez en révoquer l'accès, limiter l'accès pour l'équipe à distance ou supprimer le fichier, de façon à vous assurer que cette équipe n'a que des autorisations d'affichage. Vous pouvez aussi personnaliser les autorisations de téléchargement dans votre organisation pour ce canal.

CS : Comment Slack s’intègre-t-il dans le paysage de solutions de Salesforce ? Quelles sont les couches de sécurité supplémentaires nécessaires ?

LR : On en est encore aux premiers jours et on cherche à savoir comment intégrer Slack avec les différents produits de Salesforce. Nous n’en sommes pas à notre première intégration avec d'autres produits. Une grande partie du travail de mon équipe consiste à s'assurer que l'API fonctionne en toute sécurité, qu'elle dispose des fonctions nécessaires à la sécurité des personnes qui utilisent ces intégrations. Il s’agit ensuite de s’assurer que ces fonctions répondent aux attentes des clients. Nous avons un modèle de sécurité existant pour fonctionner avec Slack où nous demandons à nos fournisseurs d'applications de fournir des tokens très spécifiques afin qu'ils puissent contrôler les fonctionnalités dont ils ont besoin. Lors de l'événement World Tour de Salesforce à New York en décembre 2022, nous avons annoncé des fonctions d’intégration entre Slack et Sales Cloud.

C’est l’un des exemples les plus récents. De façon plus générale, notre API très évolutive met vraiment toutes les fonctionnalités du produit à la disposition des clients. Dans ce cadre, mon équipe s'assure que toutes les applications dans ce catalogue sont sûres. Nous travaillons donc avec l'équipe de gestion du catalogue d'applications pour déterminer des critères de sécurité à passer en revue pour chaque application soumise, puis nous réalisons des tests réels de pénétration des applications à fort risque. Celles qui pourraient potentiellement lire les données d’une organisation utilisatrice et conserver l’accès à celles-ci. Bien sûr, nos clients les plus soucieux de la sécurité effectueront leurs propres tests de notre plateforme et nous nous en félicitons. Il est très difficile d’être toujours confiant en tant que responsable de la sécurité. C'est notre travail d'être sceptique.