Une entreprise du secteur de la santé déjoue des milliers de cyberattaques

Merci à vous deux de vous joindre à nous. Si vous le voulez bien, prenez une minute pour vous présenter, expliquer votre rôle et  décrire les activités de votre entreprise.

Oui, je m'appelle Quynn Kars. Je suis architecte en sécurité réseau. Nous travaillons pour un organisme médical. Et moi, je m'appelle Evan Martinez. Je travaille en étroite collaboration avec Quynn en tant qu'ingénieur en sécurité réseau. Je suis donc chargé de déployer des produits comme celui-ci.

Comment votre collaboration avec Akamai a-t-elle débuté et quels produits utilisez-vous aujourd'hui au sein de votre entreprise ?

Nous sommes avant tout clients d'Akamai Guardicore Segmentation. Nous étions à la recherche d'une solution de microsegmentation ou de pare-feu est-ouest. À l'époque, nous n'avions pas encore d'idée très précise, et nous participions à un événement organisé par un fournisseur avec l'un de nos partenaires avec lequel nous travaillons en étroite collaboration. J'ai eu la chance de rencontrer un membre de l'équipe commerciale d'Akamai. Nous avons eu une conversation constructive sur ce que je pensais être les besoins de notre entreprise. J'ai également évoqué la façon dont je percevais les tendances du secteur et ce qui pourrait nous être bénéfique. Nous avons très vite repéré la solution de segmentation d'Akamai. Puis, suite à quelques démonstrations et preuves de concept, nous avons fait le bon choix et sommes devenus clients.

Avec le recul, comment estimez-vous que l'adoption de Guardicore a permis de transformer votre entreprise et quel impact cela a-t-il eu sur son fonctionnement ?

Lors de ce projet, nous avons examiné les configurations de pare-feu traditionnelles que l'on retrouve depuis des années dans tous les environnements, et nous souhaitions adopter une approche différente, nécessitant moins de ressources humaines tout en atteignant les mêmes objectifs. Guardicore nous a permis de répondre à toutes ces attentes. La solution proposée reposait sur des agents. Nous avons ainsi pu la mettre en place dès le premier jour et bénéficier d'une visibilité et d'un contrôle approfondis sur ce trafic, sans avoir à procéder à des changements d'infrastructure majeurs dans l'ensemble de notre environnement. 

Que constatez-vous concernant l'application des règles et leurs recommandations assistées par l'IA ? Comment cela s'est-il concrétisé au sein de l'organisation en termes d'amélioration organisationnelle ?

Le GPE a représenté pour nous une amélioration considérable des processus, en particulier au sein de l'équipe de sécurité réseau, en termes de rapidité avec laquelle nous pouvons faire passer le déploiement d'une application en mode d'application des règles. Cela profite non seulement aux propriétaires d'applications, qui peuvent déployer plus rapidement leur système de cloisonnement complet et fonctionnel, mais aussi à nous, du côté de l'ingénierie, car nous gagnons un temps considérable sur le déploiement proprement dit. Et puis il y a le nombre d'heures de travail nécessaires pour mettre en place un ensemble de pare-feu vraiment efficace, couvrant tous les besoins des applications de notre environnement. C'est sans aucun doute le plus grand avantage pour nous.

Quelle est votre impression jusqu'à présent sur le déploiement de Guardicore Segmentation et votre collaboration avec Akamai ?

C'est vraiment très positif. Guardicore a tout simplement répondu à toutes nos attentes. Nous voulions de la visibilité, un contrôle aisé, une granularité, et tous ces aspects ont été pris en compte dès le premier jour. Le déploiement s'est déroulé sans encombre. Nous avons très facilement pu nous familiariser avec le produit. Jusqu'à présent, il a répondu à toutes nos attentes.

Que pensez-vous du moteur de règles basé sur l'IA par rapport aux solutions de segmentation existantes avant l'adoption du programme bêta de génération de règles ? Comment cela s'est-il traduit du point de vue du déploiement, avant et après ?

