A Suggestion for MediaWiki

A Suggestion for MediaWiki, useful for multi-language wikis, based on my experience from Wikipedia.

The idea is to add multi-language search (exact) matches on the left panel of pages showing search results. Though this may not be feasible with the current data architecture within MediaWiki, there's no reason why it should be impossible to implement.

That would ease the look for information for people who can speak several languages. That would also stimulate the creation of articles by translation of articles from other languages. As a reminder, a big part of mankind speaks two or more languages, I'd say more than half of it.

Let's see an illustration. Figure 1: what you get when you search for "xades" on the English Wikipedia.

Figure 2: what you get when you search for "xades" on the French Wikipedia, no direct results.

Figure 3: What I suggest adding onto the search page (the French one, in this case).

À propos du ROI du BYOD

À propos du ROI du BYOD, j'ai lu cela dans Les Échos :

La généralisation du Byod (« Bring your own device », littéralement, « Apportez votre propre matériel ») impose d'établir une ligne de conduite. Enjeu de réduction des frais pour l'entreprise - supprimer un poste informatique génère un gain de 1.500 euros par an et par salarié - l'introduction dans l'entreprise de l'équipement personnel du salarié pose la question de la confidentialité des données véhiculées et de la protection des serveurs contre les cyberdélinquants.

Et là je dis attention ! Si l'on considère généralement que le coût d'un poste informatique est de l'ordre de 1 500 €, voire plus, c'est que l'on inclut dans ce coût total bien autre chose que le matériel. Le coût d'un poste informatique est composé de l'achat du matériel, qui peut être aussi bas que 300 € dans certains cas, de l'infrastructure centrale (serveurs, stockages, licences...), de l'infrastructure de distribution (réseaux internes, WiFi, accès Internet), des salaires du personnel et d'autres éléments, tels que les prestations de sociétés de services, qui peuvent représenter davantage de quantité de travail au sein d'une DSI que celle des employés à proprement parler.

Or, c'est en supposant qu'un poste traditionnel a le même coût d'entretien qu'un poste BYOD qu'on introduit une bonne dose d'erreur dans les prévisions de réduction de frais.

En effet, qui dit BYOD dit aussi :

• Nouveaux accès réseaux : extension du WiFi, mise en place systématique de VPNs...
• Mise en place d'infrastructures centrales : logiciels de gestion spécifiques aux smartphones, app stores internes, web-isation d'anciennes applications métier...
• Augmentation de l'hétérogénéité des terminaux du SI, entraînant une surcharge de travail dans l'administration, la maintenance, le help desk... Là où on avait une hyper-majorité de Windows, on obtient très vite : Windows (XP, Seven, Phone), Android, iOS (iPhones et iPads). Plus le Mac OSX d'un directeur qui y tient et les restants de BlackBerry d'il y a quelques années !
• Nouvelles compétences d'administration à acquérir. Si on a une charge de travail, il faut avoir les compétences nécessaires pour s'en acquitter. Et là où il est très facile de recruter des gens connaissant Windows et Linux, on trouve peu de monde pour les autres OS.
• Nouvelles compétences de développement à acquérir. Ce point est souvent complètement oublié par les décideurs. Tant pour l'administration que pour l'exploitation, de nombreux petits logiciels sont souvent développés par une DSI. Il va falloir acquérir les compétences sur le tas ou recourir à des formations rares ou à des prestations coûteuses.

En conclusion, je dirais que, comme le BYOD est de toutes façons inévitable,  les décideurs devraient tout particulièrement bien peser le poids financier d'une bonne uniformisation des flottes de mobiles. Le coût d'achat étant mineur dans le coût total de possession d'un terminal, l'incitation, même financière, des employés à se munir d'un modèle ou d'une marque données me semble très rentable.

Publication du Guide d'Hygiène Informatique par l'ANSSI

Suite à mon envoi de commentaires en décembre, j'ai reçu ce petit courriel de l'ANSSI :

de Communication (SSI)
à Moi

Bonjour,
L’ANSSI vient de publier le guide d’hygiène informatique.
Vous pourrez le trouver sur le site Internet de l’ANSSI : www.ssi.gouv.fr/hygiene-informatique  
N’hésitez pas à nous contacter si vous désirez recevoir le guide au format papier.
Nous vous remercions encore pour votre contribution à l'amélioration de ce guide.

Cordialement,

Le bureau communication de l’ANSSI

Alors comme ça, le guide est paru ? Histoire de mener chaque chose à son terme, je me décide à vérifier quelles remarques parmi les miennes ont été prises en compte. Il y a 28 points concrets dans mes commentaires. Résultat du parcours du nouveau guide :

