standards - cert devoteam

Veille Technologique Sécurité 

Rapport Mensuel N°146 

SEPTEMBRE 2010 

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: 

Stuxnet, quelques faits 

Teredo La cryptographie quantique 

L’AFNIC et le DNSSEC SmartGrid: les préconisations du NIST 

Les prescriptions de la DISA sur les supports de stockage amovibles 

Les marques et les produits cités dans ce rapport sont la propriété des dépositaires respectifs. 

CONNECTING BUSINESS & T ECHNOLOGY 

CERT-DEVOTEAM Pour tous renseignements: 

1, rue GALVANI Offre de veille http://www.cert-devoteam.com/ 

91300 Massy Palaiseau Informations vts-info@cert-devoteam.com 

©CERT-DEVOTEAM - Tous droits reserves

Au sommaire de ce rapport… 


ACTUALITES SECURITE 

CRYPTOGRAPHIE QUANTIQUE 2 

UN RETOUR SUR STUXNET 3 

COMMENT LIRE UN BREVET EN 60 SECONDES 5 

AFNIC – LES ENJEUX DU DNSSEC 6 

ANALYSES ET COMMENTAIRES 

MAGAZINES 

HNS - (IN)SECURE MAG N°27 8 

Payment card security: Risk and control assessments 8 

Learning from Bruteforcers 8 

MÉTHODOLOGIES ET STANDARDS 

MÉTHODES 

NIST - IR7628 'SMART GRID CYBER SECURITY STRATEGY AND REQUIREMENTS' 10 

NIST - SP800-135 ' RECOMMENDATION FOR EXISTING APPLICATION-SPECIFIC KEY DERIVATION FUNCTIONS’ 14 

RECOMMANDATIONS 

ANSSI – CATALOGUE DES PRODUITS QUALIFIES – MISE A JOUR 15 

APPLE – GUIDE DE SECURISATION MACOS X 10.6 16 

DISA – SUPPORTS DE STOCKAGE AMOVIBLES 17 

DISA – STIG MEDICAL DEVICES 20 

STANDARDS 

RFC5991 - TEREDO SECURITY UPDATE 21 

TABLEAUX DE SYNTHESE 

CONFERENCES 

BRUCON 2010 23 

IETF – 78TH MEETING 23 

GUIDES 

CERTA – NOTES ET AVIS 24 

NIST – ETAT DES GUIDES DE LA SERIE SPECIALE 800 25 

DISA – GUIDES ET CHECK LISTES DE SECURISATION 27 

NSA – GUIDES DE SECURITE 28 

MAGAZINES 

HNS - (IN)SECURE MAG N°27 31 

INTERNET 

LES DECISIONS DE L’OMPI 31 

STANDARDS 

IETF – LES RFC TRAITANT DIRECTEMENT DE LA SECURITE 32 

IETF – LES RFC LIES A LA SECURITE 32 

IETF – LES NOUVEAUX DRAFTS TRAITANT DE LA SECURITE 32 

IETF – LES MISES A JOUR DE DRAFTS TRAITANT DE LA SECURITE 33 

Veille Technologique Sécurité N°146 Page i 

© CERT-DEVOTEAM - Tous droits réservés Diffusion restreinte aux clients abonnés au service de veille technologique

Le mot du rédacteur 


Une excellente nouvelle en ce début d’automne plutôt marqué par de nombreux 

problèmes de sécurité: les zones gérées par l’AFNIC (‘.fr’, ‘.re’, ‘.yt’ et ‘.tf’) ont été 

signées mi-septembre. C’est une première et indispensable étape au déploiement de 

DNSSEC à plus large échelle, qui permet de « poser les premières pierres de notre 

infrastructure de signature » pour reprendre l’expression de l’AFNIC. Les paramètres 

de signatures et les certificats sont accessibles sur son site. 

http://www.afnic.fr/afnic/web/certificats 

Une fin de saison qui aurait pu voir s’effondrer l’Internet à la suite d’une expérience 

menée en grandeur réelle sur le protocole de routage BGP par le RIPE-NCC, le 

centre de coordination des réseaux européens, et l’université de Duke. Cela n’a pas 

été le cas, l’annonce BGP à l’origine du dysfonctionnement d’une grande partie des 

routeurs d’interconnexion CISCO ayant été rapidement retirée. 

https://labs.ripe.net/Members/erik/ripe-ncc-and-duke-university-bgp-experiment/ 

On pourra lire à ce sujet, l’excellent article de Stéphane Borztmeyer qui assène 

quelques vérités de plus en plus difficiles à entendre dans un monde essentiellement 

piloté par l’économie, l’individualisme et la performance à outrance. La tendance est 

grande d’oublier le rôle des individus - « l'Internet résiste aux soubresauts non pas 

parce que BGP est particulièrement bien conçu mais parce qu'il y a des gens 

compétents et dévoués derrière les routeurs » - ou encore de la mondialisation – « la 

vulnérabilité fondamentale de l'Internet est qu'il connecte des organisations 

différentes et souvent ennemies ». Nous nous opposerons seulement à l’affirmation 

que « L'Internet n'est pas et ne doit pas être une infrastructure vitale ». Non pas sur 

la prescription, « ne doit pas être », une évidence bien souvent oubliée, mais sur le 

constat du présent, « n’est pas ». Internet EST une INFRASTRUCTURE de transport 

VITALE depuis quelques temps maintenant, et il nous faut composer avec, ou bien 

accepter le retour du MINITEL et de l’infrastructure associée. 

http://www.bortzmeyer.org/bgp-attribut-99.html 

Nos lecteurs ayant connu cette époque, et celle des premiers processeurs ‘grand 

public’, pourront aller admirer une simulation visuelle du fonctionnement du 

