Gestion de projet en cybersécurité : importance et meilleurs outils pour la gestion de projet

La gestion de projet en cybersécurité consiste à appliquer une gouvernance structurée (périmètre, calendrier, budget, risques, ressources et preuves) à la mise en œuvre des initiatives de sécurité. Elle permet de faire le lien entre les vulnérabilités découvertes par l'équipe de sécurité et les solutions concrètes (correction, gouvernance et validation auprès des auditeurs).

Il ne s'agit pas de la même chose que de sécuriser vos données de gestion de projet, même si cela a aussi son importance. Gérer un projet de cybersécurité implique d'exploiter les résultats des tests d'intrusion, des analyses de vulnérabilité, des audits GRC et des revues d'architecture, et de les transformer en tâches priorisées, planifiées, attribuées et documentées, livrées dans les délais et avec une obligation de rendre des comptes à chaque étape.

Un chef de projet en cybersécurité ne remplace pas un RSSI, un architecte de sécurité ni un testeur d'intrusion. Il constitue le pilier opérationnel qui garantit que chaque livrable spécialisé devienne un projet finalisé, documenté et clos.

La plupart des chefs de projet qui se spécialisent dans la sécurité constatent rapidement que les modèles de livraison classiques sont inadaptés. Dans un projet informatique traditionnel, « terminé » signifie que la fonctionnalité a été déployée et acceptée par les utilisateurs. Dans un projet de cybersécurité, « terminé » signifie que le contrôle est mis en œuvre, validé, documenté et que le risque résiduel a été formellement accepté par l'autorité compétente.

Le déploiement d'une règle de pare-feu sans validation, le déploiement d'une authentification multifacteur sans vérification de la couverture, ou l'application d'un correctif sans test de régression peuvent tous afficher un taux d'achèvement de 100 % sur un diagramme de Gantt sans pour autant améliorer la sécurité de l'organisation. Le rôle du chef de produit sécurité est d'assurer la continuité entre l'exécution des tâches et le résultat concret en matière de sécurité.

Le paysage des parties prenantes est également fondamentalement différent. Alors qu'un projet informatique standard implique un commanditaire, un groupe d'utilisateurs et une équipe informatique, un projet de sécurité implique le RSSI, les responsables des risques, les responsables de la conformité, le conseiller juridique, les auditeurs internes, les organismes de réglementation externes et souvent un comité des risques au niveau du conseil d'administration, chacun ayant des besoins d'information, des niveaux de tolérance au risque et des définitions du succès différents.

La conformité est rarement facultative. Dans les projets de sécurité, les demandes de modification doivent être évaluées non seulement en fonction de leur impact sur le calendrier et les coûts, mais aussi afin de déterminer si elles créent une nouvelle surface d'attaque ou modifient le niveau de risque. Le suivi post-projet ne s'arrête pas à la mise en production ; il se poursuit tant que le système de contrôle est utilisé. Ces différences exigent une approche de gestion délibérément différente, ce qui explique pourquoi les outils et processus conçus pour les déploiements informatiques standard s'avèrent souvent insuffisants.

Les programmes de sécurité échouent non pas par manque de connaissances des organisations sur les actions à entreprendre, mais parce que le travail n'est ni planifié, ni doté des ressources nécessaires, ni suivi, ni documenté avec suffisamment de rigueur pour aboutir.

Le respect des exigences réglementaires et de conformité est l'une des raisons les plus immédiates pour lesquelles la rigueur de la gestion de projet en sécurité est payante. Des référentiels tels que l'ISO/IEC 27001:2022, SOC 2 Type II, le NIST Cybersecurity Framework 2.0, PCI DSS 4.0, HIPAA et CMMC 2.0 exigent tous la mise en œuvre concrète de contrôles spécifiques dans des délais définis. Chaque exigence de contrôle constitue, en pratique, un élément de projet avec un responsable, une date d'échéance et une obligation de justification. Sans une gestion de projet structurée, les organisations manquent régulièrement les délais de remédiation, fournissent des justificatifs d'audit incomplets et se retrouvent confrontées aux mêmes constats d'audit en audit.

La sécurité intégrée dès la conception exige la présence d'un chef de projet dès la planification du programme, et non son intégration en cours de développement. Le cadre de développement logiciel sécurisé du NIST et l'annexe A de la norme ISO 27001 imposent tous deux l'identification précoce des exigences de sécurité. Un chef de projet sécurité garantit que la modélisation des menaces, l'analyse de l'architecture, les exigences de codage sécurisé et les contrôles de sécurité des mises en production sont des activités planifiées avec des responsables désignés, et non des éléments ajoutés a posteriori une fois le développement déjà en cours.

La coordination interfonctionnelle est le principal point faible des projets de sécurité. Les activités liées à la sécurité impliquent des équipes qui partagent rarement une même hiérarchie : ingénierie de sécurité, infrastructure, DevOps, conformité, juridique, achats et gestion des fournisseurs. Le chef de projet sécurité joue un rôle essentiel en traduisant les constats techniques en un langage opérationnel permettant aux dirigeants d'agir face aux risques, et en traduisant les exigences de gouvernance en tâches concrètes exécutables par les équipes d'ingénierie.

