Accueil / Les articles WELIOM / L’INTÉGRATION DE LA SÉCURITÉ DANS LES PROJETS OU COMMENT BIEN FAIRE LES CHOSES DÈS LE DÉPART ?

L’INTÉGRATION DE LA SÉCURITÉ DANS LES PROJETS OU COMMENT BIEN FAIRE LES CHOSES DÈS LE DÉPART ?

Dans une précédente publication (cf. Guide cyber-résilience APSSIS – Opus 6), nous discutions de l’implémentation d’une gouvernance de Sécurité et du rôle du RSSI dans cette démarche. Nous avons pu voir que les qualités requises pour un RSSI sont nombreuses mais nous nous arrêterons aujourd’hui sur l’une d’entre elles : l’anticipation. La gestion des risques pour la Sécurité de l’information devrait, ou doit, être considérée dès la phase d’un nouveau projet informatique, quelle que soit sa nature (intégration d’une nouvelle solution, d’un nouvel équipement, une migration, etc.) C’est le principe de l’Intégration de la Sécurité dans les Projets (ISP), un pilier essentiel de l’approche de la « Security by Design ». Le principe est simple : bien faire les choses dès le départ.

Par Brice SIMON et Xavier JUNG, Consultants WELIOM

Textes, référentiels et normes

Et ça ne date pas d’hier puisque la majorité des textes, référentiels et normes pour la sécurité de l’information intègrent cette mesure :

• Annexe A ISO 27 001 inclue au référentiel de certification HDS : « Il convient de traiter la sécurité de l’information dans la gestion de projet, quel que soit le type de projet concerné » (§A.6.1.5)
• PGSSI-S : « Toute modification technique ou applicative du SI doit faire l’objet d’une spécification formalisée dans un cahier des charges, qui prenne en compte les aspects SSI liés au périmètre concerné du SI, sans omettre les points relatifs à la sauvegarde des données et à la continuité de fonctionnement » (§6.5.1.1) – A noter que la PGSSI-S découle des référentiels de PSSI-E puis de la PSSI-MCAS, qui énoncent évidemment des exigences pour l’ISP.
• INSTRUCTION N°SG/DSSIS/2016/309 : « Etablissement d’une procédure formelle d’appréciation du risque avant toute mise en production d’un SI (homologation) » (§2. Mesures de priorité 2 à mettre en place dans les 12 mois)

Ce que cela implique

La stratégie d’intégration de la sécurité dans les projets peut prendre différentes formes pour un établissement de santé mais de manière très simplifiée, la démarche à suivre devrait s’apparenter à cela :

Se tenir informer des projets

Et oui… pour sécuriser les projets, il faut évidemment les connaitre (et ce n’est pas toujours si facile). Le RSSI doit déterminer un moyen de communication avec les métiers pour recenser les projets informatiques en cours et à venir.

Apprécier les risques pour la Sécurité de l’Information

Une étude des risques doit ensuite être co-réalisée avec les métiers. Le RSSI doit accompagner les acteurs du projet dans cet exercice, leur fournir une méthodologie et un outil adéquat. C’est aussi ici que le métier pourra rappeler les besoins en sécurité pour son projet.

En découle un plan de traitement des risques.

Conseiller et orienter les acteurs du projet

En s’appuyant sur l’appréciation des risques, le RSSI émet des conseils et recommandations quant à la suite du projet. Il peut également proposer de nouvelles orientations.

Valider (homologuer) le projet

Conscient des risques pour la sécurité et des recommandations fournies par le RSSI, le métier valide ou non son projet. S’il le valide, cela signifie qu’il en accepte les risques résiduels issus de l’analyse des risques.

Suivre la sécurité tout au long du cycle de vie du projet

Suite à cette décision, le RSSI prend en compte ce projet dans sa stratégie de pilotage des risques. Il pourra apporter des solutions pour sécuriser certains aspects du projet. Exemple de la contractualisation avec la mise à disposition des modèles de clauses adéquates (de sécurité et de réversibilité) ou encore du suivi de l’implémentation d’une fonction d’authentification forte dans une solution métier.

Les bénéfices d’une telle démarche

N’oublions pas qu’une telle démarche est bénéfique pour toutes les parties :

• Le RSSI puisqu’il participe à la sécurisation du projet, ou du moins il en est informé et connait les risques pour la sécurité de l’information.
• La DSI car elle ne sera pas appelée en urgence par le métier pour déployer son projet informatique 
• Le métier lui-même parce que la DSI et le RSSI auront pris les dispositions suffisantes pour atteindre les objectifs de sécurité définis en amont

Sur le plus long terme, les bénéfices pour la sécurité sont non-négligeables :

• Une acculturation et responsabilisation des métiers à la sécurité (diffusion d’une culture sécurité)
• Une meilleure connaissance du SI et des actifs (inventaire)
• Et donc une meilleure maîtrise de la sécurité des actifs dans le temps (maintien à jour des versions, mise à niveau des OS, déploiement de l’antivirus, etc.)
• Etc.

La mise en œuvre de la sécurité dans les projets est un levier essentiel qui permettra de réduire, petit à petit, le retard accumulé ces dernières années. La sécurité n’a pas pu suivre la croissance exponentielle des besoins métiers en matière d’informatisation de solutions. Les établissements exploitent aujourd’hui des équipements et solutions, biomédicales notamment, qui ne peuvent fonctionner qu’avec une informatique obsolète et vulnérable.

Le RSSI dépense aujourd’hui de l’énergie à combler les brèches ouvertes dans le passé. Pour les refermer il doit… 

• Croiser les doigts et attendre patiemment que les actifs obsolètes soient retirés du SI – N.B. : suite à la cyberattaque du CHSF, l’établissement a pris la décision de renouveler son parc d’équipements sensibles et obsolètes : un chantier estimé à 1,8 millions d’euros.
• Travailler dès maintenant avec les métiers et la DSI pour diffuser la sécurité dans les nouveaux projets

Un exercice loin d’être évident dans le contexte où les fabricants et éditeurs ne font pas encore de la sécurité un avantage concurrentiel !

L’article DSIH