dimanche 31 août 2014

Ou bien partir en Août ?

Voici donc la rentrée et bientôt les congés
pour certains d'entre nous qui avons constaté,
en vigies estivales malgré le mauvais temps,
que ce mois passé d'août n'avait rien à envier
à ce mois de juillet pour sa sécurité
avec des patchs banals qui reviennent souvent.

Une première semaine calme


Nous pensions (espérions) avoir le temps de souffler un peu après la dernière semaine de juillet ... mais non. Le 4 août sort la version 7u67 de Java (rappelez vous que la mise à jour précédente date du 15 juillet pour le CPUJUL Oracle), le 6 août est publié un nouveau bulletin de sécurité pour OpenSSL (9 CVE), le 7 août se voit accompagné d'un fix Java pour Puppet Entreprise suite au CPUJUL Oracle et pour ceux d'entre vous qui travaillent dans notre petit monde du web, nous assistons à une publication jointe et coordonnée entre Drupal et Wordpress le 6 août (merci à eux de la part des sysops avec qui je travaille pour cette initiative ^^) qui se trouve être corrigée le même jour (7 août) par Ubuntu et Debian par exemple.

12 août 2014 - Patch Tuesday Microsoft, Adobe Flash Player et Adobe Reader


(Comparons donc avec juillet) Microsoft et Adobe publient leur "patch tuesday" le 12 août. Microsoft fixe des vulnérabilités critiques (dont un bulletin critique pour Internet Explorer 6/7/8/9/10/11 qui fixe "one publicly disclosed and twenty-five privately reported vulnerabilities in Internet Explorer") : avantage Août (25 vs 24). Adobe fixe quand à lui des vulnérabilités critiques pour Adobe Flash Player (7 CVE) et Adobe Reader sous Windows (avec un exploit reporté "in the wild") : avantage Août à nouveau (Adobe Reader). Notons finalement que Google Chrome est mis à jour le 12 août également pour le composant Flash mais intègre aussi 12 correctifs de sécurité : avantage août encore une fois (12 correctifs).

Nous n'avons pas de patch trimestriel Oracle ce mois-ci (heureusement) mais la semaine Patch Tuesday n'est pas terminée avec un bulletin OpenJDK6 pour Ubuntu le 12 août, une mise à jour pour Safari 6.1.6 / 7.0.6 le 13 aout, une mise à jour PHP en 5.3.29 (pour correspondre aux publications 5.4.31/5.5.15 du 24 juillet) le 14 août.

3ème semaine - Ne perdons pas le rythme


Pour ceux qui l'attendent, Ubuntu publie enfin son bulletin OpenJDK7 le 19 août (qui correspond au bulletin Debian DSA-2987 du 23 juillet) et fait une mise à jour de correction de régression le 25 aout, Oracle publie des bulletins pour Solaris 11.2 le 19 aout et Debian publie un bulletin PHP5.4 le 21 aout alors que PHP publie ses versions 5.5.16 et et 5.4.32 le même jour.

4ème semaine - la rentrée s'approche


Mise à jour de Chrome le 26 aout (deuxième en moins d'un mois !) avec pas moins de 50 correctifs de sécurité, re-publication du MS14-045 le 27.08 (pour correction d'instabilités sur ce bulletin initialement publié lors du patch tuesday du 12.08) un bulletin Squid3 (SQUID-2014_2 : déni de service) publié le 28 (USN le 27.08 ?, DSA le 28.08, pas de RHSA au 31.08 ?) et publication de PHP 5.6.0 le 28 août qui nous permet d'assister à une mise à jour de toutes (?) les versions de PHP (5.3, 5.4, 5.5, 5.6) en août.

Et ne passons surtout pas à côté de mon message subliminal de juillet suite à la demande sur OSS-SEC de CVE le 29 juillet (cherchez "[CVE Request] glibc iconv_open buffer overflow" pour ceux qui sont intéressés par le message subliminal) avec la publication en réponse de l'exploit correspondant (cherchez "CVE-2014-5119 glibc __gconv_translit_find() exploit") le 25 août par la "Project Zero team at Google". A noter la publication rapide des correctifs : DSA-3012-1 le 27 août, USN-2328-1 le 28 août, RHSA-2014-1110 le 29 août.

Et ma Debian-LTS ?


Et bien ma debian-lts a eu la chance de voir publiée le 6 aout la version openssl 0.9.8o-4squeeze17 suite au bulletin de sécurité OpenSSL du même jour (intégration le lendemain pour Debian stable et Ubuntu :p).

Et maintenant ?