De mon point de vue, et ayant travaillé en étroite collaboration avec Quynn, je me souviens de nombreuses sessions de travail d'une heure pendant lesquelles je passais mon temps à analyser les journaux de trafic des services principaux. Sans parler, bien sûr, des heures de travail que cela impliquait. Mais ce n'est pas tout : il fallait que le trafic soit là, n'est-ce pas ? L'application était censée avoir généré ce trafic. Nous travaillions donc non seulement par sessions d'une heure, mais nous en avions plusieurs réparties tout au long de la semaine pour accumuler davantage de trafic. Vous comprenez ? Avec le moteur GPE, il ne s'agit pas simplement de récupérer ces données en temps réel comme nous le faisions auparavant. Il analyse rétrospectivement les journaux ingérés au cours des 30 derniers jours. Il détecte donc des éléments que je n'aurais peut-être pas remarqués depuis la dernière fois où j'ai réinitialisé le nombre d'accès dans la règle d'alerte. Il offre donc une vision d'ensemble bien plus large que celle que j'aurais pu obtenir sans y consacrer davantage de mon temps.

D'après votre point de vue et votre rôle, dans quelle mesure le moteur de règles basées sur l'IA a-t-il allégé la charge de travail de votre équipe ? Il a pris en charge la partie découverte, n'est-ce pas ?

Au début de ce projet, les propriétaires d'applications n'avaient pas toujours une idée très précise du fonctionnement de leur application, des services avec lesquels elle communiquait, etc. Le moteur de règles nous a donc permis d'apporter à ces discussions une vue d'ensemble claire de ce que fait leur application et de ce que nous prévoyons de mettre en place en termes de règles. Nous pouvons ainsi présenter ces informations aux propriétaires d'applications et leur dire : « Au vu du trafic des 30 derniers jours, voici ce à quoi nous nous attendons en termes de blocages et d'autorisations », et ils n'ont plus qu'à valider ces mesures. Le processus est ainsi beaucoup plus simple, beaucoup plus facile et beaucoup plus fluide  pour nous, de bout en bout. C'est fantastique.

Selon vous, quelle est l'importance, pour l'entreprise, de pouvoir simuler des règles avant de passer à leur application effective, qu'il s'agisse d'éviter les faux positifs ou de se prémunir contre les pannes ? Quel impact cela a-t-il eu sur l'entreprise ? La simulation via les règles d'alerte pour chaque ensemble de règles m'a été extrêmement bénéfique pour gagner la confiance de mon comité de gestion des changements, vous voyez ?

Ainsi, chaque fois que je déploie le mode d'application, que ce soit au niveau 1, 2, 3 ou autre, je dois passer par le comité de gestion des changements et obtenir les autorisations nécessaires. La facilité avec laquelle j'ai pu gagner la confiance de ces décideurs et les rassurer a été, disons, décuplée depuis que je suis capable de procéder ainsi, par rapport à un pare-feu traditionnel sur lequel nous aurions pu essayer de mettre en place une nouvelle règle de blocage. Ce qui a été formidable pour les responsables, mais aussi pour les propriétaires d'applications eux-mêmes : je peux les rassurer en leur montrant que je ne vais pas provoquer de temps d'arrêt pendant leur jour de congé ni, vous savez, les appeler au milieu de la nuit parce que Guardicore a bloqué du trafic sans leur accord. Cela a donc eu un impact énorme sur le climat de confiance au sein de l'entreprise.

À quel point pensez-vous que ce soit important, vous voyez, avec l'adoption de l'IA dans, disons, l'écosystème des outils et de la protection de l'IA elle-même ? À quel point estimez-vous qu'il est important de disposer d'une IA explicable, s'appuyant sur davantage de données probantes qui montrent ce que nous observons, afin de faire respecter cette règle ? Cela permet non seulement de rassurer l'ensemble de l'entreprise, mais aussi de conserver un intervenant humain dans la boucle : nous pouvons formuler toutes sortes de recommandations en matière de règles, nous pouvons vous fournir les preuves, mais il est essentiel que cet intervenant humain soit le point de contrôle de la mise en œuvre, afin que cela ne se fasse pas de manière entièrement automatisée. Quelle importance cela revêt-il pour vous ?

