Comment faire une analyse de risques ?

Qu’est-ce que le risque ?

Rien n’est moins sûr que l’incertain.
Pierre Dac (l’os à moelle)

Définition : Le risque est un danger éventuel plus ou moins prévisible qui peut affecter l’issue du projet. Il ne sera pas possible de tous les éliminer, le risque zéro n’existe pas.
Source : Le chef de projet efficace

Toute la question repose sur la capacité d’anticiper le risque:
Somme-nous capables d’estimer la probabilité d’occurrence du risque et d’en anticiper les éventuelles impacts en terme de gravité si jamais le pire arrivait. Comment les prévenir ? Et, le cas échéant, comment y remédier pour amortir les impacts ?
Voilà des questions qui méritent des réponse précises.

Mais attention, tous les risques ne sont pas prévisibles, il faudra bien compter avec les impondérables.

Comment évaluer les risques ?

Bien entendu, il est inconcevable d’envisager de se prémunir de tous les dangers inhérents à la conduite d’un projet complexe. Il est toutefois indispensable de procéder à une étude complète et raisonnée des risques potentiels plus ou moins prévisibles, afin de dépasser le stade des croyances fondées ou non. Une analyse rigoureuse est une bonne garantie de réussite. la démarche la plus simple se déroule en cinq temps majeurs.

La carte de « chaleur » pour classifier

La table qui suit est un exemple de ventilation des risques inventoriés en tenant compte de la criticité ou impact et de la probabilité d’occurrence :

• La zone rouge, de haute chaleur répertorie les risques inacceptables à aucun prix.
• La zone orange, de chaleur élevée identifie ceux qui nécessitent des palliatifs urgents.
• La zone jaune, de chaleur moyenne identifie ceux qui nécessitent des palliatifs préalablement définis.
• Ceux de la zone verte sont acceptables mais à surveiller selon les conditions définis au moment de l’élaboration de la table, ceux en vert le plus sombre peuvent être ignorés.

Table de classification des risques

Les 5 étapes de la méthode d’Analyse

Voyons maintenant comment dérouler la démarche afin de démarrer le projet en limitant autant que faire ce peut les risques d’échecs. Cette démarche se déroule en 5 temps majeurs, tous aussi importants l’un que l’autre.

1. Établir l’inventaire des risques

Il s’agit de ratisser large et de considérer toutes les formes de risques (humain, financier, organisationnel, technologique…)

Type de risques potentiels pour un projet : financiers, organisationnels, techniques, sociaux, environnementaux sont pris en considération sans aucune exception.

• Sources d’information : Enquêtes de terrain, exploration des archives, analyse de la mémoire des réalisations antérieures, consultation d’experts, expérience du chef de projet. Une large consultation de tous ceux qui ont approché par le passé un projet similaire est une source précieuse d’information.
• C’est aussi lors de cette étude que l’on mesure l’importance d’établir une mémoire des projets réalisés qu’ils aient réussi ou échoué.

Tous les risques inventoriés seront placé dans une table avec leur description, la table sera ensuite complété tout au long de l’analyse.

2. Pondérer les risques

Tous les risques n’ont pas la même probabilité de survenance, tous les risques ne sont pas égaux en terme de criticité. Il s’agit au cours de cette étape d’effectuer un classement rationnel.

• Gravité ou Impact : Sur l’axe des ordonnés de la table de classification ci-dessus. Il s’agit évaluer la criticité de chacun des risques en terme d’impact, de dommages et de conséquences. Là encore on hésitera pas à explorer la mémoire collective des projets passés.
• Probabilité : Sur l’axe des abscises de la table de classification ci-dessus. Ensuite, on évalue la criticité en termes de probabilité d’occurrence. Cet exercice n’est pas le plus aisé, on s’en doute. la précision en est toute relative, là aussi l’xpérience du collectif peut s’avérer importante.

Chaque risque de la table doit donc être pondérer, chaque critère est évalué de 1 à 5, le poids du risque est calculé comme le produit des deux critères précédents, pour ensuie évaluer sa couleur dans la table de classification ci-dessus et en déduire l’action requise.

3. Définir les parades

Pour chacun des risques, on se posera ces 3 questions successives :
– Peut-on l’éliminer ?
– Peut-on en limiter les effets ?
– Doit-on modifier le déroulement du projet ?

