L’Operational Resilience Maturity Assessment Framework est un outil qui permet de mesurer la résilience opérationnelle d’une organisation.

Qu’est-ce que c’est la résilience opérationnelle ?

La résilience opérationnelle est une discipline encore jeune et de plus en plus inévitable pour les organisations, notamment pour le secteur financier. On peut citer le Royaume Uni qui est pionnier sur le sujet, avec l’entrée en vigueur d’un Operational Resilience Framework en mars 2022, imposé par la Bank of England, la Prudential Regulation Authority (PRA) et la Financial Conduct Authority (FCA) et l’Union Européenne, qui suit, avec la réglementation Digital Operational Resilience Act (DORA). Les autorités sont en effet parties du principe que de nombreux événements pouvaient perturber les activités des banques (et plus largement des organisations).

La résilience opérationnelle prend donc en compte différentes sources de menaces : menaces venant d’un tiers (un partenaire, un fournisseur ou un prestataire), pandémie, panne d’électricité, incendie pour ne citer qu’eux. D’un point de vue organisationnel, la résilience est très souvent un programme piloté par un Head of OpRes, la DSI ou la division risques, et moins souvent par un RSSI.

Pourquoi avoir créé l’Operational Resilience Maturity Assessment Framework accélérateur ? Quel problème cela résout chez les clients ?

Sous la pression des régulateurs, nos clients ont dû mesurer leur niveau de résilience. La compliance est un bon point de départ mais elle ne va pas assez loin ! L’idée de notre Operational Resilience Maturity Assessment Framework, c’est d’avoir un outil qui englobe à la fois ces nouvelles directives et aussi les meilleures pratiques observées sur le terrain. L’outil est utile car il :

• Permet de mesurer la maturité d’une organisation sur les méthodologies et processus en place pour appréhender la résilience opérationnelle
• Rend compte des capacités réelles de résilience à un instant T, en analysant les outils et les capacités en place
• Facilite la formalisation d’un plan de réduction des risques et de pilotage
• Intègre toute l’expérience terrain de Wavestone en matière de résilience de tous nos bureaux ! Outre-Manche notamment, plus avancé que les pays de l’Union européenne, on travaille sur des missions de résilience depuis plus de 3 ans.

Concrètement, l’Operational Resilience Maturity Assessment Framework centralise dans un Excel l’ensemble des dimensions à prendre en compte pour être résilient et monter en maturité. En tout, on a identifié 90 questions, classées en 12 grands sujets que couvrent la résilience.  Le questionnaire peut être déroulé comme tel afin d’évaluer la résilience opérationnelle d’un client. Mais il peut aussi être utilisé comme trame pour construire son propre département de résilience et comme un vecteur d’identification de projets, sans pour autant procéder à une évaluation. Comme base pour une évaluation sur-mesure et conforme aux standards du client.

Aussi, à mesure que le paysage réglementaire se développe, les entreprises doivent pouvoir mettre en place ou renforcer leurs forces de veille pour rester en avance sur les régulateurs et la concurrence. Par conséquent, en complément de notre outil d’évaluation de la maturité de résilience, nous avons développé le « Radar réglementaire de la résilience opérationnelle » qui cartographie les réglementations à travers le monde selon les mêmes thèmes. Mis à jour tous les trimestres, il offre une vue d’ensemble des évolutions réglementaires sur la résilience opérationnelle et permet à l’utilisateur de les comparer par géographie et par sujet.

Peux-tu nous parler de la dernière fois que tu l’as utilisé (exemple concret) ?

En fait, l’élément déclencheur de la création de notre outil a été la réalisation d’une mission pour un grand acteur du secteur bancaire ! Pendant cette première mission, on a pu définir quatre niveaux de résilience : 1 : « insuffisant », 2 : « compliant », 3 : « bon niveau » et 4 : « leader ».

Récemment on a décroché une deuxième mission qui nous permet de peaufiner les questions, pour qu’elles soient plus précises et exhaustives. On a également retravaillé notre liste de preuves qui sert à justifier un positionnement sur tel ou tel niveau de maturité et on a ajouté un 5^e niveau, « le pionner ».

Pour l’instant le benchmark de la maturité en matière de résilience se concentre sur les banques qui est un secteur plus mature compte tenu de leurs contraintes réglementaires et de la sensibilité des données qu’il traite. Pour une organisation d’un autre secteur, il faudra adapter les niveaux pour s’aligner sur la maturité globale du marché.

Un mot pour la fin ?

On pense qu’on pourra aller encore plus loin dans l’évaluation de la résilience dans quelques années. Plus on aura de retour du terrain, plus on pourra être précis dans les conditions requises pour atteindre un niveau. Par exemple, un acteur sera jugé mature s’il a la capacité de reconstruire son AD en 3h. Comme sur le CyberBenchmark. La prochaine étape serait donc de définir des indicateurs quantitatifs et/ou qualitatifs… Et la seule manière d’y arriver c’est de continuer à confronter le framework à la réalité !

Si tout est améliorable, on est super fières de cet outil qui a été co-construit avec nos clients et nos experts et qui a déjà fait ses preuves.

Cet article [INTERVIEW] Résilience opérationnelle, savoir rebondir après une cyberattaque est apparu en premier sur RiskInsight.

Pour cela, il est nécessaire de savoir d’où vous partez, et de connaitre votre positionnement par rapport au marché. C’est avec cette conviction que Wavestone a construit son framework d’évaluation de maturité cybersécurité, qui capitalise aujourd’hui sur l’accompagnement de 100 organisations internationales.

Découvrez le fonctionnement du CyberBenchmark avec Anthony GUIEU, Manager Cybersécurité chez Wavestone.

Bonjour Anthony. Pour commencer, peux-tu présenter le CyberBenchmark en une phrase ?

Le CyberBenchmark est un outil complet qui permet aux entreprises d’évaluer leur niveau de cybersécurité, de se positionner par rapport au marché, et d’établir une feuille de route – grâce à un questionnaire et à une base de données de près de 100 clients dans le monde entier.

Pourquoi avoir créé le CyberBenchmark, alors qu’il existe déjà de nombreux frameworks sur le marché ?