Et maintenant, je souhaiterais conclure ce mois d'aout avec deux cas illustrant ce besoin de veille opérationnelle (on me dit souvent : "mais tout est déployé automatiquement" auquel je répond : "comment vous-en assurez-vous ? par quel contrôle ? quels sont vos garde-fous ?") :
  • La réponse le 7 aout de l'orchestrateur Chef (getchef.com) au bulletin OpenSSL du 6 aout qui précise : "Chef Software has reviewed the following security advisory and does not believe that this represents a critical security risk to our users" et qui est bien plus appréciable que l'absence (volontaire ou non) de réponse par certains éditeurs en absence de bulletin.
  • La différence entre Debian et Ubuntu par exemple pour Samba avec le CVE-2014-3560 ayant fait l'objet du bulletin USN-2305-1 le 1er aout et d'une saisie de bug (#756759 le 3 aout) car déjà fixé et qui témoigne bien de la difficulté de pister les vulnérabilités au sein des Systèmes d'Information pour des composants qui, paradoxalement, pourraient sembler proches de prime abord.

Jess - @JessicaGallante

PS : Toujours un grand merci @helpacsoout et @philoupas ! et spéciale dédicace à ma @nathplanteur :)

mardi 12 août 2014

PCIDSS 3.0 Tips and Traps

par Jessica Gallante et Nathalie Planteur

Disclaimer : Nous ne sommes pas QSA et cet article ne reflète aucunement les opinions de notre employeur et patati et patatrap. Nous avons composé cet article à 4 mains dans le seul objectif d'animer la #PCIDSS avec un peu de #HipHop car "qui prétend faire de la PCIDSS sans prendre position ?".

Respecter le standard PCIDSS exige une certaine agilité d'esprit ou un certain aveuglement. Vous pouvez ainsi choisir d'être purement "conforme" (donc pas Business As Usual) ou bien de respecter l'esprit de la norme pour améliorer progressivement l'ensemble des mécanismes organisationnels et techniques concourant au maintien en conditions de sécurité optimales de votre Système d'Information (si vous bondissez déjà en lisant ces quelques lignes c'est que vous avez déjà choisi votre camp ou que - QSA ou auditeur 27x - vous aiguisez vos plus belles lames pour pourfendre ...).

Bref, il est souvent reproché (et nous sommes les premières à en faire partie) au standard de ne pas inclure tel ou tel éclaircissement, telle ou telle exigence ... Véritablement, ceci ne pose problème que si vous vous concentrez exclusivement sur une stricte conformité (avec des coûts réduits au maximum tout en conservant une conformité fil du rasoir) sans réfléchir aux meilleurs moyens de protéger les données cartes que votre Système d'Information transporte, traite et stocke.

Deux points essentiels sont ainsi à garder en tête selon nous :
  • N'oubliez pas que le standard vise à protéger les données cartes (nous utilisons cette expression par facilité pour regrouper CHD et SAD) et n'a aucunement pour objectif de protéger vos fichiers clients/patients ou les ordinateurs portables de votre Direction Commerciale ou de votre Directeur Général.
  • Travaillez avec votre QSA et (surtout) pas contre lui. Tous les QSA que nous avons eu la chance de rencontrer étaient des professionnels du standard et de ses pièges et tous étaient experts dans un domaine organisationnel et/ou technique précis. Profitez donc de leur expérience pour échanger et construire votre conformité et ne visez pas un simple tampon sur votre futur ROC.
Nous sommes intimement convaincues (et donc peut être partiales dans notre discours) que l'application du standard représente un _plus_ fondamental dans le dispositif de contrôle des établissements concernés : il est ainsi nécessaire d'évaluer périodiquement les risques, de maintenir un niveau de sécurité organisationnels et technique optimal pour se prémunir de ces risques, d'organiser et tracer tous les changements organisationnels et techniques des environnements concernés, de surveiller les pistes d'audit et les évènements anormaux se produisant, de sensibiliser les collaborateurs, etc. Retenez néanmoins que tout ceci ne doit jamais être bloquant pour votre business (hors non conformité flagrante bien entendu).

Deux autres critères à retenir sont donc selon nous :
  • N'alourdissez pas outre mesure votre organisation de process fonctionnels : il est tout à fait possible de respecter l'esprit de la norme sans allonger drastiquement les délais de recette et passage en production ou augmenter significativement les coûts de fonctionnement de votre Direction Informatique.
  • Choisissez finement qui sera votre responsable de la conformité PCIDSS et préférez de prime abord un collaborateur ouvert et apprécié de l'ensemble des lignes métier et support de votre organisation. Une expérience en tant qu'auditeur sera évidement un plus non négligeable (pour reconnaitre les questions pièges quand celles-ci se présentent). Notre conseil à nous ? Choisissez quelqu'un de #HipHop, c'est déjà c#%}^Wcompliqué d'appliquer la norme, autant le faire dans la bonne humeur.
