Quatre façons de sécuriser l’infrastructure et d’accroître l’agilité dans un monde hybride

Bon nombre de grandes organisations informatiques évoluent désormais dans des environnements complexes de cloud public, multicloud et de cloud hybride, où les équipes de développement logiciel emploient des techniques CI/CD (intégration continue/déploiement continu) afin de pouvoir publier rapidement du nouveau code. Depuis l’arrivée du COVID-19 cependant, la moitié des équipes a quitté leurs environnements de bureau sécurisés pour travailler chez eux, où périphériques personnels et professionnels se côtoient sur des réseaux domestiques moins sûrs.

Si ces mêmes tendances stimulent les programmes de transformation numérique, la sécurité est souvent considérée comme un frein aux efforts de modernisation IT. En 2020, les logiques du marché ont accéléré ces exigences à mesure que les organisations cherchent à créer des opérations plus agiles et résilientes pour suivre la cadence. Conséquence : les équipes de sécurité font face à des défis toujours plus grands, comme une couverture insuffisante des risques accrus sur le périmètre, une visibilité et un contrôle déficients, des processus manuels ou encore une hausse des restrictions sur les ressources.

Face à ces exigences et dans un monde hybride en rapide évolution, ces équipes doivent rapidement adapter leurs stratégies si elles veulent pouvoir protéger l’infrastructure. Cet article traite de quatre manières dont les équipes de sécurité peuvent répondre aux problèmes, par le biais de nouveaux modèles et pratiques mieux alignés sur les besoins actuels des entreprises :

1. Sécurité compatible SaaS. Assurer la sécurité grâce à une connectivité, une mise à l’échelle et des efficacités de type cloud.

2. Détection et réponse étendues (XDR). Offrir une visibilité et un contrôle étendus dans plus d’environnements

3. Service d’accès sécurisé en périphérie (SASE). Proposer un accès indépendant du site aux ressources de l’entreprise, contrôlé sur la base d’informations complètes sur le contexte de la connexion, l’activité et les données consultées

4. Sécurité des conteneurs. Fournir une plateforme bénéficiant d’améliorations rapides et d’une configuration homogène pour les micro-services

1. Sécurité compatible SaaS

De plus en plus de contrôles de sécurité peuvent être consommés comme des logiciels as-a-service (SaaS) — on parle alors de sécurité as-a-service, ou SECaaS. Contrairement aux services de sécurité exploités à distance, comme la gestion à distance du matériel de sécurité sur site, la SECaaS moderne englobe l’évolution architecturale vers des composants de gestion de la sécurité, de stockage des données, d’analyse et d’interface utilisateur opérés dans le cloud.

La plupart des fournisseurs traditionnels de solutions de sécurité proposent désormais d’accéder à leurs produits dans le cloud. Si des composants comme les scanners de vulnérabilités, les collecteurs de journaux et les agents continuent d’être déployés sur site, les fonctions de gestion centralisée, de configuration, de concentration des données, d’analyse et de reporting sont, elles, fournies depuis un environnement cloud. Les composants sur site et ceux déployés sur le cloud communiquent avec l’API du fournisseur via Internet à l’aide de protocoles sécurisés, offrant ainsi une vue unifiée des environnements hybrides. Les opérations de gestion des systèmes sont, quant à elles, proposées par le fournisseur dans le cadre du service standard. La SECaaS peut ainsi alléger la charge de travail administrative de l’équipe de sécurité. La gestion de l’information et des événements de sécurité (SIEM), la détection et la réponse aux menaces sur les terminaux (EDR) et l’analyse des vulnérabilités constituent des exemples d’une telle approche (Figure 1).

Figure 1: Les modèles SECaaS typiques sécurisent de nombreux environnements.

Les solutions SECaaS ont largement recours aux API, leur permettant ainsi d’être associés à d’autres outils comme le SOAR (orchestration, automatisation et réponse aux incidents de sécurité). Intégrés dans des infrastructures virtualisées et des plateformes cloud, les workloads peuvent être surveillées par le service de sécurité afin d’identifier les instances non protégées et d’automatiser la résolution des problèmes, et ce, en chargeant le service cloud de déployer un agent ou d’isoler les menaces jusqu’à ce qu’une mesure soit prise. Un tel niveau de sécurité permanente permet de garantir la protection dès que le workload est opérationnel.