64% des remarques que j'ai formulées ont été prises en compte sous une forme ou sous une autre. Il faut nuancer les 36% restants. En effet, certaines remarques s'entendent dans un contexte qui serait long à expliquer dans un tel guide. L'ANSSI doit faire des choix, aussi tout ne peut pas être retenu.

J'apprécie extrêmement le professionnalisme de certaines agences gouvernementales, notamment la CNIL et désormais l'ANSSI :

1. Publier un draft.
2. Appeler à commentaire.
3. Publier une version corrigée.
4. Remercier les personnes qui ont commenté et les inviter à télécharger le document.

Ça, c'est une façon de travailler.

Commentaires à l'ANSSI sur le guide "L'hygiène informatique en entreprise - Quelques recommandations simples"

Madame, Monsieur,
veuillez trouver ci-dessous mes commentaires, en réponse à l'appel à commentaires sur le guide "L'hygiène informatique en entreprise - Quelques recommandations simples", publié à l'adresse suivante :
http://www.ssi.gouv.fr/fr/bonnes-pratiques/recommandations-et-guides/securite-du-poste-de-travail-et-des-serveurs/appel-a-commentaires-sur-le-guide-l-hygiene-informatique-en-entreprise-quelques.html

Bien cordialement,
Christophe Pradier
http://cpradier.blogspot.com


Remarques point par point

(Les numéros se réfèrent aux numéros de règles dans vos documents.)

1.2) Ne pas oublier de situer dans la cartographie les VPN, la télémaintenance et le télétravail, qui constituent des entrées/sorties réseau à part entière.
Le lieu de stockage de la cartographie est un point intéressant. Dans un premier temps, je pense qu'il vaut mieux privilégier sa disponibilité et sa bonne mise-à-jour, en la protégeant comme un fichier "sensible", plutôt que de la tenir entièrement hors-réseau.

2) Ajouter "la liste des utilisateurs disposant d'accès à la configuration des équipements réseau".
Par ailleurs, ces inventaires, quoique fort utiles, sont lourds à maintenir. Dans mon expérience, le développement d'un ou deux petits scripts qui mettent automatiquement ces inventaires à jour est peu coûteux :
* tant vis-à-vis de l'achat de logiciels complexes sur la gestion des droits,
* de la maintenance manuelle de ces inventaires,
* que de l'absence de ces inventaires.

3.4) Expliciter le concept : "mécanismes DE gestion DU contrôle DES habilitations". C'est une chaîne logique loin d'être évidente pour des néophytes.

5) Il faudrait préciser de quels "équipements personnels" l'on parle : smartphones, laptops, clés USB, clés 3G, wifi du voisin ?

6.1) OK pour le côté client. Côté serveur, il faut également recenser (a minima) les OS, les middlewares et les bases de données.

9) Dans le tableau "checklist" seulement, les points 9.1) et 9.2) sont redondants avec le 3.1). Le point 9) du document texte "guide" est mal repris dans le tableau "checklist".
Par ailleurs, il faudrait préciser si la règle 9) s'entend uniquement pour le référentiel d'identité principal (Active Directory en environnement Microsoft) ou également pour les référentiels secondaires et applicatifs.

10) Les règles 10.2) et 10.5) ne sont pas et ne seront probablement jamais respectées en PME. Dans des environnements PME, il est plus efficace (cad respecté de façon homogène) de supprimer 10.1), 10.2) et 10.5), d'imposer un mot de passe unique mais fort et de le changer une fois par an.
Ajouter une règle 10.7) "Si un mot de passe a été transmis, le changer aussitôt." qui tombe sous le sens mais n'est pas listé dans vos documents. Ça va sans dire mais ça va mieux en le disant.

11) Les règles 11.2) et 11.3) sont rarement à la porte technique et financière des PME intéressées par ce guide d'hygiène.

12.1) et 12.2) Préciser que "ne pas autoriser" correspond à une démarche managériale de contrôle et de discipline, pas à un ensemble de mesures techniques.
12.3) L'utilisation de SSO est très discutable. Bien implémenté un SSO, même un simple SSO de navigateur web, peut aider à augmenter la sécurité. En l'absence d'un vrai "projet SSO", il vaut mieux, tristement, interdire cette fonctionnalité.

13) Remplacer "bien souvent" par "toujours". Inutile de minimiser ce problème de fond gravissime.
13.3) N'est pas à la portée technique et financière des PME intéressées par ce guide. Sur les 15 (chiffre factice) référentiels importants de la PME, on aura les outils pour procéder au contrôle sur 2 ou 3, pas plus.

14) Insérer un 14.3) Interdire l'utilisation d'un code PIN par défaut. Idem : interdire l'utilisation d'un code SOPIN par défaut.

