[Newsletter HSC] N°48 - Août 2008
Newsletter d'information de HSC
newsletter at hsc-news.com
Ven 1 Aou 09:12:51 CEST 2008
========================================================================
HSC Newsletter -- N°048 -- août 2008
========================================================================
"L'enthousiasme est à la base de tout progrès."
[ Henry Ford ]
--[ Sommaire ]----------------------------------------------------------
1. Editorial
2. Le saviez-vous ? La question
3. Photos des rallyes du Rouergue et du Terre de Langres
4. DNS cache poisonning par Alain Thivillon
5. Nouveautés du web HSC
6. Agenda des interventions publiques
7. Veille en vulnérabilités HSC
8. Offres d'emploi : consultants sécurité ISO 27001
9. Nouvelle formation : Gestion des Identités et des Accès
10. Nouvelle formation certifiante : ISO 27005 Risk Manager
11. Prochaines formations HSC
12. Tutoriels HSC et stand HSC à Infosecurity
13. Actualité des associations : Club 27001 et OSSIR
14. Le saviez-vous ? La réponse
--[ 1. Editorial - Gouvernance du Système d'Information ]---------------
par Hervé Schauer
La mode est à la gouvernance : gouvernance d'entreprise, gouvernance
mondiale, etc. La gouvernance ne voulant jamais dire la même chose
d'un interlocuteur à l'autre, cela sert souvent les intérêts de l'un
à l'encontre des autres. Dans l'informatique, la gouvernance du système
d'information m'apparaît encore plus à la mode et j'ai dis que l'ISO 27001
et la construction d'un SMSI dans un entreprise permettait de faire entrer
la SSI dans la gouvernance globale de l'entreprise et d'y trouver sa place...
Dans la newsletter de n°47 de juillet dernier nous annoncions la
formation certifiante "ISO 27005 Risk Manager" ou "Information Security
Risk Manager", suite à la publication de la norme ISO 27005 en juin dernier
par l'ISO. Dans le même temps l'ISO a publié la norme ISO/CEI 38500, qui
affiche le consensus international sur la notion de gouvernance du système
d'information.
La norme ISO 38500 est un document court qui pose des grands principes
au travers desquels elle répond aux préoccupations des organismes
sur la fiabilité et la rentabilité de leur informatique opérationnelle
et à la pertinence de leurs nouveaux investissements dans leur
infrastructure informatique. La norme s'applique à tout type d'organisme
quel que soit son métier et sa taille. Elle donne au DSI les grands
principes qu'il doit appliquer dans son métier, un peu dans une forme
PDCA.
L'ISO 38500 n'entre pas en contradiction avec le standard CoBIT des
cabinet d'audit informatique, ni avec les principes ITIL ou ISO 20000
car aucun modèle de processus de ses services informatiques n'est proposé
dans la norme.
En matière de sécurité l'ISO 38500 nous dit en 1.4.2 "le DSI peut être
considéré responsable des failles de sécurité propres aux ressources IT".
C'est léger mais cela a le mérite d'être écrit. Et en matière de gestion
des risques l'ISO 38500 nous dit en 3.3 : "Le DSI doit s'assurer que les
ressources IT font l'objet d'une appréciation des risques selon les normes
internationales". L'ISO 38500 nous renvoi là à la future norme ISO 31000,
norme de gestion de risques générale à tous les métiers (risques industriels,
santé, routiers, etc) et à l'ISO 27005 pour l'appréciation des risque en
sécurité de l'information. Nous voyons se dessiner des imbrications,
comme le processus "gestion de la sécurité" de l'ISO 20000-1 ou ITIL v3 est
une mise en oeuvre opérationnelle du SMSI de l'ISO 27001 (Système de
Management de la Sécurité de l'Information).
Les principes posés par l'ISO 38500 aident à évaluer chaque projet
d'investissement informatique ainsi que les capacités opérationnelles de
son organisme.
Une cohérence et un consensus international commencent à se dessiner
pour gagner en compréhension mutuelle et en efficacité. Tout un chacun a
intérêt à en profiter en commençant par appliquer l'ISO 38500, cela
permettra à tous de partager les mêmes principes et d'y voir plus clair.
--[ 2. Le saviez-vous ? La question ]-----------------------------------
Comment empêcher Tomcat d'afficher sa version dans les pages d'erreur ou dans
la bannière du connecteur HTTP ?
Réponse à la rubrique 14.
--[ 3. Photos des rallyes du Rouergue et du Terre de Langres ]----------
HSC sponsorise une Peugeot 106 16S qui participe aux rallyes du
championnat de France. La voiture a pour copilote Olivier Dembour,
consultant HSC.
Retrouvez les photos des rallyes du rouergue et du Terre de Langres
sur le web :
http://www.hsc.fr/societe/sponsoring/
--[ 4. DNS cache poisonning ]-------------------------------------------
------- Introduction ---------
Il est probablement bon de revenir sur l'évènement de sécurité du mois de
Juillet, dont l'écho a dépassé le petit monde de l'"industrie de la sécurité"
(dont la principale préoccupation est de "sécuriser son industrie") et dont
les médias ont largement parlé.
Pas facile de vulgariser sur un protocole aussi complexe que le DNS, dont
même la majorité des professionnels n'a qu'une idée vague du fonctionnement.
Nous avons toujours pensé ici que la configuration et le bon fonctionnement
du DNS était sous estimé dans la prise en compte de la sécurité, et que les
entreprises qui sous-traitaient la gestion de leurs serveurs de zones à des
sociétés dont elles ne savent rien commettaient une erreur fondamentale dont
les conséquences n'apparaissent que quand il est trop tard et que "le mail ne
passe plus !".
Dans la faille révélée, c'est néanmoins la fonction "résolution de nom" qui
est atteinte, celle qui permet au final aux applications clientes de
transformer "www.hsc.fr" en 217.174.211.25. Il est donc bon de rappeler que ce
n'est pas votre domaine vu de l'extérieur qui est en danger, mais les
résolutions qui sont effectuées pour la navigation web, l'envoi d'emails vers
d'autres domaines, la connexion aux VPN, et de fait, toutes les applications
Internet (mais aussi Intranet, même si l'enjeu est différent).
------- C'est quoi cette attaque ? ---------
La faille que Dan Kaminsky a découverte n'est pas neuve : on sait depuis
longtemps que le DNS est une machinerie dont la sécurité est faible, en
particulier parce que l'entropie des identifiants de question (TXID) est trop
faible (16bits). Ce que va montrer Kaminsky, c'est que l'exploitation du
problème est beaucoup (beaucoup beaucoup) plus simple que l'on ne le croyait.
Le principe de l'attaque repose toujours sur le "spoofing" IP d'une réponse
DNS : l'attaquant va essayer de répondre à une question avant les serveurs
légitimes, et remplacer la réponse par celle de son choix.
On pensait jusque là que pour que l'attaque réussisse, il fallait:
- soit que les numéros de questions soient prédictibles (ce qui a été le cas
plusieurs fois par le passé dans Bind),
- soit que les serveurs légitimes ne répondent pas (victimes d'un déni de
service),
- soit que les résolveurs soient largement buggés et acceptent des réponses à
des questions qu'ils n'ont pas posé, comme le serveur DNS de Microsoft tel
qu'il était livré et configuré dans Windows 2000,
- soit que l'attaquant puisse connaître la question (par écoute réseau).
L'attaque de Kaminsky repose sur la faculté de pouvoir _multiplier_ les
questions, et de compter sur la chance, en générant pour chaque question de
multiples réponses avec des TXID différents. Statistiquement, en ne pouvant
"glisser" dans l'intervalle avant la réponse du serveur que 20 fausses
réponses, cela fait 0.03% chances de succès. Mais si on réessaye 1000 fois,
on est déjà à 30%...
Comment faire en sorte de multiplier les questions posées ? Et bien là est
sans doute la nouveauté : au lieu de tenter d'empoisonner directement avec
l'enregistrement cible, il est possible d'empoisonner les enregistrements dans
la partie "Authority" de la réponse, et de changer ainsi _toutes_ les
résolutions ultérieures pour le domaine voulu. L'attaquant contrôlant ainsi le
serveur qui sera interrogé pour le domaine et la durée de vie de cet
information, il n'a plus qu'à attendre que l'enregistrement demandé expire
pour remplacer www.domainevoulu.com par la valeur qu'il désire.
Resolveur attaqué ns.domainevoulu.com
rand12456.domainevoulu.com ? IN A TXID 6789 ----------->
^
|
+------ rand12456.domainevoulu.com IN 127.0.0.1 TXID 8901|
+------ rand12456.domainevoulu.com IN 127.0.0.1 TXID 8902|
+------ rand12456.domainevoulu.com IN 127.0.0.1 TXID 8903| Pirate
+------ rand12456.domainevoulu.com IN 127.0.0.1 TXID 8904|
+------ rand12456.domainevoulu.com IN 127.0.0.1 TXID 8905|
<--------------------------------------------------------
rand12456.domainevoulu.com NXDOMAIN NS ns.domainevoulu.com
Les réponses forgées du pirate ont comme adresse source l'IP de
ns.domainevoulu.com et contiennent donc:
Answer:
rand12456.domainevoulu.com 3600 IN A 127.0.0.1
Authority:
domainevoulu.com 360000 IN NS piratens.domainevoulu.com
Additionnal:
piratens.domainevoulu.com 360000 IN A 191.23.45.56
ou 191.23.45.56 est l'adresse d'un serveur DNS contrôlé par l'attaquant.
Si un des TXID correspond, le resolveur va mettre en cache la réponse, et
selon les RFCs , _doit_ également conserver les enregistrements de la
partie Authority et s'y référer par la suite, ici pendant 100 heures !
Cette fonctionnalité est nécessaire afin que les gestionnaires de zone
puissent "écraser" ce qui est donné par le niveau supérieur (ici .com),
notamment pour des questions de maintenance et de déplacement des serveurs.
Ceci acquis, il reste à faire générer toutes ces questions, et de savoir
quand elles ont été posées. C'est là que les exploits publiés depuis quelques
jours sont médiocres et passent à coté de la vraie beauté de cette attaque.
Ils supposent en effet que l'attaquant puisse interroger le résolveur
attaqué, et donc que celui-ci soit 'récursivement ouvert', c'est à dire que
n'importe qui puisse lui demander n'importe quoi. Nous savons depuis plusieurs
années que c'est une mauvaise idée, et bien qu'évidemment les serveurs cache
des ISP soient ouverts au moins à leurs abonnés, ce n'est pas le cas des
serveurs résolveurs utilisés dans les entreprises, soit parce qu'ils sont
placés derrière des firewalls, et n'acceptent donc pas de requêtes DNS
entrantes, soit parce qu'ils sont configurés correctement (directives
"allow-query" et "allow-recursion" dans Bind).
Mais il est possible de faire générer relativement facilement des requêtes
vers un domaine arbitraire à un résolveur DNS : il suffit de cibler un de ses
clients : un humain avec un navigateur, un serveur de messagerie, voire un
serveur Web; et d'utiliser un instrument du diable, reconnu comme tel depuis
des années pour les problèmes opérationnels qu'il crée et la non compréhension
de son fonctionnement : l'enregistrement DNS de type CNAME (Canonical Name).
Dans l'attaque, ce type d'enregistrement sera utilisé ainsi (c'est un
exemple) : l'attaquant convainc une victime de passer sur sa page (ou lui
envoie un mail) contenant des milliers d'appels (de simples tag HTML <IMG>
peuvent suffire) à un domaine sous son contrôle:
<IMG SRC="http://rand768990.piratedomaine.com/blah.gif">
<IMG SRC="http://rand768991.piratedomaine.com/blah.gif">
<IMG SRC="http://rand768992.piratedomaine.com/blah.gif">
<IMG SRC="http://rand768993.piratedomaine.com/blah.gif">
<IMG SRC="http://rand768994.piratedomaine.com/blah.gif">
<IMG SRC="http://rand768995.piratedomaine.com/blah.gif">
Le serveur de nom NS.PIRATEDOMAIN.COM, qui contiendra le programme
d'exploitation, va recevoir les questions du résolveur utilisé par la victime.
Resolveur attaqué ns.piratedomain.com
rand768990.piratedomaine.com ? IN A TXID 15680 ----------->
<--- rand768990.piratedomaine.com IN CNAME rand768990.domainevoulu.com
Le nom rand768990.piratedomaine.com est renvoyé vers
rand768990.domainevoulu.com par un enregistrement CNAME traversant la
frontiere des domaines, et le resolveur attaqué va le résoudre en suivant
la méthode précédente. L'attaquant, dès qu'il a envoyé la réponse contenant
le CNAME, va attendre quelques millisecondes, puis spoofer les enregistrements
comme précédemment.
Il se dégage donc de la contrainte "Poser une question particulière
arbitraire", pour ne plus avoir que "Poser une question dans un domaine que je
contrôle".
Une autre technique, sans aucune interaction humaine utilise un courrier SMTP:
From: <nimportequoi at piratedomain.com>
To: <quelqueun at victime.com>
CC: <x at rand768990.piratedomaine.com>, <x at rand768991.piratedomaine.com>,
<x at rand768992.piratedomaine.com>, ....
Les serveurs de messagerie sont en effet susceptibles de canonicaliser
_toutes_ les adresses électroniques, pas seulement celles dont ils sont
responsables.
On peut imaginer d'autres techniques pour imposer à un serveur DNS (dont on
a même pas besoin de connaître initialement l'adresse IP) de venir faire
un petit tour chez soi ...
------- Ça permet de faire quoi ? --------------
Si un résolveur est "pollué" pour un domaine donné, il est dès lors possible
de diriger tout le trafic sortant des utilisateurs du résolveur à destination
de ce domaine vers les services du pirate. Cela inclue les requêtes HTTP, le
trafic Mail SMTP, les échanges FTP ou autres transferts de fichiers, le relevé
de mail par POP ou IMAP, ...
En revanche, tous les protocoles utilisant de la cryptographie permettant de
valider une identité généreront au minimum un avertissement : cela inclut
HTTPS évidemment, mais aussi SSH/SFTP, IMAPS ou POP3S. On arrive là en
revanche à une limitation humaine : les utilisateurs ne comprennent en général
pas les messages de leur navigateur, et par la faute d'administrateurs peu
prudents ou négligents, ont souvent pris l'habitude d'accepter tous les
certificats invalides ou signés par des autorités qui n'ont pas été intégrés
dans leurs navigateurs.
Une fois l'utilisateur amené sur un faux serveur gmail.com ou facebook.com,
il devient évidemment trivial de lui voler son mot de passe ou, pour des sites
de commerce électronique, son argent.
Une autre attaque inquiétante est la possibilité de remplacer des sites de
mises à jour des systèmes d'exploitation ou de logiciels dans le cas où les
nouvelles versions ne sont pas signées : c'est notamment le cas de la JVM Java
Sun, des mises à jour Apple (MacOS X et iTunes), de OpenOffice ou de Winzip.
Il y a alors un vrai risque d'injecter sur les postes clients des chevaux de
Troie.
------- C'est vraiment si facile ? ----------------------
L'attaque en elle-même est redoutablement efficace, même si elle suppose
quelques conditions qui ne sont pas forcément réunies par tous.
La limitation la plus criante pour un attaquant lambda ne disposant que de
sa machine est la nécessité de spoofer une adresse source, ce qui en
théorie, si les ISP suivaient les RFCs, ne devrait pas être possible. La
majorité des fournisseurs d'accès ADSL en France ont une configuration
sécurisée, mais ce n'est pas vrai de tous les pays, et surtout de tous les
fournisseurs de serveurs hébergés.
D'autre part, plus les serveurs DNS de la zone (et aussi le serveur DNS
résolveur) sont rapides et placés sur de bons liens, plus il est difficile
de glisser un grand nombre de réponses dans l'intervalle, ce qui peut
diminuer les chances de succès rapide. De même, plus la zone a de serveurs
DNS déclarés, plus il est nécessaire de spoofer de réponses, puisque il
est difficile de savoir lequel sera interrogé.
Enfin, les programmes d'exploitation publiés aujourd'hui sont écrits
dans des langages, qui en plus d'avoir une syntaxe improbable, sont lents.
Mais l'écriture des mêmes en C utilisant directement des raw sockets,
multipliant par 2 ou 3 le nombre de réponses envoyées, est très facile.
L'attaque utilisant les CNAME peut parfaitement être distribuée en
utilisant un BOTNET : après réception de la requête légitime, le serveur DNS
de l'attaquant peut prévenir le réseau de générer les réponses nécessaires,
_avant_ de répondre au résolveur.
------- Je dois faire quoi ? ----------------------------
Si vous êtes un gestionnaire IT qui a un résolveur DNS en contact avec
l'Internet, vous devez d'abord vérifier s'il est vulnérable, le plus simple
est d'utiliser la commande "dig" livrée avec Bind sous Unix:
- un mauvais serveur:
% dig @192.70.106.104 +short porttest.dns-oarc.net TXT
porttest.y.x.w.v.u.t.s.r.q.p.o.n.m.l.k.j.i.h.g.f.e.d.c.b.a.pt.dns-oarc.net.
"192.70.106.104 is POOR: 26 queries in 5.2 seconds from 1 ports with std dev 0
- un bon serveur :
% dig @217.174.211.25 +short porttest.dns-oarc.net TXT
porttest.y.x.w.v.u.t.s.r.q.p.o.n.m.l.k.j.i.h.g.f.e.d.c.b.a.pt.dns-oarc.net.
"217.174.211.25 is GREAT: 26 queries in 4.0 seconds from 26 ports with std dev 16357"
Pour les réfractaires à la ligne de commande, le service
https://www.dns-oarc.net/oarc/services/dnsentropy est intéressant, mais
il ne permet de tester _que_ le résolveur utilisé par votre navigateur.
Si vous êtes vulnérables, j'espère que cet article vous a convaincu qu'il
_faut_ mettre à jour. La correction que les éditeurs ont apporté ne bouleverse
pas le protocole, et le manque d'entropie du TXID n'est pas corrigé par magie.
Le correctif consiste à faire varier un autre paramètre de 16bits : le
numéro de port source UDP utilisé pour poser la question (jusqu'ici, la
plupart des implémentations utilisaient un port source fixe). La réponse est
attendue sur le même port : l'attaquant doit donc "deviner" deux nombres de
16 bits combinés au lieu d'un, et sa probabilité de succès est réduite à un
niveau statistiquement acceptable, même si elle est non nulle.
La vraie réponse est dans le déploiement d'une PKI dans le DNS à travers
DNSSEC, mais je pense que j'aurais quitté ce métier voire ce monde avant de le
voir déployé (oui, je prends un risque en disant cela).
------- La mise à jour ne va rien casser ? --------------
Hum. Si vous avez un DNS résolveur qui reçoit 10000 requêtes par seconde,
vous allez certainement avoir du mal : avoir UN socket UDP ouvert n'a pas le
même coût système qu'avoir N sockets ouverts (N étant le nombre de requêtes en
attente de réponse), surtout sur certains Unix commerciaux. Vous aurez
probablement des baisses de performances, et peut être même des plantages dus
à des limitations de ressources.
Si vous avez un DNS modérément chargé (grosso-modo si vous n'êtes pas un
ISP), ça devrait être à peu près transparent.
En revanche, attention si votre résolveur est placé derrière de la NAT : la
plupart des firewalls commerciaux (cela inclut Checkpoint et Cisco PIX)
changent alors les ports UDP source utilisés, et les rendent ... incrémentaux,
ce qui évidemment n'est pas une bonne définition du "hasard". Si vous êtes
dans ce cas, vous avez tout intérêt à utiliser le DNS de votre ISP en
"forwarder" s'il a été bien évidemment mis à jour.
------- Conclusion --------------------------------------
Les détails devaient être rendus publics le 6 Août, ils sont finalement
connus suite à une "erreur" depuis le 20 Juillet, mais ça ne change rien : à
partir du moment où le problème a été soulevé, il n'y avait qu'à réfléchir un
peu pour trouver la technique ... Il est même parfaitement possible que les
techniques évoquées ci-dessus soient connues depuis des années.
Depuis lors, on constate un certain nombre de requêtes interdites dans
les journaux, sans que l'on sache si il y a vraiment tentative d'exploitation.
La plupart des ISP commerciaux français ont mis à jour, bien qu'il reste du
travail, du coté de l'Internet sur mobile notamment.
On sait aussi que plus le serveur DNS est "petit", plus il a de chances
de ne pas être mis à jour, mais aussi plus petit sera la population menacée.
Il va falloir vivre un peu avec ce risque, se méfier encore plus des sites
"bizarres", être prudent avec les certificats invalides, prévoir encore
quelques mises à jour pendant les mois qui viennent afin que les performances
des serveurs DNS remontent.
Mais ce n'est pas parce qu'une technologie a des limites techniques qu'il
faut l'abandonner : on n'a pas trouvé mieux que le DNS en UDP non
signé, de la même manière que les essuie-glace sont encore des lamelles en
caoutchouc qui laissent des traces et des zones mouillées, même sur un
A380 du 21e siècle.
-- Alain Thivillon --
--[ 5. Nouveautés du web HSC ]------------------------------------------
- Transparents de la présentation "VMware et sécurité "
par Julien Raeis et Nicolas Collignon
Présentation effectuée au groupe SUR de l'OSSIR à Paris le 8 juillet 2008
http://www.hsc.fr/ressources/presentations/ossir_vmware_2008/
- Nouvelle formation certifiante "ISO 27005 Risk Manager"
par Anne Lupfer et Hervé Schauer
http://www.hsc.fr/services/formations/iso27005riskmanager.html.fr
- Nouvelle formation "Gestion des identités et des Accès"
par Thierry Durand et Anne Lupfer
http://www.hsc.fr/services/formations/formationIAM.html.fr
--[ 6. Agenda des interventions publiques ]-----------------------------
- 15 septembre 2008 : Paris Capitale du Libre - Remise des Lutèce d'Or
Hervé Schauer est membre du jury. Participez au concours :
http://www.paris-libre.org/
- 16 octobre 2008 : Assises de la Sécurité
Remise du prix de l'innovation en session plénière à Mobiquant
Hervé Schauer
http://www.lesassisesdelasecurite.com/accueil/prix.aspx
- 17 octobre 2008 : Assises de la Sécurité
Animation de la table-ronde "Réseaux de Confiance"
Hervé Schauer
http://www.reseauxdeconfiance.net/
http://www.lesassisesdelasecurite.com/accueil/atelier.aspx
Retrouvez l'agenda de nos interventions publiques sur
http://www.hsc.fr/conferences/agenda.html.fr
--[ 7. Veille en vulnérabilités HSC ]-----------------------------------
1373 08-07-2008 Exécution de code arbitraire distante sur l'activeX
snapview d'Access
1374 09-07-2008 Probleme d'empoisonnement de cache dans un grand nombre de
serveurs DNS
1375 31-07-2008 Exécution de code arbitraire sur le composant mod_weblogic
du serveur Oracle WebLogic
--[ 8. Offres d'emploi ]------------------------------------------------
HSC recrute des consultants sécurité ISO 27001.
HSC recrute régulièrement des consultants aptes à réaliser des
prestations techniques, nous recrutons également des profils plus
orientés management, capables d'accompagner les clients dans leur
démarche ISO27001 et aptes à participer aux projets ISO27001 menés par
HSC.
Les candidats devront avoir un bon contact humain, une bonne qualité de
rédaction en français et une maîtrise de l'informatique et des technologies.
Les ingénieurs sélectionnés peuvent être débutants et seront formés à la
sécurité et sur l'ISO27001 par HSC, soit de 3 à 7 semaines de formation
prises en charge par HSC.
Les postes sont basés à Levallois-Perret (à 5 minutes de Paris-St Lazare).
Si vous souhaitez proposer votre candidature, nous vous remercions d'envoyer
votre CV en format texte ascii par courrier électronique à cv at hsc.fr.
Pour plus d'informations : http://www.hsc.fr/societe/recrutement.html.fr
--[ 9. Nouvelle formation : Gestion des identités et des accès ]--------
Gestion des identités, annuaire partagé, IAM, role-based-management, etc,
facile à dire et entendu partout... Mais quand votre décision sera prise il
ne vous restera plus qu'à :
- comprendre, s'approprier
- expliquer,
- convaincre,
- architecturer, dimensionner,
- financer,
- choisir une solution technique,
- organiser, encore expliquer, encore convaincre, désigner, sensibiliser,
former ...
... et vous commencez par où ?
Avec nouvelle formation "Gestion des identités et des accès" conçue par
Phorcys (www.phorcys.fr) et HSC vous disposerez de tout ce que vous devez
savoir pour tracer votre propre itinéraire, celui qui vous conduira de
"votre décision" jusqu'au "système opérationnel" dont votre entreprise
a besoin, dans les conditions optimales.
Cette formation de 3 jours est dispensée par Thierry Durand (Phorcys) et
Anne Lupfer (HSC).
La première session de la formation "Gestion des identités et des accès"
est planifiées à Paris du 14 au 16 janvier 2009.
Objectifs, public visé et pré-requis, biographie des formateurs et
plan détaillé disponible sur :
http://www.hsc.fr/services/formations/gestion_des_identites.html.fr
Pour tout renseignement contactez Lynda Benchikh
formations at hsc.fr -- +33 141 409 704
--[ 10. Nouvelle formation certifiante : Information Security Risk Manager ]
Le 4 juin dernier l'ISO a publié la norme ISO 27005 "Information
Security Risk Management". Cette méthodologie de gestion de risques
pour la sécurité de l'information est le consensus international.
La norme est pragmatique et complète, utilisable dans toutes les
situations, et recommandée dans le cadre de la mise en place d'un SMSI
selon la norme ISO 27001. Elle s'inspire des méthodes existantes
comme la méthode EBIOS de la DCSSI ou la norme britannique BS7799-3.
L'organisme de certification LSTI (www.lsti.fr) a développé une
certification "ISO 27005 Risk Manager" ou "Information Security Risk
Manager", sur la base de la norme ISO 27005. HSC propose la formation
de 2,5 jours permettant de tenter cette nouvelle certification.
La formation HSC "Gestion de risques SSI" en deux jours, dispensée
depuis 2007, aura sa dernière session les 15 et 16 décembre 2008, et
sera en 2009 définitivement remplacée par la formation certifiante
avec 2,5 jours de formation et une demi-journée d'examen (2h30).
La formation "ISO 27005 Risk Manager" vous permet de devenir
gestionnaire de risques SSI, en sachant comment dérouler par vous
même et en toutes circonstances un processus de gestion des risques.
Cette formation permet aux consultants en sécurité d'assister les
entreprises dans la mise en oeuvre de leur gestion des risques en SSI.
Les premières sessions de la formation certifiante ISO 27005
Information Security Risk Manager sont :
- à Paris du 27 au 29 octobre 2008
- à Toulouse du 12 au 14 novembre 2008
- à Lyon du 27 au 29 avril 2009
Objectifs, pré-requis, formateurs et plan détaillé disponible sur :
http://www.hsc.fr/services/formations/iso27005riskmanager.html.fr
Pour tout renseignement contactez Lynda Benchikh
formations at hsc.fr -- +33 141 409 704
--[ 11. Prochaines formations HSC ]-------------------------------------
Nos prochaines formations sont les suivantes :
- Paris
Sécurité Internet/Intranet .......... : 4 et 5 septembre
ISO 20000-1 Lead Auditor ............ : 8 au 12 septembre
ISO 27001 Lead Auditor .............. : 15 au 19 septembre
Sécurité des réseaux et des transmissions : 22 au 24 septembre
Sécurité Windows .................... : 25 et 26 septembre
Sécurité des serveurs et applications web : 29 et 30 septembre
ISO 27001 Lead Auditor .............. : 22 au 26 septembre
Sécurité Unix et Linux .............. : 1 et 2 octobre
Sécurité des réseaux sans fil ....... : 3 octobre
ISO 27001 Lead Implementer .......... : 6 au 10 octobre
Réalisation pratique des Tests d'Intrusion : 13 au 17 octobre
ISO 27001 Lead Auditor .............. : 20 au 24 octobre
ISO 27005 Information Security Risk Manager : 27 au 29 octobre
Formation RSSI ...................... : 3 au 7 novembre
DNS ................................. : 12 novembre
Postfix et lutte contre le spam ..... : 13 et 14 novembre
L'essentiel de la série ISO27001 .... : 8 et 9 décembre
Réalisation pratique des Tests d'Intrusion : 8 au 12 décembre
Indicateurs et tableaux de bord SSI ... : 10 décembre
Mesures de sécurité ISO 27002 ....... : 11 et 12 décembre
Gestion de risques SSI (ISO 27005) .... : 15 et 16 décembre
Mutualisation ISO 27001, ITIL, Cobit : 17 décembre
- Fort-de-France (Martinique)
ISO 27001 Lead Auditor .............. : 11 au 15 mai 2009
- Genève (Suisse)
Réalisation pratique des Tests d'Intrusion : 27 au 31 octobre
ISO 27001 Lead Auditor .............. : 10 au 14 novembre
ISO 27005 Information Security Risk Manager : 18 au 20 février 2009
ISO 27001 Lead Implementer .......... : 1 au 8 mai 2009
- Liège (Belgique)
Sécurité des réseaux et des transmissions : 16 au 18 mars 2009
Sécurité des serveurs et applications web : 19 et 20 mars 2009
- Luxembourg
ISO 27001 Lead Auditor .............. : 13 au 17 octobre
ISO 27001 Lead Implementer .......... : 8 au 12 décembre
ISO 27001 Lead Auditor .............. : 25 au 29 mai 2009
ISO 27001 Lead Implementer .......... : 22 au 26 juin 2009
- Lyon
ISO 27001 Lead Implementer .......... : 8 au 12 décembre
ISO 27005 Information Security Risk Manager : 27 au 29 avril 2009
ISO 27001 Lead Auditor .............. : 7 au 11 décembre 2009
- Nice
ISO 27001 Lead Implementer .......... : 29 juin au 3 juillet 2009
- Strasbourg
ISO 27001 Lead Auditor .............. : 9 au 13 février 2009
- Toulouse
ISO 27005 Information Security Risk Manager : 12 au 14 novembre
Sécurité des réseaux et des transmissions : 24 au 26 novembre
Sécurité des serveurs et applications web : 27 et 28 novembre
Sécurité Windows .................... : 1 et 2 décembre
Sécurité de la VoIP/ToIP ............ : 3 décembre
Sécurité des réseaux sans fil ....... : 4 décembre
ISO 27001 Lead Implementer .......... : 2 au 6 mars 2009
Pour tout renseignement contactez Lynda Benchikh
formations at hsc.fr -- +33 141 409 704
Pour les formations à Luxembourg contactez Irina Neagu :
seminars at pt-consulting.lu ---- http://www.ptc.lu/
Tél : +352 40 26 26 40 -- GSM : +352 621 317 335 -- Fax : +352 40 24 34
Pour la formation Tests d'Intrusion à Genève contactez Aurélie Pernet :
sales at idsa.ch ---- http://www.idsa.ch/
Tél : +41 22 879 8550 -- Fax : + 41 22 793 8632
Pour les formations certifiantes à Genève contactez Jean-Benoit Fontaine :
jbf at iseig.ch ---- http://www.iseig.ch/
Tél : +41 21 654 4060 -- Fax : + 41 21 654 4069
Rappel : pour 4 jours de formation consécutifs commandés
simultanément par la même personne, le 5ème jour est offert (sauf
formations d'une semaine et certifiantes).
Vous souhaitez des formations dans votre ville ? Contactez Hervé Schauer.
Retrouvez le détail de nos formations (plan pédagogique, agenda) ainsi que
notre catalogue sur http://www.hsc.fr/services/formations/index.html.fr
--[ 12. Tutoriels HSC et stand HSC à Infosecurity ]---------------------
HSC sera présent pour la troisième fois à l'exposition Infosecurity
à Paris les 19 et 20 novembre 2008. Attention en raison des travaux du
CNIT, Infosecurity se déroule au Parc des expositions Porte de Versailles :
http://www.infosecurity.com.fr/). HSC sera sur le stand B21.
- Un consultant HSC et le responsable commercial étudieront vos projets
- Profitez d'une offre exclusive salon : réduction de 10% sur le
catalogue 2008 des formations commandées sur place.
Comme depuis 8 ans au salon Infosecurity, HSC propose 2 tutoriels
en exclusivité :
-> "Gestion des risques SSI selon l'ISO 27005" le 19 novembre
http://www.hsc.fr/conferences/reed2008_gestionrisques_ISO27005.html.fr
Ce tutoriel vous apprend à mener un processus de gestion
du risque conformément à la norme ISO 27005. Par l'étude d'un
cas pratique, vous apprendrez à réaliser une appréciation
des risques (analyse de risque + évaluation des risques) en
utilisant les principes, l'ordonnancement et les méthodes de
la norme ISO 27005.
-> "Sécurité de la Voix sur IP" le 20 novembre
http://www.hsc.fr/conferences/reed2008_securite_voip.html
Ce tutoriel d'une journée présentera les aspects sécurité des
différents protocoles sans revenir sur les bases protocolaires. Il
abordera les risques de certains softphones très répandus. De bonnes
pratiques en vigueur seront détaillées afin d'implémenter des
architectures sécurisées, des attaques VoIP pratiques et réalisables
seront décrites tout comme les moyens de s'en protéger. Ces exemples
d'attaques s'appuieront sur l'expérience de tests d'intrusion
effectués par HSC.
Organisateur : Reed Exhibitions
Prix pour chaque tutoriel : 650 euros HT
Contact pour vous inscrire : Sandrine.Jean at reedexpo.fr
Tél : +33 (0)147 566 545 -- Fax : +33 (0)147 566 547
--[ 13. Actualité des associations : Club 27001 et OSSIR ]--------------
o Club 27001 (http://www.club-27001.fr/)
. Le Club 27001 a créé un logo sur linkedin. Les membres d'une des
listes électronique du Club peuvent demander à entrer dans le groupe
"Club 27001".
. Attention : prochaine réunion exceptionellement un mercredi au
lieu d'un jeudi (conflit sur la date du jeudi)
. Prochaine réunion à Paris le mercredi 17 septembre à 14h00.
Comme décidé lors de la réunion du 15 mai 2008, cette réunion servira
d'assemblée constituante à une association.
. Pourquoi le club 27001 en association ?
Avoir une structure associative permettra d'avoir un conseil
d'administration élu par les membres, qui complétera les groupes de
travail de Paris, Toulouse, Rennes, etc. Ce conseil pourra notamment
prendre des décisions et formaliser ce qui ne l'était pas auparavant,
comme par exemple :
- décider en commun de la réponse à donner aux interview et émettre des
communiqué de presse comme lors qu'une norme importante est publiée
- formaliser un partenariat avec une autre association
- formaliser un partenariat avec un organisateur de manifestation
- pouvoir encaisser d'éventuels surplus de la conférence annuelle
du club
- financer les déplacements de conférenciers
- prendre un hébergement pour le serveur web permettant à chaque
groupe régional de mettre à jours lui-même sa partie
- développer la promotion des normes et faire une plaquette
. Conférence du 20 novembre 2008 lors du salon Infosecurity
Le programme est en cours d'élaboration par le comité de programme.
Réservez votre date !
o OSSIR (http://www.ossir.org/)
. Prochaine réunion à Paris le mardi 9 septembre à 14h00 :
- Compte-rendu de la conférence Blackhat de Las Vegas par
Cédric Blancher (EADS) et Franck Veysset (Orange-FT)
. Rappel : le conseil d'administration du 10 juin 2008 a décidé de
fusionner les deux groupes Sécurité Windows et Sécurité Unix à Paris.
--[ 14. Le saviez-vous ? La réponse ]-----------------------------------
Cette signature doit être désactivée à deux endroits :
- La chaîne retournée dans l'entête Server: par le connecteur HTTP se modifie
en éditant le fichier conf/server.xml et en intervenant sur la balise
Connector, en ajoutant le paramètre server=
<Connector
port="8081"
server="Bling-Bling HTTP Server"
redirectPort="8443"
minSpareThreads="25"
connectionTimeout="20000"
maxSpareThreads="75"
maxThreads="150">
</Connector>
- Le numéro de version renvoyé par les pages d'erreur peut se modifier en
éditant le fichier org/apache/catalina/util/ServerInfo.properties du
fichier ${CATALINA_HOME}/lib/catalina.jar :
jar xf catalina.jar org/apache/catalina/util/ServerInfo.properties
echo "server.info=Bling-Bling HTTP Server/19640728" \
> org/apache/catalina/util/ServerInfo.properties
echo "server.number=1964.07.28" \
>> org/apache/catalina/util/ServerInfo.properties
echo "server.build=Jul 28 1964 12:00" \
>> org/apache/catalina/util/ServerInfo.properties
jar uf catalina.jar org/apache/catalina/util/ServerInfo.properties
- Il faut relancer le serveur et tester:
% telnet 127.0.0.1 8081
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
GET /nonexistent HTTP/1.0
Host: 127.0.0.1
HTTP/1.1 404 /nonexistent
Content-Type: text/html;charset=utf-8
Content-Length: 1012
Date: Thu, 31 Jul 2008 12:44:05 GMT
Connection: close
Server: Bling-Bling HTTP Server
<html><head><title>Bling Bling HTTP Server/19640728 - Error report</title>
...
Bling HTTP Server/19640728</h3></body></html>
- Une autre méthode peut être utilisée afin d'obtenir le même résultat sans
pour autant avoir à modifier l'archive catalina.jar. En effet, modifier
ce fichier à chaque mise à jour dans un environnement de production n'est
pas évident.
La technique utilisée est assez proche du principe du API Hooking.
Concrètement, le serveur HTTP de tomcat (StandardServer) utilise la classe
ServerInfo pour lire le contenu du fichier ServerInfo.properties.
Étant donné qu'il est impossible d'hériter de StandardServer (la classe
est déclarée comme "final") pour modifier la fonction getServerInfo, la
méthode consiste à modifier directement la classe ServerInfo.
Donc la première étape est de développer une classe ServerInfo.
Il suffit ensuite de compiler la classe modifiée :
$ javac ServerInfo.java
et de la recopier dans un répertoire en gardant l'arborescence de base :
$ mkdir -p $CATALINA_BASE/boot/org/apache/catalina/util/
$ cp ServerInfo.class $CATALINA_BASE/boot/org/apache/catalina/util/
La même technique peut être utilisée sur le fichier Constants.java du
connector HTTP Coyote si l'on ne souhaite pas modifier le fichier
server.xml.
Ensuite, il faut utiliser le paramètre -Xbootclasspath de la JVM java pour
charger notre ServerInfo.class "maison" avant celui fournit
avec catalina.jar. "-Xbootclasspath" est un peu le LD_PRELOAD de Java :)
Pour cela, modifiez $CATALINA_BASE/bin/catalina.sh comme cela :
JAVA_OPTS="-Xbootclasspath/p:$CATALINA_BASE/boot"
Le "/p" permet d'éviter les erreurs liées au référencement de classes
non chargées depuis notre ServerInfo.class.
Idée : Nicolas Collignon et Louis Nyffenegger
Plus d'informations sur la liste de diffusion newsletter