C'est intéressant, n'est-ce pas ? Parce que c'est vraiment important. Nous ne voulons pas accumuler de dette technique. Avec ces règles relatives à l'IA, n'est-ce pas ? Nous voulons que les données issues de ces systèmes soient fiables et apportent réellement de la valeur à l'entreprise. Il est donc important de disposer d'informations explicables concernant ces règles et les éléments que l'IA fournit aux ingénieurs ou à nos équipes. Et c'est un aspect qui, j'en suis sûr, va prendre beaucoup d'ampleur dans les années à venir, à mesure que l'IA se généralisera dans le secteur.

Evan, pouvez-vous nous donner un exemple de suggestion qui a contribué à améliorer la posture de sécurité de l'entreprise ? Avez-vous des exemples particuliers à partager à ce sujet ?

Oui, tout à fait. Prenons un exemple lié à GPE : imaginez que l'application 1 communique avec l'application 2 via, disons, le port 80 ou 443, peu importe. Une deuxième suggestion vient alors signaler qu'une seule adresse IP effectue exactement la même opération. Pour moi, cela constitue immédiatement un signal d'alerte indiquant que nous avons omis un agent lors du déploiement ou dans l'application d'étiquetage. Il faut alors mener une enquête pour déterminer  de quel terminal il s'agit, pour lequel Guardicore ne détecte ni étiquette ni actif géré. Je peux ensuite collaborer avec l'équipe chargée des applications pour identifier ce terminal et lui attribuer les étiquettes appropriées. De cette manière, nous disposons non seulement d'une visibilité, mais aussi d'une application des règles associées. Ainsi, aucune charge de travail non autorisée n'est exécutée dans notre environnement.

Y a-t-il des avantages mesurables que ces outils vous ont apportés, par exemple en matière de dépannage des utilisateurs finaux, de gain de temps, ou tout autre aspect auquel vous pourriez penser, suite au déploiement que vous avez
connu du côté opérationnel ?

Oui, oui, tout à fait. Du côté des opérations, je suis en quelque sorte en retrait par rapport à l'aspect sécurité réseau de ce que nous faisons ici ; on fait appel à moi lors de sessions de dépannage ou en cas d'indisponibilité, quelle qu'en soit la cause, pour des problèmes qui ne concernent même pas les applications ou les systèmes que je gère, simplement parce que j'ai une visibilité sur le déroulement des processus. Du coup, je peux voir, par exemple, si un serveur d'application a un relais SMTP configuré vers un enregistrement DNS qui existe, mais qu'il n'y a pas de serveur à cette adresse, n'est-ce pas ? Et puis les dix autres serveurs de la ferme sont tous configurés vers un autre serveur qui répond, et c'est ça la bonne configuration, n'est-ce pas ? Il m'arrive donc souvent d'être sollicité lors d'une session de dépannage pour apporter des précisions au niveau des processus et fournir ces informations supplémentaires aux propriétaires des applications afin qu'ils puissent en tenir compte.

Au vu de votre expérience, dans quelle mesure estimez-vous qu'il est important d'expliquer à vos collègues quelle est la différence dans l'approche d'Akamai en matière d'IA ?

Je pense que c'est important, n'est-ce pas ? En effet, de nombreuses entreprises intègrent l'IA à tout va dans leurs systèmes, mais la question de savoir si cela apporte réellement une valeur ajoutée à l'expérience de l'utilisateur final ou à celle des ingénieurs reste sujette à débat. Et je pense que l'approche adoptée par Akamai en la matière est l'une des meilleures. Ce qu'ils font apporte réellement de la valeur ajoutée. Le moteur GPE ne se contente pas de générer automatiquement des résultats sans intérêt. Même si cela peut paraître simple, les suggestions concrètes issues de ce moteur sont réellement utiles. Elles apportent une réelle valeur ajoutée à notre entreprise et nous permettent de gagner du temps. Et c'est ce que j'aimerais voir davantage de fournisseurs faire.