Nous avons créé le CyberBenchmark car beaucoup de clients nous demandaient où ils se positionnaient par rapport au marché. Historiquement, nos clients recherchaient des évaluations en valeur absolue par rapport à des frameworks connus comme le NIST ou l’ISO. Aujourd’hui, ils souhaitent de plus en plus connaître leur position relative par rapport à leur écosystème. Notre CyberBenchmark permet de traiter ces deux approches simultanément.

Cela nous permet de sortir des angles d’attaque un peu différents : il y a des thématiques sur lesquelles nos clients ne sont pas matures par rapport au marché, donc ils peuvent progresser, et il faut prioriser ces actions-là. À l’inverse, il y a des thématiques où ils ne sont pas bons, mais le marché n’est, lui, pas mature ; il faut alors relativiser l’urgence du sujet. Des entreprises comme Gartner ou Forrester fournissent des tendances générales sur des grandes thématiques cyber, nous y ajoutons une vision concrète de nos observations sur le terrain, auprès de nos clients.

Quand nous avons construit le CyberBenchmark, nous avons vite réalisé que beaucoup de concurrents proposent leur version enrichie des questionnaires de cybersécurité. Notre vraie valeur ajoutée, c’est la comparaison avec le marché : près de 100 clients nous font confiance et ont été évalués avec ce cadre de référence à date !

Comment fonctionne le CyberBenchmark ?

Pour avoir un cadre cohérent, nous nous sommes basés sur des frameworks existants, c’est-à-dire les normes de sécurité qui font référence sur le marché : ISO 27001/2, NIST… C’était un point de départ obligé, car nos clients utilisent ces standards pour s’évaluer. Nous avons ensuite enrichi le questionnaire avec notre propre retour terrain, pour affiner les niveaux de maturité par thématique.

Une des valeurs ajoutées du CyberBenchmark : la granularité de l’évaluation, qui permet de mesurer précisément quelle part du périmètre atteint chaque palier de maturité. Concrètement, il est possible de répartir le niveau de maturité pour une question donnée entre les différents niveaux : par exemple 30% niveau 2, 60% niveau 3 et 10% niveau 4, ce qui peut être dû à un périmètre hétérogène, à des initiatives en cours… Cela nous permet de valoriser les projets au temps long et aux déploiements complexes sur plusieurs périmètres, en particulier dans les grands groupes, en matérialisant leur avancement.

Par la suite, chaque évaluation donne lieu à un rapport en deux parties :

• Une partie pour le top management avec les ratios budgétaires, ressources humaines et le niveau de maturité par rapport aux référentiels internationaux.
• Une partie pour les opérationnels de la sécurité avec les bonnes et mauvaises pratiques identifiées, ainsi que les actions à lancer en priorité. L’idée, c’est d’aboutir à des recommandations et des mesures concrètes pour augmenter le niveau de l’organisation.

Dans quels cas utiliser le CyberBenchmark ? 

Pour moi, c’est l’outil idéal pour une organisation qui souhaite identifier rapidement ses priorités en cybersécurité.

• Les premiers résultats sont rapides : en un mois, nous sommes en mesure de produire un livrable à présenter au Comité Exécutif, avec des propositions d’actions concrètes.
• C’est l’un des rares outils du marché à offrir une comparaison par rapport aux concurrents.
• A la différence des frameworks classiques, notre questionnaire traite à la fois de problématiques de gouvernance et opérationnelles.

Le CyberBenchmark a aussi l’avantage de se décliner pour tous les besoins et les budgets.

• L’approche « rapide » ne nécessite que quelques entretiens, et repose sur une évaluation déclarative pour rapidement détourer le niveau de maturité de l’entreprise et les projets à lancer.
• L’approche « complète » repose sur un audit approfondi, de plusieurs dizaines d’entretiens et une revue des preuves voire des tests techniques complémentaires (test d’intrusion, Red Team…)

Peux-tu donner un exemple d’utilisation concret du CyberBenchmark ?

Pour illustrer l’approche « rapide », nous l’avons utilisé récemment pour accompagner un grand groupe industriel qui voulait initier une démarche de sécurisation et interpeller son comité exécutif. Après 2 mois de travaux et 5 ateliers de travail, nous avons pu restituer une vision claire du niveau de cybersécurité de la structure et projeter un niveau cible à 3 ans, qui a été accepté par le Comité Exécutif.

En termes d’approche complète, nous avons accompagné ces derniers mois une banque britannique pour évaluer finement son niveau de conformité par rapport aux cadres de référence et sa posture générale en cybersécurité. Dans ce cadre, nous avons mobilisé une équipe de 10 consultants sur 3 pays différents pour réaliser plus de 50 ateliers, en collectant des preuves pour amener un retour concret et fiabilisé du niveau de sécurité tout en identifiant par rapport au marché les points sur lesquels ils devaient investir en priorité. Ces éléments sont également utilisés dans les échanges avec leurs principaux régulateurs.

Un mot pour la fin ?

Le CyberBenchmark de Wavestone fournit une vision large du niveau de maturité du marché, tout en entrant dans des sujets techniques très précis. C’est ce qui en fait un atout différenciant pour nos clients c’est qu’ils ont la capacité de se positionner face aux entreprises de leur secteur sur chacune de leurs thématiques. Les priorités en matière de cybersécurité ressortent alors clairement, ce qui permet de construire efficacement son budget cyber. Il s’agit d’un réel accélérateur de stratégie cyber, testé et approuvé par de nombreux clients !

Grâce aux données exclusives du CyberBenchmark, nous pouvons sortir des statistiques et des tendances très facilement : combien d’entreprises ont déployé un outil de sécurité (EDR, bastion, sondes…) et où en sont-elles sur le déploiement, qui est en avance sur le marché… Par exemple, d’après notre dernière étude sur la maturité des entreprises françaises, le niveau de maturité général sur notre référentiel basé sur les normes internationales (NIST CSF Framework et ISO 27001/2) est de… 46% en moyenne. Chaque année, nous formalisons notre connaissance du marché, et nous anticipons les tendances fortes par secteur et sujet technique.

Enfin, vous l’aurez compris, le CyberBenchmark vit et se développe au fur et à mesure qu’il est utilisé pour de nouvelles entreprises. Nous disposons aujourd’hui d’une base de près de 100 entreprises ce qui va nous permettre dès janvier d’ouvrir une nouvelle catégorie : « Luxury goods & retail », comportant plus d’une dizaine d’entreprises sur lesquelles nous pourrons affiner les analyses relatives à leur secteur d’activité.