La préparation à un audit est le fruit direct d'une bonne gestion de projet. Les journaux de décisions, les registres d'approbation, les registres de preuves et les demandes de modification constituent la piste d'audit que les outils de sécurité autonomes ne peuvent fournir. Lorsqu'un auditeur demande pourquoi un contrôle particulier a été accepté comme risque résiduel, la réponse doit figurer dans un document formel horodaté, et non être reconstituée de mémoire ou à partir d'échanges de courriels.

La priorisation des ressources et des budgets dépend d'une visibilité globale du portefeuille, que seule une gestion de portefeuille structurée permet d'offrir. Les ingénieurs en sécurité sont rares. Les RSSI capables de démontrer, données à l'appui, quelles initiatives consomment des ressources et quel est le retour sur investissement en termes de réduction des risques sont bien mieux placés pour justifier les demandes de budget et d'effectifs.

Le chef de projet sécurité est responsable de la gouvernance de la mise en œuvre d'une ou plusieurs initiatives de sécurité. Il est important de bien comprendre ce rôle, car les organisations ont souvent tendance soit à le sous-dimensionner (en attendant d'un ingénieur sécurité qu'il gère également le projet), soit à le définir de manière erronée (en attendant du chef de projet qu'il prenne des décisions relatives aux risques qui relèvent du RSSI ou du responsable des risques).

La gestion du périmètre implique de définir les limites du projet de sécurité et, surtout, les critères d'acceptation en matière de sécurité, en collaboration avec le RSSI ou le responsable des risques. Il ne s'agit pas simplement de « déployer l'outil », mais de « déployer l'outil, de valider la couverture sur tous les terminaux de production et de produire un rapport final examiné par le responsable de la sécurité ».

La gestion des échéanciers dans un contexte de sécurité implique l'intégration de points de contrôle de sécurité dans le plan : des points d'examen formels où les critères d'acceptation de sécurité sont confirmés avant la poursuite du projet. Il ne s'agit pas d'étapes facultatives pouvant être raccourcies en cas de retard.

La gestion des risques implique la tenue à jour d'un registre des risques tout au long du projet, la facilitation de revues régulières des risques et le signalement des risques, acceptés ou non, à l'autorité compétente, accompagné des documents nécessaires. Le chef de projet ne prend pas les décisions d'acceptation des risques, mais il est responsable de s'assurer que ces décisions sont prises par la personne compétente et correctement consignées.

La gestion des preuves est souvent négligée dans la définition du rôle de chef de projet, alors qu'elle est essentielle à la réussite des programmes de sécurité. Le chef de projet doit veiller à ce que, pour chaque tâche accomplie, les preuves correspondantes soient collectées, examinées et archivées conformément aux exigences de conservation de l'organisation, et non pas considérées comme une simple formalité de clôture.

La communication de haut niveau dans les programmes de sécurité nécessite de traduire les données relatives aux risques et aux contrôles en formats exploitables par les conseils d'administration et les dirigeants : pourcentage de vulnérabilités critiques en retard, taux de conformité aux SLA de remédiation, ancienneté de l'acceptation des risques et taux de réussite des contrôles de sécurité, et non seulement le statut RAG et les pourcentages d'étapes clés.

Le chef de produit n'effectue pas de tests d'intrusion, ne réalise pas d'audits d'architecture, ne configure pas les contrôles de sécurité et ne prend pas de décisions relatives à l'acceptation des risques. Ces responsabilités incombent respectivement aux architectes de sécurité, aux ingénieurs, aux analystes, au RSSI et aux responsables des risques.

L'étendue des responsabilités d'un chef de produit sécurité est plus vaste que ce que la plupart des organisations imaginent. Les déploiements IAM et PAM impliquent une intégration multisystème complexe, une coordination étroite avec les fournisseurs et des exigences de gouvernance progressives s'étalant sur plusieurs mois. Les déploiements MFA, bien qu'inattendus, nécessitent une gestion du changement intensive : le suivi des exceptions et la vérification de l'adoption requièrent autant de rigueur de la part du chef de produit que du déploiement technique. Les programmes de correction des vulnérabilités consistent essentiellement en une gestion continue du backlog, avec obligation de respecter les SLA, analyse des régressions et dépendance aux cycles de publication des correctifs tiers.

La remédiation suite à un test d'intrusion est un type de projet souvent sous-estimé. Le test d'intrusion génère une liste de résultats, mais la transformation de cette liste en un projet de remédiation planifié, doté des ressources nécessaires et étayé par des preuves, incluant la coordination des nouveaux tests et une clôture formelle, représente un effort de gestion de projet conséquent.

