Maintenir la conformité PCI DSS au sein du SI

Le véritable challenge après avoir atteint le nirvana de la Conformité PCI DSS est de la maintenir dans le SI existant qui lui continuera à évoluer dans le cadre de son exploitation. Il faut s’assurer que l’ensemble des contrôles sur les composants PCI DSS soient correctement mise en oeuvre dans la bulle PCI. (Bon courage…).

Je propose à travers cet article quelques conseils/idées pour maintenir cette conformité sans mettre des batons dans les roues des équipes informatiques & métiers. La difficulté forte sera de convaincre le Directeur Général et le Directeur Financier du coût de maintient de la plateforme PCI DSS qui n’est pas à négliger. Ceci fera parti d’un autre article.

Etape N°1 : Mettre en place une équipe PCI 

Un responsable/référent du programme PCI DSS doit être nommé dans l’entreprise. Il aura pour tâche de suivre les actions de sécurité à travers les responsables de chaque composant PCI (Business Unit, Filiales…). Celui-ci doit disposer d’une autonomie forte par rapport aux métiers et la DSI. Il est souhaitable qu’il soit challenger par un N-2/N-3 au maximum. Ayant un rôle transverse, il devra savoir manier l’art de la diplomatie et rester ferme par rapport aux contraintes de la norme PCI DSS et la PSSI (Sensibiliser, former, partager sur la norme PCI DSS et maintenir au respect de la PSSI en ce sens).

Un référent PCI DSS dans chaque Business Unit (Ex. Responsable Infra, Responsable Réseaux, Responsable Application métier…). Il sera le coordinateur entre les recommandations et exigences du Responsable PCI DSS et ses équipes. Il aura une forte sensibilisation sur PCI DSS et portera la responsabilité de maintenir dans son périmètre la conformité PCI DSS (Je vois d’ici la tête de certains…je peux aussi leur proposer ma méthode mais on m’a encore précisé que les pertes humaines n’étaient pas acceptable dans l’entreprise…je suis convaincu qu’avec un petit 3% de perte on pourrait motiver les troupes 🙂 )

Etape N°2 : Appliquer les contrôles

L’ensemble des controles sur une plateforme PCI DSS peut se résumer dans la majorité des cas à ceux-ci:

S’assurer que les composants de sécurité soient bien opérationnels comme les Firewall, les sondes IPS/IDS, le FIM (intégrité des fichiers sensibles), durcissements des socles, les anti-virus quand cela s’applique, les contrôles d’accès, la sécurité physique…

Verifier que toutes défaillances soient détectées et résolues dans un délai court. Ne pas hésiter à s’appuyer sur les processus de changements de l’entreprise si elle suit la norme ITIL c’est encore mieux (CAB, ECAB) et intégrer la problématique PCI DSS dans ceux-ci. On maintient les processus existants et on les fait évoluer avec les exigences PCI DSS.

La résolution d’un incident de sécurité doit comporter au minima les points suivants:

• Restauration des contrôles de sécurité,
• Identification de la vulnérabilité/faille (Suis je Impacté, non impacté, mesure compensatoire…),
• Le suivi et la résolution de l’incident de sécurité dans l’outil de gestion du changement,
• Le suivi et l’amélioration des processus pour éviter un nouvel incident de sécurité,
• Le suivi de la résolution de l’incident dans le temps (période de surveillance accrue après l’incident…).

et bien entendu la reprise des contrôles des composants PCI DSS après l’application des mesures.

La gestion du changement fait partie intégrante de la mise à jour permanente de la plateforme PCI DSS. La gestion du changement doit faire partie d’une surveillance permanente dans le respect des processus PCI DSS. Pour les grands comptes, on n’hésite pas à s’appuyer sur la gestion des changements existants et les comités d’architectures techniques & fonctionnelles des composants PCI DSS (Ici commence un rôle de contrôle Interne…). Pour les petites structures, on suit chaque changement obligatoirement…et on implique FORTEMENT le responsable technique (Ne pas hésiter à lui mettre des objectifs forts chaque année, maintien de la conformité…)

• Appréhender et déterminer les changements sur la bulle PCI DSS (Ouverture de Flux, installation d’un nouveau serveur et d’une application, VPN…).
• Identifier la nature du changement et son impact par rapport à la norme PCI DSS en place dans le SI (Durcissement du socle, Documentations, Règles de Firewall, centralisation des logs, mise en oeuvre du FIM, Mises à jour « Patch Management », obsolescence des composants », ajouts dans les scans et tests d’intrusions…).
• Mettre à jour l’ensemble des processus de changement suite à l’évolution de la norme. Dans mon cas de la 2.0 à la 3.0. On ne fait pas les Scan de la même façon par exemple.

La gestion des changements organisationnelles rentre aussi en ligne de compte. Lors de l’intégration (Rachat, cessions, fusions) d’une entreprise, le périmètre PCI DSS doit être revu en particulier lors de la mise à disposition de la consultation des PAN (Centre d’appels, support niveau 2…). Cette action appartient au responsable du programme PCI DSS.

Ces contrôles sont périodiques et facilement panifiables.  Ils portent sur la sensibilisation et la formation des personnels sur la norme PCI DSS dans le cadre de leurs missions. On vérifie aussi que le corpus documentaire soit à jour (échantillonnage par trimestre par exemple) ainsi que le suivi de la norme :

• Mise en pratique des règles de durcissements.
• Scan trimestriel sur l’ensemble des composants.
• Applications des mises à jours.
• Applications des correctifs de sécurité.
• Analyse des fichiers journaux (log).
• Suivi des changements PCI (Traçabilité).

L’ensemble des contrôles permet de vérifier que l’ensemble des preuves soient à jour ainsi lors de l’audit annuel, nous pouvons afficher un taux de confiance fort, baisser les coûts de remédiations et CONSERVER notre conformité PCI DSS.

Un travail conséquent et à ne pas négliger est l’examen de l’ensemble des composants technologies (Hardware, Software) au minimum une fois par an. Ce travail d’inventaire demande une mobilisation des référents PCI DSS. Les contrôles portent sur l’obsolescence des composants, la mise à jour de ceux-ci, l’application des correctifs…en cas de non conformité on lance le plan de remédiation pour mettre à niveau le composant.

Conclusion

On peut ajouter que pour les organisations d’une certaine taille, il est fortement recommandé de séparer les rôles sur le contrôle et les actions de sécurités. Il ne faut pas hésiter à s’appuyer sur l’Audit Interne pour le contrôle et différencier le coté Opérationnel. Je déconseille fortement qu’une seule personne soit de bout en bout responsable du Contrôle, de l’application de la mesure et de la validation de celle-ci.

La formation ainsi que la sensibilisation de la norme PCI DSS font partie d’un travail de fond recurrent et le responsable PCI DSS doit avoir une casquette d’évangéliste en ce sens (Communiquer fait partie du job à 200%, si vous avez des problèmes avec les humains…retourner faire du développement  Cobol cela vous évitera des migraines…).

Voila pour ce premier article sur le maintien de la conformité PCI DSS…

Enjoy 🙂