Selon vous, quel élément de la plateforme apporte le plus de valeur à votre entreprise ?

Je dirais sans hésiter que c'est le moteur GPE qui a apporté le plus de valeur ajoutée. Au-delà des besoins de segmentation que Guardicore a couverts pour notre environnement, une fois l'achat effectué et après être devenus clients, la véritable valeur ajoutée a résidé dans le déploiement des fonctionnalités du GPE. Quynn et moi-même avons tous les deux plusieurs projets en cours à tout moment. Nous participons à des réunions de dépannage pour de nouvelles initiatives. Le fait de permettre à certains de nos utilisateurs expérimentés de gagner un peu plus de temps lors de la phase de déploiement a donc constitué un avantage considérable pour nous : cela nous a permis de libérer du temps à consacrer à d'autres tâches qui ne sont peut-être pas menées de manière aussi efficace.

Ainsi, après avoir examiné différentes solutions de segmentation, comment estimez-vous que Guardicore s'est finalement démarqué, du point de vue d'un fournisseur de segmentation, à savoir en réduisant réellement le temps nécessaire au cloisonnement ?

Cette solution a-t-elle, en quelque sorte, renforcé sa valeur ajoutée, notamment en termes d'estimations du temps de déploiement à l'échelle de l'entreprise ? Comment pensez-vous qu'Akamai a réellement su s'imposer auprès de votre entreprise ? 

Selon moi, la meilleure façon de présenter les choses est de dire que le secteur avait, depuis très longtemps, une méthode bien établie pour mettre en œuvre la segmentation est-ouest. Il s'agissait d'acquérir un pare-feu traditionnel, de l'intégrer au réseau au point de présence souhaité, d'y définir vos règles de pare-feu ou de configurer des listes de contrôle d'accès (ACL) sur un commutateur. Le fait de disposer d'un agent qui permet simplement de définir une règle, de l'installer sur la machine et d'être immédiatement opérationnel a considérablement accéléré ce déploiement. Au départ, nous avions prévu d'adopter une approche traditionnelle, et cela nous aurait pris des mois pour, vous savez, gérer les temps d'arrêt, respecter les fenêtres de maintenance, etc., avant d'en arriver au stade où nous aurions même pu commencer à analyser le trafic pour prendre des décisions. Au lieu de cela, avec Guardicore, il nous a suffi d'une semaine pour installer l'agent sur toutes nos machines et mener à bien le processus de déploiement. Bien sûr, nous avons dû passer par différentes phases, comme tout le monde, mais le délai nécessaire pour obtenir cette visibilité a été considérablement réduit. À partir de là, nous pouvons commencer à déployer des règles et à prendre des décisions. Nous pouvons enfin exploiter ces données, qui sont immédiatement disponibles. Je pense donc que cela nous a été très utile et que c'est sans doute la tendance que va suivre le secteur.

Que pensez-vous du fait qu'Akamai Guardicore soit véritablement parvenu à mettre en œuvre ce modèle Zero Trust au sein de l'entreprise ? Cela vous a-t-il ouvert les yeux, d'un point de vue opérationnel, sur les possibilités offertes par Guardicore, même au-delà de la simple protection par pare-feu est-ouest ? Y a-t-il eu d'autres cas d'utilisation et une valeur ajoutée que vous avez tirée de cet outil, en plus de ce que vous recherchiez initialement ?

