26/09/2013

PCI DSS 3.0 : sécurité système

Première nouveauté, le standard exige désormais qu'un inventaire du CDE soit maintenu à jour : "2.4 Maintain an inventory of system components that are in scope for PCI DSS".

Même si cela était déjà certainement le cas, l'audité devra fournir au QSA, avant l'audit, un tableau détaillé des hardwareset des logiciels installés. Le niveau de détail attendu dépendra alors du QSA. Un simple listing de type rpm -qa ne sera pas suffisant, un inventaire synthétique et cohérent sera attendu.


Ensuite, le PCI DSS 3.0 clarifie que si un service non-sécurisé est nécessaire (exemple : TN3270, FTP, NetBIOS, Telnet), une couche de chiffrement doit être ajoutée : tunnel SSL, tunnel VPN, etc...

Le sujet des anti-virus n'évolue que très peu. Le standard attends maintenant que l'entité auditée justifie d'une véritable veille sur l'évolution des virus sur les systèmes mis volontairement hors-scope (MacOS, Linux, AIX, z/OS...). 

Le 3.0 devient plus cohérent pour ce qui est du patch-management (PCI DSS 6.2). La distinction entre les patchs critiques affectant des systèmes à risque est dorénavant faite avec les patchs pour les systèmes de back-offices. La période de 3 mois apparait comme assouplie en devant un simple exemple "[...]within an appropriate time frame (for example, within three months)."

L'utilisation des clés SSH, qui était jusque là pas forcément très claire, est désormais clairement prise en compte : une clé SSH doit impérativement être associée à un compte unique (nominatif) et être protégée par une sécurité (une passphrase).

Enfin, au niveau des logs, le 3.0 précise qu'il faut désormais tracer les modifications de droits : Par exemple, si un compte est ajouté à un groupe "Adminstrateurs", cela doit être tracé dans les logs.

Un grand nombre de petites clarifications existent, je vous recommande de vous rapprocher de votre QSA pour en comprendre les impacts sur vos systèmes.

Aucun commentaire:

Enregistrer un commentaire