Le bienfaiteur anonyme dans le nuage

Je viens d'apprendre l'histoire horrible du suicide d'Amanda Todd, cette jeune Canadienne qui a été persécutée sur les réseaux sociaux par un inconnu qui savait tout d'elle. Pour mieux comprendre l'histoire, autant l'écouter elle-même quand elle présente son cas, peu avant son suicide :



Qu'en dire ?
Le taux de suicide des jeunes est de l'ordre de 0,5 à 3 sur 10 000 dans les pays développés. Les taux de tentatives de suicide sont encore plus haut. Et ceux de comportements à risques mortels en toute connaissance de cause sont encore encore plus haut. Aussi, le suicide en soi ne m'étonne pas.

Ce qui m'étonne par contre pour cette pauvre malheureuse, c'est surtout qu'elle n'ait pas trouvé à rebondir alors que ses parents étaient au courant (déménagements, changements d'école) et qu'elle-même semblait avoir bien conscience du problème.

Facebook dans l'affaire ?
L'internet et les réseaux sociaux ne me semblent statistiquement pas un terreau digne d'un intérêt spécifique dans la lutte contre le suicide. Par contre, le rapport de cette fille en particulier à ces médias mérite d'être étudié. La mise en scène de son propre cas est un phénomène étonnant, proche de la mise en scène du suicide. Non pas un appel à l'aide mais un rejet de la honte sur les autres. Je ne suis pas médecin mais je pense que c'est un sujet d'intérêt.

Surveiller l'usage des réseaux sociaux ?
Des collègues ou des relations qui connaissent mes activités professionnelles m'ont souvent interrogé sur la façon de mieux surveiller leurs enfants. Ils sont inquiets de ce qui peut passer inaperçu sur les réseaux sociaux. La crainte du violeur ou du kidnappeur rencontré sur internet est omniprésente, la crainte aussi que l'enfant ait simplement trop de "mauvaises fréquentations" qui lui ruineraient la vie.

Ma première réaction est toujours de bien clarifier que je suis RSSI d'entreprise, pas RSSI familial. Je suis professionnel, on ne se refait pas.

Ma seconde est de rappeler que rien ne remplace une vraie relation de confiance avec l'enfant. S'il vient demander conseil, s'il ose parler de ses doutes, de ses peurs, s'il ose avouer ses maladresses avant que le pire ne soit arrivé, alors le risque sera réduit de beaucoup. (Note : c'est la même chose en entreprise entre le RSSI et l'informaticien. Une relation de confiance est primordiale.)

Et si le réseau social participait à la lutte contre le suicide ?
C'est une remarque d'informaticien : on sait faire de la publicité ciblée, on sait corréler les informations reçues de divers réseaux sociaux, pourquoi ne mettrait-on pas en place des robots, des applis iPhone, Android ou Facebook, qui préviendraient les services SOS Suicide d'une personne qui pourrait passer à l'acte ? Il y a clairement des signes avant-coureurs qui pourraient être récoltés par le cloud.

Divers cas d'usage et d'utilité peuvent être envisagés :

• Détection automatisée des personnes à risque,
• Premiers secours automatisés ou accélérés,
• Transfert automatisé ou accéléré du cas à des contacts de proximité de la personne,
• Récolte en ligne de données-clés permettant de connaître mieux et plus vite le cas de la personne,
• Prévision de rechute ou de passage à l'acte pour des personnes connues,
• Étude statistique des facteurs clés qui peuvent contribuer au comportement suicidaire (par recherche des similarités entre les cas).

Ainsi, le réseau social ne serait plus seulement l'outil du tortionnaire mais aussi celui du médecin. Plus seulement un lieu où le réseau amoncelé renforce la pression sociale et les préjugés mais aussi un lieu où l'on casserait les cercles vicieux en mettant à profit l'irruption possible d'un bienfaiteur anonyme.

La peur du Cloud : réinterprètons !

Une remarque pour les blogueurs du Cloud qui s'appuient sur des enquêtes statistiques du type : opinion des DSI.
Il faut réinterpréter la « peur du Cloud » : quand un DSI dit que la sécurité du Cloud est sa première préoccupation, il ne veut pas dire que la confidentialité, l'intégrité ou la disponibilité du Cloud lui font peur. Il veut dire que la pérennité des habitudes, des services et des budgets de sa DSI sont menacés par le Cloud.
C'est une peur rationnelle : comme beaucoup de managers expérimentés, il a surtout peur que les choses changent trop vite et qu'elles ne soient plus contrôlables.
Alors, à mon avis, il faut nuancer les chiffres sur la peur de l'insécurité dans le Cloud.

Security ROFL 8

• French public job platform going unavailable because of too many requests, on the very day people are asked to update their personal situation to get unemployment benefit. The screenshot below reads "Our services are currently unavailable because of a high level of request. We kindly ask you to excuse us. We advise you to connect later." Either they're getting DoS'ed or they just self-slashdot themselves.

• Hackers Reveal How They Accessed Syrian President Bashar Assad's Email Using World's Worst Password. The password, of course, was 1234.
• Dilbert's "preventer" Mordac goes crazy:

• Security technologies are even in video games nowadays : Blizzard inserts watermarks into all game screens so that screenshots allow them to track (identify, at least) users.

Coded TCP va booster les performances de nos réseaux

Lu cela ce matin sur le blog de Korben : Coded TCP va booster les performances de nos réseaux.

Ledit Coded TCP est une évolution du protocole TCP dédiée aux réseaux à perte de paquets, genre Wifi, qui en envoyant les paquets différemment permet d'éviter les erreurs TCP et donc autorise des gains substantiels en débit pour des cas d'usage TCP (web et autres).
Les auteurs, des chercheurs du MIT et de Caltech, annoncent des tests où des débits effectifs de 1 Mbps sont passés à 16 Mbps grâce à Coded TCP.

Comment ça marche ?

Supposons que l'on veuille envoyer une série de n paquets TCP.

L'envoyeur choisit alors r séries de n coefficients (pour r combinaisons linéaires des contenus des n paquets du message entier), avec r >= n.
D'après l'étude statistique empirique des auteurs, un rapport r ~= 1,1 n est une valeur idéale.
L'envoyeur partage avec le destinataire les r  x n coefficients de ces combinaisons linéaires.

L'envoyeur envoie un par un les r paquets codés avec pour chacun comme contenu la combinaison linéaire correspondante des n paquets originaux.

Le destinataire déduit les n paquets originaux à partir des r paquets codés et de la table des coefficients.

Comme r >= n, on peut deviner les n paquets même s'il en manque. C'est un simple jeu d'équations linéaires à inconnues multiples. (Théoriquement, si les coefficients sont bien choisis, il peut même manquer r - n paquets.)

Remarque : Si on avait r = n, on obtiendrait un résultat équivalent à TCP, avec en plus des kilos de multiplications et d'additions.

Un des intérêts principaux est que l'on peut attendre d'avoir reçu (ou mal reçu) les r paquets avant de se rendre compte, la plupart du temps, que l'on a bien reçu tout le contenu des n paquets. Tandis qu'avec le protocole TCP original, dès qu'un paquet est manquant, le receveur se met en erreur jusqu'à ce que l'envoyeur le lui renvoie, dans l'ordre...

Supposons un fichier de 6ko envoyé par TCP. Il est coupé en quatre paquets 1 2 3 4 de 1,5ko chacun. Si le second paquet est perdu, le destinataire va se mettre en erreur, le temps que l'envoyeur reprenne là où ça s'était arrêté.

• Côté envoyeur : 1 2 3 4 2 3 4.
• Côté destinataire. OK1 Timeout2 KO2 KO2 KO2 OK2 OK3 OK4.
• Le total est de 7 paquets lourds + 8 paquets légers de réponse. Le fichier est transmis en un temps 7 RTT + 1 timeout TCP. Ça, c'est TCP.

 La même chose avec Coded TCP en prenant n = 4 et r = 5 :

• Côté envoyeur : 1 2 3 4 5.
• Côté destinataire : OK1 [rien pour 2] OK3 OK4 OK5. Et on recalcule le 2 manquant à partir des quatre autres paquets.
• Le total est de 5 paquets lourds + 5 paquets légers de réponse. Le fichier est transmis en un temps de 5 RTT + 0 timeout. Ça, c'est Coded TCP.

C'est un exemple volontairement simpliste (avec notamment l'hypothèse simplificatrice comme quoi 1 timeout TCP a une durée égale/voisine d'un RTT sur le réseau considéré) mais les résultats sont meilleurs encore si on choisit n et r supérieurs, comme ce serait le cas dans des situations quotidiennes d'usage d'un Wifi.

Le PDF complet des auteurs de Coded TCP est dispo, en anglais bien sûr.

Two-Factor Authentication with a Smartphone

Passwords are now depleted. We used them too much and we need something else. That's my feeling since a few years.
I just hit upon the article by Randall Stross "Doing the Two-Step, Beyond the A.T.M." among the New York Times news. The article first compares using a PIN code to using a password, just like I did some time ago. It then goes into suggesting the generalization of two-factor authentication with the help of a smartphone. Clearly, there's a need and a market here.

Whatever the solutions that will come up in the next years, they'll have to face the following challenges:

1. Be user-friendly enough.
2. Be applicable both for individual use and for corporate use (at least, integrate in BYOD processes).
3. Allow for safe backup methods in case you lose one of the two factors, for instance, a stolen smartphone.
4. Allow for Single Sign-On : avoid user-side repetitions.
5. Allow for federation : avoid server-side repetitions, like maintaining similar lists of users in multiple applications.
6. Allow for automated patches/updates. There will be flaws in the beginning, that will require patching.

Guest Post: Le sentimancho, comment soutenir ?

Ce billet est écrit par Jice.

En ce moment se tient sur le web un concours de référencement dont le mot-clé cible est 'sentimancho'. Pour vous faire mieux comprendre de quoi il retourne, je vous propose un petit billet mi-explicatif, mi-satirique. J'espère que les explications données en demi-teinte vous donneront l'envie d'en savoir plus sur le référencement.

Le sentimancho : sa définition

L'expression "sentimancho' a été créée dans l'objectif de permettre l'existence d'un concours de référencement en France. Qui dit référencement souligne la nécessite de se placer de façon idéale en première position des moteurs de recherche, de façon plus réaliste de faire en sorte que son classement sentimancho apparaisse déjà dans les deux premières pages du classement.

C'est en écrivant des textes de qualité sur son site internet par exemple qu'une bonne indexation devient possible. Une autre méthode consiste en partenariats avec des amis ou connaissances. Inutile de se tourner vers des techniques de référencement utilisant le spam à outrance. Polluer le web n'aidera en rien à se démarquer des ses compétiteurs !

Ce genre de pratiques absolument répréhensibles se détourne volontairement d'un usage optimisé du web pour des raisons mercantiles. Peu leur importe la consommation énergétique d'une recherche sur Google !

Que faire pour soutenir le vrai sentimancho ?

Il est possible de l'aider ce vrai sentimancho, le sentimancho élevé dans la nature. Sans soutien, il ne sera rien, son existence est menacée. Alors impliquez-vous !

• Vous aimez rendre service ?
• La nature et sa protection sont un combat que vous aimez livrer ?
• Le spam vous semble une méthode à proscrire ?
• Vous avez envie de rédiger sur le référencement ?

Publiez donc un texte sur votre blog sur la thématique suivante, référencement et/ou sentimancho et linkez sur Presstor.fr en suivant les instructions suivantes :

<a href="http://www.presstor.fr" title="sentimancho">sentimancho</a>

Un bon adjuvant à un référencement organique du site et un geste positif pour l'environnement web.

The State of Open-Source Monitoring

I've found this excellent presentation and comparison of opensource monitoring tools by Jason Dixon (GitHub). It's a must-read if you sometimes wonder what tool to choose, among the vast number to choose from.

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

Is Android the New IBM PC Compatible?

(translated from the French article) 

Above is a map giving the date when, for the first time, country by country, web searches related to Android have exceeded those related to iPhones and iPads. The color key is on the left.
Grey means that it hasn't happened yet. White means there was not enough data (approx. 2% of world population).

For information, I made this map with The GIMP, based on graphs from Google Trends comparing the number of web searches containing the names of the various Android smartphones and tablets, iPhones and iPads. The map background is from www.histgeo.ac-aix-marseille.fr. All demographic data used below is from the CIA Fact Book.

First, some facts:

1. The trend is worldwide. It's not yet over but actually present everywhere: searches about Android do exceed those about Apple smartphones, showing a greater interest in the products based on the Google environment.
2. The date when the Google trend exceeds the Apple trend is an interesting criterion to be put on a world map, because it's highlighting clear patterns.
3. In terms of compared populations, thus in terms of potential markets, this is a major trend, as is showing the demographic count below.

Census :

• early adopters of Android (yellow and red) : 22.4%
• happy followers (green) : 11.1%
• followers (blue) : 27.2%
• laggards (grey) : 37.2%
• no data (white) : 2.1%

I can identify the following patterns:

• Mid-developed countries are the first to adopt. Look on the map: Central Europe, India, Indonesia, South America.
• Then come the other developing countries, especially Africa and former USSR.
• Developed countries are the laggards. West Europe, United States, South Africa, Japan, Australia.

With notable exceptions:

• Why is Germany among early adopters ? I think that the current actual economic success of Germany resides in its industrial relations with Central Europe. Such relations make that the interests are common and web searches follow.
• Same for France, dragging Morocco, Algeria and Tunisia towards Apple.
• Same for South America dragging Spain and Portugal towards Android.
• The following countries would need further explanations that I cannot provide: China, Myanmar, Thailand, Cambodia, Laos, Vietnam. I don't have the necessary knowledge about this region to make assumptions. I think that the reasons why China is late and the impacts of it would merit a whole article by themselves.

Starting from the following hypotheses about Android's most attractive features:

• The relative freedom of its environment.
• The low cost of tablets.
• The diversity of makers and vendors, thanks to Google's policy about it.

I deduce the following:

• There is a real mass market to be taken by Google in new developing countries.
• It's developing countries best interest to push a company that allows reuse, adaptation, competition and enhancement, rather than conforming to closed Apple platforms (thinks about the markets created by the IBM compatible PC in 1981).
• The diversity of actors and thinking heads in developing countries will ensure that Android soon becomes a more diverse and useful ecosystem than that of iOS or even that of Windows on PC or even than anything we have known so far (here again, think about the growth of the PC).
• The direct earnings from making and selling this ecosystem, added to the indirect gains related to just using a better ecosystem, will broadly influence the economies of those early adopters countries and the best among them will probably overtake West countries in terms of technological progress (think of how the US profited from the PC boom).
• Central Europe is certainly the best place to invest industrially right now. early adopters + relatively low costs + stable democracies + known and mastered history and management culture + availability of experienced West Europe managers if needed + European infrastructures + neighbourhood of West European markets + proximity of Turkey for even lower cost of manufacture if required.

Saving Money with IT Security Processes. Example 13/26: Avoid Misleading Vendor Advice with Security Awareness

Article number 13 in a series dedicated to giving examples of the way IT security processes can help your company save money.

Vendors are doing their job: they try and sell security solutions and services. Ideally, they prefer to sell solutions rather than services. It's more concrete, more helpful to convince non-security people and it implies additional services in order to implement and maintain them.
In order to do so, they demonstrate the profitability by showing critical examples of security breaches and/or outages. This could be a kind of Awareness if it weren't so biased. It's biased to:

• Concentrate fear on the subject that's addressed by the solution they're trying to sell. (Whereas the subject may not be a major concern for the company nor even a concern at all.)
• Concentrate fear on the little points in the whole subject that the solution actually helps solving. (Letting 95% of the actual subject unsolved.)

CISOs are used to this kind of manipulation. They just go though it without even noticing anymore. For instance, as a CISO, I used to receive every day up to 30 dedicated e-mails from real people I actually met before. I didn't mind.

So, in order to still sell "solutions", vendors attack easier targets: high placed executives outside of IT Security. More precisely, they try and sell solutions wherever the CISO cannot constantly reach:

• IT managers of remote sites where there is no permanent security team,
• Users of packaged "IT tools not considered IT" like Telephony, Document Management, Technical Services from Logistics...
• People interested in closely related matters: Quality, Compliance.
• And sometimes even through service providers!

That's the costly point. If vendors are able to sell solutions, they'll sell unfit solutions:

• Costly,
• Uneffective,
• Ill-centered on minor points,
• Duplicate with what's already implemented,
• Sometimes completely irrelevant...

Through a correct Awareness process, you'll not only touch end-users, but also management. It does the following:

• Communicate around what you already do, → no more duplicates
• Communicate around what you don't do and why (we'll do it later, we don't do it because it's not relevant, it's not a major concern), → no more irrelevant solutions.
• De-mystify buzzwords, → no more ill-centered solutions.
• Communicate about real threats and the associated risk.→ no more haste resulting in cost-ineffectiveness.

Android est-il le nouveau PC compatible IBM ?

Ci-dessus une carte donnant la date à laquelle, pour la première fois, pays par pays, les recherches web concernant Android ont dépassé celles concernant iPad et iPhones. Se reporter à la colonne de gauche pour la légende. En gris les pays pour lesquels ce n'est pas encore arrivé.
En blanc ceux pour lesquels je ne disposais pas de données suffisantes (environ 2% de la population mondiale).

Pour info, j'ai fabriqué cette carte avec The GIMP à partir de graphes Google Trends comparant le nombre des recherches web contenant les noms des différents téléphones Android, iPhone et iPad. Le fond de carte vient de www.histgeo.ac-aix-marseille.fr. Les démographies que je compare ci-dessous sont issues du CIA Fact Book.

En premier lieu, quelques faits :

1. La tendance est mondiale. Elle n'est pas encore achevée mais bel et bien présente partout : les recherches concernant Android dépassent celles concernant les smartphones Apple, montrant un intérêt supérieur pour les produits à base d'OS Google.
2. La date à laquelle la "tendance Google" dépasse la "tendance Apple" est un critère intéressant à positionner sur une carte mondiale. En effet, elle met en valeur des motifs clairement identifiables.
3. En termes de masses de populations et donc en termes de marchés potentiels, cela n'a rien d'insignifiant, comme le prouve le compte démographique ci-dessous.

Compte démographique :

• early adopters d'Android (jaunes et rouges) : 22.4%
• happy followers (verts) : 11.1%
• followers (bleus) : 27.2%
• laggards (gris) : 37.2%
• no data (blanc) : 2.1%

 J'identifie les tendances suivantes :

• Les pays en bonne voie de développement sont les premiers à adopter. Voyez : Europe Centrale, Inde et Indonésie, Amérique du Sud.
• Puis viennent les autres pays en voie de développement, notamment Afrique et pays d'ancienne URSS.
• Les pays développés sont les retardataires. Voyez : Europe de l'Ouest, États-Unis, Afrique du Sud, Japon, Australie.

Avec toutefois des exceptions notables :

• Pourquoi l'Allemagne et l'Autriche sont-elles parmi les early adopters ? Je propose la véritable réussite allemande actuelle qui consiste à utiliser à plein profit la proximité avec l'Europe Centrale. Ainsi, les échanges sont tels que les préoccupations sont communes.
• Même chose pour la France et ses partenaires commerciaux majeurs, anciennes colonies, que sont le Maroc, l'Algérie et la Tunisie.
• Même chose pour l'Espagne et le Portugal, qui ont des préoccupations communes avec leurs rejetons géants d'Amérique du Sud.
• Reste à comprendre la zone Chine, Birmanie, Thaïlande, Cambodge, Laos, Vietnam. Je n'ai pas les connaissances nécessaires pour faire des hypothèses sur cette zone. Les tenants et les aboutissants de cet étonnant retard de la Chine mériteraient un article à eux seuls.

En partant du principe que trois des atouts d'Android sont :

• La relative liberté de son environnement.
• Le prix bas des tablettes.
• La diversité des fabricants et revendeurs, grâce à la politique Google sur ce sujet.

Je déduis les éléments suivants :

• qu'il y a un réel marché de masse à prendre par Google,
• que les pays en développement ont tout intérêt à appuyer un fabricant qui autorise la réutilisation, l'adaptation, la compétition et l'amélioration, plutôt que d'adopter les plateformes fermées d'Apple (pensez à la libération du compatible IBM en 1981),
• que la diversité des acteurs et le nombre de têtes pensantes dans ces pays vont bientôt faire d'Android un écosystème plus varié et plus utile qu'iOS, que Windows sur PC, voire que tout ce que nous avons connu jusque-là (là aussi, pensez essor du PC),
• que le gain direct lié à la fabrication et la commercialisation de cet écosystème, ajouté au gain indirect lié à l'utilisation de ce meilleur écosystème, vont largement influer sur l'économie des pays early adopters et que les meilleurs de ceux-ci vont rattraper ou dépasser les pays occidentaux en termes d'avance technologique (là encore, pensez essor du PC),
• que l'Europe Centrale est certainement le meilleur endroit pour investir à l'heure actuelle. early adopters + coûts assez bas + démocraties stables + historique et culture managériale connue + disponibilité de nombreux managers de l'ouest expérimentés à l'est + infrastructures européennes + proximité des marchés ouest-européens + proximité de la Turquie pour des coûts de main-d'œuvre plus bas si nécessaire.

Saving Money with IT Security Processes. Example 12/26: Avoid Website Defacement with Vulnerability Management

Article number 12 in a series dedicated to giving examples of the way IT security processes can help your company save money.

Vulnerability Management is the process that helps your information system stay up to date with patches that fix vulnerabilities in the software you use. One striking example is: with correct Vulnerability Management, you won't get any of your websites defaced.

Please note that it can't be reduced to just using another piece of software to update it all. No single piece of software can possibly fix everything on a regular basis, nor can it fix problems with the best acumen. It's the Vulnerability Management process. It does the following:

• Technological Watch for all currently used pieces of software and technologies. This means subscribing to newsletters or feeds from every single related vendor and reading them.
• Whenever a new vulnerability has been spotted, identify whether the company is affected or not.
• If it's affected, check how much it would cost to suffer from the exploitation of the vulnerability and compare with the cost of applying the patch or workaround.
• Have it put in action.

The Vulnerability Management process is not always identified as a process per se, but sometimes distributed in the Technological Watch and Patch Managements processes.

Friday Liberty Blogging - Death of a Robot

Just hit upon an old French song, "The Death of a Robot", by Daniel Balavoine, in 1980. It's amazing to think how up-to-date it is. Could very well be the original soundtrack of WALL-E. Here is a personal translation:

Tout articulé tout fabriqué Bien programmé pour vous aider Je suis robot depuis plus de 2 000 ans J'ai déplacé tous les océans C'était urgent, je le savais J'ai réinventé le cycle des saisons Et vos déserts sont pleins de poissons Je sais, mes circuits sont usés J'ai beaucoup travaillé Faudrait les remplacer Me laissez pas tomber Oh ! oh ! oh ! J'ai toujours dominé mes envies Je n'ai jamais trahi Jamais désobéi Vous me devez la vie Vous me devez la vie Avant la dernière guerre atomique Si pathétique que j'ai pleuré J'avais réuni le conseil des savants Le danger, c'est votre politique Vos présidents sont dépassés Mais avant qu'un fou n'appuie sur le bouton Quittez la terre il est encore temps Et la terre vous l'avez quittée Mais moi, je suis resté Quand vous étiez là-haut Et je vous ai sauvés Oh oh oh Si vous voulez m'assassiner Après ce que j'ai fait Moi qui vous ai aimé Je peux tout faire sauter Oh ! oh ! oh ! Pas de problèmes pour me soigner Vous m'avez fabriqué J'ai appris à pleurer Je vais apprendre à tuer Oh ! oh ! oh ! J'ai beaucoup travaillé J'ai beaucoup travaillé...

All jointed all fabricated Well programmed to help you I've been a robot for more than 2,000 years I displaced all oceans It was an emergency, I know it I reinvented the cycle of the seasons And your deserts are now full of fish I known, my circuits are overused I've worked so much They've got to be changed Don't ditch me Oh! oh! oh! I always controlled my desires I never betrayed you Never disobeyed You owe me life You owe me life Before the last nuclear war So pathetic it made me cry I gathered the council of scientists The danger is your politics Your presidents are obsolete But before someone crazy pushes the button Leave the earth while it's time And the earth you left But I remained When you were up there And I saved you Oh! oh! oh! If you want to assassinate me After all that I've done That I've loved you I can blow up everything Oh! oh! oh! Never mind healing myself You created me I've learnt to cry I'll learn to kill Oh! oh! oh! I've worked so much I've worked so much...

Note for Myself: List of Security Certifications and Related

By (ISC)²:

• SSCP - Systems Security Certified Practitioner
• CAP - Certified Authorization Professional
• CSSLP - Certified Secure Software Lifecycle Professional
• CISSP - Certified Information Systems Security Professional

By ISACA:

• CISM - Certified Information Security Manager
• CISA - Certified Information Systems Auditor
• CGEIT - Certified in the Governance of Enterprise IT
• CRISC - Certified in Risk and Information Systems Control

By Cisco:

• CCNP - Cisco Certified Network Professional
• CCNA - Cisco Certified Network Associate

By Microsoft:

• MCSE - Microsoft Certified Systems Engineer

 By British Office of Trade:

• ITIL Foundation, Intermediate, Expert and Master

Saving Money with IT Security Processes. Example 11/26: Avoid a Technology SPOF with License Management

Article number 11 in a series dedicated to giving examples of the way IT security processes can help your company save money.

What's License Management got to do with SPOFs?

It's got to do with the Technology SPOF.  "Technology SPOF" is the name I gave to all incidents that trigger a failure on all systems of a similar technology. For instance, if two redundant servers share a single storage bay that's full, both servers will suffer the same disk full failure.

Licences are a major source of technology SPOFs. Many products, once their paying period is expired, just stop functioning at all. For instance, antivirus software suites. Many products, once reached their usage limit, also just stop functioning at all. For instance, a dedicated appliance that can host 100 concurrent users.
That's the time when you'd wish you had a sound License Management process.

The License Management process does the following:

• It inventories all current licenses and their limitations.
• It monitors their use so that they don't reach limitations.
• It purchases new licenses in time and quantity.
• It installs new licenses and updates the inventory.

The Licence Management could be seen as a part of a larger Procurement process, however I see fit to put it in Security and not Procurement, because it requires active monitoring, capacity planning and some administation, which are more IT related.

Saving Money with IT Security Processes. Example 10/26: Preventing Massive Outages with Electricity Management

Article number 10 in a series dedicated to giving examples of the way IT security processes can help your company save money.

Electricity Management is the process that ensures correct availability of electric power for all IT needs.

"Green IT" is the fancy name for it nowadays. We've come to a level of risk awareness where it's common sense that ensuring reduction of consumption and availability of power (that come together, think of it) can make good money for companies. If we can make a point by calling it ecology or eco-friendliness or environmentalism, that's an asset.

To correctly operate Electricity Management process and prevent massive power failures that would cause your company huge losses in downtimes, the following duties must be accomplished:

1. Assess power purchase and power producing capabilities.
2. Put in action a set of load balancing items.
3. Supervise the electric load of all sources. SNMP is a possible choice.
4. Make sure you have recovery documentation for major possible outages.

Free Dynamic DNS Providers

A friend sent me a compared list of free Dynamic DNS providers. For memory, dynamic DNS is the mechanism that allows someone with a dynamic IP (virtually everyone at home) to get a domain name always pointing at the current IP.
This list compares usual Dynamic DNS providers like no-ip.com or dyndns.com and many others.

Saving Money with IT Security Processes. Example 9/26: Preventing the Angry Administrator Revenge

Article number 9 in a series dedicated to giving examples of the way IT security processes can help your company save money.

The incident that I refer to when I speak about the "Angry Administrator Revenge" is the one that happens when you sack an admin and that he uses his administrative rights to wreak havoc in your Information System. That's a pretty common case:

• Example 1: Ex-Gucci IT Employee Seeks Revenge on a $200,000 Hacking Spree
• Example 2: 10 Ways Fired Employees Got Their Revenge On Their Ex-Bosses / Former Firms
• Example 3: Disgruntled employees may seek IT revenge

This is when the IT Security process of Password Management comes in. (It's sometimes part of a larger Identity and Access Management process.)

Basically, almost everything in IT is protected by a password. Rare exceptions are the things that are not protected at all or the things that require more than just a password. However, password is the rule.
There are two kinds of passwords to be distinguished:

• The personal passwords, that are known by one person only.
• The shared passwords, that are known by multiple people.

Whatever your degree of maturity, shared passwords can't be eliminated completely. So, virtually any Information System in this world has both personal and shared passwords and they give access to virtually every server, storage, application...

The Password Management process does the following:

• It knows who's supposed to know (be in the shared secret) each password.
• It knows how to change them.
• It does change them whenever someone who knows them is no more in charge (or has been sacked).
• And, because there are sometimes more people who know a password than the few supposed to know it, it changes all passwords on a regular schedule, like once a year, or more for critical data.

So, with a sound Password Management process, you can avoid what's happened to Gucci and so many other companies.

Saving Money with IT Security Processes. Example 8/26: Quick Recovery from Backup

Article number 8 in a series dedicated to giving examples of the way IT security processes can help your company save money.

Recovering a server or user data from backed up copy is a well known activity in IT. Not doing so would cause huge losses to the company, including downtimes and manual recovery (double work from the end user). However, you can't ensure that your copies will be functional without a proper Disaster Recovery process. The duties of the Disaster Recovery process manager are the following:

1. Include all new data and servers into the saving mechanisms. This may require that backup people be at the conception phase of each project to ask corresponding questions: what's to be saved? How often? How to access it?
2. Test the recovery mechanisms. Although what's backed up is backed up, you may not be able to use it if only a tiny bit of it is missing or backed up incorrectly. So, recovery should be tested at least once for every business applications and recovery machinery and media should be tested very often.
3. Review the list of what's to be backed up. The copying of older applications can be stopped. Newer versions of the same applications may require new data to be copied.

Please Don't Break Tabbed Browsing and Browsing History!

Tabbed browsing or the ability to browse websites in multiple tabs at the same time is now an acquired benefit. Yet, it can be broken if ill-designed websites just try to mess with it.

Basically, when you click a link, the address of the link gets copied into the address bar of the browser and you access that address. If you open the link in a new tab (middle button on the mouse, usually), the address gets copied to the address bar of the new tab. Pretty simple, huh?

But some sites try to add scripts that tell your browser where to go when the link is clicked, instead of just doing the normal way. So, they mess with the regular work of the browser. Three kinds of bugs can then be encountered:

1. The link opens both in the current tab and the new tab.
2. The new tab opens but the linked page doesn't show in it.
3. The browsing history gets broken, preventing you from correctly returning to the previous page.

So, here is my point:

STOP MESSING WITH LINKS!
STOP MESSING WITH BROWSING HISTORIES!
Just let users open what they want where they see fit.

Example:
Viadeo, a French kind of LinkedIn, is doing it. If you middle-click a link, it will open both in the current tab and in the new tab. Thank you developers! Let me add that this is particularly inadvisable for a social network, where the most valuable users are very experienced and open dozens of tabs at once.

Saving Money with IT Security Processes. Example 7/26: Early Notice of Regulatory Compliance Changes through Technological and Legal Watch

Article number 7 in a series dedicated to giving examples of the way IT security processes can help your company save money.

Regulatory Compliance requirements are a pain in the back for companies. They've got to reach some government-imposed or industry-imposed requirements and they sometimes have to reach them by using imposed means, tools, technologies...

However, the most costly is not to put the requirements in practice if you know them from the start of projects. The most costly is to modify production afterwards, in haste, in order to comply:

• The production may incur downtimes and bugs because of the hasty patches.
• Besides, the architecture may have to be reviewed to support the requirements, and the previous architecture may be obsolete before it has paid off.
• Eventually, the patched system may be more expensive to operate than if it had been thought about correctly from the beginning.

A good way to prevent such blunders and losses of money from happening is the Technological and Legal Watch process. The goal of the process is to identify emerging threats. Threats can be:

• Technical, like a new vulnerability.
• Commercial, like a vendor no more supporting a product.
• Trends, like the emergence of a new kind of attacks (think XSS a few years ago).
• Regulatory, like the validation of an industry standard.
• Legal, like the imposition of a new legal requirement.

The best tool for Technological and Legal Watch process is the RSS feed. Feeds can be collected from related web sites. Feeds can also be created from Google searches (with keywords).

Two Security Policy Writing Tips

Reading Anton Chuvakin's On Nebulous Security Policies reminds me I wanted to share two very simple, basic, common sense, advices about writing the Security Policy.

Although norms like ISO27000 may give good guidelines to the content you put into the Security Policy, it would be quite suboptimal to write nothing more and nothing less. You have to adapt it to your organization and you can benefit from it.

My first advice is:
Stick to what you already have, or almost have. For instance, if you already backup 95% of your servers, you can write something like "all servers must be backed up". That will help you communicate what you already do and obtain more observance from your own teams.
If, on the contrary, you only backup a few servers, don't go into writing that they must all be backed up. That would show that you don't do what you say and that you write things you don't have a clue how to put in practice.

My second advice is:
Think of IT problems actually occurring, where you would welcome help from top management, and write these principles into the policy. This way, the top-management-approved policy will support your efforts to address these problems. For instance, if you would like to clarify that the IT service doesn't support hardware that wasn't bought by the IT service itself, the Security Policy is the right place to state it.

Saving Money with IT Security Processes. Example 6/26: Reducing Project Delays with Secure Project process

Article number 6 in a series dedicated to giving examples of the way IT security processes can help your company save money.

Projects have a conception phase. In this phase, networks are designed, interactions with users are designed and so on. This is a moment when thinking critically with a security mindset is most valuable.

If you let the conception phase evolve without a security engineer, IT people will think about networks but not about intrusions. They'll think about users but not about attackers. Because that's the security job. So, they will design vulnerable software, networks and/or servers.

Then the vulnerable conception will be implemented and put into production. Then either the Security Audit will spot vulnerabilities and ask for a costly patch (or re-design) or the Security Audit will miss it and a security incident is going to happen soon. Both cases are very expensive for a company.

If you have a sound Secure Project process, with a goal to secure developing projects, this will not happen and the company will save a lot of money.


The whole case in this article is based on two little known asymmetries:

1. You can look for a vulnerability at the conception phase or at the production phase. But doing it in production is longer (more expensive) and is more likely to just fail spotting the vulnerability.
   
   
2. You can patch a vulnerability at the conception phase or at the production phase. But doing it in production is longer (more expensive), may require stopping production (lost business hours) and may trigger side-effects.

Saving Money with IT Security Processes. Example 5/26: Reducing Help Desk calls and duration with Patch Management

Article number 5 in a series dedicated to giving examples of the way IT security processes can help your company save money.

The Help Desk is the service provided by people who are there to collect user calls about IT incidents, answer them when possible and, when not, transmit to people who can. A typical Help Desk receives thousands of calls a month. Companies lose percents of their annual revenue in these incidents: incident ⇒ business is down, user (employee) is demotivated + Help Desk must be paid to intervene.

There are three levels of difficulty for a user call handled by the Help Desk:

1. The Help Desk knows how to solve the incident described by the user, or they know to whom they should redirect it. This takes a few minutes and represents an important part of the whole lot.
   
   
2. They don't know precisely how to solve incident nor whose help they should ask for. So they must investigate, take a lot of time to understand the real root of the incident and to act accordingly. Along the time, the Help Desk will build a database of knowledge about these incidents and, so, will improve its overall performance. However, this second level of difficulty represents the biggest part of all calls.
   
   
3. The incident is just overly complex, the Help Desk knows they won't be able to solve the incident, so they just redirect it to the regular IT team and ask for help. This is a small part of all calls.
   
   

Improving on this may seem like climbing an impossible mountain.

However, IT Security can simplify the work of the Help Desk and save company's money this way: accelerate work ⇒ downtimes decrease + Help Desk teams can be reduced. One way is the Patch Management process.
Albeit unrelated at first sight, the Patch Management process keeps your software up-to-date. If it's up-to-date on all workstations, then it's precisely the same on all workstations. Then two workstations will have the same set of possible incidents, instead of two different sets of possible incidents. Now, if the Information System is 30 software pieces on 1,000 desktop PCs, then instead of having, say 5 different versions per software, you'll have just one. So, instead of 30 x 5 = 150 sets of possible incidents, you'll have just 30.

This means that the database of incidents (for level 2 difficulty) will grow faster compared to the total number of possible incidents. So a larger part of level 2 incidents will be treated as fast as level 1 incidents, resulting in a significant increase in Help Desk performance:

• Users will be more satisfied,
• Help Desk will find its job more rewarding,
• Help Desk will save time, that can be put onto something else.

This is a very often forgotten side of security. Most people will just see Patch Management as a protection against vulnerabilities or vendors no more supporting old versions of software, but will overlook the virtuous circle of simplifying the information system.

Saving Money with IT Security Processes. Example 4/26: Identifying SPOFs with Network Architecture

Article number 4 in a series dedicated to giving examples of the way IT security processes can help your company save money.

SPOF is a very hackneyed expression, nowadays. However, a certainty remains: SPOFs must be addressed, or your company will loose a lot of money in downtimes. To address them, you must first identify them. One of the objectives of the Network Architecture process is to prevent SPOFed architectures to go into production and to identify SPOFs in the existing production architectures.

This, contrary to the opinion of many, is not a lost race. There is a finite number of 4 kinds of SPOFs, that you must all look for:

1. The hardware SPOF: your hardware (whether servers, network equipments, etc.) is not redundant.
2. The network SPOF: your hardware is redundant, but the network links that connect equipments are not crossed. They should normally deserve all redundant hardware just as well.
3. The configuration SPOF: your hardware is redundant, the network deserves it well but the clients are not aware that they should be connecting to the failsafe servers if the main ones are not available. In my experience, this one type of SPOF accounts for a huge part of forgotten SPOFs and related losses in unplanned downtimes.
4. The technology SPOF: one of your technologies fails (whether hardware, software or network). As it is the same in the main architecture and in the redundant architecture, both suffer from the same downtime.

Please read my previous article for sample network diagrams of these types of SPOFs. With a sound Network Architecture process, you can reduce downtimes by identifying SPOFs before crashes occur.

Saving Money with IT Security Processes. Example 3/26: Identifying Low Use or Unused Servers

Article number 3 in a series dedicated to giving examples of the way IT security processes can help your company save money.

Maintaining servers is often costly. Electricity is a point and complexity is another: various technologies, various network connections, etc. The use a few years ago was to have 1 server per business applications.

The flaw of IT services is often to just let things how they are until something bad happens. But losing money day after day is a bad thing, and you can do better with a strong Supervision process. Supervision of servers must include graphs of intensive values: number of connected users, CPU usage, memory usage, inbound network flows, etc. With these graphs, you can identify:

• Low use deprecated servers and effectively unused servers (happens, sometimes), which you can decide to just stop.
• Low charge but important servers, which you can virtualize. You'll then reduce hardware costs and decrease complexity through homogeneity.

Saving Money with IT Security Processes. Example 2/26: Retrieving Stolen Smartphones and Laptops

Article number 2 in a series dedicated to giving examples of the way IT security processes can help your company save money.

Companies lose a lot of money in stolen smartphones and laptops. It does not just amount to the price of hardware, it also includes the quantity of time lost by workers without their tools, the quantity of work needed to report the incident and to, optionally, declare it to the police and to an insurer. Besides, the devices can contain valuable information that the company will miss and that may be dangerous to put on the public place or in a competitor's hands.

It's possible to address the loss of smartphones and laptops with a sound BYOD* process. I'm not talking about a policy, I'm talking about a process, that includes:

• Securing information flows from/to devices with appropriate extranet and telecommuting tools.
• Making sure devices that will save company's property locally do have encryption features, access control features and geographical tracking activated.
• Inventory the types of devices and establish required procedures for each type, because the list is ever-growing, you can't do without managing it clearly.

* I'm talking about BYOD because it's time to face it: most devices are now no longer company devices.

Saving Money with IT Security Processes. Example 1/26: Reducing Virus Crises

Article number 1 in a series dedicated to giving examples of the way IT security can help your company save money.

IT services lose a lot of time and money in virus crises. You can save this time and money with a sound Antivirus process.
I'm not talking about software, I'm talking about process. The process is:

• To have a baseline antivirus, make sure it's configured optimally and installed on every workstation and laptop.
• To have a requirement in RFPs that machines your IT service will not maintain will have a running, up-to-date, antivirus, and to ensure service providers do follow this requirement.
• To analyse unusual network-capable hardware (like tablets, old servers, smartphones, CCTV, storage bays, etc.), inventory them and decide whether they deserve an antivirus or not.

Identity Management Steps, from the Ground Up

Norms and legal compliance often require companies to do strong authentication. But it must not be forgotten that strong authentication is merely the cherry on top of the cake.

Strong Authentication is an improvement upon Authentication, weak or not. Authentication is built upon a correct Identification of people. Identification allows for Authorization based on rules, for instance, ORBAC or RBAC.

Or, if we put it into natural questions:

1. Who are we speaking about? Identification
2. And who's that? What's he supposed to be doing around here? Authorization
3. Let him prove he's really who he means! Authentication
4. Let him prove that he's not cheating on authentication! Strong authentication.

Strong Authentication Authentication Authorization Identification

The most important is to understand that a compliance requirement about Strong Authentication is only the tip of the iceberg. Any project targeting Strong Authentication should first concentrate on cleaning and validating Identification (list of users → list of all users → list of all users individually identified → up to date list of all users individually identified → up to date list of all users individually identified with all information related to their work assignments and related Authorizations), then choose specific areas among all possible Authorizations (among the many things people are allowed to do in the Information Systems, which are now to be protected?) and then enhance Authentication into Strong Authentication.

Symantec Endpoint Protection v11, Switching a Client PC from Managed to Unmanaged

This procedure is intended only for version 11 of Symantec Endpoint Protection.

This procedure is for a client PC that was configured as "Managed" and, thus, takes its configuration from a server. You may want to make it an "Unmanaged", standalone client for specific reasons, eg testing specific configuration parameters or because the server is no longer available.

If the server is still available to you, you can use the method given by Symantec.

If, as was my case, you cannot access the server and you do not want to reinstall the whole software suite, you can proceed this way:

1. Open regedit and navigate to HKEY_LOCAL_MACHINE\SOFTWARE\Symantec\Symantec Endpoint Protection\LiveUpdate.
2. Set the key named AllowManualLiveUpdate to value 1.
3. In the folder: C:\Program Files\Symantec\Symantec Endpoint Protection backup the four files SyLink.xml and SyLink.xml.bak, serdef.dat and serdef.dat.bak.
4. Kill the Smc.exe process and quickly delete SyLink.xml, SyLink.xml.bak, serdef.dat and serdef.dat.bak before the process respawns.
5. The respawning process will recreate an appropriate default config and let you update everything manually from the Symantec server on the Internet.

Petite arnaque facebook

Une amie s'est fait voler son compte Facebook. Aussitôt le voleur en profite pour essayer de me faire envoyer un SMS certainement surtaxé. Je me demande tout de même combien ça peut rapporter !

Security ROFL 7

• [EN] XKCD always so strong on sarcastics:
   
• [RO] In the rush to advertise their new Internet Explorer 10 browser, it seems Microsoft has (unwillingly?) compared what's not to be compared. They advertise their rendering engine as faster than those of Google and Mozilla, which is true only because the default config for Internet Explorer allows for a direct access to the graphic card hardware acceleration, which can be problematic. When compared with the same configuration, browsers are, as usual: Chrome >= Firefox >>> Internet Explorer.
• [FR] Le spam nigérian le plus poétique (et drôle).
• [EN] Tax havens among the most popular hangouts for Apple's Safari browser. Just take a look at the chart ^^
  
  
• [EN] Fun and unusual HTTP response headers. My favorite is "PoweredBy: Rats in our Basement" ;-)
  

Petit manuel anti-dépression à l'usage des administrateurs systèmes et réseaux

Il est toujours bon de revoir ses classiques et je me permets de pomper le site de Gérard Milhaud pour présenter à ceux qui ne la connaissent pas cette petite perle : le

Petit manuel anti-dépression à l'usage des administrateurs systèmes et réseaux

Quoiqu'il date de 2004, la teneur est encore bien d'actualité. Voilà ce qu'en disaient Gérard Milhaud et Olivier Pagé, Responsables informatiques de l'ESIL et de Centrale Marseille.

---

Résumé

Dans une première partie, nous isolerons clairement les problèmes actuels du métier d'Administrateur Systèmes et Réseaux (AS&R par la suite), en donnerons les causes principales et leurs implications pour la fonction : nous montrerons que le mal-être et l'état bien trop souvent dépressif de l'AS&R provient essentiellement d'un énorme surbooking, lié à la faiblesse des ressources humaines, qui n'ont pas suivi l'accroissement spectaculaire des ressources matérielles et des services nouveaux offerts à l'utilisateur depuis l'avènement de l'Internet pour tous au milieu des années 1990. Nous verrons à quel point cette situation généralisée est alarmante et entraîne une très mauvaise utilisation des compétences des personnels en place.
Dans la deuxième partie, nous tenterons de donner des solutions, tant sur le plan technique que sur le plan organisationnel et humain, permettant de gérer au mieux ce surbooking, en le prenant comme contrainte principale et prioritaire de l'activité. Même si elles ne peuvent prétendre remplacer un inévitable recrutement massif, nous exposerons des « recettes » qui permettent de l'attendre plus sereinement, en dégageant du temps pour les tâches fondamentales de coeur de métier, motivantes, que l'urgence nous vole trop souvent, générant des cohortes d'AS&R frustrés.

---

Téléchargez l'article, présenté à la conférence JRES 2001 (10-14 Décembre 2001, Lyon) :

• Article : format pdf ou MSWord 2000,
• Présentation version 2001 : format MSPowerpoint2000.

NOUVEAUTÉ 2004 : téléchargez la présentation updatée pour 2004 présentée lors de la journée thématique "Administrateur Systèmes et Réseaux, un métier qui se transforme" du réseau grenoblois SARI :

• Présentation version 2004 : format MSPowerpointXP.

Désolé pour les formats propriétaires .doc et .ppt mais c'était l'une des obligations de la conférence. Nous avons choisi de les diffuser dans leur format original car la traduction HTML fournie par Word et Powerpoint appauvrit trop les 2 documents à notre sens. En attendant une éventuelle traduction en LaTeX quand on aura 5 minutes (avant 2005 on l'espère), c'est mieux que rien.

Bonne lecture.

---

Currently on: Stripe's Capture The Flag

I'm all excited about this contest. Although I've been running many of these, this one is particularly well structured, with a strong emphasis on web applications, injections and analysis of source code. The source code for all exercices is given. It's always amazing how you can make software work in unthought ways.

The programme is, at least : code injection, SQL injection, Javascript injection, and that in PHP, Ruby, Python and of course, HTTP protocol ;-)

For now, I just arrived to level 6 (out of 8). Much fun, some learning and much practicing. A must-do if you're interested in IT security.

If you're aware of other security contests like this one, please let me know, I'm always interested.

Time passes so fast

First time I worked as CISO: almost 5 years ago,
first time I was paid by a company just to do IT: 8 years ago,
first time I owned a PC on my own: 12 years ago,
first time I wrote a full-featured game, on a TI calculator: 13 years ago,
first time I gave a lesson on IT matters: 13 years ago,
first time I used Linux as my main OS for home: 13 years ago,
first time I reverse-engineered a piece of software: 14 years ago,
first time I used the Internet, wrote a website (and learnt English): 15 years ago,
first time I used Linux : 15 years ago,
first time I used a PC : 18 years ago,
first time I wrote code, on a CASIO calculator : 20 years ago.

Remarque agnostique sur Linux en entreprise

Pour avoir travaillé dans de nombreuses sociétés, il me semble évident que Linux représente une menace. Notez que je ne dis pas que c’est le choix de Linux qui représente une menace, car Linux n’est pas un choix. Linux est imposé par le marché. De plus en plus d’outils utilisent Linux, y compris des sociétés très respectables et des éditeurs de logiciels métier. Ce qui représente une menace, c’est le manque de réaction managériale face à l’arrivée de Linux.

Deux menaces principales existent :

• Le scénario de ne pas savoir intervenir en cas de panne, par faute de formation.
• Le scénario d’avoir tellement de Linux différents que l’on ne sait plus comment les gérer et que l’on multiplie les coûts.

Ces remarques s’étendent à Linux, à Mac OSX, aux BSD et aux autres sortes d’Unix.

Ma recommandation

Tout d’abord, cesser le déni et reconnaître que Linux est utilisé au sein de l'entreprise. Ensuite, accorder un crédit de temps *qui peut être de l’autoformation* à un ou plusieurs administrateurs système, pour se former à Linux.

Enfin, faire un certain nombre de choix concernant Linux, visant à éviter le chaos de la muliplication. Par exemple, le choix d’une ou deux distributions « supportées » par le service informatique et l’achat d’une suite logicielle permettant l’intégration des machines Linux aux outils centraux, y compris outils Microsoft.

At the Heart of Security: Doing What You Say And Saying What You Do

Security is about deciding what's forbidden, what's allowed and enforcing these decisions.

There's the technical part, doing what you can to technically enforce the decisions.
And there's the human part, managing things in a way that reduces related uncertainties.

The human part is the most important. You cannot enforce every decision technically. Besides, you have to allow for people to switch on/off certain features, eg to allow for good functioning outside of the company's premises. So, you forcibly leave some room for employees to decide by themselves whether they respect the rules or not. And that's the moment when the human factor matters.

The most important tool for the human factor is the security policy. You have to say what you do in terms of security and to do precisely what you say.

If you don't do what you say, you invite people to force the system, they think they can fool you. It may go as far as disregarding completely the policy.
If you don't say what you do, you invite people to rebel and contest the security measures. Additionally, you scramble people's understanding of your security policies, which may lead them to give up trying to respect it.

Note on the Future of RSS Feeds

These days, I see a decline in the publication of RSS feeds. Either they're not present, not advertised much, or incomplete. This is especially true of mainstream, non-professional sites.

One of the reasons that might lead bloggers and webmasters to remove or neglect RSS feeds is that they provide no way to count followers (unique followers). A good evolution off RSS would be to allow a simple "declarative" download of RSS feeds.

• Authentication might be hard to obtain and maintain.
• Identified-only feeds might make users reluctant to use them.
• "Declaration" of an identifier of the follower is subject to many uncertainties, but could allow for a better count of unique users, returning users, etc.

Security ROFL 6

• 10 (or so) of the worst passwords exposed by the LinkedIn hack, like "ihatemyjob", "fuckmylife" or "123456" through Anton Chuvakin's G+.
• Using tax refunds to steal money from taxpayers ;-) Tax Return Identity Theft from Bruce Schneier's blog.
• Displaying password in the TV news is no good idea ;-) from the Front Line Sentinel blog.
• Movie Hacking vs Real Hacking, from the Saturday Morning Breakfast Cereal webcomics.
• Dilbert's use of users' private data :-D
• And finally the eternal lesson from the Demotivators : 