processeur 6505, lequel équipait l’Apple ][ puis le Commodore 64. Navigateur Firefox, 

ou assimilé, et machine performante absolument indispensables… 

http://visual6502.org/JSSim/index.html 

Enfin, pour terminer et en complément à notre article ‘OpenBTS sur Droid’ publié 

dans notre dernier rapport de veille, nous conseillons la lecture du support de la 

présentation ‘GSM security: fact and fiction’ proposée par Fabian van den Broek à 

l’occasion de l’édition 2010 de la conférence BRUCON. 

http://www.feedsite.org/security4all/BruCON_2010_-_GSM_Security_Fact_and_Figures.pdf 

BERTRAND VELLE 

Veille Technologique Sécurité N°146 Page 1/38 


CRYPTOGRAPHIE QUANTIQUE 


ACTUALITES SECURITE 

En août 2009, à l’occasion de la conférence ‘Hacking At Random 2009’, cinq chercheurs de 

l’université Norvégienne des sciences et technologies – NTNU – et du centre pour les technologies 

quantiques de Singapour publiaient un papier intitulé ‘How we eavesdropped 100% of a quantum 

key’ qui aurait dû retenir l’attention de tous les médias (Rapport N°134 – Septembre 2009). Il aura fallu 

attendre 6 mois et la publication d’un second papier, ‘How You Can Build An Eavesdropper For A 

Quantum Cryptosystem’, durant le très médiatique CCC - ‘Chaos Communication Congress’ – pour que 

la sensationnelle découverte de ces chercheurs fasse enfin réagir l’ensemble de la communauté (N°138 – 

Janvier 2010). Nous concluions à l’époque sur l’importance du choix du contexte de la communication en 

précisant que le choix d’une conférence de faible notoriété pour une première annonce a dû rebuter plus 

d’un journaliste couvrant l’événement. Autre lieu, autre intitulé, autre audience et autre sensibilisation, 

voilà peut-être les facteurs ayant contribué à changer la donne… 

Trois jours seulement auront été nécessaires pour que leur dernier papier ‘Hacking commercial 

quantum cryptography systems by tailored bright illumination’ publié par la revue ‘Nature 

Photonics’ soit repris par toute la presse. Celui-ci ne détaille pourtant que la simple mise en application 

de la découverte fondamentale dévoilée, et validée sur un système expérimental, il y a tout juste un an: il 

est possible par un remarquable tour de passe-passe, d’acquérir la clef transmise par un système de 

cryptographique quantique sans que ceci ne soit détecté de part et d’autre. 

Un résultat a priori en totale contradiction avec la théorie, résultat qui trouve son origine dans la difficulté 

rencontrée à produire un capteur physique – ici un détecteur de photon – parfait, c.-à-d. à même 

d’assurer une traduction fidèle, reproductible mais aussi inaltérable de l’information reçue. Ces chercheurs 

ont ainsi mis en évidence un phénomène de saturation des capteurs utilisant des diodes à avalanche 

contrôlée, phénomène permettant d’aveugler partiellement le capteur, de lui faire perdre sa capacité de 

mesure et de lui faire prendre des vessies pour des lanternes. Nos lecteurs désireux de rentrer dans le 

détail de l’attaque pourront se reporter à l’article publié dans notre rapport N°134. Tous les systèmes de 

cryptographie quantique utilisant cette technique de détection (à ce jour l’ensemble des produits du 

marché) sont ainsi vulnérables, la seule difficulté de l’attaque résidant dans le paramétrage précis, le 

dosage devrions nous dire, de l’énergie à transmettre pour saturer le capteur et du quantum d’énergie 

supplémentaire requis pour changer l’état détecté. Ce dosage dépendra de nombreux facteurs dont le 

schéma du détecteur mais aussi, et surtout, des caractéristiques de la diode de détection utilisée. 

Ce que confirment nos chercheurs: 

The security loophole we have exposed is intrinsic to a whole class of single-photon detectors, regardless of their 

manufacturer and model. However we had to reverse-engineer each system, to see what we are doing and also to 

illustrate the principle. 

Et qu’ils ont mis en application avec succès en passant de la théorie - sur un système de recherche - à la 

pratique - sur deux dispositifs commerciaux (ID Quantique id3110 Clavis2 et MagiQ Technologies QPN 

5505), les fabricants ayant été informés bien avant la publication des résultats. 

This security vulnerability was responsibly disclosed to both system manufacturers, several months prior to its public 

release. 

Le papier publié dans Nature présente avec force de détails et d’illustrations - un indéniable avantage de 

la publication dans une revue de référence - le procédé d’attaque ainsi que sa mise en œuvre sur les deux 

dispositifs commerciaux. 

Les paramètres de configuration de l’illuminateur – les puissances requises pour aveugler et altérer l’état 

des deux capteurs via un laser – sont fournis facilitant la reproduction de l’attaque. Les auteurs précisent 




cependant que l’équipement QPN 5505 n’est plus livré, les modèles suivants n’ayant pas été testés, et 

que des contre-mesures ont été incorporées dans les équipements livrés par la société ID Quantique. Nos 

lecteurs trouveront quelques détails techniques complémentaires sur le site de l’équipe universitaire dont 

en particulier diverses photos des détecteurs des équipements testés ainsi que la liste des instruments de 

mesure employés pour mener à bien les tests. 

En pratique, comme nous le soulignions dans notre tout premier article, pour être mise en œuvre cette 

attaque suppose l’insertion d’un dispositif en coupure, et donc une manipulation physique de la fibre 

optique transportant le flux photonique laquelle manipulation pourrait être assez aisément détectée. 

« In theory, theory and practice are the same but in practice, they're very different » 

« En théorie, théorie et pratique sont identiques mais dans la pratique, il y a une grande différence » 

Bruce Schneier 2010 

POUR PLUS D’INFORMATION 

http://www.iet.ntnu.no/groups/optics/qcr/hacking-commercial-quantum-cryptography-2010/ 

http://www.nature.com/nphoton/journal/vaop/ncurrent/full/nphoton.2010.214.html 

https://har2009.org/program/events/168.en.html 

http://www.vad1.com/photo/stock/20090705-eavesdropping-experiment-on-nus-campus-map.html 

http://www.cert-devoteam.fr/articles/CERT-DVT-134-0909_Cryptographie_Quantique.pdf 

UN RETOUR SUR STUXNET 

Découvert en juin dernier, le ver W32.Stuxnet est caractéristique de l’émergence de nouvelles 

menaces ciblant explicitement certains actifs, dans le cas présent, les systèmes de gestion 

industriels – SCADA - et en particulier le système développé par la société Siemens. 

Ce ver tire avantage de multiples vulnérabilités présentes dans les systèmes Windows dont celle, 

désormais célèbre, liée à un problème dans le traitement des fichiers de raccourci (extension .LNK). Pour 

mémoire, il est possible de construire un fichier de raccourci spécifique référençant un fichier contenant 

un code qui sera chargé, puis exécuté, par toute application – dont l’explorateur de fichiers – cherchant à 

afficher à l’écran l’icône associée à ce raccourci. A ce sujet, la série de correctifs publiée par Microsoft ce 

mois-ci comporte une mise à jour – MS010-061 – verrouillant un autre des accès utilisés par Stuxnet. 

Autre caractéristique remarquable de ce ver, l’installation de deux gestionnaires de périphériques – les 

fichiers ‘mrxcls.sys’ et ‘mrxnet.sys’ – authentifiés par la signature du code, celle-ci référençant un 

certificat délivré par Verisign à la société ‘Realtek Semiconductor Corp.’, un fabricant de composants 

taïwanais réputé pour ses contrôleurs de réseaux. 

La stratégie de réplication utilisée par Stuxnet a fait l’objet d’études très détaillées dont celle publiée par 

Symantec quelques temps après la découverte de ce ver. Automatiquement exécuté par le système 

Windows durant la routine de détection de présence d’un support infecté, une clef USB ou un nouveau 

partage réseau par exemple, Stuxnet engage prioritairement une procédure permettant de dissimuler sa 

présence puis installe en mémoire un processus masqué. 

Ce processus est le cœur du ver. D’après les analyses disponibles, ce processus assure la réplication du 

code d’infection sur les supports amovibles et sur les partages réseaux présents sur le système infecté. Il 

gère aussi les communications avec un système de contrôle distant et est capable de télécharger des 

mises à jour. 

Enfin, et c’est là sa réelle spécificité, il interagit avec les fichiers des applications de gestion et de 

supervision des automates programmables industriels (Programmable Logic Controller ou PLC) de la série 

Siemens SIMATIC 7. Deux applications HMI (Humain Machine Interface) semblent être plus 

particulièrement visées: WINcc et PCS7. 

Aucun détail concernant les actions engagées sur ces applications n’est fourni dans les analyses publiées à 

ce jour en dehors d’une liste de fichiers annoncés appartenir à l’environnement de gestion des systèmes 

SIMATIC Siemens, d’une vague référence à des requêtes sur des ‘DB’ utilisées par les logiciels et de 

l’existence d’interactions avec les librairies dynamiques de ces derniers. 

Le terme DB ne signifie ici nullement Base de données (Data Base) comme certains ont pu l’interpréter 

mais ‘Data Bloc’. Pour mieux comprendre la suite de notre propos, un bref rappel du fonctionnement d’un 

Automate Industriel Programmable ne sera peut être pas inutile. 

De nombreux processus industriels peuvent aisément être décrits sous la forme d’automates d’états finis 

prenant en entrée divers signaux issus de capteurs physiques – position, angle, vitesse, débit… - et 

pilotant en sortie divers actionneurs – témoin de signalisation, pompe, moteur, vanne... – en fonction de 

consignes spécifiques à chaque processus – plage de température, niveau de liquide… 

Les contraintes liées au milieu – robustesse, sureté de fonctionnement, temps de réponse, déterminisme 

de l’exécution, volume réduit et protection contre les agressions externes – conduisent à privilégier 

l’utilisation d’équipements spécifiquement conçus au détriment de systèmes informatiques plus 




classiques, lesquels seront généralement réservés aux fonctions de gestion et de supervision. 

Un automate programmable industriel moderne prendra Automate Télémécanique TSX17 des années 90 

bien souvent la forme d’un module maître s’installant sur 

un rail DIN et d’un ou plusieurs modules spécialisés 

assurant le raccordement des capteurs, des actionneurs 

mais aussi l’interfaçage vers un bus de communication 

et un protocole spécialisé tel ModBus ou ProfiBus pour 

ne citer que les protocoles les plus connus. 

Ces automates sont généralement dotés d’un langage de 

programmation simple, d’une mémoire sauvegardée, 

d’une librairie de fonctions élémentaires et d’un protocole 

de transfert d’informations basé sur l’échange de 

structures de données opaques. Cette approche permet 

d’optimiser les performances en éliminant le besoin 

d’encoder le type des données échangées, les 

applications disposant d’un catalogue des structures 

utilisées par les librairies. 

Dans le cas des automates Siemens, ces fonctions (FB ou Function Bloc) et structures de données (DB ou 

Data Bloc) sont référencées par un identifiant numérique. 

Pour en revenir à notre sujet de départ, une étude 

détaillée des interactions de StuxNet (version non 

précisée) avec un environnement SIMATIC 7 a été 

publié mi-septembre. Cette étude offre un nouvel 

éclairage sur ce qui n’avait été jusqu’à présent 

analysé qu’à travers la vision d’une attaque de 

masse. 

L’étude publiée par un chercheur travaillant pour 

l’IACS Allemand, Ralph Langner, met en lumière 

deux interactions qui ne doivent de toute évidence 

rien au hasard: 

- La première consiste à intercepter les requêtes 

de lecture d’un bloc de données spécifique (DB 

890) transmis par un automate à destination 

d’une application de supervision et à altérer son 

contenu lorsque celui-ci contient une séquence 

précise, en l’occurrence la chaîne ‘HNDS’. 

Une rapide recherche dans le catalogue des structures du système SIMATIC Siemens nous permet 

d’identifier ce bloc, lequel est dénommé ‘RC_SEND_FIFO1’ et décrit comme étant le ‘Bloc interne pour 

l'émission de télégrammes au serveur RC (maître)’. Le serveur RC - le terme RC signifie ‘Route Control’ 

- est responsable de la gestion, de la configuration et de la supervision des mécanismes de transport de 

matière – lignes de convoyage des matériaux ou de distribution de liquides ou de gaz par exemple – 

entre les différentes unités de production supervisées. 

The Route Control Server (RC Server) supplies the Route Control Clients (Route Control Center) with the necessary 

data and transfers their operations to the automation systems. 

Tout laisse donc à penser que le code malveillant déposé par Stuxnet tente de manipuler des trames 

de routage contenant une étiquette précise, ici ‘HNDS’. Il pourrait s’agir de la référence d’une ligne de 

distribution ou d’approvisionnement d’une unité dans un système de production complexe mais seul 

l’auteur du code, ou le concepteur de l’infrastructure cible, pourrait le confirmer. 

- La seconde interaction consiste à modifier la configuration d’une routine cyclique avant son chargement 

dans l’automate, en l’occurrence, la routine ‘OB 35’ déclenchée toute les 100ms en y insérant une 

nouvelle tâche. Positionné en début de routine, cette tâche teste le code retour d’une fonction bien 

précise (FC 1874), et quitte le traitement lorsque ce code retour prend une valeur prédéterminée 

(DEAFF007). Aucune information n’a hélas pu être trouvée ni sur la signification de ce code, ni sur le 

rôle de la fonction 1874. 

Même sans disposer de toutes les informations permettant de comprendre le fonctionnement détaillé du 

code injecté dans les postes de gestion et de supervision, les données publiées par Ralph Langner 

confirment qu’il y a de très fortes chances pour que Stuxnet soit le résultat d’un développement très 

spécifique, ‘à façon’ dirions-nous, probablement conduit par une équipe pluridisciplinaire intégrant non 

seulement des spécialistes de l’intrusion mais aussi de l’environnement Siemens STEP 7. Stuxnet utilise 

ainsi quatre vulnérabilités inconnues à l’époque de sa découverte – vulnérabilités dites ‘0-Days’ – pour se 

dupliquer et se propager, un record absolu. 




Le code analysé par Ralph Langner prouve que l’objectif des concepteurs n’était certainement pas 

d’interrompre instantanément le système de production cible mais plutôt de modifier son fonctionnement 

sans que cela ne soit immédiatement détecté, et sans que cela n’impacte les autres systèmes susceptibles 

d’avoir été infectés. Une bombe logique, dont on ne sait rien encore des conditions de déclenchement, 

comme celle que Thierry Breton envisageait en 1984 dans son remarquable livre Softwar. Ralph 

Langner envisage ici que la cible de cette attaque puisse être un centre d’enrichissement d’uranium ou 

une centrale nucléaire, la centrale Iranienne de Bushehr est citée dans l’article; une pure spéculation au 

regard de l’information publiquement disponible. 

Le choix du vecteur premier de compromission – une clef USB, un fichier de raccourci judicieusement 

construit et quelques fichiers exécutables dont certains ayant toutes les caractéristiques de fichiers 

officiels car signés – permet de passer outre tous les contrôles aux frontières du réseau de raccordement 

des systèmes de gestion de l’environnement de production cible, lequel réseau doit très probablement 

être totalement isolé et déconnecté de tout autre réseau. Les concepteurs de ce qui apparaît être une 

véritable cyber-arme auront d’ailleurs très certainement bien peu apprécié que leur création se soit 

échappée du réseau cible pour se retrouver active, au vu et su de tous, sur Internet. Peut-être est-ce là la 

plus belle erreur de conception qui soit: avoir sous-estimé la capacité d’infection d’un support aussi 

élémentaire qu’une clef USB à moins que cela ne soit partie intégrante de la stratégie d’infection. 

Il n’y aucune raison pour que Stuxnet soit un cas isolé et le seul représentant d’une nouvelle forme de 

lutte offensive. Nous sommes persuadé que bien d’autres créations de ce type sont en cours d’étude dans 

les laboratoires de ‘sécurité offensive’ dont nombre de gouvernements se dotent depuis quelques temps. 

Espérons simplement que les concepteurs de ces armes du 21 ième siècle auront tiré une leçon de cette 

‘affaire’ et auront, comme leurs ainés durant la guerre froide, implémenté les mécanismes requis pour 

désactiver celles-ci en cas d’erreur sur la cible, ou plus simplement en cas de perte de contrôle du canal 

de commande. 


http://www.langner.com/en/index.htm 

http://www.digitalbond.com/index.php/2010/09/16/stuxnet-target-theory/ 

http://www.symantec.com/connect/fr/blogs/w32stuxnet-installation-details 

http://www.symantec.com/connect/blogs/stuxnet-infection-step-7-projects 

http://www.cs.columbia.edu/~smb/blog/2010-09/2010-09-27.html 

COMMENT LIRE UN BREVET EN 60 SECONDES 

Les brevets sont une fabuleuse source d’information pour qui prendra le temps de consulter les 

bases de données libres d’accès sur l’Internet qu’il s’agisse d’étudier l’avance technologique d’un 

éventuel concurrent, d’identifier les nouvelles technologies émergentes ou encore de comprendre 

le fonctionnement d’un dispositif, d’un procédé, ou d’un algorithme, développé par un tiers. 

Les descriptions, et revendications, contenues dans les brevets de certains dispositifs de sécurité peuvent 

devenir leur talon d’Achille. Ce fût par exemple dernièrement le cas dans la mise en défaut d’un certain 

nombre de systèmes de contrôle d’accès, dont en particulier, le système MIFARE. 

Le risque de voir un verrou technologique divulgué par le bais d’un dépôt de brevet quand l’objectif initial 

était simplement d’assurer la protection de l’invention est d’autant plus grand que de nombreux outils de 

recherche perfectionnés sont désormais disponibles. Le WIPO – Office Mondial de la Propriété 

Intellectuelle ou OMPI – reconnaît explicitement l’importance des brevets dans le communiqué de presse 

accompagnant l’annonce de la mise en place de son programme ASPI (Access to Specialized Patent 

Information) destiné à faciliter l’accès à la matière de certains brevets spécialisés: 

“Patent information represents a critical source of knowledge and insight for researchers and innovators, legal 

professionals, entrepreneurs, and policymakers across the globe. The ASPI program will allow developing and leastdeveloped 

countries to benefit from enhanced access to powerful tools for exploiting this valuable resource under very 

favorable conditions.” 

Cette même organisation vient d’annoncer la mise à disposition d’un outil de recherche spécialisé dans le 

domaine du développement durables, des énergies renouvelables et de l’écologie. Cet outil, IPC Green 

Inventory, s’appuie sur le service de recherche PatentScope opéré par le WIPO (Rapport N°143 – Juin 

2010). On notera que dans cette liste spécialisée ‘GREEN’ figure une section consacrée aux systèmes 

d’information, ou plus précisément aux moyens permettant de rationnaliser l’accès et la gestion des SI. Le 

thème ‘Commuting’ qui apparaît ainsi dans la section ‘Administrative, Regulatory Or Design Aspects’ 

regroupe des brevets de la catégorie ‘G06Q – Computing; Calculating; Counting’ et ‘G08G - traffic 

control systems’. 

La mise à disposition de cette masse d’information ne dispense pas de savoir lire un brevet, une 

connaissance qui s’acquiert généralement à force de lecture, et parfois par la pratique en se faisant 

accompagner d’un cabinet de conseil spécialisé dans le dépôt de brevets. 




Dans un court billet intitulé ‘How to read a patent in 60 seconds’, Dan Shapiro énumère les quelques 

principes fondamentaux qui permettront d’aller à l’essentiel – le fond à savoir les revendications – sans se 

perdre, dans un premier temps du moins, dans les méandres de la forme du brevet. L’approche proposée 

est applicable en premier lieu aux brevets américains, véritables fourre-tout, et dans une moindre mesure 

aux brevets européens mieux organisés. 

Dan Shapiro suggère ainsi de ne pas tenir compte de ce qui représente, en volume, plus des deux tiers 

d’un brevet, à savoir: 

- le titre (section Title) dont il dit avec raison que celui-ci n’a généralement que bien peu de rapport avec 

l’innovation proprement dite, 

- la synthèse (section Abstract), et la description (section Description), qui ici encore n’apporte 

aucune précision sur l’innovation proprement dite, et perd le lecteur dans des détails concernant le 

contexte, 

- les dessins d’accompagnement (section Drawings) qui, la plupart du temps et au moins dans le cas 

des brevets américains, n’apportent guère d’information, 

Il s’agira donc d’aller immédiatement à la section décrivant toutes les revendications (section Claims) en 

identifiant le principe fondamental de l’innovation (‘independant claim’ dans l’article) tout en ignorant 

dans un premier temps les revendications secondaires (‘dependant claim’ dans l’article), lesquelles ne font 

qu’étendre le champ d’application à toutes les situations pouvant être imaginées. La distinction est aisée 

puisque ces revendications secondaires sont décrites par de courtes phrases ayant toujours la même 

forme et référençant elles-mêmes la revendication principale ou l’une des revendications secondaires 

précédemment exprimée: ‘The method of claim x’, ‘The system of claim x’, ‘The apparatus of claim x’… 

La partie la plus intéressante dans le cadre de l’étude d’une veille, ou d’une recherche d’antériorité, est 

probablement la liste des brevets portant sur des innovations référencées dans la description, ou 

considérées comme susceptibles de modifier l’étendue des revendications (section US Patent Reference 

en tête des brevets américains et section Document Considered to be Relevant en fin des brevets 

Européens). Outre le nom, ou la raison sociale, de l’inventeur, le brevet porte deux dates intéressantes: la 

date de dépôt (date de la demande) et la date de publication (date de l’acceptation de la revendication). 

Dans un autre domaine, le programme de transfert de technologie initié par la NSA offre une intéressante 

source d’information pour tout ce qui concerne les techniques et innovations de pointe dans le domaine de 

la sécurité des systèmes de communication et d’information. 


http://www.danshapiro.com/blog/2010/09/how-to-read-a-patent-in-60-second/ - Article 

http://www.wipo.int/pressroom/en/articles/2010/article_0031.html - Annonce du WIPO 

http://www.wipo.int/pressroom/en/articles/2010/article_0032.html - Annonce du WIPO 

http://www.uspto.gov/patents/process/search/ - Recherche sur les brevets US 

https://data.epo.org/publication-server/?lg=en - Recherche sur les brevets EU 

http://www.nsa.gov/research/tech_transfer/fact_sheets/index.shtml - Transfert de technologies NSA 

AFNIC – LES ENJEUX DU DNSSEC 

L’AFNIC vient de publier un guide traitant des extensions de sécurité du système de gestion des 

noms, extensions désignées par le sigle désormais bien connu ‘DNSSEC’. 

Disponible en langue Française mais aussi Anglaise, cet opuscule de 8 pages intitulé ‘Les enjeux de 

DNSSEC’ tente de répondre aux nombreuses questions que les administrateurs et les exploitants de 

systèmes d’information ne manqueront pas de se poser avant de sauter le pas, et d’activer les 

fonctionnalités de sécurité dans leur serveur DNS. 

Les deux premiers chapitres illustrent l’intérêt de l’activation de ces fonctionnalités en détaillant le 

fonctionnement du DNS ‘classique’ et en mettant en évidence les vulnérabilités structurelles qui pourront 

être exploitées pour induire en erreur un usager. Le fonctionnement des mécanismes de sécurité du 

DNSSEC, et leur intégration dans la structure du DNS, est présenté dans les chapitres suivants, les 

descriptions techniques étant éclairées par quelques illustrations simples et pédagogiques. Le service DNS 

étant bien souvent délégué à l’opérateur assurant le transport et/ou l’hébergement, il conviendra de bien 

étudier l’offre de service proposée par celui-ci. On pourra pour cela s’appuyer sur la check liste proposée 

par l’AFNIC en fin de document. 

La publication de ce guide intervient après qu’une étape cruciale pour le déploiement du DNS sécurisé en 

France ait été franchie: les zones gérées par l’AFNIC - .fr, .re, .tf, .yt et .pm – sont désormais signées, 

et les paramètres de signatures ont été publiés à la mi-septembre. L’AFNIC annonce d’ailleurs à ce sujet 

que les enregistrements DNS seront mis à jour dans le mois à venir et que le service sera ouvert aux 

délégations dans le ‘.fr’ durant le second semestre 2011. Pour simplifier, ceci veut dire que tout serveur 

de nom sera à même de vérifier les réponses des serveurs de l’AFNIC d’ici la fin octobre, et l’intégralité de 

la chaîne de certification pour un nom de domaine signé dans la zone ‘.fr’ à la fin de l’année prochaine. 




Le guide de l’AFNIC aborde les points suivants: 

1 - Organisation et fonctionnement du DNS 

2 - Les attaques par empoisonnement de cache 

3 - Qu’est-ce que DNSSEC ? 

4 - Ce que n’est pas DNSSEC 

5 - Utilisation des clés dans DNSSEC 

6 - Le déploiement de DNSSEC 

7 - Quelques questions à se poser au regard de la mise en place de DNSSEC 

8 - Pour aller plus loin 

9 - Glossaire 

On notera qu’une intéressante liste des trois principaux problèmes rencontrés à l’occasion du déploiement 

du DNSSEC dans le domaine ‘.gov’ réservé aux institutions gouvernementales américaines a été publiée 

par Scott Rose, du NIST. 


http://www.afnic.fr/afnic/r_d/dnssec - Accueil DNSSEC 

http://www.afnic.fr/afnic/web/certificats - Certificats fr, re, tf, yt et pm 

http://www.afnic.fr/data/divers/public/afnic-dossier-dnssec-2010-09.pdf - Version Française 

http://www.afnic.fr/data/divers/public/afnic-issue-paper-dnssec-2010-09.pdf - Version Anglaise 

https://www.dnssec-deployment.org/index.php/2010/08/biggest-problems-seen-in-dnssec-operation-in-gov/ 



MAGAZINES 

HNS - (IN)SECURE MAG N°27 


ANALYSES ET COMMENTAIRES 

Le 27 ième numéro du magazine ‘(In)Secure Mag’ est paru fin août. Deux articles ont plus 

particulièrement attiré notre attention. 

PAYMENT CARD SECURITY: RISK AND CONTROL ASSESSMENTS G.T. Rasmunssen 

Ce court article de Gideon Rasmussen, consultant indépendant, est consacré à la sécurité des 

systèmes de paiement. Il rappelle l’intérêt d’une analyse conduite sous l’angle de vue des modes de 

défaillance – AMDEC (Analyse des Modes de Défaillance, de leurs Effets et de leur Criticité) ou FMEA 

(Failure Mode and Effects Analysis), une approche couramment utilisée dans l’analyse de la sûreté de 

fonctionnement des systèmes de conduite industriels critiques. 

L’utilisation de cette approche sur un scénario très certainement réel, bien que rien ne soit précisé, 

mène à l’établissement d’une liste de mesures permettant de couvrir les exigences PCI-DSS - voire 

même d’aller au-delà de ces exigences – en matière de: 

- vérifications préventives, 

- moyens de détection et 

- techniques de réduction du risque. 

LEARNING FROM BRUTEFORCERS Erich Samuel 

L’auteur de cet article, Erich Samuel, est consultant sécurité auprès d’une société d’assurance. Il a 

installé, comme de nombreux informaticiens, un petit serveur chez lui qui lui sert à diverses 

expérimentations dans son domaine d’expertise, la sécurité. Et il n’a pas manqué de remarquer, 

comme beaucoup d’exploitants, les traces des innombrables tentatives d’attaque des comptes SSH 

dans les journaux de son système LINUX. Ceci l’a conduit à se poser la question de savoir ce que l’on 

pouvait tirer des informations collectées durant ces tentatives. 

Après avoir pris le temps d’analyser le problème, et d’écrire un module PAM ‘maison’, il était à même 

d’étudier plus en détails les caractéristiques de ces tentatives d’intrusion et ceci, sans avoir à déployer 

aucun outil tiers. L’intérêt de l’approche réside dans l’utilisation de l’interface programmatique UNIX 

dite ‘Pluggable Authentication Module’, ou PAM, laquelle permet d’intégrer dynamiquement un 

traitement spécifique dans la chaîne d’authentification. Un module PAM aura ainsi accès à de 

nombreuses informations contextuelles qui ne sont pas toujours retranscrites dans les journaux de 

sécurité sans oublier la possibilité de traiter les données en temps réel. 

Les informations collectées sur une période allant de décembre 2009 à juillet 2010 lui ont permis 

d’obtenir quelques réponses aux questions que ses clients institutionnels lui posaient. 

1- Quelqu’un veut-il vraiment nous attaquer ? 

Comme le fait remarquer l’auteur de l’article cette question est régulièrement posée par le béotien à 

qui le consultant sécurité explique la nécessité de protéger son système quand bien même ne 

serait-il qu’un système personnel. Le résultat, évident pour quiconque travaille dans le domaine, est 

bien difficile à faire admettre hors la profession sauf à disposer de données en provenance, non 

d’une étude menée par des spécialistes sur des systèmes professionnels, mais d’une machine 

‘lambda’ similaire à celle (ou presque) utilisée par tout un chacun. Les chiffres présentés par 

l’auteur parlent d’eux-mêmes puisque sur une période de 8 mois, 159969 tentatives d’accès sur un 

compte SSH ont été comptabilisées en provenance de 728 sources distinctes, soit une moyenne de 

658 tentatives par jour. 

2- Pourquoi dois-je sélectionner un bon mot de passe ? 

Encore une question que nos lecteurs auront probablement entendu de la bouche de leurs proches 

après avoir tenté d’expliquer qu’utiliser le même mot de passe pour tous les comptes de la famille, 

ou de choisir un mot de passe facile à mémoriser, est une très mauvaise habitude. La liste des mots 

de passe les plus fréquemment testés sur la période d’observation (123456, password, test, 1234, 

root, oracle, qwerty, 12345, abc123, redhat) établie par l’auteur n’apportera guère d’eau au moulin. 

Ces mots de passe sont en effet probablement issus de listes (dictionnaires) communs à la majorité 

des outils d’attaque. A contrario, l’analyse des variations d’un même mot de passe – dans le cas 




étudié par l’auteur, le mot ‘password’ – prouve sans ambiguïté au plus défiant des usagers qu’il ne 

suffit pas de remplacer ca et là, une lettre par un symbole dans un mot courant – ‘P@ssw0rd’ par 

exemple - quand bien même cette technique permettra de réduire notablement le risque de voir son 

mot de passe être immédiatement révélé. L’usage du langage ‘L337’ doit donc désormais – hélas - 

être proscrit au profit d’autres techniques. 

3- Ne s’en vont-ils pas après quelques essais ? 

Le sujet abordé à travers cette question est particulièrement pertinent et, à notre connaissance, a 

rarement été traité dans les études publiées par ailleurs. Répondre à cette question avec précision 

supposerait de pouvoir distinguer dans les traces de journalisation les tentatives en provenance de 

systèmes totalement automatisés et éventuellement couplés, peut-être devenus hors contrôle, de 

celles résultant d’une activation ponctuelle et explicite. 

Les résultats présentés par l’auteur mettent 

en évidences deux types d’activés distincts: 

des tentatives apparaissant être ponctuelles 

mais susceptibles d’être le résultat d’une 

campagne coordonnée sur plusieurs systèmes 

d’une durée de l’ordre du mois, et de 

véritables campagnes de fond, continues ou 

récurrentes, en provenance de sources 

stables. Nous reproduisons ci-contre, pour 

information, le tableau de synthèse présenté 

dans l’article. 


http://www.net-security.org/dl/insecure/INSECURE-Mag-27.pdf 



METHODES 


METHODOLOGIES ET STANDARDS 

NIST - IR7628 'SMART GRID CYBER SECURITY STRATEGY AND REQUIREMENTS' 

En octobre 2009, le NIST diffusait pour relecture et commentaire un document de première 

importance, le rapport IR-7628 ‘Smart Grid Cyber Security Strategy & Requirements’ 

(Rapport N°135 – Octobre 2009). La version finale de ce volumineux document – plus de 500 pages – 

vient d’être publiée. Un document de première importance car traitant de la sécurité de ce qui sera 

probablement la plus grande évolution technologique du 21 ième siècle: la gestion intelligente, et locale, de 

la distribution de l’énergie électrique. 

L’objectif de ce que les américains appellent le réseau intelligent, ‘Smart Grid’ dans le jargon, est de 

s’appuyer sur les dernières technologies de communication et de traitement de l’information pour acquérir 

les données de pilotage permettant d’adapter la demande des usagers à la production d’énergie en temps 

quasi-réel et disposer d’indicateurs prévisionnels fiables. 

Une nécessité liée à la caractéristique de cette forme d’énergie immédiatement disponible mais difficile à 

stocker, du moins à des coûts inférieurs à ceux de sa production. Ce besoin d’optimisation de la 

distribution est bien loin d’être nouveau - les centres de gestion (dispatching) existent depuis toujours, ou 

presque, mais sans toutefois pouvoir agir aussi près des consommateurs avec la granularité et le temps 

de réponse promis par les équipements intelligents disponibles depuis quelques années sur le marché. 

A même de mesurer instantanément notre consommation électrique avec une fiabilité jamais atteinte, de 

corréler celle-ci avec divers événements extérieurs, et par conséquent de révéler nos habitudes de vie, 

ces équipements peuvent être perçus comme une atteinte à notre liberté individuelle si des mesures de 

protection ne sont pas prises: encadrement de l’usage des données collectées mais aussi protection de 

l’accès à l’équipement et de la confidentialité des données télé-collectées. 

Modèle d’échange d’informations au sein d’une grille intelligente établi par le NIST (IR-7628 – part 2 – page 22) 




Ouvrons une parenthèse pour rappeler qu’il s’agit d’un problème auquel nos concitoyens vont être 

rapidement sensibilisés avec l’annonce de la possible obligation d’installation du compteur intelligent 

‘Linky’ dans les nouvelles habitations. Celui-ci dispose de fonctions de gestion évoluées accessibles à 

distance, et utilise le réseau électrique comme moyen de collecte: transmission par courant porteur ou 

‘CPL’ avec collecte au niveau des postes HTA/BT desservant un ensemble d’abonnés puis acheminement 

vers un centre de traitement. Nos lecteurs intéressés par les spécifications du protocole de communication 

pourront se reporter avec intérêt à la note interne ‘Spécifications du profil CPL Linky’ publiée en 

octobre dernier par ERDF. L’analyse des caractéristiques de la modulation retenue – FSK centrée une 

fréquence de 68.65kHz avec une vitesse de 2400bds et un niveau d’émission variant entre -53 et 6dBV 

laisse entendre qu’il ne sera guère difficile à un amateur de réaliser un dispositif d’acquisition à distance 

des trames, ou a minima un brouilleur, pour quelques dizaines d’euro, et même d’écrire le module 

d’analyse WireShark qui va bien. Le chapitre 5 de la note ‘Spécifications fonctionnelles du profil CPL 

Linky’ laisse fort heureusement entendre que les données seront protégées par un mécanisme de 

chiffrement selon la spécification COSEM DLMS UA 1000-1 ‘Identification System and Interface’. 

Gageons qu’avec le déploiement des compteurs intelligents, ces documents vont être très rapidement 

étudiés à la loupe par tous les spécialistes de la retro-analyse, et feront peut être l’objet de 

communications dans les mois à venir. 

Ces technologies, qui au regard du citoyen apparaissent être coûteuses, inutiles et intrusives, pourraient 

bien être rejetées en bloc si des mesures permettant de garantir que tout sera fait pour assurer la 

protection de la vie privée ne sont pas rapidement prises. La CNIL Française joue ici parfaitement son 

rôle de vigie en rappelant dans un communiqué récent qu’elle suit avec attention le développement de ces 

systèmes afin de s'assurer que les informations concernant les usagers seront traitées dans le respect de 

la loi Informatique et Libertés. 

Protéger le consommateur, qu’il s’agisse des citoyens ou des entreprises et autres organisations, est une 

exigence forte qui ne doit cependant pas masquer les autres contraintes pesant sur les opérateurs de ces 

infrastructures critiques, en particulier la résilience des systèmes assurant le contrôle de équipements de 

distribution. 

Disposant de moyens de communication performants, les équipements existants et à venir sont une cible 

de premier choix pour quiconque envisagerait de déstabiliser une région, un pays. La mise en évidence de 

problèmes critiques ces dernières semaines – vulnérabilité dans le système de gestion industriel WinCC 

de Siemens (CVE-2010-2772) et existence d’un accès exploitable dans le système d’exploitation industriel 

VxWorks (CVE-2010-2965 et CVE-2010-2966) – confirme si besoin la réalité du risque, et prouve que la 

sécurisation des environnements industriels est l’un des grands défis des prochaines années. 

L’ENISA a ainsi engagé depuis l’année dernière une réflexion approfondie sur la résilience des réseaux de 

communications. 

Aux Etats-Unis, la North American Electric Reliability 

Corporation – NERC - a publié un impressionnant 

ensemble de recommandations, guides et bonnes 

pratiques au titre de la protection des infrastructures 

critiques dont une liste proposée ci-contre. 

Le document établi par le groupe de travail ad hoc 

constitué par le NIST vient compléter ce premier 

référentiel. Il prescrit la mise en place d’un système de 

défense en profondeur et détaille 189 exigences de 

sécurité applicables sur les quelques 137 interfaces 

d’échange identifiées. 

Critical Infrastructure Protection Cyber Security Guides 

CIP-001 Sabotage Reporting 

CIP-002 Critical Cyber Asset Identification 

CIP-003 Security Management Controls 

CIP-003 Security Management Controls 

CIP-004 Personnel & Training 

CIP-005 Electronic Security Perimeter(s) 

CIP-006 Physical Security of Critical Cyber Assets 

CIP-007 Systems Security Management 

CIP-008 Incident Reporting and Response Planning 

CIP-009 Recovery Plans for Critical Cyber Assets 

Ce document est organisé en 10 chapitres et 10 annexes, l’ensemble étant découpé en trois volumes 

d’inégale importance: 

- la première partie (289 pages – chapitres 1 à 4) est consacrée à la formulation des exigences de 

sécurité, 

- la seconde (69 pages – chapitre 5) traite principalement de la problématique de la protection des 

données privées, et 

- la troisième partie (219 pages – chapitres 6 à 10) détaille l’approche méthodologique retenue et 

propose quelques cas d’école. 

L’importance accordée à ce sujet par les instances américaine est mesurable au travail accompli en 11 

mois: le document IR-7628 comportait en effet initialement 4 chapitres et 6 annexes pour un total de 236 

pages. En pratique, et à l’exception de la modélisation de la grille, le lecteur constatera un changement 

assez radical dans l’approche méthodologique, avec en particulier l’abandon d’une classification des 

interfaces par domaines fonctionnels (six domaines étaient définis) au profit d’un modèle de référence 

global bien plus difficile à apprécier. On appréciera par contre l’intégration d’un chapitre entièrement 

consacré aux exigences. 




Le sommaire du rapport IR-7628 est le suivant: 

Part 1 - Smart Grid Cyber Security Strategy, Architecture, and High-Level Requirements 

CHAPTER 1 CYBER SECURITY STRATEGY 

1.1 Cyber Security and the Electric Sector 

1.2 Scope and Definitions 

1.3 Smart Grid Cyber Security Strategy 

1.4 Outstanding Issues and Remaining Tasks 

CHAPTER 2 LOGICAL ARCHITECTURE AND INTERFACES OF THE SMART GRID 

2.1 The Seven Domains to the Logical Reference Model 

2.2 Logical Security Architecture Overview 

2.3 Logical Interface Categories 

CHAPTER 3 HIGH-LEVEL SECURITY REQUIREMENTS 

3.1 Cyber Security Objectives 

3.2 Confidentiality, Integrity, and Availability Impact Levels 

3.3 Impact Levels for the CI&A Categories 

3.4 Selection of Security Requirements 

3.5 Security Requirements Example 

3.6 Recommended Security Requirements 

3.7 Access Control (SG.AC) 

3.8 Awareness and Training (SG.AT) 

3.9 Audit and Accountability (SG.AU) 

3.10 Security Assessment and Authorization (SG.CA) 

3.11 Configuration Management (SG.CM) 

3.12 Continuity of Operations (SG.CP) 

3.13 Identification and Authentication (SG.IA) 

3.14 Information and Document Management (SG.ID) 

3.15 Incident Response (SG.IR) 

3.16 Smart Grid Information System Development and Maintenance (SG.MA) 

3.17 Media Protection (SG.MP) 

3.18 Physical and Environmental Security (SG.PE) 

3.19 Planning (SG.PL) 

3.20 Security Program Management (SG.PM) 

3.21 Personnel Security (SG.PS) 

3.22 Risk Management and Assessment (SG.RA) 

3.23 Smart Grid Information System and Services Acquisition (SG.SA) 

3.24 Smart Grid Information System and Communication Protection (SG.SC) 




3.25 Smart Grid Information System and Information Integrity (SG.SI) 

CHAPTER 4 CRYPTOGRAPHY AND KEY MANAGEMENT 

4.1 Smart Grid Cryptography and Key Management Issues 

4.2 Cryptography and Key Management Solutions and Design Considerations 

4.3 NISTIR High-Level Requirement Mappings 

4.4 References & Sources 

APPENDIX A Crosswalk Of Cyber Security Documents 

APPENDIX B Example Security Technologies And Services To Meet The High-Level Security Requirements 

Part 2 - Privacy and the Smart Grid 

CHAPTER 5 PRIVACY AND THE SMART GRID 

5.1 Introduction 

5.2 What Is Privacy? 

5.3 Legal Frameworks and Considerations 

5.4 Consumer-to-Utility Privacy Impact Assessment 

5.5 Personal Information in the Smart Grid 

5.6 In-depth Look at Smart Grid Privacy Concerns 

5.7 Mitigating Privacy Concerns Within the Smart Grid 

5.8 Smart Grid Privacy Summary And Recommendations 

APPENDIX C State Laws – Smart Grid And Electricity Delivery Regulations 

APPENDIX D Privacy Uses Cases 

D.1 Use Case Inventory, Consolidation and Gap Analysis 

D.2 Incorporating Privacy Into Existing Smart Grid Use Cases 

D.3 Privacy Use Case Examples 

D.4 Privacy Use Case #1: Landlord with Tenants 

D.5 Privacy Use Case #2: PEV General Registration and Enrollment Process 

APPENDIX E privacy related definitions 

E.1 Privacy Impact Assessment 

E.2 Personal Information 

E.3 Personally Identifiable Information (PII) 

E.4 Composite Personal Information 

E.5 Private Information 

E.6 Confidential Information 

E.7 Individual 

E.8 Smart Grid Entity 

Part 3 - Supportive Analyses and References 

CHAPTER 6 VULNERABILITY CLASSES 


6.2 People, Policy & Procedure 

6.3 Platform Software/Firmware Vulnerabilities 

6.4 Platform Vulnerabilities 

6.5 Network 

6.6 References 

CHAPTER 7 BOTTOM-UP SECURITY ANALYSIS OF THE SMART GRID 

7.1 Scope 

7.2 Evident and Specific Cyber Security Problems 

7.3 Nonspecific Cyber Security Issues 

7.4 Design Considerations 

7.5 References 

CHAPTER 8 RESEARCH AND DEVELOPMENT THEMES FOR CYBER SECURITY IN THE SMART GRID 


8.2 Device-Level Topics—Cost-Effective Tamper-Resistant Device Architectures 

8.3 Cryptography and Key Management 

8.4 Systems-Level Topics - Security and Survivability Architecture of the Smart Grid 

8.5 Networking Topics 

8.6 Other Security Issues in the Smart Grid Context 

CHAPTER 9 OVERVIEW OF THE STANDARDS REVIEW 

9.1 Objective 

9.2 Review Process 

9.3 NIST CSWG Standards Assessment Template. 

9.4 Standards Review List 

CHAPTER 10 KEY POWER SYSTEM USE CASES FOR SECURITY REQUIREMENTS 

10.1 Use Case Source Material 

10.2 Key Security Requirements Considerations. 

10.3 Use Case Scenarios 

APPENDIX F LOGICAL ARCHITECTURE AND INTERFACES OF THE SMART GRID 

F.1 Advanced Metering Infrastructure 

F.2 Distribution Grid Management 

F.3 Electric Storage 

F.4 Electric Transportation 

F.5 Customer Premises 




F.6 Wide Area Situational Awareness 

APPENDIX G ANALYSIS MATRIX OF LOGICAL INTERFACE CATEGORIES. 

APPENDIX H MAPPINGS TO THE HIGH-LEVEL REQUIREMENTS 

H.1 R&D Topics 

H.2 Vulnerability Classes 

APPENDIX I GLOSSARY AND ACRONYMS 

APPENDIX J SGIP-CSWG MEMBERSHIP 


http://www.nist.gov/public_affairs/releases/nist-finalizes-initial-set-of-smart-grid-cyber-security-guidelines.cfm 

http://csrc.nist.gov/publications/nistir/ir7628/nistir-7628_vol1.pdf 



http://www.cert-devoteam.fr/articles/CERT-DVT-135-0910_IR7628.pdf 

NIST - SP800-135 ' RECOMMENDATION FOR EXISTING APPLICATION-SPECIFIC KEY DERIVATION FUNCTIONS’ 

Publiée pour commentaire par le NIST, cette courte recommandation - 25 pages – détaille 

les procédés normalisés permettant à une application de calculer une clef cryptographique à 

partir d’une information secrète généralement partagée par toutes les entités en relation. Ce processus, dit 

de ‘dérivation’ ou de ‘diversification’ selon les écoles, s’avère être bien pratique s’agissant d’assurer la 

distribution des clefs entre plusieurs entités toutes susceptibles d’entrer en communication deux à deux. 

En effet, dans un système de communication utilisant une cryptographie à clefs secrètes comportant ‘n’ 

correspondants, chaque correspondant devra conserver les clefs des (n-1) autres correspondants s’il veut 

assurer une protection distincte pour chacun des correspondants. Un cas de figure qui conduira le centre 

de gestion des clefs à devoir distribuer, et gérer, n*(n-1)/2 clefs. 

Un schéma simplificateur consisterait à distribuer une unique clef – dite ‘clef maitre’ ou ‘clef partagée’ - à 

l’ensemble des correspondants en leur donnant comme consigne d’utiliser une clef de travail générée à 

partir de la clef maitre et de paramètres spécifiques constants, ou résultant d’un échange préalable. De la 

manière dont sera opérée la génération de cette clef de travail dépendra la robustesse de la protection 

contre un tiers externe au système. 

Deux méthodes de mise à la clef s’appuyant sur un schéma cryptographique à clefs publiques ont été 

normalisées par le NIST en 2007 et 2009 respectivement. Celles-ci se différencient par le schéma utilisé: 

- une cryptographie basée sur le problème du logarithme discret pour la méthode décrite dans le SP800- 

56A ‘Recommendation for Pair-Wise Key Establishment Schemes Using Discrete Logarithm 

Cryptography’ – approche Diffie-Hellman pour faire simple, 

- une cryptographie basée sur le problème de la factorisation d’un nombre premier en ce qui concerne la 

méthode exposée dans SP800-56B ‘Recommendation for Pair-Wise Key Establishment Schemes Using 

Integer Factorization Cryptography’ – approche RSA. 

Une troisième méthode est décrite dans le guide SP800-56C ‘Recommendation for Key Derivation through 

Extraction-then-Expansion’ tout juste publié pour commentaire. Elle utilise un processus de dérivation 

combinatoire désigné par les opérations employées - Extraction et Expansion ou ‘E-E’ - et fait appel à une 

fonction ‘pseudo-aléatoire’ dont le NIST recommande qu’elle soit sélectionnée conformément aux 

recommandations du guide SP800-108 ‘Recommendation for Key Derivation Using Pseudorandom 

Functions’. 

Le guide SP800-135 ‘Recommendation for Existing Application-Specific Key Derivation Functions’ décrit 

les fonctions de dérivation utilisées par les applications fondamentales de l’Internet en classant celles-ci en 

deux catégories: les fonctions s’appuyant sur un processus conforme au guide SP800-56C et donc aux 

recommandations du SP800-108, et les autres fonctions. 

Les procédés utilisés par les protocoles IKE (Echange de clef sur Internet) et TLS (Transport Sécurisé) 

appartiennent à la première catégorie. Ceux spécifiés par les standards ANSI X9.42, X9.63 mais aussi 

utilisés par les protocoles SSH (Interpréteur de commande sécurisé), SRTP (Transmission de données 

temps réel sécurisé), SNMPv3 ou encore par le module TPM appartiennent à la seconde catégorie. 

Le sommaire du SP800-135 est le suivant: 

1 Introduction 

2 Authority 

3 Glossary of Terms, Acronyms and Mathematical Symbols 

3.1 Terms and Definitions 

3.2 Acronyms 

3.3 Symbols & Mathematical Operations 

4 Extraction-then-Expansion (E-E) Procedure 

4.1 Internet Key Exchange (IKE) 

4.1.1 IKE version 1 (IKEv1) 

4.1.2 IKE version 2 (IKEv2) 




4.2 Key Derivation in Transport Layer Security (TLS) 

4.2.1 Key Derivation in TLS versions 1.0 and 1.1 

4.2.2 Key Derivation in TLS version 1.2 

5 Other Existing Key Derivation Functions 

5.1 Key Derivation Functions in American National Standards (ANS) X9.42-2001 and ANS X9.63-2001 

5.2 Secure Shell (SSH) Key Derivation Function 

5.3 The Secure Real-time Transport Protocol (SRTP) Key Derivation Function 

5.4 Simple Network Management Protocol (SNMP) Key Derivation Function/Key Localization Function 

5.5 Trusted Platform Module (TPM) Key Derivation Function 

6 References 

Cette recommandation est particulièrement intéressante. Elle met en évidence la structuration élégante et 

la cohérence de la construction proposée par le NIST: un ensemble de recommandations s’appuyant sur 

des procédés bien identifiés, et organisés, utilisant eux-mêmes des briques élémentaires par ailleurs 

normalisées et ayant fait leurs preuves. 


http://csrc.nist.gov/publications/drafts/800-135/draft-sp800-135.pdf - SP800-135 

http://csrc.nist.gov/publications/drafts/800-132/draft-sp800-132_june2010.pdf - SP800-132 

http://csrc.nist.gov/publications/nistpubs/800-108/sp800-108.pdf - SP800-108 

http://csrc.nist.gov/publications/nistpubs/800-56A/SP800-56A_Revision1_Mar08-2007.pdf - SP800-56A 

http://csrc.nist.gov/publications/nistpubs/800-56B/sp800-56B.pdf - SP800-56B 

http://csrc.nist.gov/publications/drafts/800-56C/draft-SP800-56C.pdf - SP800-56C 


ANSSI – CATALOGUE DES PRODUITS QUALIFIES – MISE A JOUR 

Le catalogue des produits qualifiés par l’ANSSI a fait l’objet d’une mise à jour. Ce catalogue 

recense les produits dits d’usage général en cours de qualification, ou ayant été qualifiés 

conformément aux processus décrits dans le Référentiel Général de Sécurité (RGS). 

Cette mise à jour porte sur: 

- La certification EAL3+ au niveau de qualification dit ‘Standard’ du produit de protection du poste de 

travail ‘Zed!’ de la société PrimX, 

- La publication du niveau de certification (EAL5+) de la carte SAGEM ‘Ideal Citiz’. 

Le produit de signature ‘TrustySign’ proposé par la société CS a été annoncé certifié EAL3+ dans un 

communiqué de presse publié mi-septembre. Il n’apparaît pas encore au catalogue de l‘ANSSI. 

Editeur Produit Certification Qualification Cat. 

ARKOON Fast Firewall v3.0/11 EAL2+ 11/04 Standard 12/04 3 

Security Crypto Box v6.0 EAL4+ élevé 05/04 Standard 07/04 5 & 6 

Security Box Enterprise 7.2 EAL3+ visé - En cours - 5 

BULL Trustway PCI S302 EAL4+ élevé 11/04 Standard 01/05 6 & 7 

Trustway PCI S507 et S709 EAL4+ 03/10 Renforcé 04/10 6 & 7 

TrustWay VPN v3.01.06 EAL2+ 09/04 Standard 09/04 2 

TrustWay VPN Line EAL2+ 04/09 Standard 04/09 2 

CdC Fast Signature v1.1 EAL2+ 12/08 Standard 12/08 7 

DICTAO Adsignerweb v3.1.800 EAL3+ 04/06 Standard 05/06 7 

Validation Server v4.0.6 EAL3+ 09/07 Standard 09/07 7 

Digimedia Scrutalys EAL3+ visé - En cours - 7 

EdenWall tech. Edenwall 4 EAL3+ visé - En cours - 3 

ERCOM SecPhone EAL2+ 12/05 Standard 12/05 6 & 9 

Exaprotect ExaProtect Sec. Manag. V2.7.3.5 EAL2+ 11/08 Standard 12/08 1 

FT Applatoo EAL2+ 04/05 Standard 05/05 7 

GEMALTO ePassport Sealys EAC v1.1 EAL4+ 12/08 Renforcé 08/09 8 

eTravel EAC v1.0 EAL4+ 12/08 Renforcé 08/09 8 

MultiApp IAS ECC EAL4+ 02/10 Renforcé 03/10 6 

Keynectis Sequoia EAL4+ visé - En cours - 4 

NETASQ NETASQ IPS v5 EAL2+ 03/05 Standard 03/05 2 & 3 

IPS Firewall 8.0.1.1 EAL3+ 07/09 Standard 03/05 2 & 3 

Oberthur Tec. ID One ePASS v2.1 EAL4+ 08/09 Renforcé 07/09 8 

ID One ePass 64 v2.0 EAL4+ 05/08 Renforcé 08/09 8 

PrimX ZoneCentral v3.1 EAL2+ 12/08 Standard 12/08 5 

ZED! EAL3+ 07/10 Standard 08/10 5 M 

SAGEM Carte Morpho-Citiz32 sur Atmel EAL4+ Standard 02/08 6 

Carte Morpho-Citiz32 sur NXP EAL4+ Standard 02/08 6 




Morpho ePass V3 EAL4+ 07/08 Renforcé 08/09 8 

Morpho ePass V1.1.0 EAL4+ 07/09 Renforcé 09/09 8 

Ideal Citiz EAL5+ 04/10 Renforcé 05/10 6 M 

Smart Quantum SQDefender EAL3+ visé 09/08 En cours - 10 

THALES Mistral v4.5.2.2 EAL3+ 05/05 Standard 06/05 2 

Mistral 2 v4.6.1 EAL3+ 03/08 Standard 03/08 2 

Mistral 3 v4.6.2 EAL3+ 07/08 Standard 09/08 2 

Catégories : 1- Administration de la sécurité 4- IGC 7- Signatures et Preuves 

2- Chiffrement IP 5- Protection du Poste de Travail 8- Titres d’identité électroniques 

3- Firewall 6- Ressources Cryptographiques 9- Voix sécurisée 

10- Chiffrement de liens 


http://www.ssi.gouv.fr/site_rubrique52.html - Catalogue 

http://www.c-s.fr/Le-produit-TRUSTYSIGN-de-CS-evalue-Criteres-Communs-niveau-EAL3_a350.html 

APPLE – GUIDE DE SECURISATION MACOS X 10.6 

Apple publiait en mai dernier deux guides de sécurisation consacrés à la dernière version du 

système d’exploitation MacOS X, la version 10.6 dite ‘Snow Leopard’. Le premier guide (456 

pages) est consacré à la sécurisation de la version serveur du système d’exploitation. Il intéressera 

donc plus particulièrement les équipes en charges de la sécurisation des systèmes de production. Le 

second guide (272 pages), qui traite de la problématique de la sécurisation de l’équipement de l’utilisateur 

final, vient d’être référencé dans le catalogue des guides de sécurité maintenu par le SNAC, le service de 

la NSA en charge de la gestion des incidents systèmes et réseaux. 

Ce document très complet guide l’utilisateur d’un système Mac désireux de renforcer la sécurité de son 

environnement de travail en détaillant chacune des opérations devant être menée et en illustrant celles-ci 

d’une copie des écrans de configuration. Ces guides rejoindront, si cela n’est déjà fait, la bibliothèque de 

référence de tout exploitant d’un système d’information accueillant des équipements – postes ou serveurs 

– Apple. 

Le sommaire du guide de sécurisation de la version utilisateur est le suivant: 

Preface 

Chapter 1 - Introduction to Mac OS X Security Architecture 

Security Architectural Overview 

What’s New in Snow Leopard v10.6 

Existing Security Features in Snow Leopard 

Signed Applications 

Mandatory Access Controls 

Enhanced Quarantining 

Application-Based and IP Firewalls 

Memory and Runtime Protection 

Chapter 2 - Installing Mac OS X 

System Installation Overview 

Initial System Setup 

Chapter 3 - Securing System Hardware 

Protecting Hardware 

Preventing Wireless Eavesdropping 

Understanding Wireless Security Challenges 

About OS Components 

Chapter 4 - Securing Global System Settings 

Securing System Startup 

Protecting Intel-Based Mac Systems 

Configuring Access Warnings 

Chapter 5 - Securing System Preferences 

System Preferences Overview 

Securing MobileMe Preferences 

Securing Accounts Preferences 

Securing Appearance Preferences 

Securing Bluetooth Preferences 

Securing CDs & DVDs Preferences 

Securing Date & Time Preferences 

Securing Desktop & Screen Saver Preferences 

Securing Display Preferences 

Securing Dock Preferences 

Securing Energy Saver Preferences 

Securing Exposé & Spaces Preferences 

Securing Language & Text Preferences 

Securing Keyboard Preferences 

Securing Sharing and Collaborative Services 

Improved Cryptography 

Extended Validation Certificates 

Wildcard in Identity Preferences 

Enhanced Command-Line Tools 

FileVault and Encrypted Storage 

Enhanced Safari 4.0 Security 

Updating System Software 

Repairing Disk Permissions 

Preventing Unauthorized Recording 

Preventing Data Port Access 

System Hardware Modifications 

Enabling Access Warnings for the Command Line 

Turning On File Extensions 

Securing Mouse Preferences 

Securing Network Preferences 

Securing Managed User Accounts Preferences 

Securing Print & Fax Preferences 

Securing Security Preferences 

Securing System Swap and Hibernation Storage 

Securing Sharing Preferences 

Securing Software Update Preferences 

Securing Sound Preferences 

Securing Speech Preferences 

Securing Spotlight Preferences 

Securing Startup Disk Preferences 

Securing Time Machine Preferences 

Securing Universal Access Preferences 



Chapter 6 - Securing Accounts 

Types of User Accounts 

Securing the Guest Account 

Securing Nonadministrator Accounts 

Securing Administrator Accounts 

Securing the System Administrator Account 

Chapter 7 - Securing Data and Using Encryption 

Understanding Permissions 

Setting POSIX Permissions 

Setting File and Folder Flags 

Setting ACL Permissions 

Changing Global omask for Stricter Default Perm. 

Restricting Setuid Programs 

Securing User Home Folders 

Chapter 8 - Securing Applications 

Protecting Data While Using Apple Applications 

Setting Mail Security 

Setting Web Browsing Security with Safari 

Using Instant Message Security with iChat 

Chapter 9 - Securing Network Services 

Securing Internet com with Host-Based Firewalls 

Protecting Data While Using Apple Services 

Securing Bonjour (mDNS) 

Securing the Back to My Mac (BTMM) Service 

Securing Network Sharing Services 

DVD or CD Sharing 

Screen Sharing (VNC) 

File Sharing (AFP, FTP, and SMB) 

Printer Sharing (CUPS) 

Chapter 10 - Advanced Security Management 

Managing Authorization Through Rights 

Understanding the Policy Database 

Managing Authorization Rights 

Maintaining System Integrity 

Validating File Integrity 

Using Digital Signatures 

Appendix A - Security Checklist 

Installation Action Items 

Hardware Action Items 

Global System Action Items 

System Preferences Action Items 

Account Configuration Action Items 

Appendix B - Security Scripts 



Understanding Directory Domains 

Using Strong Authentication 

Setting Global Password Policies 

Storing Credentials 

About Certificates 

Encrypting Home Folders 

Encrypting Portable Files 

Securely Erasing Data 

Securing Guest OSes with Boot Camp 

Understanding the Time Machine Architecture 

Storing Backups Inside Secure Storage 

Restoring Backups from Secure Storage 

Enhancing Multimedia Security with iTunes 

Setting Photo Sharing Security with iPhoto 

Setting Contact Sharing Security with Address Book 

Strengthening Data Security with MobileMe 

Scanner Sharing 

Web Sharing (HTTP) 

Remote Login (SSH) 

Remote Management (ARD) 

Remote Apple Events (RAE) 

Xgrid Sharing 

Internet Sharing 

Bluetooth Sharing 

Understanding and Managing Daemons and Agents 

Using Activity Analysis Tools 

Validating System Logging 

Auditing System Activity 

Using Antivirus Tools 

Using Intrusion Detection Systems 

Encryption (DAR) Action Items 

Application Action Items 

Services Action Items 

Advanced Management Action Items 

http://images.apple.com/support/security/guides/docs/SnowLeopard_Security_Config_v10.6.pdf 

http://images.apple.com/support/security/guides/docs/SnowLeopard_Server_Security_Config_v10.6.pdf 

DISA – SUPPORTS DE STOCKAGE AMOVIBLES 

L’agence pour les systèmes d’information de la défense, la DISA, vient de publier un guide de 

prescriptions de sécurité adaptées aux supports de stockages amovibles et, plus largement, aux 

technologies de connexion de périphériques tiers; dans les faits, les connexions USB. Ce guide, 

intitulé ‘Removable Storage and External Connection Technologies’, est livré sous la forme 

d’un fichier d’archive, un paquetage, contenant trois documents dont un détaillant l’historique des 

évolutions. 

Le premier document, ‘Overview’, propose une très intéressante synthèse des problèmes posés par la 

commercialisation de périphériques amovibles intelligents, performants et d’un prix très abordable, 

autorisant le stockage de gros volumes de données, voire leur traitement, dans un encombrement réduit 

à l’extrême. Un succès notamment dû à la présence sur toutes les machines récentes d’interfaces 

autorisant le raccordement de périphériques, et leur alimentation, à chaud, c.-à-d. sans avoir à 

réinitialiser le poste de travail : interface sans fil Bluetooth, bus Firewire mais aussi et surtout, bus 

USB. Bien qu’applicables à tous ces supports de connexion, les prescriptions de la DISA traitent plus 

particulièrement du contrôle de l’usage des périphériques USB, dispositifs de loin les plus nombreux sur le 

marché. Une situation qui s’explique par les évolutions successives de ce bus – USB V1, USB V2 et 

désormais USB V3 – qui ont permis d’améliorer le taux de transfert et d’enrichir la panoplie des 

fonctionnalités offertes à l’usager. Parmi celles-ci, la définition de classes d’utilisation, et des interfaces 

programmatiques associées, qui permettent d’automatiser la reconnaissance d’un périphérique, et 




d’inscrire automatiquement celui-ci dans la liste des ressources actives du système. A ce jour, quelques 

19 classes ont été spécifiées par le consortium en charge de la spécification USB dont les classes ‘Audio’ 

(périphérique audio), ‘Image’ (caméras et appareils photo), ‘Printer’ (Imprimantes), ‘Mass Storage’ 

(Stockage de données), ‘Wireless Controller’ (Interface réseau sans fil), ‘Smard Card’, ‘Personnal 

Healthcare’ ou encore ‘Human Interface Device’ dit ‘HID’. 

Cette dernière classe de périphériques est particulièrement intéressante car elle englobe tous les 

périphériques de saisie usuels d’un système, le clavier, la souris, la manette de jeu mais aussi certains 

canaux de communication auxiliaires tels que les interfaces de contrôle des onduleurs, des téléphones ou 

encore des systèmes multimédia. La simple insertion d’un périphérique USB s’annonçant avec un 

identifiant de classe HID dans le port USB d’un système récent va automatiquement activer un processus 

destiné à connecter les interfaces d’entrée/sortie du périphérique au gestionnaire approprié au type 

annoncé par ce périphérique, un clavier par exemple. Une fonctionnalité certes remarquable sur le plan de 

l’ergonomie et de la facilité d’utilisation – aucun gestionnaire de périphérique à charger – mais qui pourra 

être exploitée avec succès à des fins détournées, par exemple pour capturer les données saisies sur le 

périphérique principal en s’insérant dans la chaîne de traitement, ou encore pour transmettre des 

commandes sur un système industriel dont le clavier aurait simplement été déconnecté. 

Un excellent exemple de détournement de cette fonctionnalité a d’ailleurs été présenté cette année lors 

de l’édition USA de la conférence BlackHat par Richard Rushing dans une présentation intitulée ‘USB - 

HID, The Hacking Interface Design’. L’auteur y démontre la facilité avec laquelle un bricoleur pourra, sans 

être un génie de l’électronique et de la programmation, réaliser pour un investissement dérisoire (une 

dizaine d’euro tout au plus) un dispositif permettant d’exécuter, après connexion et sans autre action, des 

commandes sur le système Windows cible. Ce dispositif utilise une minuscule carte de développement 

commercialisée sur Internet offrant une interface USB ainsi que la librairie HID ad hoc. Quelques 

secondes après que l’interface soit connectée, une fonction développée sur mesure transmet la séquence 

des codes claviers requise pour ouvrir la fenêtre ‘Exécuter’, lancer l’interpréteur de commande ‘cmd.exe’ 

puis enfin passer une série de commandes sous l’autorité du compte actif. 

Deux autres fonctionnalités sont susceptibles de poser quelques problèmes de sécurité: 

- la spécification ‘On the GO’ ou ‘OTG’, une 

extension de la spécification USB 2.0, qui décrit les 

fonctionnalités permettant à un périphérique USB 

2.0 d’activer une association avec un autre 

périphérique comme le ferait un contrôleur USB. 

Cette fonctionnalité, que l’on trouvera intégrée à 

certains disques amovibles intégrant une batterie, 

permet d’assurer la recopie de données, pour 

sauvegarde par exemple, d’un périphérique à 

l’autre sans avoir à recourir à un ordinateur. 

Utilisée à mauvais escient, elle permettra de copier 

rapidement, et en toute discrétion, le contenu de 

tout équipement de stockage disposant d’une 

interface USB: clef, disque mais aussi caméra, 

appareil photo numérique ou téléphone portable. 

- la spécification dite ‘U3’ proposée par la société U3 LLC. qui décrit l’intégration d’un système de fichier 

au format ISO 9660 – le format des CD-ROM – déclaré en lecture seule et contenant un fichier de 

démarrage automatique, ‘autorun.inf’ ainsi qu’un système de menu permettant de sélectionner 

l’application à exécuter parmi les applications présentes sur le support. Cette fonctionnalité semble ne 

pas avoir eu le succès attendu, pas plus que l’alternative, Startkey, proposée par Microsoft. Le niveau 

de sécurité de cette approche a été remis en cause par quelques publications prouvant qu’il était 

possible de recharger le firmware de certaines clefs et ainsi de changer le contenu du disque pourtant 

censé être inaltérable. 

La DISA rappelle qu’en 2008 le Département de la Défense américain suspendait l’autorisation d’utiliser 

en environnement Windows les supports de données amovibles utilisant la technologie ‘Flash’. Cette 

interdiction faisait suite aux nombreux problèmes de sécurité – propagation de codes malveillants mais 

aussi fuites d’informations sensibles - auxquels le DoD se retrouvait confronté avec la démocratisation de 

cette technologie. Depuis, cette règle s’est très légèrement assouplie, le DoD admettant un usage limité 

et strictement encadré des supports de données amovibles dans le contexte d’opérations spécifiques en 

relation avec le système d’information global de la défense dit ‘Global Information Grid’ ou ‘GIG’. 

Le second document, ‘STIG’, contient la liste des prescriptions applicables à ces dispositifs. Ce document 

est fourni au format XML, comme c’est désormais le cas des mises à jour, et des nouveaux guides, de la 

DISA. L’objectif annoncé est de faciliter l’intégration des prescriptions énumérées par ces documents au 

sein de l’environnement de description unifié dit ‘XCCDF’ (eXtensible Configuration Checklist Description 

Format) lequel a été conçu pour être utilisé par les outils d’automatisation développés dans le cadre du 




projet SCAP (Security Content Automation Protocol) (Rapport N°130 – Mai 2009). 

La visualisation des documents XCCDF s’effectuera 

donc à travers un navigateur Internet, le fichier de 

transformation XSL étant livré dans le paquetage. 

Le référencement des documents en fonction de leur 

usage – STIG pour les Guides et CheckList pour les 

listes de contrôle – n’a plus de raison d’être et 

disparaitra donc au fur et à mesure de la mise à jour 

du référentiel documentaire. 

Cette évolution engagée il y a maintenant quelques 

mois transparaissait déjà dans le tableau de 

synthèse que nous mettons à jour après chaque 

nouvelle publication. 

On notera par ailleurs que les documents d’accompagnement au format WORD référencés par les guides 

dans leur ancienne version ne seront plus livrés. Nous convions nos lecteurs désireux d’en savoir plus à se 

reporter au document intitulé ‘STIG Transition to XCCDF’ dont un exemplaire est intégré à chaque 

paquetage. 

Chaque prescription de la DISA porte une identification unique. Elle précise le niveau de sécurité traité 

conformément à l’échelle définie par le DoD qui comporte trois niveaux: 

- 1: vulnérabilités offrant un accès immédiat sur une machine, un accès à un compte privilégié ou le 

contournement d’un pare-feu, 

- 2: vulnérabilités fournissant de l’information susceptible d’être exploitée pour obtenir un accès avec une 

haute probabilité, 

- 3: vulnérabilités fournissant de l’information susceptible de conduire à la compromission du système. 

Au total, 20 prescriptions sont ainsi définies dans la version actuelle du guide ‘Removable Storage and 

External Connection Technologies’ que nous reproduisons ci-dessous pour information: 8 prescriptions 

applicables aux applications de gestion de ces périphériques, 6 prescriptions d’ordre organisationnel, et le 

reste aux dispositifs. 

STO-ALL-010 Require approval prior to allowing use of portable storage devices. 

STO-ALL-020 Permit only government-procured and -owned devices. 

STO-ALL-030 Maintain a list of approved removable storage media or devices. 

STO-ALL-040 

STO-ALL-050 

STO-ALL-070 

STO-DRV-005 

STO-DRV-010 

STO-DRV-020 

STO-DRV-021 

STO-DRV-025 

STO-DRV-030 

STO-DRV-040 

STO-DRV-060 

STO-FLSH-010 

Set boot order of computers approved for use with removable storage such that the BIOS 

does not allow default booting from devices attached to a USB, firewire, or eSATA port. 

Train all users on the secure use of removable media and storage devices, acceptable use 

policy, and approval process through use of user's guide, user's agreement, training program. 

The host system will perform on-access anti-virus and malware checking, regardless of 

whether the external storage or flash drive has software or hardware malware features. 

DoD components will purchase removable storage media and Data at Rest (DAR) products 

from the DoD Enterprise Software Initiative (ESI) blanket purchase agreements program. 

Access to mobile and removable storage devices such as USB thumb drives and external hard 

disk drives will be protected by password, PIN, or passphrase. 

Encrypt sensitive but unclassified data when stored on a USB flash drive and external hard disk 

drive. 

Use an NSA-approved, Type 1 certified data encryption and hardware solution when storing 

classified information on USB flash media and other removable storage devices. 

Configure the cryptographic module on a USB thumb drive or external hard drive using a NISTapproved 

encryption algorithm to encrypt sensitive or restricted data-at-rest. 

For all USB flash media (thumb drives) and external hard disk drives, use an approved method 

to wipe the device before using for the first-time. 

Firmware on the USB flash drive and external hard drive will be signed and verified with either 

Hashed Message Authentication Code (HMAC) or digital signatures. 

Removable storage devices for which the organization has failed to maintain physical control 

will be scanned for malicious activity upon reclamation. 

Data transfers using USB flash media (thumb drives) will comply with the requirements in the 

CTO 10-004(A or most recent version) and these procedures will be documented. 

STO-FLSH-020 Maintain a list of all personnel that have been authorized to use flash media. 

STO-FLSH-030 Maintain a list of all end point systems that have been authorized for use with flash media. 

STO-FLSH-040 

Install and configure Host-Based Security System (HBSS) with Device Control Module (DCM) 

on all Windows host computers that will use USB flash media (thumb drives). 

STO-FLSH-050 For end points using Windows operating systems, USB flash media will be restricted by a 



STO-FLSH-060 

STO-FLSH-070 


specific device or by a unique identifier (e.g., serial number) to specific users and machines. 

Organizations that do not have a properly configured HBSS with DCM configuration will not use 

flash media. 

For higher risk data transfers using thumb drives, use the File Sanitization Tool (FiST) with 

Magik Eraser (ME) to protect against malware and data compromise. 

USB-WUSB-010 For Wireless USB (WUSB) devices, comply with the Wireless STIG peripheral devices policy. 

Nos lecteurs n’auront pas manqué de noter le référencement de deux outils, l’un dit ‘File Sanitization 

Tool’ assurant la stérilisation du support et l’autre, ‘Magik Eraser’, son effacement. Ces outils semblent 

avoir été spécialement développés pour le DoD par la société commerciale Tresys Technology. 

Le sommaire du document d’accompagnement de 14 pages publié est le suivant: 

1. INTRODUCTION 

1.1 Background 

1.2 Authority. 

1.3 Scope. 

1.4 Vulnerability Severity Code Definitions 

1.5 STIG Distribution 

1.6 Document Revisions 

2. TECHNOLOGY OVERVIEW 

2.1 USB Devices 

2.1.1 USB Standards 

2.1.2 USB Compliance Testing 

2.2 Volatile and Persistent Memory Devices 

2.3 Flash Media Use in DoD 

2.4 Performing a Security Assessment 


http://iase.disa.mil/stigs/downloads/zip/unclassified_removable_storage_extl_%20conn_tech_v1r1_stig.zip 

http://www.cert-devoteam.fr/articles/CERT-DVT-130-0509_SCAP.pdf 

DISA – STIG MEDICAL DEVICES 

La directive ‘Information Assurance 8500.1’ du département américain de la défense – DoD 

– stipule que la configuration de tous les dispositifs de protection de l’information - dits ‘IA 

products’ - (pare-feux, anti-virus, IDS...), ou intégrant un mécanisme de protection - dits ‘IAenabled 

products’ - (systèmes d’exploitation, applications, bases de données, routeurs…), doit 

être conforme aux spécifications décrites dans les guides de configuration édités par l’agence pour les 

systèmes d’information de la défense, la DISA. La sécurité à long terme du système d’information est 

assurée par la mise en place d’un programme de gestion des vulnérabilités, dit ‘Information Assurance 

Vulnerability Management’ ou IAVM. 

Une analyse récemment menée par le DoD a mis en évidence la non-conformité des matériels médicaux 

utilisés dans les unités médicales placées sous le commandement du service de santé de la défense, le 

MHS (Military Health Systems), notamment en ce qui concerne la conformité au programme de gestion 

des vulnérabilités quand pourtant un nombre croissant de ces matériels sont interconnectés directement, 

ou par le biais de connections sans fil, à des réseaux IP, dont certains publics. La mise à jour des logiciels 

embarqués dans ces équipements s’avère être très problématique au regard du contexte de leur 

d’utilisation, et de l’impact que pourrait avoir un quelconque problème sur la santé des patients. 

L’administration américaine des denrées alimentaires et des médicaments, la célèbre ‘Food & Drugs 

Administration’ ou FDA, impose comme ses homologues dans d’autres pays une procédure de certification 

draconienne visant à vérifier que les équipements réagissent comme ils le doivent sans risquer de mettre 

en péril la vie des usagers. La décision d’appliquer un correctif, le plus anodin soit-il, ne pourra donc être 

prise sans l’aval préalable de la FDA, avec les conséquences que l’on imagine sans peine sur le délai de 

mise en application. Il est des cas où l’application d’un correctif ne pourra même pas être envisagée, le 

matériel ou le logiciel embarqué dans celui-ci étant obsolète depuis longtemps. La DISA indique à ce 

sujet que plusieurs vendeurs ont explicitement indiqué que certains de leurs matériels ne pourront être, 

et ne seront jamais, compatibles avec les exigences du programme de gestion IAVM. Une prise de 

position qui n’a rien d’étonnant au regard du nombre d’équipements produits ces quinze dernières 

années, et encore en usage, quand le système d’exploitation qui les anime n’est plus supporté depuis 

plusieurs années: moniteur cardiaque utilisant une version allégée du système Windows 95 ou 98, 

système d’imagerie s’appuyant sur un système temps réel dédié… Les exemples sont probablement légion 

en particulier s’agissant d’équipements projetables ou spécifiques. 

La stricte application des règles de sécurité du DoD interdit la connexion de ces équipements au réseau 

d’information global de la défense, Global Information Grid ou GiG, sauf à justifier de l’application d’une 

stratégie de réduction du risque. Le guide de sécurisation dédié à ces équipements que vient de publier la 




DISA décrit par le détail les aménagements devant être apportés à la structure du système d’information, 

dont principalement l’infrastructure de communication, pour répondre aux exigences de protection. Les 

stratégies d’isolation et de filtrage des flux, considérées par certains comme inutiles dans le contexte de 

systèmes d’information récents, reprennent ici tout leur intérêt en permettant la création d’enclaves 

accueillant les équipements non-conformes IAVM ou dont la conformité avec les exigences IAVM est 

inconnue. Cette dernière catégorie regrouperait d’après la DISA la majorité des matériels médicaux 

communicants du service de santé de la défense. 

Le sommaire du guide de 56 pages publié par la DISA est le suivant: 

1. INTRODUCTION 

2. MEDICAL DEVICE OVERVIEW 


2.2 Medical Device Class 

2.2.1 Class I 

2.2.2 Class II 

2.2.3 Class III 

3. NETWORKED MEDICAL DEVICES 


3.2 Networked Medical Devices Life Cycle 

3.2.1 Networked Medical Device Procurement 

3.2.2 Inventory 

3.2.3 Device Classification 

3.2.4 Device Accreditation 

3.2.5 Networked Medical Device Configuration Control 

3.2.6 Networked Medical Device Vulnerability Management 

3.2.7 Incident Response 

3.2.8 Maintenance 

3.2.9 Disposal 

4. NETWORKED MEDICAL DEVICES IN MILITARY HEALTH TREATMENT FACILITIES 

4.1 Networked Medical Device IAVM Types 

4.2 Networked Medical Device VLAN Separation 

4.2.1 Virtual Local Area Network (VLAN) 

4.3 Networked Medical Device Security Zone 

4.4 Screened Subnet 

4.5 Networked Medical Device Architecture Security Settings 

4.5.1 VLAN Security Settings 

4.5.2 Access Control Lists (ACLs) 

4.5.3 Networked Medical Device Intrusion Detection/Prevention System 

4.5.4 Port Security for VLAN-Separated Medical Device Segments 

5. NETWORKED MEDICAL DEVICE MANAGEMENT AND MAINTENANCE 

5.1 Internally Supported Devices 

5.1.1 Out-of-Band Management 

5.1.2 In-Band Management 

5.2 Externally Supported Devices 

5.3 Authentication 

6. NETWORKED MEDICAL DEVICE SECURITY 

6.1 Device Configuration 

6.1.1 Device Settings 

6.1.2 Networked Medical Device Security Settings 

6.2 Wireless 

APPENDIX A. RELATED PUBLICATIONS 

APPENDIX B. GLOSSARY OF TERMS 

APPENDIX C. LIST OF ACRONYMS 

APPENDIX D. MEDICAL DEVICE SPECIALITIES 


http://iase.disa.mil/stigs/stig/medical_devices_stig_memo.pdf 

http://iase.disa.mil/stigs/stig/unclassified_medical_device_stig_27July2010_v1r1FINAL.pdf 

STANDARDS 

RFC5991 - TEREDO SECURITY UPDATE 

Co-édité par D.Thaler (Microsoft), S.Krishnan (Ericsson) et J.Hoagland (Symantec), ce document décrit 

les modifications apportées à la définition du rôle d’un champ de bits intégré dans chacune des adresses 

IPV6 utilisée par Teredo. Cette modification des spécifications n’impactera pas les implémentations 

actuelles qui utilisent la spécification décrite dans le RFC4380 ‘Teredo: Tunneling IPv6 over UDP through 




Network Address Translations (NATs)’. 

Rappelons que le protocole Teredo, spécifié par Christian Huitema, autorise l’accès à des systèmes 

adressés en IPV6 par le biais de systèmes IPV4 ou IPV6 disposant d’un accès sur un réseau de transport 

IP V4, soit en pratique la majorité des accès Internet actuels. Les paquets IPV6 sont pour cela encapsulés, 

non pas dans un paquet IPV4 comme cela est le cas du mécanisme 6to4, mais dans un paquet UDP qui 

pourra alors être routé à travers l’Internet par tout équipement de raccordement offrant une fonction de 

translation d’adresse (NAT). 

Un poste de travail disposant d’un client Teredo offrant une interface réseau spécifique dotée d’une 

adresse IPV6 unique mais respectant un format bien défini. Les paquets IPV6 seront gérés par cette 

interface qui assurera leur insertion ou extraction des datagrammes UDP transportés entre le client et un 

équipement tiers public ou privé – un relais ou un serveur Teredo – assurant l’interface avec le réseau 

IPV6 cible. 

Teredo est nativement intégré dans le système d’exploitation Windows depuis la version XP SP2 mais 

devra toutefois être explicitement activé à l’exception de l’environnement Vista. Pour la petite histoire, la 

configuration fournie par Microsoft référence le serveur ‘teredo.ipv6.microsoft.com’ lequel, longtemps 

inaccessible, fût la cause d’une pollution des intranets par les nombreuses requêtes transmises par les 

postes de travail sous Vista. L’un des plus gros fournisseurs d’accès Teredo, hors Microsoft, est encore 

probablement l’opérateur Américain Hurricane Electric avec son service gratuit ‘TunnelBroker’ et ses 14 

points d’accès repartis dans le monde: Ashburn, Chicago, Dallas, Fremont, Los Angeles, Miami, New York, 

Seattle, Toronto pour le continent américain et Amsterdam, Frankfurt, Hong Kong, London, Paris pour le 

reste du monde. 

Les modifications apportées à la spécification originale visent à améliorer la robustesse de ce protocole de 

transport et d’interconnexion vis-à-vis d’attaques spécifiques exploitant certaines spécificités de la 

structure d’information intégrée à l’adresse IPV6 Teredo. Ainsi, 12 des 13 bits inutilisés de la structure de 

16 bits réservée dans l’adresse IPV6 contiendront une valeur aléatoire. Un attaquant ayant connaissance 

par un moyen, ou un autre, de l’adresse IPV4 et du numéro de port assigné au client devra encore 

déterminer l’adresse IPV6 en usage parmi les 4096 (2 12 ) adresses possibles. La première phase de la 

procédure d’établissement, laquelle autorisait l’échange de messages de contrôle préalablement à 

l’utilisation de l’adresse IPV6 Teredo, devra désormais être ignorée. Cette fonctionnalité pouvait être 

utilisée par un tiers pour profiler l’infrastructure. Ceci conduit à déprécier l’usage de l’indicateur binaire, 

dit ‘Cone Bit’, lequel devra et sera toujours transmis à 0. 

Le sommaire de cette spécification de 10 pages est le suivant: 

1. Introduction 

2. Terminology 

3. Specification 

3.1. Random Address Flags 

3.2. Deprecation of Cone Bit 

4. Security Considerations 

5. Acknowledgments 

6. References 

6.1. Normative References 

6.2. Informative References 

Appendix A. Implementation Status 

Appendix B. Resistance to Address Prediction 


http://www.rfc-editor.org/rfc/rfc5991.txt 



CONFERENCES 

BRUCON 2010 


TABLEAUX DE SYNTHESE 

La conférence technique BruCon 2010 s’est tenue les 24 et 25 septembre à Bruxelles. La 

majorité des supports des présentations sont disponibles en ligne. Voici la liste des 

présentations. 

"The Monkey Steals the Berries" The State of Mobile Security Tyler Shields 

Creating a CERT at WARP Speed: How To Fast Track the Implementation of Your CERT Brian Honan 

CsFire: browser-enforced mitigation against CSRF Lieven Desmet 

Cyber [Crime|War] - connecting the dots Ian Amit 

Embedded System Hacking and My Plot To Take Over The World Paul Asadoorian 

Finding Backdoors in Code Matias Madou 

Fireshark - A tool to Link the Malicious Web Stephan Chenette 

GSM security: fact and fiction F van den Broek 

Head Hacking – The Magic of Suggestion and Perception Dale Pearson 

How I Met Your Girlfriend Samy Kamkar 

Memoirs of a Data Security Street Fighter Mikko Hypponen 

NFC Malicious Content Sharing Roel Verdult 

Project Skylab 1.0: Helping You Get Your Cloud On Craig Balding 

The WOMBAT Project: Recent Developments in Internet Threats Analysis Thonnard, Moser 

Top 5 ways to steal a company "Forget root, I want it all" Chris Nickerson 

You Spent All That Money And You Still Got Owned... Joseph McCray 

Your Project: From Idea To Reality "Make A Living Doing What You Love" Mitch Altman 


http://2010.brucon.org/index.php/Presentations 

IETF – 78TH MEETING 

La 78 ième édition de la réunion plénière de l’IETF s’est tenue en Europe, du 25 au 30 juillet 2010 

à Maastricht, l’occasion pour les participants de plus de 98 groupes de travail de se rencontrer 

et de faire un point sur l’avancement de leurs travaux. 

Les minutes de toutes les réunions des groupes sont disponibles en ligne, accompagnées des supports de 

présentations ayant pu être faites par certains participants. Il ne nous est hélas pas possible de lister ici 

l’intégralité des documents publiés dans les 8 thèmes de travail de l’IETF (Applications, Général, Internet, 

Supervision et Management, Applications Temps réel et Infrastructure, Routage, Sécurité, et Transport). 

Nous nous restreindrons en conséquence au thème de la sécurité, et des groupes de travail associés. 

dkim Domain Keys Identified Mail 

Third-Party Authorization Label for ADSP 

emu EAP Method Update 

Channel Bindings : The train departs the Station 

EAP ID Protection 

fedauth Federated Authentication Beyond the Web 

Beyond The Web: Problem Statement and Requirements 

Eduroam Trust Management 

Introduction & use-cases 

Key Negotiation Protocol 

Project Moonshot 

hokey Handover Keying 

ERP extension for EAP Early- authentication Protocol (EEP) 

ERP/AAK support for Inter-AAA realm handover 

IEEE 802.21a Status Report 

RFC5296bis 

ipsecme IP Security Maintenance and Extensions 

IPsec High Availability – Recap 

IPsecME WG Status 




Modes of Operation for SEED for Use with IPsec 

Proposed IPsec HA Cluster Protocol 

Secure Failure Detection Decision Process 

kitten Common Authentication Technology Next Generation 

kitten update 

Naming Extensions Lessons Learned 

ltans Long-Term Archive and Notary Services 

Agenda 

LTANS Architecture 

Validation & long term verification data for Evidence Records & signed documents 

XML Evidence Record Syntax 

msec Multicast Security 

GDOI Update 

Opening Slides 

Update on Symmetric Key Transport 

nea Network Endpoint Assessment 

NEA Slides for IETF 78 

pkix Public-Key Infrastructure (X.509) 

Additional Key Identifier Methods 

CMC Updates 

OCSP Algorithm Agility 

OCSP Update 

PKIX Overview 

RFC 5280 Clarifications 

Transport Protocols for CMP 

saag Security Area Open Meeting 

Agenda and Overview 

Cipher Suite Proliferation 

Cryptographically Generated Address (CGA) Extension Header for IPV6 

Distributed Security Architecture Within Enterprise Environments -1 

Distributed Security Architecture Within Enterprise Environments -2 

ECC Efficiencies 

Revisiting IPv6 Node Requirements 

TLS Server ID Check 

tls Transport Layer Security 

AES-CCM 

Agenda 

Server ID Check 

SSL Must Not 

TLS Cached Information 


http://www.ietf.org/proceedings/78/ 

http://www.ietf.org/proceedings/78/sec.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 CERTA-2002-INF-001 

sur la vulnérabilité de type ‘Cross-Scripting’ initialement publiée en 2002. 

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 date de mise à jour. 

NOTES D’INFORMATION M 

2002-INF-001 Vulnérabilité de type « Cross Site Scripting » 14/10/10 M 

2000-INF-002 Mesures de prévention relatives à la messagerie 27/03/09 

2008-INF-005 Gestion des journaux d'événements 31/12/08 

2008-INF-004 E-mail backscatting, pollution par des rapports de non-livraison de courriels 19/12/08 

2008-INF-003 Les attaques de type «cross-site request forgery» 17/12/08 

2008-INF-002 Du bon usage du DNS 21/07/08 

2008-INF-001 iFRAME, fonctionnement et protection 17/07/08 

2006-INF-004 Migration IPv6 : enjeux de sécurité 09/01/08 

2002-INF-002 Les bons réflexes en cas d'intrusion sur un système d'information 07/01/08 




2007-INF-003 Sécurité des réseaux sans fil Bluetooth 01/08/07 

2007-INF-002 Du bon usage de PHP 20/03/07 

2007-INF-001 Conseils pour la gestion des noms de domaine 02/02/07 

2006-INF-006 Risques associés aux clés USB 15/01/09 

2006-INF-009 Outils d'indexation et de recherche 21/11/06 

2006-INF-002 Terminologie d'usage au CERTA 21/04/06 

2006-INF-001 Filtrage et pare-feux 10/01/06 

2005-INF-005 Bonnes pratiques concernant l'hébergement mutualisé 19/12/05 

2001-INF-003 Tunnels et pare-feux : une cohabitation difficile 05/10/05 

2005-INF-004 Limiter l'impact du SPAM 03/10/05 

2005-INF-002 Les mémentos du CERTA 24/06/05 

2005-INF-001 Les mots de passe 24/06/05 

2005-INF-003 Les systèmes et logiciels obsolètes 13/06/05 

2004-INF-001 Sécurité des applications Web et vulnérabilité de type "injection de données" 03/01/05 


2005-REC-003 Les systèmes et les logiciels obsolètes 16/07/10 

2002-REC-002 Sécurité des réseaux sans fil (Wi-Fi) 21/11/08 

2005-REC-002 Attaque ciblée par cheval de Troie 24/06/05 

2005-REC-001 La bonne utilisation des protocoles SSL/TLS 01/03/05 


http://www.certa.ssi.gouv.fr/ 

NIST – ETAT DES GUIDES DE LA SERIE SPECIALE 800 

Le NIST vient de publier pour commentaire les guides SP800-135 ‘Recommendation for 

Existing Application-Specific Key Derivation Functions’ et SP800-56C ‘Recommendation 

for Key Derivation through Extraction-then-Expansion’. 

SP800-135 Recommendation for Existing Application-Specific Key Derivation Functions [R] 09/10 N 

SP800-132 Recommendation for Password-Based Key Derivation - Part 1: Storage Applications [R] 06/10 

SP800-131 Recommendation for the Transitioning of Cryptographic Algorithms and Key Sizes [R] 06/10 

SP800-130 Framework for Designing Cryptographic Key Management Systems [R] 06/10 

SP800-128 Guide for Security Configuration Management of Information Systems [R] 03/10 

SP800-126r1 The Technical Specification for SCAP [R] 05/10 

SP800-126 The Technical Specification for SCAP [F] 11/09 

SP800-125 Guide to Security for Full Virtualization Technologies [R] 07/10 

SP800-124 Guidelines on Cell Phone and PDA Security [F] 11/08 

SP800-123 Guide to General Server Security [F] 07/08 

SP800-122 Guide to Protecting the Confidentiality of Personally Identifiable Information [F] 04/10 

SP800-121 Guide to Bluetooth Security [F] 09/08 

SP800-119 Guidelines for the Secure Deployment of IPv6 [R] 02/10 

SP800-120 EAP Methods used in Wireless Network Access Authentication [F] 09/09 

SP800-118 Guide to Enterprise Password Management [R] 04/09 

SP800-117 Guide to Adopting and Using the Security Content Automation Protocol [F] 07/10 

SP800-116 Recommendation for the Use of PIV Credentials in Physical Access Control Systems [F] 11/08 

SP800-115 Technical Guide to Information Security Testing [F] 09/08 

SP800-114 User’s Guide to Securing External Devices for Telework and Remote Access [F] 11/07 

SP800-113 Guide to SSL VPNs [F] 07/08 

SP800-111 Guide to Storage Encryption Technologies for End User Devices [R] 11/07 

SP800-110 Information System Security Reference Data Model [R] 09/07 

SP800-108 Recommendation for Key Derivation Using Pseudorandom Functions [F] 11/08 

SP800-107 Recommendation for Using Approved Hash Algorithms [F] 02/09 

SP800-106 Randomized Hashing Digital Signatures [F] 02/09 

SP800-104 A Scheme for PIV Visual Card Topography [F] 06/07 

SP800-103 An Ontology of Identity Credentials, Part I: Background and Formulation [R] 09/06 

SP800-102 Recommendation for Digital Signature Timeliness [F] 09/09 

SP800-101 Guidelines on Cell Phone Forensics [F] 05/07 

SP800-100 Information Security Handbook: A Guide for Managers [F] 03/07 

SP800-98 Guidance for Securing Radio Frequency Identification (RFID) Systems [F] 04/07 

SP800-97 Guide to IEEE 802.11i: Robust Security Networks [F] 02/07 

SP800-96 PIV Card / Reader Interoperability Guidelines [R] 09/06 

SP800-95 Guide to Secure Web Services [F] 08/07 

SP800-94 Guide to Intrusion Detection and Prevention (IDP) Systems [F] 02/07 

SP800-92 Guide to Computer Security Log Management [F] 09/06 

SP800-90 Random Number Generation Using Deterministic Random Bit Generators [F] 03/07 

SP800-89 Recommendation for Obtaining Assurances for Digital Signature Applications [F] 11/06 




SP800-88 Guidelines for Media Sanitization [F] 09/06 

SP800-87r1 Codes for the Identification of Federal and Federally-Assisted Organizations [F] 04/08 

SP800-86 Computer, Network Data Analysis: Forensic Techniques to Incident Response [F] 08/06 

SP800-85A2 PIV Card Application and Middleware Interface Test Guidelines [F] 07/10 

SP800-85A1 PIV Card Application and Middleware Interface Test Guidelines [F] 03/09 

SP800-85B1 PIV Middleware and PIV Card Application Conformance Test Guidelines [R] 09/09 

SP800-85B PIV Middleware and PIV Card Application Conformance Test Guidelines [F] 07/06 

SP800-84 Guide to Single-Organization IT Exercises [F] 09/06 

SP800-83 Guide to Malware Incident Prevention and Handling [F] 11/05 

SP800-82 Guide to Industrial Control Systems (ICS) Security [R] 09/08 

SP800-81r1 Secure Domain Name System (DNS) Deployment Guide [F] 08/10 

SP800-80 Guide for Developing Performance Metrics for Information Security [R] 05/06 

SP800-79r1 Guidelines for Certification & Accreditation of PIV Card Issuing Organizations [F] 06/08 

SP800-78-2 Cryptographic Algorithms and Key Sizes for Personal Identity Verification [R] 10/09 

SP800-78r1 Cryptographic Algorithms and Key Sizes for Personal Identity Verification [F] 08/07 

SP800-77 Guide to Ipsec VPNs [F] 12/05 

SP800-76r1 Biometric Data Specification for Personal Identity Verification [F] 01/07 

SP800-73r3 Interfaces to Personal Identity Verification [R] 08/09 

SP800-73r2 Interfaces to Personal Identity Verification [F] 09/08 

SP800-72 Guidelines on PDA Forensics [F] 11/04 

SP800-70r1 NCP for IT Products - Guidelines for Checklist Users and Developers [F] 09/09 

SP800-70 The NIST Security Configuration Checklists Program [F] 05/05 

SP800-69 Guidance for Securing Microsoft Windows XP Home Edition [F] 08/06 

SP800-68r1 Guidance for Securing Microsoft Windows XP Systems for IT Professionals [F] 07/08 

SP800-67 Recommendation for the Triple Data Encryption Algorithm Block Cipher [F] 06/08 

SP800-66r1 An Introductory Resource Guide for Implementing the HIPAA Security Rule [F] 10/08 

SP800-65r1 Integrating IT Security into the Capital Planning and Investment Control Process [R] 07/09 

SP800-65 Integrating IT Security into the Capital Planning and Investment Control Process [F] 01/05 

SP800-64r2 Security Considerations in the Information System Development Life Cycle [F] 10/08 

SP800-63r1 Electronic Authentication Guidelines [R] 12/08 

SP800-61r1 Computer Security Incident Handling Guide [F] 03/08 

SP800-60r1 Guide for Mapping Types of Information & IS to Security Categories [F] 08/08 

SP800-59 Guideline for Identifying an Information System as a National Security System [F] 08/03 

SP800-58 Security Considerations for Voice Over IP Systems [F] 03/05 

SP800-57p1 Recommendation for Key Management, 1: General Guideline [F] 03/07 

SP800-57p2 Recommendation for Key Management, 2: Best Practices [F] 08/05 

SP800-57p3 Recommendation for Key Management, 3: Application-Specific Key Management [D] 10/08 

SP800-56A Pair-Wise Key Establishment Schemes Using Discrete Logarithm Cryptography [F] 03/07 

SP800-56B Pair-Wise Key Establishment Using Integer Factorization Cryptography [F] 09/09 

SP800-56C Recommendation for Key Derivation through Extraction-then-Expansion [R] 10/10 N 

SP800-55r1 Security Metrics Guide for Information Technology Systems [F] 08/08 

SP800-54 Border Gateway Protocol Security [F] 07/07 

SP800-53r3 Recommended Security Controls for Federal Information Systems [F] 08/09 

SP800-53r2 Recommended Security Controls for Federal Information Systems [F] 12/07 

SP800-53Ar1 Guide for Assessing the Security Controls in Federal Information Systems [F] 05/10 

SP800-53A Guide for Assessing the Security Controls in Federal Information Systems [F] 06/08 

SP800-52 Guidelines on the Selection and Use of Transport Layer Security [F] 06/05 

SP800-51 Use of the Common Vulnerabilities and Exposures Vulnerability Naming Scheme [F] 09/02 

SP800-50 Building an Information Technology Security Awareness & Training Program [F] 03/03 

SP800-49 Federal S/MIME V3 Client Profile [F] 11/02 

SP800-48r1 Guide to Securing Legacy IEEE 802.11 Wireless Networks [F] 08/08 

SP800-47 Security Guide for Interconnecting Information Technology Systems [F] 08/02 

SP800-46r1 Guide to Enterprise Telework and Remote Access Security [F] 06/09 

SP800-46 Security for Telecommuting and Broadband Communications [F] 08/02 

SP800-45V2 Guide On Electronic Mail Security [F] 02/07 

SP800-44V2 Guidelines on Securing Public Web Servers [F] 09/07 

SP800-43 System Administration Guidance for Windows00 [F] 11/02 

SP800-42 Guidelines on Network Security testing [F] 10/03 

SP800-41r1 Guidelines on Firewalls and Firewall Policy [F] 09/09 

SP800-41 Guidelines on Firewalls and Firewall Policy [F] 01/02 

SP800-40-2 Creating a Patch and Vulnerability Management Program [F] 11/05 

SP800-39 Managing Risk from Information Systems: An Organizational Perspective [R] 04/08 

SP800-38E Recommendation for Block Cipher Modes of Operation – XTS-AES [F] 01/10 

SP800-38D Recommendation for Block Cipher Modes of Operation – GCM [F] 11/07 

SP800-38C Recommendation for Block Cipher Modes of Operation – CCM [F] 05/04 

SP800-38B Recommendation for Block Cipher Modes of Operation – RMAC [F] 05/05 

SP800-38Aa Recommendation for Block Cipher Modes of Operation: Ciphertext Stealing for CBC [R] 07/10 




SP800-38A Recommendation for Block Cipher Modes of Operation – Method and Techniques [F] 12/01 

SP800-37r1 Guidelines for the Security C&A of Federal Information Technology Systems [R] 11/09 

SP800-37 Guidelines for the Security C&A of Federal Information Technology Systems [F] 04/04 

SP800-36 Guide to IT Security Services [F] 10/03 

SP800-35 Guide to Selecting IT Security Products [F] 10/03 

SP800-34r1 Contingency Planning Guide for Information Technology Systems [R] 10/09 

SP800-34 Contingency Planning Guide for Information Technology Systems [F] 06/02 

SP800-33 Underlying Technical Models for Information Technology Security [F] 12/01 

SP800-32 Introduction to Public Key Technology and the Federal PKI Infrastructure [F] 02/01 

SP800-31 Intrusion Detection Systems [F] 11/01 

SP800-30 http://csrc.nist.gov/publications/nistpubs/800-30/sp800-30.pdf [F] 01/04 

SP800-29 Comparison of Security Reqs for Cryptographic Modules in FIPS 140-1 & 140-2 [F] 10/01 

SP800-28v2 Guidelines on Active Content and Mobile Code [F] 03/08 

SP800-27A Engineering Principles for Information Technology Security – Rev A [F] 06/04 

SP800-26r1 Guide for Inform. Security Program Assessments & System Reporting Form [R] 08/05 

SP800-26 Security Self-Assessment Guide for Information Technology Systems [F] 11/01 

SP800-25 Federal Agency Use of PK Technology for Digital Signatures and Authentication [F] 10/00 

SP800-24 Finding Holes in Your PBX Before Someone Else Does [F] 08/00 

SP800-23 Guidelines to Federal Organizations on Security Assurance [F] 08/00 

SP800-22r1a Statistical Test Suite for Random and Pseudorandom Number Generators [F] 04/10 

SP800-21 Guideline for Implementing Cryptography in the Federal Government [F] 12/05 

SP800-16r1 Information Security Training Requirements: A Role & Performance Based Model [R] 03/09 

SP800-12 An Introduction to Computer Security: The NIST Handbook [F] 10/95 

[F] Finalisé [R] Relecture 


http://csrc.nist.gov/publications/PubsSPs.html - Catalogue des publications 

DISA – GUIDES ET CHECK LISTES DE SECURISATION 

La DISA vient de publier deux nouveaux guides d’implémentation technique (STIG), l’un 

consacré aux dispositifs médicaux (medical devices), l’autre aux dispositifs amovibles. 

[1 Mise(s) à jour, 2 Nouveau(x) Document(s)] 

APPLICATIONS 

Guide (STIG) Check Liste 

Applications Sécurité et Développement 3.1 26/04/10 3.1 26/04/10 

Services 1.1 17/01/06 1.1.1 21/09/06 

Microsoft Exchange 2003 1.3 25/04/10 1.2 05/01/10 M 

ESM 1.1 05/06/06 1.1.3 10/04/07 

ERP 1.1 10/04/07 1.1.1 10/04/07 

Database Générique 8.1 19/10/07 8.1.6 27/08/10 

Oracle 9, 10 et 11 8.1.8 27/08/10 

MS SQL Server 7, 2000, 2005 8.1.7 27/08/10 

ISA Server 2006 OWA Proxy 1.2 29/06/10 

ENVIRONNEMENTS 

Access Control 2.2 18/12/08 

Directory Service 1.1 10/03/06 1.1.5 28/08/09 

Collaboration 1.1 28/03/07 1.1 28/03/07 

Desktop Générique 4.1 03/12/10 3.1.11 09/03/07 

Windows 4.1 03/12/10 

Enclave Périmètre 4.2 31/03/08 4.2 31/03/08 

.NET 1.2.3 18/02/09 

Personal Computer Clients Voix, Vidéo et Collaboration 1.1 26/06/08 1.1.1 15/08/08 

Secure Remote Computing 2.3 27/08/10 2.1 02/10/09 

Instant Messaging 1.2 15/02/08 1.2.5 15/04/09 

Biométrie 1.3 10/11/05 2.1.1 17/10/07 

VoIP Voix sur IP 2.2 21/04/06 2.2.4 12/08/08 

VVoIP Voix et Video sur IP 3.2 27/08/10 

Vidéo Téléconférence 

PERIPHERIQUES 

1.1 08/01/08 1.1.2 06/11/08 

Sharing peripheral across the network 1.2 27/07/10 M 

- Multi-Function Device (MFD) and Printer Checklist 1.1.3 09/04/09 

- Keyboard, Video, and Mouse (KVM) Switch Checklist 1.1.3 19/12/08 

- Storage Area Network (SAN) Checklist 1.1.4 26/06/09 

- Universal Serial Bus (USB) Checklist 1.1.3 19/12/08 

Removable Storage and External Connection Technologies 

RESEAUX 

1.2 27/07/10 N 

Network Liste de contôle générique 7.1 25/10/07 7.1.10 28/08/09 




Cisco 6.1 02/12/05 

Juniper 6.4 02/12/05 

IP WAN Générique 2.3 12/08/04 

Wireless Liste de contôle générique 6.2 23/04/10 6.3 23/04/10 

Blackberry Guidance for BES 1.0 05/01/10 

BlackBerry 5.6 05/01/10 

Apriva 5.2.2 15/04/09 

Motorola 5.2.3 15/04/09 

Good 6.3 23/04/10 

Windows 5.2.4 15/04/09 

Wireless LAN Security Framework 2.1 31/10/05 

LAN Site Survey 1.1 31/10/05 

LAN Secure Remote Access 1.1 31/10/05 

SERVICES 

Mobile Computing 1.1 31/10/05 

DNS Générique 4.1 17/10/07 4.1.8 26/02/10 

Web Servers Générique 6.1 11/12/06 6.1.7 15/04/09 

IIS 6.1.12 23/04/10 

Netscape/Sun 6.1.6 26/06/09 

Apache 6.1.12 23/04/10 

TomCAT 6.1.5 14/04/09 

WebLogic 6.1.4 14/04/09 

SYSTEMES 

OS/390 & z/OS Générique 6.1.1 06/08/09 5.2.7 17/01/08 

Logical Partition 2.2 04/03/05 2.1.4 04/06 

RACF 6.4 27/08/10 6.1.2 23/04/10 

ACF2 6.4 27/08/10 6.1.2 28/08/09 

TSS 6.4 27/08/10 6.1.2 23/04/10 

MacOS/X 1.1 15/06/04 1.1.3 28/04/06 

TANDEM 2.2 04/03/05 2.1.2 17/04/06 

UNISYS 7.2 28/08/06 7.2 24/11/06 

UNIX 5.1 04/04/06 5.1.25 25/04/10 

VM IBM 2.2 04/03/05 2.2.1 04/06 

SUN Solaris 2.6 à 2.9 - 20/01/04 

RAY 4 1.1.1 17/04/09 1.1.1 17/04/09 

OPEN VMS 2.2.3 17/04/06 

Windows NT 3.1 26/12/02 4.1.21 28/07/08 

2000 6.1.19 27/08/10 

XP 6.1.19 27/08/10 

Vista 6.1.19 27/08/10 

2003 6.1.19 27/08/10 

2008 6.1.12 27/08/10 

7 1.2 27/08/10 

Addendum 2000/XP/Vista/2003 6.1 21/05/07 

VMWare ESX 1.1.0 28/04/08 1.4.0 15/10/09 

Citrix XENApp 

AUTRE 

1.1.2 15/10/09 1.1.2 15/10/09 

AntiVirus Security Guidance Générique 4.1 03/12/09 

McAfee 4.3 27/08/10 

Symantec 4.1 03/12/09 

Best Practice Security Générique 2.1 29/01/07 

Browser Security Guidance IE6 4.2 23/04/10 

IE7 4.2 23/04/10 

IE8 1.3 27/08/10 

Firefox 4.2 23/04/10 

Cloud Computing Guidance 1.0.2 01/07/10 

Medical Devices 1.1 27/07/10 N 

Office Security Guidance Microsoft Office 2003 4.1 03/12/09 

Microsoft Office 2007 4.2 26/08/09 


http://iase.disa.mil/stigs/checklist/index.html 

http://measurablesecurity.mitre.org/about/index.html 

NSA – GUIDES DE SECURITE 




Après plus de 6 mois de silence, la NSA vient de mettre à jour son catalogue de guides de 

sécurité avec le référencement du guide produit par Apple traitant du système MacOS X 10.6 dit 

‘Snow Leopard’. 

FACT SHEETS 

Desktop or Enterprise Firewall? - 08/06 NSA 

Enterprise Firewall Types - 08/06 NSA 

Enterprise Firewalls in Encrypted Environments - 08/06 NSA 

Social Networking Sites - 12/09 NSA 

Mail Client Security Cheat Sheet - 02/07 NSA 

Mitigation Monday: Defense Against Malicious E-mail Attachments - 05/08 NSA 

Security Guidance for Using Mail Clients - 02/07 NSA 

Secure Instant Messaging - 02/07 NSA 

Configuring a Cisco Router for Remote Administration Using the Router Console - 05/07 NSA 

Configuring a PC to Remotely Administer a Cisco Router Using the Router Console - 05/07 NSA 

Port Security on Cisco Access Switches Factsheet - 01/08 NSA 

Internet Protocol version 6 - 01/08 NSA 

802.11 Wireless LAN Intrusion Detection Systems - 05/08 NSA 

Biometrics Security Considerations - 04/07 NSA 

Bluetooth Security - 12/07 NSA 

Video Teleconferencing (VTC) - 03/08 NSA 

Disabling USB Storage Drives - 03/08 NSA 

Securing Fibre Channel Storage Area Networks - 03/09 NSA 

Security Tips for Personally-Managed Apple iPhones - 12/09 NSA 

So Your Boss Bought you a New Laptop...How do you disable wireless capabilities - 05/07 NSA 

A Deployment Guide for the Microsoft Office ICE and File Block Functionality - 02/08 NSA 

Data Execution Prevention (DEP) - 10/07 NSA 

Encrypting Files with WinZip® - 12/09 NSA 

Exchanging Files with PGP - 12/09 NSA 

How to Securely Configure Microsoft Windows Vista BitLocker - 08/07 NSA 

The Microsoft Office ICE & File Block Functionality with Office 2003 - 02/08 NSA 

Windows Fine-Grained Password Policies - 05/09 NSA 

Minimize the Effectiveness of SQL Injection Attacks - 05/08 NSA 

Securing Supervisory Control & Data Acquisition (SCADA) & Control Systems (CS) - 03/09 NSA 

Service Oriented Architecture Security Vulnerabilities - Web Services - 11/08 NSA 

SUPPORTING DOCUMENTS 

Activating Authentication and Encryption for Cisco CallManager 4.(x) 04/08 NSA 

Cloud Computing Guidance 07/10 NSA 

Defense in Depth 06 NSA 

Guide to Sun Microsystems Java Plug-in Security 04/04 NSA 

How to Safely Publish Sanitized Reports Converted From Word 03/08 NSA 

How to Secure a Groove Manager Web Site 04/07 NSA 

Microsoft Office Groove Security Architecture 04/07 NSA 

Outlook E-mail Security in the Midst of Malicious Code Attacks 04/05 NSA 

The 60 minute Network Security Guide 05/06 NSA 

The Case for Using Layered Defenses to Stop Worms 06/04 NSA 

VMware ESX Server 3 Configuration Guide 03/08 NSA 

Web Application Security Overview 07 NSA 

Vulnerability Technical Reports 

Best Practices for Storage Networks 18/10/07 NSA 

How to Safely Publish Sanitized Reports Converted from Word to PDF 02/02/06 NSA 

Manageable Network Plan 18/11/08 NSA 

APPLICATIONS 

Microsoft 

CIS Exchange Server 2003 Benchmark 05 CIS 

Guide to Microsoft .NET Framework Security 21/12/06 NSA 

Guide to Secure Configuration and Administration of Microsoft Exchange 2000 1.3a 14/12/04 NSA 

Microsoft Office 2000 Executable Content Security Risk and Countermeasures 08/02/02 NSA 

Office XP/2003 Executable Content Security Risks & Countermeasures Guide 02/05/05 NSA 

Systems Management Server 2003 Security Guide 1.0 04/05 NSA 

Oracle 

BEA WebLogic Platform Security Guide 1.0 04/04/05 NSA 

Oracle Application Server on Windows 2003 Security Guide 12/06 NSA 

Oracle Application Server Security Recommendations and DoDI 8500.2 IA Controls 12/06 NSA 

Adobe 

Hidden Data and Metadata in Adobe PDF Files 27/07/08 NSA 




DATABASE SERVERS 

Oracle 

Security Configuration Benchmark For Oracle Database Server 11g 1.01 01/09 CIS 

Guide to Secure Configuration and Administration of Oracle9i Database Server 1.2 30/09/03 NSA 

Center for Internet Security Benchmark for Oracle 9i/10g 2.0 05 CIS 

Microsoft 

Guide to Secure Configuration and Administration of Microsoft SQL Server 2000 1.5 26/08/03 NSA 

Benchmark for Microsoft SQL Server 2005 1.0 06/04/07 CIS 

OPERATING SYSTEMS 

Apple 

Mac OS X Security Configuration for Version 10.6 - 09/10 APP N 

Mac OS X Security Configuration for Version 10.5 2.0 08 APP 

Hardening Tips for the Default Installation of Mac OS X 10.5 09/08 NSA 

Mac OS X Security Configuration For Version 10.4 or Later 2.0 07 APP 

Mac OS X Server Security Configuration For Version 10.4 or Later 2.0 07 APP 

Apple Mac OS X v10.3.x Security Configuration Guide 1.1 04 NSA 

Apple Mac OS X Server v10.3.x Security Configuration Guide 05 NSA 

Linux 

Guide to the Secure Configuration of Red Hat Enterprise Linux 5 2.0 20/12/07 NSA 

Hardening Tips for the Red Hat Enterprise Linux 5 11/07 NSA 

Microsoft 

Windows Vista Security Guide 13/11/06 MIC 

The Windows Server 2003 - Security Guide 2.1 26/04/06 MIC 

The Windows Server 2003 - Security Guide - Read Me 2.1 26/04/06 MIC 

The Windows Server 2003 - Security Guide - Release Notes 2.1 26/04/06 MIC 

The Windows Server 2003 - Security Guide - Tools and Templates 2.1 26/04/06 MIC 

NSA Windows Server 2003 Security Guide Addendum 1.0 12/09/06 NSA 

Windows XP Security Configuration Guides 12/09/06 MIC 

NSA Windows XP Security Guide Addendum 1.0 12/09/06 NSA 

Microsoft Windows 2000 Network Architecture Guide 1.0 19/04/01 NSA 

Microsoft Windows 2000 Router Configuration Guide 1.02 01/05/01 NSA 

Microsoft Windows 2000 IPsec Guide 1.0 13/08/01 NSA 

Group Policy Reference 1.08 02/03/01 NSA 

Guide to Securing Microsoft Windows 2000 Group Policy 1.1 13/09/01 NSA 

Guide to Securing Microsoft Windows 2000 Group Policy: Security Configuration Tool 1.22 12/09/01 NSA 

Guide to Securing Microsoft Windows 2000 Active Directory 1.0 12/00 NSA 

Guide to Securing Microsoft Windows 2000 DNS 1.0 09/04/01 NSA 

Guide to Securing Microsoft Windows 2000 Encrypting File System 1.0 01/01 NSA 

Guide to Securing Microsoft Windows 2000 File and Disk Resources 1.01 26/11/02 NSA 

Guide to Securing Microsoft Windows 2000 Schema 1.0 06/03/01 NSA 

Guide to Securing Microsoft Windows NT/9x Clients in a Windows 2000 Network 1.02 23/01/01 NSA 

Guide to Securing Microsoft Windows 2000 DHCP 1.3 18/07/02 NSA 

Guide to Securing Microsoft Windows 2000 Terminal Services 1.0 02/07/01 NSA 

Guide to Secure Configuration and Administration of Microsoft ISA Server 2000 1.5 08/08/02 NSA 

Guide to Secure Configuration of Microsoft Windows 2000 Certificate Services 2.11 10/10/01 NSA 

Guide to Windows 2000 Kerberos Settings 1.1 27/06/01 NSA 

Sun Solaris 

An Overview of Solaris 10 Operating System Security Controls 25/09/07 CIS 

CIS Solaris 10 Benchmark 4.0 24/09/07 SUN 

Guide to Secure Configuration of Solaris 9 1.0 16/07/04 NSA 

IPV6 

A Filtering Strategy for Mobile IPv6 19/09/07 NSA 

Firewall Design Considerations for IPv6 03/10/07 NSA 

CISCO Routeur Guide 

Router Security Configuration Guide, Executive Summary 10/02/03 NSA 

Router Security Configuration Guide 1.1c 15/12/05 NSA 

Router Security Configuration Guide Supplement – Security for Ipv6 Routers 1.0 23/05/06 NSA 

Zipped Router Security Configuration Guide 26/05/06 NSA 

Switches 

Cisco IOS Switch Security Configuration Guide 1/0 21/04/04 NSA 

VoIP 

Security Guidance for Deploying IP Telephony Systems 1.01 14/02/06 NSA 

Recommended IP Telephony Architecture 1.0 01/05/06 NSA 

WEB Servers & BROWSERS 

Microsoft 




Guide to Secure Configuration of Microsoft Internet Information Services 5.0 1.4 20/10/03 NSA 

Guide to Securing Microsoft Internet Explorer 5.5 Using Group Policy 1.0 07/02 NSA 

WIRELESS 

Guidelines for the Development and Evaluation of IEEE 802.11 IDSs 01/11/05 NSA 

Recommended 802.11 Wireless Local Area Network Architecture 23/09/05 NSA 


http://www.nsa.gov/ia/guidance/security_configuration_guides/index.shtml 

MAGAZINES 

HNS - (IN)SECURE MAG N°27 

Le 26 me numéro du magazine ‘(In)Secure’ – 11 articles, 63 pages et moins de 8Mo – est 

paru début septembre. En voici le sommaire: 

Security World 

Review: BlockMaster SafeStick secure USB flash drive 

The devil is in the details: Securing the enterprise against the cloud 

Latest Addition to our bookshelf 

Cybercrime may be on the rise, but authentication evolves to defeat it 

Twitter security spotlight 

Learning from bruteforcers 

PCI DSS v1.3: Vital to the emerging demand for virtualization and cloud security 

Events around the world 

Security testing - the key to software quality 

Security Software Spotlight 

A brief history of security and the mobile enterprise 

Payment card security: Risk and control assessments 

Malware World 

Security as a process: Does your security team fuzz? 

Book review: Designing Network Security, 2 nd Edition 

Security Videos 

Intelligent security: Countering sophisticated fraud 


http://www.net-security.org/dl/insecure/INSECURE-Mag-27.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 de domaine. Parmi tous 

les litiges jugés, en voici quelques uns concernant l’usage abusif de marques célèbres 

en France. 

Deux litiges ont porté sur des tentatives d’exploitation de la marque Sanofi-Aventis, l’une (sanofi-anventis 

/ D2010-1005) sur un domaine enregistré auprès d’un registre Chinois par un certain ‘搜商商’, l’autre 

(sanofi-adventis / D2010-0964) par une société anglaise. Dans les deux cas, l’enregistrement a été jugé 

avoir été effectué avec une intention déloyale et les domaines ont été détruits à la demande du plaignant, 

la société Sanofi-Aventis. 

Le litige DFR2010-0018 porte sur un nom de domaine enregistré en son nom personnel par le membre 

d’une association, l’Association Française des Travels Managers, quelques jours après la réception d’un 

courrier annonçant la création de cette association. Sans surprise, le domaine est transféré à l’association, 

le jugement précisant d’une part que « le seul fait d’intervenir dans la création, la maintenance ou le 

contenu éditorial d’un site Internet ne confère pas de droits privatifs sur le nom de domaine exploité » et 

d’autre part que « sa seule qualité de membre de l’Association AFTM ne lui conférait pas et ne lui confère 

aujourd’hui pas plus de droits sur la dénomination “AFTM”. En effet, sauf disposition contraire, seule 

l’Association est en droit de disposer de cette dénomination et des droits qui y sont attachés ». 

Le litige DFR2010-0019 oppose la société ‘Grande Brasserie de la Patrie Schutzenberger & CIE’ et un 

repreneur possible de celle-ci dans le cadre d’une procédure collective, lequel repreneur prend position et 




« considère que ses intentions légitiment l’enregistrement du nom de domaine litigieux » ajoutant « qu’il 

ne peut être valablement soutenu que l’enregistrement du nom de domaine litigieux porte atteinte aux 

règles de la concurrence puisque depuis le prononcé de la liquidation judiciaire en avril 2006, le Requérant 

n’exploite plus ses marques excluant de facto toute situation de concurrence ». Le juge ne le suit pas 

dans son analyse et ordonne le transfert du nom de domaine au requérant ici représenté par son 

administrateur judiciaire. 

Portant sur les domaines ‘lagardere.es’ et ‘lagardereactivemedia.es’ enregistrés en 2006 et 2007, le litige 

DES2010-0042 oppose la SCA Lagardère et un ancien employé d’une filiale espagnole de celle-ci. Ce 

dernier fait valoir que la marque ‘Lagardère’ n’est pas exploitée telle quelle en Espagne, que 

l’enregistrement des noms de domaine date de plus de 3 ans sans qu’aucun recours n’ait été engagé, et 

surtout que la simple détention d’un nom de domaine sans que celui-ci ne soit utilisé par un site ne peut 

être considérée comme un acte de mauvaise foi. Cette prise de position n’est pas en accord avec les 

critères définis par la procédure de résolution de l’OMPI, le domaine est donc transféré. 

Le litige ‘D2010-1237’ porte sur quelques 37 altérations du nom de domaine ‘fragrancex.com’ déposés par 

la société éponyme FraganceX.com. Probablement utilisés à des fins de détournement de traffic, ces noms 

de domaine ont été enregistrés chez le même fournisseur, et aux mêmes dates, au nom de 24 sociétés, 

ou personnes, différentes. L’analyse menée par l’expert mandaté par l’OMPI montre sans ambiguïté qu’il 

s’agit d’une opération conduite par une seule et même personne physique résidant en Ukraine. La 

procédure de résolution de l’OMPI autorise alors un jugement de fond unique. Ce litige est à mettre en 

relation avec le litige ‘D2006-1537’ qui opposait la société ‘Barnes & Noble’ à cette même personne en 

2006. 

DFR2010-0017 � akbank.fr Akbank Turk A.S 18/08 

* DFR2010-0020 � bet365.fr Bet365 Group Limited 19/08 

* D2010-0964 ⌧ sanofiadventis.com Sanofi-Aventis 31/08 

* D2010-1005 ⌧ sanofi-anventis.com Sanofi-Aventis 23/08 

D2010-1236 ⌧ galerieslafayete.com Societe Anonyme des Galeries Lafayette 14/09 

* D2010-1237 � 37 altérations de fragrancex.com FragranceX.com, Inc. 17/09 

* DFR2010-0018 � aftm.fr Ass. Française des Travels Managers 30/08 

DFR2010-0019 � schutzenberger.fr Grande Brasserie de la Patrie Schutzenberger 20/08 

DES2010-0042 � lagardere.es 

Lagardere SCA 23/09 

lagardereactivemedia.es 

�: Transfert du domaine, �: maintien du domaine, ⌧: Annulation du domaine *: pas de réponse du détenteur 


http://www.wipo.int/rss/index.xml?col=dnddocs - Dernières décisions 

http://www.wipo.int/freepublications/fr/arbitration/779/wipo_pub_779.pdf - Procédure de règlement des litiges 

STANDARDS 

IETF – LES RFC TRAITANT DIRECTEMENT DE LA SECURITE 

Thème Num Date Etat Titre 

CMS 5990 09/10 Pst Use of the RSA-KEM Key Transport Algorithm in the Cryptographic Message Syntax (CMS) 

6010 09/10 Pst Cryptographic Message Syntax (CMS) Content Constraints Extension 

CRYPTO 6008 09/10 Pst Authentication-Results Registration for Differentiating among Cryptographic Results 

IKE 5996 09/10 Pst Internet Key Exchange Protocol Version 2 (IKEv2) 

5998 09/10 Pst An Extension for EAP-Only Authentication in IKEv2 

MIKEY 5748 08/10 Inf IANA Registry Update for Support of the SEED Cipher Algorithm in Multimedia Internet KEYing 

RADIUS 5997 08/10 Inf Use of Status-Server Packets in the Remote Authentication Dial In User Service (RADIUS) Protocol 

SRTP 5669 08/10 Pst The SEED Cipher Algorithm and Its Use with the Secure Real-Time Transport Protocol (SRTP) 

TEREDO 5991 09/10 Pst Teredo Security Updates 

IETF – LES RFC LIES A LA SECURITE 

Thème Num Date Etat Titre 

EID 6017 09/10 Inf Electronic Data Interchange - Internet Integration (EDIINT) Features Header Field 

IPV6 5969 08/10 Pst IPv6 Rapid Deployment on IPv4 Infrastructures (6rd) -- Protocol Specification 

TIME 6019 09/10 Pst BinaryTime: An Alternate Format for Representing Date and Time in ASN.1 

IETF – LES NOUVEAUX DRAFTS TRAITANT DE LA SECURITE 

Thème Nom du Draft Date Titre 




CMS draft-turner-cms-symmetrickey…-algs-00 23/09 Algo for CMS Protection of Symmetric Key Package Content Types 

ERP draft-ietf-hokey-rfc5296bis-00 12/09 EAP Extensions for EAP Re-authentication Protocol (ERP) 

HIP draft-ietf-hip-rfc5202-bis-00 23/09 Using the ESP Transport Format with the Host Identity Protocol 

IPV6 draft-ietf-v6ops-tunnel-loops-00 11/09 Routing Loop Attack using IPv6 Automatic Tunnels 

MANRAL draft-bhatia-manral-auth-trailer-ospfv3-00 28/09 Supporting Authentication Trailer for OSPFv3 

PANA draft-ohba-pana-relay-00 21/09 PANA Relay Element 

draft-ohba-pana-keywrap-00 22/09 PANA Extension for Key Wrap 

PKI draft-ietf-sidr-signed-object-00 28/09 Signed Object Template for the Resource Public Key Infrastructure 

SAML draft-ietf-kitten-sasl-saml-00 24/09 A SASL and GSS-API Mechanism for SAML 

draft-cantor-ietf-kitten-saml-ec-00 23/09 SAML Enhanced Client SASL and GSS-API Mechanisms 

IETF – LES MISES A JOUR DE DRAFTS TRAITANT DE LA SECURITE 

Thème Nom du Draft Date Titre 

AFS3 draft-brashear-afs3-pts-extended-names-06 30/08 Auth. Name Mapping extension for AFS-3 Protection Service 

BUNDLE draft-irtf-dtnrg-bundle-security-17 13/09 Bundle Security Protocol Specification 

CGA draft-garcia-martinez-cgamib-02 22/09 Management Information Base for CGA 

CISCO draft-nourse-scep-21 22/09 Cisco Systems' Simple Certificate Enrollment Protocol 

CRYPTO draft-turner-md5-seccon-update-03 23/09 Updated Security Considerations for MD5 & HMAC-MD5 Algorithms 

draft-turner-akf-algs-update-01 16/09 EC Algorithms for Asymmetric Key Package Content Type 

draft-turner-ekpct-algs-update-01 16/09 EC Algorithms for CMS Encrypted Key Package Content Type 

EAP draft-ietf-emu-eaptunnel-req-08 17/09 Requirements for a Tunnel Based EAP Method 

HIP draft-ietf-hip-cert-04 23/09 HIP Certificates 

HTTP draft-bryan-metalinkhttp-17 13/09 Mirrors and Cryptographic Hashes in HTTP Headers 

IBAKE draft-cakulev-ibake-02 14/09 IBAKE: Identity-Based Authenticated Key Agreement 

IPSEC draft-welter-ipsecme-ikev2-reauth-00 28/09 Reauthentication Extension for IKEv2 

IPV4 draft-ietf-mip4-gre-key-extension-02 27/09 GRE Key Extension for Mobile IPv4 

IPV6 draft-vandevelde-v6ops-harmful-tunnels-01 31/08 Non-Managed IPv6 Tunnels considered Harmful 

draft-ietf-v6ops-cpe-simple-security-13 28/09 Simple Security Capabilities in Customer Premises Equipment 

draft-ietf-v6ops-tunnel-security-concerns-02 31/08 Security Concerns With IP Tunneling 

IRC draft-hartmann-default-port-for-irc-via-tls…02 28/09 Default Port for IRC via TLS/SSL 

ISMS draft-ietf-isms-radius-vacm-11 14/09 AAA services to Dynamically Provision View-based Access Control 

KERB draft-ietf-krb-wg-anon-12 30/08 Anonymity Support for Kerberos 

MSEC draft-ietf-msec-ipsec-group-counter…-06 10/09 Using Counter Modes with ESP and AH to Protect Group Traffic 

OPENPGP draft-jivsov-openpgp-ecc-06 18/09 ECC in OpenPGP 

OPSEC draft-ietf-opsec-routing-protocols-crypto-…-07 31/08 Issues with Cryptographic Protection Methods for Routing Proto. 

draft-ietf-opsec-igp-crypto-requirements-01 27/09 Crypto. Auth Algo Implementation Req. for Routing Protocols 

OSPF draft-bhatia-karp-non-ipsec-ospfv3-auth-01 27/09 Non IPSec Authentication mechanism for OSPFv3 

PANA draft-yegin-pana-unspecified-addr-03 26/09 PANA with IPv4 Unspecified Address 

PBKDF2 draft-josefsson-pbkdf2-test-vectors-06 14/09 PKCS #5 Password Based Key Derivation Function 2 Test Vectors 

RFC5081 draft-mavrogiannopoulos-rfc5081bis-08 16/09 Using OpenPGP Keys for TLS Authentication 

RTP draft-ietf-avt-srtp-big-aes-04 15/09 The use of AES-192 and AES-256 in Secure RTP 

SEND draft-ietf-csi-proxy-send-05 28/09 Secure Proxy ND Support for SEND 

draft-ietf-csi-send-cert-07 24/09 Certificate profile and certificate management for SEND 

draft-garcia-martinez-sendmib-02 23/09 Management Information Base for the SEND rotocol 

SHA2B draft-eastlake-sha2b-04 22/09 US Secure Hash Algorithms: SHA and SHA based HMAC and HKDF 

SIDR draft-ietf-sidr-cp-11 15/09 Certificate Policy (CP) for the Resource PKI (RPKI) 

draft-ietf-sidr-arch-11 21/09 An Infrastructure to Support Secure Internet Routing 

SIP draft-ietf-sip-certs-15 21/09 Certificate Management Service for The Session Initiation Protocol 

SPEER draft-ietf-speermint-voipthreats-05 23/09 SPEERMINT Security Threats and Suggested Countermeasures 

TLS draft-hoffman-keys-linkage-from-dns-02 15/09 Secure DNS to Associate Certificates with Domain Names For TLS 

draft-ietf-tls-rfc4366-bis-12 20/09 Transport Layer Security (TLS) Extensions: Extension Definitions 

TSVWG draft-ietf-tsvwg-rsvp-security-groupkeying-07 23/09 Applicability of Keying Methods for RSVP Security

standards - cert devoteam

Create successful ePaper yourself

Delete template?

Save as template?