• Éliminer le risque. Est-il possible de l’éliminer en augmentant les ressources ou en intégrant dans l’équipe de nouveaux intervenants spécialistes de la question et plus aguerris ? Le coût sera l’un des principaux critères de jugement.
• Limiter les effets dévastateurs des sinistres potentiels. De même, la solution est souvent du côté de l’optimisation de la gestion des ressources.
• Réviser le projet. Faut-il modifier les orientations, limiter les spécifications et trouver des alternatives plus paisibles quitte à modérer les ambitions et à procéder à des simplifications ? Une précaution à prendre au cas par cas.
• Il ne faut pas non plus hésiter à limiter le périmètre du projet pour gagner en visibilité. les projets courts et rapidement mis en oeuvre son plus aisés à gérer et à intégrer dans l’existant.

4. Identifier les points critiques

Une étape souvent oubliée dans les études de risques.

Les risques sont changeants. La probabilité et la criticité évoluent au fur et à mesure de l’avancement du projet. Certaines phases du projet sont plus à risques que d’autres. Il faut les identifier.

• Lieux et/ou moments où la probabilité et/ou la gravité sont les plus importants, les instants du déroulement où il faudra redoubler de vigilance.

On le constate dans le cycle de vie d’un projet ci-dessous, à chaque jalon important une réévaluation des risques est réalisée :

Cycle de développement sécurité

5. Réviser la table des risques

La table des risques n’est pas statique, il faut la réviser régulièrement.

• Suivre l’évolution dans le temps de la criticité.
  Cette table n’est pas statique, elle n’est pas non plus une assurance.
  Prévoir un danger n’est pas s’en protéger !
• En outre, la dangerosité potentielle tout comme la probabilité d’occurrence évoluent au fil du temps et de l’avancement.
  Cette table sera soigneusement suivie et mise à jour très régulièrement.

Voici un exemple de table d’analyse des risques réalisée pur une salle informatique déportée :

Afficher ce document sur Scribd

Comment s’y prendre ?

Et bien en impliquant un maximum de monde, en fouillant dans les archives, en incitant « les experts du moment» à la communication quels qu’ils soient, où qu’ils se trouvent ? Toutes les péripéties des projets passés, comme les difficultés et la manière de les solutionner sont une mine de ressources pour la réflexion préalable à l’analyse de risques. Mais encore faut-il avoir pris le soin d’enregistrer les expériences passées…

Le soin apporté lors du déroulement de chacune des étapes l’analyse de risques est d’une importance capitale pour la réussite du projet.

Il existe des méthodes spécialisées selon le domaine d’activité, par exemple pour un projet de sécurité des SI on pourra utiliser les méthodes EBIOS (ANSSI) ou MEHARI (CLUSIF), mais dans leurs principe elles se déroulent comme indiqué ci-dessus.

Sécurité en développement logiciel

Développement et maintenance des systèmes

La stratégie d’une entreprise développant des logiciels se doit d’envisager les propriétés et les implications de la sécurité des applications, des systèmes et des services utilisés ou fournis par l’entreprise tout au long du cycle de vie d’un projet.

La charte de sécurité de développement des applications, systèmes et services de l’entreprise doit prévoir que les équipes et les personnes mettent en œuvre les mesures de sécurité appropriées dans les applications, les systèmes et les services en cours de développement, en fonction des risques et préoccupations de sécurité identifiés. La charte doit mentionner que l’entreprise dispose des rôles et des responsabilité de sécurité dont la mission est de fournir des lignes directrices de sécurité et d’assurer l’évaluation des risques.

L’entreprise doit mettre en oeuvre un certain nombre de mesures visant à garantir que les produits logiciels et services quelle propose aux utilisateurs soient conformes aux normes les plus strictes sur la sécurité logicielle. Cet article décrit une approche en matière de sécurité logicielle, celle-ci peut s’adapter et évoluer en fonction de l’organisattion et de la culture de l’entreprise.

Consultation et revue de sécurité

S’agissant de la conception, du développement et du fonctionnement des applications et services, les rôles de sécurité inclus les catégories principales de services de consultation suivantes aux équipes de développement, techniques et production :

