jeudi 11 décembre 2014

Tu nous manques

Que s'éloigne la passion
qui laisse, pour le pire,
s'enfuir tous les rires
qui blessent la raison.

Que s'estompe l'absence,
qui laisse mon âme hantée
de joies inexplorées
qui blessent le silence.

Que s'efface ma haine
qui laisse plein de douleur
mon coeur si lourd de pleurs
qui blessent mon âme en peine.

Pourquoi m'as tu quittée, j'avais tant à te dire.
C'est dur, si tu savais, de garder le sourire.

Jess - la vie est poésie

dimanche 30 novembre 2014

Novembre : l'hiver vient

Novembre, nous avons tout intérêt à colmater nos fenêtres pour face au froid et aux vagues d'assaillants qui nécessitent de notre part une véritable garde de jour ... et de nuit. Et à dire vrai, il semble que toutes les technologies qui nous permettent de tenir le Mur présentent un caractère fragile en cette fin d'année. Qu'en pensez-vous ? Serait-ce l'hiver qui vient ?

Une première semaine apéritive


Le premier novembre 2014, FreeBSD fête ses 21 ans, OpenBSD publie sa version 5.6 (retirant officiellement sa 5.4) et NetBSD publie un fix pour tnftp (CVE-2014-8517) intéressant à analyser : Sévérité NVD High (CVSS/7.5), no-dsa_minor_issue pour Debian, impact modéré (CVSS/6.8) pour RedHat, OpenBSD non impacté, Mac OS X ? Et vous, comment vous assurez-vous qu'une vulnérabilité publiée par un tiers dans votre distribution de production est corrigée ou non impactante ?

Et en première semaine, c'est donc la fête aux *BSD : 3 bulletins (ftp, mount, openssl) pour NetBSD le 3 novembre, 3 bulletins (sshd, setlogin, ftp) pour FreeBSD le 4 novembre et un commit OpenBSD le 4 novembre qui fixe le CVE-2014-3710 pour File (précédente version datée du 28.10.09 ?) ... Fixé par Ubuntu avec par un bulletin USN pour PHP5, par Debian par des bulletins PHP5 et File, par RedHat par des bulletins PHP. Et vous, comment vérifiez-vous qu'une vulnérabilité est corrigée quand elle est simplement référencée par des commit de source ?

En première semaine, est aussi publié le 4 novembre le DSA-3064-1 pour PHP5 qui corrige les CVE mentionnés par PHP dans ses mises à jour 5.4/5.5/5.6 du 16 octobre et qui précise "it has been decided to follow the stable 5.4.x releases for the Wheezy PHP packages". Transition annoncée diront certains d'un mode stable "intégration des correctifs de sécurité" à un mode rolling "application des mises à jour mineures") ? Mais nous avons aussi la publication pour Solaris 10/11/11.1 de nombreux correctifs le 4 novembre (correctifs OpenSSL du 15 octobre dont POODLE) et le 7 novembre (Bash, Gzip, Samba, X.Org, Zip, ...).

Et la première semaine c'est aussi la notification avancée de Microsoft le 6 novembre pour le patch tuesday de Novembre : 5 bulletins critiques et 9 importants qui corrigeront entre autre des "remote code execution" dans Internet Explorer et Office - patch tuesday prévu le jour férié du 11 novembre.

Une seconde semaine compliquée pour Microsoft ... mais pas que