A l'attention des RSSI : Sur la fuite des mots de passe LinkedIn

Il y a quelques jours, une fuite massive de comptes et de mots de passe LinkedIn a été révélée sur Internet.

Je recommande aux RSSI de faire suivre le mot au sein de leur entreprise/administration.

En effet, comme le site LinkedIn utilise l'adresse e-mail des gens comme identifiant, la plupart des utilisateurs moyens utilisent pour ce site le même mot de passe que pour leur adresse e-mail. Ainsi, les adresses e-mail de ces utilisateurs deviennent des cibles, via les webmails.
De plus, les utilisateurs qui réutilisent leurs mots de passe risquent aussi de les réutiliser pour tous les autres sites dont l'identifiant est l'adresse e-mail. Ces autres sites sont donc menacés aussi.

Exemple : Un utilisateur lambda, Jean Dupont, travaille pour la société Youpeee. Son adresse e-mail est "jean.dupont@youpeee.fr". Son mot de passe est "kevin1502", le prénom de son fils et sa date d'anniversaire. Jean s'enregistre sur LinkedIn avec son adresse e-mail et, pour simplifier, le même mot de passe "kevin1502". Il fait de même sur Facebook. Il fait de même sur Amazon.
De plus, pour qu'il puisse télé-travailler, son entreprise met à disposition un site http://webmail.youpeee.fr où il peut consulter son courrier électronique.


