18/11/2015

Eviter l'échec d'un projet PCI DSS

Lorsque je présente les contraintes PCI DSS, je constate souvent réside que le client ne lit pas le standard et base ses actions sur des informations erronées.

Ces ont-dit sont diffusés par les vendeurs de logiciel/boitiers, admins, blogs, consultants, détracteurs du standard et même parfois par des QSAs qui imposent plus que le standard n'impose !

Je recommande au client de toujours se reporter au texte original pour discuter avec son QSA et ses collaborateurs sur des bases solides. La lecture détaillée du texte est l'un des moyens pour éviter l'échec d'un projet PCI DSS.

Je propose ici un petit exercice de lecture concernant le fameux patch-management :

Texte extrait du document PCI DSS 3.1 publié par le PCI SSC (Avril 2015) : Exigences 6.1 et 6.2

Applicable critical vendor-supplied security patches are installed within one month of release.

All applicable vendor-supplied security patches are installed within an appropriate time frame (for example, within three months).

Prioritizing patches for critical infrastructure ensures that high-priority systems and devices are protected from vulnerabilities as soon as possible after a patch is released. 

Note: Critical security patches should be identified according to the risk ranking process defined in Requirement 6.1.  Methods for evaluating vulnerabilities and assigning risk ratings will vary based on an organization’s environment and risk assessment strategy. 

Plusieurs mots me semblent très importants :

  • applicable : il s'agit donc des patchs pour des composants installés sur le système du CDE.
  • security patches : il s'agit des patchs de sécurité, ceux qui corrigent une faille, et non de tous les patchs et mises à jour diverses.
  • appropriate time frame : le client peut donc ici définir la période qui lui semble appropriée pour installer le patch.
  • as soon as possible after a patch is released : ASAP ne veut pas dire immédiatement.
  • for example : un exemple reste un exemple.
  • will vary based on an organization : la méthode de ré-évaluation de la criticité d'un patch varie donc entre les entreprises.

J'espère que cet exercice donnera l'envie d'adopter le reflex de lecture du standard.

Aucun commentaire:

Enregistrer un commentaire