La communication fondée sur API entre les agents et la couche de gestion SECaaS autorise la mise à niveau automatique des agents, réduisant ainsi davantage les demandes envoyées à l’équipe de sécurité. Bon nombre de solutions SECaaS intègrent — dans un seul composant déployable — un éventail de fonctionnalités de protection, réduisant d’autant plus les coûts de déploiement de plusieurs agents.

Généralement conçues pour le cloud, les conteneurs et les micro-services, ces solutions permettent aux modèles de déploiement traditionnels et plus agiles d’être protégés grâce à une solution unifiée, renforcée par des règles et des rapports communs. La consolidation des outils réduit la complexité, élargit la couverture, favorise la cohérence et simplifie le déploiement, la maintenance ainsi que l’exploitation : l’équipe de sécurité peut ainsi se focaliser sur les projets essentiels.

Malgré ses avantages potentiels, le déploiement de la SECaaS peut présenter quelques difficultés sur le plan de la maturité du produit et de sa dépendance vis-à-vis du fournisseur de services. Les solutions gérées dans le cloud peuvent offrir moins de fonctionnalités, notamment par rapport aux solutions sur site plus réputées et plus matures du même fournisseur.

En outre, le modèle SECaaS introduit une tierce partie — le fournisseur de services — qui a accès aux détails de la configuration ainsi qu’aux journaux système. Ces données, ainsi que le personnel y ayant accès, peuvent être situées hors des limites de souveraineté des données de l’organisation concernée. L’identité et les activités des administrateurs des services resteront floues pour le client, de même que la plupart des opérations et des sauvegardes quotidiennes, de la continuité des opérations, etc. Ce n’est pas tout : le portail de gestion est visible sur Internet, et les plateformes sont régulièrement utilisées dans des environnements multi-client fortement influents. Cette situation peut contrarier les stratégies traditionnelles de sécurité et de conformité, mais aussi entraver la visibilité et le contrôle direct des opérations, dans un contexte de responsabilité des opérations d’allocation des ressources et de prestations. Le fournisseur de services doit garantir la visibilité des contrôles internes, aux côtés des attestations de sécurité et des preuves de conformité vérifiée vis-à-vis des normes de l’industrie. Le client achetant la solution reste toutefois responsable de la sécurité, et doit par conséquent exécuter une diligence raisonnable lors de l’achat, mais aussi effectuer régulièrement des examens de conformité auprès du fournisseur.

2. Détection et réponse étendues

Il est largement admis qu’il est impossible d’assurer une prévention totale des incidents de sécurité : c’est pourquoi les équipes de sécurité doivent garantir une capacité de détection et d’intervention rapide. Pour cela, elles ont besoin d’outils leur permettant de collecter des informations détaillées, de les rapatrier dans une console unifiée, de renforcer l’analyse des incidents grâce à l’interrogation interactive de l’état des périphériques, puis de modifier le statut des systèmes afin de contrer les attaques. Pas encore déployés à grande échelle, les outils de détection et de réponse aux menaces sur les terminaux (EDR) constituent néanmoins une stratégie efficace et éprouvée de défense des systèmes, et sont un composant essentiel du kit d’outils servant à mener des enquêtes poussées et à apporter des réponses complexes.

Sur le plan de la visibilité, les outils EDR ne sont pas exempts de tout reproche : ainsi, l’EDR est généralement déployé uniquement sur les périphériques fournis par les entreprises aux utilisateurs finaux. Toutefois, les attaques peuvent se concentrer sur des zones plus exposées, comme les périphériques reliés à un réseau (systèmes de stockage, imprimantes et appareilsréseau), les systèmes BYOD (utilisation d’appareils personnels au bureau) et autres systèmes basés sur le cloud, sans oublier la multitude d’appareils IdO (Internet des objets) désormais connectés aux réseaux. En outre, d’autres vecteurs d’attaque (par ex. les courriels) passent inaperçus sur l’interface du système d’exploitation, là où l’EDR réside généralement. Le niveau de surveillance de ces systèmes (basé sur les journaux générés par ces derniers) n’est souvent pas aussi détaillé que ce que peut offrir l’EDR.