Aujourd'hui son mot de passe LinkedIn fuite sur Internet. Résultat :

• Ses comptes Facebook et Amazon sont menacés.
• Son courrier électronique d'entreprise est menacé.
• Si l'entreprise Youpeee utilise d'autres moyens de télétravail, ils peuvent eux aussi être menacés.

Le problème du transfert des données des passagers européens aux États-Unis

Article qui pointe un problème de fond : Le problème du transfert des données des passagers européens aux États-Unis.
Le problème de fond est l'harmonisation des législations et des pratiques informatiques (ou "informatique et libertés") entre des pays "alliés sur tous les autres plans", ici l'Union Européenne et les États-Unis.

L'une des parties a une tendance très démocratique, sauf sur les questions de politique étrangère (États-Unis), l'autre a une tendance très pro-peuple mais peu démocratique (Union Européenne). Je n'ai pas de certitude sur la façon dont ces problèmes vont se résoudre, à terme, mais je parie que le processus ne sera pas démocratique.

Weiße Listen

Ich bin immer neugierig über Anwendungsfalle einer Technologie weg von ihrer ursprünglicher Welt : Weiße Listen :-D

Epiphany: Free Software = Lower Entry Barrier = Greater Risk of Project Failure

Discussing with a friend lead me to this epiphany: the reason why Free/Libre/OpenSource software is not used enough in traditional companies is that they invest too little in it. Not in money, but in time, thought and human resources.