Oui, absolument. Nous avions bien sûr un plan de projet précisant à quoi ressemblerait le déploiement dès que nous sommes devenus clients et que nous avons découvert le potentiel du produit. Puis, comme vous le laissez entendre, cela a évolué au fil du temps, à mesure que nous acquérions de l'expérience avec le produit et que nous commencions à vraiment comprendre tout ce qu'il nous permettait de faire. Donc, sans entrer dans les détails, par exemple pour certaines applications que nous avions initialement décidé de cloisonner sans aller plus loin, nous sommes ensuite passés à une phase 2 du déploiement pour nous pencher sur les systèmes vraiment sensibles. Il s'agit peut-être de proposer une solution de remplacement pour un système qui ne reçoit plus de mises à jour de sécurité, en appliquant des règles basées sur les processus de manière beaucoup plus stricte. Vous voyez, le cloisonnement est mise en place, elle est beaucoup plus restreinte. Ainsi, au lieu d'une application dans un environnement pour votre cloisonnement, par exemple, vous descendez au niveau d'un seul cluster de serveurs que vous ne voulez vraiment pas voir communiquer avec vos postes de travail, votre serveur de messagerie ou autre.

Combien d'applications protégez-vous réellement aujourd'hui, approximativement, à ce stade de votre déploiement ?

Oui, eh bien, nous en sommes à un peu plus de 100 applications et, vous savez, ce nombre continue d'augmenter à mesure que notre entreprise se développe. Et cela a vraiment simplifié ce processus.

Combien de temps faut-il, selon vous, pour bien comprendre la gestion des incidents et est-ce que cela a permis de réduire votre MTTR ? Par exemple, dans le cadre des enquêtes menées par l'entreprise ?

Oui, absolument. Nos analystes du SOC et nos équipes de gestion des incidents, dont Evan et moi-même faisons partie, a permis d'identifier très rapidement ce qui se passe, n'est-ce pas ? Cette vision au niveau des processus nous permet de nous dire, par exemple : « OK, une alerte XDR a été déclenchée pour un processus ». Maintenant, nous ne nous contentons plus de fouiller dans ces journaux XDR pour essayer de reconstituer le puzzle, mais nous pouvons nous demander : « Quelles machines cette machine a-t-elle contactées au cours des 7 derniers jours ? ». « Qu'a-t-elle fait exactement ? » « Ce processus a-t-il généré du trafic réseau ? » Nous avons donc vraiment pu bénéficier d'un niveau de visibilité supplémentaire qu'un outil XDR ne fournit peut-être pas, ou en tout cas pas aussi bien que Guardicore.

D'un point de vue configuration, lors du déploiement d'une solution de microsegmentation avec cloisonnement, à quelle fréquence constatez-vous des erreurs de configuration ou peut-être des activités malveillantes qui, selon vous, auraient pu passer inaperçues si vous n'aviez pas disposé d'Akamai Guardicore Segmentation ?

Je dirais que presque toutes les applications que nous examinons présentent, non pas nécessairement un risque de sécurité, mais très certainement des erreurs de configuration. J'ai donc constaté très souvent les deux cas de figure, qu'il s'agisse de quelque chose d'aussi simple que des requêtes sortantes sur le port 80 au lieu du 443, ou encore de tâches FTP au lieu de tâches SFTP exécutées à partir de systèmes critiques. Vous savez, cette visibilité nous permet de détecter très facilement ces problèmes via le GPE ou même simplement à partir des journaux eux-mêmes, jusqu'au niveau des processus. Nous disposons ainsi d'un moyen très simple d'exporter ces journaux réseau, de les transmettre au propriétaire de l'application, puis de lui attribuer une tâche de correction en précisant que nous souhaitons que le problème soit résolu d'ici un mois environ. Si ce n'est pas possible, n'hésitez pas à revenir nous voir et nous essaierons de trouver une solution. Mais cette visibilité à elle seule nous a fourni une mine d'informations qui nous a permis de remédier à ces problèmes. Je pense que nous avons fait le tour.

Merci beaucoup à vous deux pour votre temps. Nous apprécions ce partenariat et cette collaboration, et tenons également à remercier les téléspectateurs qui nous suivent depuis chez eux.