Ce manque de visibilité peut être résolu par l’introduction de technologies de détection et de réponse spécifiques à chaque domaine — chaque outil assurant l’enregistrement détaillé, l’interrogation et la modification du statut. La détection et la réponse aux menaces réseau, par exemple, offrent une analyse du trafic réseau et s’intègrent à des périphériques de contrôle réseau afin d’améliorer la réponse. Malheureusement, il est difficile de gérer efficacement plusieurs technologies à la fois indépendantes et spécialisées. Cette situation provoque des silos de visibilité et de contrôle, les pirates pouvant facilement se dissimuler dans les failles entre ces systèmes.

Dans l’idéal, une fonctionnalité de détection et de réponse universelle couvrant différentes zones (y compris les terminaux, le réseau et le cloud) et unifiant les informations, permettrait aux analyses de suivre les activités entre les zones et fournirait un point de contrôle unifié pour la réponse aux menaces. Cette concentration des capacités de visibilité et de contrôle offre en outre une plateforme à des fins d’analyse, d’IA et d’automatisation.

Développé par les fournisseurs de solutions de sécurité, le concept XDR (détection et réponse étendues) désigne ce type d’outil universel et intelligent de réplication des données, « X » symbolisant la couverture « étendue » ou « omniprésente ». Il n’existe pour l’instant aucune définition standard de la XDR. De même, le contenu d’une solution XDR n’est pas clairement défini, pas plus que le degré d’importance qu’une telle solution doit accorder à l’ingestion des journaux, aux renseignements sur les menaces, à l’analyse et à l’automatisation. Le concept de la XDR risque de passer aux mains des équipes marketing, qui l’appliqueront alors à tout et n’importe quoi ; toutefois, on s’accorde généralement à dire qu’un système XDR doit éliminer les silos d’information et offrir des capacités de réponse efficaces. Par comparaison, cette technologie souffre néanmoins d’une immaturité qui freine son adoption. Il est irréaliste de penser qu’une solution universelle de détection et de réponse pourra être mise en place via une seule implémentation. Toutefois, en dépit de certaines considérations pratiques pouvant empêcher la création d’une solution 100 % universelle, le renforcement des capacités de détection et de réponse reste un objectif louable.

Des complexités demeurent, notamment en ce qui concerne la mise à disposition de ressources d’analyse et d’expertise suffisantes au sein de l’organisation pour répondre aux renseignements fournis. Pour utiliser efficacement les informations, les équipes de sécurité doivent disposer de renseignements détaillés sur le comportement des systèmes ainsi que sur les techniques d’attaques potentielles. Le machine learning offre des résultats prometteurs dans ce domaine, et complète — voire remplace — de plus en plus les outils de détection d’approches basées sur les signatures. Il est également crucial de disposer d’un plan et des autorisations appropriées pour déployer les éventuelles interventions requises.

L’unification des outils de détection et de réponse tend à promouvoir le choix d’un fournisseur unique pour tous les composants : néanmoins, les organisations de sécurité font souvent face à des dilemmes cornéliens, entre les suites d’outils de pointe, le choix et la gestion des fournisseurs, ou encore l’abandon progressif des outils existants.

La XDR exige une stratégie claire sur le long terme. Les organisations doivent opter pour des technologies, des fournisseurs et des partenaires de services dans le cadre de plans durables. Elles peuvent commencer par mettre l’accent sur les éléments les plus matures de la XDR, les principaux éléments à risque élevé devant être couverts, ainsi que les emplacements où les outils actuels sont les moins efficaces. Cette méthode aboutit généralement à une concentration initiale sur les terminaux. Une fois l’EDR efficacement opérationnelle dans les limites de sa visibilité, elle doit être étendue dans la XDR.

3. Service d’accès sécurisé en périphérie

