Blog ENI : Toute la veille numérique !
💥 Un livre PAPIER acheté
= La version EN LIGNE offerte pendant 1 an !
Accès illimité 24h/24 à tous nos livres & vidéos ! 
Découvrez la Bibliothèque Numérique ENI. Cliquez ici
  1. Livres et vidéos
  2. La sécurité informatique en mode projet
  3. Les spécificités de projets sécurité
Extrait - La sécurité informatique en mode projet Organisez la sécurité du SI de votre entreprise (2e édition)
Extraits du livre
La sécurité informatique en mode projet Organisez la sécurité du SI de votre entreprise (2e édition) Revenir à la page d'achat du livre

Les spécificités de projets sécurité

Introduction

À chaque domaine les projets qui lui sont spécifiques avec des caractéristiques qui lui sont propres. Ainsi, un chef ou un directeur de projet spécialisé dans le domaine public et de la paie, par exemple, saura éviter ou du moins anticiper les écueils les plus courants dans son domaine mais sera démuni lors du pilotage d’un projet de déploiement de cash management international. Il ne connaît pas le domaine bancaire ainsi que les métiers associés.

Dans les paragraphes suivants, c’est ce que nous allons présenter : quelques projets en sécurité typiques et classiques, les pièges à éviter ainsi que les bonnes pratiques à mettre en œuvre.

Nous irons du projet de déploiement d’un antivirus au pilotage d’un Plan de Reprise d’Activité (PRA) en passant par la mise en œuvre de ce plan.

Le PRA est un projet complexe qui donne lieu à un ouvrage dédié aux éditions ENI : Plan de Continuité d’Activité - Concepts et démarche pour passer du besoin à la mise en œuvre du PCA.

Nous avons sélectionné des exemples de projets essentiellement techniques. Mais, comme nous l’avons vu, la protection de l’information est transverse à l’entreprise et ne représente qu’une partie des sujets...

Les bons réflexes à appliquer

1. Les principes directeurs

La liste ci-dessous est une somme de bons réflexes qu’il convient, suivant les besoins et la taille du projet, d’appliquer en totalité ou de façon partielle. Cela dit, dans tous les cas, vous devez vous poser la question de l’applicabilité de chacun de ces principes.

  • Un projet est placé sous la responsabilité d’un chef de projet ou, selon les cas, d’un responsable métier. Ce responsable est garant de l’intégration de la sécurité lors du projet et du respect de l’application de la présente instruction.

  • Le responsable du projet doit associer les équipes sécurité dès le début et à chaque étape du projet.

  • Tout projet ou application doit faire l’objet d’une démarche sécurité adaptée à son niveau de sensibilité, dont les risques résiduels et le plan d’action doivent être acceptés par le responsable métier avant mise en production.

  • L’externalisation de tout ou partie du projet doit être spécifiquement prise en compte lors de l’analyse de risque.

  • Les jalons sécurité, ainsi que les livrables correspondants (QES, soit Questionnaire d’Évaluation de la Sensibilité, dossier de sécurité, audit de sécurité, fiche d’objectifs de sécurité...), sont à intégrer dans la gestion de projet.

2. Durant la "préparation de projet"

  • La démarche sécurité doit être initiée dès le début du projet. Cela se concrétise par la rédaction d’un QES.

  • Ce questionnaire doit être réalisé durant les phases d’étude d’opportunités et de cadrage à l’initiative du chef de projet, en collaboration avec la filière SSI concernée, validé par le responsable métier, et mis à disposition du RSSI. Un comité projet doit s’assurer du remplissage et de la validation du QES avant la fin du cadrage.

  • Toute application sensible doit disposer d’un dossier de sécurité. Dans les autres cas de sensibilité remontés par le QES, le RSSI doit déterminer s’il...

Quelques exemples de projets sécurité et leurs spécificités

1. Déploiement antivirus

Vous recevez de bon matin cet e-mail, avant le premier café d’une longue série...

"Michel, on en a marre des virus sur nos postes, fais quelque chose, tu as deux semaines... La Direction"

Déployer un antivirus, oui bien sûr... mais pas si simple. Un antivirus, c’est quoi :

  • Un logiciel par poste de travail ?

  • Des logiciels sur les postes informatiques et un logiciel sur un serveur ?

  • Des mises à jour manuelles ou automatiques ?

  • Des mises à jour obligatoires ou facultatives ?

  • Avec un firewall inclus ?

  • Que devra faire l’utilisateur quand l’antivirus l’informera d’un virus ?

  • À quels risques l’entreprise est-elle exposée si elle n’a pas le support de l’éditeur en cas d’attaque (outil gratuit sans support, outil payant dont la licence a expiré, version obsolète, etc.) ?

  • De combien de temps, de ressources, aurai-je besoin pour installer mes 80 antivirus sur les postes de travail ?