• Revues de sécurité au niveau de la conception : évaluations au niveau de la conception des risques de sécurité d’un projet et mesures d’atténuation correspondantes, tout en considérant leur caractère approprié et leur efficacité.
• Revues de sécurité au niveau de l’implémentation : évaluation au niveau de l’implémentation des artefacts de code pour mesurer leur fiabilité par rapport aux menaces de sécurité applicables.
• Consultation de sécurité : consultation en continu des risques de sécurité associés à un projet donné et solutions éventuelles aux problèmes de sécurité, souvent sous forme d’exploration de l’espace de conception dans les phases initiales des cycles de vie des projets.

Une multitude de types de problèmes de sécurité peuvent intervenir au niveau de la conception du produit, c’est pourquoi ils doivent être pris en considération et résolus au plus tôt lors de la phase de conception du produit ou du service. La finalité essentielle de la revue de sécurité au niveau conception est de garantir la prise en compte de ces considérations. 

Dans ce cadre, la revue de sécurité au niveau de la conception se fixe les objectifs suivants :

• Fournir une évaluation de haut-niveau des risques de sécurité associés au projet, sur la base d’une recherche des menaces réelles en réalisant une analyse des risques.
• Procurer aux décideurs du projet les informations nécessaires afin qu’ils puissent faire des choix éclairés en matière de gestion des risques et intégrer les considérations de sécurité dans les objectifs d’un projet.
• Fournir des lignes directrices quant au choix et à la mise en œuvre correcte de contrôles de sécurité planifiés (par exemple : protocoles d’authentification ou chiffrement).
• S’assurer que l’équipe de développement dispose de la formation adéquate eu égard aux classes de vulnérabilités applicables, aux schémas d’attaque et aux stratégies d’atténuation appropriées.

Lorsque des projets impliquent des fonctionnalités ou des technologies innovantes, un des rôles de sécurité est chargé de rechercher et d’explorer les menaces, les schémas d’attaque potentiels et les classes de vulnérabilités spécifiques des technologies et fonctionnalités en question. Le cas échéant, l’entreprise peut sous-traiter à des prestataires la consultation de sécurité pour compléter les compétences de l’équipe de sécurité et obtenir une revue indépendante garante d’objectivité afin de valider les revues de sécurité internes.

Sécurité dans le contexte du cycle de vie des logiciels

La sécurité est au cœur du processus de conception et de développement que l’on nomme cycle de vie des logiciels ou Software Devlopment Life Cycle (SDLC) en anglais. L’organisation technique de l’entreprise ne requiert pas que les équipes de développement de produits suivent un processus de développement logiciel particulier, au contraire, les équipes choisissent et mettent en œuvre des processus adaptés aux besoins du projet. Dans ce cadre, un certain nombre de processus de développement logiciel sont utilisés, allant des méthodologies de développement Agile aux processus plus classiques : par étapes, en V ou en cascade.

Sur les illustrations ci-dessous vous pouvez découvrir comment l’intégration de la sécurité se fait dans un cycle en V :

Les processus du développement logiciel

Cycle de développement sécurité

Les processus de revue de la sécurité sont prévus pour fonctionner dans la structure choisie. Leur réussite dépend de la culture technique en matière de qualité et de quelques exigences définies par la direction technique des processus de développement de projet :

• Documentation de conception revue par les pairs.
• Conformité aux lignes directrices de style de codage.
• Revue de code par les pairs.
• Tests de sécurité multi-couches.

Les exigences ci-dessus représentent la culture d’ingénierie logicielle, dans laquelle les objectifs clés sont la qualité, la fiabilité et la maintenabilité des logiciels. Tandis que la finalité première de ces exigences est d’encourager la création d’artefacts logiciels irréprochables en matière de qualité logicielle, les bonnes pratiques de sécurité suggèrent également qu’ils représentent des « moteurs » significatifs et évolutifs en faveur de la réduction de l’incidence de failles de sécurité dans la conception logicielle :

• L’existence d’une documentation de conception suffisamment détaillée constitue une condition préalable du processus de revue de sécurité au niveau de la conception, dans la mesure où lors des premières phases du projet, c’est en général le seul artefact disponible pour élaborer les évaluations de sécurité. Bon nombre de classes de failles de sécurité au niveau implémentation s’apparentent finalement à des défauts fonctionnels courants, à faible risque. La plupart des failles au niveau implémentation sont le résultat d’omissions très simples de la part du développeur.
• Avec des développeurs et des réviseurs de code formés aux schémas de vulnérabilité en vigueur et aux méthodes permettant de les éviter, une culture du développement basée sur la revue par les pairs, insistant sur la création d’un code de haute qualité est un moteur important et évolutif vers une base de code sécurisée.

