Veille Technologique Sécurité - cert devoteam

More documents

Recommendations

Info

Avril 2001 La suite du document est consacré à l'infrastructure 'Federal PKI' dont l'objectif est de fédérer les différentes Autorités de Certification ou AC indépendantes mises en place par les Agences Fédérales. Dans un tel contexte, la principale difficulté provient de la diversité des moyens utilisés par les agences dont certaines ont fait appel à des Autorités de Certification commerciales. L'infrastructure 'Federal PKI' doit offrir un service permettant d'interconnecter les AC des Agences Fédérales par un chemin de certification fiable et de confiance. Ce service est normalement assuré par une passerelle spécialisée dite 'Bridge CA' ou BCA jouant le rôle d'un simple médiateur entre domaines de confiance. Il est important de noter qu'un BCA n'a pas à jouer le rôle d'une autorité de certification racine à partir de laquelle sont initialisés les chemins de certification. Les AC fédérales s'appuieront sur une passerelle située dans le domaine Fédéral, le FBCA ou Federal BCA, pour communiquer entre eux ou avec des AC situées en dehors de ce domaine. A cette fin, une cross certification sera effectuée entre les AC respectant un certain nombre de règles imposées et le FBCA. Ces règles prennent notamment la forme de profils mandataires ou optionnels, venant compléter ceux décrits dans le RFC2459 (PKIX Profile), et spécifiant les extensions dans les certificats (x509 version 3) et dans les CRL (version 2). Une démarche conduite en 7 étapes dont l'objectif est de faciliter le déploiement d'un PKI conforme aux exigences de l'infrastructure précitée est proposée en fin de document: 1. Analyse des données et des applications de l'organisation susceptibles d'utiliser les services du PKI 2. Etude des normes et des modèles génériques de politique mis à disposition 3. Ecriture d'un premier jet de politique de certification en s'appuyant sur celle du FBCA 4. Sélection d'un produit PKI ou d'un fournisseur de service 5. Ecriture de la CPS (Certification Practice Statement ou Enoncé des Pratique de Certification ) dont une copie sera maintenue sur le BCA 6. Réalisation d'un pilote sur une durée suffisante pour acquérir une expérience significative 7. Interconnecter son PKI en demandant la cross-certification de l'AC avec le FBCA Les problèmes abordés n'étant pas spécifiques des infrastructures gouvernementales, nous recommandons la lecture de ce document qui constitue une excellente introduction à la problématique de l'interconnexion de PKI. Complément d’information http://csrc.nist.gov/publications/drafts.html http://csrc.nist.gov/pki/twg/y2000/papers/twg-00-18.xls http://csrc.nist.gov/pki/twg/y2000/doc_reg_00.htm LES CONTENUS DYNAMIQUES ET CODES MOBILES Description Intitulé 'Guidelines on Active Content and Mobile Code', ce guide de 45 pages publiée par le NIST propose un état de l'art des technologies ayant permis d'étendre les fonctionnalités initiales proposées par le WEB. Destiné à sensibiliser les personnels des Agences Fédérales Américaines, ce document ne propose aucune solution innovante que ce soit sur le plan technique ou organisationnel en dehors des traditionnelles mesures de prévention. Sa principale qualité réside donc dans l'utilisation d'une approche pédagogique trop rarement rencontrée: chaque élément vital de l'infrastructure - technologies clefs ou composants logiciels - fait l'objet d'un paragraphe détaillant non seulement la fonctionnalité associée mais aussi l'historique attaché à cet élément: son origine et les évolutions successives … Un important chapitre est ainsi réservé à la présentation de "l'anatomie" d'un navigateur et d'un serveur WEB en insistant, d'une part, sur les différentes méthodes d'activation d'un code par le navigateur,et d'autre part, sur les procédés de traitement spécifiques des pages dynamiques - SSI, ASP et servlet - par le serveur. Un second chapitre aborde les risques induits par les diverses technologies de présentation employées dont les langages de visualisation PostScript et PDF, les langages de programmation Java et VBScript, les composants autonomes Activ/X, le macro-langage VBA et enfin les applications externes telles ShockWave ou QuickTime. Cette approche permet de mieux comprendre - voire de justifier - les défaillances d'une infrastructure - The WEB - initialement conçue dans l'optique d'assurer un service élémentaire fiable et sécurisé mais ayant subit des modifications structurelles fondamentales désormais irréversibles. Tout en essayant d'avoir une approche positive, les auteurs insistent sur les nombreux facteurs endémiques qui continueront à favoriser l'insécurité de l'Internet en général, et des infrastructures WEB en particulier - Le facteur d'échelle conduisant à faire coexister les systèmes les plus solides car issus des dernières évolutions Veille Technologique Sécurité N°33 Page 10/59 © APOGEE Communications - Tous droits réservés Diffusion restreinte aux clients abonnés aux services VTS-RAPPORT et VTS-ENTREPRISE
Avril 2001 technologiques avec des systèmes fragilisés par l'âge et l'obsolescence des logiciels utilisés. Ces derniers seront les cibles privilégiées des attaques car offrant des plates-formes aptes à relayer ces attaques au sein de l'infrastructure, - La difficulté d'appliquer des correctifs sur un système opérationnel conduisant à devoir laisser ouverte une fenêtre temporelle plus ou moins longue durant laquelle ce système est totalement vulnérable, - La diminution du niveau de qualité (et du contrôle de la qualité) des développements, la qualité n'étant plus un argument de vente mais plutôt un frein conduisant à retarder la mise sur le marché des produits. La présence quasi systématique de fonctions cachées tels les 'Easters Eggs' dans les produits les plus réputés tend à prouver que l'éditeur est en passe de perdre le contrôle de sa propre chaîne de production, - La confusion engendrée par les exigences de modularité et de flexibilité des constituants conduisant les développeurs à utiliser telles quelles, et sans précautions particulières, des technologies ne permettant plus de distinguer le programme des données, - La complexité grandissante des applications menant à un code de plus en plus volumineux et, par voie de conséquence, difficilement vérifiable, - Les trop nombreux paramètres de configuration devant être maîtrisés pour garantir un niveau de sécurité minimal, - L'absence d'éthique des sociétés collectant et archivant des données personnelles sur leurs sites WEB sans pour autant renforcer le niveau de sécurité de ceux-ci, - Les atteintes en déni de service engendrées par le raccordement, sur un réseau ouvert tel l'Internet, de composants dont les ressources ne sont pas illimitées. Complément d’information http://csrc.nist.gov/publications/drafts.html PROTECTION SDMI Description SDMI, acronyme de Secure Digital Music Initiative, résulte du regroupement des principaux acteurs dans le domaine de l'édition et de la publication musicale. L'objectif de cette initiative est de spécifier les bases d'un système de protection du contenu musical indépendamment de la forme du support, étant cependant entendu que celui-ci est digital ! Le problème devant être prioritairement traité est celui de la diffusion d'un contenu sur un support autre que celui pour lequel il a été généré. En d'autres termes, le système de protection devra permettre de distinguer entre un contenu original et un contenu similaire mais ayant fait l'objet d'une manipulation visant par exemple à réduire le volume à transférer, la copie intégrale ('rip') d'un support original restant autorisée. Bien entendu, un tel système n'a de sens qu'à la condition que tous les dispositif permettant la restitution du contenu soient conformes aux spécifications SDMI. Cette conformité sera sanctionnée par le label DMAT (Digital Music Access technology). Afin de valider la solidité des concepts et principes ainsi établis pour le premier palier technique, dit phase 1, un défi public a été lancé en Septembre 2000 pour une durée de 3 semaines. Ce palier utilise deux mécanismes, l'un permettant de prouver la non-manipulation du contenu au moyen d'une signature cryptographique de celui-ci, le second visant à fournir un moyen de marquage non altérable du contenu utilisant la technique dite du 'watermarking'. Un contenu non marqué et ne comportant pas de signature est considéré comme acceptable car antérieur à la mise en place du système; il faut bien assurer la compatibilité avec les contenus existants ! Le défi portait sur ce dernier mécanisme et avait pour objectif d'éliminer le marquage effectué au moyen de 6 algorithmes distincts sur des contenus imposés sans que cette manipulation ne soit détectable. A cette fin, trois fichiers ont été fournis pour chaque algorithme: - un fichier non marqué contenant une chanson - le même fichier mais marqué - un fichier marqué contenant une autre chanson La bonne éradication du marquage de ce dernier fichier pouvait être contrôlée par chaque participant par le biais d'un ORACLE mis à disposition et accessible par courrier électronique. L'utilisation d'un ORACLE (réponse binaire OUI/NON) permet d'éviter de divulguer l'algorithme utilisé tout en garantissant le bon déroulement des tests. Bien que les participants se soient engagés à ne pas divulguer les techniques employées pour contourner la protection offerte par le marquage, les rapports techniques détaillés concernant les attaques menées par deux groupes ont été rendus disponibles sur l'Internet depuis le début de l'année: - Groupe Français: Julien Bœuf et Julien P Stern via le site de JP.Stern - Groupe Américain: Université de Princeton via 'Cryptome' Ces rapports seraient passés inaperçus du public si une tentative d'interdiction de la publication du rapport du groupe de l'université de Princeton à l'occasion de la conférence International Information Hiding Workshop devant se tenir en avril n'avait été dévoilée par le site 'Cryptome'. Ce document, démontre en effet, chiffres à l'appui, l'efficacité et l'ingéniosité des techniques d'analyses employées, en considérant que 2 des 6 défis ne pouvaient relevés avec le matériel fourni: Veille Technologique Sécurité N°33 Page 11/59 © APOGEE Communications - Tous droits réservés Diffusion restreinte aux clients abonnés aux services VTS-RAPPORT et VTS-ENTREPRISE
Page 1 and 2: APOGEE Communications Rapport de Ve
Page 3 and 4: Avril 2001 MICROSOFT 27 NCM 27 NETS
Page 5 and 6: Avril 2001 LES PRODUITS TELEPHONIE
Page 7 and 8: Avril 2001 LES TECHNOLOGIES SYSTEME
Page 9: Avril 2001 LES INFORMATIONS CERT IN
Page 13 and 14: Avril 2001 LES SERVICES DE BASE LOG
Page 15 and 16: Avril 2001 NORMES ET STANDARDS LES
Page 17 and 18: Avril 2001 Thème Nom du Draft Date
Page 19 and 20: Avril 2001 SIP draft-ietf-simple-im
Page 21 and 22: Avril 2001 IPv6, en l'absence d'une
Page 23 and 24: Avril 2001 FORMAT DE LA PRESENTATIO
Page 25 and 26: Avril 2001 Déni de service sur les
Page 27 and 28: Avril 2001 MICROSOFT Débordement d
Page 29 and 30: Avril 2001 WATCHGUARD Déni de serv
Page 31 and 32: Avril 2001 PGP Exposition de clé p
Page 33 and 34: Avril 2001 Reprise de l'avis CERT C
Page 35 and 36: Avril 2001 OpenBSD Disponibilité d
Page 37 and 38: Avril 2001 LINUX REDHAT Annonce de
Page 39 and 40: Avril 2001 MS00-098 Indexing Servic
Page 41 and 42: Avril 2001 y a quelques années ave
Page 43 and 44: Avril 2001 GET /guest/default.asp/.
Page 45 and 46: Avril 2001 Une synthèse commentée
Page 47 and 48: Avril 2001 NC 6969 3149 3163 'del s
Page 49 and 50: Avril 2001 Microsoft(R) Windows NT(
Page 51 and 52: Avril 2001 12/26/00 07:10p New Fol
Page 53 and 54: Avril 2001 C:\Program Files\Common
Page 55 and 56: Avril 2001 12/15/00 07:05p 673 lrfp
Page 57 and 58: Avril 2001 11/26/00 12:34p 0 AUTOEX
Page 59: Avril 2001 Conclusion 1. Deux vague

Veille Technologique Sécurité - cert devoteam

Create successful ePaper yourself

Delete template?

Save as template?