Si vous ne vous êtes jamais posé ces questions, il est fort probable que votre projet de déploiement s’avère compliqué et chronophage.

Nous ne le répéterons jamais assez : posez-vous, préparez, exprimez votre besoin, écrivez-le dans un cahier des charges. La solution technique viendra s’imposer d’elle-même. Faire cela, c’est déjà répondre à l’étape 1 : la préparation de projet.

Une fois cette réflexion faite, vous vous rendez compte que votre besoin d’entreprise est bien spécifique, il prend en compte les impératifs de votre société.

Vous avez compris et analysé la demande :

  • On vous a donné un objectif : installer des antivirus sur tous les postes de la société.

  • Vous avez détecté une contrainte de temps : deux semaines.

Vous disposez donc de deux des trois composantes du triangle projet : le périmètre, et le temps.

images/09DP001.png

Vous devez maintenant définir la dernière composante du triangle : préparer le prévisionnel financier. Votre objectif sera de faire valider ce "triangle projet"...

Des difficultés propres à chaque secteur d’activité

1. L’exemple du secteur de l’édition logicielle

L’éditeur de logiciel produit "le code source", c’est-à-dire toutes les lignes de code informatique qui constituent l’essence d’un logiciel. Son principal effort de sécurisation doit logiquement se porter sur ce point.

Ce code source doit être protégé de plusieurs attaques qui peuvent être de différents types (technique ou juridique). L’entreprise mise à mal cherchera un coupable. En interne, c’est le RSSI ou le responsable informatique qui sera mis en cause.

La protection qu’il doit mettre en œuvre dépend de la façon dont l’entreprise diffuse son logiciel. Différentes protections peuvent être mises en place.

Pour les envisager, il faut comprendre et connaître la stratégie de diffusion de l’entreprise. Selon les approches commerciales, on observe deux modèles :

  • Le logiciel seul.

  • Le logiciel et le code source.

Dans le premier cas, prenons un malheureux exemple vécu : l’entreprise X achète un logiciel à Y. Les locaux de Y brûlent, emportant avec eux matériel et sauvegardes informatiques. Tout le code est perdu, Y n’y survit pas. Y ne peut plus assurer ni la maintenance, ni l’évolution.

Dans ce cas, il est aisé de comprendre qu’une banque, un industriel du CAC 40 achetant un logiciel à un éditeur, va vouloir se garantir de la pérennité de la mise à disposition du code source en cas de cessation d’activité. Et ceci afin de toujours pouvoir faire évoluer le logiciel par rapport à son besoin.

Dans cet exemple, le RSSI va devoir mettre en œuvre des solutions de stockage externalisé de code source avec une société spécialisée.

Son action consiste par exemple à formaliser un contrat en collaboration avec un prestataire spécialiste, qui stipule que seuls certains clients bien définis pourront bénéficier de l’accès au code source en cas de cessation d’activité de l’entreprise. Dans cette situation le code est régulièrement stocké sur un média (CD, DVD, etc.) et est envoyé...

Conclusion

Au travers de sept projets "sécurité" classiques, nous avons voyagé entre plusieurs couches du SI en mettant en avant les principaux freins ou les principales difficultés que vous pourriez rencontrer.

Des difficultés humaines qui demandent de l’accompagnement au changement, des difficultés techniques qui demandent de l’expertise, des difficultés organisationnelles qui demandent des connaissances sur l’entreprise et son fonctionnement.

Vous le constatez, gérer un projet en sécurité informatique ne demande pas uniquement des connaissances d’expert en sécurisation de bases de données ni d’être un gourou du paramétrage des pare-feu. Mais bel et bien des connaissances méthodologiques, managériales, politiques, juridiques, techniques, etc., ainsi qu’une énorme capacité "d’écoute active", c’est-à-dire une compétence pour entendre, comprendre un métier dont on n’est pas l’expert, reformuler ses besoins réels, les vulgariser et sensibiliser les utilisateurs.

Nous sommes aujourd’hui entourés de numérique, et notre vie privée ne l’est plus réellement pour qui possède un compte Twitter, Facebook… La sécurité des SI mais surtout de l’information est de plus en plus cruciale....