Le 11 novembre voit arriver un patch tuesday teinté de rouge pour Microsoft avec 14 mises à jour dont 4 critiques et 8 importantes dont les critiques MS14-065 qui "resolves 17 privately reported vulns in Internet Explorer 6/7/8/9/10/11" et MS14-066 qui "resolves a privately reported vulnerability in Schannel that could allow remote code execution" (l'année 2014 pouvant donc prétendre au statut bingo pour toutes les implémentations TLS ?). Ce patch tuesday permet aussi de clôturer, avec le MS14-064, le security advisory SA3010060 du 21 octobre (Windows OLE) mais inclut deux bulletins MS14-068 / MS14-075 annoncés avec le message "Release date to be determined".

Adobe publie aussi ses correctifs pour Flash Player le 11 novembre avec la correction de 18 CVE (mise à jour Chrome pour Flash dans la foulée) et nous pouvons aussi voir arriver quelques vulnérabilités intéressantes comme celles référencées par le bulletin "node.js/dns-sync" ou des bulletins dont la qualification est compliquée avec le DSA-3071-1 NSS du 11 novembre (High MFSA avec CVSS à 10 du 22.07 à comparer avec le DSA-3033-1 d'un Critical MFSA avec CVSS à 7.5 corrigé en moins de deux jours) ... et nous pouvons même apprendre que toutes les technologies ciblées (iPhone5S, GalaxyS5, Nexus5, FirePhone) lors de la troisième "HP ZDI Mobile Pwn2Own competition" pendant la conférence PacSec sont exploitables ... et exploitées.

Heureusement que ce 11 novembre était férié :) Et vous, comment gérez-vous la qualification et application en urgence lors des jours non travaillés ?

Sans oublier notre publication mensuelle par PHP de mises à jour 5.5/5.6 le 13 novembre.

3ème semaine rouge écarlate pour Microsoft


La 3ème semaine commence sur les chapeaux de roue avec la publication le 17 novembre du SA-2014-11-17-2 de Apple pour OS X Yosemite et de nouveaux bulletins reliability OpenBSD entre le 17 et le 18 novembre puis la sortie le 18 novembre d'une nouvelle version de Chrome qui fixe 42 problèmes de sécurité (avec la suppression du "SSLv3 fallback") et la publication le même jour de l'un des deux bulletins manquants du patch tuesday de Novembre : le bulletin critique MS14-068 Kerberos (CVE-2014-6324) pour 2003/2008/2012 qui est publié le 18 novembre en hors cycle par Microsoft avec l'intéressante note : "The only way a domain compromise can be remediated with a high certainty is a complete rebuild of the domain". Et vous, comment gérez-vous la sortie d'un bulletin critique hors cycle lorsque votre processus d'application des correctifs est en cours ?

Et pour ceux d'entre nous qui attendaient les bulletins Debian pour PHP, le DSA-3074-1 du 18 novembre qui fixe le seul CVE-2014-3710 mentionné dans la publication PHP du 13 novembre confirme à nouveau ce qui était annoncé en début de mois "As announced in DSA-3064-1 it has been decided to follow the stable 5.4.x releases for the Wheezy php5 packages".

Le 19 novembre se voit publié le bulletin drupal-sa-core-2014-006 qualifié comme "moderately critical" et l'annonce d'une vulnérabilité "OS X sandbox escape" par le Google Project Zero (qui applique sa politique "90-day disclosure deadline"), le 20 novembre commence avec la publication de 7 bulletins pour Asterisk, la sortie de multiples bulletins pour Solaris 11.2/11.1/10/9/8 et l'annonce d'une mise à jour critique pour Wordpress.

Et pour conclure cette 3ème semaine, @lcamtuf poste sur twitter le 23 novembre la mention choc "Quick quiz: would you run 'less' on an untrusted file?" puis s'explique sur OSS-SEC...

4ème semaine


Notre dernière semaine de novembre se calme (!) avec la publication d'un bulletin pour Docker le 24 novembre, la sortie d'un nouveau bulletin pour Flash Player le 25 novembre, la demande de CVE sur OSS-SEC pour cpio suite au fil de discussion sur lesspipe du 23 novembre et comme nous n'avions pas encore de bulletins Java, Debian publie ses bulletins DSA-3077-1 openjdk-6 et DSA-3080-1 openjdk-7 les 26 et 29 novembre (mises à jour suite au Critical Patch Update de Oracle du 14 octobre). Notons aussi l'information d'un chercheur Google mentionant une "sandbox escape" sur Adobe Reader stable le 27 novembre.

Et maintenant ?


Et comme un échange badin d'anecdotes sur le sujet de la veille opérationnelle pour clôturer ce mois de novembre :

  • nous avons le 2 novembre l'annonce de sortie d'une nouvelle version MantisBT 1.2.18 "for release in the next few days" car "the patch did not fully address the original problem" (injection SQL corrigée dans la 1.2.16 du 08.02.14). Toujours pas de publication au 30 novembre 2014. Annonce à mettre en relief avec le VMSA-2014-0008 du 9 septembre 2014 pour lequel la mention "Patch Pending" est toujours d'actualité pour Vcenter/ESXi 5.0/5.1 au 30 novembre. Et vous, comment gérez-vous le suivi de ces avertissements sur le moyen terme ?
  • nous avons le 10 novembre, l'alerte TA14-310A du US-CERT sur la prochaine fin de support pour Windows Server 2003. Et vous, où en êtes vous de votre plan de migration ?
  • et que penser de la nouvelle politique PHP5 pour Debian stable ? Nous avons eu 7 DSA (2 mars, 1er juin, 16 juin, 8 juillet, 21 août, 4 novembre, 18 novembre) pour 12 mises à jour de version 5.4. Est-ce pour vous comparable avec la politique de mise à jour pour openjdk-6/openjdk-7 (24 avril et 5 mai pour le CPU Oracle du 15 avril, 17 juillet et 23 juillet pour le CPU Oracle du 15 juillet, 26/29 novembre pour le CPU Oracle du 14 octobre). Qu'en pensez-vous ?

Jess - @JessicaGallante

PS : Merci @helpacsoout, @philoupas, John et à ma @Nathplanteur.

PPS : Quelle déception pour l'absence de MFSA autour du 25 novembre. J'avais la réponse mais sans doute pas la bonne question ...

vendredi 7 novembre 2014

Je suis un peu perdue

Je suis un peu perdue, il fait très sombre aussi
Il y a bien trop d'aigues, et aussi trop de basses
Pourquoi fait-il si froid? Pourquoi donc tous ces cris?
A quoi cela rime-t-il? Pourquoi suis-je donc si lasse.

Nous sommes arrivés tard, le temps était pluvieux
Nos rires étaient joyeux, nos pieds s'impatientaient
La musique sans fausse note et les fruits délicieux
Et là j'ai vacillé puis me suis absentée.

Et ces lumières criardes, qu'elles cessent de clignoter
Et toutes ces ombres autour, qu'elles s'arrêtent de tourner
Pourquoi suis-je allongée? Je n'en puis plus pitié.
Je dois ouvrir les yeux, je dois me réveiller.

Jess - La vie est poésie

vendredi 31 octobre 2014

Octobre : Vulnérabilités "Trick or Treat !"

"Heartbleed le 7 avril 2014, Shellshock le 24 septembre 2014, jamais deux sans trois" disais-je le mois dernier. Pour ceux d'entre nous qui pensaient que le mois d'octobre serait calme en comparaison du buzz #ShellShock et du Black April je ne peux que souhaiter que la fin d'année soit plus calme.

Une première semaine type


La première semaine du mois d'octobre 2014 me semble une semaine type exemplaire en matière de veille opérationnelle en vulnérabilités.

Les plans d'analyse et de remédiation #ShellShock s'enchainent tranquillement une semaine après la publication du 24 septembre sur la vulnérabilité #Bash (exemple: publication par Apple de l' "OS X bash Update 1.0" (HT6495) le 29 septembre et par Vmware du VMSA-2014-0010 le 30 septembre 2014) et l'analyse des nouvelles vulnérabilités commence sur les chapeaux de roue avec la publication le 30 septembre de correctifs pour Joomla (RFI/DOS pour les versions inférieures à 3.3.5, 3.2.6 and 2.5.26) et la sortie du CVE-2014-3634 sur Rsyslog ("DOS from untrusted sources") avec la publication par Debian des DSA-3040-1 et DLA-72-1.

Nous assistons ensuite au retour de correctifs pour OpenBSD le 1er octobre (CVE-2014-3616 pour nginx pour 5.5/5.6), à une nouvelle version de PHP 5.6.1 le 2 octobre et à deux bulletins Ubuntu USN-2367-1/OpenSSL (qui peut nous laisser présager de futurs bulletins sur le sujet par d'autres distributions) et USN-2368-1/OpenVPN (corrigeant le CVE-2013-2061 de mars 2013).

Une seconde semaine type (jamais deux sans toi ?)


La seconde semaine d'octobre continue sur la lancée précédente avec la publication des versions 4.0.15, 4.2.11, 4.4.6, et 4.5.6 de Bugzilla le 6 octobre (et du mini-buzz correspondant), la sortie d'une mise à jour majeure pour Chrome le 7 octobre avec "159 security fixes" (!), la publication du JSA10560 pour J-Web sur Junos et des correctifs Solaris 11.2/10/9 pour Bash le 7 octobre également, la publication du cisco-sa-20141008-asa par Cisco le 8 octobre, la nouvelle correction pour Rsyslog par Debian (DSA-3047-1) car la précédente correction DSA-3040-1 était incomplète (nouveau CVE-2014-3683) le 8 octobre (et son pendant chez Ubuntu - USN-2381-1 - corrigeant les deux CVE d'un seul coup le 9 octobre) et un nouveau bulletin Juniper JSA10655 (CVE-2014-6380) pour Junos le 10 octobre.

Et nous avons le droit à un week-end de repos bien mérité avant le doublé Microsoft / Oracle prévu le 14 octobre (la notification avancée par Microsoft le 9 octobre nous prévenant de 9 bulletins dont 3 critiques avec une RCE pour IE6 à IE/11 et Office 2007/2010).

14 octobre 2014 : Un déferlement de vulnérabilités : Trick or Treat!


Le 14 octobre voit arriver une déferlante à faire pâlir le Black April 2014 et ses Heartbleed et fin de support Windows XP : Patch Tuesday de Microsoft (3 bulletins critiques et 5 importants dont le MS14-056 qui "resolves 14 privately reported vulns in Internet Explorer"), Patch tuesday Adobe avec la sortie du bulletin APSB14-22 pour Flash Player (3 CVE) et la mise à jour pour Chrome correspondante et le (tant attendu) critical patch update trimestriel d'Oracle qui arrive avec "154 new security fixes" dont (entre autres) 31 correctifs pour les serveurs "Oracle Database", 15 correctifs pour les "Sun Systems", 24 correctifs pour Mysql et 25 correctifs pour Java. Ajoutons à cela la sortie de la version 33 de Firefox (qui corrige trois vulnérabilités élevées) et nous avons (à nouveau) en une semaine tous nos navigateurs critiquement vulnérables (il nous manque Safari je vous l'accorde mais laissez lui un peu de temps).

Nous sommes toujours le 14 octobre et la battle commence entre la vulnérabilité CVE-2014-4114 aka "Sandworm" dont la correction est disponible car reportée officiellement par un tiers à Microsoft - le plan média étant certainement prévu de manière coordonnée avec la publication du MS14-060 intégré au Patch tuesday du 14 octobre ... et ... et ... et la publication de la vulnérabilité CVE-2014-3566 "POODLE" par Google sur SSL.

Comment comparer ces deux vulnérabilités ? L'une des deux éclipse-t-elle l'autre ? Pouvons-nous porter nos efforts en terme de priorisation de remédiation sur l'une d'entre elles ou devons nous scinder nos efforts à part égale ?

Il me semble rétrospectivement que POODLE a fait coulé plus d'encre que Sandworm et que le mois d'octobre sera dans le futur associé à POODLE (ceci n'est qu'un avis personnel, donnons-nous rendez-vous d'ici quelques mois si vous le voulez bien). Demeurons néanmoins attentifs un instant à Sandworm dont le plan média semble avoir été préparé de manière appropriée : une vulnérabilité est identifié par des chercheurs. Ceux-ci reportent cette vulnérabilité à l'éditeur qui prépare le correctif et le publie. Les chercheurs publient ensuite leur propre bulletin et nos sysops / adminsys perdent quelques jours de sommeil (grâce leurs soit rendue). Avançons quelque peu dans le temps, quelques jours plus tard commencent à circuler des informations semblant indiquer que le MS14-060 est incomplet et peut être contourné ... et Microsoft acquitte ces informations par la publication du Security Advisory 3010060 le 21 octobre (nouveau CVE-2014-6352) avec un Fixit (attendons le bulletin pour le mois prochain ?) ... Cela ne vous rappelle-t-il rien ? Je vous aide, le mot clé est "internet-o-vision" dans mon article du mois de septembre.

Arrive le 15 octobre (si vous ne dormez pas, les journées font effectivement plus de 24 heures mais ceci est un autre débat) et la semaine voit tous les éditeurs publier leurs analyses sur ce désormais fameux POODLE (qui est il ? d'où vient il ? quels sont ses réseaux d'influence ? a-t-il définitivement refusé de porter plainte contre ses parents pour ce sobriquet dont il a été affublé ?) dont le score de base CVSS s'élève autour de 4 à 5 (Moyen) mais les impacts potentiels en terme métier semblent estimés à important : Mise à jour du SA3009008 Microsoft ("to include a workaround for disabling the SSL 3.0 protocol in Windows"), BlueCoat SA83, Juniper JSA10656, VMWARE KB2092133, Cisco cisco-sa-20141015-poodle, etc...

Ne zappez pas, pour que ce 15 octobre soit "trick or treat", il en faut plus ... bulletin critique DRUPAL-SA-CORE-2014-005 ("SQL Injection by anonymous user"), bulletin important RHSA-2014-1620 pour java-1.7.0-openjdk, USN-2384-1 pour Mysql suite au CPU Oracle (rapide !) ... Et si POODLE ne vous suffisait pas, le bulletin OpenSSL secadv_20141015 inclut d'autres CVE (CVE-2014-3513, CVE-2014-3567, CVE-2014-3568).

Quelques heures de sommeil et le 16 octobre débute avec les bulletins pour OpenSSL : Debian DSA 3053-1, Ubuntu USN-2385-1, RedHat RHSA-2014:165 (bon courage si vous tracez la cohérence entre CVE et bulletins multiples) et le sympathique LibreSSL 2.1.1 qui désactive SSLv3 par défaut et qui précise "not vulnerable to 2 memory leak from OpenSSL".

Ne zappez pas, pour que cette semaine soit véritablement "trick or treat !", il nous faut entendre sonner le tocsin plusieurs fois ! Le 16 octobre c'est aussi : un bulletin JSA10652 "Junos RSVP DOS", une mise a jour PHP5 5.6.2/5.5.18/5.4.3, le bulletin USN-2386-1 pour OpenJDK 6, le RHSA-2014:1654-1 rsyslog RHEL6 pour rsyslog (après le RHSA-2014:1397-1 RHEL7 du 13 octobre pour notre DSA-3040-1 du 30 septembre sur le CVE-2014-3634), le RHSA-2014:1655-1 pour un DOS dans libxml2 (CVE-2014-3660) ... Et les mises a jour Apple OS X Server v2.2.5/3.2.2/4 et OS X Security Update 2014-005 (pour laquelle Apple confirme le 17 octobre avec le APPLE-SA-2014-10-16-2 que les corrections incluent le CVE-2014-3566 et le fix OS X bash Update 1.0) ...

A nouveau quelques heures de sommeil (ou de veille F5 F5 F5 comme le dit @Philoupas) mais heureusement tout le monde est fatigué (au moins de notre côté et le week-end est enfin là).

3ème semaine : et c'est parti pour une semaine de rab


Reprenons en fanfare le 20 octobre : bulletin Asterisk AST-2014-011 pour POODLE et bulletin Oracle Solaris 11.2 pour les CVE OpenSSL. Nouveaux bulletins catégorisés "Reliability" pour OpenBSD 5.4/5.5/5.6 auxquels s'ajoute un fix pour désactiver SSLv3. Sortie du DSA-3054-1 MySQL suite au CPU Oracle (enfin !).

Passons au 21 octobre avec le Microsoft SA3010060 sur la RCE OLE incomplète pour Sandworm et à 4 bulletins pour FreeBSD (dont un pour les vulnérabilités OpenSSL).

... Et au 22.10 avec le bulletin TYPO3-CORE-SA-2014-002, le bulletin USN-2388-1 pour OpenJDK 7 et un nouveau bulletin Vmware VMSA-2014-0011 pour vSphere Data Protection (CVE-2014-4624).

4ème semaine : est-ce que cela va s’arrêter ?


Une dernière semaine qui commence bien avec les CVE-2014-8484 et CVE-2014-8485 (et CVE-2014-8501 à CVE-2014-8504 ?) pour " strings / libbfd " qui ont inquiété les veilleurs le dimanche 26 octobre au soir (et des points de vue différents et très intéressants sur la réponse à apporter à ces vulnérabilités : comparez les mailing lists OSS-SEC et openbsd-tech à ce sujet) et le bulletin Debian DSA-3057-1 pour libxml2 (qui corrige le CVE-2014-3660 et 3 bugs).

Passons au 27 octobre avec un nouveau bulletin Oracle pour OpenSSL sur Solaris 10/11.2 et à un bulletin sur Node.js pour un contournement de filtre de validation entrainant une possibilité de XSS.

Puis au 28 octobre avec le bulletin Puppet pour POODLE et SSLv3.

Puis au 29 octobre avec le CVE-2014-4877 sur WGET (USN-2393-1 / RHSA-2014:1764 du 30 octobre et intéressante "disclosure timeline" par Rapid7), la modification du Microsoft SA3009008 pour annoncer la "deprecation of SSL 3.0" (message subliminal : cette information ne devrait pas être prise à la légère) et l'annonce par Drupal avec un bulletin spécial PSA-2014-003 que les attaques ciblant les sites Drupal ont débuté "within hours of SA-CORE-2014-005" (publié, je vous le rappelle, le 15 octobre en même temps que Sandworm et POODLE et qui devrait porter à notre attention que la priorisation des corrections sur un Système d'Information doit toujours être fonction du Métier et non des buzz médiatiques dont nous sommes submergés).

Puis au 30 octobre avec : les bulletin Ubuntu USN-2391-1 et RHSA-2014:1767-1 pour PHP5 sur les CVE publiés le 16 octobre (enfin ! mais nous attendons toujours la transition Debian de testing vers stable :( ), une mise à jour Chrome stable pour Chrome OS et une mise à jour sécurité GitLab 7.4.3 (CVE-2014-8540).

Et maintenant ?


Que vous dire de plus si ce n'est joyeuse All Hallows Eve !

Jess - @JessicaGallante

PS : Enormes merci à @helpacsoout, @philoupas, @helkhoury, X et X2 (qui se reconnaitront) pour vos messages. (inlove) à John, Marie et @AdBaz1 pour votre support pendant ce mois compliqué :)

PPS : @Nathplanteur : à ce soir ! (j'ai un habit de princesse pour toi aussi :D)

vendredi 10 octobre 2014

Il s'est enfui si vite

Il s'est enfui si vite, il était encore tôt
Le jour pointait à peine, il faisait encore nuit
Le silence pesait, il n'a pas fait un bruit
Sans daigner prévenir, sans me laisser un mot.

De guerre lasse je cherche, et cherche s'il me faut
Pourtant je le savais, mais sotte je le suis,
Et ces conseils d'amis? bien sur je les fuis
A nouveau l'appeler ... et qu'il me fasse défaut ?

Et maintenant que faire? Devrais-je lui promettre,
Attendre, patienter, lui dire que je suis prête ?
Notre couche était tiède, froissée de mille rèves
Nos souffles étaient si calmes, nos songes sans une ombre
Un repos mérité, la nuit semble si brève.
Nos souffles étaient si liés, et il fait encore sombre.

Jess - la vie est poésie

jeudi 2 octobre 2014

Je l'ai accompagnée

Le coeur paré de rêves, je l'ai accompagnée
Sa coiffe était baissée et sa démarche brève
Avec son port altier, sa robe couleur de sève
Elle s'avance, elle est Eve, de grâce auréolée.

Le coeur serré d'amour, je l'ai accompagnée
Sa jolie peau dorée, toute parée de velours
En cette longue journée, en ce tout premier jour
Après ces longs cris sourds, calmés par nos bonnes fées.

Le coeur lourd de sanglots, je l'ai accompagnée
Sans pouvoir m’arrêter, sans pouvoir dire un mot
Et cette envie d'hurler, de crier c'est trop tôt
Qui passera bientôt sur nos deux coeurs brisés.

Jess - La vie est poésie

dimanche 28 septembre 2014

Septembre : Le 24 c'est toujours Noël

Moins de six mois après Heartbleed surgit Shellshock. Loin des débats sur le niveau de sévérité réel de ce qui deviendra certainement une "famille" de vulnérabilités touchant (ou pas) un peu tout et n'importe quoi, l'année 2014 revet pour moi les atours d'une année riche d'enseignements qui nous permettront d'éviter une banalisation du travail de vigie des équipes chargées de la veille opérationnelle en vulnérabilités.

Construire puis maintenir (de manière pérenne) un processus de gestion des vulnérabilités qui s'adapte, d'une part, aux besoins en terme de sécurité exprimés par nos métiers et reflète, d'autre part, le niveau de menace réel/avéré impactant les Systèmes d'Information dont nous avons la charge présente un problème particulièrement compliqué à surmonter : Comment nous assurer et contrôler que notre capacité à conserver un niveau de vigilance élevé est optimal et adapté à nos métiers ?

Heartbleed le 7 avril 2014, Shellshock le 24 septembre, jamais deux sans trois ?

Une première semaine bien calme


Des mises à jour Firefox (3 MFSA critiques) et Thunderbird (3 MFSA critiques) accompagnées de mises à jour sur ma #SqueezeLTS dont le DLA-43-1 (eglibc) le 02.09.14 correspondant au DSA 3012-1 du 27.08.14 corrigeant un CVE qui avait été demandé par @taviso sur OSS-SEC le 29 juillet et des notifications avancées de Microsoft et d'Adobe qui ne s'annoncent pas comme spécialement catastrophiques.

9 septembre 2014 - Patch Tuesday Microsoft, Adobe Flash Player (mais décalage Adobe Reader/Acrobat) et Chrome


Microsoft et Adobe publient leur patch tuesday le 9 septembre 2014. Microsoft publie, entre autres, un bulletin critique (Internet Explorer 6/7/8/9/10/11 qui fixe "one publicly disclosed and thirty-six privately reported vulnerabilities in Internet Explorer"). Adobe fixe, de son côté, des vulnérabilités critiques dans Adobe Flash Player (12 CVE) et annonce le report de la sortie des mises à jour Adobe Reader/Acrobat à la semaine du 15 septembre. Notons aussi que Chrome est mis à jour pour Flash et intègre aussi 4 correctifs de sécurité.

Et cette même semaine survient également le 9 septembre un bulletin de sécurité Vmware pour les "vSphere third party libraries" avec une mise à jour pour Vcenter/ESXi 5.5 mais un "patch pending" pour Vcenter/ESXi 5.0/5.1 (toujours pending le 28 septembre), la correction par le projet FreeBSD le 09.09.14 (FreeBSD-SA-14:18.openssl) du bulletin OpenSSL du 06.08.14 (secadv_20140806), une mise à jour PHP5 chez Ubuntu le 09.09.14 (USN-2344-1 faisant écho au DSA-3008 du 21.08.14), une publication officielle le 10.09.14 du CVE-2013-4444 pour une correction sur Tomcat 7.0 publiée le 09.05.13, une publication d'un nouveau bulletin Vmware le 11.09.14 pour NSX & vCNS et une mise à jour Bind9 chez Debian le 11.09.14 (DSA-3023-1 faisant écho au USN-2081-1 du 13.01.14 et au RHSA-2014:0043-1 du 20.01.14).

Un grand merci à Adobe pour cette annonce concernant le report de la publication Adobe Reader qui permet aux équipes de déclencher les actions appropriées sans se demander si les priorités de leurs plans d'action vont évoluer.

3ème semaine - Séance d'échauffement ?


Oracle publie des correctifs pour Solaris 11.2/11.1/10 le 15.09.14, Adobe publie le 16.09.14 ses nouvelles versions pour Adobe Reader et Acrobat (comme nous nous y attendions) et Ubuntu publie une mise à jour OpenJDK7 le même jour. Le CVE-2014-3616 affectant Nginx fait l'objet d'un DLA le 17.09.14 (<3 #SqueezeLTS, le DSA-3029-1 étant publié trois jours plus tard le 20.09.14), FreeBSD publie le 17.09.14 un bulletin FreeBSD-SA-14:19.tcp mentionannt le CVE-2004-0230 (oui oui 10 ans), Apple publie ses mises à jour OS X Server 2.2.3 / 3.2.1, OS X 10.9.5 et Safari 6.2/7.1 le 17.09.14, Asterisk publie deux bulletins le 18.09.14, PHP annonce ses mises à jour 5.4x et 5.5x le 19.09.14 et Chef annonce des correctifs le même jour, Debian publie le DSA-3030-1 pour MantisBT (avec des correctifs originellement publié le 08.02.14) le 20.09.14 et ... le dimanche 21.09.14 nous permet enfin de nous reposer ou de sortir un peu.

4ème semaine - Le 24 c'est toujours Noël ...


La 4ème semaine s'annonce sympathique avec la publication par la Google Security Team du CVE-2014-6273 "apt-get buffer overflow" (sortie le 23.09 des bulletins DLA-58-1, DSA-3031-1, USN-2353-1) et, le 24.09.14, la publication du CVE-2014-6271 sur #Bash, la publication (coordonnée ?) des correctifs Chrome, Firefox et Thunderbird pour le CVE-2014-1568 (NSS RSA sig) et la publication de 6 bulletins chez Cisco pour IOS (RSVP, SIP, mDNS, DHCPv6, metadata, NAT) ... puis la machine s'emballe autour de ce qui devient #ShellShock et de sa myriade de CVE.

#Bash #ShellShock etc.


Faisons une pause, nous sommes le 24.09.14 en milieu d'après-midi, le CVE-2014-6271 sur #Bash vient de sortir et tous les correctifs sont disponibles. La vulnérabilité est rapidement qualifiée comme critique si exploitée mais les vecteurs d'exploitation sont "flous". Qu'importe le brouillard, l'application des correctifs doit être réalisée sans tarder (ie : nous avons eu Adobe Reader la semaine dernière, Internet Explorer et Chrome la semaine précédente, nous sommes habitués).

Les équipes sont déjà en train de corriger ou d'organiser les recettes fonctionnelles avant déploiement en production et une information tombe en fin d'après-midi : le correctif est incomplet selon @taviso (encore lui! coupez-lui donc l'accès à internet que nous puissions être tranquilles ^^). "Et là c'est le drame" : quelles sont les conséquences ? les impacts ? aucune information et en internet-o-vision, ce qui était une vulnérabilité critique standard devient le nouvel heartbleed^Wshellshock (être baptisé d'un nom effrayant^Wcool étant absolument nécessaire pour que le cirque médiatique^W^Wgrand public soit informé).

Avance rapide d'une journée, nous sommes le 25.09.14 au soir et de nouveaux bulletins corrigeant ce qui est désormais le CVE-2014-7169 sont publiés pour ce #BashRound2 (DSA 3035-1 et USN-2363-1 le 25.09, DLA-63-1, RHSA-2014:1306-1,1311-1,1312-1 le 26.09.14, etc) avec une correction supplémentaire pour deux nouveaux CVE CVE-2014-7186 et CVE-2014-7187.

Et là, le 25.09.14 à minuit, alors que s'approchent les 36 heures de veille après le début de cette crise ... et comme nous l'avait annoncé de manière prémonitoire @helpacsoout le 17 septembre 2014 : "Awake for over 36H because of a breach. Go home and sleep or keep working? WDYD? #ciso #hacsoo" ? ... je pense à tous les mainteneurs qui font ce travail et à tous les sysop qui ont encore de longues nuits à patcher devant eux et qu'on blame à cause de ces problèmes alors qu'ils font souvent tout leur possible pour faire face à ce b0rd3l avec le sourire et je veux faire partie de celles et ceux qui les remercie pour cela <3.

Et le week-end ne s'annonce pas meilleur, de nouveaux problèmes #Bash sont annoncés le 26.09.14 au soir et ce qui devient le CVE-2014-6277 (dont les détails ne sont pas encore connus pour mon article :p) est ouvert le 27.09.14.

Et ma Debian-LTS ?


Pour celles et ceux qui suivent ce projet (inlove), je crois que nous ponvons désormais constater que Debian dispose maintenant d'une vraie distribution LTS avec une publication des correctifs de sécurité dans des délais similaires à la branche stable et un référencement des vulnérabilités totalement adéquat sur security-tracker.debian.org avec la publication de bulletins DLA qui lui sont propres. Et le site lui-même est beau esthétiquement ! Que demander de plus ? :)

Et maintenant ?


Et maintenant, tentons de conclure à contre-courant sur l'actualité de ce mois ?
  • Il y a au moins une différence entre #OpenSSL #HeartBleed et ce #Bash #ShellShock : Avions nous beaucoup d'autre choix que OpenSSL avant HeartBleed ? Vous savez autant que moi ce que OpenBSD puis Google ont décidé de faire pour "résoudre" le "problème".
  • #ShellShock est critique ? Le cumul ce mois-ci de correctifs critiques pour Firefox, Internet Explorer, Chrome, Safari, Adobe Flash, Adobe Reader (entre autres) ne l'est-il pas également (n'oublions pas que client/server-side n'est pas un critère métier) ? Succomber à la fascination de la partie émergée de l'iceberg serait une erreur.
  • #ShellShock vous prend du temps à corriger ? Attention, il vous reste 15 jours avant le patch tuesday Microsoft annoncé pour le 14 octobre 2014 ... accompagné du critical patch update trimestriel de Oracle annoncé le même jour :)

Je me permet de conclure en citant D. Aitel sur dailydave le 26 septembre 2014 (http://seclists.org/dailydave/2014/q3/66) : "This weird dichotomy between things that are vulnerable, and things that are at risk, is a real problem with the bash bug and right now it's being solved with consulting hours for most people. How do you go to the SEC and say "90% of our infrastructure is vulnerable"? Answer: You don't.".

Jess - @JessicaGallante

PS : @helpacsoout et @philoupas : merci ! @Nathplanteur : (kiss).

jeudi 25 septembre 2014

Sanguine est son humeur

Sanguine est son humeur avec son rire cristal
Toute habillée de pourpre elle se cache et se voile
et si sa voix charmeuse et ses yeux pleins d'étoiles
m'intimident et m'obsèdent, elle demeure digitale.

Jess - La vie est poésie

dimanche 21 septembre 2014

Elle scintille, elle est belle

Elle scintille, elle est belle
Elle inspire, rugissante
Elle se fache, elle est belle
Elle chantonne, lancinante

Je l'adore, elle est belle
je l'entend, à toute heure
je l'étreins, elle est belle
je la fuis, elle demeure

Et quand loin d'elle je reste, son souvenir j'isole
Ainsi quand vient la nuit, elle me berce et console

Jess - la vie est poésie

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.

lundi 30 juin 2014

Nuits de Juin

Les yeux fermés, l'oreille aux rumeurs entrouvertes, on ne dort qu'à demi d'un sommeil transparent.

5 Juin 2014 - Nouveaux CVE OpenSSL


Annonces concomitantes par OpenSSL de nouveaux CVE le 5 juin 2014 [1] et par OpenBSD [2] des fixes correspondants, prélude à une publication par Google de BoringSSL qui sera communiquée le 20 juin 2014 [3]. A dire vrai, je ne sais (pas encore) qu'en penser... Votre avis ?

10 juin 2014 - un véritable Patch Tuesday


Prenez place, nous sommes le 10 juin et nous assistons à la fois à la publication du Patch Tuesday Microsoft, à une mise à jour pour Adobe Flash (bien synchronisée à nouveau), à une mise à jour pour Mozilla Thunderbird, à un VMSA VMWARE mais également à une déferlante (?) sur tous les navigateurs : Internet Explorer 6/7/8/9/10/11 avec le MS14-035, Firefox avec 5 MFSA critiques et Chrome avec 4 security fixes.

Cet évènement est intéressant à double titre. D'une part car la synchronisation des publications sur la même (courte) période permet aux opérationnels d'enclencher leurs procédures organisationnelles et techniques de recette et mise à jour et d'autre part car la publication simultanée de bulletins sur toutes les technologies participant d'une même fonction replace la notion de priorisation des solutions de contournement au coeur du problème. Pour le 10 juin, que préférez-vous : recetter Firefox ou Chrome en priorité pour remplacement temporaire de Internet Explorer ou rusher l'application du bulletin Microsoft pour Internet Explorer en désactivant Firefox/Chrome ?

Mon avis personnel est qu'il n'y a pas de bonne ou mauvaise réponse à cette question pour autant que la sécurité du SI réponde adéquatement aux besoins des Métiers.

Quelques jours après le Patch Tuesday


Avec un patch Tuesday général comme celui du 10 juin, il convient de correctement poursuivre le suivi des publications ultérieures afin de (re)prioriser les plans de patch management en cours d'application. A titre d'exemple, sont publiés le 12 juin 2014 une série de bulletins pour Asterisk ou pour le framework Zend, divers correctifs pour Solaris 8/9/10/11 les 17 et 23 juin, des mises à jour de sécurité pour Chef Server le 26 juin...

Ce suivi, ce mode projet sur la gestion des vulnérabilités du SI me semble un impératif : la sécurité du SI est bien un travail à temps plein pour reprendre la citation de @helpacsoout (merci pour la relecture :p).

Juin 2014 c'est aussi Debian Squeeze LTS


Force est de constater que la création de la branche LTS pour Squeeze semble plus compliquée à mettre en oeuvre que pour la branche oldstable [4]. Ce projet semble néanmoins sur la bonne voie et serait une très bonne rampe de lancement pour enfin doter la distribution Debian d'une série LTS.

Et le mois de Juin c'est finalement


Et le mois de Juin c'est finalement une annonce de Microsoft fin juin qui indique la suspension de publication par email des notifications annonçant les bulletins de sécurité et avertissements de sécurité [5]. Cela peut bien entendu sembler anecdotique mais cela traduit bien le caractère fondamentalement vivant des mécanismes technologiques que nous employons pour assurer une veille pérenne en matière de sécurité du Système d'Information : rechercher et qualifier les sources ouvertes ou semi-publiques et les exploiter nécessite un investissement humain et ne peut totalement reposer sur une automatisation.

Et Maintenant

 

Et maintenant, avec le décalage horaire, n'oubliez pas d'aller consulter les Security Advisories Apple du 30 juin au soir :)

Jess - @JessicaGallante

PS : A nouveau merci à @helpacsoout et à @philoupas et à ma @nathplanteur à moi :)

Sources :

[1] : https://www.openssl.org/news/secadv_20140605.txt
[2] : http://ftp.openbsd.org/pub/OpenBSD/patches/5.5/common/008_openssl.patch.sig
[3] : https://www.imperialviolet.org/2014/06/20/boringssl.html
[4] : https://lists.debian.org/debian-lts/2014/06/maillist.html
[5] : http://seclists.org/microsoft/2014/q2/26

vendredi 30 mai 2014

Voici le mois de mai

Après le désormais fameux "Black April", voici le mois de mai où les fleurs volent au vent...

1er mai 2014 - Microsoft MS14-021 hors cycle et Fix OpenBSD pour SSL


Corrigeant le SA 2963983 publié le 26 avril, le MS14-021 publié par Microsoft le 1er mai a présenté la particularité de couvrir Windows XP après la fin de support standard de Windows XP. Geste particulièrement appréciable et apprécié de tous ceux avec qui j'ai pu échanger sur le sujet.

N'oublions pas un nouveau fix OpenBSD pour SSL publié à la même date qui devrait permettre aux DSI et RSSI de maintenir un niveau d'attention élevé sur l'application des correctifs en mode hors cycle.

8 mai 2014 - Notification avancée pour Adobe


Après avoir synchronisé (constatation personnelle sur les mois précédents) la publication de ses correctifs sur ceux de Microsoft, Adobe passe à la vitesse supérieure en fournissant une notification avancée des bulletins à sortir. Cette démarche me semble particulièrement adaptée à l'industrialisation des processus de cycle de patch management.

13 mai 2014 - Patch tuesday !


Comme attendu, le patch tuesday du 13 mai 2014 amène avec lui son lot de bulletins Microsoft et la correction de nombreux CVE pour Adobe Flash et Adobe Reader (certains ayant été reportés lors du Pwn2Own de mars 2014).

Le mois de mai c'est aussi


Des mises à jour OS X Mavericks le 15 mai, l'arrivée de repositories officiels Mysql pour Debian et Ubuntu le 20 mai, une série de fix pour les produits Cisco NX-OS-Based et une nouvelle version de Safari pour OS X le 21 mai, de nombreux patchs pour Solaris 8/9/10/11.1 le 22 mai et une (très) "mauvaise bonne idée" le 26 mai de transformer des Windows XP en "Windows Embedded POSReady 2009" pour (ne pas) bénéficier des correctifs jusqu'à 2019.

27 mai 2014 - Squeeze LTS !


Comme annoncé il y a quelques semaines, une prise en charge à long terme pour Debian Squeeze (6.0) est désormais officielle avec une date de clôture fixée au 6 février 2016. Ceci est une bonne nouvelle pour tous les sysops ayant décidé de suivre cette option avant de migrer vers Wheezy.

29 mai - Apothéose Truecrypt pour l'Ascension mais pas que


Le 29 mai sonne la fin du logiciel Truecrypt (ou pas, seul l'avenir nous le dira) et nous permet par la même occasion de formaliser une nouvelle facette particulière du processus de Patch Management : la décommision "hors cycle" d'un produit/logiciel déployé comme conclusion de l'analyse de risques afférente au traitement de la veille sur le niveau de vulnérabilité du Système d'Information. Sujet intéressant à traiter comme cas d'école dans le cas présent au vu de la fiabilité dudit logiciel (ANSSI-CSPN-2013/09 certifié en version 7.1a le 24/10/2013).

Mais le 29 mai c'est aussi (ne l'éclipsons pas avec ce "buzz" TrueCrypt) la sortie de la version 7u60 de Oracle Java ou la publication d'un bulletin vmware corrigeant une "guest privilege escalation" (sur Windows 8.1).

Et maintenant ?


Et maintenant, je profite d'un très bon article [1] "CISOs taking a leap of faith" publié sur www.csoonline.com le 28 mai 2014 par George V. Hulme et que je me permet de citer :

"Those who have been in security for a decade or more have usually built security programs from scratch. They’ve helped organizations recover from breaches. They’ve mentored new professionals. They’ve seen what works well and what doesn’t. And now they are ready to try new things."

... Oui, je pense que nous sommes tous volontaires pour tester de nouvelles approches dans un mouvement d'amélioration progressive et continue en brisant les silos et en instaurant le dialogue, c'est ce qui caractérise notre métier et c'est ce qui finalement fait la différence.

Jess - @JessicaGallante

PS : Merci @helpacsoout et @philoupas et bien entendu 1000 merci à ma jolie @nathplanteur à moi.

Sources :

[1] : http://www.csoonline.com/article/2212383/security-leadership/cisos-taking-a-leap-of-faith.html

mercredi 30 avril 2014

Black April

Avril 2014 aura été un mois particulièrement éprouvant pour les administrateurs et responsables sécurité informatique auxquels je tiens ici à manifester mon respect pour leur réactivité et leurs (très longues) nuits à investiguer/corriger leurs Systèmes d'Information (ceux avec qui je travaille se reconnaitront, je sais bien qu'on vient vous chercher des noises quand il y a un problème et que vous recevez rarement les compliments adéquats quand tout va bien).

Nous avons en effet subi^Wassisté  à un cumul de publications de vulnérabilités diverses ciblant toutes les technologies, tous les systèmes, tous les environnements. Bref un "black april" comme je l'ai maintes fois entendu depuis le début du mois.

 

7 et 8 avril - Heartbleed, Patch Tuesday et dernière mise à jour Windows XP


Avec la publication de la vulnérabilité OpenSSL (CVE-2014-0160 aka "Heartbleed") le 7 avril 2014 et la publication du Patch Tuesday Microsoft le 8 avril (et je n'oublie pas le bulletin de sécurité Adobe Flash le 8 avril 2014 également), la fin de support standard de Windows XP me semble momentanément avoir été éclipsée.

 

14 / 15 avril - (Le très attendu et trimestriel) Critical Patch update Oracle mais pas que...


Avec la correction de vulnérabilités dans de nombreux produits Oracle (Database, Fusion, WebLogic, Mysql) et les mises à jour de Solaris ou de Java, la mi-avril a clairement sonné comme un nouveau coup de tocsin pour des équipes déjà surchargées par les plans d'actions relatifs aux analyses liées à Heartbleed (publication le 14 avril du bulletin VMWARE, mises à jours quotidiennes du bulletin Cisco depuis le 9 avril, mises à jour OpenBSD les 7 et 12 avril pour OpenSSL).

 

26 - 29 avril - Microsoft SA2963983 pour Internet Explorer 6 à 11


La publication du SA 2963983 le 26 avril par Microsoft (non fixé au 30 avril) et un nouveau bulletin Adobe Flash le 29 avril permet finalement de constater que tous les processus de gestion des vulnérabilités devraient inclure la notion de contournement. Autant le déploiement de Flash peut ainsi (paradoxalement) paraître simple pour les administrateurs, autant les mesures de protection/contournement pour réduire l'exposition face aux vulnérabilités Internet Explorer paraissent compliquées (autrement que d'imposer l'usage temporaire d'un autre navigateur qui peut sembler simple et de bon aloi mais qui peut être ardu à implémenter sur certains SI).

 

Et maintenant ?


Mon avis personnel est que ce mois d'avril 2014 peut représenter un moment charnière pour de nombreux confrères, qu'ils apportent conseil et expertise ou qu'ils soient en charge de la sécurité de leurs organisations et entreprises.

Nous pouvons nous servir de ces évènements pour inception-ner la confiance des Directions Générales dans le paradigme d'une confiance dans les processus organisationnels et techniques de réaction "rapide" aux alertes et incidents (réduction des dommages et pertes) en l'opposant drastiquement aux mesures de prévention dont nous (en tant que professionnels) connaissons les limites (que eux ne connaissent qu'en terme de coupes budgétaires).

Il ne reste plus qu'à convaincre le métier comme dirait l'autre.

Jess - @JessicaGallante

PS : @NathPlanteur : juste merci :)