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é
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 :

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.

Gestion de crise et exercices

Définitions

Une crise est une situation anormale, venant perturber le fonctionnement habituel d’une organisation, pouvant aller jusqu’à la mettre en péril. Elle nécessite des réactions adaptées de la part des décideurs afin de revenir à une situation nominale, dans les meilleures conditions.

Alors même que la crise dépasse les capacités d’organisation et nécessite des mesures exceptionnelles en interne ou en faisant appel à des tiers, elle est bien souvent la conséquence d’un ou plusieurs faits – prévisibles ou non – exogènes ou endogènes.

Afin de pouvoir réagir au mieux, la préparation, l’anticipation, la prévision, la sensibilisation et la formation sont des éléments essentiels permettant une gestion adaptée, cohérente et efficace dans des situations instables. Cela passe par la rédaction de politiques de gestion de crise et de continuité d’activité, l’investissement en ressources humaines et matérielles, ou encore, la formation à la gestion de crise.

Exercices de gestion de crise

L’exercice de crise, qu’il soit « sur table » ou « terrain », annoncé ou inopiné, permet de manière transversale de répondre à plusieurs éléments de préparation à la gestion de crise, en fonction des objectifs de l’organisation et de son niveau de maturité.

Il faut alors considérer l’exercice de crise, d’une part en tant que moyen de validation de dispositifs et politiques, d’autre part en tant qu’outil ded formattion et enfin, en tant que levier stratégique, le tout, au profit d’une gestion de crise plus efficiente.

S’exercer pour valider les dispositifs et politiques de gestion de crise

Exemple d’exercice de crise dans le cadre d’un plan de continuité infomatique / PRA

Mettre en place pour la première fois une politique de gestion de crise ou revoir un dispositif de gestion de crise, doit provoquer l’automatisme de le tester, le valider de manière opérationnelle.

Politique de gestion de crise

En effet, à froid et en théorie, la conception et la rédaction de politiques de gestion de crise et de continuité d’activité peuvent paraître complètes et opérationnelles. Cela est effectivement peut-être le cas. Cependant, les acteurs de la gestion de crise, réussiront-ils à les comprendre et à se les approprier le moment venu, en cas de crise réelle ? Seule une mise en situation – la plus réaliste possible – permettra de mettre en lumière d’éventuels effets de bord. Ces derniers pourront être corrigés dans des versions ultérieures des politiques de gestion de crise. La fameuse roue de Deming, avec le « PDCA » (Plan / Do / Check / Act)[  issu de la norme ISO entre alors en jeu pour une amélioration continue vertueuse.

Vérifier et valider les dispositifs de gestion de crise est incontestablement un atout permettant de gérer au mieux la potentielle crise à venir. Cela permet également, grâce à l’exercice de crise, de profiter de cette occasion pour sensibiliser et former les collaborateurs à la gestion de crise.

Services de consulting

Nous pouvons vous accompagner pour mettre en place les dispositifs de gestion de crise pour gérer au mieux les potentielle situation de crise à venir. La création et le déploiement d’exercice de crise, permettra de sensibiliser et former vos collaborateurs pour gestion de crise opérationnelle.

Pour cela notre accompagnement peux concerner :

  • Évaluation ou audit de plan de continuité et de processus de gestion de crise
  • Définition et au déploiement de plans d’action d’amélioration.
  • Définition du processus opérationnel de gestion de crise.
  • Coaching du responsable de gestion de crise.
  • Organisation d’exercice sur table de gestion de crise.

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
Les processus du développement logiciel
Cycle de développement sécurité
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 :