Since FLOSS has a very low entry barrier (starting from just zero, up to prime class paying service from companies such as IBM), it tends to attract people and companies that want to invest very little in it. That's why they fail to make a great use of it.

Mem: I think there's a business model in just selling GPL software, without any added value, with the argument that the buyer will be more motivated to implement it well ;-)

Draft: Stuffing Security into MVC

A long time ago, when I was young and crazy, if I ever was, I used to code components in Java, with the help of the MVC design pattern.

It's a very useful tool and I've recently had the occasion to recommend it to a little company. They used it very efficiently to solve the messy  graphical interface of their featured soft. Nowadays, I'm mostly concerned about security and I do suffer, as those of my kind, from the underlying insecurity of software. It's not just insecure on the surface, it's insecure from the bottom up.


A complex system that works is invariably found to have evolved from a simple system that worked. (he said)
A complex system that is secure is invariably found to have evolved from a simple system that was secure. (let me add).

So I got to ask myself if it was possible to put some security directly into design patterns.

Say you'd like to stuff some of the following principles into the above diagram:  identification, authentication, authorization, audit, capacity planning, soft/hard redundancy, load balancing, cyphering, shoulder spying, data integrity, backup. Where would you start?

For each of them, I'd start by putting appropriate data/meta-data into the Model or near it. Then I'd make the View able to display what's necessary. Then I'd update the Controller with adequate intelligence. Simple, no?