Si vous êtes intéressés pour positionner votre organisation par rapport au marché, n’hésitez pas à me contacter ou à prendre contact avec nos experts : nous pourrons vous accompagner sereinement dans cette démarche.

Cet article Interview : Un mois pour évaluer votre posture en cybersécurité ! est apparu en premier sur RiskInsight.

De l’évidence de l’IAM, et de la difficulté des transformations qu’il implique

Face à l’évolution des menaces et des usages (mobilité, télétravail, Cloud Computing…), non seulement l’IAM n’est plus une option ; mais il est désormais acquis que disposer d’une gestion efficace et agile des identités et des accès est un différentiateur.

Par essence, l’IAM est à la croisée de toutes les transformations structurantes : c’est entre autres choses un pilier majeur pour s’orienter dans une approche zéro-trust, un essentiel « de base » pour servir efficacement ses utilisateurs et leur apporter un confort constant pendant toutes les phases de transformation, et c’est évidemment un différentiateur dans la création de la relation avec ses clients.

L’IAM ne peut plus simplement se permettre de « suivre à distance » les transformations de l’Entreprise, en offrant un niveau de service a minima et souvent difficile à faire évoluer. Il doit être efficace, agile, et en capacité d’anticiper des situations parfois complexes comme des M&A, la multiplication des APIs, ou la bascule vers modèle d’économie « plate-forme ». Ces situations impliquent de repenser en profondeur son IAM : son périmètre et son ambition, sa politique et sa gouvernance, son mode de delivery (on-premise vs SaaS), son offre de service et son modèle économique…

Le déploiement des services d’IAM chez les grands comptes 

Maturité du marché : savoir évaluer sa maturité par rapport au marché pour engager son programme de transformation sur une base solide et objective

La grande majorité des grands comptes ont déjà conduit un ou plusieurs projets qui ont permis de déployer des services IAM. Toutefois, ces déploiements sont souvent partiels et la maturité du déploiement peut fortement varier d’une entité à l’autre. Historiquement, ces projets sont en fait confrontés à une forte hétérogénéité des existants (en matière d’organisations, de processus et de SI), et ne dispose pas de la légitimité nécessaire pour faire converger les pratiques. De plus, l’IAM était souvent vu comme un projet « one shot » avec des moyens souvent insuffisants pour suivre et s’adapter aux évolutions de l’Entreprise (réorganisation, M&A, évolutions d’application…). Ces éléments ont pu conduire à un « décrochage » entre les sujets IAM, trop statiques, et les besoins réels en évolution permanente.

Parce que déployer des services d’IAM, ce n’est pas simplement déployer une « boîte » en production. Pour en tirer bénéfice, il est nécessaire de repenser et simplifier son organisation et ses processus IAM, et notamment se poser les questions suivantes :

• Comment gérer l’arrivée d’un nouveau collaborateur ?
• Comment gérer l’internalisation d’un prestaire ?
• Comment modéliser ses profils métiers ? Comment les faire évoluer dans le temps ?
• Comment impliquer les managers, les responsables des données dans les processus IAM ?
• Comment traiter la perte de moyen d’authentification forte ?
• Quels standards imposer pour simplifier le raccordement des applications à l’IAM ?
• Comment s’assurer du respect des règles internes ou de règlementations ?

Depuis maintenant quelques années, nous constatons une réelle prise de conscience et une volonté de nos clients à s’emparer de l’IAM pour le rendre plus efficace, plus rationalisé et plus agile : cela implique pour pouvoir arbitrer et conduire une transformation en profondeur. Concrètement, sur les 3 dernières années, 2/3 de nos clients ont lancé de tels programmes de transformations IAM. Ces initiatives, pluriannuelles, ont gagné en ambition, en structure, en investissement, en visibilité et réussissent désormais à figurer en bonne place dans le « Top 5 » des grands projets de transformation de la DSI.

Pour engager de tels programmes, la première étape consiste à pourvoir évaluer sa maturité réelle, entité par entité, avant de pourvoir définir une trajectoire de transformation réaliste et fédératrice entre les parties prenantes. De manière très simplifiée, nous pouvons distinguer 4 niveaux de maturité :

• Fragmenté: l’organisation n’a pas d’approche consolidées
• Rationnalisé: l’IAM est simplifié et géré de manière centralisée sur les services de base
• Etendu: capacités organisationnelles d’IAM adaptées à un S.I en évolution
• Maîtrisé: IAM efficient, agile, réduction de la charge de travail grâce à l’automatisation

En tendance, nous pouvons considérer que les grandes entreprises se situent sur les niveaux intermédiaires « Rationnalisé » et « Etendu », et vise une cible « maitrisée » ; s’appuyant sur :

• Une infrastructure IAM centrale, unique et optimisée.
• Une gestion courante déléguée au sein de chaque entité.

5 clés pour réussir à opérationnaliser sa stratégie d’IAM

L’IAM est un vaste sujet où il est facile de se perdre. De plus, la réalité opérationnelle de l’IAM est très souvent mal connue et la complexité de transformation sous-estimée.

Pour pallier ces risques, nous vous proposons 5 clés majeures :

• Bien définir son ambition IAM et s’assurer de la cohérence entre cette ambition et les moyens alloués : sponsor, capacité à faire bouges les lignes, moyens humains et financiers
• Prendre le temps de s’approprier la réalité opérationnelle de l’IAM
• S’organiser dans un programme de transformation à même d’aborder l’ensemble des facettes
• Se préparer à une transformation en profondeur, et accepter d’avancer par étapes et avec des compromis, et donc des renoncements, pour faire face à la somme des contraintes
• S’appuyer sur les données réelles pour expliquer ses arbitrages et pour anticiper les éventuels manques de qualité.

S’appuyer sur les fournisseurs IAM : tendances et risques

Le marché des fournisseurs IAM se structure, et translate dans le Cloud

Le marché des fournisseurs IAM, comme les autres marchés spécialisés, évolue à partir des évolutions que connaissent les systèmes d’informations : basculer vers le Cloud, offrir plus d’API, intégrer des fonctionnalités d’analyse de données, d’IA, afin de simplifier voire d’automatiser la prise de décision.