Après tous ces entrechats (sont là) et issus de notre propre expérience terrain des deux dernières années passées à voir et revoir (et revoir ... et revoir ... au revoir) divers environnements PCIDSS chez divers clients, nous vous proposons une liste choisie de "Tips and Traps" à parcourir et cocher entre amis. Pour les connaisseurs ou vous qui nous lisez (écrivez) sur Twitter, vous aurez certainement le sourire aux lèvres en pensant aux âpres débats et négociations en interne ou avec vos QSA et pour ceux qui nous découvrent et qui souhaitent échanger, n'hésitez pas à nous contacter.

Jess (@JessicaGallante) et Nath (@NathPlanteur)

PS : Un grand merci à @helpacsoout qui nous a suggéré d'écrire cet article après nos échanges sur Twitter et à @AdBaz1 pour la relecture.

PPS : "We #PCIDSS-ize either for #Compliance or for #Infosec. Looking for compliance only? theres a lot that PCIDSS cant fix".

Build and Maintain a Secure Network and Systems


Le premier ensemble d'exigences ("1. Install and maintain a firewall configuration to protect cardholder data" et "2. Do not use vendor-supplied defaults for system passwords and other security parameters") présente bien les trois problématiques qui sont pour nous caractéristiques de la démarche à mettre en oeuvre.
  • La connaissance (et la justification) de votre périmètre PCIDSS : l'exigence #2.4 impose de maintenir un référentiel/inventaire de tous les composants considérés comme in-scope, ceci vaut donc pour tous les composants applicatifs, système et réseau composant le CDE mais également pour tous les composants annexes - qui ne sont ni dans le CDE ni en frontière de celui-ci) donc la réduction du niveau de sécurité ou la compromission peut affaiblir ou permettre de compromettre un composant typé CDE. La difficulté résidant dans la pérennisation de ce référentiel au gré des évolutions fonctionnelles et techniques impactant le Système d'Information.
  • Le respect de l'esprit de la norme et non la juste conformité à celle-ci : l'exigence #1.1.3 implique de représenter les flux de données concernant les données cartes sous forme de diagrammes (?) pour les aspects réseau et système. Ces diagrammes ne doivent pas être simplement formalisés juste avant l'audit pour être conforme, ils doivent servir de base de travail aux diverses exigences imposées par le standard (évolution des analyses de risques en fonction des besoins métier, mises à jour des systèmes et réseau au gré des évolutions imposées par le Schéma Directeur Informatique, etc.).
  • La sujétion de la norme PCIDSS à la législation ou à la règlementation locale : l'exigence #1.4 requiert l'installation de pare-feu personnels sur les ordinateurs personnels (et mobiles etc.) des collaborateurs si ceux-ci sont à la fois utilisés au sein et en dehors du Système d'Information. La problématique qui se pose alors concerne l'application de règles propres à l'entreprise sur les dispositifs numériques personnels des employés.

Protect Cardholder Data


Le second ensemble d'exigences ("3. Protect stored cardholder data" et "4. Encrypt transmission of cardholder data across open, public networks") illustre trois autres challenges qu'il convient d'appréhender.
  • Bien mesurer que tous les processus de contrôle doivent faire l'objet de pistes d'audits, de traces, de comptes rendus archivés et conservés pour présentation au QSA : l'exigence #3.1 impose ainsi de conserver les comptes rendus d'analyse trimestrielle de rétention des données cartes après expiration et ce même si vous savez pertinemment qu'aucune donnée carte conservée par devers vous n'a excédé la période maximale pour laquelle vous êtes autorisés à les conserver.
  • Bien comprendre que tous les processus de segmentation imposés par le standard ont pour objectif de durcir au maximum les données cartes transportées, traitées ou stockées : l'exigence #3.4 exprime clairement qu'il est trivial de reconstruire les PAN lorsque l'on dispose à la fois de la version tronquée et hachée d'un même enregistrement.
  • Bien comprendre que les interdictions imposées par la norme doivent évidement être observées en compromis des besoins métier : l'exigence #4.2 précise ainsi qu'il est interdit de transmettre des PAN en clair par messagerie instantanée sauf si les PAN sont rendus illisibles ou sont sécurisés par des moyens cryptographiquement robustes.    

Maintain a Vulnerability Management Program