Les contrôles de sécurité traditionnels ont tendance à se focaliser sur des concepts de zones et de systèmes « fiables » et « non fiables », imposés par un périmètre strictement défini. L’octroi de l’accès se base souvent sur les utilisateurs « de confiance », tandis que l’activité (une fois l’accès réseau autorisé) est faiblement surveillée. L’adoption d’une approche diamétralement opposée en matière d’architecture de sécurité d’entreprise est une étape fondamentale dans la transformation de l’entreprise.

Cette décision doit être influencée par la « Confiance zéro », un concept reconnu dans l’industrie où la confiance est appliquée à des ressources individuelles plutôt qu’à des réseaux entiers. L’architecture SASE permet la création d’un point de présence fourni par le cloud, basé sur des services et indépendant du site, afin d’offrir un accès sécurisé aux applications distribuées, aux services, aux utilisateurs et aux périphériques. Cette architecture peut protéger les environnements (aussi bien traditionnels que numériquement transformés) pour le plus grand profit des utilisateurs, où qu’ils soient dans le monde (Figure 2).

Figure 2. L’architecture SASE permet la création d’un point de présence fourni par le cloud, basé sur les services et indépendant du site.

Le SASE abandonne le concept de points d’accès restreints sur un périmètre de réseau d’entreprise au profit d’un périmètre virtuel pour les utilisateurs professionnels et externes, assorti de décisions d’accès basées sur des règles, des identités, des périphériques et des contrôles de sécurité de type données.

Plutôt que de se baser sur le déploiement d’un tunnel réseau externe vers un réseau de confiance d’entreprise (via une combinaison de périphériques utilisateur et permettant d’accéder à toutes les ressources internes), les décisions d’accès sont basées sur les connexions individuelles, déterminées au moment de l’utilisation. Les décisions dépendent de l’identité, du profil du périphérique, de l’heure, de l’utilisateur, du contexte cible et du site (qui, où, quoi, quand et comment). Les pirates peuvent obtenir l’accès à un périphérique sur un réseau, mais auront plus de mal à se déplacer latéralement car chaque action et chaque accès seront contestés et réévalués.

Il existe plusieurs approches du SASE : certaines impliquent des agents de poste de travail, d’autres utilisent des techniques de réseau étendu définies par logiciel, et d’autres encore sont plus étroitement alignées sur les réseaux de fourniture de contenu. L’architecture SASE combine plusieurs contrôles, comme l’inspection du contenu déchiffré, le sandbox, le filtrage, la prévention du vol d’identité et la prévention de la perte de données, sans oublier l’authentification et l’autorisation sensibles au contexte. Ces contrôles sont réunis dans un seul système homogène, par le biais d’une règle uniforme et centralisée. Il est possible de combiner des journaux d’événements SASE à l’aide de capacités de détection et de réponse comportementales (par ex. la XDR) afin de permettre la surveillance de bout en bout de toutes les activités sur l’architecture — l’organisation étend ainsi ses capacités de détection et de blocage des attaques là où elles se produisent. Les architectures SASE sont généralement hébergées dans le cloud, ce qui leur permet de tirer profit de l’approche SECaaS.

Le SASE ne consiste pas à déployer un produit unique à petite échelle : il exige une stratégie bien définie, une refonte des architectures et des investissements traditionnels, le remplacement des connexions conventionnelles des fournisseurs de services Internet, mais aussi des réseaux étendus virtuels basés sur le cloud (MPLS, par ex.) avec dorsale cloud et SD-WAN. L’adoption d’un pare-feu as-a-service (FWaaS) est un autre élément typique de cette stratégie — les pare-feu matériels et de périmètre sur site ayant migré sur une dorsale cloud.

La concentration des contrôles et des règles de sécurité dans l’architecture SASE, assortie d’une intégration étroite entre les composants, peut contraindre de choisir entre capacité d’intégration et performances des composants individuels Il n’est pas toujours possible d’adopter la meilleure stratégie sur l’ensemble de l’architecture. Toutefois, compte tenu du rythme de l’adoption du SASE par les principaux fournisseurs et de l’émergence des innovateurs, les contraintes fonctionnelles individuelles devraient s’effacer rapidement au profit des bénéfices potentiels qu’offre l’architecture.

4. Sécurité des conteneurs

