Comment le groupe RATP a déployé son EDR sur 32 000 endpoints

Un projet EDR qui a permis d’identifier tous les actifs IT

« Nous ne voulions pas d’un EDR qui nécessite aussi l’agent EPP de l’éditeur. En outre, l’agent EDR devait pouvoir fonctionner en parallèle avec un agent EPP déjà en place. »

Un cahier des charges précis a été rédigé. Le groupe RATP étant un établissement public, un appel d’offres public a été lancé : « nous avons récolté les besoins de toutes nos entités afin de rédiger le cahier des charges. Nous avons identifié les cas d’usage et formalisé nos critères de sélection. Nous nous sommes mis d’accord sur 3 critères éliminatoires, notamment la capacité à déployer l’agent sur des systèmes obsolètes répandus dans les environnements industriels, et sur la capacité de fonctionner en parallèle aux logiciels déjà déployés. Nous ne voulions pas d’un EDR qui nécessite aussi l’agent EPP de l’éditeur. En outre, l’agent EDR devait pouvoir fonctionner en parallèle avec un agent EPP déjà en place ».

En effet, plusieurs antivirus étant déjà en production dans les entités, l’EDR devait pouvoir cohabiter avec ce parc installé. Enfin, l’EDR devait pouvoir se déployer sur tous les actifs du groupe, qu’il s’agisse de machines Windows, Linux et des Mac.

Ces critères ont permis d’éliminer plusieurs éditeurs. Les capacités techniques et opérationnelles des éditeurs restants ont été soigneusement notées. Finalement, une phase de PoC a été lancée avec les deux éditeurs les mieux notés : « les éditeurs ont mené 4 PoC chacun auprès de nos 4 DSI », précise David Diallo. Et d’ajouter qu’au « niveau central, nous avons consolidé ces résultats et établi un classement. Nous aurions pu nous retrouver avec une égalité entre les 2 éditeurs, mais nous sommes parvenus à un consensus sur l’offre SentinelOne ».

En parallèle, le volet financier a été négocié avec les éditeurs si bien qu’en fin d’évaluation, l’équipe projet avait la note technique et la note financière ; lesquelles ont permis de choisir en toute conformité avec les règles des marchés publics. Si une note était donnée quant à la souveraineté des solutions, celle-ci n’a pas suffi aux deux solutions françaises initialement considérées pour passer l’évaluation.

Pas de déploiement « Big Bang » possible

Le périmètre du projet incluait les postes de travail et les serveurs, qu’ils soient dans les datacenters du groupe, virtualisés ou dans le cloud. De même, l’EDR devait être déployé sur l’ensemble des actifs sur lesquels les DSI du groupe sont maîtres, c’est-à-dire ceux sur lesquels l’IT peut installer des logiciels. Ce qui n’est pas toujours possible sur les équipements industriels ou les systèmes embarqués.

Chaque entité a ses propres processus et ses propres outils de déploiement des logiciels, et chacune a été laissée libre de mener son déploiement : « chaque entité rapportait en central sur l’avancement de son déploiement. Une entité a fait le choix de déployer auprès de bêta-testeurs issus de tous leurs métiers, avant de déployer sur l’ensemble de son périmètre. Une autre a déployé sur une première filiale, puis une autre, etc. Nous ne sommes pas intervenus dans cette phase, par contre il y avait un reporting au niveau du comité de pilotage du projet ».

Un planning de déploiement précis avait été établi dès le départ. Et si des problèmes étaient rencontrés et qu’il fallait faire des arbitrages, le top management prenait les décisions. 

De 95 à 98 % des postes équipés

« Chacun a déployé la solution avec son propre mode de déploiement selon le planning établi au départ jusqu’en 2024. »

« La phase de déploiement a véritablement commencé en mars 2023 dans les 4 DSI du groupe », raconte le responsable Cyber Défense : « chacun a déployé la solution avec son propre mode de déploiement selon le planning établi au départ jusqu’en 2024. Nous avons priorisé le périmètre des Jeux olympiques, avec l’Île-de-France, mais aussi dans les villes où il y avait des sites olympiques et une présence RATP ».