La préparation à la norme SOC 2 et la mise en œuvre de la norme ISO 27001 sont des projets de conformité qui nécessitent une cartographie des contrôles et des preuves pour des dizaines, voire des centaines d'exigences, une coordination interfonctionnelle des responsables et une gestion de la communication avec les auditeurs. Les déploiements SIEM comportent des phases distinctes d'infrastructure, d'intégration et de mise en œuvre des cas d'utilisation, qui doivent être soigneusement séquencées. Les programmes Zero Trust sont des projets pluriannuels de grande envergure qui requièrent une planification des flux de travail couvrant les domaines de l'identité, du réseau, des périphériques et des données, avec d'importantes interdépendances.

Ces problématiques ont toutes en commun de nécessiter bien plus qu'un simple suivi des tâches. Elles requièrent une planification tenant compte des risques, une gouvernance des preuves, une gestion des dépendances, une responsabilisation interfonctionnelle et des rapports destinés à la direction ; c'est précisément là que Celoxis apporte une valeur ajoutée.

La plupart des programmes de sécurité disposent de cadres de gouvernance adéquats et d'outils techniques appropriés. Le problème réside dans la mise en œuvre rigoureuse de la transformation des résultats de la gouvernance en projets planifiés, dotés de ressources, documentés et clôturés. SECURE propose une structure en six étapes pour y parvenir.

S

Définir le périmètre du résultat en matière de sécurité

La première étape définit non seulement les livrables du projet, mais aussi le résultat de sécurité attendu. Cela implique de documenter l'objectif métier, l'objectif de sécurité, les systèmes et données concernés, le périmètre du projet et, surtout, les critères d'acceptation en matière de sécurité. Ces critères définissent le niveau de contrôle minimal requis pour considérer le projet comme « terminé » et doivent être validés par le RSSI ou le responsable des risques avant le début de la planification.

Document clé : Charte du projet de cybersécurité

Critère de sortie : Une charte approuvée par le sponsor, comportant des critères d’acceptation de sécurité explicites et une liste confirmée des actifs concernés.

E

Évaluer les risques et les obligations

Avant d'établir le planning, il est indispensable de cartographier le paysage des menaces. Cette étape permet d'identifier les menaces, les vulnérabilités, les obligations réglementaires, les lacunes en matière de contrôle, les dépendances vis-à-vis des tiers, les risques inhérents, les risques résiduels et l'appétit pour le risque de l'organisation. Les échéances réglementaires – audit de surveillance ISO 27001, période d'évaluation CMMC, analyse trimestrielle PCI DSS – doivent être confirmées et intégrées au planning de référence.

Document clé : Registre des risques

Critère de sortie : Un registre de référence comportant tous les risques élevés et critiques attribués à un propriétaire et un plan de traitement.

C

Convertir les contrôles en travail exécutable

C’est l’étape que la plupart des programmes de sécurité négligent. Les résultats du NIST, les contrôles de l’annexe A de la norme ISO 27001, les conclusions d’audit et les exigences d’architecture doivent être traduits en tâches concrètes, attribuées et planifiées, et non pas laissées à l’état de simples documents de gouvernance dans une plateforme GRC. Chaque contrôle correspond à une ou plusieurs tâches, chaque tâche a un responsable et une date d’échéance, et chaque tâche possède des critères d’acceptation et des exigences de preuve définis.

Élément clé : Matrice de contrôle et de travail

Critère de sortie : 100 % des contrôles requis associés à au moins un élément de travail planifié et dont vous êtes responsable.

U

Unir les propriétaires, les ressources et les dépendances

Les projets de sécurité échouent le plus souvent lors du transfert de responsabilités entre les équipes. Cette étape permet de confirmer les engagements et les capacités en matière de ressources pour la sécurité, l'ingénierie, l'infrastructure, le DevOps, la conformité, le juridique, les achats et les fournisseurs. Elle permet d'établir la cartographie intégrée des dépendances et de définir la procédure d'escalade avant même que les problèmes ne surviennent.

Élément clé : Carte des dépendances et matrice RACI

Critère de sortie : Tous les responsables des flux de travail ont été confirmés, le plan de ressources a été établi et la procédure d’escalade a été documentée.

R

Examiner en permanence les risques, les preuves et les mesures correctives

La livraison n'est pas une phase passive. Cette étape comprend des revues hebdomadaires des risques et de l'état d'avancement, le suivi de la conformité aux SLA de remédiation, la gestion des demandes de changement avec évaluation d'impact sur la sécurité, l'escalade des éléments en retard et la surveillance de la préparation aux contrôles de sécurité. Les preuves sont collectées au fur et à mesure de l'exécution des tâches, et non lors de leur clôture.

Documents clés : Registre des risques vivants et registre des preuves

Critère de sortie : Tous les points de contrôle de sécurité ont été franchis avec des preuves documentées et aucun élément critique n’est en retard sans risque formellement accepté.

E

Preuves, escalade et évolution

Dans un contexte de sécurité, la clôture d'un projet exige plus qu'une simple approbation. Cette étape valide tous les critères d'acceptation en matière de sécurité, confirme que le registre des preuves est complet et conservé conformément à la politique en vigueur, obtient l'acceptation formelle des risques pour les éléments résiduels, transfère la responsabilité du suivi opérationnel et documente les enseignements tirés.