En complément de ces considérations, deux tendances propres au marché des fournisseurs IAM se dégagent :

• Premièrement, les acteurs leaders de l’Access Management cherchent à progressivement étendre leur couverture fonctionnelle vers des fonctionnalités de Gestion des Identités ou de PAM.
• Deuxièmement, il y a de plus en plus d’acteurs couvrant des besoins fonctionnels spécifiques, comme l’IAI (Identity Analytics & Intelligence), le CIAM ou le souhait de disposer d’une plate-forme directement développée dans Service Now.

Le déplacement dans le Cloud indique des modifications d’architecture des solutions IAM

De plus en plus d’éditeurs proposent des solutions d’IAM dans le Cloud. Ce mouvement vise à offrir la même couverture fonctionnelle que les applications « on-premise » en mode SaaS. Suivant les services offerts, elles sont structurées autour de deux composants :

• Une partie « Cloud » qui porte l’ensemble des fonctionnalités et stocke les données des clients ;
• Une « passerelle » sur site qui permet de faire le lien avec le système historique en place (pour le provisioning par exemple). Elle permet un meilleur contrôle des échanges de données et concourt donc à sécuriser l’architecture.

Ainsi, cette architecture à deux composants présente les mêmes risques que tout autre service Cloud, et il faut les aborder de la même manière : Quels sont les niveaux de services garantis ? Où sont stockées mes données ? Quid de la protection de mes données et du respect des normes (GDPR notamment) ? Dans quelles conditions puis-je changer de fournisseurs ?

Le contexte géopolitique accroit ces risques et fait également peser un risque spécifique de coupure de service en application d’éventuelles sanctions internationales.

Et l’IAM du futur : quelles évolutions ?

Demain, l’IAM va continuer ses transformations pour aller vers plus d’agilité, plus de Cloud, plus de standard et d’intégration, plus d’aide à la décision et d’automatisation grâce à l’IA. Concernant le système d’authentification, l’authentification forte est désormais un « basic » et deux évolutions majeures se jouent :