17) C'est un investissement de départ élevé mais tout à fait valable. Par contre, les solutions du marché souffrent d'être souvent spécifiques à un fabricant donné. Il faut faire des choix.

18) Là aussi, problème des produits vendor-specific.
18.2) Qu'entend-on précisément dans ce paragraphe par "politique de sécurité" ?

19.8) Ce point est difficile à réaliser en pratique. Un moindre mal pourrait être de s'assurer que le compte courant du téléassistant ne dispose pas de droits d'administration.

19.9) Ce point me semble trop technique pour une PME néophyte. Des produits recommandés seraient une meilleure option.

19.12) Qu'entendez-vous par "l'ensemble des opérations de téléassistance" ?
* Si vous entendez "l'ensemble des sessions, horaires, acteurs...", OK.
* Si vous entendez "l'ensemble des actions effectuées, dans le détail", alors c'est complètement infaisable. En particulier dans le contexte 19.1) et 19.2), en raison de la nature extrêmement diverse des interactions possibles, a fortiori pour des PME néophytes.

21.2) Un compte individuel ou... plusieurs pour les administrateurs.
Plutôt que de disposer d'un compte "jean.dupont" individuel et d'un compte "administrateur" partagé, il vaut souvent mieux disposer d'un "jean.dupont.admin" nominatif et en profiter pour désactiver le compte partagé "administrateur".

24.3), 27.1), 27.2) et 27.3) Qui dit supervision dit ressource humaine pour superviser. Il faudrait donner une règle simple pour déterminer quelle masse RH consacrer à la question.

24.4) Cette question est très technique et nécessite des implémentations différentes selon les "passerelles d'interconnexion". Pour connaître les machines *internes*, il est souvent avantageux de faire appel tout de même au DNS, car elles sont gérées par DHCP automatique.

28.1) Vaste et abstrait, pour un néophyte.

30) "Ne surtout pas faire d’exception pour les dirigeants de l'entreprise", insérer "ni pour les télétravailleurs."

32) et 33) Dans les entreprises, la sûreté des locaux est souvent traitée par un service différent de la sécurité informatique. Il serait bon de préciser que les responsabilités doivent être clarifiées et que les services doivent travailler ensemble.

36) Ajouter de toujours informer le RSSI d'une infection, même mineure, même traitée sans difficulté, ne serait-ce que pour information statistique.

37.0) + "Quelles sont les activités métier à redémarrer en premier ?"

38) + "Les utilisateurs, quand ils signalent un incident, doivent être remerciés et tenus scrupuleusement au courant de la bonne prise en compte/résolution/date prévue de résolution de l'incident."

39.1) Dans le tableau "checklist", la phrase est incomplète, il manque un verbe.

40) Pour une PME néophyte, sur quelle base demander un audit ?


Remarques générales

1/ Tous les points abordés dans vos documents sont valides mais trop abstraits pour être abordés par des néophytes. En effet, si une entreprise est à même d'embaucher un RSSI expérimenté à plein temps, elle n'aura pas besoin d'une telle méthodologie simplifiée. Elle s'adresse donc aux PME qui abordent pour la première fois une démarche de sécurité.
La solution est d'illustrer un minimum les points abordés, en précisant bien que les exemples sont non-limitatifs.

2/ J'ai précédemment abordé la question d'une méthodologie de sécurité adaptée pour les PME dans l'article :
http://cpradier.blogspot.fr/2011/02/draft-step-by-step-security-approach.html

3/ Retour sur le 22.1) Un document de récapitulation sur les principes de DMZ, de cloisonnement... et leur mise en pratique serait particulièrement bénéfique. Sous prétexte de cloisonner et sous la pression de prestataires de services parfois peu scrupuleux, les PME cloisonnent tout et n'importe quoi, sauf souvent l'essentiel.

Appel à commentaires sur le guide : « L’hygiène informatique en entreprise - Quelques recommandations simples »

L'ANSSI lance un appel à commentaires :

Protéger les données et le réseau informatique des entreprises est aujourd’hui crucial pour leur survie et leur compétitivité. A cette fin, l’ANSSI a réalisé un guide d’hygiène informatique destiné aux entreprises et présentant 40 recommandations simples pour sécuriser leur(s) systèmes d’information.

Afin qu’il puisse répondre à vos attentes et besoins, l’ANSSI souhaite recueillir votre avis sur ce projet.

Les observations, commentaires et propositions de modifications pourront être envoyés jusqu’au 15 novembre à l’adresse suivante :

communication [at] ssi.gouv.fr

Guide d’hygiène inform­atique
PDF - 651.3 ko

Check List
PDF - 265.3 ko