Document clé : Liste de contrôle de fermeture du portail de sécurité

Critère de sortie : Tous les critères d’acceptation sont remplis ou formellement acceptés, le registre des preuves est complet et la propriété opérationnelle est confirmée.

La différence entre un programme de sécurité qui réussit son audit et un autre qui échoue ne réside souvent pas dans les contrôles de sécurité eux-mêmes, mais dans la rigueur de la documentation qui les entoure. Ce sont là les éléments essentiels qu'un chef de projet sécurité doit maintenir tout au long de chaque projet.

La charte de projet de cybersécurité est le document de base. Elle définit le périmètre, les objectifs, les critères d'acceptation en matière de sécurité, l'autorité du commanditaire et la procédure d'escalade. Elle doit être approuvée avant toute autre planification et ne peut être modifiée que par le biais d'une procédure de changement formelle.

Le registre des risques est un document évolutif, et non un exercice ponctuel. Il permet de suivre les risques identifiés, leur probabilité, leur impact, la méthode de traitement, le responsable et le risque résiduel tout au long du projet. Dans Celoxis, les registres des risques et des problèmes peuvent être configurés sous forme de flux de travail personnalisés, ce qui permet de visualiser les risques directement dans le planning du projet plutôt que dans un tableur isolé.

Le registre RAID, qui centralise les risques, les hypothèses, les problèmes et les dépendances dans un document unique et contrôlé, garantit que les points bloquants, les questions en suspens et les dépendances inter-équipes sont suivis, pris en charge et remontés au niveau supérieur, au lieu d'être négligés entre les mises à jour des équipes.

La matrice de contrôle est le document qui transforme la gouvernance en exécution. Elle associe chaque contrôle requis aux tâches qui le mettent en œuvre, au responsable, aux preuves nécessaires, à la date d'échéance et aux critères d'acceptation. C'est l'élément le plus important qu'un chef de projet sécurité gère, et pourtant, c'est celui qui fait le plus souvent défaut dans les programmes en phase de développement.

Le backlog de correction des vulnérabilités recense les anomalies non résolues issues des analyses de vulnérabilités et des tests d'intrusion, classées par ordre de gravité, avec des objectifs de SLA, une attribution de responsable et un statut. Dans Celoxis, ce backlog peut être géré comme un backlog de projet avec des champs de gravité personnalisés, un suivi des SLA et un tableau de bord générant des rapports par niveau de risque.

Le registre des preuves consigne les éléments de preuve recueillis pour chaque contrôle, leur emplacement de stockage, leur version et les personnes qui les ont consultés. Sans ce registre, la préparation d'un audit se résume à une recherche frénétique dans les lecteurs partagés et les archives de courriels.

Le registre d'acceptation des risques est le document officiel recensant tous les risques acceptés plutôt que traités, incluant la justification, l'approbateur, la date d'expiration et les conditions éventuelles. Ce document, essentiel à la gouvernance et non à la gestion de projet, doit être conservé conformément à la politique de conservation des preuves de l'organisation.

La liste de contrôle des points de contrôle de sécurité confirme, à chaque étape, que les critères d'acceptation de sécurité pour cette phase ont été respectés avant la poursuite du projet. Dans Celoxis, les points de contrôle peuvent être configurés sous forme de flux d'approbation exigeant la validation d'approbateurs désignés avant le déblocage de la phase suivante.

Notes fournisseur par fournisseur 

Celoxis

Celoxis se positionne dans cette comparaison comme une plateforme qui combine nativement, dans un seul système, la gouvernance de portefeuille, la planification Gantt avec analyse du chemin critique, le suivi des dépendances entre projets, la planification des capacités des ressources et le suivi financier, avec la flexibilité supplémentaire d'un déploiement sur site pour les organisations qui en ont besoin.

Pour la gestion de projets de cybersécurité, Celoxis assure la couche d'exécution et de gouvernance du portefeuille, reliant les résultats de la gouvernance de la sécurité à la responsabilité de la livraison. Les flux de travail de gestion des risques et RAID sont configurables sous forme de flux personnalisés structurés, et non de champs de texte libre. Ainsi, les registres des risques, les registres de preuves et les journaux d'acceptation des risques font partie intégrante du processus de livraison des projets, et non de simples documents administratifs. Les approbations des points de contrôle de sécurité sont structurées en flux d'approbation routés avec des enregistrements horodatés, générant la piste d'audit indispensable aux programmes de sécurité basés sur les preuves.

L'intégration de Jira et d'Azure DevOps est bidirectionnelle, un atout majeur pour les programmes de sécurité où les résultats sont suivis dans Jira et leur diffusion gérée dans Celoxis. Les flux de statut entre les deux plateformes s'effectuent sans synchronisation manuelle. Pour les organisations soumises à des exigences de résidence des données, le déploiement sur site est disponible en plus de l'option cloud, permettant ainsi aux PMO de sécurité de concilier fonctionnalités et conformité.