Parmi les tendances actuelles du développement d’applications, la segmentation des applications en un ensemble de micro-services facilite la gestion des complexités et des dépendances des applications monolithiques. Cette approche offre également un atout de sécurité appréciable, celui d’isoler les défaillances. Combinée à la technique de déploiement de l’intégration continue et au CI/CD, l’architecture permet de déployer les micro-services dans des conteneurs qui encapsulent dans une seule image la totalité du code et des dépendances.

Ces images nécessitent de fréquentes itérations de développement et de déploiement. Bien qu’ils simplifient la structure des applications, les environnements de conteneur restent complexes, avec de nombreuses couches d’abstraction (images, conteneurs, hôtes, runtime de conteneur, registres et orchestrateur) qui nécessitent des outils spécialisés d’interprétation, de surveillance et de protection.

Les déploiements immatures d’architectures de micro-services peuvent présenter les mêmes problèmes de sécurité que les applications monolithiques. Par exemple, l’incorporation de composants et de bibliothèques obsolètes et non corrigés, ou de configurations inadéquates, peut entraîner des défaillances sur de nombreux conteneurs dans l’application. Le développement et le déploiement d’applications s’effectuent en quelques jours seulement (et non plus en plusieurs mois), mais butent souvent sur des stratégies de sécurité traditionnelles : révision du code, tests de pénétration, approbations des modifications, etc.

Les équipes de sécurité doivent veiller à ce que la sécurité soit intégrée au processus CI/CD et prenne en charge les cycles de développement rapide. Cette même sécurité doit intégrer les outils de déploiement et aller plus loin que les conteneurs eux-mêmes, pour s’étendre au cycle de vie de ces derniers. Une telle approche permettra d’exploiter certaines propriétés inhérentes des conteneurs, tandis que le déploiement rapide renforcera la sécurité. Par exemple, les capacités de test et de déploiement automatisés inhérentes au CI/CD facilitent le déploiement bien plus opportun des correctifs et augmentent la confiance à l’égard des tests rigoureux de ces derniers — tout en simplifiant le processus de retrait des modifications. Les meilleures pratiques sont détaillées ci-dessous :

Sécurisation de la source. Un processus CI/CD est très exposé au déploiement de code malveillant : si le pirate peut modifier la source, celle-ci sera visible en production côté CI/CD. C’est pourquoi les composants à partir desquels les conteneurs sont construits doivent provenir de sources de confiance, et que ces composants doivent faire l’objet de contrôles d’accès et d’intégrité des plus rigoureux.
Incorporation des dernières versions. L’utilisation de composants plus anciens et vulnérables dans les images de conteneurs est l’une des principales causes de vulnérabilité de ces mêmes conteneurs. Le système doit vérifier l’existence de versions plus récentes, et les incorporer.
Analyse continue des vulnérabilités. L’incorporation d’analyses des vulnérabilités dans le pipeline CI/CD peut renforcer la confiance dans le fait que les composants les plus récents ont été intégrés et correctement configurés.
Immuabilité. Cette approche interdit toute modification aux conteneurs en cours d’exécution. Elle exige que les mises à jour soient effectuées uniquement via le processus suivi et versionné de déploiement, garantissant cohérence et reproductibilité. Cette approche signifie également que toute modification sur un conteneur en cours d’exécution est suspecte par nature.
Sécurité de l’hôte. Le recours à des systèmes d’exploitation simplifiés et spécifiques aux conteneurs, mais aussi l’utilisation et le test de benchmarks des meilleures pratiques, contribuent à réduire la surface d’attaque.
Gestion des secrets. Pour les activités d’authentification et d’autorisation, les conteneurs ont besoin de secrets tels que des clés d’API, des identifiants et des certificats. Ces informations sensibles ne doivent pas être stockées dans les sources des conteneurs, mais enregistrées dans un référentiel séparé et mises à disposition des seuls conteneurs et applications qui en ont besoin.
Surveillance et réponse. La surveillance peut être effectuée à la fois dans le conteneur et par le système d’exploitation sous-jacent. La concentration des conteneurs sur une seule tâche simple peut faciliter la surveillance des comportements. En outre, l’approche basée sur conteneurs peut faciliter les réponses en bloquant les connexions ou en mettant en pause un composant spécifique.