Les développeurs logiciels de l’équipe de sécurité collaborent avec d’autres développeeurs de l’entreprise sur le développement et la validation de composants réutilisables conçus et implémentés pour permettre aux projets logiciels d’éviter certaines classes de vulnérabilités. Parmi les exemples figurent les couches d’accès aux données conçues pour résister aux failles d’injection de langage de requête SQL, ou les structures de modèles HTML avec défenses intégrées contre les vulnérabilités XSS.

Formation à la sécurité

Reconnaissant l’importance d’une main-d’oeuvre technique formée aux pratiques de codage sécurisé, le responsable sécurité met en place une campagne de communication et un programme de formation à l’intention des équipes, dont le contenu est le suivant :

• Formation des nouveaux développeurs à la sécurité
• Création et gestion d’une documentation complète sur les pratiques sécurisées de codage et de conception
• Références ciblées et contextuelles à la documentation et aux supports de la formation (par exemple, des outils automatisés de test des vulnérabilités fournissent aux ingénieurs des références à la documentation de formation et de fond en rapport avec les bugs ou classes de bugs spécifiques mis en évidence par l’outil)
• Présentations techniques sur les rubriques relatives à la sécurité
• Newsletter sur la sécurité distribuée à l’ensemble des équipes et destinée à informer la main-d’œuvre technique des menaces, schémas d’attaque, techniques d’atténuation, bibliothèques liées à la sécurité, meilleures pratiques et lignes directrices, etc. recensés récemment
• Ateliers sécurité, sous forme de conférences récurrentes à l’échelle de l’entreprise, qui réunit les développeurs des différentes équipes travaillant sur la sécurité et propose des présentations techniques détaillées sur les sujets de sécurité

Tests et revue de sécurité au niveau implémentation

L’entreprise doit appliquer un certain nombre d’approches pour continuer de réduire l’incidence de failles de la sécurité au niveau de l’implémentation dans ses produits et services :

• Revues de sécurité au niveau implémentation : réalisées par les rôles de sécurité, généralement lors des dernières phases du développement de produits, les revues de sécurité au niveau implémentation visent à valider la résistance d’un artefact logiciel aux menaces de sécurité applicables. Ces revues sont généralement constituées d’une réévaluation des menaces et contremesures identifiées lors de la revue de sécurité au niveau conception, de revues ciblées sur le code critique pour la sécurité, de revues de code sélectives permettant d’évaluer la qualité du code du point de vue de la sécurité, et de tests de sécurité ciblés.
• Tests automatisés des failles dans certaines classes de vulnérabilités pertinentes. Pour ces tests, il faut utiliser aussi bien des outils développés en interne que des outils disponibles sur le marché.
• Tests de sécurité réalisés par des ingénieurs de la qualité logicielle dans le contexte des actions menées en matière de test et d’évaluation de la qualité logicielle globale du projet.

Services de consulting

Nous menons les projets de conseils en sécurité avec une offre de services très diversifiée et adaptée à vos besoins, par exemple :

• Audit des processus de développement logiciel
• Rédaction d’une charte sécurité pour les développeurs
• Sensibilisation à la sécurité des développements et du SI
• Mise en oeuvre des processus de revue de la sécurité
• Réalisation d’analyse de risques projet et produit

Les enjeux de la conformité RGPD

Quelle conformité pour les organisations ?

Le Règlement européen impose une prise en compte accrue de la protection des données à caractère personnel : « Protection des données dès la conception » et « Protection des données par défaut ».

L’urgence est de prendre en compte les exigences du RGPD dans les contrats au plus tôt et en particulier sur le changement du statut du sous-traitant en termes de responsabilités (article 26 et article 28).

L’ampleur des sanctions (article 84) en cas de non conformité va de 10 M€ ou 2% du CA mondial consolidé à 20 M€ ou 4% du CA mondial consolidé. Le montant le plus élevé étant retenu comme sanction maximale possible.

Lorsque des transferts d’information hors Union Européenne sont effectués, des BCR ou Binding Corporate Rules peuvent constituer une solution juridique de mise en conformité et de maintient d’exploitabilité.

Le chapitre IV section 4 concerne le Délégué à la Protection des Données (DPD) ou Data Privacy Officer (DPO). L’obligation de la désignation d’un DPO ne concerne pas toutes les structures, bien que la CNIL recommande fortement sa désignation, y compris dans les cas d’exceptions. Le DPO peut être un rôle interne porté par un salarié ou externalisé chez un prestataire.