Sur G2, Celoxis affiche actuellement une note de 4,6 sur 5, basée sur plus de 650 avis. Les utilisateurs occupant des postes de direction de projets informatiques et de sécurité citent le plus souvent la combinaison de la planification des ressources, de la gestion des dépendances inter-projets et du reporting de portefeuille au sein d'une plateforme unique comme principale raison de leur choix d'abandonner des outils distincts. Le principal inconvénient mentionné est que la profondeur de configuration offerte peut engendrer une courbe d'installation initiale plus abrupte que pour des outils plus légers comme Wrike ou Smartsheet. Cependant, les utilisateurs estiment généralement que cette courbe est justifiée une fois la plateforme configurée selon les besoins du programme.

Celoxis est le choix idéal lorsque votre programme de sécurité gère plusieurs initiatives simultanées nécessitant une gouvernance au niveau du portefeuille, une gestion des capacités des ressources et des flux de travail formels de gestion des risques et d'approbation, et lorsque vous avez besoin d'une plateforme pouvant fonctionner en parallèle avec GRC et Jira sans dupliquer l'un ou l'autre.

Jira (Atlassian)

Jira est le point de départ le plus courant pour les équipes de sécurité déjà intégrées à l'écosystème Atlassian. Sa flexibilité et son large marché en font un choix judicieux pour la gestion des backlogs de correction des vulnérabilités, des sprints DevSecOps et des résultats des tests d'intrusion, notamment lorsque les activités de sécurité sont menées de front avec le développement logiciel au sein d'un même outil.

La limitation devient évidente au niveau du portefeuille. Jira est un outil de suivi des problèmes, et non une plateforme de gestion de portefeuille de projets (PPM). La planification des ressources, la gouvernance financière et les rapports de direction inter-projets nécessitent des feuilles de route avancées ou des plugins tiers, ce qui engendre des coûts et une complexité de configuration supplémentaires. Les registres des risques et les journaux RAID sont possibles dans Jira, mais requièrent une configuration personnalisée plutôt que des flux de travail natifs, ce qui peut entraîner des incohérences entre les équipes au fil du temps. Jira Government Cloud bénéficie de l'autorisation FedRAMP pour les charges de travail fédérales américaines, mais comme pour toute autorisation, les organisations doivent s'assurer que leur configuration et leur gestion des données spécifiques répondent aux exigences de conformité, plutôt que de supposer que l'autorisation au niveau de l'infrastructure s'étend à leur utilisation.

Jira est la solution idéale lorsque votre travail de sécurité est indissociable de votre pipeline de livraison de logiciels et que votre équipe maîtrise déjà parfaitement l'environnement Atlassian. Son utilisation est moins pertinente lorsque le besoin principal concerne la gouvernance du portefeuille, la planification des ressources et la gestion formelle des flux de travail de gestion des risques pour plusieurs programmes de sécurité menés simultanément.

Wrike

Wrike se positionne comme un compromis idéal entre la gestion de projets simplifiée et les solutions PPM complètes pour entreprises. Son automatisation des flux de travail configurable et ses fonctionnalités de collaboration transversale en font un choix judicieux pour les équipes de sécurité qui ont besoin d'une structure de gouvernance plus poussée que Jira, mais qui ne gèrent pas encore un portefeuille de programmes multi-applications important.

Wrike est certifié SOC 2 Type II et ISO 27001, prend en charge l'authentification unique SAML, l'authentification à deux facteurs et propose des options de résidence des données en Europe et aux États-Unis. Wrike Lock, qui permet aux entreprises de gérer leurs propres clés de chiffrement, est disponible sur certains niveaux d'abonnement Entreprise ; veuillez vérifier sa disponibilité et les exigences de chaque niveau avant de l'inclure dans une évaluation.

En contrepartie, la gestion des ressources et la gouvernance financière de Wrike au niveau du portefeuille sont moins abouties que celles des plateformes PPM dédiées aux organisations gérant des programmes de sécurité vastes et complexes. Les registres des risques, les journaux RAID et les flux de travail de traitement des preuves sont configurables mais non natifs ; leur mise en place et leur maintenance nécessitent donc une grande rigueur. Wrike ne propose actuellement aucun déploiement sur site, ce qui constitue une contrainte pour les entreprises de défense et les programmes de sécurité gouvernementaux soumis à des exigences strictes en matière de résidence des données.

Feuille intelligente

L'interface en grille de Smartsheet en fait l'un des outils les plus rapides à adopter pour les équipes migrant depuis les tableurs, un atout indéniable dans les organisations où la gestion du changement est aussi importante que la fonctionnalité. Sa force réside dans sa flexibilité structurée : presque tous les flux de travail peuvent être mis en place avec Smartsheet moyennant un effort de configuration suffisant, et la plateforme a tendance à se diffuser naturellement une fois adoptée par une équipe.

