Nous essayons de connecter la caméra et nous pourrons commencer dans une minute. Je vais commencer le webinar, Victor va essayer de connecter la caméra. Bonjour à tous, bienvenue.
Donc le sujet aujourd'hui c'est comment réussir l'intégration de la sécurité dans les projets, qui est un vrai challenge pour les RSSI. L'idée c'est vraiment de diffuser la sécurité, c'est-à-dire... Voilà.
T'es déconnecté, le papier qui est mis en micro. Je n'ai pas le son, je vais voir si ça marche. Ben ouais, ouais. Bonjour à tous, est-ce que vous nous entendez ?
Super. Voilà, donc excusez-nous du léger retard, on va essayer de couper la caméra. Ça devrait marcher.
Donc je vous propose de commencer. Le sujet de ce webinar, c'est la réussite de l'intégration de la sécurité dans les projets. C'est-à-dire, comment réussir à diffuser la sécurité auprès des métiers, dans les filiales, dans les organisations, pour que le RSSI soit vrai chef d'orchestre.
et que la sécurité arrive au plus près des nouveaux projets et de la digitalisation des entreprises. On va commencer par les enjeux problématiques, on va parler un petit peu de l'ISP et comment digitaliser, comment apporter, quels sont les retours d'expérience des bonnes pratiques sur ce sujet. On vous propose de commencer tout de suite par un sondage qui est à votre droite.
Avez-vous mis en place un processus d'intégration de la sécurité dans les projets ? oui ou non, et quelles sont les problématiques que vous avez rencontrées pour mettre en place ce processus. On vous laisse répondre.
Pour un petit rappel sur Digitemis, Digitemis, c'est à la fois l'alliance d'une expertise... Donc en cybersécurité technique, tout ce qui est offensif, également tout ce qui est organisation de la cybersécurité, processus. et tout ce qu'on appellerait défensif, mis en place de chartes, d'analyse de risques. On a également une équipe de juristes et en parallèle, on a développé une solution logicielle, on est éditeur, qui s'appelle Make it safe et qui permet d'accompagner le RSSI dans le pilotage de ses risques et de sa conformité et d'avoir des indicateurs de suivi de la cybersécurité.
Donc on est qualifié par l'ANSI comme prestataire d'audit de confiance. avec différents labels. Aujourd'hui c'est une cinquantaine de collaborateurs avec un bureau sur Paris, sur Nantes et en Vendée avec un nombre assez impressionnant de projets, plus de 300 projets délivrés cette année et puis à la fois des PME UTI et des grands comptes internationaux. Notre solution Make It Safe, l'idée c'est qu'elle couvre l'ensemble du périmètre de la gouvernance de la cybersécurité, à la fois sous les enjeux de risque et de conformité, donc à la fois les filiales, les fournisseurs, la gestion des audits et des contrôles, l'intégration de la sécurité dans les projets, on en parlera tout à l'heure, les analyses de risque, la digitalisation des plans d'assurance sécurité, et puis le suivi dans le temps des remédiations, des plans d'action collaboratifs.
L'idée c'est que la plupart des processus, on puisse les rendre collaboratifs, qu'ils puissent être efficients. et qu'on puisse avoir des indicateurs qui sont souvent absents. Donc voilà, cette solution vient en support de transformation du métier de RSSI pour le faire entrer dans une ère beaucoup plus performante. Merci Ludovic. Donc moi, je suis Victor Mallet, je suis consultant GRC, gouvernance risque conformité en cybersécurité, et j'assure le rôle de RSSI pour un certain nombre de nos clients.
Suite au premier sondage qu'on vous a proposé via l'outil, vous avez été 53%, donc 10 personnes qui ont répondu que vous ayant mis en place un processus d'ISP, et 47% n'ayant pas mis en place ce processus-là. On va commencer par introduire pourquoi c'est important de mettre en place un processus d'ISP. Quels sont les enjeux et quelles sont les grandes problématiques que vous pouvez rencontrer ?
dans le cadre de la mise en œuvre d'un tel processus. Pour revenir à la base, c'est-à-dire à la fonction, la mission, la mission première du RSSI, c'est quoi ? C'est simplement de maîtriser et réduire les risques de cybersécurité auxquels dispose son organisation, son entreprise.
Et donc, pour maîtriser et réduire ces risques, le RSSI, qu'est-ce qu'il va faire ? Il va mettre en place des règles. au sein d'une politique.
Donc il va être dicté un certain nombre de règles de sécurité qui vont toucher un certain nombre de domaines, que ce soit la sécurité physique comme la sécurité logique, la gestion des fournisseurs, la gestion de la conformité. Donc on va retrouver toutes les thématiques de sécurité qu'on retrouve dans l'ISO 27001 et ISO 27002 pour ceux qui la connaissent. Donc la sécurité ça touche vraiment toute l'organisation et à la fois l'humain, l'organisation et le technique. Et une fois que le RSSI a mis en place ces règles, il va avoir besoin de mettre en place du contrôle et de la vérification et qui va pouvoir piloter à travers notamment des indicateurs, des KPIs.
Et donc parmi ces règles qui va être dictées, un sujet important à prendre en compte dans le cadre de sa gouvernance, c'est les projets et comment chaque nouveau projet, un RSSI va mettre en place de la sécurité. Alors pourquoi mettre de la sécurité dans les projets ? L'objectif est simple, c'est de prévenir les risques informatiques.
On l'a vu au début, mais là c'est prévenir les risques informatiques qui sont ennuyés par chaque nouveau projet. Quand vous mettez en place, quand vous intégrez une nouvelle solution, que ce soit une nouvelle solution technique, une nouvelle solution métier, vous introduisez naturellement de nouvelles vulnérabilités et de nouveaux risques, notamment des risques métiers, le risque de fuite de données, le risque d'indisponibilité du service. Donc vous...
un nouveau projet va induire forcément de nouveaux risques. Et le second objectif, c'est faire adhérer toute l'entreprise. C'est-à-dire qu'aujourd'hui, la sécurité, c'est l'affaire de tout le monde. C'est l'affaire de la sécurité, l'usage de sa boîte mail, mais aussi à chaque nouveau projet, chaque nouveau porteur de projet doit prendre en compte la sécurité et appliquer les règles de la PSSI qu'aura édicté le RSSI dans sa PSSI. Je me répète un peu.
Donc voilà les deux grands objectifs. Et quels sont les enjeux ? Donc, vous faites des objectifs. Le premier enjeu, c'est l'ensemble, c'est tous les projets à... à prendre en compte.
Donc il y a de plus en plus de projets, aujourd'hui on a une digitalisation qui est de plus en plus prégnante au sein des organisations, donc l'enjeu c'est vraiment de capter tous ces projets. Le second enjeu, c'est qu'aujourd'hui les organisations sont plus ou moins matures au niveau de leur processus, que ce soit les processus projet, processus RH, processus d'exploitation informatique, donc l'enjeu du RSSI, c'est vraiment de s'intégrer au sein de cette organisation et de ses processus. Et enfin le troisième enjeu, C'est les ressources et l'expertise qui souvent peuvent manquer au sein d'une organisation pour pouvoir adresser l'ensemble des sujets et accompagner l'ensemble des projets.
Suite au sondage numéro 2, quelles sont les problématiques que vous rencontrez le plus souvent pour mettre en place de l'ISP ? Vous avez répondu à 38%, la majorité c'est la contrainte de temps. Ensuite, le manque d'adhésion des parties prenantes et problème de budget, c'est 0%. On a les deux raisons principales qui sont le temps et faire adhérer l'ensemble des parties prenantes.
On va voir comment, de manière assez simple et de manière pragmatique, on peut facilement venir répondre à ces contraintes-là et venir résoudre ces contraintes. Donc l'ISP, l'objectif des prochaines slides, c'est un peu de théoriser ce que l'ISP est, et comment de manière assez simple, on peut l'intégrer à une organisation. Donc si on schématise un peu un processus projet, un projet c'est assez simple, c'est un début et ça a une fin. Et l'objectif c'est vraiment de fournir un produit pour un besoin métier.
Donc on va avoir une première phase qui est l'étude de faisabilité, puis l'expression de besoin. Ensuite, ça va être décliné en spécifications techniques et fonctionnelles. Ces spécifications techniques et fonctionnelles réalisées, on va voir la phase de réalisation et développement du projet. Puis la validation du projet, est-ce que les spécifications ont bien été respectées ?
Et ensuite on a la mise en production et l'exploitation. Voilà, c'est cet exemple de projet. Aujourd'hui on a de plus en plus d'entreprises qui adoptent l'agilité dans leurs projets.
Ce processus-là, on peut très bien le calquer sur un modèle agile. la notion de sprint et de mise en production sous un modèle DevOps. Et pour supporter ces processus, on a des acteurs, on a une organisation, donc on a des acteurs des ressources humaines.
Donc en amont, on va avoir forcément le métier et la maîtrise d'ouvrage qui vont exprimer les besoins. L'explication, c'est plus du ressort de la maîtrise d'ouvrage qui connaît à la fois le métier et qui connaît aussi à la fois l'informatique et la maîtrise d'œuvre qui connaît très bien l'informatique. La phase de développement...
qui est purement technique, donc plutôt la maîtrise d'oeuvre, la validation du projet, donc à la fois maîtrise d'ouvrage et maîtrise d'oeuvre, pour la validation fonctionnelle et la validation technique, et enfin l'ingénieur de production sera en charge d'installer la solution développée et de maintenir dans le temps la sécurité et l'exploitation de la solution. Et en fait l'ISP c'est un processus qui va venir se greffer à ce qui existe, à ce qui est en place, ce qui est plus ou moins mis en place suivant les organisations. Mais l'objectif du ISP, c'est vraiment de venir se calquer, se greffer à ce process-là.
Donc, si on reprend ces cinq phases, et si on décide d'y intégrer une étape liée à la sécurité, on va retrouver, durant l'étude de faisabilité et d'expression de besoin, la qualification de la criticité. Ensuite, lors des spécifications techniques et fonctionnelles, on va devoir faire des choix de sécurité en fonction de l'expression de besoin de sécurité. Donc ça, c'est la phase numéro 2. La phase numéro 3, ça va être l'intégration des mesures de sécurité, donc la phase de développement, qui va venir mettre en œuvre ce qui a été défini dans la phase numéro 2. La phase numéro 4 va venir valider ce qui a été mis en place dans la phase numéro 3 et choisie dans la phase numéro 2. Et enfin, la phase numéro 5, qui est la phase qui est souvent oubliée, c'est le passage dans les opérations.
C'est vraiment prise en compte de la sécurité. Une fois que le projet est terminé, qu'on passe le fruit du projet aux opérations. prendre en compte la sécurité tout au long de la vie de la solution. Donc si on revient étape par étape, la première étape, comme je l'ai dit, c'est l'évaluation de la criticité. La criticité, très souvent, c'est un questionnaire assez simple qui est...
On répond à des questions sur la nature des données qui vont être traitées. Est-ce qu'on va traiter sur des données sensibles, des données à caractère personnel, des données stratégiques ? Est-ce que ça va être un projet d'externalisation ? Est-ce qu'on va faire appel à une solution SaaS qui est fournie clé en main par un fournisseur qui a développé la solution ?
Donc ça, ça va permettre d'identifier ce qu'on appelle le shadow IT. Là où très souvent c'est le nerf de la guerre pour les RSSI, c'est-à-dire qu'aujourd'hui il y a beaucoup de métiers dans des organisations qui achètent leurs solutions SaaS. Aujourd'hui, comme on l'a dit, il y a un process de digitalisation.
Beaucoup de startups se lancent sur des projets spécifiques. sur des projets métiers. Donc l'enjeu aussi de cette première phase, c'est de capter tous les projets et de les passer au TAMI afin d'identifier les projets les plus sensibles et les plus critiques pour l'entreprise. Donc c'est vraiment la première phase qui doit être une phase très simple à partir de 5, 6, 7 questions, de qualifier la sensibilité du projet.
Et derrière, en fonction de la sensibilité du projet, ça va permettre aussi d'identifier en termes de ressources, quelles ressources on va mettre en place. Est-ce qu'on a besoin... vraiment d'un accompagnement à pousser de la filière sécurité, ou alors les métiers, l'ensemble du projet peut directement gérer à partir de ce qui était établi en matière de règles et en matière de PSSI, peut directement s'auto-gérer en termes d'intégration de la sécurité dans les projets. Une fois qu'on a évalué la criticité du projet, en phase numéro 2, on va exprimer les besoins. Pour un projet donné, on va avoir des besoins de sécurité.
Les besoins, c'est quoi ? C'est la disponibilité. Est-ce que l'interruption de 24 heures, de 48 heures d'une semaine est acceptable pour la solution qui sera développée ? L'intégrité. Est-ce que si on a une perte de données, est-ce qu'on peut la corriger de manière dans les 4 heures, dans les 24 heures ?
Ou alors, la donnée doit être intègre tout au long, en continu dans le projet. La confidentialité. Qui a le droit d'en connaître ?
Est-ce que c'est une donnée publique, une donnée interne à l'organisation ? ou alors c'est une donnée stratégique qui doit être restreinte à un certain nombre limité de personnes. La traçabilité, enfin, quel est le niveau de traçabilité dont on a besoin ?
Est-ce qu'on a besoin juste à des fins statistiques, ou alors on doit vraiment tracer de manière très fine les opérations et tout ce qui est fait au sein de l'application. On peut aussi exprimer des besoins en termes de PRA, donc plan de reprise d'activité, donc là on a plutôt sur la notion de sinistre, est-ce qu'on a un sinistre, est-ce que l'application, elle est... à les critiques à redémarrer.
On va définir des valeurs telles que le DIMA ou le PDMA, qui sont vraiment la durée d'interruption maximale autorisée et la perte de données maximale autorisée. On peut aussi exprimer les besoins en termes de RGPD. Est-ce qu'on va traiter des données à caractère personnel ?
Est-ce que c'est un traitement de volume de masse ? Est-ce que c'est un traitement sur des données très sensibles au sens de l'acnyl ? On va identifier tous ces sujets-là. Cette expression de besoin doit s'appuyer forcément sur une échelle, dans l'idéal, une échelle préétablie qui permette à chacun, à partir d'éléments factuels, de définir le besoin de sécurité pour son projet. Et à partir de ces besoins, l'idéal, c'est de calquer, c'est de venir coller des mesures de sécurité qui sont prédéfinies au sein des référentiels.
et qui vont permettre de répondre à un besoin de disponibilité élevé ou un besoin de confidentialité faible. On va mettre en place un référentiel de mesures de sécurité qui va venir se coller directement aux besoins identifiés. Une fois qu'on a identifié les mesures au regard des besoins de sécurité, il y a le passage dans la gestion de projet, donc la mise en œuvre des mesures qui doit s'intégrer dans le plan d'action du projet.
en plus des spécifications techniques et fonctionnelles déjà établies dans le cadre de la réalisation du projet. Donc on va venir insérer ces mesures de sécurité, et qui vont faire le choix de solutions techniques et ou organisationnelles. On peut à la fois mettre en place des solutions d'authentification forte, de chiffrement des flux, donc des solutions techniques, mais aussi des procédures organisationnelles, telles que de l'externalisation de sauvegarde, telles que du contrôle des accès, la revue des habilitations, etc. Et forcément, ces mesures, comme tout projet, comme tout projet a des contraintes budgétaires et de planning, et bien ces mesures peuvent faire l'objet d'un arbitrage avec tout l'ensemble des parties prenantes et dont le RSSI, qui est garant de la sécurité. Donc ces mesures peuvent faire l'objet d'un arbitrage en fonction du coût et de la complexité de mise en œuvre.
Donc une fois qu'on a mis en œuvre toutes ces mesures, on a... ce qu'on appelle la recette sécurité, donc c'est vraiment la validation de ce qui a été mis en œuvre. Est-ce qu'on a bien respecté le cahier des charges et est-ce qu'on a bien pris en compte les mesures qui ont été choisies dans la phase numéro 2 ? Donc c'est à la fois le contrôle et c'est aussi l'occasion de faire des audits techniques sur la solution produite et développée.
Donc on parle de thèse d'intrusion, d'audit de code, de thèse de charge. Donc en fonction du projet qui est développé et des besoins, on va auditer techniquement la solution. Et enfin, pour terminer, cette recette, c'est une phase de validation obligatoire avant le passage aux opérations, qui est souvent le passage...
La phase qui est oubliée dans le cadre de l'intégration de la sécurité dans les projets, mais qui est très importante parce qu'il y a la phase projet et la phase de développement, mais après il y a toute la phase de run, toute la vie de la solution. Et c'est là où les risques vont être mis en lumière. Donc il faut vraiment que la sécurité soit maintenue tout au long de la vie du projet réalisé.
Et donc la nouvelle solution doit s'intégrer dans les processus existants, s'ils existent forcément. Donc on va parler de la gestion des actifs, donc il faut référencer effectivement la nouvelle application développée, la gestion des vulnérabilités, la gestion des accès, tout ça dans le cadre de ce qu'on appelle le MCO-MCS, donc maintien en condition opérationnelle et maintien en condition de sécurité. Et pour finir, forcément l'utilisation doit aussi être documentée et communiquée aux parties prenantes.
Dans le cadre d'une organisation qui est pérenne, on a vraiment des process et une architecture technique qui est documentée. et communiquer à l'ensemble des parties intéressées. Voilà maintenant on vous propose, maintenant qu'on a vu la description du processus et sa justification, l'idée c'est d'avoir un processus qui fonctionne et nous notre conviction c'est que ce processus doit être outillé pour simplement réussir à embarquer les métiers, pour simplement réussir à centraliser les échanges et puis gagner en performance. Donc la clé, on parlait tout à l'heure des très nombreux projets, pourquoi les projets sont nombreux ? Parce que les entreprises se digitalisent.
Une chose qui est vraiment importante c'est d'homogénéiser les pratiques. Pourquoi ? Globalement le meilleur allié du RSSI et de la cybersécurité c'est la standardisation. Donc il faut homogénéiser les pratiques et en cela un outil est vraiment le meilleur allié du RSSI pour réussir à diffuser le process.
et qu'il soit standardisé. Les ressources en cybersécurité sont limitées, on le sait, on le répète, et évidemment, le coût de la sécurité est moindre s'il est pris à l'origine des projets, plutôt qu'en aval, une fois que les projets, les solutions, sont mises en condition opérationnelle et qu'on rajoute de la sécurité a posteriori. Donc vraiment, c'est important d'intégrer ça au début. pour réduire les budgets de sécurité, parce que globalement, une mesure de sécurité prise en compte à la conception d'un projet va coûter beaucoup moins cher qu'une mesure de sécurité déployée a posteriori.
Donc l'intérêt de l'outillage, c'est aussi de pouvoir valider chaque phase que Victor a expliquée de façon collaborative, en impliquant les métiers, je dirais même plus, en les embarquant, en animant tout un écosystème, toute une communauté. Et ça vraiment c'est quelque chose qui va être un facteur clé de succès, de pouvoir réussir à faire ça, d'embarquer tous ces relais. L'idée c'est de faire gagner du temps à tout le monde, on parlait de faire gagner du temps à la cybersécurité en centrale, mais également aux personnes des métiers. Si on leur propose des mesures de sécurité de façon automatique, si on leur fait gagner du temps sur le process, évidemment ils seront beaucoup plus à même de s'impliquer et de collaborer dans ce processus de sécurisation de l'écosystème. Voilà, donc un exemple de périmètre de l'intégration de la cybersécurité dans les projets, il y a évidemment le périmètre interne qui correspond au projet interne, également le périmètre externe.
L'idée c'est qu'on puisse avoir une vision des deux, à la fois si on veut filtrer sur l'implication par exemple des fournisseurs ou des projets qui correspondent uniquement à certaines filiales ou à certains services. au sein d'un groupe, au sein d'une BU, au sein d'une entité. Après, ce qui est intéressant, c'est de pouvoir avoir une vision globale de tous les projets, tous les projets dans une BU, dans une filiale, tous les projets qui correspondent aux applicatifs, à certains actifs du groupe, par exemple l'ensemble des applications, l'ensemble des applications en mode SaaS, et ensuite de pouvoir faire des filtrages. Filtrages, je disais, sur les projets internes, filtrages sur les projets externes, filtrages aussi sur différents types d'actifs ou différents types.
de projet. Donc ça c'est évidemment assez pertinent et ensuite de pouvoir avec cette vision globale suivre des indicateurs pertinents pour les piloter. Ensuite ce qui est important c'est évidemment on parlait de standardisation tout à l'heure qui est vraiment une clé en sécurité. La standardisation ça va vraiment être l'objectif d'avoir une homogénéisation du suivi des projets. Donc de suivre évidemment les différents états des projets, selon les étapes que Victor a proposées.
Évidemment, les étapes, il peut y en avoir quatre, il peut y en avoir cinq, il peut y en avoir six, tout dépend du processus qu'on veut mettre en place. Mais derrière, en tout cas, on peut avoir un filtrage par état, qui est efficace et homogène, qui permet de suivre tous les projets qui sont en phase d'analyse préliminaire, par exemple, ou tous les projets qui sont archivés, tous les projets qui sont en... en phase opérationnelle ou en phase de recette par exemple. Donc ça c'est quand même assez pertinent d'avoir cette vision-là.
Aujourd'hui, il y a assez peu de groupes qui l'ont, on est souvent dans du bricolage. Après, on peut retrouver évidemment tous les critères de sécurité, DICT, et là aussi faire un filtrage, une classification par critère de sécurité. Et selon ces critères, on peut aussi pondérer la classification avec les couleurs de chaque projet. Les critères dont la criticité sont les plus basses peuvent avoir une couleur particulière et ceux qui ont les plus hautes peuvent tout de suite ressortir. L'intérêt, c'est vraiment de pouvoir piloter rapidement et de répartir les critères entre ceux qui sont le plus présents.
Est-ce qu'on a plus de rouge, plus de vert ? Et ensuite, de pouvoir filtrer. C'est l'intérêt de l'outil par rapport à ce qui se fait habituellement.
Évidemment, ce qui est intéressant dans cet outillage, c'est qu'on parlait tout à l'heure d'embarquer les métiers, on peut pousser du contenu pour les sensibiliser. Vraiment, c'est la partie initiale qui est très importante, notamment du contenu vidéo, du contenu pour expliquer le processus, les différentes phases, ce qu'on attend d'eux, à quelles étapes, quel est le rôle entre le RSSI d'une branche, un chef de projet et puis le RSSI d'un groupe, qui valide quoi ? L'idée, c'est quand même de...
de pouvoir diffuser des vidéos explicatives simples. Donc ça aussi, évidemment, c'est possible. L'idée, c'est vraiment de rendre ce côté cybersécurité qui n'est pas leur quotidien, quelque chose de facilement accessible, facilement compréhensible par ces métiers.
Donc, cette interface d'évaluation de Make It Safe permet vraiment d'engager ces opérationnels pour répondre aux questions essentielles. Et l'idée, c'est vraiment... d'avoir une implication maximale des métiers. Et là, on a vraiment des résultats. Tout comme quand on veut impliquer des fournisseurs, par exemple, qui sont dans des projets, on constate des pourcentages d'implication voisins de 100%.
Alors qu'habituellement, on sait bien, on envoie des mails, on n'a pas de réponse. On a des fichiers qui ne sont pas complets. On a énormément d'échanges. L'idée d'avoir cette interface, ça permet quand même de simplifier tous ces échanges et d'engager même ces parties prenantes.
Donc évidemment dans la solution on peut modéliser tout ce qu'est analyse de risque. Donc on commence par des évaluations à travers des questions, des questions fermées, on voit bien, et on peut ajouter évidemment des éléments de preuve. Donc une personne peut ajouter des cahiers des charges, des choses qui vont correspondre au projet.
Et puis l'interface va être évolutive. Selon ce que... le chef de projet ou le responsable applicatif ou le responsable architecture va entrer comme élément ou comme réponse, on va pouvoir de façon dynamique proposer des référentiels conditionnels, donc dynamiques, qui là sont un vrai avantage aussi de la solution. Après, autre chose clé, évidemment, on peut accéder directement à l'ensemble des questions plutôt que de les avoir une à une. Et après, on peut évidemment faire des filtrages.
par statut sur ces différentes analyses de risques, par exemple préliminaires, c'est ce qu'on voit à l'écran, ou bien on peut les regrouper par domaine, ce que j'expliquais tout à l'heure. Donc tout ça, selon les étapes, on peut avoir une certaine flexibilité. Ensuite, l'intérêt c'est pour chacune des phases, On peut rassembler toutes les informations et valider séparément la sécurité de chaque étape.
Donc là, c'est vraiment l'idée de séquencer, d'avoir une démarche itérative pour chacune des phases. Victor en a proposé cinq, mais globalement, l'idée, c'est de pouvoir temporaliser le projet pour chacune des phases, bien identifier tous les éléments de la phase, les rassembler au même endroit et de façon dynamique et collaborative. Après, évidemment, ce qui est intéressant, c'est tout ce qui est autour des mesures de sécurité. Donc autour des mesures de sécurité, elles vont pouvoir être générées automatiquement à partir d'une base de connaissances qui peut être enrichie, une base de connaissances qui peut être complétée aussi par le chef de projet s'il y a des mesures de sécurité spécifiques. Et là, derrière, du coup, ça fait aussi gagner du temps parce qu'on va pouvoir être force de proposition et suggérer des mesures de sécurité et même peut-être un chef de projet pour les projets, par exemple, non critiques.
on n'aura pas besoin de solliciter un RSSI en centrale puisque finalement dans certains cas, on a des mesures de sécurité qui vont être imposées de par la PSSI et qui vont être assez standards et qui vont être suggérées au chef de projet. Donc ça va beaucoup l'aider dans son quotidien et dans la phase initiale du projet. Ensuite évidemment, par rapport aux mesures, on peut avoir des filtrages de mesures de sécurité, on peut avoir un listing complet de toutes les mesures de sécurité proposées et acceptées pour ce projet. En fonction du statut aussi, est-ce que les mesures sont... proposées, est-ce qu'elles sont implémentées, est-ce que c'est en cours d'implémentation, et puis quel est l'avancement du coup de cette mise en sécurisation du projet, et quel est en termes de délai, en termes d'avancement, de mise en oeuvre de ces mesures, et qui, une suite répartition des rôles, qui doit faire quoi dans la mise en place de ces mesures, entre le responsable d'une application, le responsable technique, mettons, des développements, etc., etc., donc c'est vraiment pertinent de pouvoir allouer les mesures de sécurité aux différentes personnes et de suivre ensuite de façon collaborative et structurante l'avancée de la mise en oeuvre de ces mesures.
Evidemment le pilotage peut être en temps réel donc ça c'est un vrai atout puisque du coup comme c'est collaboratif chacun va pouvoir déclarer, remplir je dirais les éléments qui le concernent, est-ce qu'il a mis en oeuvre ou pas la sécurité, est-ce qu'il est passé, est-ce qu'il a validé une des étapes de l'ISP. Est-ce que globalement il a réussi à réduire le risque ? Est-ce que la recette a été mise en place ?
Toutes les parties prenantes peuvent suivre en temps réel. On peut aussi avoir des cloisonnements en termes de vue des informations. Peut-être que le RSSI peut avoir accès à tout.
Et puis évidemment, le responsable d'une application n'a accès qu'à ses applications où il est propriétaire de l'application, par exemple. Voilà pour la vision digitale du process des sécurités. Je laisse la parole à Victor pour une synthèse des bonnes pratiques. Pour conclure, une intégration de la sécurité dans les projets réussis, c'est à la fois une méthode et un investissement. Et ça fait écho directement au résultat du sondage numéro 2. C'est-à-dire qu'une méthodologie, ça va venir répondre à la contrainte de temps.
Aujourd'hui, il y a de plus en plus de projets, il y a de plus en plus de... d'activité, donc il faut vraiment optimiser la méthodologie. Et le deuxième point, c'est l'investissement des différents acteurs. Et donc ça fait écho directement aussi à la deuxième raison pour laquelle vous avez répondu au sondage numéro 2, c'est le manque d'adhésion des parties prenantes. Donc là, concrètement, la conclusion, c'est vraiment mettre en place une solution, une méthode O, et aussi un référentiel et standardiser les mesures.
à répéter à plusieurs reprises Ludovic, c'est important, pour un RSSI, il aura des standards, plus ce sera facile pour lui de piloter et d'appliquer ces mesures de sécurité. L'objectif, c'est vraiment d'adopter une mythologie pragmatique outillée en s'appuyant sur un référentiel de mesures de standards, tout ce que vient de présenter Ludovic. Avec pour bénéfice l'optimisation des ressources, l'adhésion du processus et la centralisation des projets au sein d'un même outil.
Et à partir de ça, l'ERSI va pouvoir piloter l'ensemble des projets et garantir un niveau de sécurité homogène dans l'évolution de son RSI. On a vu aussi bien pour des entreprises de taille intermédiaire que des grands groupes, un gain de temps et un gain de performance qui est assez intéressant, de l'ordre de 50% par rapport au temps passé dans les allers-retours ou par rapport à des sujets de projet de shadow IT qui n'étaient pas du tout faits. Maintenant, on vous propose, comme c'est Noël, on vous propose un rendez-vous conseil gratuit de 30 minutes avec un de nos experts.
Vous pouvez solliciter un rendez-vous à la fin de ce webinaire. On vous propose également de télécharger le support. On va répondre maintenant à quelques questions. Il y en a déjà qui ont été posées. Donc, vous avez l'affichage pour prendre un rendez-vous conseil.
On vous propose gratuitement un rendez-vous de 30 minutes avec un expert par rapport à votre process ISP, par rapport éventuellement à l'idée d'avancer jusqu'à une digitalisation de ces process. Donc, première question, c'était est-ce que la solution peut être on-premise ? Oui, elle peut être on-premise, elle peut être en SaaS mutualisé, elle peut être en SaaS dédié, elle peut être en SaaS avec un hébergement Sektum Cloud, par exemple. possibilités d'hébergement après évidemment si on veut quelque chose de collaboratif si on veut du on-premise ça va rester peut-être dans l'univers interne d'un groupe.
Si on veut l'ouvrir avec des parties prenantes externes, on recommandera quand même d'être sur des environnements évidemment ouverts vers l'extérieur. Autre question, comment délimiter les éléments à recéder par les équipes de sécurité et ceux attestés par les équipes de recette générale ? Alors souvent, ça va être autour du process de criticité des projets où il va y avoir différents critères qui vont faire que l'équipe en centrale va suivre de près 30 ou 40% des projets les plus critiques. On a des exemples, quand il y a des données personnelles, des traitements de données personnelles, ça remonte au DPO d'une entité ou au DPO d'un groupe. Quand on est sur des applications assez standards, par exemple développées en interne et qu'il y a déjà des process bien huilés, et que la politique de sécurité est appliquée, on n'a pas forcément besoin d'un arbitrage.
Quand on a des projets souvent exotiques, On va pouvoir remonter ça aux équipes sécurité par exemple. Donc là, il faut en préalable, c'est ce que disait Victor, déterminer des critères qui vont finalement formaliser le process. Est-ce qu'on donne une subsidiarité, une délégation de pouvoir pour des petits projets en fonction de montant, en fonction de l'analyse de risque préliminaire, ou globalement, comme l'équipe sécurité n'a pas beaucoup de temps, on accepte, je dirais, que le sujet d'intégration de la sécurité dans les projets soit géré.
dans une filiale, soit gérée dans une équipe. Tout à fait. Et là, en l'occurrence, la recette, ça peut être effectué par l'équipe directement, l'équipe projet.
Tout dépend de votre organisation et de votre capacité à faire, de votre filière sécurité. Mais l'essentiel, c'est vraiment de tracer tout ce qui a été fait en matière d'ISP, d'enregistrer, de tracer, et de pouvoir revenir en arrière si jamais il y a un problème, de savoir ce qui a été fait en matière de sécurité. Et c'est là tout l'enjeu d'un outil centralisé, c'est que ça permet d'avoir cette traçabilité. Peu importe l'acteur, que ce soit un acteur sécurité ou un acteur plutôt généraliste en termes d'informatique, il faut être en capacité de prendre en compte l'ensemble des étapes, recettes y compris, et qu'elles soient réalisées.
Après, on a une question, une contrainte qu'on rencontre, c'est que des projets peuvent être très divers, plus ou moins techniques, plus ou moins fonctionnels. En effet, du coup, on va avoir un certain nombre de correspondants. On peut avoir des correspondants techniques sur l'architecture, par exemple.
sur la partie sécurité des développements, et puis des correspondants plus fonctionnels, qui vont être plus, par exemple, je parlais de la gouvernance de la privacité, et donc en effet, selon les fameux critères de l'analyse préliminaire, selon le processus, on va pouvoir solliciter les différents interlocuteurs. Il y a certains grands groupes, il y a des projets qui vont passer systématiquement par les mains d'un responsable de la conception de l'architecture. Par exemple, dès qu'on est... avec un fournisseur sur une solution, on va dire sur des environnements dédiés, connectés au réseau, on va avoir certaines implications qui vont devoir valider cette architecture.
Autre question, quel est le bon niveau des détails à prendre en compte, sachant que le nombre de technologies devient pléthorique, en effet, et que le temps joue contre nous ? Je pense que dans un premier temps, il faut définir des règles de haut niveau. Ça ne sert à rien de rentrer dans le détail de chaque technologie, sachant que ces technologies effectivement évoluent de manière exponentielle, mais il faut dans un premier temps définir les règles, les règles génériques de sécurité, et petit à petit rentrer dans le détail en fonction de votre écosystème, en fonction des technologies que vous installez, et à partir de l'expertise que vous développez, adapter le référentiel de sécurité qui est standard, qui doit être le plus haut niveau possible.
et le décliner technologie par technologie. Ça doit être de l'amélioration continue. Vous ne pouvez pas, comme ça, de prime abord, avoir des règles de sécurité technologie par technologie.
Il faut, dans un premier temps, avoir un socle de base qui définisse les grandes règles. Et ensuite, en fonction de votre évolution, de votre système de formation, ça va venir s'enrichir en amélioration continue. Il y a une autre question sur la définition des étapes du projet. Est-ce qu'elle est paramétrable au lieu égard au procès ? processus de l'entreprise avec notamment par exemple l'étape initiale du contrat donc oui en effet c'est paramétrable qu'on soit sur trois sur cinq sur sept sur neuf étapes il n'y a pas de souci pour le paramétrer dans la solution l'idée de la solution c'est qu'elle puisse digitaliser le processus que vous avez défini après l'idée c'est qu'en effet ce processus d'ISP puisse être connecté avec ce que je présentais au début les processus de plan d'assurance sécurité C'est là qu'on rejoint ce que vous avez mentionné avec l'étape contrat, l'étape contrat auquel on rajouterait l'étape plan d'assurance sécurité, voire les clauses contractuelles, par exemple sur les données personnelles, qui peuvent être à l'origine dans l'analyse préliminaire, comme des données en entrée.
C'est comme différents SAS qui se succèdent. On aura le plan d'assurance sécurité, les clauses, et ensuite on arrive sur l'intégration de la sécurité dans les projets. Les choses sont cohérentes et on va intégrer évidemment les filiales, les fournisseurs, les services, de cette façon collaborative, pour qu'il y ait une cohérence, c'est vraiment le maître mot, et qu'on puisse embarquer tout le monde, pour, je dirais, dès l'origine de toutes ces choses-là, le contrat et le projet, intégrer la sécurité, et garantir une réduction des coûts de sécurité, et surtout des bonnes pratiques dès le début.
Alors, je crois qu'il y a d'autres questions. Alors, pour un même projet, peut-on avoir deux volets, ISP d'un côté et RGPD de l'autre, qui vont avoir des étapes différentes ? Tout à fait, notamment dans l'outil.
C'est-à-dire que si dès le début, on a un critère qui est la conformité RGPD avec la présence ou pas des données personnelles, derrière, soit on a un seul processus qui va combiner les deux, Soit on va pouvoir, avec un arbre de décision, aller soit d'un côté ISP avec des interlocuteurs côté sécurité, et de l'autre côté un arbre qui va aller sur de la conformité, et là avoir des interlocuteurs sur la partie RGPD. Nous, on propose quand même d'avoir une vision cohérente, souvent on va être sur des choses, on va avoir un même projet, avec des enjeux de risque et des enjeux de conformité. Et l'idée, c'est quand même d'avoir une cohérence sur ces sujets-là, parce que les mesures de sécurité peuvent aider à gérer le risque et à garantir la conformité.
Et même, quand on parle RGPD, on va parler aussi de mesures de sécurité. Donc, on recommande quand même d'avoir un processus commun, cohérent, et en tout cas, on pousse les organisations à aller vers ça. C'est ce qui est le plus efficace, de mettre tout le monde autour de la table dans l'intégration et de la sécurité dans les projets. et dans l'intégration du Security by Design et du Privacy by Design. Est-ce que la solution vient déjà avec une liste de mesures de sécurité qui peut ensuite être complétée par client ou est-ce à ce dernier de les définir entièrement ?
On a évidemment à la fois des mesures de sécurité qui sont pré-remplies et également des étapes. Par défaut, on en propose cinq qui correspondent à ce qu'on voit le plus communément admis. Je crois que le Clusif aussi avait proposé cinq étapes. Donc par défaut, on va plutôt proposer sur étagère ce type de processus digitalisé. Après, une configuration pour modifier ces choses-là n'est pas très compliquée.
Est-ce que l'outil s'interface-t-il avec une CMDB pour tracer l'évolution des mesures revues qui ont été faites sur un même asset dans le temps ? Alors ça, je dirais que c'est envisageable avec une API. Après, tout dépend de quel CMDB, donc là c'est plus, il y a une phase de configuration et de projet pour bien se caler sur le suivi des assets de la CMDB.
Donc ça c'est envisageable, après c'est à voir évidemment quelles sont les informations à récolter ou à transmettre aux différentes solutions qui sont déjà en place. Après en termes d'interface, c'est souvent ça qui est le côté interface, c'est quand même un point fort. pour embarquer les métiers, pour la réussite de l'intégration de la sécurité dans les projets. Et parfois, il y a d'autres outils qu'on voit qui ne sont pas toujours aussi flexibles et pratiques d'utilisation.
Il nous reste encore une ou deux minutes pour une question, si c'est la dernière éventuellement. C'est le moment ou jamais. Alors oui, ceux qui souhaitent évidemment avoir des réponses personnalisées, c'est aussi l'intérêt du rendez-vous qu'on vous offre avec un expert, c'est de pouvoir répondre directement là où vous en êtes, et d'avoir des réponses beaucoup plus pertinentes. Alors je ne sais pas s'il y a d'autres questions, je vois si...
Écoutez, merci beaucoup en tout cas de votre participation. Excusez-nous de la petite difficulté sur la caméra, mais en tout cas, on était content de vous avoir partagé nos retours d'expérience. Et nous sommes à votre disposition de par les rendez-vous, de par nos coordonnées et puis le fait que vous pourrez télécharger le support.
Écoutez, on vous souhaite une bonne fin de journée. Bonne fin de journée à tout le monde. Au revoir.