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.