Pour les charges de travail du gouvernement américain, Smartsheet Gov est certifié FedRAMP, un atout majeur pour les programmes de sécurité fédéraux. Les certifications SOC 2 Type II et ISO 27001 sont en vigueur, et l'authentification unique SAML, le provisionnement SCIM et l'authentification multifacteur sont disponibles.

La limitation de la gestion de programmes de sécurité complexes est d'ordre structurel. Smartsheet, basé sur des grilles et des feuilles, convient parfaitement au suivi par listes, mais complexifie la planification des processus prédécesseur-successeur dans le cadre de grands projets intégrés. La planification des ressources et le suivi financier au niveau du portefeuille nécessitent généralement des plans de niveau supérieur et un effort supplémentaire de création de tableaux de bord, comparativement aux plateformes conçues dès le départ pour la gouvernance PPM. L'acceptation des risques et les flux de travail RAID sont possibles, mais requièrent une configuration spécifique pour garantir des enregistrements conformes aux exigences d'audit.

Projet ouvert

OpenProject est la plateforme idéale pour les organisations qui privilégient la souveraineté des données. Plateforme open source et auto-hébergée, elle leur offre un contrôle total sur l'emplacement, le chiffrement et l'accès à leurs données de projet ; un atout majeur pour les entreprises de défense, les agences gouvernementales et les institutions financières soumises à une réglementation stricte, qui ne peuvent pas stocker leurs données de projet dans un cloud commercial.

Il prend en charge l'authentification LDAP et SAML, le contrôle d'accès basé sur les rôles et le suivi adaptable des lots de travaux, configurable pour la gestion des risques et des problèmes. Son outil de planification Gantt et son suivi des dépendances inter-projets offrent une planification native plus poussée que la plupart des outils de gestion du travail.

La principale limitation réside dans la maturité de la solution PPM d'entreprise. L'analyse de portefeuille, la planification des ressources pour les grandes équipes et la gouvernance financière sont moins développées que sur les plateformes PPM commerciales. Les SLA de support et les engagements de maintenance dépendent de l'édition choisie et de l'hébergement. Pour les organisations où un déploiement auto-hébergé est indispensable et où la complexité de la gouvernance de portefeuille est modérée, OpenProject est une solution pertinente. En revanche, pour celles qui exigent une gouvernance financière de portefeuille approfondie et un contrôle total des données, une évaluation minutieuse est nécessaire.

Les rapports relatifs aux programmes de sécurité doivent faire la distinction entre les indicateurs de mise en œuvre et les indicateurs de résultats en matière de sécurité. Un programme peut être conforme au calendrier à 95 % alors que des vulnérabilités critiques demeurent non corrigées et que des contrôles clés ne sont pas mis en place.

Les indicateurs clés de performance (KPI) importants pour un RSSI sont les mesures de résultats en matière de sécurité : le nombre de vulnérabilités critiques non couvertes par l’accord de niveau de service (SLA), le pourcentage d’anomalies corrigées dans les délais convenus, le taux d’achèvement des contrôles de sécurité à chaque étape clé, le taux de complétude des preuves avant un audit, le taux de réussite des contrôles de sécurité lors de la première revue et le dépassement de la date de révision des acceptations de risques. Ces indicateurs doivent être suivis et rapportés séparément, mais en parallèle, des indicateurs de performance standard tels que les écarts de planning, les écarts par rapport aux jalons, les écarts budgétaires et l’utilisation des ressources.

Dans Celoxis, il est possible de créer des tableaux de bord personnalisés permettant de faire apparaître simultanément les deux catégories, offrant ainsi aux responsables PMO de sécurité et aux RSSI une vue unique de l'état du programme qui capture à la fois la discipline de livraison et les progrès en matière de résultats de sécurité.

Les projets de sécurité gouvernementaux et ceux des industries réglementées fonctionnent selon des exigences de gouvernance qui diffèrent sensiblement des pratiques par défaut du secteur commercial, et le choix de la plateforme de gestion de projet doit refléter ces exigences.

Les règles de souveraineté des données peuvent restreindre l'emplacement de stockage des données de projet, notamment les registres des risques, les rapports de vulnérabilité et les preuves d'audit. Les fournisseurs doivent pouvoir s'engager sur des emplacements de centres de données spécifiques, et non se contenter d'une disponibilité régionale générale. Un déploiement sur site ou dans un cloud certifié par les autorités compétentes peut être exigé par politique ou contrat, et les organisations doivent vérifier toute autorisation revendiquée directement auprès du registre officiel. Le recours par un fournisseur à un prestataire cloud prenant en charge les charges de travail FedRAMP ne confère pas automatiquement la certification FedRAMP à son produit. L'autorisation FedRAMP s'applique au produit lui-même, et non à l'infrastructure sous-jacente.

Dans les environnements gouvernementaux, les exigences en matière d'identité imposent souvent l'authentification PIV/CAC ou l'intégration SAML auprès des fournisseurs d'identité gouvernementaux, ainsi qu'une application stricte du principe du moindre privilège. Les durées de conservation des journaux d'audit et les formats de preuve doivent respecter les exigences spécifiques du gouvernement, et les journaux doivent être exportables dans des formats permettant l'audit.