Le troisième ensemble d'exigences ("5. Protect all systems against malware and regularly update anti-virus software or programs" et "6. Develop and maintain secure systems and applications") expose un certain nombre d'impératifs techniques à respecter qui peuvent amener à des non conformités pourtant facilement évitables pour autant qu'un processus organisationnel de gestion des vulnérabilités soit convenablement implémenté et respecté :
  • Contrairement aux idées reçues, le standard impose par exemple avec l'exigence #5.1.2 qu'une évaluation périodique soit menée pour justifier que les systèmes *Nix ne sont pas affectés par des "malicious software" : cette évaluation périodique doit donc être documentée.
  • La conservation des journaux afférents aux mécanismes antiviraux imposée par l'exigence #5.2 précise un respect de l'exigence #10.7 mais la guidance correspondante correspond à l'exigence #10 dans son ensemble : il est donc recommandé de mener une analyse précise sur ce sujet.
  • L'application des correctifs qualifiés comme critiques doit être réalisée sous 30 jours tel qu'imposé par l'exigence #6.2 mais la guidance correspondante précise bien que les correctifs qualifiés avec des niveaux de sévérité inférieurs doivent être installés sous 2 à 3 mois.
  • La mise en œuvre de processus de revue de code tel qu'imposée par l'exigence #6.3.2 nécessite évidement documentation et trace mais également une validation des résultats par le management (les comptes rendus ou procès-verbaux de ces validations pouvant évidement être demandés par le QSA).
  • La mise en œuvre du processus de contrôle des changements nécessite pour l'exigence #6.4.5 une documentation spécifique aux correctifs de sécurité avec à minima une description de l'impact, une approbation formelle et un mécanisme de retour arrière.
  • La formation continue des développeurs aux bonnes pratiques en matière de développement sécurisé doit être documentée et, conformément à l'exigence #6.5c, n'oubliez pas que le QSA interviewera un panel représentatif de développeurs à ce sujet (par exemple pour leurs demander comment ils assurent un traitement sécurisé des données sensibles en mémoire).
  • La revue périodique du niveau de vulnérabilités des applications web publiées sur Internet imposée par l'exigence #6.6 en cas d'absence de dispositif de type WAF doit être réalisée au moins annuellement mais également après chaque changement.

Implement Strong Access Control Measures


Le quatrième ensemble d'exigences ("7. Restrict access to cardholder data by business need to know", "8. Identify and authenticate access to system components" et "9. Restrict physical access to cardholder data") présente de nombreux cas concrets de questions qui pourront être (seront) posées par votre QSA et pour lesquels des non conformités sont également facilement évitables.
  • L'exigence #7.1.3 requiert que les accès soient fournis selon la fiche de poste (ou classification du poste) et la fonction du collaborateur concerné. N'ayez aucun doute sur le fait que votre QSA souhaitera consulter cette classification des rôles et postes en vigueur et qu'il interviewera par échantillonnage un certain nombre de collaborateurs sur ce sujet précis.
  • La réactivation des comptes verrouillés par un service Helpdesk ou administrateur nécessite, selon l'exigence #8.1.7, que l'utilisateur demandant cette réactivation soit formellement identifié/validé avant déverrouillage. A l'identique, il est fort probable que votre QSA vous demande comment vous vérifiez l'identité de l'utilisateur demandant une réinitialisation de son mot de passe tel qu'imposé par l'exigence #8.2.2.
  • L'exigence #8.4 précise que votre QSA interviewera un panel d'utilisateurs et consultera la documentation afférente à votre politique d'authentification pour s'assurer que les utilisateurs disposent de conseils avisés sur les moyens mis à leur disposition pour protéger leur identifiants et mots de passe de connexion au Système d'Information.
  • L'exigence #8.6 précise que les mécanismes d'authentification forte déployés ne peuvent être partagés entre multiples utilisateurs logiques ou physiques et il est donc fort probable que votre QSA procède à des recoupements à des périodes données sur la base des journaux que vous devez avoir conservés. (Exemples types : deux administrateurs connectés simultanément en astreinte alors qu'un seul OTP est consigné ou deux utilisateurs connectés localement alors qu'un seul badge accès physique a été activé).
  • L'exigence #8.7 précise que seuls les DBA sont autorisés à accéder directement aux bases de données. Si vous avez des collaborateurs exclusivement DBA, n'oubliez pas de vérifier que vos Sysops/Webops ne disposent de privilèges similaires ou modifiez leur fiche de fonction/poste pour préciser qu'ils peuvent également assurer ce rôle.
  • L'exigence #9.6.2b précise que votre QSA sélectionnera un échantillon de pistes d'audit pour les medias conservés hors site et qu'il vérifiera, via l'exigence #9.7.1, que vous avez tenu à jour, à minima annuellement, un inventaire exhaustif de tous les médias utilisés au sein du périmètre PCIDSS.

Regularly Monitor and Test Networks