Identification: Identification is based on data that's common with many other pieces of software. Let's say we'll dedicate a new model for it. Then say that neither the view, the model nor the controller will act before the user has been identified.
Authentication: Authentication requires pieces of data, or tokens, that can be verified by interacting with Identification data. But it requires no model of its own. Authentication is -nowadays- a period of time during which the system assumes the user really is whoever is was identified to be. Say that Authentication is a method of the identification component that returns a binary (authenticated or not). Then say that neither the view, the model nor the controller will act if the user is not authenticated.
Authorization: Authorization is a b/w mask (allowed/denied). It's a function of Identification data and the data in our model. So we want to add the "authorization mask" into our model. (That's a huge part of the security job. You can simplify it by using roles, such as in ORBAC.)
Audit: Audit is keeping track of what happens. It can be seen as a two-bit mask of the data in our model, indicating what's going to be logged. 00 means nothing, 01 means read operations, 10 means write operations, 11 means read and write operations. So we want to add the "audit mask" into our model. Then the controller will just write logs of whatever is to be audited.
Capacity planning: Capacity planning is measuring the volume of activity inside the component, as well as the size of the model itself. The numbers of read access and write access to model data and the number of routine execution of controller methods should be counted. These counts can be put into the model and updated by the controller.
Redundancy and Load Balancing: There's not much data in it but the choice of a pattern. Say active/active, active/passive, multiple instances, etc. The choice of this redundancy pattern can be put inside the model. The controller will have to instantiate components and "control" them. This may require an external Timer, or Sequencer, or Scheduler, whatever you call it, in order to trigger events on a defined schedule. (One huge advantage of component programming is that you can play at instantiating them in no time. This part really can be fun)
Cyphering: Cyphering between components is no big matter if you know the basics about PKI. You just need to make sure that you know which flows of data you want to cypher. This can be seen as a one-bit mask (cyphered/cleartext) of component-to-component flows. This "internal cyphering mask" can be put inside the model. Disclaimer: you DON'T WANT to create a unique instance of an object that handles cyphering for every component!
Shoulder spying: Shoulder spying should be let up to the view itself. However, the choice of what data has to be protected from neighbours should be stored in the model. It can be seen as a "hiding mask" (one bit or more). Then the view chooses how to implement it.
Data integrity: Whenever in the history of IT, integrity has meant the addition of control data to check validity and completeness. This data can be put in the model. The controller will have to take on the job of updating it whenever data changes. This means the model will have to enable atomicity of transactions.
Backup : Backup definitely requires an external scheduler because of its high cost. You just don't want to replicate data every time it changes. Plus you may want to rewind time later. Backup can be seen as just a serialization of the model. It means the model will have to support serialization.

More next time...