L'option de déploiement sur site de Celoxis est particulièrement pertinente ici. Les organisations qui ne peuvent pas héberger leurs données de projet dans un cloud commercial peuvent déployer Celoxis au sein de leur propre infrastructure, conservant ainsi un contrôle total sur l'emplacement, l'accès et la conservation des données, tout en bénéficiant des fonctionnalités de gestion de projet et de portefeuille d'entreprise.

Il s'agit d'un scénario représentatif, inspiré des pratiques courantes des programmes de sécurité d'entreprise. Il ne concerne pas un client spécifique de Celoxis, mais illustre les difficultés réelles rencontrées par les chefs de produit sécurité lorsqu'ils gèrent la certification de conformité parallèlement aux actions correctives.

La situation

Une entreprise de services financiers de taille moyenne s'est engagée à obtenir la certification ISO/IEC 27001:2022. Le conseil d'administration a fixé une échéance stricte : l'audit externe aura lieu dans 22 semaines. Deux semaines avant l'arrivée du responsable de la sécurité, un test d'intrusion interne révèle des résultats alarmants : quatre failles critiques et onze failles de haute gravité, nécessitant toutes une correction documentée avant l'ouverture de la période d'audit.

C'est une situation que beaucoup de chefs de produit sécurité connaissent bien. On ne part pas de zéro, mais on ne part pas non plus de zéro. Il y a un programme de conformité à mettre en place, un retard de correction à rattraper, une équipe pluridisciplinaire qui n'est pas encore formellement alignée et une date limite d'audit qui reste inchangée.

Le premier réflexe d'un chef de projet sécurité est souvent de créer un tableau et de commencer à attribuer des tâches. Ce réflexe est compréhensible, mais c'est aussi à ce moment-là que de nombreux programmes commencent à perdre le contrôle. Voici comment ce scénario se déroule différemment lorsque le cadre SECURE est appliqué chez Celoxis.

Définition du périmètre et élaboration de la charte

La première action du chef de projet sécurité n'est pas d'établir une liste de tâches, mais de définir précisément ce que signifie « terminé » pour ce programme. En collaboration avec le RSSI et le responsable des risques désigné, le chef de projet élabore une charte de projet dans Celoxis qui définit le périmètre du SMSI (systèmes de traitement des données clients, infrastructure cloud et processus RH essentiels), les critères d'acceptation de sécurité pour la préparation à l'audit, les exigences en matière de preuves pour chaque contrôle et la date limite d'audit non négociable.

Cette charte n'est pas un document voué à l'oubli. Chez Celoxis, elle devient le document de référence pour toutes les discussions relatives au périmètre, les demandes de modification et les décisions d'allocation de ressources. Lorsque l'équipe infrastructure se demande ultérieurement si un serveur existant doit être inclus dans le périmètre du SMSI, la réponse se trouve dans la charte approuvée, datée et signée par le responsable.

Conversion de 93 contrôles en un calendrier de livraison

Une analyse des écarts par rapport à l'annexe A de la norme ISO/IEC 27001:2022 identifie 17 lacunes en matière de contrôle, où l'organisation ne dispose d'aucun contrôle ou d'un contrôle dont les éléments probants ne sont pas actuellement conformes aux exigences d'audit. Chaque lacune est intégrée au plan de projet Celoxis et associée au contrôle correspondant de l'annexe A grâce à un champ personnalisé. Cette association permet de transformer un document de gouvernance en un calendrier de livrables.

Les quatre anomalies critiques du test d'intrusion sont chacune transformées en tâches de remédiation avec un SLA de deux semaines. Les onze anomalies à haute gravité bénéficient d'un SLA de quatre semaines. Chaque tâche a un responsable désigné, sélectionné dans le plan de ressources, des exigences de preuve définies et un critère d'acceptation précisant ce que signifie « remédié » : non pas simplement « correction appliquée », mais « correction appliquée, test de régression effectué et confirmation de l'absence de vulnérabilité par une nouvelle analyse DAST »

À ce stade, le chef de projet sécurité dispose non seulement d'une liste de tâches, mais d'une base de projet complète : 93 contrôles pris en compte, les lacunes cartographiées dans les lots de travaux, les résultats des tests d'intrusion dans le backlog de correction, les responsables confirmés et l'échéance de l'audit de 22 semaines visible comme étape clé sur le diagramme de Gantt.

Là où les dépendances créent un risque réel

En pratique, la mise en œuvre de la norme ISO 27001 révèle presque toujours des dépendances imprévues au départ. Dans ce cas précis, la plus importante apparaît quatre semaines plus tard.

La mise à jour des accords fournisseurs, nécessaire pour se conformer à la norme ISO 27001 A.5.20 relative à la sécurité de l'information dans les relations fournisseurs, dépend de la finalisation par le service juridique de l'examen de tous les contrats avec les tiers. Cet examen, initialement estimé à deux semaines, se poursuit depuis trois semaines sans date de fin confirmée.