Preuves de la responsabilité opérationnelle et juridique de l’organisation, le corpus documentaire exigé est constitué :

• d’un registre des activités de traitements qui permet de recenser les traitements de données et de disposer d’une vue d’ensemble de ce qui est fait avec les données personnelles,
• d’une Etude d’Impact sur la Vie Privée (EIVP ou PIA) pour les traitements décrit à l’article 35 du règlement susceptibles d’engendrer un risque élevé pour les droits et libertés des personnes physiques,
• de la réalisation d’un rapport annuel d’activité.

En synthèse les exigences du RGPD sont :

• Protection des données dès la conception (Privacy by Design).
• Protection des données par défaut (Privacy by Default).
• Représentant dans l’organisation (Data Protection Officer).
• Registre des traitements.
• Coopération avec l’autorité de contrôle.
• Notification à l’autorité de contrôle.
• Notification des personnes concernées.
• Analyse d’impact (Privacy Impact Assessment).

En cas de défaut la sanction prévue est de 2% du CA consolidé ou 10 M€.

La suite des exigences :

• Respect des principes de base d’un traitement (Licéité, loyauté, légitimité, consentement, données sensibles …).
• Respect du droit des personnes (Droit d’accès, de rectification, d’effacement dit « Droit à l’oubli », à la limitation du traitement, à la portabilité et d’opposition).
• Respect des règles relative au transfert de données (Privacy Shield / Binding Corporate Rules).

Dans ces cas le non respect peut être sanctionné par 4% du CA consolidé ou 20 M€.

La mise en conformité n’est pas un simple projet, il s’agit plus d’un changement de culture dans les organisations quelques soient leurs tailles.

Méthodologie

Pour qu’une organisation se mette en conformité, il faut qu’elle se prépare en 6 étapes selon les conseils de la CNIL :

1. Désigner un pilote,
2. Cartographier les traitements de données personnelles,
3. Prioriser les actions,
4. Gérer les risques,
5. Organiser les processus interne,
6. Documenter la conformité.

Pour rester dans l’esprit de ces étapes nous proposons de vous accompagner sur un projet de mise en conformité en 5 phases comme suit (cliquer sur l’image pour l’agrandir) :

Ce type de projet vous permet d’obtenir une évaluation de votre conformité au Règlement européen, d’avoir une cartographie complète de vos traitements et un plan d’action d’amélioration pour être en conformité. L’ensemble des résultats obtenus permet au DPO ou au responsable de traitement de prendre en charge immédiatement le maintien de cette conformité et le pilotage du plan d’action. Il est conseillé de réévaluer la démarche au moins une fois tous les 3 ans.

Services de consulting

Nous menons les projets de mise en conformité RGPD avec une offre de services très diversifiée et adaptée à vos besoins, par exemple :

• Évaluation flash de maturité au RGPD et à la sécurité des données.
• Pilotage complet du projet de mise en conformité RGPD.
• Établissement et documentation du registre des traitements.
• Sensibilisation au Règlement et aux bonnes pratiques de sécurité.
• Analyse de risques et évaluation d’impact sur la vie privée (PIA).
• Coordination du plan d’amélioration des processus et de la sécurité du SI.
• Aide au déploiement des processus de sécurité des données.

Comment standardiser sans uniformiser ?

J’ai contribué au Club PMO animé par ACDE Conseil en faisant un retour de mon expérience de standardisation pragmatique de processus au sein d’une organisation de services spécialisée en développement et hébergement de logiciels pour le monde de la santé.

Cegedim a souhaité définir un référentiel commun de bonnes pratiques, propre à l’entreprise, construit à partir de plusieurs méthodologies et référentiels : CMMI, Prince 2, ITIL, ISO 2701, ISO 9001, etc.

Cette approche de rationalisation interne des référentiels sert également à montrer aux clients de l’organisation comment sont gérés les projets et les services, cette standardisation aide à vendre la démarche de définition des processus internes aux Managers opérationnels.

Un point de vigilance qu’il ne faut pas négliger dans ce type de projet, c’est de rechercher et trouver le bon niveau de détails dans la définition des processus sans nuire à l’innovation.

Vous pouvez retrouver cette présentation sur le site du Club PMO ou directement en la téléchargeant ici.