Le cinquième ensemble d'exigences ("10. Track and monitor all access to network resources and cardholder data" et "11. Regularly test security systems and processes") nécessite des collaborateurs de votre Direction Informatique qu'ils disposent d'un bagage sécurité fonctionnel et technique (ou qu'ils soient accompagnés/conseillés). Dans ce cas, cet ensemble d'exigences est pour nous l'un des plus simples à respecter (soit vous appliquez l'exigence soit vous êtes non conforme - nulle possibilité pour se faufiler). Quelques exemples de non conformité qui vous paraitront triviaux mais qui peuvent être néanmoins faciles à oublier.
  • L'exigence #10.3 relative à la traçabilité requiert qu'un certain nombre de critère soit consignés dans les pistes d'audits et détaille une liste précise d'éléments à enregistrer tout en précisant qu'il s'agit du minimum imposé. La guidance de cette exigence précise néanmoins que les pistes d'audits doivent faire l'objet d'enregistrements permettant d'identifier rapidement toute compromission potentielle et avec suffisamment de détails pour savoir qui, quoi, ou, quand et comment. Si les éléments imposés ne sont pas suffisants dans votre contexte, vous devrez donc en paramétrer de nouveaux afin d'être conformes.
  • L'exigence #10.4 relative à la synchronisation temporaire des composants est imposée pour tous les systèmes considérés comme critiques. Bien entendu, les éléments critiques ne sont pas tous composants du CDE ou en frontière de celui-ci. Les composants permettant de répondre à certains exigences précises ou desquels dépendent des fonctions de sécurité annexe sont également concernés (exemple type : serveurs de messagerie électronique ou serveurs DNS).
  • L'exigence #10.5.4 relative à la sécurisation des pistes d'audit précise une modalité spécifique pour la conservation des journaux relatifs aux composants systèmes avec une surface d'exposition externe/publique/internet et indique en guidance que les évènements propres aux technologies sans-fil (Wireless), aux pare-feu, aux DNS et aux serveurs de messagerie sont concernés. Si vous appliquez déjà les préceptes Business As Usual et respectez l'esprit de la norme, vous n'aurez pour nous pas de problème à ce niveau là car vous aurez déjà géré ce cas. Dans le cas contraire, relisez attentivement chaque item.
  • L'exigence #10.6.2 relative à la revue périodique et régulière des évènements de sécurité survenant sur le Système d'Information précise deux cadres de revue : l'un est imposé pour un certain nombre précis d'évènements (eg: sécurité) ou de composants (eg: CDE, critiques, sécurité) alors que l'autre concerne tous les autres systèmes en imposant un sous-jacent respectant l'analyse de risques correspondantes (indice : pensez matriochki). La même exigence impose du processus de revue qu'il intègre la revue des évènements permettant d'obtenir un accès aux systèmes sensibles à partir de systèmes non sensibles (eg: tentatives à destination du scope PCIDSS en provenance de ce qui est non scope PCIDSS).
  • L'exigence #10.8 relatives à la documentation des processus de surveillance impose la formalisation de procédures opérationnelles qu'il serait bon de documenter au plus tôt afin qu'elles soient comprises et connues par les collaborateurs (eg: ne pensez pas que les règles de votre IDS ou la configuration de votre SIEM font office de procédures opérationnelles).
  • L'exigence #11.1 relative à la détection préventives de technologies sans-fil impose qu'une surveillance/revue préventive soit documentée et appliquée et ce même si vos politiques interdisent l'usage de telles technologies (n'oubliez pas de lire attentivement les guidances). De même l'exigence #11.1.2 précise bien que dans le cas où les politiques de sécurité interdisent l'usage de technologies sans-fil, le plan de réponse sur incident doit néanmoins inclure une procédure relative à la détection de points d'accès non autorisés.
  • L'exigence #11.2 est pleine de petits pièges techniques : n'oubliez pas que les scans internes/externes doivent être fait de manière trimestriel mais également après chaque changement significatif (la définition de ce significatif, up to the QSA dirons nous, sera évidement plus simple à formaliser si votre responsable de conformité PCIDSS dispose d'une expérience en tant qu'auditeur). N'oubliez pas non plus que vous avez à répéter les scans une fois que les vulnérabilités sont corrigées (eg : dans un mode de scan trimestriel exclusivement car peu de changements significatifs, n'oubliez pas de tourner les scans de contrôle avant l'échéance trimestrielle).
  • L'exigence #11.2.1 est l'une des exigences que nous affectionnons dans ce standard et qui impose que les audits de vulnérabilité internes soient réalisés par des équipes/collaborateurs qualifiés et raisonnablement indépendants. Pour nous, un collaborateur qualifié n'est pas un simple utilisateur qui clique pour lancer un scan, télécharge un PDF et le dépose sur un partage : il doit comprendre comment fonctionnent les outils qu'il utilise, il doit être capable de les configurer et d'expliquer techniquement pourquoi les vulnérabilités sont identifiées, comment elles le sont et comment y remédier de manière conforme au standard et aux politiques de sécurité en vigueur. Similairement, pour nous un collaborateur raisonnablement indépendant doit être autorisé à escalader la résolution des vulnérabilités entrainant une non conformité hors de l'environnement propre à la Direction Informatique (nous apprécions particulièrement cette exigence car, sous un aspect purement organisationnel lié à un impératif technique, son application peut entrainer positivement de profondes modification de la chaine décisionnelle sécurité au sein d'une organisation).
  • L'exigence #11.2.3 est intéressante dans le sens où la corrélation de la documentation propre aux changements du Système d'Information (besoins métier ou adaptation au schéma directeur informatique) avec les conclusions d'audits de vulnérabilités peut être réalisée par les responsables du changements ou par les responsables des audits. Cette formalisation sera donc toujours fonction des profils des intervenants et particulièrement riche d'enseignements en fonction des organisations.
  • L'exigence #11.3 relative aux tests d'intrusion présente une difficulté majeure au niveau du 7eme item imposé ("Includes review and consideration of threats and vulnerabilities experienced in the last 12 months") : Veillez à bien informer vos prestataires de cette obligation (qui doivent, à notre avis, travailler avec vous et non pour vous) ou à vous assurer que vos personnels internes qualifiés savent comment formaliser cette nouvelle obligation. Notez que cette exigence est considérée comme best practice jusqu'en juin 2015 mais nous vous conseillons de vous appliquer à la respecter dès que possible. La même exigence dans sa guidance suggère que vous ne pourrez totalement interdire l'exploitation des vulnérabilités identifiées en test d'intrusion ce qui peut poser problème pour certaines organisations habituées à s'arrêter à l'identification des vulnérabilités (crainte d'atteinte à la production ou volonté de réduction des coûts).
  • Les exigences #11.3.1 et #11.3.2 (11.3 en version 2) relatives à la réalisation de tests d'intrusion internes et externes est l'une des exigences souvent sous-estimée pour les environnements qui sont sujets à des évolutions fréquentes (exemple type pour les cyber marchands mettant en œuvre des développements en mode agile avec des sprints courts pour répondre aux attentes du marché) : il est ainsi imposé de réaliser ces tests d'intrusion une fois par an mais également après chaque changement significatif ce qui peut entrainer une augmentation des coûts significatives si cet aspect est compris tardivement. Pensez également que l'application des correctifs de sécurité publiés par les éditeurs (exemple type: patch tuesday de Microsoft) peut fréquemment être considéré comme un changement significatif.
  • L'exigence #11.5.1 relative à l'implémentation de mécanismes de détection de changement est pour nous fréquemment l'objet de "vous êtes certaines? Relisons la norme ensemble". Les mécanismes de détection des changements que vous avez déployés et qui tournent 24/7/265 en remontant des alertes à vos administrateurs - alertes qui sont correctement gérées par ces administrateurs. N'oubliez pas que vous devez disposer d'un processus formalisé et d'un modèle de document pour la gestion de ces alertes.