• Une évolution plutôt technique avec le « passwordless » qui vise à faire disparaitre les mots de passe, y compris techniquement dans les bases de données des applications et les flux inter-applicatifs.
• Une évolution sur le moyen d’authentification donné aux utilisateurs. Le Smartphone s’est imposé comme un facteur d’authentification mais toutes les populations en Entreprise ne sont pas équipées. Et alors que le support « carte à puce » est en perte de vitesse, les dongles sécurisés (composant matériel se branchant sur les ordinateurs ou les téléviseurs, généralement sur un port d’entrées-sorties semblent s’imposer pour ces populations sans Smartphone.

Enfin, à plus long terme, l’IAM évoluera certainement sous l’impulsion de l’approche « privacy-by-design », de plus en plus intéressante et amenée à être de plus fréquente ; et, pourquoi pas, avec la généralisation de l’identité citoyenne (avec un niveau d’enrôlement ad hoc), y compris pour des usages commerciaux.

Cet article L’IAM est enfin entré dans le Top des grands projets de transformation de la DSI ! est apparu en premier sur RiskInsight.

Tout d’abord, il faut savoir que la sécurité du cloud est particulièrement différente en fonction des types de cloud et de la manière de consommer des services cloud. Parmi ces services, on y retrouve trois grandes catégories : SaaS (Software as a Service), PaaS (Platform as a Service) et IaaS (Infrastructure as a Service).

Globalement la sécurité du cloud est bien distincte entre la partie PaaS / IaaS et la partie SaaS. Cela se matérialise par le principe de modèle de responsabilité partagée. Lors de la consommation d’un service cloud, le client aura accès à un certain périmètre avec un certain nombre de couches de données ou infrastructure suivant la catégorie de service cloud.

Ce modèle permet de déterminer sur quel périmètre du service la responsabilité du fournisseur de cloud ou celle du client est engagée. La partie sécurité va elle aussi être partagée sur les couches de données sur lesquelles le client va avoir la responsabilité, cela demande donc au client de s’assurer de la sécurité de son périmètre.

Dans le cadre du SaaS, pour donner un exemple, Microsoft Office 365 est un service où le client intègre ses données et n’a pas accès à toutes les couches basses du service. Le client ayant peu d’accès à la configuration du service et par conséquent sur la sécurité, il peut exiger contractuellement un niveau de sécurité auprès de son fournisseur qui aura la main sur la configuration du service.

Au contraire, sur des solutions PaaS ou IaaS, le client aura accès aux couches inférieures et aura donc la responsabilité de les configurer pour se garantir de leur sécurité si elles ne sont pas gérées par le fournisseur de services. Le client peut toujours exiger certains éléments mais la responsabilité du client sera engagée sur une partie importante de la configuration et de l’utilisation sécurisée du service cloud.

La sécurité du cloud soulève particulièrement un sujet contractuel puisque ce n’est pas le service du client lui-même mais celui d’un tiers. Cela amène des enjeux de sécurité à part entière et en particulier la question de ce que le client peut exiger à son fournisseur en termes de sécurité des données. Ces exigences sont amenées à évoluer en fonction de la nationalité du fournisseur.

Cet enjeu de sécurité induit également des changements d’organisation. La consommation de service cloud doit impliquer de repenser l’organisation de la DSI et sa manière de fonctionner au sens large avec une inclusion de la sécurité dans les nouveaux processus. Dans cette démarche d’agilité, la sécurité doit également l’être avec des pratiques type DevSecOps.

Quelles sont les tendances du marché du cloud et de sa sécurisation ?

Il y a encore quelques années les clients étaient retissant à s’orienter vers des solutions cloud alors qu’aujourd’hui, le sujet fait consensus, il s’impose de plus en plus. Un des facteurs majeurs à son développement est la solution Office 365 de Microsoft Azure.

La tendance du marché côté client est de lancer des grands programmes de migration cloud afin d’être accompagné dans cette démarche, notamment s’ils doivent faire appel à un seul ou plusieurs fournisseurs. Le sujet du multisourcing est particulièrement important en ce moment. Les clients se demandent également comment organiser leur DSI afin d’adopter des principes agiles et DevOps et ainsi réaliser leur transformation de manière intelligente. L’objectif n’est pas de réaliser du “lift and shift”, soit migrer une application on-premise existante sans effectuer de modification ou de refonte en l’intégrant directement dans le cloud.

Les clients se rendent compte que la gestion du système d’information suppose des coûts très importants et que cela ne correspond pas au cœur de leur métier. L’offre cloud permet de laisser les entreprises avec cette expertise, les fournisseurs de services, réaliser la migration de ces plateformes cloud. Cela permet au client de se concentrer sur ses processus métier et réduire le time to market, le temps nécessaire pour réaliser une idée initiale et livrer un produit fini aux consommateurs.

En termes de sécurité, une tendance pour les grands programmes est d’accompagner de manière sécurisée les migrations cloud. Cela passe par plusieurs éléments :

• Un accompagnement sur la contractualisation avec le fournisseur cloud concernant le modèle de responsabilité partagée et ce que le client peut migrer ou non ;
• Sur l’organisation de la DSI pour qu’elle devienne DevSecOps, approche qui permet d’intégrer la sécurité dans l’ensemble du cycle de vie des projets, du développement à la mise en œuvre, en utilisant des méthodes flexibles et l’approche DevOps ;
• Pour les clients plus avancés ayant déjà entamés une migration et qui possèdent déjà un multicloud, l’objectif est de les accompagner dans l’harmonisation de ces différentes plateformes cloud et en particulier en termes de sécurité.

Du côté des éditeurs de solution de sécurité pour le cloud, la tendance est de proposer des offres multicloud mais tout en cloisonnant les différents types de cloud (IaaS, PaaS, SaaS) afin de proposer des outils spécialisés. Les outils dits CSPM (Cloud Security Posture Management) qui permettent de réaliser des contrôles de conformité sur des plateformes multicloud sont la dernière tendance du marché. Sur le volet chiffrement qui est un sujet sensible pour nos clients, la dynamique d’accompagnement du multicloud s’articule autour d’offres de service type HSMaaS ou KMSaaS qui permettent de provisionner des clés, appartenant au client – de type BYOK, utilisables d’un cloud à l’autre.

D’un point de vue technologique, la tendance de fond reste le serverless. C’est un modèle de développement cloud qui permet aux développeurs de créer et d’exécuter des applications sans avoir à gérer des serveurs. La conteneurisation et les technologies Dockers ou Kubernetes sont en cours de déploiement à grande échelle chez nos clients entrainant des grands enjeux de sécurité.

Quelles sont les difficultés que nos clients rencontrent sur les sujets abordés ? En quoi cela constitue un réel challenge ?

Les clients ayant une faible maturité sur le sujet qui sont réticents à migrer dans le cloud sont généralement les entités qui traitent des données avec un très haut niveau de confidentialité (ex : prestataire de santé, armement, etc.). Ils se demandent notamment comment ils peuvent faire confiance à une entreprise américaine. Actuellement quand on parle cloud, on parle principalement d’acteurs américains : Microsoft, Amazon et Google, qui possèdent la quasi-totalité du marché du cloud public.

Pour répondre à cette interrogation, on met en avant que lorsque l’on fait appel à un fournisseur de cloud, il faut une totale confiance envers lui. L’objectif est de définir la partie contractuelle en amont de la migration du client pour s’assurer d’une total confiance envers le fournisseur sur l’accès aux données qu’on va lui transmettre. Cela peut notamment passer par une garantie contractuelle, des contrôles de sécurité, etc.  À noter que le chiffrement n’empêchera jamais le fournisseur d’accéder aux données, il faut donc s’assurer de sécuriser le cloud contre les vraies menaces.

Certes, on accepte un risque infime que le fournisseur puisse accéder à ses données, puisqu’elles lui sont transmises, mais le risque reste négligeable par rapport au risque en tant que client d’effectuer une mauvaise configuration du service cloud. Ainsi, les principaux incidents de sécurité du Cloud concernent le vol de données exposées publiquement au travers de services de stockage (S3 bucket, Azure storage, etc.). La responsabilité du fournisseur n’est pas engagée dans ces cas-là puisque c’est au client de garantir la bonne configuration des services PaaS qu’il utilise afin qu’ils soient utilisés en mode privé et non exposé.

Cela nécessite bien évidemment un effort sur les compétences pour consommer des services cloud de manière intelligente tout en le sécurisant.

Pour les clients plus avancés, le vendor locking est un sujet dominant. Si demain, le fournisseur de cloud avec qui le client collabore est amené à arrêter son activité ou est indisponible pour une durée définie, le client perd l’accès à son SI. C’est d’ailleurs pour cette raison que les clients se tournent vers des stratégies multicloud.

Comment répondre à ces problématiques et comment Wavestone peut intervenir ?

Notre conviction chez Wavestone, c’est que le cloud peut être un facilitateur pour la sécurité du SI. Une porte d’entrée pour construire un SI sur des bases saines et s’appuyer sur des technologies qui fonctionnent. Vous pouvez en profiter pour mettre la sécurité au bon endroit dès le début et une des clés pour y arriver est l’automatisation.

L’automatisation doit être mise en place dans le déploiement, les infrastructures mais également la sécurité afin d’obtenir une véritable plus-value. Si le client pose les bonnes règles de sécurité et que ces règles techniques sont traduites dans les chaines d’intégration et de déploiement (CI/CD), le client aura la garantie que le déploiement ses ressources et infrastructures seront sécurisées dès leur déploiement.

Wavestone accompagne également les clients à contractualiser avec des fournisseurs cloud. Nous aidons nos clients à construire des landings zones, c’est-à-dire les bases des architecteurs de sécurité qui vont être déployée dans le cloud. Nos équipes sont intégrées dans des centres d’excellence cloud chez nos clients et travaillent tous les jours à la sécurisation des infrastructures de cloud. Nous avons également la capacité d’aider nos clients dans leur transformation agile et notamment sur les sujets DevSecOps, afin d’apporter la sécurité au plus près de leurs projets.

Quel avenir pour la sécurité du cloud ?

La tendance émergente du moment est le Zéro Trust. C’est un nouveau modèle de sécurité qui répond aux enjeux cloud et usages actuels de mobilités des personnes et de la donnée. Le modèle Zero Trust a pour objectif d’accorder l’accès sur le besoin d’en connaitre et donc de remettre la sécurité au plus proche des ressources.

L’objectif est de remettre l’utilisateur au centre avec la garanti du moindre privilège et de contrôler l’accès à une ressource à chaque fois que quelqu’un en exprime le besoin. Cette vérification se fera quelle que soit son origine même si c’est un collaborateur interne. L’identité et l’authentification sont au centre, tout comme les moyens de détection et de contrôle.

La définition des algorithmes d’attribution des moindres privilèges et la vérification systématique à chaque nouvelle demande d’entrée drainent de vastes sujets autour de la gouvernance des identités pour nos clients. Leur traduction technologique, comme avec Azure AD pour citer la technologie de Microsoft, nécessite de solides connaissances techniques et un accompagnement au changement pour être en mesure d’identifier et configurer les bons moyens d’authentification (MFA, attribution de droits temporaire, etc.) et de contrôles (Conditional Access Policy, sign-logs, etc.) disponibles.

Ce modèle est particulièrement adapté à un usage cloud puisque la plupart des fournisseurs de cloud public permettent l’utilisation de technologies plus fiables et configurables qu’on-premise pour gérer les identités, l’authentification et la détection.

Cet article Les enjeux et les tendances de la sécurité du cloud, interview de Vincent Ferrie est apparu en premier sur RiskInsight.

Les tableaux de bord et KPIs qui véhiculent des messages concrets et appellent à l’action sont souvent le moteur du succès des initiatives de résilience opérationnelle.

La résilience opérationnelle rassemble des disciplines auparavant gérées en silos : continuité d’activité et reprise métier et IT, gestion d’incident et de crise (IT, métier et cyber), cyberdéfense, gestion des tiers, gestion des risques opérationnels. Un pilotage efficace de la résilience opérationnelle nécessite une analyse des données relatives à tous ces sujets afin de produire une vision réaliste de la résilience globale de l’entreprise, et notamment de ses services critiques. Ceci nécessite une cartographie complète des services critiques et de leurs dépendances (processus métiers, applications, fournisseurs, équipes, bâtiments…) et une analyse continue de la résilience des dépendances.

Pour parvenir à cet objectif, un enjeu majeur est lié à l’outillage et l’automatisation. Nous voyons apparaître sur le marché des solutions complètes de « Gestion de la Résilience Opérationnelle » chez des éditeurs spécialisés comme Fusion Risk Management, Castellan ou non spécialisés, comme ServiceNow.

Quels sont les défis à relever dans ce domaine ?

Selon la maturité de l’entreprise, chaque étape du projet peut poser des défis particuliers.

Défi n°1 : le modèle de données

Le modèle de données de la cartographie de résilience opérationnelle doit être créé en tenant compte des services métiers critiques et de leurs dépendances. Idéalement, les organisations réutilisent les inventaires existants (par exemple : CMDB, inventaires des fournisseurs, BIA, systèmes RH, etc.) et organisent des ateliers pour tirer parti des connaissances des représentants métier et des experts IT, des fournisseurs, etc. Le défi découle de la nécessité de rationaliser tous les éléments dans un format permettant l’analyse des données. Cela signifie que même si l’on débute avec Excel, il est important de définir des règles précises (référencement commun, une information par ligne, etc.).

Défi n° 2 : identifier les lacunes

Une fois cette cartographie effectuée, les organisations doivent identifier les menaces existant sur l’ensemble de la chaîne, ainsi que les compétences de résilience dont l’entreprise dispose déjà pour atténuer le danger lié à ces menaces. Ces compétences peuvent être spécifiques à un élément de la chaîne ou bien générales. Ceci permet aux organisations de créer des indicateurs qui lui permettront d’identifier ses lacunes en termes de résilience. Deux sortes de lacunes peuvent être identifiées :

1. Une dépendance n’a pas de contingence adéquate

Ceci peut être identifié lors de l’analyse initiale, grâce à des contrôles en place, ou lors de tests.

Exemple : une personne veut retirer des espèces. En temps normal, il a accès à ce service via un distributeur automatique de billet. Plusieurs éléments sont nécessaires au bon fonctionnement du service « normal » :

• Le distributeur physique en lui-même
• Le système d’authentification des clients via leur carte bancaire
• Le logiciel de gestion des comptes client fourni par un tiers permettant la vérification du solde

Ce service peut être affecté par les menaces suivantes :

• Perte informatique majeure (causée ou non par une attaque cyber)
• Perte du fournisseur de logiciel
• Sinistre bâtiment affectant le distributeur physique

Considérant que la période avant que l’impossibilité de retirer de l’argent ne devienne une source intolérable de préjudice pour le client (c’est-à-dire la tolérance à l’impact) est de 4 heures, la banque doit se poser les questions suivantes pour identifier les lacunes en matière de résilience :

• RTO (Recovery Time Objective) : En cas de perte informatique, le distributeur et le système d’authentification peuvent-il être remis en marche en moins de 4 heures selon leur RTO ? Un test a-t-il été réalisé ?
• Plan de réversibilité : En cas de panne majeure ou banqueroute du fournisseur de logiciel de gestion des comptes, a-t-on un fournisseur alternatif prêt à délivrer le service sans dépasser cette période de 4h ? Dans le cas contraire, dispose-t-on d’un plan permettant de délivrer ces activités avec des capacités internes ?
• Contingences : Existe-t-il un processus dégradé permettant de distribuer des espèces en agence par exemple, afin de remplacer un distributeur défectueux ? Quelles sont les dépendances de ce processus ? Peut-il être réalisé sans système informatique ?

Une fois ces lacunes identifiées, des scores de résilience pour les différents composants peuvent être calculés.

2. L’absence d’une compétence clé de résilience

Un certain nombre de compétences clés dans les différents domaines de résilience (continuité d’activité métier et IT, gestion des tiers, cyberdéfense, reconstruction informatique, gestion de crise) doivent être en place dans l’organisation. Wavestone a identifié une liste de 50 compétences clés génériques, liées aux menaces les plus communes, et déploie ce modèle chez nos clients pour mesurer leur niveau de maturité global.

Les compétences clés peuvent être par exemple :

• Gestion de crise : canal de communication alternatif
• Reconstruction IT : coffre-fort cyber
• Gestion des tiers : SLA de crise en place avec les tiers
• Continuité d’activité métier et IT : processus dégradés sans IT
• Cyberdéfense : procédure d’authentification d’urgence

Défi n°3 : la gouvernance

Enfin, une gouvernance doit être mise en place pour garantir que les données de résilience opérationnelle sont maintenues à jour et que les tableaux de bord générés sont utilisés pour la prise de décision dans les bons comités. Par exemple, l’adhésion de la direction est nécessaire pour financer et hiérarchiser la correction des lacunes identifiées.

              Concrètement, que doit-on mesurer ? 

La question sous-jacente est la suivante : à quel point l’organisation est-elle préparée à faire face à un incident majeur ?

• Est-ce que les dépendances sont identifiées ?
• Est-ce que la documentation nécessaire est en place ?
• Est-ce que les menaces sont connues ?
• Est-ce que des contrôles sont bien en place pour indiquer une lacune ?
• Est-ce que les employés de l’entreprise sont prêts à répondre et minimiser l’impact opérationnel d’un incident majeur ?

Quelles sont les attentes des clients ?

À ce jour, trois thèmes principaux ont émergé de nos constats sur le terrain aux côtés des clients.

Tout d’abord, les organisations ont besoin d’aide pour créer un inventaire en rationalisant plusieurs sources avec divers formats de données.

Ensuite, nos clients ont régulièrement besoin d’aide pour la mise en place de tableaux de bord. Cela peut prendre la forme de la conception d’indicateurs de performance clés (KPI) utiles (actionnables, conduisant à la prise de décision) ou de la création de tableaux de bord visuels dans un outil tel que PowerBI.

Enfin, une demande émergente concerne le déploiement d’outils. Wavestone peut aider les organisations tout au long de leur recherche d’outils correspondant le mieux à leurs besoins :

• Réalisation d’un benchmark
• Création du cahier des charges grâce à des ateliers avec les futurs utilisateurs
• Création d’un RFP et son suivi pour évaluer des fournisseurs

Un exemple concret de l’expertise de Wavestone dans ce domaine est la deuxième édition du panorama des fournisseurs d’outils de résilience opérationnelle. Il capte les principaux acteurs du marché à travers une gamme de sujets tels que les notifications d’urgence, la gestion de la résilience (cartographie, tests, tableaux de bord), la gestion de crise et la simulation d’incidents métier ou cyber. Le panorama vise à englober les innovateurs et les acteurs traditionnels, les start-up et les grandes organisations.

Un dernier conseil pour les lecteurs ?

Pour les clients français n’ayant pas lancé de programme de résilience opérationnelle, pour le moment, deux conseils sont à retenir :

• Une fois la cartographie réalisée, il faut réfléchir à la manière de stocker les données (c’est-à-dire le modèle de données). Pour assurer la pérennité, Excel ne sera pas forcément suffisant.
• Ne pas hésiter à réutiliser ce que l’organisation possède déjà en termes de continuité d’activité et IT, de gestion des tiers, de risque opérationnel, de cyberdéfense, de reconstruction informatique et de gestion de crise.

Cet article L’analyse de données et l’automatisation au cœur du pilotage de la résilience opérationnelle, interview de Roxane Bohin est apparu en premier sur RiskInsight.

Historiquement l’approche Agile est un ensemble de pratiques utilisées pour des projets de développement informatique.  

Le Manifeste publié en 2001 propose 4 grandes valeurs pour révolutionner la performance des entreprises : 

Ce point d’honneur mis aux interactions humaines entre équipe de développement et acteurs métiers vise à réduire le time to market des produits ainsi développés, par opposition à des projets menés en cycle en V qui une fois livrés, et pour caricaturer, ne correspondaient plus aux attentes du métier qui avaient eu le temps d’évoluer.  

Aujourd’hui cette pratique est appliquée dans la majorité des entreprises à tous les niveaux. Dans le dernier State of Agile Report, sur plus de 4000 entreprises interrogées dans le monde, 95% déclarent utiliser l’agile et 65% d’entre elles le pratiquent depuis au moins 3 ans.  Par ailleurs au-delà des domaines IT, la méthodologie est aussi utilisée dans les directions marketing, ressources humaines, ventes ou encore finances. 52% des entreprises sondées déclarent qu’au moins la moitié des directions de leur entreprise travaillent en agile. C’est un réel passage à l’échelle qu’il ne faut pas louper.  

Au-delà d’une méthode de management de projet c’est une nouvelle philosophie avec des éléments gamifiés. On ne parle plus de réunion mais de cérémonie et de rituel, et de nouveaux rôles apparaissent (product owner et scrum master par exemple). Le souhait est réellement de créer une ambiance de co-construction et d’utiliser au maximum l’intelligence collective pour améliorer les performances de l’entreprise. 

Concernant la sécurité, bien que sous-jacente à la pensée des auteurs du manifeste, ils ne donnent pas plus d’indications que cela pour l’intégrer aux produits. L’intégration de la sécurité dans les projets (ISP) à la mode « cycle en V » n’aurait pas de sens dans un produit Agile ; l’ISP (le « P » pour « produits » cette fois) doit donc se réinventer.  

Quels sont les défis et tendances du domaine ?  

Un de nos défis est d’apporter à nos clients une vision globale de la problématique. Réussir à passer d’une approche traditionnelle à une approche agile nécessite plusieurs niveaux de réflexion pour la sécurité (et d’autres équipes support, telle la qualité, peuvent également être amenées à évoluer en ce sens). Il faut penser organisation certes mais aussi outillage.  

En termes d’organisation, la SSI doit se repositionner comme un service au métier, pour retrouver une image de fonction support, et non plus de « gendarme ». Le rôle de Security Champion est créé : c’est un membre de la feature team (souvent un développeur) qui devient le point de contact privilégié des équipes SSI. Cela permet de recréer du lien avec chaque feature team tout en augmentant l’autonomie sur l’intégration de la sécurité. Cela ne se fait pas en un jour, et un certain nombre de formations doivent être créées et dispensées, pour repartager les enjeux de cybersécurité et de la connaissance (bases de la SSI, développement sécurisé, notamment). Au-delà des formations, cela passe aussi par l’instauration d’une Guilde Sécurité, regroupant experts SSI, Security Champion et toutes personnes intéressées à la sécurité, et permettant d’échanger de l’information sur les dernières actualités sécurité, les bonnes pratiques, mais aussi de partager les retours d’expérience terrain. Cette Guilde doit être outillée pour communiquer le plus simplement possible et pour capitaliser les informations (sur un wiki interne par exemple). 

En tant que référent sécurité, c’est à lui que les développeurs peuvent s’adresser en cas de questions, une fois que l’équipe SSI l’aura formé. Il a donc une casquette assez technique. Les experts SSI gardent leur rôle mais adapté à l’agile ; on va passer d’une relation de contrôle et d’audit à une relation de soutien au fil de l’eau, de facilitateur. Des audits peuvent toujours être réalisés (tests d’intrusion, sur demande de la feature team ou à l’initiative des experts sécurité). De l’outillage méthodologique doit aussi être disponible pour aider les Champions dans leurs tâches et cela passe notamment par la réécriture des risques au format conversationnel. Pour s’adapter à l’utilisation de User Story par les feature teams, l’équipe SSI pourra s’essayer à la rédaction d’Evil User Story, qui correspond à une action réalisée du point de vue d’un attaquant. Par exemple : 

En face de ces risques, des User Story Sécurité, proposant des solutions de remédiation face aux EUS, avec des critères d’acceptance prêts à l’emploi. Tout cela peut être intégré dans une baseline sécurité (également au format backlog, dans un outil de product management, comme JIRA par exemple), proposant un socle minimum de sécurité à intégrer dans les produits. 

Au soutien organisationnel aux équipes doit s’ajouter le soutien technique via l’optimisation de la chaine d’intégration et de déploiement continu (CI/CD) avec des outils visant à automatiser au maximum la sécurité, ce que l’on pourra appeler la Stack Sécurité ou Security pipeline : revue de code, scans de vulnérabilité, détection de secrets, sécurité de l’Infrastructure as Code, etc.).  Une attention particulière doit être porté à sa propre sécurisation, pour ne pas produire l’effet inverse… Dans une optique de shift left security, la sécurité est intégrée par défaut dans le produit, et ce dès le début. Elle adapte donc sa vélocité à celle de l’agile et permet de passer d’une logique de DevOps à celle de DevSecOps.  