Après cette phase de déploiement pré-JO, les entités hors de ce périmètre ont mené à bien leur déploiement. Il reste encore 2 % à 5 % des postes de travail et serveurs à déployer, mais ce seront les plus complexes à atteindre : « ces actifs sont entre les mains des entités, la gouvernance est à définir et certains ne sont pas connectés à Internet. La question qui se pose pour ces derniers postes est “quel est le bénéfice/risque”, car l’agent EDR nécessite une connexion au cloud. Soit nous connecterons ces postes de manière sécurisée, soit nous les sécuriserons via d’autres dispositifs. Nous les traiterons au cas par cas. 95 à 98 % des endpoints équipés restent un excellent résultat ».

La règle en place est que tous les nouveaux systèmes doivent disposer de l’agent EDR et dès lors qu’il n’est pas possible de l’activer, il faut disposer d’une dérogation où l’on consigne la raison pour laquelle il n’est pas possible de déployer l’EDR.

Cette non-conformité est ensuite gérée dans la durée et sera réévaluée régulièrement à l’avenir. Comme lors de tout grand projet, il y eut quelques surprises en phase de déploiement et des soucis rencontrés qui n’avaient pas été détectés lors du PoC.

Un suivi régulier avec SentinelOne a été mis en place sur les problèmes rencontrés, notamment liés à des applicatifs anciens pour lesquels des exceptions ont été mises en place avec l’aide de l’éditeur.

Certaines pratiques des administrateurs considérées comme dangereuses ont été remontées par l’EDR. Celles-ci ont été traitées comme des exceptions dans un premier temps, puis un rappel aux bonnes pratiques a permis de régler ces écarts : « certaines macros Excel ont été jugées dangereuses par SentinelOne. Cela nous a permis de les identifier et de les corriger lorsque cela s’avérait nécessaire. Nous avons traité ces petits problèmes avec l’équipe ingénierie, avec qui nous étions en contact étroit. Ce fut un échange humain qui a été décisif dans le succès du projet ».

Une gestion des alertes confiée aux MSSP de chaque entité

Le groupe RATP s’appuie sur plusieurs SOC managés. Certaines entités ont ajouté l’EDR aux dispositifs de sécurité pris en charge par leur MSSP, quand d’autres ont souhaité prendre en charge cette gestion des alertes.

« Un projet transverse est complexe et l’agilité et la souplesse sont les critères de succès. L’important est d’avoir un objectif commun et les équipes savent s’adapter pour l’atteindre sans devoir les contraindre ».

« Il s’agissait de décisions au cas par cas et les entités se sont adaptées en fonction de leur existant », explique David Diallo. « Nous n’avons pas imposé un “choix groupe”. Un projet transverse est complexe et l’agilité et la souplesse sont les critères de succès. L’important est d’avoir un objectif commun et les équipes savent s’adapter pour l’atteindre sans devoir les contraindre ».

Comme tous les acteurs impliqués dans les JO, le groupe RATP était considéré comme cible potentielle pour les attaquants. L’équipe projet a géré la phase d’apprentissage de l’EDR très en amont de l’événement, afin d’anticiper le passage du mode détection seule au mode protection : « nous avons bénéficié du retour d’expérience des entités qui ont été les plus rapides dans le déploiement de SentinelOne et sont passées en phase de détection et réponse automatique rapidement. Cela nous a permis d’aider celle qui devait déployer à une date plus proche de l’échéance ».

Le responsable révèle que l’EDR a effectivement détecté des tentatives d’attaques, mais il lui est difficile de dire si celles-ci auraient pu passer les autres dispositifs de sécurité. « En tant que dispositif supplémentaire, l’EDR nous a permis d’être plus sereins lors de l’événement. Aujourd’hui, il joue un rôle indispensable dans un dispositif de sécurité : les attaques ont évolué et passent les dispositifs de type antivirus. Déployer un EDR était une démarche indispensable et si les JO ont accéléré ce projet, nous l’aurions mené de toute manière », conclut David Diallo.