La gestion des conteneurs peut également présenter des difficultés. Le nombre de conteneurs pouvant exister et la vitesse à laquelle ils peuvent être créés et retirés peuvent poser problème aux systèmes tentant de les surveiller, ainsi qu’aux analystes tentant d’interpréter le comportement du système.

Si la simplification de la tâche de déploiement (en la divisant en micro-services bien définis) peut grandement améliorer la sécurité de la couche applicative, l’infrastructure requise pour appuyer cette architecture à grande échelle peut s’avérer très complexe. Les plateformes de gestion des secrets, par exemple, peuvent être difficiles à intégrer lorsqu’elles doivent satisfaire les exigences de vitesse et d’évolutivité, en présence de centaines — voire de milliers — de micro-services.

Les problèmes organisationnels doivent être résolus, à l’heure où la fonction de sécurité ne se contente plus d’être un service séparé travaillant (sur des périodes prolongées) sur des déploiements massifs et ponctuels, et s’intègre désormais de plus en plus étroitement (ou délègue de plus en plus ses activités) aux opérations de développement et de déploiement, lesquelles exigent l’automatisation des processus et des décisions rapides.

Correctement exécutée, la conteneurisation peut améliorer la sécurité, mais accroît la complexité de l’infrastructure — une situation qui nécessite une stratégie, de la prudence et des ressources.

Déploiement des contrôles de sécurité

Le passage au télétravail en 2020 a forcé les équipes de sécurité à adapter les contrôles périmétriques existants et à préparer le déploiement ou l’élargissement d’une capacité d’accès à distance, provoquant un relâchement des exigences et des contrôles. À l’heure où les travailleurs utilisent leurs appareils personnels dans des environnements domestiques partagés sur des réseaux publics, les pirates en profitent pour tenter de subtiliser les données et d’extorquer de l’argent aux organisations par le biais de ransomwares. Voici comment ces stratégies de sécurité peuvent contribuer à éliminer ces vulnérabilités :

Sécurité compatible SaaS. Ce contrôle vise à offrir un niveau égal d’accès et de sécurité, que vous travailliez dans ou hors du périmètre traditionnel de l’organisation. Il fournit en outre des décisions d’autorisation et une inspection du contenu bien plus nuancées et affinées par rapport à ce que les technologies VPN peuvent proposer.
Service d’accès sécurisé en périphérie. Ce service facilite le travail de l’équipe de sécurité (également en télétravail) en lui donnant accès à des outils de gestion de la sécurité conçus pour une utilisation en ligne. Grâce à cette approche cloud-native, les équipes de sécurité gèrent les outils à distance et prennent en charge de nombreuses modifications au niveau des systèmes et des applications.
Détection et réponse étendues. Cette approche élargit la visibilité dans tout l’environnement, depuis les terminaux jusqu’aux réseaux et aux systèmes cloud. Elle est également essentielle dans l’efficacité des captures et des réponses, sans qu’une intervention humaine soit nécessaire. Même les activités les plus basiques de détection de terminaux et de réponse ont leur rôle à jouer dans l’étude et la réponse à distance aux attaques.

Les bouleversements de 2020 ont également contribué à une demande sans précédent en matière de déploiement rapide d’applications dans la quasi-totalité des cas d’utilisation : visioconférence, services de santé, programmes d’aide gouvernementaux, services financiers, achats et livraison en ligne...

La fourniture cloud de micro-services a appuyé une grande partie de l’expansion vers le développement rapide et le CI/CD. Aussi, les conteneurs et la sécurité (dans tous ses aspects) de ces micro-services jouent un rôle extrêmement pertinent.

La SECaaS est un élément essentiel de la fourniture cloud de ces nouvelles applications.

Ce n’est pas tout : une fois adaptée et déployée, la XDR peut faciliter la sécurisation des terminaux utilisés par les développeurs et les administrateurs, tout en fournissant aux infrastructures des capacités de surveillance, d’examen et de réponse. Le SASE a un rôle à jouer dans le contrôle efficace de l’accès aux nouveaux systèmes.

Conclusion