Un autre rôle peut être créé, celui d’AppSec Manager. Il fait partie cette fois de l’équipe SSI et est un expert en sécurité logicielle doublé d’un expert de la Stack Sécurité. Il aide les développeurs à prioriser et remédier aux vulnérabilités remontées par la Stack. Il travaille en binôme avec le Risk Manager/Expert SSI, qui lui apporte la connaissance des risques associés au produit, ce qui permet une analyse plus fine des vulnérabilités à traiter en priorité. Tout cela participe à créer une culture de security by design. 

Les défis en mission ensuite sont de s’adapter au maximum aux spécificités client : côté secteur public les attentes et défis sont un peu différents. En effet les ministères sont en train de passer à l’agile mais se pose à eux la problématique des homologations de sécurité de l’ANSSI en neuf étapes. Ce processus s’intègre mal à la méthodologie agile et il faut donc trouver des biais d’adaptation. Une possibilité pourrait être de détailler une checklist de Release permettant à la feature team d’être autonome dans ses mises en production, en sachant quels éléments sont autorisés à passer en production, et lesquels doivent faire l’objet d’une vérification plus approfondie (via un go/no go du RSSI par exemple, ou des contrôles spécifiques).  

Quelles sont les attentes de la part des clients ? 

Les clients RSSI attendent d’être rassurées sur le fait que la sécurité en mode agile ne va pas leur faire « perdre le contrôle » sur la bonne mise en œuvre de la sécurité. Et le modèle que nous proposons responsabilise les feature teams, les outille, mais la sécurité garde le contrôle en centralisant les indicateurs de performance, en ayant la capacité de réaliser des contrôles aléatoires/en fonction de critères prédéfinis, via du bugbounty par exemple ou une enveloppe de jours de pentesters, à répartir sur les différents produits. 

