Author Archives: enicaise

Le binômage: plus rapide, plus sûr et pourtant si peu fréquent.

De nos jours, la gestion de projets en mode « agile » est de plus en plus utilisée dans les entreprises. Elle est même à la mode. En effet, ses principes, ou du moins certains de ses modes de fonctionnement sont même appliqués à des processus de transformation de l’entreprise qui se doit elle-même d’être de plus en plus agile, réactive.

Cependant, cette méthode est encore souvent employée dans un cadre qui n’est pas agile, avec, dès le départ, une demande du « client » d’avoir certaines fonctionnalités livrées à un moment donné (ce qui va en soi un peu à l’encontre du principe même des méthodologies agiles). Entre parenthèse, il me semble aussi assez souvent qu’une partie des quatre principes de base de la méthodologie (le focus sur les personnes et de leurs interactions, l’importance de livrer un logiciel opérationnel avant tout, l’implication forte du « client » dans le processus et l’adaptation continue aux changements) sont souvent ignorés ou minimisés, probablement de par la différence culturelle que cela implique au sein de l’entreprise.

Mais ce n’est pas là que je veux porter votre attention aujourd’hui. Parmi les méthodes « agiles », celle que je rencontre le plus souvent, pour ne pas dire exclusivement, est la méthode Scrum. Pourtant, ce n’est pas la seule méthode agile existante. XP, eXtreme Programming, développée en 1999,  un peu après Scrum (en 1995), s’inspire aussi des principes de la méthode agile. Une des pratiques courantes de la méthode XP est le binômage, la programmation en binôme. Ce mode de programmation requière deux programmeurs: le conducteur (driver) et l’observateur (observer). Le conducteur programme pendant que l’observateur l’assiste en faisant une revue du code en direct. Déjà, du point de vue des bonnes pratiques de sécurité, telles celles édictées par la désormais incontournable OWASP, la case « revue du code source par une tierce partie » peut-être cochée. Mais de plus, cette pratique semble permettre d’augmenter la vitesse de livraison et la qualité du code fourni. Quand on connaît le coût et le temps passé à tester et re-tester les applications, une augmentation de la qualité du code devient très vite un avantage financier non-négligeable, sans compter la diminution de la frustration chez les utilisateurs quand ils tombent sur un « bug ». Parmi les autres avantages, celui qui doit théoriquement venir avec les méthodes agiles  mais qui devient une condition sine qua non est l’amélioration de la communication au sein de l’équipe, tout au moins, au sein du binôme.

Alors, quand verra t’on le binômage dans nos exigences de sécurité pour les projets de développement?

Stéganographie et cryptographie dans l’antiquité romaine

J’ai eu le plaisir aujourd’hui de tomber par hasard sur les 7ème et 8ème feuillets des Folia Electronica Classica de la faculté de Philosophie et Lettre de l’UCL. Ces deux feuillets sont consacrée à la reproduction du mémoire de Brigitte Collard, Licenciée en langues et littératures classiques, ayant pour titre « Les langages secrets. Cryptographie, stéganographie et autres cryptosystèmes dans l’Antiquité gréco-romaine ».

Ce document qui n’est plus tout récent (2004) reste néanmoins fort intéressant (les connaissances historiques n’évoluent pas trop vite en général) pour ceux qui veulent aller un peu plus loin que le chiffre de César ou les messages tatoués sur les cranes des serviteurs qui sont si souvent mentionnés comme étant aux origines de la cryptographie et de la stéganographie. D’autant que si la technique à bien évoluée depuis l’antiquité, les principes restent les même et les recettes d’antan pourraient très bien être légèrement améliorées pour s’adapter au contexte actuel. Imaginez la quantité d’information que l’on peut transporter sur une carte micro SD de 64 GB attachée à un pigeon voyageur sans risquer de se faire intercepter à la douane ou tracer sur Internet.

Négliger l’histoire, c’est refuser de tirer des leçons du passé et se vouer à répéter ses erreurs. Je vous invite donc à lire ce travail très intéressant et agréable à lire de Brigitte Collard: La Cryptographie et la stéganographie et les signaux.

Bonne lecture

Crélan victime d’une fraude de 70 millions EUR par ingénierie sociale?

Le 19 janvier 2016 la presse belge a révélé que la banque belge Crélan aurait été victime d’une fraude à hauteur de 70 millions d’Euro. Bien que le journal l’Echo ne donne pas énormément de detail sur le sujet, De Morgen cite des sources qui mentionnent une fraude utilisant de l’ingéniérie sociale via des emails. Il semblerait que les fraudeurs auraient envoyés des emails qui proviendraient prétendument du CEO de la banque, demandant à certains employés d’effectuer des virements aux montants importants vers des comptes externes à la banque.

Ce genre d’attaque est relativement simple et peu coûteuse à mettre en oeuvre et ne peut réussir que si une série de conditions sont rencontrées:

  • Au niveau de la gouvernance et des processus, une faille dans les processus de contrôle interne qui permet à une seule personne d’effectuer des virements sans avoir une validation formelle préalable;
  • Au niveau technique, un système qui permet de recevoir de l’extérieur des emails qui peuvent sembler provenir de l’intérieur de l’entreprise, et encore plus de son CEO;
  • Au niveau humain, un manqué de sensibilisation et de formation aux techniques d’ingéniérie sociale qui permet d’abuser de la bonne volonté et de la crédulité du personnel de la banque.

Comme d’habiture, on retrouve la trilogie Personnes-Processus-Technologie dans les risques identifies. Cela nous rappelle une fois de plus la nécessité d’une approche « holistique » de la sécurité tenant compte de tous les facteurs de risques et surtout de la partie trop souvent négligée qui est le facteur humain. N’oublions jamais que les processus ne sont efficaces que si les personnes qui les opèrent les suivent correctement. De même pour la technologie qui est toujours configurée et gérée par des êtres humains qui peuvent être facilement manipulés, voire même menacés.

Trop souvent la sécurité de l’information est vue comme une problématique technique alors qu’il s’agit réellement d’une problématique profondément intriquée dans les processus de l’entreprise et dans ses forces vives.