1 Le référentiel général de sécurité (RGS) entre en application
Dans le cadre du développement de l'administration électronique, un référentiel général de sécurité a été élaboré par l'Agence nationale de la sécurité des systèmes d'information (ANSSI) en liaison avec la Direction générale de la modernisation de l'État (DGME). La sécurité des procédures dématérialisées est en effet un enjeu crucial tant pour les autorités administratives elles-mêmes que pour leurs usagers, et la confiance de ces derniers est essentielle à l'essor de l'administration électronique.
L'arrêté du Premier ministre portant approbation du RGS a été publié au Journal Officiel le 18 mai 2010. Il fait entrer en application ce référentiel qui définit les règles de sécurité et les bonnes pratiques pour dématérialiser les procédures administratives en garantissant leur fiabilité et la sécurité des données échangées.
Le RGS s'adresse à toutes les autorités administratives (administrations de l'État, collectivités territoriales, établissements publics à caractère administratif, organismes gérant des régimes de protection sociale et autres organismes chargés de la gestion d'un service public administratif), en particulier à la maîtrise d'ouvrage (MOA), à la maîtrise d'œuvre (MOE) et aux responsables de sécurité des systèmes d'information (RSSI). Au-delà des autorités administratives, ce document intéresse également les éditeurs de services de sécurité et les prestataires de services de confiance.
Le corps du document donne des lignes directrices d'une politique de sécurité pour chaque système d'information. D'un point de vue technique, le RGS examine et donne les règles à suivre concernant notamment les différentes fonctions de sécurité, les politiques de certification ou encore le choix des mécanismes cryptographiques, la gestion de clés et l'authentification.
Les règles et recommandations du RGS devront être appliquées dans un délai de trois ans pour les téléservices et systèmes en service, dans un délai d'un an pour ceux en cours de réalisation, et d'emblée pour les téléservices et systèmes déployés après octobre 2010. Nombre de ces règles et recommandations sont d'ores et déjà mises en œuvre par des autorités administratives dans le cadre de téléservices existants.
Documentation :
- Brève et communiqué de presse de l'ANSSI :
http://www.ssi.gouv.fr/site_article228.html
- Référentiel général de sécurité : document de présentation, documents concernant l'utilisation de certificats électroniques dans les fonctions de sécurité, documents concernant l'utilisation de mécanismes cryptographiques dans les fonctions de sécurité :
http://www.ssi.gouv.fr/rgs
- Contacter l'ANSSI au sujet du RGS : rgs@ssi.gouv.fr
2 Qu'est ce que le tabnabbing ?
Cette semaine, un employé de la société Mozilla a publié sur son blog une nouvelle approche pour le filoutage accompagnée d'une preuve de faisabilité.
Cette nouvelle méthode, baptisée « tabnabbing », permet de profiter de la navigation par onglet de certains navigateurs afin de tromper la vigilance de l'utilisateur.
Le principe de cette attaque est le suivant :
- un utilisateur navigue sur un site malveillant via un onglet de son navigateur ;
- l'utilisateur change d'onglet afin d'aller visiter un autre site ;
- le site malveillant profite que l'utilisateur n'est pas actif sur son site ou ne visionne plus la page pour déclencher un JavaScript et complètement refondre l'aspect visuel de la page qui était visitée ;
- cette modification se fait afin de tromper l'utilisateur et usurper l'apparence d'un site filouté (webmail, site bancaire, de commerce en ligne, réseau sociaux, ...) ;
- l'utilisateur peu attentif, revenant sur l'onglet malveillant précédemment ouvert, peut ainsi être trompé et penser que sa session a expirée ou qu'il a oublié de se connecter au site filouté ;
- il ne reste plus à l'attaquant qu'à intercepter les données saisies par la victime, les enregistrer et éventuellement rediriger le malheureux visiteur vers le véritable site.
Même si l'approche est tout à fait originale pour une attaque de type phishing, le CERTA rappelle quelques principes de base et vérification à effectuer afin de ne pas être victime de ce genre d'escroquerie :
- toujours désactiver par défaut l'interprétation des codes dynamiques (JavaScript, Flash, ActiveX, ...) sur des sites qui ne sont pas de confiance ;
- s'assurer que l'adresse URL affichée correspond bien à celle du site légitime ;
- toujours utiliser les versions sécurisées des sites Internet nécessitant une authentification ou la saisie de données personnelles et vérifier la cohérence du certificat présenté avec l'identité du site ;
- toujours utiliser un système d'exploitation, un navigateur et des modules ou extensions parfaitement à jour et un compte utilisateur aux droits limités.
3 Domotique et SSI
Cette semaine, un avis de sécurité sur un produit un peu particulier a été publié sur le site du CERTA : l'avis CERTA-2010-AVI-229 intitulé « Multiples vulnérabilités dans Cisco Network Building Mediator ».
Le Cisco Network Building Mediator est une solution complète de domotique sur IP, permettant un contrôle via le réseau des fonctions de gestion du chauffage, de la climatisation, du contrôle d'accès, de l'éclairage...des bâtiments. Le taux de pénétration de ces solutions est en forte croissance, car les promesses sont très intéressantes : meilleure gestion des bâtiments, pilotage centralisé, maintenance facilitée. Malheureusement, la sécurité de ces produits doit être parfaitement vérifiée, car il s'agit d'un point critique non seulement pour le bon fonctionnement, mais aussi pour la sécurité même des personnes.
L'avis de sécurité publié cette semaine est à ce titre particulièrement critique, car ce produit souffre de multiples vulnérabilités qui pourraient permettre à un attaquant une prise de contrôle totale, à distance, de ces systèmes. Il ne faut pas oublier que même si les fonctions informatiques sont enfouies ou peu visibles, comme c'est le cas dans des solutions de type informatique industrielle ou domotique, la protection contre les attaques ne doit en aucun cas être oubliée. La société Cisco a publié un avis de sécurité, il est donc indispensable d'appliquer au plus tôt le correctif adapté. D'une façon général et quelle que soit la marque des produits utilisés, il ne faut pas les omettre dans votre politique de sécurité, et bien surveiller la bonne mise à jour et l'application des correctifs de sécurité de ces solutions.
Documentation
- Avis CERTA-2010-AVI-229 :
http://www.certa.ssi.gouv.fr/site/CERTA-2010-AVI-229/
4 Migration vers OpenBSD 4.7
La dernière version (4.7) du système d'exploitation OpenBSD a été publiée le 19 mai 2010. Cette version apporte son lot de nouveauté parmi lesquelles on trouve une modification dans le pare-feu intégré : Packet Filter. En effet, la syntaxe dans le fichier de configuration pf.conf nécessaire aux règles de translation d'adresse ou NAT a totalement changé. Ainsi les directives : nat, rdr, et binat ont toutes été remplacées par une seule et nouvelle directive : match.
Vous pourrez trouver les exemples et les explications de sur la nouvelle syntaxe à la page : http://openbsd.org/faq/upgrade47.html.