Ensuite, en tant que cabinet de conseil, je pense que les clients attendent de nous le partage de convictions et d’exemples très concrets de ce que nous avons pu réaliser chez d’autres clients. Pour répondre à cette demande, la practice cybersécurité et confiance numérique de Wavestone a créé un certain nombre d’accélérateurs méthodologiques grâce à des retours terrains, prêts à être partagés pour être déconstruits et adaptés. Pouvoir mener nous-aussi la mission en mode Agile fait également partie des attentes, en favorisant la co-construction plutôt que d’apporter des livrables figés et quasi finalisés dès le premier jet. Dans cette optique de gamification chère à l’agile, nous proposons des ateliers de co-construction originaux basés sur l’intelligence collective, grâce à notre asset Creadesk, qui forme les consultantes et consultants et met à disposition des outils de travail collectif à distance. 

Un dernier conseil pour les lecteurs ?  

Mettre en place une véritable démarche en mode test & learn est capital. Co-construire des outils est une chose, mais les tester et les vérifier sur le terrain en est une autre. Anticiper les problèmes est possible jusqu’à un certain point, mais les confronter directement (et les résoudre !) au fur et à mesure représente une valeur ajoutée énorme en mission. Cela permet d’être au contact des métiers et des feature teams directement, de leur montrer que des actions concrètes sont mises en œuvre. La démarche est agile, souple et évolutive. Les accélérateurs, les méthodologies et les outillages proposés évoluent au cours des pilotes et n’en deviennent que plus pertinents pour la deuxième vague de pilotes, jusqu’à ce que toutes les feature teams soient intégrées. 

En parallèle, il faut retenir que la conduite du changement est primordiale. Il faut prévoir un vrai plan de communication, construire les communautés de pratique/les guildes dès les débuts des pilotes, identifier des early adopters qui seront des moteurs précieux du changement au sein même des équipes. L’agile a un impact réel et rapide dans la vie de tous les jours et à tous les niveaux d’équipe : accompagner ce changement est primordial.   

Cet article La sécurité dans l’agile, interview d’Emma Barféty est apparu en premier sur RiskInsight.