Comme cette tâche est répertoriée dans Celoxis comme une étape préalable à la soumission des éléments probants d'audit, le retard est immédiatement détecté et non découvert la semaine précédant l'audit. Le chef de produit sécurité en informe le RSSI en documentant la dépendance, en quantifiant l'impact sur le calendrier et en présentant deux options : accélérer l'examen juridique en allouant des ressources supplémentaires, ou accepter formellement que les éléments probants A.5.20 soient soumis partiellement et préparer une justification compensatoire pour l'auditeur.

Il s'agit d'une décision de gouvernance, et non de gestion de projet. Mais elle ne peut être prise qu'au moment opportun, avec les informations adéquates, car la dépendance a été gérée et non présumée.

Portails de sécurité comme véritables points de contrôle

Quatre semaines avant l'ouverture de la période d'audit, la première étape majeure de sécurité est déclenchée chez Celoxis. Avant que la phase d'examen des preuves puisse commencer, le responsable de la sécurité et le RSSI doivent approuver formellement l'exhaustivité du registre des preuves, confirmant ainsi que chaque contrôle concerné est associé à une preuve, que chaque preuve a été examinée par un approbateur désigné et qu'aucune lacune n'est restée sans solution ou non acceptée.

Il ne s'agit pas d'une réunion suivie d'un courriel. Chez Celoxis, le processus d'approbation est un flux de travail : le responsable de la sécurité examine et approuve, puis le RSSI examine et approuve à son tour. L'enregistrement est horodaté et conservé dans la piste d'audit du projet. Si l'un des approbateurs signale un contrôle incomplet, le processus est bloqué et la tâche est renvoyée à son responsable avec la mention de l'anomalie.

C’est précisément le type de point de contrôle que requièrent les preuves prêtes pour un audit, et précisément le type de point de contrôle qui est négligé lorsque les programmes de sécurité sont gérés dans des feuilles de calcul sous la pression des délais.

Comment le programme se termine

À la 22e semaine, le programme est clôturé. Les 93 contrôles de l'annexe A sont consignés dans le registre des preuves de Celoxis, chacun étant associé à un emplacement de stockage, un statut de révision et un approbateur. Trois domaines de risques résiduels, que l'organisation a choisi d'accepter plutôt que de corriger, ont été formellement traités selon la procédure d'acceptation des risques de Celoxis. Le dossier comprend une justification documentée, le nom du responsable du risque, une date d'expiration et l'approbation du conseil d'administration.

Le RSSI a pu suivre en temps réel le taux d'achèvement des contrôles, la conformité aux SLA et les risques non identifiés sur son tableau de bord Celoxis pendant les 22 semaines. Aucun rapport manuel hebdomadaire n'a été établi, aucune réunion de suivi n'a été consacrée à démêler le vrai du faux, et aucune course contre la montre n'a été nécessaire pour retrouver des preuves collectées mais jamais correctement archivées.

Ce que ce scénario illustre

Dans ce cas précis, la société de services financiers n'a pas réussi grâce à une meilleure connaissance de la sécurité ou à une équipe plus compétente que les organisations qui échouent à leur premier audit ISO 27001. Son succès repose sur une exécution structurée : l'écart entre les exigences de gouvernance et les éléments de preuve fournis a été comblé par une gestion de projet rigoureuse, soutenue par une plateforme qui a intégré les flux de travail relatifs aux risques, aux dépendances, aux preuves et aux approbations au processus normal de réalisation du projet, plutôt que de les considérer comme des charges administratives supplémentaires.

Voilà la contribution de Celoxis à la gestion de projets de cybersécurité. Non pas l'expertise en sécurité fournie par votre équipe, mais la structure qui garantit que cette expertise produise des résultats concrets.

La gouvernance de la sécurité indique aux organisations les actions à entreprendre. Les outils de sécurité technique détectent les failles. Les plateformes GRC organisent les contrôles, les risques et les preuves dans un cadre de conformité. Cependant, aucun de ces éléments, pris isolément, ne garantit que les bonnes actions sont réalisées par les bonnes personnes, dans les délais impartis et avec les preuves nécessaires.

C’est là le problème de l’exécution, et c’est là que la plupart des programmes de sécurité échouent.

Celoxis offre aux PMO de sécurité la structure nécessaire pour relever les défis. De la visibilité globale sur de multiples initiatives de sécurité simultanées à la planification Gantt avec points de contrôle de sécurité, en passant par les flux de travail RAID configurables, la planification des ressources, les processus d'approbation avec pistes d'audit et les tableaux de bord de direction en temps réel, Celoxis est conçu pour aligner les exigences de gouvernance de la sécurité sur les résultats concrets.

Les systèmes de sécurité détectent les points à corriger. Les plateformes GRC définissent les exigences. Celoxis s'assure de leur mise en œuvre.