Veille Technologique Sécurité

Transcription

Veille Technologique Sécurité
Rapport Mensuel N°132
JUILLET 2009
Les informations fournies dans ce document ont été collectées et compilées à partir de sources d'origines diverses et
publiquement accessibles: listes de diffusion, newsgroups, sites Web, ...
Ces informations sont fournies pour ce qu'elles valent sans garantie d'aucune sorte vis à vis de l'exactitude, de la
précision ou de la qualité de l'information. Les URL associées à certains thèmes sont validées à la date de la rédaction du
document.
Dans ce numéro:
La conférence RFID2009
EQR - La revue de l’ENISA
Le CERT Resilience Management Model
NMAP V5.00
Extensions DNSSEC et EDN0
Les marques et les produits cités dans ce rapport sont la propriété des dépositaires respectifs.
CONNECTING BUSINESS & TECHNOLOGY
DEVOTEAM – BU Sécurité
1, rue GALVANI
91300 Massy Palaiseau
Pour tous renseignements:
Offre de veille
http://www.devoteam.fr/
Informations
[email protected]
©DEVOTEAM Solutions - Tous droits réservés
JUILLET 2009
Au sommaire de ce rapport…
ACTUALITES SECURITE
LE PROJET ‘ZONE-ROOT ARCHIVE’
SUR LA TRAVERSEE DES FRONTIERES
UN HISTORIQUE DES PROCEDES DE PROTECTION DES EXECUTABLES
LE ‘DNS HELPER SERVICE’ COMCAST
SUR LA COMPLEXITE DE LA MAINTENANCE D’UNE APPLICATION
2
3
4
5
5
ANALYSES ET COMMENTAIRES
ETUDES
ENISA - FONCTIONNALITES DES CARTES D’IDENTITE ELECTRONIQUES
7
CONFERENCES
RFID09
PATHCHECKER: An RFID application for tracing products in Supply-chains
Mifare Classic troubles
Cloning MiFare Classic Rail and Building Passes, Anywhere, Anytime
When Compromised Readers Meet RFID
8
8
8
10
10
LOGICIELS
INSECURE.ORG – NMAP 5.00
OARC – DNS REPLY SIZE TEST SERVER
11
12
MAGAZINES
ENISA - QUARTERLY REVIEW
Information Sharing Exchanges
Strategie and Business Risk
Privacy
Security of Wireless Networks
13
14
15
15
16
METHODOLOGIES ET STANDARDS
METHODES
SEI – CERT RESILIENCY MANAGEMENT MODEL
18
RECOMMANDATIONS
CERTA – NOTE SUR LES SYSTEMES ET LOGICIELS OBSOLETES
19
STANDARDS
RFC 5598 - EMAIL ARCHITECTURE
21
TABLEAUX DE SYNTHESE
CONFERENCES
NANOG 46
RFIDSEC09
24
24
GUIDES
CERTA – NOTES ET AVIS
NIST – ETAT DES GUIDES DE LA SERIE SPECIALE 800
25
26
MAGAZINES
28
INTERNET
LES DECISIONS DE L’OMPI
28
STANDARDS
IETF – LES RFC TRAITANT DIRECTEMENT DE LA SECURITE
IETF – LES RFC LIES A LA SECURITE
IETF – LES NOUVEAUX DRAFTS TRAITANT DE LA SECURITE
IETF – LES MISES A JOUR DE DRAFTS TRAITANT DE LA SECURITE
Veille Technologique Sécurité N°132
© DEVOTEAM - Tous droits réservés
29
29
29
29
Page i
Diffusion restreinte aux clients abonnés au service de veille technologique
JUILLET 2009
Le mot du rédacteur
En ce mois d’été largement consacré aux loisirs, nous avons particulièrement apprécié
l’approche retenue par la société Amazon pour résoudre un épineux problème
juridique concernant les droits d’auteurs de deux livres ayant été légalement achetés
par de nombreux possesseurs de la tablette ‘Kindle’.
Amazon se serait en effet permis d’accéder à distance, et sans aucun avertissement
préalable, aux tablettes de lecture des acheteurs pour y supprimer les ouvrages
litigieux, ouvrages ensuite remboursés aux acheteurs. La presse s’est rapidement
emparée de l’affaire avec des références appuyées sur l’attitude ‘Big Brother’
d’Amazon, le hasard voulant que l’un des ouvrages retirés soit le célèbre ‘1984’ de
Georges Orwell. Cette affaire soulève surtout la question de la légalité de l’action
d’Amazon au regard d’un accès non autorisé – les conditions de vente ne mentionnent
pas cette possibilité - sur un équipement ne lui appartenant pas. Le problème se serait
posé différemment avec un système de gestion des droits permettant de résilier ceuxci en temps réel.
Avec cette première affaire, le monde numérique apparaît dans toute son ambiguïté. Il
sera sous peu nécessaire d’écrire une nouvelle version de Fahrenheit 451, les
autodafés du futur ne nécessitant plus de combustible. Et comme le note un
journaliste de Libération:
Dans une ère où le numérique est censé simplifier la vie, il finit par la compliquer. Un livre
numérique acheté aujourd’hui sur un Kindle ne peut être ni prêté ni donné. Summum : il
peut même être récupéré…
http://www.liberation.fr/medias/0101580884-big-brother-amazon-la-surprise-kindle
Le projet de loi relatif à la programmation militaire pour les années 2009 à 2014 et
portant diverses dispositions concernant la défense intègre un très intéressant chapitre
relatif à la ‘Lutte informatique offensive’ - Art. 2.5.1.9 – dans le volet consacré à
‘l'intervention sur un spectre large d'opérations’.
L'adaptation de notre défense à la lutte dans le cyberespace nécessite en premier lieu de fixer une
doctrine et une organisation, d'identifier et de former les personnels dédiés à cette capacité, de les
organiser, de mener des expérimentations techniques et de développer des outils spécifiques, dans le
respect du droit. Cette capacité dont les premières bases seront posées dès l'été 2009, constituera l'une
des clés de la supériorité opérationnelle.
Le terme qualificatif – ‘offensif’ - venant en complètement de la définition de l’objectif
– ‘la lutte informatique’ – confirme la volonté de développer une capacité permettant
de prendre l’initiative et d’engager toutes les actions offensives requises. Un virage
amorcé il y a quelque temps par la création d’un laboratoire de virologie et de
cryptologie hébergé par l’ESAT.
http://www.senat.fr/leg/pjl08-514.html
BERTRAND VELLE
Page 1/35
JUILLET 2009
ACTUALITES SECURITE
LE PROJET ‘ZONE-ROOT ARCHIVE’
Le centre d’étude DNS-OARC (Domain Name System Operation, Analysis, and Research
Center) vient d’annoncer la création du projet ‘Zone-Root Archive’.
Celui-ci a pour ambition de conserver un historique de l’évolution de configuration de la zone racine du DNS
mais aussi des fichiers d’un certain nombre de domaines de premier niveau, ou TLD, représentatifs.
Le système de gestion de noms utilise une structure arborescente, et hiérarchisée, dans lequel tous les
noms peuvent être résolus par le parcours de cette structure à partir de sa racine, ou ‘root’, représentée par
convention à l’extrême droite du nom de domaine d’une ressource. Les requêtes de résolution portant sur la
constitution du premier niveau hiérarchique du DNS aboutissent sur des serveurs, dits serveurs racines. Le
fichier de configuration de ces serveurs, dit fichier ‘zone-root’, contient la liste des serveurs responsables
de la gestion de ce premier niveau, c'est-à-dire des TLD et ccTLD.
L’archivage de l’évolution de la constitution de ce fichier, et des fichiers de configuration des domaines de
premier niveau les plus importants tels les TLD .com, .net ou encore .org, permettra d’étudier l’évolution
de la structure logique de l’Internet sur le long terme.
A ce jour et grâce à l’aide de certains de ses membres au rang desquels l’AFNIC, DNS-OARC dispose de
copies du fichier racine lui permettant d’établir un historique fiable des évolutions de la racine depuis juillet
1999. DNS-OARC lance cependant un appel pour compléter ses archives notamment sur les années 1999,
2001 et 2002, années pour lesquelles elle ne dispose que d’une ou deux copies.
Un premier graphe de tendance a pu ainsi être établi, et publié mi-juillet, qui fait parfaitement apparaître le
lent déploiement du protocole IP V6, et de la déclaration de ressources disposant d’une adresse IP V6
(enregistrements AAAA en jaune sur le graphique).
DNS-OARC annonce par ailleurs qu’elle archive les fichiers de configuration de neuf TLD -.com, .net, .org,
.info, .biz, .name, .asia, .pro et .aero - depuis mars 2009 avec une périodicité hebdomadaire. Ces archives
sont accessibles, sous certaines conditions, aux membres de l’OARC qui souhaiteraient mener leurs propres
recherches.
POUR PLUS D’INFORMATION
https://www.dns-oarc.net/oarc/data/zfr/root
Page 2/35
JUILLET 2009
SUR LA TRAVERSEE DES FRONTIERES
Dans un article intitulé ‘Laptop Security while Crossing Borders’ publié dans la revue
‘Wired’, Bruce Schneier suggère un mode opération astucieux pour garantir que les
données stockées sur un portable, ou un support amovible, ne pourront jamais être
interceptées par les douanes de certains pays lors du passage de la frontière.
Son protocole comporte 5 étapes:
1- Une clef totalement aléatoire est créée et ajoutée à l’anneau des clefs de chiffrement du disque dur,
2- L’utilisateur transmet cette clef à quelqu’un de confiance et en contrôle la bonne réception,
3- La clef de chiffrement transitoire peut alors être oubliée,
4- L’utilisateur peut travailler durant le voyage en utilisant la clef originale,
5- Avant d’atterrir, cette clef est détruite interdisant tout accès à l’ordinateur, et au contenu du disque,
même par son détenteur,
6- Une fois la douane passée, l’utilisateur contacte le dépositaire pour récupérer la clef transitoire, accède
à sa machine, et recréé sa clef usuelle.
L’utilisateur ne pourra prétendre échapper aux possibles tracas que sa démarche engagera, de la simple
confiscation de l’équipement jusqu’à la mise en demeure de livrer la clef de chiffrement. Bruce Schneier
suggère de présenter une copie de son article aux fonctionnaires récalcitrants mais nous doutons de
l’efficacité de cette démarche, rien dans le protocole proposé ne permettant de prouver, sans doute
possible, que toutes les clefs d’accès ont bien été détruites.
Ce mode opératoire est rendu possible par l’existence de produits de chiffrement autorisant l’utilisation de
plusieurs clefs d’accès, ces clefs étant en réalité utilisées pour (dé)chiffrer la véritable clef de chiffrement
du disque, inconnue de l’usager.
Sa mise en pratique est cependant bien moins évidente que l’article pourrait le laisser supposer. Se pose
tout d’abord la question de la solidité de l’implémentation du mécanisme de dérivation de la clef de
chiffrement du disque, et du procédé de génération de cette dernière. Rien ne servirait en effet de
générer une clef transitoire robuste si la clef de chiffrement du disque est incorrectement générée.
L’utilisation d’un produit Open Source permet de se garantir d’un tel problème. Vient ensuite la question
de l’application de la phase 6, à savoir la récupération de la clef transitoire et son introduction dans le
système lors du démarrage.
Une opération simple à décrire mais bien plus complexe à mettre en pratique.
Il s’agira tout d’abord de transmettre la clef transitoire en n’oubliant pas qu’elle aura été générée de
manière purement aléatoire (et non sous la forme d’une phrase mnémotechnique). Le portable ne
pouvant être démarré, on peut imaginer que le dépositaire la transmette par SMS, ou tout autre moyen
moderne, plutôt que de l’épeler au téléphone. Une courte période de vulnérabilité existe entre le moment
où cette clef est transmise – et peut être assez aisément interceptée – et celui où le portable aura été
reconfiguré pour utiliser la clef usuelle de l’utilisateur.
Il s’agira ensuite de l’introduire caractère par caractère sans erreur aucune. Une opération qui
heureusement ne sera effectuée qu’une seule fois, l’utilisateur réactivant immédiatement sa clef usuelle
et ne pouvant alors plus prétendre ignorer la clef permettant de déverrouiller l’accès.
On notera que Bruce Schneier ne propose aucune solution pour l’étape du retour, le mode opératoire
décrit ne pouvant s’appliquer, sauf à confier la clef transitoire à quelqu’un résidant dans le pays visité. Il
serait en effet bien risqué de transmettre celle-ci au-delà de la frontière en utilisant des moyens
susceptibles d’être contrôlés localement, et ce avant d’avoir passé la frontière...
Le problème de la fouille des équipements informatiques aux frontières n’est pas nouveau mais il se pose
désormais avec d’autant plus d’importance que les systèmes portables se sont démocratisés, et que les
capacités de stockage permettent d’emporter bien plus de dossiers qu’il n’en faut réellement. Dans un
contexte difficile, où la lutte contre le terrorisme est annoncée être priorité nationale par de nombreux
pays, les mesures de contrôle mises en place au frontière sont l’occasion de glaner des informations utiles
à la défense mais aussi à l’économie du pays. La Chine est bien souvent montrée du doigt mais d’autres
états ont, de longue date, procédés à la fouille en règle des matériels. Les procédés ne changent pas,
seuls les équipements utilisés pour ces opérations ont bien évolué. Quand il y a quelques années encore,
le douanier se contentait de demander poliment l’ouverture et l’allumage d’un équipement pour s’assurer
prioritairement qu’il ne s’agissait pas d’un leurre cachant une bombe, ce même douanier empruntera
désormais cet équipement quelques minutes pour effectuer une copie de son contenu.
Le mode opératoire proposé par Bruce Schneier ne permet pas de répondre totalement au problème,
nous l’avons vu. Il pourrait même s’avérer dangereux lors du passage de la frontière de pays considérant
qu’un chiffrement fort est assimilable à une arme de guerre, un problème que nous avons depuis
quelques temps tendance à oublier mais qui reste d’actualité. L’approche que nous considérons être la
plus satisfaisante consisterait à emporter avec soi un portable préalablement nettoyé et installé avec une
image contenant tous les outils requis, outils de bureautique mais outils réseaux dont un client VPN
Page 3/35
JUILLET 2009
configuré à minima. L’usager passera la frontière sans aucun souci puis accédera à ses dossiers par le
biais d’un VPN établi depuis son lieu de villégiature, ou encore en rechargeant un volume chiffré
préalablement stocké sur un site fiable. Ce site pourra être un site géré à cette fin par l’entreprise ou
encore un service externe, tel par exemple, le service ‘Steekr’ qui offre un espace de stockage gratuit de
1Go pour une période d’un an, espace dans lequel les dossiers sont accessibles à partir de n’importe quel
navigateur. Bien d’autres approches pourront être envisagées qui toutes cependant reposent sur une
constante: l’usager devra mémoriser la clef d’accès aux données, clef qui pourra toujours être obtenue
par des méthodes coercitives.
http://www.schneier.com/blog/archives/2009/07/laptop_security.html
UN HISTORIQUE DES PROCEDES DE PROTECTION
DES EXECUTABLES
Nicolas Brulez, expert français de la retro analyse de code qui a rejoint la société
Websense après avoir fait ses premières armes chez Cartel Sécurité, vient de
publier un excellent historique des procédés de protection des binaires Windows
contre la retro-analyse.
Intitulé ‘Win32 Portable Executable Packing Uncovered’, ce document technique de 29 pages rédigé
en anglais détaille tout d’abord les différentes approches utilisées pour protéger un binaire contre toute
tentative de retro-analyse, de la ‘simple’ adaptation d’un outil de compression conçu pour limiter la taille
occupée sur le disque par le code d’une application au système conçu spécifiquement pour déjouer tous
les procédés d’analyse existants et à venir.
Le second volet traite des procédés permettant d’interdire l’acquisition de tout ou partie du code en
mémoire au moment de son exécution. Car il ne faut pas l’oublier, le code binaire original sera tôt ou tard
exposé, en totalité, ou par petites portions, lors de l’exécution de l’application.
Toute l’astuce du concepteur d’un système de protection consistera donc à réduire au maximum la fenêtre
d’exposition du code clair lors de l’exécution de l’application, à masquer la structure de ce code mais aussi
toutes les informations susceptibles de faciliter l’analyse du système de protection lui-même.
Il conviendra de discerner deux domaines d’utilisation pour ces mécanismes de protection:
1 La protection contre la copie d’une œuvre numérique, une application dont le comportement est
parfaitement connu et reproductible. L’objectif de la retro-analyse sera alors d’identifier les verrous de
protection pour les faire sauter en disposant bien souvent d’une licence d’utilisation officielle. Le
procédé de protection intégrera généralement non seulement un mécanisme de vérification du droit
d’exécution mais aussi un ensemble de mécanisme de protection ayant pour objet de complexifier la
tâche d’analyse. Une approche que l’on pourrait qualifier de ‘ceinture et bretelles’, un bon système de
protection contre l’usage non autorisé ne nécessitant théoriquement pas d’autres protections hors peutêtre celle apportée par un élément matériel externe, et non reproductible. L’analyste étant ici réputé
avoir tout son temps, on demandera par contre à ce système de protection d’être robuste sur le long
terme mais aussi d’être facile à intégrer dans la chaîne de production pour être aisément modifié en cas
de mise en défaut.
2 La protection contre l’analyse du comportement d’un code que l’on ne pourra exécuter tel quel sans
risque, ou sans perdre un temps précieux, ce code étant généralement un code malveillant, l’analyste
œuvrant alors ici du ‘bon coté’. L’objectif du concepteur du système de protection sera de ralentir au
maximum l’analyse du comportement du code protégé afin de prolonger son action autant que peu se
faire. Le concepteur n’a ici aucune contrainte quant au choix d’un mécanisme, ni même sur sa fiabilité.
Que le code protégé ne fonctionne pas dans certains environnements du fait d’un choix technique osé
est certes dommageable mais si cela concoure à renforcer la durée de vie de la protection, et par
conséquent la durée de vie du code, les objectifs seront atteints.
Dans sa conclusion, Nicolas Brulez précise qu’il n’a pas traité des techniques les plus avancées, celles-ci
étant généralement employées par les produits de protection commerciaux, tel le système ‘Armadillo’
(SoftwarePasswport) de la société ‘Silicon Realm Toolworks’ sur lequel il a travaillé. La lecture des
résultats des analyses de certains malwares publiés sur le Net laisse cependant entrevoir une réelle
évolution dans la complexité, et la performance, des mécanismes embarqués par certains de ces
malwares. Dans bien des cas, et afin d’extraire au plus vite les propriétés caractéristiques de ces
malwares – les adresses des serveurs utilisés pour se mettre à jour par exemple ou encore la liste des
mots clefs à rechercher dans les URL saisies par l’usager dans le cas de malwares bancaires – les
analystes auront recours à l’utilisation de plateformes dédiées à l’aide desquelles il sera possible
d’observer l’exécution du code.
http://securitylabs.websense.com/content/Assets/HistoryofPackingTechnology.pdf
Page 4/35
JUILLET 2009
LE ‘DNS HELPER SERVICE’ COMCAST
Comcast vient d’annoncer la mise en place d’une version de test d’un nouveau
service destiné à faciliter la vie de l’Internaute en l’aidant à sélectionner le bon
service quand l’adresse réticulaire par lui saisie s’avère être invalide.
Pour faire simple, en cas d’insuccès dans la résolution d’un nom DNS, le service DNS déployé par
Comcast retournera une adresse IP valide pointant un serveur WEB appartenant à Comcast en lieu et
place du code d’erreur NXDOMAIN normalement attendu. Appliqué au cas le plus classique de l’utilisation
du DNS, à savoir la résolution d’un nom via le navigateur WEB, ce mode de fonctionnement conduira à
l’affichage d’une page HTML contrôlée par Comcast en cas d’erreur sur le nom. Cette page contient,
selon Comcast, une liste de sites susceptibles d’intéresser l’usager.
Ce comportement n’est pas nouveau, le célèbre DNS alternatif ‘OpenDNS’ fonctionnant de cette manière
depuis bien longtemps.
Résolution normale
Résolution mensongère
> www.jenexistepas.com
> www.jenexistepas.com
< Server:
80.10.xxx.yyy (FAI Lambda)
< Server:
208.67.222.222 (OpenDNS)
< Address: 80.10.xxx.yyy#53
< Address: 208.67.222.222#53
<
< Non-authoritative answer:
< ** server can't find dddd.ararara.com:
< Name: dddd.ararara.com
<
NXDOMAIN
< Address: 67.215.65.132
Une approche qui, certes pourra faciliter la vie de certains usagers, mais qui risque de mettre en péril le
fonctionnement de toutes les applications. En particulier, les applications, qui s’appuyant sur les
spécifications du DNS, s’attendent à obtenir un code d’erreur lorsqu’une requête porte sur un domaine
inexistant.
Cette situation est dénoncée par Stéphane Borzmeyer dans un billet très justement intitulé ‘Le
déploiement des résolveurs DNS menteurs’. Et de rappeler qu’une situation similaire avait vu le jour
en 2003 avec la décision du plus gros registre américain, Verisign, de répondre positivement aux
requêtes contenant un joker portant sur un domaine inexistant dans la zone ‘.com’. Le requérant obtenait
en réponse, non pas un code d’erreur, mais l’adresse IP d’un service d’aide, SiteFinder, opéré par
Verisign.
Comme le fait remarquer Stéphane Borzmeyer, la grande différence entre le procédé utilisé par Verisign
- à l’époque condamné à l’unanimité - et celui consistant à mentir sur la réponse ici dénoncé, est que ce
dernier procédé ne respecte pas les spécifications du DNS. En outre, l’opérateur d’un tel service manipule
des données relatives à des domaines sur lesquels il n’a potentiellement aucun droit.
Un billet qu’il faudra lire pour bien comprendre la stratégie de Comcast mais aussi de biens d’autres FAI,
et les problèmes que cela soulève.
http://www.comcastvoices.com/2009/07/domain-helper-service-here-to-help-you.html
http://www.bortzmeyer.org/dns-menteur.html
SUR LA COMPLEXITE DE LA MAINTENANCE D’UNE APPLICATION
Microsoft vient tout juste de publier, hors cycle normal, deux correctifs critiques, l'un MS09-034 - corrigeant une vulnérabilité dans Internet Explorer, l'autre - MS09-035 - un
problème dans l'environnement de développement Microsoft Visual Studio. La lecture des
bulletins associés nous apprend que ces deux correctifs sont en fait liés: plusieurs erreurs de
conception dans certains des modèles de développement C++ ATL (Active Library Template)
rendent tous les composants ActiveX s'appuyant sur ces modèles vulnérables.
Parmi ces composants, le contrôle ActiveX Video 'msvidctl.dll' annoncé vulnérable dans le bulletin
MS09-32 diffusé il y a moins de trois semaines.
Dans ce bulletin, Microsoft recommandait de réduire l’exposition d’un système en interdisant l'exécution
du composant en environnement Internet Explorer. Il suffisait pour cela de positionner un drapeau, dit
'KillBit', conçu à cet usage dans la base de registre. Puis, confronté à l'annonce d'une possibilité de courtcircuiter ce mécanisme de protection, et donc de voir un composant banni être réactivé par un tiers,
Microsoft a décidé de prendre 'le taureau par les cornes' et de publier une version immune de cet ActiveX
(MS09-034). En parallèle, les modèles ATL touchés ont été mis à jour (MS09-035). C’est à notre
connaissance la première fois que ces modèles sont officiellement mis à jour en dehors d’une évolution de
l’environnement de développement.
Une excellente initiative qui pose cependant un problème de fond:
Page 5/35
JUILLET 2009
- Que des vulnérabilités soient mises en évidence dans le code d’un composant ActiveX, ou d’une
bibliothèque dynamique, et il suffira d’en diffuser une nouvelle version corrigée pour qu’à la prochaine
exécution de l’application, la faille soit refermée.
- Que ces vulnérabilités touchent une bibliothèque statique, et donc intégrée à l’application lors de la
production (phase d’édition de lien), et il sera nécessaire non seulement de diffuser la nouvelle version de
cette bibliothèque mais aussi une nouvelle version de toutes les applications l’ayant intégrée. Une
opération déjà plus conséquente imposant à chaque éditeur de mettre à jour son environnement de
développement et de régénérer ses applications, du moins celles utilisant les services de la bibliothèque
mise en cause. La phase d’édition de lien est, fort heureusement, encore peu couteuse en ressources.
- Qu’une vulnérabilité touche maintenant un modèle générique de classe – c’est le cas des modèles ATL –
et il sera nécessaire de recompiler l’intégralité des applications s’appuyant sur ces modèles, une opération
conséquente.
Ouvrons une rapide parenthèse pour rappeler que ces modèles génériques – ou templates – permettent
de définir un objet, ses propriétés et les méthodes permettant de le manipuler en faisant abstraction de
ce que sera l’objet réellement utilisé par le développeur. Ainsi, et à titre d’exemple, un modèle peut
permettre de définir un ‘ensemble de choses’ (‘array of’), et les opérations associées (dénombrement,
addition, soustraction, énumération…), sans jamais avoir à préciser ce que sont ces ‘choses’. C’est au
moment de l’utilisation du modèle que le développeur précisera leur nature: nombres entiers, chaînes de
caractères, voire même ensembles d’objets par ailleurs définis… On imagine sans peine l’intérêt pratique
d’une telle abstraction pour accélérer les développements en évitant de réinventer la poudre.
Cette approche suppose toutefois que ces modèles génériques, véritables fondations sur lesquelles
viendront s’appuyer les développements, soient fiables et exempts de tout problème de sécurité. A une
époque où n’importe quel bogue, ou presque, peut se transformer en faille de sécurité exploitable, les
modèles génériques existants sont en passe de devenir de véritables pièges. Ajoutons à cela l’existence
de multiples bibliothèques, et pour une même bibliothèque générique, d’autant de versions qu’il peut
exister de versions de l’environnement de développement et l’on comprendra aisément le casse-tête
auquel est confronté un développeur responsable.
Ainsi, et à titre d’exemple, au moins cinq versions de la librairie ATL (co)existent: ATL 2.0 et 2.1 livrées
avec Visual C++ V5.0, ATL 3.0 livrée avec Visual C++ V6.0, ATL 7.0 et 7.1 introduite avec Visual C++
V6.0 et livrées avec Visual C++ .NET avec, dans certains cas, des changements conséquents allant bien
au-delà d’une simple évolution fonctionnelle.
Le développeur, et l’éditeur avec lui, est alors confronté à un dilemme cornélien lorsqu’il s’agit de
maintenir une application parfaitement fonctionnelle et rendant les services attendus mais développée
avec un environnement commençant à dater et pour lequel les composants fondamentaux – dont les
librairies ATL mais aussi WTL (la version modèle générique de la librairie de classe MFC) – ne sont plus
supportés.
Microsoft a ici la part belle, en n’ayant qu’à diffuser une nouvelle version de la dernière édition de l’ATL
pour se dédouaner de tout problème à venir, et en laissant aux utilisateurs de ses environnements de
développement le choix de ne rien faire ou de rentrer dans un cycle complexe de mise à jour des
applications, et des composants associés.
Mais il ne peut y avoir d’autres solutions sauf à imposer la certification de tous ces composants essentiels
au développement que sont les modèles génériques de développement et les bibliothèques de classe
fondamentales. En encore, comme le dit le célèbre dicton "chassez un bogue et il reviendra au galop".
http://voices.washingtonpost.com/securityfix/2009/07/microsofts_emergency_patch_mes.html?wprss=securityfix
http://blogs.technet.com/bluehat/archive/2009/07/27/black-hat-usa-atl-killbit-bypass.aspx
Page 6/35
JUILLET 2009
ANALYSES ET COMMENTAIRES
ETUDES
ENISA - FONCTIONNALITES DES CARTES D’IDENTITE ELECTRONIQUES
L’ENISA a mis à disposition une version Française d’un très intéressant document de
synthèse sur les cartes d’identité électroniques publié en langue anglaise en janvier dernier.
En toute objectivité, et après lecture des deux versions, notre préférence va à la version
originale, la traduction étant émaillée de fautes d’orthographes et d’erreurs grammaticales.
Quoiqu’il en soit, on ne peut que reconnaître, et apprécier, l’effort engagé par l’ENISA pour mettre à
disposition des membres de la communauté européenne des documents accessibles à toutes – ou presque
- les communautés linguistiques.
L’ENISA nous propose donc ici un dossier de synthèse sur les problématiques de sécurité associées à
l’utilisation de cartes d’identité dites ‘électroniques’, c’est-à-dire pour lesquelles les informations
d’identification du porteur ne sont plus seulement inscrites en surface mais aussi en profondeur, dans une
puce électronique. Pour la rédaction de ce dossier, l’ENISA s’est appuyée sur l’avis de 9 experts œuvrant
principalement dans le domaine de la validation et de la normalisation.
Ce dossier met l’accent sur l’absolue nécessité de coordonner les développements au niveau européen. En
effet, en l’absence d’une stratégie commune, les systèmes de cartes d’identité déployés au sein de l’Union
pourraient bien non seulement ne pas être interopérables mais aussi ne pas offrir un niveau de protection
des données personnelles homogène.
En page 8 du rapport, un tableau de synthèse dresse un état des lieux sur l’utilisation, par les différents
pays européens, d’un système de cartes d’identité, son caractère mandataire et l’existence d’une version
électronique. On y découvre que, sur les 30 pays étudiés, 5 pays, dont la Norvège et le Danemark,
n’utilisent pas de cartes d’identité, que ces cartes ne sont pas le moyen d’identification privilégié pour 5
autres pays parmi lesquels l’Autriche, la Finlande et la Suède, et enfin que seuls 10 pays ont déjà mis en
place une version électronique de leur système de cartes d’identité dont l’Autriche, l’Espagne, la Finlande
ou encore l’Italie. Cette évolution vers un système électronique est par contre planifiée par 13 pays.
Sont ensuite rapidement passées en revue les différentes menaces visant ce nouveau support
d’identification, sans a priori sur la technologie d’accès sous-jacente (avec ou sans contact), et de mettre
en péril non seulement les données privatives qui y sont enregistrées mais aussi son acceptation par le
public. Les mécanismes de protection définis par les spécifications applicables en matière d’identité
électronique, dont les mécanismes BAC (Basic Access Control) de l’ICAO (International Civil Aviation
Organization) ou EAC (Extended Access Control) adopté par l’Union Européenne, sont ensuite listés.
La lecture du chapitre consacré aux caractéristiques propres des cartes d’identité électroniques
Européenne met en évidence la difficulté rencontrée pour spécifier un dispositif a priori simple – prouver
l’identité du porteur – dans un contexte éminemment sensible mais aussi très fortement lié aux
spécificités d’un monde connecté.
Doivent ainsi être prises en compte les sensibilités propres à chaque pays de l’UE en matière de
protection de la vie privée, les contraintes imposées par la nécessaire normalisation des structures de
données et des méthodes d’accès au titre de la reconnaissance de ce moyen par tous les pays de l’UE
mais aussi les exigences associées à la volonté d’étendre l’utilisation de ce moyen d’identification à de
nouveaux usages par le biais d’applications dédiées: authentification électronique en ligne (eID),
signature électronique de documents voir même intégration de la fonction de passeport électronique.
Les tableaux de synthèse proposés dans ce chapitre comparent les interfaces d’accès, les mécanismes de
contrôle d’accès, les fonctions de sécurité et les fonctionnalités embarquées dans les cartes d’identité
électroniques des 11 pays ayant décidé d’adopter cette technologie. Ces tableaux, mais surtout les notes
d’information associées, mettent en relief la diversité des choix techniques (avec ou sans contact, une ou
deux puces, applications complémentaires ou non) mais aussi politiques (contrôle d’accès basic conforme
aux exigences de l’ICAO, ou étendus modifiés par l’Union Européenne, moyen d’identification non
mandataire mais activation des applications pourtant obligatoire…).
Il nous reste hélas beaucoup de chemin à parcourir avant que l’Europe n’arrive à se mettre d’accord sur
un véritable système d’identité européen qui ne soit plus un assemblage de besoins nationaux répondant
à des exigences dictées des organisations tierces elles-mêmes gouvernées par des intérêts qui ne sont
Page 7/35
JUILLET 2009
pas toujours ceux de l’Europe…
Nous nous prenons à imaginer qu’un jour nous n’aurons plus à devoir laisser notre carte d’identité, ou
notre passeport, à l’accueil d’une société avec les abus que cela autorise mais tout simplement à passer
cette carte devant un terminal pour lui délivrer une identité restreinte mais certifiée.
Le sommaire de ce dossier de synthèse est le suivant
1. Introduction
2. Menaces pour la vie privée
2.1. Actifs
2.2. Menaces
3. Lutte contre les menaces pour la vie privée
3.1. Fonctions de protection de la vie privée disponibles sur les cartes d’identité électroniques
3.2. Exemples dans les caractéristiques existantes
3.3. ICP à confidentialité améliorée
4. Aperçu des caractéristiques des cartes d’identité électroniques européennes
4.1. Interfaces et fonctionnalité
4.2. Écriture de données sur une carte
4.3. Fonctions de protection de la vie privée déployées
4.3.1. Contrôle d’accès
4.3.2. Comparaison Authentification/Signature numérique
4.3.3. Cartes d’identité électroniques sans contact
4.3.4. Informations personnelles et identifiants pouvant être liés
5. Conclusions
6. Terminologie et abréviations
7. Références et spécifications des cartes d’identité électroniques
Autriche
Belgique
Estonie
Finlande
Allemagne
Italie
Pays-Bas
Pologne
Portugal
Espagne
Suède
Royaume-Uni
Union européenne
Autres
http://enisa.europa.eu/doc/pdf/deliverables/privacy_features_eid_fr.pdf
http://enisa.europa.eu/doc/pdf/deliverables/enisa_privacy_features_eID.pdf
http://enisa.europa.eu/doc/pdf/publications/privacy_features_of_eid_cards.pdf
- Version Française
- Version Anglaise
- Sur les fonctions de protection
CONFERENCES
RFID09
L’édition 2009 de la conférence RFiD s’est tenue en l’Université Catholique de Louvain –
UCL - célèbre pour son laboratoire de cryptographie. Les communications présentées
sont le reflet de cette très haute technicité, et restent difficilement abordables pour un
public non averti. Quelques présentations méritent toutefois d’être commentées.
PATHCHECKER: AN RFID APPLICATION FOR TRACING PRODUCTS IN SUPPLY-CHAINS
Cette communication nous présente un travail de recherche appliquée mené par une équipe de
cryptographes du laboratoire de l’Ecole Polytechnique Fédérale de Lausanne (EPFL). Cette étude a pour
objet de trouver une solution viable à un problème pratique posé par un industriel, à savoir: garantir
qu’un produit (ou pour être plus rigoureux, l’étiquette électronique qui lui est attachée) est bien passé
par toutes les étapes imposées au long d’une chaîne d’approvisionnement.
Comme l’indiquent les auteurs, il s’agit ici d’une démarche pragmatique et constructive à l’opposé de
celle, destructive, généralement suivie par les équipes d’universitaires: démontrer l’insécurité d’une
solution.
Un exposé qui s’avère passionnant à lire, chaque hypothèse posée étant systématiquement étudiée
sous l’angle de vue de l’attaquant. Un protocole de sécurité est initialement proposé, puis amélioré pas
à pas pour aboutir à un système répondant au cahier des charges et résistant à toutes les attaques
envisagées. Les caractéristiques minimales – capacité de calcul et ressources mémoire – de l’étiquette
électronique peuvent alors être définies avec précision.
http://www.cosic.esat.kuleuven.be/rfidsec09/Papers/rfidsec.pdf
Peter Van Rossum
MIFARE CLASSIC TROUBLES
Peter Van Rossum, chercheur à la Radboud University de Nijmegen, Hollande, nous propose un très
intéressant tour d’horizon des problèmes de sécurité mis en évidence dans le désormais célèbre
système Mifare Classic développé à l’origine par Mikron puis repris par Philips Composants (devenu
Page 8/35
JUILLET 2009
NXP).
Ce système cryptographique est utilisé dans les cartes à mémoire sans contacts du même nom pour
contrôler l’accès à la structure de stockage des données. Les cartes utilisant ce système ont connu un
immense succès dans les secteurs du contrôle d’accès et de la billetterie électronique, la majorité des
sources leurs accordant une part de marché de l’ordre de 70 à 80%.
Fin 2007, la communication de deux chercheurs, Henryk Plötz et Karsten Nohl, à l’occasion du 24C3 Chaos Communication Congress - venait confirmer ce qui n’était jusqu’alors qu’une rumeur persistante
- le système Mifare Classic n’offrait plus la solidité attendue – en mettant en évidence de nombreuses
faiblesses susceptibles d’être exploitées pour copier – cloner dans le jargon - une carte. Depuis, les
attaques se sont perfectionnées, et les derniers travaux prouvent qu’il est désormais possible d’extraire
la clef maître – 48 bits - d’une quelconque carte Mifare Classic à portée ‘radio’ de l’agresseur, et de
cloner celle-ci en moins de 10s.
Parmi toutes les applications utilisant les cartes sans contact Mifare Classic, deux systèmes ont suscité
l’intérêt des chercheurs de par leur utilisation à très grande échelle comme titre de transport: dans la
ville de Londres avec le système ‘Oyster’ et sur tous les réseaux de transport Hollandais avec le
système ‘ov-Chipkaart’. On imagine sans peine l’impact que peut avoir l’annonce de la possibilité de
cloner n’importe quelle carte passant à proximité d’un dispositif conçu à cet effet quand bien même la
fraude sera parfaitement détectable et pourra être circonscrite, dans un premier temps, par la mise en
place d’un système d’inscription en liste noire.
La lecture de la communication de Peter Van Rossum laisse entendre que les cartes Mifare Classic,
conçues en 1994, ont très certainement fait l’objet d’une rétro-analyse à l’échelle industrielle dans les
années 2000 puisque des copies parfaitement fonctionnelles et interopérables étaient mises sur le
marché dès 2004 par une société chinoise, Fudan Microelectronics. On notera que ces cartes ne
reproduisaient cependant pas totalement le fonctionnement de l’original, un traitement spécifique lié à
un contrôle de parité, et posant un problème de sécurité, n’étant pas effectué par les copies. Rien ne
permet de dire si cette altération résulte d’une erreur fortuite dans la rétro-analyse ou d’une correction
volontaire, ce qui sous-entendrait que la vulnérabilité associée avait été découverte à l’époque.
Le tableau suivant, extrait de la communication, présente le calendrier des découvertes et événements
marquants. Dans ce tableau, ‘RU’ désigne l’université de Radboud, ‘Court’ référence Nicolas Courtois,
‘RHUL’ désigne la ‘Royal Holloway University of London’ et ‘TNO’ est une société de conseil ayant
produit une analyse de risque pour le compte des exploitants de cette technologie.
2004
Fudan
Sale of fully functional Mifare Classic clones
2006
Angstrom
(Rumour) Mifare Classic reverse engineered and CRYPTO1 broken
Jun 06
RU
Start of development of Ghost for ISO 14443-A (Mifare) emulation
Nov 07 RU
Functional ISO14443-A (Mifare) emulation
Dec 07
CCC, VA
Presentation: reverse engineered encryption of Mifare Classic: CRYPTO1
Feb 08
RU
Media report: cloning Mifare Ultralight (single-use OV-chipkaart)
Feb 08
TNO
Report on OV-chipkaart: fraud unlikely, advanced equipment needed, 2 year respite
Mar 08
RU
Reverse engineered CRYPTO1 & authentication protocol
Mar 08
RU
Key recovery using intercepted traffic or communication with reader
Apr 08
RHUL
Report on OV-chipkaart: fraud likely, replace cards, design open&modular
Jun 08
NXP
Lawsuit against RU to stop publication
Jul 08
Court
Publication allowed: potential damage due to flaws in chip, not publication
Oct 08
RU
Publication at ESORICS
Nov 08 RU
Card-only key recovery of Mifare Classic
Dec 08 RU
Attack possible using commercially available (cheap) NFC hardware
Un événement important est absent dans ce calendrier, celui de la publication de la toute dernière
attaque développée par Nicolas T. Courtois et présentée pour la première à l’occasion de cette même
conférence.
On passera rapidement sur les justifications techniques des failles développées dans la suite de la
communication pour s’arrêter sur l’analyse des stratégies retenues par les protagonistes:
- l’Université de Radboud ayant choisi de divulguer l’information de manière contrôlée,
- la société NXP ayant pris l’option de limiter les dégâts en déclarant le système ‘Classic’ obsolète,
- les intégrateurs plutôt soucieux de protéger leurs investissements en annonçant un risque limité et
Page 9/35
JUILLET 2009
l’absence de fraude connue.
La lecture de cette communication met en lumière la complexité de la conception d’un système
cryptographique robuste à clef secrète, et soulève la question de possibilité de l’existence même d’un
tel système dans le cas d’un dispositif doté de ressources limitées. Un système parfait ne pouvant être
conçu, il serait souhaitable, et judicieux, d’appliquer à ces technologies cryptographiques, qu’elles aient
été ou non certifiées, une stratégie d’obsolescence programmée. Une date de péremption au-delà de
laquelle la technologie sera considérée comme ne plus être à même de rendre les services attendus.
http://www.cosic.esat.kuleuven.be/rfidsec09/Papers/MifareClassicTroubles.ppt
Nicolas T. Courtois
CLONING MIFARE CLASSIC RAIL AND BUILDING PASSES, ANYWHERE, ANYTIME
Nicolas Courtois, University College of London, est un grand expert de la cryptographie connu pour
avoir mis à mal quelques systèmes dont le système ‘Keeloq’ intégré dans la majorité des dispositifs de
télécommande, et le célèbre système ‘Mifare Classic’ principalement utilisé dans les secteurs des
tickets électroniques.
Il intervient ici pour présenter une nouvelle attaque permettant de cloner une quelconque carte
‘Classic’ en moins de 10s sous réserve d’être à ‘portée’ de celle-ci, et ce en lui soumettant ‘seulement’
300 requêtes astucieusement construites. Il annonce aussi être à même d’obtenir la clef ‘maître’ d’un
composant NXP ‘Hitag2’ en une journée quand il faudrait plus de 3 ans pour obtenir cette clef par une
attaque en force. Une communication à ce sujet aura lieu à l’occasion de la conférence ACS 2009 en
septembre prochain.
Très intéressante, cette présentation n’en reste pas moins très technique. Elle nécessite une bonne
connaissance de la structure de l’algorithme CIPHER 1 utilisé par le système MIFARE et des attaques
déjà connues. La lecture de la présentation ‘Mifare Classic Troubles’ de Peter van Rossum permettra
d’acquérir les fondamentaux requis.
On recommandera toutefois la lecture de
l’introduction – les 20ières pages – lesquelles
proposent une intelligente relecture du célèbre
principe de Kerckhoffs lorsque celui-ci doit
s’appliquer
aux
dispositifs
de
sécurité
embarqués.
Ce principe fondamental, qui dit en substance «
que la sécurité d'un crypto système ne doit
reposer que sur le secret de la clef », trouve son
origine dans l’expression des règles permettant
de garantir, selon Auguste Kerckhoffs (1883), la
confidentialité d’une communication.
Le principe voulant que la sécurité ne soit pas remise en cause quand bien même le système – hors ses
clefs - tomberait dans des mains ennemies est bien souvent considéré comme une justification de
l’impérative nécessité de publier celui-ci. L’auteur s’élève contre cette interprétation en arguant que si
ce principe doit en effet impérativement dicter la structure du système, il n’impose nullement de
publier celui-ci, et que la sécurité n’en sera que meilleure si le système est conservé secret.
Il justifie cette étonnante position en mettant en avant la quasi-impossibilité d’éliminer les attaques
liées à des effets de bord incontrôlables, ou ‘side channel attacks’, en particulier s’agissant
d’implémentations purement matérielles. On pourra lire à ce propos l’intéressante communication de
David Oswald intitulée ‘New Methods for Cost-Effective Side-Channel Attacks on Cryptographic
RFIDs’ laquelle traite justement de ce sujet.
Une prise de position parfaitement défendable qui conduit à devoir considérer que le secret d’un bon
algorithme doit impérativement être préservé s’agissant d’algorithmes à clefs secrètes.
http://www.cosic.esat.kuleuven.be/rfidsec09/Papers/mifare_courtois_rfidsec09.pdf
WHEN COMPROMISED READERS MEET RFID
Gildas Avoine, Cédric Lauradoux et Tania Martin, du Groupe de la Sécurité de l’Information (GSI) de
l’UCL, interviennent pour proposer une solution pratique au problème du risque de compromission des
équipements dits ‘lecteurs’ assurant l’interface avec des cartes électronique, quelles soient dotées ou
non de contacts, en particulier quand ces lecteurs sont mobiles et utilisés en mode déconnecté. Un
thème de recherche qui risque de prendre de l’ampleur avec les récentes annonces de la découverte de
terminaux de paiement ayant été piégés durant les phases de fabrication.
Les auteurs proposent un protocole de sécurité permettant de maintenir le niveau de sécurité attendu
d’un système après que tout ou partie des lecteurs aient été compromis, et ce sans imposer le
changement des cartes à microprocesseurs. Le protocole ici présenté a pour particularité d’assurer un
service d’authentification mutuelle entre carte et lecteur mais aussi d’autoriser une mise à jour
sécurisée de la clef d’authentification propre à chaque carte en s’appuyant sur n’importe quel lecteur
Page 10/35
JUILLET 2009
sous réserve que celui-ci assure encore un service normal.
http://www.cosic.esat.kuleuven.be/rfidsec09/Papers/RFIDSec2009-Avoine-Martin-Lauradoux.pdf
http://www.cosic.esat.kuleuven.be/rfidsec09/Program/index.html
LOGICIELS
INSECURE.ORG – NMAP 5.00
La version 5.00 de l’outil de cartographie réseau ‘nmap’ a été diffusée le 16 juillet. Cette
nouvelle version est annoncée être l’une des plus importantes mises à jour depuis sa
création en intégrant plus de 600 changements significatifs. Et de fait, la version 5.00
s’avère être une belle réussite.
Pour mémoire, l’outil ‘nmap’ permet de cartographier la structure d’un système d’information à partir des
données pouvant être collectées par un équipement connecté au réseau. Contrairement à certains outils,
dits ‘furtifs’, utilisant une approche basée sur l’observation passive des échanges réseaux pour
reconstruire la topologie de l’infrastructure, l’outil ‘nmap’ identifie les équipements actifs, et les services
ouverts sur ceux-ci, par l’analyse des données transmises en réponse à des requêtes judicieusement
choisies.
Cet outil a été conçu en 1997 et diffusé pour la première fois par l’intermédiaire du magazine alternatif
‘Phrack’ sous la forme d’un fichier de 2000 lignes de langage ‘C’. Quelques 12 années plus tard, la
distribution ‘nmap 5.00’ atteint une taille respectable de 14Mo en environnement Windows, cette
distribution intégrant l’environnement Python devenu indispensable pour animer les fonctionnalités
d’automatisation des tâches d’analyse et d’audit.
Cette nouvelle version corrige de nombreux
bogues - certaines instabilités peuvent toutefois
encore être notées en environnement Windows,
améliore notablement les performances en
réduisant notamment le sondage des ports par
défaut aux ports les plus utilisés, intègre une
version enrichie de l’interface graphique ZenMap
(cf. la copie d’écran ci-contre) et propose une
logique d’automatisation des tâches encore plus
performante comprenant 32 nouveaux scripts.
Deux nouveaux utilitaires font leur apparition
avec cette nouvelle distribution:
- L’outil ‘ndiff’ qui permet de comparer les
résultats de deux campagnes de sondage –
fichiers XML - pour mettre en évidence de
possibles modifications dans l’infrastructure.
Cette fonctionnalité est accessible en ligne de
commande mais aussi via l’interface ZenMap
(menu outils/comparer les résultats). Elle reste
cependant réduite à sa plus simple expression en listant les différences de manière linéaire à l’identique
de la fonction UNIX ‘diff’.
- l’outil ‘ncat’ qui, en offrant des fonctionnalités de transfert de données par le réseau similaires à celle
du vénérable utilitaire UNIX ‘ncat’, doit faciliter l’administration à distance et l’exploitation centralisée
des résultats des campagnes d’analyse. Autorisant l’utilisation des protocoles UDP et TCP en intégrant
le support des mécanismes SSL, SOCKS4 et HTTP Connect, ‘ncat’ va, n’en doutons pas, rapidement
remplacer ‘netcat’ dans la boîte à outils des analystes, et des exploitants. Le ‘Ncat Users' Guide’
disponible en ligne détaille les différents scénarios d’utilisation de cet outil. Un guide qu’il faut avoir lu
pour utiliser au mieux un outil que l’on conservera à portée de la main.
Avec cette version 5.00, l’équipe d’Insecure.org confirme que leur développement est loin d’avoir atteint
tout son potentiel et ses limites. On notera simplement que cet outil est loin d’être aussi facile à utiliser
que les exemples – et les copies d’écran montrant de superbes topologies - peuvent le laisser entendre.
http://nmap.org/5/#5changes
http://nmap.org/ncat/guide/index.html
Page 11/35
JUILLET 2009
OARC – DNS REPLY SIZE TEST SERVER
Pour déployer avec succès la version sécurisée du service de nom, dit ‘DNSSEC’, l’infrastructure
environnante devra respecter certains pré-requis dont celui d’autoriser le routage et le transport de
paquets DNS d’une taille supérieure à 512 octets.
La spécification initiale du service de nom fixait par le biais du RFC1025 la taille maximale d’un paquet
DNS transporté sur le protocole UDP à seulement 512 octets - principalement pour des raisons
d’optimisation des performances - une valeur bien en deçà de la capacité de transport d’un paquet UDP
(65535 octets). Cette limitation imposait d’optimiser les réponses des serveurs DNS en excluant toutes
les informations non strictement nécessaires, l’alternative étant de basculer sur le protocole ‘TCP’ bien
plus consommateur de ressources sur les équipements et bien souvent filtré par les mécanismes de
sécurité.
Les réseaux actuels permettant de s’affranchir de nombreuses contraintes d’optimisation, cette limitation
a été levée il y a tout juste 10 ans par le RFC2671 ‘Extension Mechanism for DNS’ aussi désigné par
le sigle ‘EDN0’. Le principe retenu permet d’éviter d’imposer de nouveau une limitation fixe en offrant la
possibilité à chaque serveur DNS d’annoncer la taille maximale d’un message UDP supportée par la
configuration active. Cette taille est codée dans un pseudo-enregistrement DNS, dit ‘OPT’, que tout client
DNS compatible EDN0 prendra soin de demander avant d’engager un échange en mode étendu.
Cette extension prend toute son importance avec l’avènement des extensions de sécurité DNSSEC qui
nécessitent le transfert d’éléments volumineux tels des certificats. On comprendra alors l’intérêt de
vérifier la compatibilité de son infrastructure avant de déployer ces extensions.
La conformité EDN0 d’un quelconque serveur DNS peut être aisément vérifiée en observant la réponse
de ce dernier à une requête transmise par un client annonçant la taille ‘EDN’ qu’il supporte. On peut ainsi
utiliser le client ‘dig’ et l’option ‘+bufsize=’ comme suit:
Requête traditionnelle: aucune information sur la taille
# dig ns.colt-france.com
; <<>> DiG 9.4.3-P2 <<>> ns.colt-france.com
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 40792
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
;; QUESTION SECTION:
;ns.colt-france.com.
;; AUTHORITY SECTION:
colt-france.com. 584
21600 604800 600
IN
IN
A
SOA
icenet.ice-dev.com. admin.ice-dev.com. 2003100916 3600
;; Query time: 35 msec
;; SERVER: 80.10.246.130#53(80.10.246.130)
;; WHEN: Tue Jul 21 16:42:00 2009
;; MSG SIZE rcvd: 93
Requête étendue: la taille est annoncée dans la section OPT
# dig +buzsize=2048 ns.colt-france.com
; <<>> DiG 9.4.3-P2 <<>> +bufsize=2048 ns.colt-france.com
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 53043
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;ns.colt-france.com.
IN
A
;; AUTHORITY SECTION:
colt-france.com. 584
21600 604800 600
;;
;;
;;
;;
IN
SOA
icenet.ice-dev.com. admin.ice-dev.com. 2003100916 3600
Query time: 36 msec
SERVER: 80.10.246.130#53(80.10.246.130)
WHEN: Tue Jul 21 16:47:29 2009
MSG SIZE rcvd: 104
Ce rapide test appliqué à ses propres serveurs DNS ne permettra que de vérifier, tout au plus, leur bonne
configuration. Rien n’indique en effet qu’un paquet DNS de grande taille ne sera pas rejeté par un autre
équipement de l’infrastructure, généralement un routeur ou pare-feu. Seule une requête portant sur un
enregistrement d’une taille supérieure à ces fameux 512 octets permettra de s’assurer de la conformité
de l’ensemble de l’infrastructure. Afin de faciliter la mise en œuvre d’un tel test, l’organisme ‘DNS-OARC’
met à disposition un serveur DNS, dit ‘DNS Reply Size Test Server’, configuré pour délivrer un
Page 12/35
JUILLET 2009
enregistrement de grande taille.
La capacité d’une infrastructure à correctement gérer les extensions EDN0, et par conséquent à migrer
vers DNSSEC, pourra être vérifiée par une simple requête TXT transmise à l’attention du serveur
‘rs.dns-oarc.net’, par exemple au moyen de la commande ‘dig +short rs.dns-oarc.net txt’. Le résultat
sera immédiatement connu par la lecture des dernières lignes de la réponse. Ainsi toute réponse ne
contenant pas la sentence ‘DNS reply size limit is at least 4023 bytes’ devra être interprétée comme
révélatrice d’un problème.
Réponse correcte: l’infrastructure entre le client et le serveur de référence est conforme EDN0
# dig +short rs.dns-oarc.net txt
rst.x4001.rs.dns-oarc.net.
rst.x3985.x4001.rs.dns-oarc.net.
rst.x4023.x3985.x4001.rs.dns-oarc.net.
"84.14.XX.YY sent EDNS buffer size 4096"
"84.14.XX.YY DNS reply size limit is at least 4023 bytes"
Réponse incorrecte: la réponse est filtrée par un pare-feu qui filtre les paquets fragmentés
# dig +short rs.dns-oarc.net txt
rst.x1014.rs.dns-oarc.net.
rst.x1202.x1014.rs.dns-oarc.net.
rst.x1382.x1202.x1014.rs.dns-oarc.net.
"80.12.XX.YY DNS reply size limit is at least 1382 bytes"
"80.12.XX.YY sent EDNS buffer size 4096"
Le site de l’organisation présente une liste des réponses incorrectes les plus couramment rencontrées, et
suggère les pistes à explorer en priorité pour résoudre le problème.
https://www.dns-oarc.net/oarc/services/replysizetest
http://www.bortzmeyer.org/dns-size.html
MAGAZINES
Avec ce nouveau numéro de sa revue, l’ENISA fête ses cinq ans d’existence passés à rendre
l’Europe plus sûre si l’on se réfère à la règle de conduite inscrite sur l’écusson apparaissant en
première pages. Cinq années qui n’ont pas dû être de tout repos pour une institution en charge
d’un domaine pour le moins complexe et éminemment politique.
Si les choses n’ont pas avancées aussi vite que certains l’auraient souhaité, l’ENISA peut cependant
afficher un excellent résultat sur le plan de la communication avec des prises de position appuyées sur
certains sujets sensibles dont les réseaux sociaux ou la résilience des réseaux de communication.
Cette agence communautaire encore jeune a été créée en 2004 pour harmoniser les politiques
européennes en matière de sécurité, pour conseiller les états membres et la commission européenne,
pour évaluer et gérer les risques, pour aider aux efforts de recherche et de normalisation mais aussi pour
informer les citoyens, les entreprises et les administrations.
The Agency's activities consist of giving advice and recommendations, data analysis, as well as supporting awareness
raising and cooperation by the EU bodies and Member States. Building on national and Community efforts, the Agency
is a Centre of Expertise in this field. ENISA uses its expertise to stimulate cooperation between actions from the public
and private sectors.
Son mode de fonctionnement, bien éloigné – au
sens propre comme au figuré – du terrain et des
besoins pratiques des citoyens et des entreprises,
ne semble pas lui avoir encore permis d’atteindre
l’efficacité, et dans une moindre mesure la
notoriété, que l’on serait en droit d’attendre d’une
telle structure quand bien même n’aurait-elle pour
seule mission d’analyser, de promouvoir, de fédérer
ou de redistribuer. Mais peut-être en demandonsnous trop et trop vite, bien mal éduqués par nos
voisins d’Amérique et leur capacité à mettre sur
pied une organisation de gestion de la cyber
sécurité pragmatique et a priori efficace.
On notera à ce propos, la création de l’ANSSI - Agence Nationale de la Sécurité des Systèmes
d'Information – le 9 juillet dernier, laquelle est annoncée permettre à la France de se doter d'une capacité
*
Page 13/35
JUILLET 2009
de défense de ses systèmes d'information. Elle sera l'instrument de la mise en œuvre d'une véritable
politique de défense contre les attaques informatiques. Cette agence se substitue à l’actuelle DCSSI Direction Centrale de la Sécurité des Systèmes d’Information – en renforçant les compétences, les
effectifs et les moyens.
http://www.anssi.gouv.fr/
Dans ce nouveau numéro de la revue de l’ENISA, quatre thèmes sont abordés.
INFORMATION SHARING EXCHANGES
Le thème de la protection des infrastructures et du partage l’information – Infrastructure Protection
& Information Sharing – est traité par le biais d’un premier article édité par deux experts de l’ENISA.
Constatant l’importance de l’échange d’informations entre les acteurs des secteurs privés et publics
pour mieux faire face aux menaces, l’ENISA souhaite développer le principe de partenariats dédiés dits
‘NSIE’ - Network Security Information Exchanges – destinés à faciliter l’échange d’informations et
d’idées dans un domaine concurrentiel, celui des ISP, où la coopération n’est pas toujours facile.
L’ENISA annonce la prochaine mise à disposition d’un guide destiné à faciliter la mise en place, et
l’exploitation, d’une structure d’échange. L’objectif de l’ENISA est d’accélérer le déploiement de telles
structures au niveau national de chacun des pays membres de l’Union Européenne. Les auteurs
détaillent rapidement les éléments qui devront être pris en compte lors de la création de ces
structures: une taille raisonnable de tout au plus 30 personnes, des rencontres régulières, une
participation active du gouvernement, une participation libre de droit d’entrée, une double présidence
partagée entre un représentant du gouvernement et un représentant de l’industrie, la reconnaissance
du caractère sensible des informations échangées, et la mise en place d’un mode de fonctionnement
favorisant l’échange au simple transfert d’information.
Les derniers points nous apparaissent être primordiaux dans le contexte concurrentiel auquel se livrent
tous les acteurs du marché. La réussite d’une structure d’échange passera par la mise en place de
règles de fonctionnement et la présence d’un garant de leur bonne application, le représentant de l’Etat
en l’occurrence. Il s’agira d’établir un subtil équilibre permettant à chacun de s’exprimer sans jamais se
sentir lésé en donnant trop au regard de se que l’on pense recevoir. Un exercice déjà difficile par
nature dont on imagine ce qu’il pourra en être s’agissant d’échanger des informations sur la sécurité de
ses actifs, et sur les méthodologies applicables pour renforcer leur protection.
Les membres d’un NSIE ne pourront à eux seuls produire les informations destinées à être partagées,
et redistribuées: retour d’expérience, bonnes pratiques, analyses de menaces, plans de contingence,
de reprise, de crises… Une telle structure sera donc implicitement adossée aux cellules de gestion de la
sécurité et du risque mises en place par les organisations qui y seront représentées.
La réflexion de l’ENISA porte ici sur la sécurité des infrastructures critiques conformément à la
stratégie sur laquelle elle a été missionnée, et donc prioritairement sur les réseaux de communications
et leurs opérateurs.
Trois autres articles viennent compléter la réflexion amorcée par les experts de l’ENISA:
Le troisième article concerne le projet FISHA - a Framework for Information Sharing and Alerting –
mené en collaboration par NASK (le premier fournisseur d’accès en Pologne), le CERT Hongrois et
l’Institut pour la Sécurité de l’Internet de l’université de Gelselkirchen. L’idée de ce projet de 2 ans
engagé en février dernier est de poser les bases d’un système de partage et d’échange d’information
destiné aux petites et moyennes entreprises ainsi qu’aux particuliers. Le Royaume Unis a résolu cette
problématique avec beaucoup d’élégance il y a déjà quelques années en animant un réseau
d’information, d’échange et d’alerte constitué d’une multitude de nœuds – dits WARP ou Warning,
Advice and Reporting Point – gérés par des bénévoles œuvrant pour une communauté d’intérêt: un
quartier, un métier, une activité…
Le second présente l’organisation mise en œuvre par le Royaume Unis pour favoriser l’émergence de
projets de recherche innovants. Trois structures étatiques – le TSB (Technology Strategy Board), le
CPNI (Centre for the Protection of National Infrastructure) et l’EPSRC (Engineering and Physical
Sciences Research Council) – ont libéré un budget de recherche de £6M, le NSIP (Network Security
Innovation Platform) étant chargé de son allocation et de sa gestion.
Le dernier article nous propose un retour d’expérience concernant la création par l’Afrique du Sud de
son centre de traitement des incidents ou CSIRT. Approuvé en avril dernier, le budget de
fonctionnement pour les premiers 18 mois du CSIRT-ZA couvre majoritairement les dépenses liées à
la stratégie d’accompagnement choisie. En effet, le CSIR (Council for Scientific and Industrial
Research) initiateur de la démarche sera accompagné par un acteur ayant déjà mené cette opération
avec succès, à savoir l’Autorité de Régulation de Communication Finlandaise – FICORA – qui gère le
CERT-FI. Un très intéressant exemple de coopération internationale qui permettra au CSIRT-ZA de
bénéficier non seulement de l’expérience acquise par le CERT-FI et d’être rapidement efficace mais
aussi d’être introduit par le biais de ce parrainage dans le réseau de confiance établie par les CSIRT.
Page 14/35
JUILLET 2009
STRATEGIE AND BUSINESS RISK
En décembre 2008, la Finlande a révisé sa stratégie nationale de sécurisation des informations,
stratégie adoptée pour la première fois en 2003. Mari Herranen, conseillère auprès du ministre
finlandais du transport et des communications présente les trois volets de cette stratégie: faire en
sorte que les citoyens disposent des connaissances minimales requises pour se protéger, améliorer la
confiance des citoyens dans la sécurité des services par une bonne gestion et la mise en place de
processus fiables, œuvrer pour que la Finlande soit le leader mondial en matière de sécurité de
l’information d’ici 2015. Un vaste programme que l’on pourra consulter sur le site du groupe de travail
‘Ubiquitous Information Society’ (le terme ‘Ubiquitous’ – Ubiquité en Français – désigne ici la
capacité, pour le citoyen, de pouvoir accéder à l’information en tout temps et en tous lieux). Un
programme qui indique vouloir « transform Finland into an internationally recognized, competitive,
competence-based service society with a human touch ».
Le second article de ce volet consacré à la stratégie et à la gestion des risques métiers, est intitulé
‘The Convergence of Risk’. Il présente les résultats d’un projet mené par l’ISF – Information
Security Forum – une organisation à but non lucratif – dans le domaine de la gestion du risque. Il en
ressort que les organisations auraient tout intérêt à gérer le risque comme un problème transverse
plutôt que de compartimenter celui-ci en l’étudiant localement. Aucun document d’accompagnement
permettant de mieux appréhender la logique développée n’est, semble-t-il, disponible.
L’article suivant nous propose une synthèse des idées échangées sur ‘la prévention des risques
internes’ à l’occasion d’un séminaire consacré à ce sujet qui s’est déroulé du 20 au 25 juillet dernier au
château de Dagstuhl. Les documents produits à cette occasion sont disponibles en ligne.
- Countering Insider Threats Abstracts Collection
- Countering Insider Threats Summary
- Collaborative Fraud Detection in Outsourcing Scenarios: Solutions for Privacy and Confidentiality
- Fraud Detection from a Business Perspective: Future Directions and Challenges
Le dernier article de ce thème est proposé par le président de la société de conseil Belge LSEC, qui
intervient pour rappeler que les petites entreprises sont tout autant, si ne n’est plus, concernées par la
sécurité que les moyennes et grandes entreprises. Leur problème est qu’elles ne disposent
généralement pas de ressources dédiées à gestion du système d’information, et encore moins à la
sécurité de celui-ci. C’est bien souvent le directeur de la société qui assure, en plus de toutes ses
missions, la fonction de DSI et de RSSI sans toujours être bien formé pour cela. En conséquence, le
Business Crime Reduction Centre anglais, les sociétés de conseil KTN Cybersecurity et LSEC ont
œuvré pour la réalisation d’une liste de recommandations permettant à ces dirigeants de mesurer leur
performance en matière de sécurité et d’établir les actions devant être prioritairement menées pour
améliorer la situation. Cette liste est accompagnée de brochures de sensibilisation annoncées être
disponibles en Français, Anglais et Hollandais. A ce jour, cependant, ni la liste de recommandations, ni
les versions française et anglaise des brochures ne sont disponibles, la version hollandaise datant
d’avril dernier. Nous avons posé la question de la disponibilité de ces documents à l’auteur de l’article
qui nous a répondu que ceux-ci sont en cours de relecture, de nombreuses modifications ayant été
effectuées dernièrement.
PRIVACY
Ce volet consacré à la protection de l’intimité commence par un intéressant article proposé par JaapHenk Hoepman, consultant scientifique chez TNO, société d’analyse Hollandaise. Celui-ci introduit le
concept de ‘droit révocable à l’intimité’, ou ‘Revocable Privacy’, lequel permettrait de concilier
l’inconciliable, à savoir la sécurité et l’intimité.
Un système implémentant ce concept garantirait les droits
fondamentaux des usagers mais ces droits pourraient être
révoqués à tout instant en cas de violation de tout ou partie des
règles régissant le fonctionnement du système.
Une forme d’immunité pouvant être levée à la demande de l’autorité compétente, encore faut-il bien
définir les conditions régissant cette exception; peut-être est-ce là le plus difficile !
L’objectif de l’article est de montrer qu’il ne s’agit pas ici d’une idée utopique mais bien d’une approche
réaliste et fondée au regard des technologies existantes. Rappelons à ce propos que depuis plus de 15
ans des travaux de recherche sont menés dans le domaine de la protection de l’identité et de la nontraçabilité des transactions, un thème cher à ce remarquable visionnaire qu’est David Chaum. L’auteur
de l’article ne manque pas d’ailleurs de rendre à César ce qui revient à César en citant les travaux de
ce chercheur quelque peu oublié. Et de fait, les technologies, et les supports associés, sont disponibles
depuis quelques années déjà qui permettraient d’authentifier un citoyen, de signer un document, ou
encore d’effectuer un paiement, sans rien dévoiler de son identité réelle.
Mettre en phase deux exigences aussi incompatibles engendrera un surcoût qui reste actuellement bien
difficile à justifier, la mesure du coût financier d’une atteinte à l’intimité étant bien plus complexe que
Page 15/35
JUILLET 2009
celle d’un manquement directe à la sécurité d’un système ou d’une infrastructure. Il est probable que
seule une prise de conscience collective et globale permettra de faire avancer les choses en mettant les
Etats face à leurs responsabilités. L’opinion publique est hélas bien plus sensible à l’annonce d’incidents
de transport certes graves mais de faible probabilité d’occurrence qu’aux annonces réitérés du vol
d’enregistrements concernant l’intimité de plusieurs milliers quand ce n’est pas plusieurs millions
d’individus. Il est vrai que nous vivons une époque où tout un chacun expose les moindres détails de
sa vie personnelle sur certains sites accessibles de tous…
Une approche alternative, plus simple de mise en œuvre, consisterait à ne dévoiler que le strict
minimum des informations requises pour le bon déroulement d’une opération.
La lecture du document publié par
l’ENISA comparant les fonctionnalités
des cartes d’identités électroniques
Européennes montre la prise en compte
de cette approche par le biais de la déclaration d’identifiants spécifiques et/ou d’une identité restreinte.
Proposé par Sergio Loureiro et Matthias Jung, experts indépendants, l’article ‘Privacy in Cloud
Computing’ traite d’un sujet d’actualité, celui du ‘Cloud Computing’; une nouvelle forme de
décentralisation des traitements, et des données, qui n’est pas sans conséquence sur la sécurité de
l’information. Les auteurs remarquent que si les problématiques liées à la sécurisation des données
dans de tels environnements ont fait l’objet de toutes les attentions conduisant même à la création de
la Cloud Security Alliance, ou CSA, le sujet de la protection de la vie privée n’a qu’à peine été
abordé par les grands acteurs de ce domaine.
Le World Privacy Forum a fort heureusement publié en février dernier un dossier très complet qu'il
conviendra d’étudier. Ce dossier comprend un rapport d’analyse de 26 pages intitulé ‘Privacy in the
Clouds: Risks to Privacy and Confidentiality from Cloud Computing’ ainsi qu’une liste de onze
recommandations fondamentales sous le titre ‘Cloud Computing Tips for Consumers, Business,
and Government’.
SECURITY OF WIRELESS NETWORKS
Le premier article intitulé ‘Improving the Security of Wireless Communications’ récapitule les
principes de sécurisation applicables aux équipements sans fils et dispositifs mobiles utilisés par les
particuliers. L’auteur s’appuie sur les préconisations du rapport d’étude PTS-ER-2009:16 publié en
avril dernier par les PTT Suédois et accessible en langue anglaise.
Ce rapport s’accompagne de trois vidéos de sensibilisation de moins de 2mn – hélas uniquement
proposées en langue Suédoise – accessibles sur le site de l’opérateur mais aussi sur You-Tube:
- Använd bluetooth på ett säkert sätt ou L’utilisation de Bluetooth de manière sécurisée,
- Kommunicera trådlöst på ett säkert sätt ou La communication sans fil de façon sécuritaire,
- Säkra ditt trådlösa nätverk ou Sécurisez votre réseau sans fil.
Une excellente approche de la pédagogie et de la communication a ici été appliquée qui permet de
toucher les jeunes, et les moins jeunes, toutes ces générations qui ne sont pas toujours au fait des
problématiques de sécurité posées par les dernières technologies, ou qui en mésestiment les risques.
Le support You-Tube est ainsi devenu un vecteur de sensibilisation incontournable.
Le second article proposé dans ce thème commence par une prise de position qui rejoint celle que nous
venons d’exposer, prise de position qui cible explicitement les adultes, comprendre toutes les
générations n’ayant pas passé leur adolescence avec un téléphone cellulaire en main:
A considerable number of adults do not know about the Bluetooth device on their mobile phones. Many users are
not aware that enabling Bluetooth opens up a security gap. This contrasts dramatically with the experience of visiting
Luxembourgish schools where children and young adolescents know exactly how to use Bluetooth to connect to and
‘hack’into other children’s mobile phones.
Et de fait, cette analyse ne s’applique pas uniquement au Luxembourg mais bien à tous les pays
Européens. Nous faisons tous régulièrement l’expérience de la capacité de nos enfants à s’approprier
un nouveau téléphone en moins de temps qu’il n’en faut pour lire la notice. Et quand, en parents
concerné, nous nous permettons une réflexion sur le risque qu’il peut y avoir à autoriser les connexions
Bluetooth en permanence, notre enfant nous remet très rapidement en place par un ‘c’est évident’.
Il est intéressant de constater, comme cela transparait dans la prise de position des auteurs, que cette
sensibilisation résulte, non pas tant de l’application de bonnes pratiques transmises par les parents ou
les éducateurs, mais bien d’un apprentissage sur le terrain au fil des manipulations effectuées entre
copains pour jouer, et la plupart du temps dans aucune volonté de nuisance. C’est en se brulant que
l’on apprend à se méfier du feu… Dès lors, et s’agissant des jeunes générations, toute tentative
d’éducation ‘classique’ – énumération de préceptes et de bonnes pratiques - sera vouée à l’échec
quand une approche ludique basée sur l’expérimentation directe donnera de bien meilleurs résultats.
Page 16/35
JUILLET 2009
Cette approche ne permettra toutefois pas de résoudre le problème de la prise de conscience de
l’illégalité de certaines actions qui, portant sur des biens par nature intangibles, peuvent apparaître à
beaucoup comme ne portant pas à conséquence. Et lorsque cette prise de conscience émerge,
l’absence de règles bien établies, et partagées, permet de rejeter la faute sur la victime. Les auteurs de
l’article citent ainsi la réflexion bien souvent entendue: « c’est de sa faute s’il laisse son Bluetooth
activé », sous-entendu « il n’a qu’à s’en prendre à lui-même s’il a été attaqué ». Une tentative de rejet
de sa responsabilité hélas classique et utilisée dans bien d’autres situations.
Il est possible d’accélérer la prise de conscience d’un individu du risque posé par une technologie en
mettant celui-ci dans une situation inconfortable dont il se souviendra longtemps. C’est ainsi qu’au
Luxembourg, le Service National de la Jeunesse et le CASES (Cyberworld Awareness Security
Enhancement Structure) ont mis en place une expérience grandeur réelle à l’occasion d’une grande
manifestation: deux grands écrans affichaient en permanence le nom des dispositifs Bluetooth acquis
par le biais d’un logiciel d’analyse maison. Quelques 4000 équipements ont ainsi été identifiés, leurs
propriétaires ayant certainement, toute honte bue, retenu la leçon.
http://www.enisa.europa.eu/doc/pdf/publications/enisa_quarterly_06_09.pdf
Page 17/35
JUILLET 2009
METHODOLOGIES ET STANDARDS
METHODES
SEI – CERT RESILIENCY MANAGEMENT MODEL
Le Software Engineering Institute, ou SEI, s’intéresse de longue date aux techniques de
conception et de gestion de systèmes d’information résilients, un domaine devenu l’objet de
toutes les attentions ces dernières années.
Le terme de système résilient désigne ici un système susceptible de maintenir un niveau de service
acceptable en présence de fautes ou de dysfonctionnements de tout ordre. Une approche issue des
exigences applicables aux systèmes critiques industriels, ou militaires, exigences à l’origine de la
conception si particulière du réseau Internet.
Etre à même de continuer à transporter (réseau), ou à traiter une information (système), quand pourtant
certaines fonctions sont atteintes est l’un des défis qu’il va nous falloir relever dans les années à venir,
que la perte de fonctionnalité soit le fait d’une action délibérée (attaque) ou d’un problème local.
L’ENISA, et avec elle, l’Europe, s’intéresse tout particulièrement à la mise en œuvre des technologies
susceptibles de renforcer l’immunité des réseaux de communications, dont IPV6, DNSSec ou encore
MPLS, en considérant que ces réseaux sont devenus les indispensables supports de notre économie. Que
ces derniers cessent d’assurer un service a minima, et la stabilité de notre société sera grandement mise
en péril. On pourra relire avec intérêt les résultats de l’analyse menée par l’ENISA (‘Resilience Features
Of Ipv6, Dnssec And Mpls And Deployment Scenarios’) sur l’impact des trois technologies précitées
ou encore le numéro de la revue de l’ENISA (EQR 1Q08) entièrement consacré à ce sujet.
Pour mémoire, ce numéro propose un remarquable article intitulé ‘Self Cleansing and Intrusion
Tolerance’ posant les bases de ce qui pourrait être la prochaine grande révolution en matière de
systèmes de traitement de l’information, les systèmes tolérants aux intrusions, une forme de résilience.
Une approche, novatrice dans le domaine des systèmes commerciaux, basée sur l’idée que les processus
d’un système de traitement puissent être très régulièrement réinitialisés à partir d’une image de confiance
sans que le consommateur du service n’en soit impacté. Encore faut-il que la technologie sous-jacente
soit exempte de tout défaut, ce qui est loin d’être le cas avec les technologies de virtualisation actuelles.
En mars 2008, une équipe du SEI, spécialisée dans l’étude et la conception de systèmes d’information
‘survivables’, a donc publié une première version d’une approche méthodologique destinée à faciliter la
mise en place, et la gestion, de systèmes résilients. S’appuyant sur les principes d’une démarche
d’amélioration continue – un modèle de maturité à 5 niveaux d’aptitude – cette approche dénommée REF
(‘Resiliency Engineering Framework’) identifie les 21 domaines clefs sur lesquels il y aura lieu de se
pencher pour amener une organisation à améliorer ses aptitudes à intégrer les principes de la résilience
au quotidien.
Ces 21 domaines, classés par ordre alphabétique, sont les suivants:
- ADM Asset Definition and Management
- AM
Access Management
- COMM Communications
- COMP Compliance
- EC
Environmental Control
- EF
Enterprise Focus
- FRM Financial Resource Management
- HRM Human Resources Management
- ID
Identity Management
- IMC Incident Management and Control
- KIM Knowledge and Information Management
- MA
Measurement and Analysis
- MON Monitoring
- OTA Organizational Training and Awareness
- PM
People Management
- RISK Risk Management
- RRD Resiliency Requirements Development
Page 18/35
JUILLET 2009
- RRM Resiliency Requirements Management
- SC
Service Continuity
- TM
Technology Management
- VAR Vulnerability Analysis and Resolution
L’annexe A du document initial publié en 2008 inventorie les objectifs, et les pratiques, applicables à
chacun de ces domaines, soit plus de 420 pages sur les 456 pages que compte le document ce qui rendait
celui-ci difficilement lisible.
Le SEI semble avoir récemment opté pour une réorganisation de ce référentiel en publiant ces
informations sous la forme d’autant de documents indépendants – dits ‘Process Area Documents – qu’il y
a de domaines à traiter et en améliorant le référencement des objectifs – Specific Goals ou SG – et des
pratiques associées – Specific Pratice ou SP.
Les trois premiers documents indépendants, qui correspondent aux trois premiers domaines (ADM, AM et
COMM), ont été mis à disposition fin juin:
Process area documents
Asset Definition & Management
Gérer les actifs au long de leur cycle de vie afin d’assurer une 30/06/09
(ADM)
26 pages
productivité durable et conforme aux besoins de service.
ADM:SG1 Establish Organizational
ADM:SG1.SP1 Inventory Assets
Assets
ADM:SG1.SP2 Establish a Common Understanding
ADM:SG1.SP3 Establish Ownership and Custodianship
ADM:SG2 Establish Relationship
ADM:SG2.SP1 Associate Assets with Services
ADM:SG2.SP2 Analyze Asset-Service Dependencies
Between Assets & Services
ADM:SG3 Manage Assets
ADM:SG3.SP1 Identify Change Criteria
ADM:SG3.SP2 Maintain Changes to Assets and Inventory
Access Management
(AM)
AM:SG1
Manage and Control
Access
Veiller à ce que les accès accordés soient conformes aux 30/06/09
exigences en matière de métier et de résilience.
25 pages
AM:SG1.SP1 Enable Access
AM:SG1.SP2 Manage Changes to Access Privileges
AM:SG1.SP3 Periodically Review and Maintain Access Privileges
AM:SG1.SP4 Correct Inconsistencies
Communications
(COMM)
COMM:SG1 Prepare for Resiliency
Communications
Gérer les communications internes et externes dans l’optique 30/06/09
33 pages
de garantir la résilience des activités et processus.
COMM:SG1.SP1 Identify Relevant Stakeholders
COMM:SG1.SP2 Identify Communications Requirements
COMM:SG1.SP3 Establish Communications Guidelines & Standards
COMM:SG2 Prepare for Communications COMM:SG2.SP1 Establish a Resiliency Communications Plan
Management
COMM:SG2.SP2 Establish a Resiliency Communications Program
COMM:SG2.SP3 Identify and Assign Plan Personnel
COMM:SG3 Deliver Resiliency
COMM:SG3.SP1 Identify Communications Methods and Channels
Communications
COMM:SG3.SP2 Establish & Maintain Communications Infrastructure
COMM:SG4 Improve Communications
COMM:SG4.SP1 Assess Communications Effectiveness
COMM:SG4.SP2 Improve Communications
Supplementary Documents
Generic Goals and Practices
Glossary of Terms
Objectifs et pratiques devant être appliqués
Définition des termes utilisés dans le modèle
30/06/09
30/06/09
http://www.cert.org/resiliency/rmm.html
http://www.sei.cmu.edu/cgi-bin/form_processor.cgi
http://www.sei.cmu.edu/community/resiliency-engineering/REFramework.zip
- Matériels
- Modèle REF
RECOMMANDATIONS
CERTA – NOTE SUR LES SYSTEMES ET LOGICIELS OBSOLETES
Le CERTA - Centre d'Expertise Gouvernemental de Réponse et de Traitement des Attaques
informatiques - a publié une mise à jour de la note d’information CERTA-2005-INF-003.
Cette note de 4 pages, initialement publiée en septembre 2005, établie une liste des systèmes et logiciels
devant être considérés comme obsolètes car ne faisant plus l’objet d’aucune mise à jour de la part de
l’éditeur.
Un document de synthèse dont il y a lieu de connaître l’existence, et sur lequel on pourra s’appuyer pour
définir une politique de protection ad’hoc des systèmes d’exploitation annoncés obsolètes, et pourtant
indispensables au bon fonctionnement d’une infrastructure. Ce document est cependant loin d’être
Page 19/35
JUILLET 2009
exhaustif, et l’on regrettera que ne soient pas pris en compte certains logiciels, ou applications, pourtant
tout aussi largement déployés que PHP ou Microsoft Office.
Le sommaire de cette note d’information est le suivant:
1 Introduction
2 Les systèmes d’exploitation obsolètes
2.1 Les systèmes d’exploitation propriétaires obsolètes
2.2 Les systèmes d’exploitation libres obsolètes
2.2.1 Les systèmes GNU/Linux
2.2.2 Les systèmes BSD
2.2.3 Les systèmes d’exploitation Apple
3 Les produits obsolètes
3.1 Les gestionnaires de base de données
3.2 Les serveurs WEB
3.3 Logiciels obsolètes
3.3.1 PHP
3.3.2 Microsoft Office
4 Documentation
http://www.certa.ssi.gouv.fr/site/CERTA-2005-INF-003.pdf
Page 20/35
JUILLET 2009
STANDARDS
RFC 5598 - EMAIL ARCHITECTURE
En 1982, le RFC-822 ‘Standard for the Format of ARPA Internet Text Messages’, édité par un
certain David H. Crocker de l’université du Delaware, formalisait les bases de ce qui allait devenir le
système de messagerie électronique le plus utilisé au monde, détrônant au passage le pourtant
remarquable système X400. Ces spécifications ont régulièrement fait l’objet d’aménagements et
d’évolutions permettant de prendre en charge les nouveaux besoins: gestion des alphabets étendus,
pièces jointes, fonctions de sécurité…
Quelques 27 ans plus tard, la complexité de l’architecture de messagerie, et la multiplicité des concepts
associés, conduisent ce même David H. Crocker à éditer un document d’information, le RFC 5598
‘Email Architecture’, dont l’objet est de fixer les concepts et de définir une terminologie commune et
partagée par l’ensemble des acteurs, utilisateurs finaux, fournisseurs de service mais aussi exploitants,
administrateurs, concepteurs et architectes.
L’auteur le fait remarquer à juste titre, les modifications de ce système de messagerie ne l’ont pas
révolutionné mais simplement fait évoluer, au fil de l’eau - et des besoins rajouterons-nous - sous la
forme d’aménagements décrits dans autant de RFC rédigés sans grand soucis de cohérence en l’absence
d’une trame commune ou d’un fil conducteur. Il devenait donc urgent de poser sur papier, en un
document unique, les spécifications fonctionnelles de l’architecture existante et d’offrir à chaque acteur
concerné une vision d’ensemble cohérente et logique du système.
C’est désormais chose faite avec ce document, qui étant toujours édité au format ‘texte’, contient des
figures dignes de figurer en bonne place dans les galeries dédiées à l’ASCII-ART à coté d’Einstein ou de
Marylin Monroe.
Page 21/35
JUILLET 2009
Le sommaire du RFC 5598, 54 pages, est le suivant
1. Introduction
1.1. History
1.2. The Role of This Architecture
1.3. Document Conventions
2. Responsible Actor Roles
2.1. User Actors
2.2. Message Handling Service (MHS) Actors
2.3. Administrative Actors
3. Identities
3.1. Mailbox
3.2. Scope of Email Address Use
3.3. Domain Names
3.4. Message Identifier
4. Services and Standards
4.1. Message Data
4.2. User-Level Services
4.3. MHS-Level Services
4.4. Transition Modes
4.5. Implementation and Operation
5. Mediators
5.1. Alias
5.2. ReSender
5.3. Mailing Lists
5.4. Gateways
5.5. Boundary Filter
6. Considerations
6.1. Security Considerations
6.2. Internationalization
7. References
Page 22/35
JUILLET 2009
7.1. Normative References
7.2. Informative References
ftp://ftp.isi.edu/in-notes/rfc5598.txt
Page 23/35
JUILLET 2009
TABLEAUX DE SYNTHESE
CONFERENCES
NANOG 46
La 46ième édition des rencontres du North American Network Operator’s Group, le NANOG,
a eu lieu du 14 au 17 juin dernier. Les textes des communications sont accessibles sur le
site de ce groupe.
ARIN Update
BGP Scalability Considerations
Communications Sector and Information Technology Sector
Data Center Cooling New Technologies
Data Center Top-of-Rack Switch Redundancy Models
DNSSEC Goes Mainstream: Deployment Incentives, Experience, Questions
Hijacking Mitigation: Something is Better Than Nothing
Internet Superbugs and The Art of War
IPv4 NAT A Mechanism to Transition to IPv6
IPv4 NAT Dual-Stack lite:a scalable CGN story
IPv4 NAT IPv6 Transition and Address Family Translation
IPv4 NAT ISC and CGN
IPv4 NAT Possible NAT444 Broadband Transition Strategy
IPv6 CND
IPv6 Content Provider and Enterprise Challenges
IPv6 Deployment on a Broadband Access Network
IPv6 deployment: Netflix and Limelight
IPv6 IPv6 Broadband and Cable
IPv6 IPv6 in the Enterprise Sector
IPv6 Pay me Now or Pay me Later
ISP Security
LISP Updates
Pseudowires from 1999 to 2009, 10 Years of Evolution and Deployments
Virtually Eliminating Router Bugs
Wireless: The Headache You Can't See
M.Kosters
D.McPherson
M.Sachs
A.Hughes
D.Roisman
S.Woolf
T.Daly
P.Vixie
L.Zhang
A.Durand
D.Ward
S.Woolf
C.Chase
T.Coffeen
D.Temkin
A.Douitsis
D.Temkin
J.Brzozowski
A.Davidson
R.Bush
R.Bush
V.Fuller
L.Martini
E.Keller
V.Khanna
Présentations Express
BGP Advisory Message
Cyclops Open Eye to Your Network
DNSSEC Recursive Resolver
DNSSEC, EDNS and TCP
ICANN DNS Root Scaling Study
IPv6 and Recursive Nameservers
MPLS Fast ReRoute as Redundancy Indicator
My Life with the DLV
Rapid Convergence in IP Networks
Study of the Current Internet Architecture and Future Implications
Up and to the Right, The Recent History of the Global Usenet Feed
T.Scholl
R.Oliveira
T.Daly
D.Wessels
G.Kowack
I.Gashinsky
P.Templin
M.Sinatra
T.Scholl
G.Burdett
E.Henigin
Tutoriels
Deploy a Production IPv6 Network in 30 Minutes or less (or it's free)
Effective BGP Load Balancing Using "The Metric System"
Introduction to DHCPv6 and DHCPv6 for DOCSIS
Introduction to DOCSIS 3.0
Network Capacity RFP: What, Why, How-To
VoIP Peering
R.Steenbergen
D.Roisman
J.Brzozowski
B.Pularikkal
M.Hannigan
J.Peterson
http://www.nanog.org/meetings/nanog46/agenda.php
RFIDSEC09
Page 24/35
JUILLET 2009
La cinquième édition de la conférence RFIDSec consacrée à la sécurité des étiquettes
électroniques sans fils a eu lieu du 30 juin au 2 juillet en la cité de Louvains. Cette
édition a été organisée par le COSIC (COmputer Security and Industrial Cryptography),
un département de la célèbre université catholique de Leuven.
A Flyweight RFID Authentication Protocol
A Privacy Impact Assement for RFID - A Proposal
Cloning MiFare Classic Rail and Building Passes, Anywhere, Anytime
Coupon Recalculation for the Schnorr and GPS Identification Scheme
Efficient RFID Security and Privacy with Anonymizers
Hyperelliptic curve processor for RFID tags
Implications of Data Remanence on the Use of RAM for True RNG on RFID Tags
Mifare Classic Troubles
MIFARE Plus and Privacy Preserving Technologies
Modeling Privacy for Off-line RFID Systems
New Methods for Cost-Effective Side-Channel Attacks on Cryptographic RFIDs
Pathchecker: an RFID Application for Tracing Products in Suply-Chains
Practical Experiences with NFC Security on mobile Phones
Semi-Destructive Privacy in RFID Systems
Sensor Security: A Kaleidoscopic View
The Ff-Family of Protocols for RFID-Privacy and Authentication
Un-Trusted-HB: Security Vulnerabilities of Trusted-HB
Using HB Family of Protocols for Privacy-Preserving Authentication of RFID Tags
Weaknesses in Two Recent Lightweight RFID Authentication Protocols
When Compromised Readers Meet RFID
Jorge Munilla
Sarah Spiekermann
Nicolas T. Courtois
Christoph Nagl
C. Wachsmann
Junfeng Fan
Jonathan Voris
Peter van Rossum
Marc Vauclair
Flavio D. Garcia
David Oswald
Serge Vaudenais & all
G. Van Damme
Paolo D'Arco
Rene Struik
Erik-Oliver Blass
Adi Shamir
Jonathan Voris
Pedro Peris-Lopez
Gildas Avoine & all
http://www.cosic.esat.kuleuven.be/rfidsec09/Program/index.html
GUIDES
CERTA – NOTES ET AVIS
Le CERTA – le Centre d'Expertise Gouvernemental de Réponse et de Traitement des
Attaques informatiques Français – a mis à jour sa note d’information sur les Systèmes et
les Logiciels Obsolètes.
Les recommandations (REC) et notes d’information (INF) du CERTA, publiées ou mises à jour il y a moins
de trois ans, sont listées dans le tableau suivant, triées par leur date de mise à jour.
RECOMMANDATIONS
2005-REC-003
Les systèmes et les logiciels obsolètes
2002-REC-002
Sécurité des réseaux sans fil (Wi-Fi)
2005-REC-002
Attaque ciblée par cheval de Troie
2005-REC-001
La bonne utilisation des protocoles SSL/TLS
NOTES D’INFORMATION
2000-INF-002
Mesures de prévention relatives à la messagerie
2008-INF-005
Gestion des journaux d'événements
2008-INF-004
E-mail backscatting, pollution par des rapports de non-livraison de courriels
2008-INF-003
Les attaques de type «cross-site request forgery»
2008-INF-002
Du bon usage du DNS
2008-INF-001
iFRAME, fonctionnement et protection
2006-INF-004
Migration IPv6 : enjeux de sécurité
2002-INF-002
Les bons réflexes en cas d'intrusion sur un système d'information
2007-INF-003
Sécurité des réseaux sans fil Bluetooth
2007-INF-002
Du bon usage de PHP
2007-INF-001
Conseils pour la gestion des noms de domaine
2006-INF-006
Risques associés aux clés USB
2006-INF-009
Outils d'indexation et de recherche
2006-INF-002
Terminologie d'usage au CERTA
2006-INF-001
Filtrage et pare-feux
2005-INF-005
Bonnes pratiques concernant l'hébergement mutualisé
2001-INF-003
Tunnels et pare-feux : une cohabitation difficile
2005-INF-004
Limiter l'impact du SPAM
2005-INF-002
Les mémentos du CERTA
2005-INF-001
Les mots de passe
26/06/09 M
21/11/08
24/06/05
01/03/05
27/03/09
31/12/08
19/12/08
17/12/08
21/07/08
17/07/08
09/01/08
07/01/08
01/08/07
20/03/07
02/02/07
15/01/09
21/11/06
21/04/06
10/01/06
19/12/05
05/10/05
03/10/05
24/06/05
24/06/05
Page 25/35
JUILLET 2009
2005-INF-003
2004-INF-001
Les systèmes et logiciels obsolètes
Sécurité des applications Web et vulnérabilité de type "injection de données"
13/06/05
03/01/05
http://www.certa.ssi.gouv.fr/
NIST – ETAT DES GUIDES DE LA SERIE SPECIALE 800
Le NIST publie, pour relecture, la première révision du guide SP800-65
‘Recommendations for Integrating Information Security into the Capital Planning and
Investment Control Process (CPIC)’.
SP800-124
SP800-123
SP800-122
SP800-121
SP800-120
SP800-118
SP800-117
SP800-116
SP800-115
SP800-114
SP800-113
SP800-111
SP800-110
SP800-108
SP800-107
SP800-106
SP800-104
SP800-103
SP800-102
SP800-101
SP800-100
SP800-98
SP800-97
SP800-96
SP800-95
SP800-94
SP800-92
SP800-90
SP800-89
SP800-88
SP800-87r1
SP800-86
SP800-85A1
SP800-85A
SP800-85B
SP800-84
SP800-83
SP800-82
SP800-81
SP800-80
SP800-79r1
SP800-78r1
SP800-77
SP800-76r1
SP800-73r2
SP800-72
SP800-70r1
SP800-70
SP800-69
SP800-68r1
SP800-67
SP800-66r1
SP800-65r1
SP800-65
SP800-64r2
Guidelines on Cell Phone and PDA Security
Guide to General Server Security
Guide to Protecting the Confidentiality of Personally Identifiable Information
Guide to Bluetooth Security
Recommendation for EAP Methods Used in Wireless Network Access Authentication
Guide to Enterprise Password Management
Guide to Adopting and Using the Security Content Automation Protocol
Recommendation for the Use of PIV Credentials in Physical Access Control Systems
Technical Guide to Information Security Testing
User’s Guide to Securing External Devices for Telework and Remote Access
Guide to SSL VPNs
Guide to Storage Encryption Technologies for End User Devices
Information System Security Reference Data Model
Recommendation for Key Derivation Using Pseudorandom Functions
Recommendation for Using Approved Hash Algorithms
Randomized Hashing Digital Signatures
A Scheme for PIV Visual Card Topography
An Ontology of Identity Credentials, Part I: Background and Formulation
Recommendation for Digital Signature Timeliness
Guidelines on Cell Phone Forensics
Information Security Handbook: A Guide for Managers
Guidance for Securing Radio Frequency Identification (RFID) Systems
Guide to IEEE 802.11i: Robust Security Networks
PIV Card / Reader Interoperability Guidelines
Guide to Secure Web Services
Guide to Intrusion Detection and Prevention (IDP) Systems
Guide to Computer Security Log Management
Random Number Generation Using Deterministic Random Bit Generators
Recommendation for Obtaining Assurances for Digital Signature Applications
Guidelines for Media Sanitization
Codes for the Identification of Federal and Federally-Assisted Organizations
Computer, Network Data Analysis: Forensic Techniques to Incident Response
PIV Card Application and Middleware Interface Test Guidelines
PIV Card Application and Middleware Interface Test Guidelines
PIV Middleware and PIV Card Application Conformance Test Guidelines
Guide to Single-Organization IT Exercises
Guide to Malware Incident Prevention and Handling
Guide to Industrial Control Systems (ICS) Security
Secure Domain Name System (DNS) Deployment Guide
Guide for Developing Performance Metrics for Information Security
Guidelines for Certification & Accreditation of PIV Card Issuing Organizations
Cryptographic Algorithms and Key Sizes for Personal Identity Verification
Guide to Ipsec VPNs
Biometric Data Specification for Personal Identity Verification
Interfaces to Personal Identity Verification
Guidelines on PDA Forensics
NCP for IT Products - Guidelines for Checklist Users and Developers
The NIST Security Configuration Checklists Program
Guidance for Securing Microsoft Windows XP Home Edition
Guidance for Securing Microsoft Windows XP Systems for IT Professionals
Recommendation for the Triple Data Encryption Algorithm Block Cipher
An Introductory Resource Guide for Implementing the HIPAA Security Rule
Integrating IT Security into the Capital Planning and Investment Control Process
Integrating IT Security into the Capital Planning and Investment Control Process
Security Considerations in the Information System Development Life Cycle
[F]
[F]
[R]
[F]
[R]
[R]
[R]
[F]
[F]
[F]
[F]
[R]
[R]
[F]
[R]
[R]
[F]
[R]
[R]
[F]
[F]
[F]
[F]
[R]
[F]
[F]
[F]
[F]
[F]
[F]
[F]
[F]
[R]
[F]
[F]
[F]
[F]
[R]
[F]
[R]
[F]
[F]
[F]
[F]
[F]
[F]
[F]
[F]
[F]
[F]
[F]
[F]
[R]
[F]
[F]
11/08
07/08
01/09
09/08
12/08
04/09
05/09
11/08
09/08
11/07
07/08
11/07
09/07
11/08
07/08
07/08
06/07
09/06
11/08
05/07
03/07
04/07
02/07
09/06
08/07
02/07
09/06
03/07
11/06
09/06
04/08
08/06
02/09
04/06
07/06
09/06
11/05
09/08
05/06
05/06
06/08
08/07
12/05
01/07
09/08
11/04
09/08
05/05
08/06
07/08
06/08
10/08
07/09
01/05
10/08
M
Page 26/35
JUILLET 2009
SP800-63r1
SP800-61r1
SP800-60r1
SP800-59
SP800-58
SP800-57p1
SP800-57p2
SP800-57p3
SP800-56A
SP800-56B
SP800-55r1
SP800-54
SP800-53r3
SP800-53r2
SP800-53A
SP800-52
SP800-51
SP800-50
SP800-49
SP800-48r1
SP800-47
SP800-46r1
SP800-46
SP800-45V2
SP800-44V2
SP800-43
SP800-42
SP800-41r1
SP800-41
SP800-40-2
SP800-39
SP800-38D
SP800-38C
SP800-38B
SP800-38A
SP800-37r1
SP800-37
SP800-36
SP800-35
SP800-34
SP800-33
SP800-32
SP800-31
SP800-30
SP800-29
SP800-28v2
SP800-27A
SP800-26r1
SP800-26
SP800-25
SP800-24
SP800-23
SP800-22r1
SP800-21
SP800-16r1
SP800-12
Electronic Authentication Guidelines
Computer Security Incident Handling Guide
Guide for Mapping Types of Information & IS to Security Categories
Guideline for Identifying an Information System as a National Security System
Security Considerations for Voice Over IP Systems
Recommendation for Key Management, 1: General Guideline
Recommendation for Key Management, 2: Best Practices
Recommendation for Key Management, 3: Application-Specific Key Management
Pair-Wise Key Establishment Schemes Using Discrete Logarithm Cryptography
Pair-Wise Key Establishment Using Integer Factorization Cryptography
Security Metrics Guide for Information Technology Systems
Border Gateway Protocol Security
Recommended Security Controls for Federal Information Systems
Recommended Security Controls for Federal Information Systems
Guide for Assessing the Security Controls in Federal Information Systems
Guidelines on the Selection and Use of Transport Layer Security
Use of the Common Vulnerabilities and Exposures Vulnerability Naming Scheme
Building an Information Technology Security Awareness & Training Program
Federal S/MIME V3 Client Profile
Guide to Securing Legacy IEEE 802.11 Wireless Networks
Security Guide for Interconnecting Information Technology Systems
Guide to Enterprise Telework and Remote Access Security
Security for Telecommuting and Broadband Communications
Guide On Electronic Mail Security
Guidelines on Securing Public Web Servers
System Administration Guidance for Windows00
Guidelines on Network Security testing
Guidelines on Firewalls and Firewall Policy
Guidelines on Firewalls and Firewall Policy
Creating a Patch and Vulnerability Management Program
Managing Risk from Information Systems: An Organizational Perspective
Recommendation for Block Cipher Modes of Operation – GCM
Recommendation for Block Cipher Modes of Operation – CCM
Recommendation for Block Cipher Modes of Operation – RMAC
Recommendation for Block Cipher Modes of Operation – Method and Techniques
Guidelines for the Security C&A of Federal Information Technology Systems
Guidelines for the Security C&A of Federal Information Technology Systems
Guide to IT Security Services
Guide to Selecting IT Security Products
Contingency Planning Guide for Information Technology Systems
Underlying Technical Models for Information Technology Security
Introduction to Public Key Technology and the Federal PKI Infrastructure
Intrusion Detection Systems
http://csrc.nist.gov/publications/nistpubs/800-30/sp800-30.pdf
Comparison of Security Reqs for Cryptographic Modules in FIPS 140-1 & 140-2
Guidelines on Active Content and Mobile Code
Engineering Principles for Information Technology Security – Rev A
Guide for Inform. Security Program Assessments & System Reporting Form
Security Self-Assessment Guide for Information Technology Systems
Federal Agency Use of PK Technology for Digital Signatures and Authentication
Finding Holes in Your PBX Before Someone Else Does
Guidelines to Federal Organizations on Security Assurance
Statistical Test Suite for Random and Pseudorandom Number Generators
Guideline for Implementing Cryptography in the Federal Government
Information Security Training Requirements: A Role & Performance Based Model
An Introduction to Computer Security: The NIST Handbook
[F] Finalisé
[R]
[F]
[F]
[F]
[F]
[F]
[F]
[D]
[F]
[R]
[F]
[F]
[R]
[F]
[F]
[F]
[F]
[F]
[F]
[F]
[F]
[F]
[F]
[F]
[F]
[F]
[F]
[R]
[F]
[F]
[R]
[F]
[F]
[F]
[F]
[R]
[F]
[F]
[F]
[F]
[F]
[F]
[F]
[F]
[F]
[F]
[F]
[R]
[F]
[F]
[F]
[F]
[F]
[F]
[R]
[F]
12/08
03/08
08/08
08/03
03/05
03/07
08/05
10/08
03/07
12/08
08/08
07/07
06/09
12/07
06/08
06/05
09/02
03/03
11/02
08/08
08/02
06/09
08/02
02/07
09/07
11/02
10/03
07/08
01/02
11/05
04/08
11/07
05/04
05/05
12/01
08/08
04/04
10/03
10/03
06/02
12/01
02/01
11/01
01/04
10/01
03/08
06/04
08/05
11/01
10/00
08/00
08/00
08/08
12/05
03/09
10/95
[R] Relecture
http://csrc.nist.gov/publications/PubsSPs.html
http://csrc.nist.gov/publications/drafts/800-53/800-53-rev3-FPD-clean.pdf
http://csrc.nist.gov/publications/nistpubs/800-46-rev1/sp800-46r1.pdf
- Catalogue des publications
MAGAZINES
Page 27/35
JUILLET 2009
Le second numéro de l’année 2009 de la revue de l’ENISA a été publié début Juillet. Avec une
ligne éditoriale légèrement remaniée, ce numéro aborde quatre thématiques:
- la protection des infrastructures et le partage de l’information,
- la stratégie et les risques métiers,
- la protection de la vie privée, et
- la sécurité des réseaux sans fils.
Le sommaire de ce numéro de 24 pages est reproduit ci-dessous:
A Letter from the Executive Director
A Word from the Editor
A Word from the Experts
Infrastructure Protection and Information Sharing
Information Sharing Exchanges
FISHA: a Framework for Information Sharing and Alerting
Information Infrastructure Protection
Establishing a National CSIRT in South Africa
Strategy and Business Risks
The Finnish National NIS Strategy and Information Risk Management and Process Reliability
The Convergence of Risk
Countering Insider Threa
Flemish SMEs Leave their IT Security in the Hands of Badly Informed Managers
Privacy
Revocable Privacy
Privacy in Cloud Computing
Security of Wireless Networks
Improving the Security of Wireless Communications
Can you be Traced by your Bluetooth Device?
Food for Though
Rule-breakers - the Ones to Watch?
http://www.enisa.europa.eu/doc/pdf/publications/enisa_quarterly_06_09.pdf
INTERNET
LES DECISIONS DE L’OMPI
L’Organisation Mondiale de la Propriété Intellectuelle – OMPI ou WIPO – est chargée
de l’arbitrage et de la résolution des litiges relatifs aux noms domaines. Parmi tous
les litiges jugés, en voici quelques uns concernant l’usage abusif de marques célèbres
en France. On notera par ailleurs l’apparition de termes relatifs à des produits liés à l’épidémie de grippe.
DTV2009-0005
D2009-0565
D2009-0493
D2009-0501
D2009-0617
D2009-0574
D2009-0537
DBZ2009-0001
D2009-0558
D2009-0649
D2009-0618
D2009-0657
D2009-0578
D2009-0543
DIR2009-0001
D2009-0729
D2009-0640
D2009-0579
D2009-0660
D2009-0682
afflelou.tv
collinsdictionary.com
lacoste-shopping.com
larocheinternational.com
wwwtelia.com
accorhotells.com, sofitels.com
credit-du-nord.pro, creditdunord.pro
creditmutuel.bz
blackberrymovies.com
orangetogo.com
dhl-post.com
tamiflu-generic.com
swineflutamiflu.com, tamifluswineflu.com
google4people.net
facebook.ir
lancomeblog.com, lorealblog.com
canadatamiflu.com, canadiang.com
dhlpost.com
baleciaga.com
sanofizentiva.com
Alain Afflelou Franchiseur
HarperCollins Publisher Ltd.
Lacoste Alligator S.A
F. Hoffmann-La Roche AG
Aktiebolaget TeliaSonera AB
Accor SoLuxury HMC
Crédit du Nord
Crédit Mutuel
Research In Motion Limited
Orange
DHL Operation
Google, Inc
Facebook, Inc
Lancôme Parfums & l’Oréal SA
DHL Operations
Balanciaga
Sanofi-aventis
Transfert
Transfert
Transfert
Transfert
Transfert
Transfert
Transfert
Transfert
Transfert
Transfert
Transfert
Transfert
Transfert
Transfert
Transfert
Transfert
Transfert
Transfert
Transfert
Destruction
22/06
22/06
22/06
22/06
22/06
23/06
23/06
25/06
30/06
30/06
02/07
03/07
09/07
09/07
13/07
14/07
14/07
17/07
18/07
19/07
Page 28/35
JUILLET 2009
http://www.wipo.int/rss/index.xml?col=dnddocs
http://www.wipo.int/freepublications/fr/arbitration/779/wipo_pub_779.pdf
- Dernières décisions
- Procédure de règlement des litiges
STANDARDS
IETF – LES RFC TRAITANT DIRECTEMENT DE LA SECURITE
Thème
GSS-API
IPV6
RADIUS
SNMP
SNMP
Num Date Etat
Titre
5588
5570
5607
5591
5592
Generic Security Service Application Program Interface) Extension for Storing Delegated Credentials
Common Architecture Label IPv6 Security Option (CALIPSO)
Remote Authentication Dial-In User Service (RADIUS) Authorization for NAS Management
Transport Security Model for the Simple Network Management Protocol (SNMP)
Secure Shell Transport Model for the Simple Network Management Protocol (SNMP)
07/09
07/09
07/09
06/09
06/09
Pst
Inf
Pst
Pst
Pst
IETF – LES RFC LIES A LA SECURITE
Thème
MAIL
Num Date Etat
Titre
5598
Internet Mail Architecture
07/09 Inf
IETF – LES NOUVEAUX DRAFTS TRAITANT DE LA SECURITE
Thème
Nom du Draft
Date Titre
CRYPTO
IPSEC
IPV6
MPLS
SIDR
draft-ietf-saag-crypto-key-table-00
draft-ietf-ipsecme-aes-ctr-ikev2-00
draft-baker-ipv6-nd-session-hijack-00
draft-manral-mpls-tp-oam-security-tlv-00
draft-huston-sidr-rpki-algs-00
10/07
27/07
28/07
30/06
29/07
Database of Long-Lived Cryptographic Keys
Using Advanced Encryption Standard Counter Mode with IKEv2
Session Hijack in Neighbor Discovery
MPLS-TP General Authentication TLV for G-ACH
A Profile for Algorithms and Key Sizes for use in the Resource PKI
IETF – LES MISES A JOUR DE DRAFTS TRAITANT DE LA SECURITE
Thème
AES
ARIA
BMWG
CSI
DHCP
DIME
DNS
DSSC
EAP
GEOPRIV
GRE
HTTP
IKE
IPSEC
IPV6
KEYPROV
MANET
MPLS
MSEC
P2PSIP
RADIUS
Nom du Draft
draft-housley-aes-key-wrap-with-pad-04
draft-nsri-aria-01
draft-ietf-bmwg-ipsec-term-12
draft-ietf-bmwg-ipsec-meth-05
draft-ietf-csi-proxy-send-01
draft-haddad-csi-symbiotic-sendproxy-01
draft-jiang-dhc-secure-dhcpv6-02
draft-neumann-dime-webauth-01
draft-wijngaards-dnsext-trust-history-03
draft-gudmundsson-dnsext-setting-ends0-…-01
draft-ietf-ltans-dssc-10
draft-ietf-emu-chbind-03
draft-latze-emu-eap-tpm-01
draft-ietf-geopriv-policy-21
draft-yegani-gre-key-extension-04
draft-ietf-httpbis-p7-auth-07
draft-nir-ike-qcd-05
draft-detienne-ikev2-recovery-03
draft-padmakumar-ikev2-redirect-and-…-01
draft-ietf-ipsecme-roadmap-03
draft-patil-mext-mip6issueswithipsec-01
draft-jml-ipsec-ikev2-security-context-01
draft-nir-ipsecme-childless-01
draft-daniel-6lowpan-security-analysis-03
draft-haddad-mext-mobisoc-01
draft-korhonen-mext-mip6-altsec-01
draft-ietf-keyprov-dskpp-08
draft-ietf-keyprov-symmetrickeyformat-05
draft-herberg-manet-packetbb-sec-02
draft-ietf-mpls-mpls-and-gmpls-security-…-06
draft-seokung-msec-mikey-seed-03
draft-matuszewski-p2psip-security-….-05
draft-lior-radius-prepaid-extensions-16
draft-zorn-radius-pkmv1-05
draft-ietf-radext-radsec-05
Date Titre
27/07
28/07
28/07
28/07
13/07
29/07
13/07
13/07
30/06
28/07
29/07
10/07
27/07
13/07
28/07
13/07
11/07
29/07
27/07
14/07
13/07
10/07
13/07
13/07
13/07
13/07
28/07
13/07
27/07
13/07
29/07
10/07
13/07
28/07
13/07
AES Key Wrap with Padding Algorithm
A Description of the ARIA Encryption Algorithm
Terminology for Benchmarking IPsec Devices
Methodology for Benchmarking IPsec Devices
Secure Proxy ND Support for SEND
Secure Neighbor Discovery Proxying 'Symbiotic' Relationship
Secure DHCPv6 Using CGAs
Diameter Application for Authentication and Authorization
DNSSEC Trust Anchor History Service
DNSSEC OK buffer minimum size requirement and error handling
Data Structure for the Security Suitability of Crypto. Algorithms
Channel Binding Support for EAP Methods
EAP Method for TCG Trusted Platform Modules
Expressing Privacy Preferences for Location Information
GRE Key Extension for Mobile IPv4
HTTP/1.1, part 7: Authentication
A Quick Crash Detection Method for IKE
Safe IKE Recovery
IKEv2 Redirect and Authentication Offload
IP Security and Internet Key Exchange (IKE) Document Roadmap
Problems with IPsec as the security protocol for Mobile IPv6
Security Context Addendum to IPsec
A Childless Initiation of the IKE SA
IPv6 over Low Power WPAN Security Analysis
Mobile IPv6 Route Optimization Mode Secure Social Dimension
TLS Mobile IPv6 Security Framework for Mobile Node
Dynamic Symmetric Key Provisioning Protocol (DSKPP)
Symmetric Key Package Content Type
MANET Cryptographical Signature TLV Definition
Security Framework for MPLS and GMPLS Networks
New values to use the SEED Cipher Algorithm in MIKEY
P2PSIP Security Overview and Risk Analysis
Prepaid Extensions to Remote Authentication Dial-In User Service
RADIUS Attributes for IEEE 802.16 PKMv1 Protocol Support
TLS encryption for RADIUS over TCP (RadSec)
Page 29/35
JUILLET 2009
RTP
SAVI
SCEP
SIDR
SIP
SMIME
SPEER
SRTP
SSH
TCP
TLS
ULE
V6OPS
draft-ietf-radext-dynamic-discovery-01
draft-ietf-avt-srtp-not-mandatory-03
draft-perkins-avt-srtp-vbr-audio-01
draft-ietf-savi-threat-scope-01
draft-nourse-scep-19
draft-ietf-sidr-cp-06
draft-ietf-sidr-arch-08
draft-ietf-sidr-rpsl-sig-01
draft-ietf-sip-certs-08
draft-liao-smimeheaderprotect-05
draft-ietf-speermint-voipthreats-01
draft-mcgrew-srtp-ekt-05
draft-igoe-secsh-aes-gcm-03
draft-lebovitz-ietf-tcpm-tcp-ao-crypto-02
draft-ietf-tls-extractor-06
draft-noisternig-ipdvb-sec-ext-01
draft-ietf-v6ops-cpe-simple-security-07
13/07
13/07
13/07
27/07
13/07
13/07
29/07
11/07
13/07
30/06
13/07
12/07
20/07
27/07
12/07
13/07
27/07
NAI-based Dynamic Peer Discovery for RADIUS over TLS
Why RTP Does Not Mandate a Single Security Mechanism
Guidelines for the use of Variable Bit Rate Audio with Secure RTP
SAVI Threat Scope
Cisco Systems' Simple Certificate Enrollment Protocol
Certificate Policy (CP) for the Resource PKI (RPKI)
An Infrastructure to Support Secure Internet Routing
Securing RPSL Objects with RPKI Signatures
Certificate Management Service for SIP
Header Protection for S/MIME
SPEERMINT Security Threats and Suggested Countermeasures
Encrypted Key Transport for Secure RTP
AES Galois Counter Mode for theSSH Layer Protocol
Cryptographic Algorithms, Use, & Implementation Requirments
Keying Material Exporters for Transport Layer Security (TLS)
Security ext for Unidirectional Lightweight Encapsulation Protocol
Recommended Simple Security Capabilities in Customer Premises
Page 30/35

Veille Technologique Sécurité

Transcription

Documents pareils

AUX ETATS-UNIS Social Security 401k, 403b EN FRANCE Régime

HEBERGEMENT WEB LUXEMBOURG

Tableau comparatif

TÜV SÜD Acertigo Compliance Services - Certificate

Security Center - Certification technique Omnicast

Tutoriel HijackThis

CBSA CONSENT STATEMENT DÉCLARATION DE

HP EliteBook 8560p - Core i5 2540M / 2.6 GHz

information bulletin