L’évolution continue des techniques de fourniture des infrastructures appuie le changement numérique et satisfait les exigences de fourniture de systèmes agiles et flexibles, ainsi que les besoins de changement des habitudes d’utilisation. Ces tendances exigent en outre une évolution de la mise en œuvre des contrôles de sécurité. Parallèlement, les organisations s’inquiètent de la quantité d’informations qu’elles reçoivent déjà, et consacrent énormément de ressources à maintenir les systèmes existants.

Quatre technologies clés peuvent consolider la stratégie de sécurité d’une organisation afin de relever les défis, appuyer la transformation et créer une plateforme en vue des développements futurs :

Sécurité compatible SaaS pour offrir une visibilité sur l’ensemble des périmètres organisationnels conventionnels, et pour confier la maintenance des outils de gestion de la sécurité à un prestataire de services
Détection et réponse étendues (XDR) pour offrir une visibilité plus détaillée sur les environnements et mieux contrôler ces derniers
Service d’accès sécurisé en périphérie (SASE) pour consolider les contrôles existants et offrir un accès indépendant du site aux ressources, avec un contrôle affiné de l’accès conforme à une approche Confiance zéro
Sécurité des conteneurs pour fournir une plateforme bénéficiant d’améliorations rapides et d’une configuration homogène pour les micro-services

En aidant les équipes de sécurité à améliorer la couverture et la visibilité sur les événements liés à la sécurité, ces approches élargies leur permettent de se focaliser sur la gestion des résultats réels en matière de sécurité, plutôt que de passer du temps à gérer les plateformes — une activité chronophage, qui les détourne de leur cœur de métier.

DXC, un expert de la sécurité

Leader reconnu en matière de services de sécurité, DXC donne à ses clients les moyens d’empêcher les attaques potentielles, de réduire les cyber-risques, et d’augmenter leurs capacités de détection et de gestion des attaques. Nos services de conseil et nos services de sécurité gérés 24 h/24 et 7 j/7 sont assurés par 3 000 experts et reposent sur un réseau mondial de centres de sécurité. Avec ses solutions sur mesure adaptées aux divers besoins de sécurité du client, DXC est notamment spécialisé dans les domaines suivants : cyberdéfense, identité numérique, infrastructure sécurisée et protection des données.

Découvrez comment DXC peut aider votre entreprise à l’ère de la révolution numérique : www.dxc.technology/security.

Les auteurs

Dr. Rhodri Davies est architecte opérations de sécurité et de service chez DXC Technology, avec plus de 20 ans d’expérience dans le domaine. Membre de la division Services de sécurité gérés, il étudie notamment les technologies requises pour protéger les clients de DXC et la façon dont elles opèrent au quotidien pour offrir un service efficace.

Mike Dutton est architecte sécurité senior pour DXC Managed Security Services (Australie). Présent chez DXC depuis près de dix ans, il est impliqué dans la quasi-totalité des services de sécurité gérés de DXC, notamment ceux portant sur la sécurité du cloud. Mike veille à ce que DXC sélectionne des contrôles de sécurité adaptés et efficaces pour aider les clients à atteindre leurs objectifs de transformation numérique.

Yahya Kharraz est architecte sécurité de l’information chez DXC Technology, et possède une vaste expérience dans la sécurité, des solutions techniques à la gouvernance de la sécurité, en passant par les risques. Fort d’une solide expérience dans la sécurité des terminaux et des infrastructures, Yahya est un passionné du cloud, du développement d’applications Web, d’automatisation et de code. Il démontre un vif intérêt professionnel vis-à-vis des technologies de pointe, qu’il ne cesse d’explorer et d’évaluer.

Dirk Thys est consultant en conformité aux règles de sécurité chez DXC Technology. Il est également architecte en chef/ingénieur chargé de la consolidation et de la sécurité de la plateforme DXCTM à travers le monde. Dirk travaille en étroite collaboration avec les partenaires et les fournisseurs afin de satisfaire les besoins métier de DXC et les exigences de la clientèle. Il a occupé divers postes aux opérations informatiques, en ingénierie, en gestion de projet et en direction de programmes. Enfin, il a géré des équipes de sécurité des plateformes, chargé de mener à bien des services de gestion de la conformité auprès de plus de 600 clients du monde entier.