Pour conclure ce chapitre et si vous disposez d'une expérience en terme d'auditeur vous avez déjà compris où nous souhaitons en venir. Il n'est pas possible de feinter l'une des exigences précédentes car toutes s'emboitent telles des poupées russes et sont autant de questions pièges à la disposition du QSA pour savoir où il met les pieds.

Maintain an Information Security Policy


Le sixième et dernier ensemble d'exigences ("12. Maintain a policy that addresses information security for all personnel") est selon nous le chapitre le plus compliqué à mettre en œuvre quand la responsabilité de conformité au standard PCIDSS est confiée à un intervenant avec un profil technique qui ne dispose pas (ou peu) d'expérience en matière de sécurité organisationnelle et fonctionnelle. Nous recommandons souvent aux organisations concernées d'être assistée ou conseillée dans la formalisation ou la maitrise d'ouvrage afférente au respect de ces exigences.
  • L'exigence #12.10.4 impose un entrainement régulier des équipes/collaborateurs en charge de la réponse aux incidents de sécurité. Il ne s'agit pas ici d'être capable techniquement d'identifier un incident ou d'y répondre par des mesures techniques mais de s'assurer que le processus global de gestion des incidents de sécurité respecte les obligations imposées par le standard et que l'ensemble des intervenants est au fait de ses devoirs et obligations.
  • L'exigence #12.2 impose que le processus afférent à la gestion des risques soit mis en oeuvre après chaque changement significatif. Il est donc recommandé d'intégrer la mise à jour périodique des analyses de risques en mode Business as Usual et de ne pas attendre l'échéance des audits de conformité PCIDSS pour ce faire.
  • L'exigence #12.3 relative à la formalisation de politiques d'usage des technologies sensibles impose avec l'exigence #12.3.7 de maintenir une liste de produits approuvés par l'entreprise. N'oubliez pas que ces produits doivent ensuite respecter l'ensemble des autres exigences du standard (exemple non exhaustif : exigences #6.1/#6.2, #10, #11.1 etc.).
  • L'exigence #12.3.9 impose que les accès à distance pour les vendeurs ou partenaires ne soient activés que s'ils sont strictement nécessaires et qu'ils soient immédiatement désactivés après usage. N'oubliez pas que ces accès doivent être tracés et faire l'objet de pistes d'audits présentables au QSA lors de son audit.
  • L'exigence #12.5 est l'une de nos exigence préférées car elle témoigne bien du bon sens des rédacteurs du standard PCIDSS en ce qu'elle impose que les prérogatives afférentes à la Sécurité de l'Information soit formellement attribuées à un CSO ou à un "other security-knowledgeable member of management". Il est donc tout à fait possible pour une organisation d'attribuer la responsabilité SSI à un membre de la Direction pour autant que celui-ci soit assisté/conseillé par des tiers (internes ou externes) qualifiés dans ce domaine. Notez que nous déconseillons l'attribution de ces responsabilités aux collaborateurs dirigeants de la Direction Informatique ou aux opérationnels en charge du périmètre PCIDSS pour que l'indépendance des contrôles et recommandations soit préservée et conforme à l'esprit du standard et des bonnes pratiques.
  • L'exigence #12.6 pour l'implémentation d'un programme de sensibilisation des collaborateurs nécessite que ceux-ci soient formés à l'importance de la sécurité propre à la protection des données cartes. N'oubliez pas que le QSA peut demander copie des supports de cette sensibilisation : si vous avez parlé de tout mais pas des données cartes, alors Houston, vous avez un problème. L'exigence #12.6.2 impose par ailleurs de son côté que l'ensemble des collaborateurs reconnaisse (au moins annuellement) qu'ils ont lu et compris les politiques de sécurité (la dimension manuscrite ou électronique de cette exigence permettant aux programmes d'elearning d'apporter les pistes d'audits nécessaires et suffisantes).

vendredi 1 août 2014

Partir en Juillet ?

Est-ce que le mois de juillet vous a semblé calme ? Nous avions pourtant un combo trimestriel annoncé avec le Patch Tuesday Microsoft du 8 juillet suivi de près par le quaterly Oracle du 15 juillet : retour illustré sur la veille opérationnelle que vous avez menée avant de partir en congés.

Une première semaine calme (?)


La première semaine semblait calme mais c'étant sans compter l'ouverture du CVE-2014-4699 sur la vulnérabilité "ptrace/sysret" du noyau Linux avec une timeline serrée : CVE le 30 juin pour un commit le 3 juillet, annonce publique "née un 4 juillet" sur OSS-SEC suivie d'un avertissement de @grsecurity le 6 juillet ("Expect exploits against upstream within the next month") et d'une publication des correctifs dans les heures et jours suivants (5/6 juillet pour Ubuntu et Debian par exemple).

Et effectement les poc/exploits ont été publiés en moins d'un mois. Vous étiez prévenus pourrait-on nous dire.

8 juillet 2014 - Patch Tuesday Microsoft et Adobe Flash Player


Microsoft et Adobe publient leur "patch tuesday" le 8 juillet et fixent tous deux des vulnérabilités critiques (dont un bulletin critique pour Internet Explorer 6/7/8/9/10/11 qui fixe "one publicly disclosed vulnerability and twenty-four privately reported vulnerabilities in Internet Explorer"). Notons la mise à jour de Google Chrome le même jour pour une simple mise à jour du composant Flash.

15 juillet 2014 - Avalanche confirmée avec le CPUJUL Oracle


La publication du bulletin trimestriel Oracle le 15 juillet inclut "113 new fixes across hundreds of Oracle products" dont notre bien aimé Java qui est mis à jour en versions 8u11 et 7u65, Mysql qui voit 10 CVE fixés (avec un CVSS maximum à 6.5) pour les branches 5.5.37/5.6.17, Solaris 11.1/10/9/8 qui incluent leur lot de correctifs et Oracle DB 12.1.0.1 qui fixe deux CVE avec une notation CVSS étrange laissée pour analyse à la curiosité des lecteurs : CVE-2013-3751 (cvss=9) et CVE-2013-3774 (cvss=7,6).

Et ne passons pas à côté d'une nouvelle version de Apache en version 2.4.10 entre les 14 et 15 juillet, d'une mise à jour de Puppet Enterprise pour OpenSSL le 15 juillet, de la mise à jour de Google Chrome stable qui inclut "26 security fixes" (comme ça pas de jaloux) le 16 juillet et d'un bulletin DSA sur OpenJDK-6 le 17 juillet.

Notons également que la mise à jour Mysql 5-5 pour Ubuntu (USN-2291-1) publiée le 17 juillet est suivie le 22 juillet par la mise à jour Debian (DSA 2985-1).

4ème semaine - Ne perdons pas le rythme


Vous auriez été déçu de ne pas avoir de correctif pour Firefox en juillet suite aux correctifs pour Internet Explorer et pour Chrome. Vous auriez eu raison, Mozilla publie une mise à jour Firefox 31 le 22 juillet (3 bulletins MFSA importants) et une mise à jour Thunderbird 31 (3 bulletins MFSA importants également) (à nouveau pas de jaloux ce mois-ci).

Pour vous qui aimez OpenJDK, Debian ne nous oublie pas et publie un DSA sur OpenJDK-7 le 23 juillet 2014 (moins de 10 jours après le bulletin sur OpenJDK-6) et pour vous qui êtes afficionados de Tomcat, notez la publication le 30 juillet du bulletin USN-2302-1 tomcat7 intégrant la correction de CVE en version 7.0.53 initialement publiée le 30 mars 2014 (4 petits mois).

Vous souhaitiez une mise à jour mensuelle "à la patch tuesday" pour PHP, vous êtes servis avec la publication de PHP 5.4.31/5.5.15 le 24 juillet 2014 (précédente publication le 26 juin 2014).

Vous attendiez les bulletins propres aux distributions pour la version 2.4.10 Apache des 14/15 juillet ? Ubuntu publie ses correctifs le 23 juillet (USN-2299-1) et Debian le 24 juillet (DSA-2989-1).

Et ne passons pas à côté du CVE-2014-0475 sur la GLIBC publié sur OSS-SEC le 10 juillet et de la remarque de @taviso que je me permet de citer ici ("This seems like a pretty minor flaw that I wouldn't normally bother mentioning, but as I'm tacking it onto a more serious bug and we're all discussing the LC_ALL thing anyway I don't mind so much") et qui fait l'objet d'une demande de CVE le 29 juillet (cherchez "[CVE Request] glibc iconv_open buffer overflow" pour ceux qui sont intéressés par le message subliminal).

Et ma Debian-LTS ?


Je ne sais pourquoi mais j'éprouve une affection particulière pour ce projet (disclaimer: je ne suis donc pas 100% objective sur le sujet).

Constatons donc que le CVE-2014-4699 fixé le 6 juillet pour Debian stable a été fixé sur Squeeze-lts le 12 juillet et que la mise à jour Debian Stable DSA 2974-1 pour PHP5 du 8 juillet a été fixée sur Squeeze LTS le 24 juillet. C'est plutôt bien non ?

Je constate néanmoins qu'il est assez pénible pour le moment de suivre la publication des correctifs de sécurité sur Debian LTS si on se réfère au security-tracker Debian, j'espère personnellement que ceci sera amélioré pendant les prochains mois.

Et SSL ?


Parlons un peu de SSL avec la première "OpenSSL Project Roadmap" publiée le 30 juin 2014 et mise à jour le 16 juillet 2014 et la première publication de LibreSSL portable "for Linux, Solaris, Mac OSX, and FreeBSD" le 11 juillet 2014. Et comme nous connaissions pour Flash et Java, voici désormais un nouveau site à bookmarker : http://dayswithoutansslexploit.com

Et maintenant ?


Et maintenant, finissons donc ce mois de juillet illustré sous plusieurs angles différents :

  • Une très jolie nouvelle fonctionnalité chez Microsoft de fin juillet avec myBulletin qui nous permet *gratuitement* de configurer une liste personalisée de bulletins de sécurité par technologie (plutôt que par bulletin) : Merci !
  • Une impressionnante timeline concernant la publication du bulletin MS14-035 de juin 2014 sur Internet Explorer 6/7/8/9/10/11 avec une vulnérabilité identifiée par @vupen en février 2011, reportée par leurs soins à Microsoft en mars 2014 pendant le Pwn2Own 2014 et fixée par Microsoft lors du patch tuesday de juin 2014.
  • Et une mise à jour de Tor le 30 juillet 2014 et l'analyse détaillée correspondante.

Alors, vous trouvez que ce mois de juillet a été calme ? Attendez août :)

Jess - @JessicaGallante

PS : Merci @helpacsoout et @philoupas et à ma @nathplanteur qui se dore au soleil.