lundi 29 juillet 2013

Vers une certification … utile

Contexte

Avec les nouvelles CSPN très symboliques délivrées ces derniers mois, il apparaît clairement que la certification sécurité de produits logiciels est une activité politico-marketing, dont l'efficacité réelle a largement été battue en brèche lors de la conférence SSTIC 2013.

Les questions fondamentales qui se posent alors sont les suivantes : est-il possible d'améliorer la sécurité des logiciels commerciaux ? D'aider à la sélection des meilleurs, lorsque ni Darwin, ni la main invisible du marché n'y arrivent ? Et si oui, par quel miracle ?

La sûreté logicielle est un domaine curieux. La majorité des problèmes avaient été résolus il y a 30 ans. La quête de la perfection a produit les langages formels, la preuve de programme, ainsi que des certifications fiables - comme la DO-178 en aéronautique. L'ANSSI semble d'ailleurs redécouvrir aujourd'hui que les systèmes critiques sont programmés en ADA. L'industrie informatique était alors à son apogée. On entrait dans les salles machines en blouse blanche, et les informaticiens étaient promis à de brillantes carrières dans leurs entreprises respectives. Bref, le paradis originel.

Puis tout a basculé avec l'informatique personnelle. En quelques années, tout le monde est devenu informaticien. Les systèmes MS-DOS, puis Windows 3.1, sont devenus des références pour le grand public, habituant les utilisateurs à tolérer les bogues et les redémarrages intempestifs. La science informatique est devenue une commodité dont la valeur ajoutée a été remise en cause, jusqu'à être complètement niée, ouvrant la voie à l'externalisation puis à la "cloudification", voire au BYOD, qui sont les négations suprêmes de toute forme d'informatique interne.

Ce billet ne va donc pas essayer de résoudre un problème qui n'existait pas avant d'avoir été inventé. Il va juste pointer les défauts du processus de certification actuel, en proposant (une fois n'est pas coutume) des solutions concrètes.

Point de vue de l'éditeur

Pour l'éditeur, l'équation est simple : une CSPN coûte environ 30k€ et permet de mettre le logo "ANSSI" sur toutes ses plaquettes commerciales.

Même si le produit n'a aucune qualité, deux ou trois itérations sur la cible de certification permettront d'obtenir le précieux label sur un périmètre tellement contraint que l'échec est impossible. Rappelons que Windows NT4 est certifié "C2" (soit EAL4) sur un système qui n'a pas de lecteur de disquette, de lecteur de CD-ROM, ni de carte réseau.

Au pire le produit est une bouse innommable qui échoue même à remplir les fonctions de sécurité élémentaires pour lesquelles il a été conçu. Il n'obtiendra donc (probablement) pas la certification, mais personne n'en saura jamais rien.

Point de vue de l'auditeur

Pour l'auditeur, l'équation est plus compliquée, car elle fait intervenir son "éthique" (une notion si difficile à définir) …

La première réaction d'un auditeur qui découvre une faille peut être de la garder sous le coude. Car cela lui permettra de "réussir" tous ses pentests futurs dans le même environnement. Et après tout, No More Free Bugs.

Supposons maintenant que l'auditeur décide de remonter les failles de sécurité. C'est une obligation pour les sociétés certifiées PASSI (certification qui va être un échec, mais ceci est une autre histoire Sourire).

La communication avec le vendeur est la suivante : "Votre produit souffre d'un Cross-Site Scripting (XSS). Voici une preuve de concept en Python permettant de reproduire la faille."

Et là, tout est possible …

  • Réponse A : "C'est quoi Python ?"

Décision : vendez la faille au plus offrant. Vous allez perdre du temps avec cet éditeur, au pire il va vous menacer.

  • Réponse B : "Ok c'est corrigé."

Décision : ditchez le produit ("poubellisez" n'ayant pas encore été validé par l'Académie Française). L'éditeur a probablement utilisé un hack sordide pour corriger la ligne de code qui pose problème, afin de passer le test. La faille sera réintroduite dans la prochaine version du produit.

  • Réponse C : "Ok merci. Qu'est-ce que vous recommandez comme librairie de filtrage ? Est-ce que OWASP ESAPI est efficace contre cette attaque ?"

Décision : gardez le produit. Il y aura probablement d'autres failles, mais l'éditeur connaît son métier.

  • Réponse D : "désolé l'outil d'analyse statique que nous utilisons en intégration continue avait détecté le problème, mais le développeur a fermé le ticket sans corriger. Il sera durement châtié."

Décision : appelez moi. Vous êtes probablement en communication avec des entités extraterrestres chargées d'asservir les humains par la technologie.

La clé du problème

Le fond du problème, c'est que les audits de sécurité ne servent à rien. D'ailleurs en ce qui me concerne, j'ai arrêté le pentest. Désormais les tâcherons de l'informatique (souvent appelés "chef de projet Java" Sourire), frappés de cyber-superstition savamment entretenue par les technomanciens et autres cyber-charlatans, déposent leurs enfants accouchés dans la douleur (certains projets informatiques prennent largement plus de 9 mois) devant l'antre de la Sybille. Je questionne la pureté de leur cœur, et prononce (parfois) la sentence fatidique: "il vivra".

Mais quel est le secret de la clairvoyance ? Comment auditer un logiciel par des méthodes plus proches de la thérapie analytique que du reverse engineering ?

L'édition logicielle c'est la vie: tous les projets naissent égaux, mais certains sont plus égaux que d'autres. Car un CMS peut être né en Erlang, ou en PHP. Et born in PHP, born dead.

Pour juger de la qualité d'un produit, il est inutile de se focaliser sur les failles d'implémentation. Certes je ne nie pas l'élégance d'une exploitation de faille particulièrement ardue, mais les bonnes questions à se poser sont d'abord les suivantes :

  • Quelle est l'origine du projet ? S'agit-il du travail d'un stagiaire hâtivement rebaptisé "produit" ? Quel est l'historique de l'entreprise ?
  • Quels sont les choix technologiques opérés ? Sont-ils subis (ex. PHP c'est gratuit, Java tout le monde connait) ou choisis ?
  • Quels sont l'environnement et les méthodes de développement mises en œuvre ? Quelles sont les options de compilation utilisées ?
  • Quelle est la liste du code tierce partie et/ou Open Source intégré au produit ? L'éditeur est-il seulement capable d'en fournir la liste ?
  • Y a-t-il une équipe sécurité côté vendeur ? Y a-t-il eu des bulletins de sécurité publiés ? La liste des alertes de sécurité est-elle claire et facilement accessible ?

Mes plus grand succès en pentest ne sont pas d'avoir réussi à pénétrer un OpenVMS depuis un accès FTP anonyme, ou d'avoir analysé un firmware inconnu over the night dans une chambre d'hôtel. Mes plus grands succès sur le long terme sont d'avoir réussi à convaincre un éditeur d'effectuer une montée de version sur Visual Studio, ou d'appliquer le template SiteLock sur un contrôle ActiveX. Car indépendamment des failles d'implémentation qui restent à découvrir, cela démontre une maturité de l'éditeur sur le sujet, et procure des bénéfices beaucoup plus larges que la correction d'une faille unitaire.

A contrario, j'ai du mal à imaginer comment on peut certifier sans réserve un produit qui expose d'emblée une interface Web en PHP à des utilisateurs non authentifiés. Rien que la lecture du changelog PHP donne une idée du nombre de failles qui affecteront la version "certifiée" d'un tel produit. Sans parler des mécanismes "annexes" tels que la mise à jour, la vérification de licence, le reporting ou l'administration distante – presque toujours exclus du périmètre – et pourtant risques majeurs pesant sur la sécurité du système.

Pour avoir une certification qui fonctionne, il faut juger l'esprit d'un produit plus que son implémentation.

Des propositions concrètes

Maintenant que tous les biais du système ont été identifiés, voici des propositions concrètes qui permettraient de rendre la certification plus efficace à mon sens.

Mettre la pression sur les éditeurs

Le choix d'entrer en CSPN doit être une décision lourde de conséquences. L'une des mesures "phare", toujours réclamée, mais jamais obtenue, serait de publier la liste des produits "recalés" (assortie des motifs). Sous cette hypothèse, aucun éditeur ne s'amuserait à soumettre un produit dans lequel il n'a qu'une confiance limitée.

L'un des problèmes de fond est la valeur de la CSPN dans le temps. Certes un produit peut être conforme à un instant T selon l'avis d'un expert X, mais l'état de l'art évolue et tous les logiciels ont (et auront) des bogues. Comment faire en sorte que le travail réalisé sur une CSPN donnée puisse encore signifier quelque chose 6 mois après ? Un produit certifié CSPN il y a 10 ans, à base de DES et MD5, figurerait-il encore en bonne place sur le site de l'ANSSI ? (Notons que c'est le cas pour certains produits certifiés Critères Communs qui ne sont pourtant plus du tout à l'état de l'art).

La valeur d'une évaluation s'effrite avec le temps. Dans un autre domaine, CVSS définit un facteur "temporel" sur la criticité des failles. Voici quelques idées pour transposer le concept à la CSPN :

  • Borner dans le temps la validité d'une évaluation, par exemple à 3 ans. Au-delà, le produit devrait passer par une phase de re-certification, ou bien perdre son "tampon".
  • Obliger les éditeurs à commercialiser la version certifiée pendant toute la durée de validité du certificat, avec support technique et maintien en condition de sécurité (MCS). Après tout, on oblige bien les boulangers à fabriquer un quota de baguettes au prix réglementé.

Car la plupart des produits figurant sur le site de l'ANSSI ne sont tout simplement plus disponibles dans la version certifiée ; il existe même parfois plusieurs versions majeures d'écart. Ce qui conduit à des incompréhensions entre l'auditeur (qui découvre que la version qu'il audite est une passoire) et l'administration (qui confirme que la version "tamponnée" était bien meilleure).

Au final, comme il faut bien annoncer au client que la sécurité de son réseau est affaiblie par l'utilisation d'un produit CSPN, alors que n'importe quel produit standard de l'industrie aurait fait l'affaire, c'est un coup fatal qui est porté à tout le processus de création de confiance.

  • Suspendre ou révoquer la certification en cas de faille identifiée a posteriori, ou d'évolution majeure du produit (ex. montée de version obligatoire pour les clients).

(Accessoirement, on peut déplorer le fait que les versions auditées ne soient pas archivées par l'ANSSI dans une démarche d'investigation a posteriori, pouvant éventuellement conduire à la révocation d'un certificat.)

  • Publier le rapport d'audit technique complet. Ceci permettrait à chacun de se faire une idée ce qui a été réellement testé, ce qui a été laissé de côté, ainsi que les choix d'implémentation de l'éditeur.

Car personnellement, savoir si la couche cryptographique repose sur OpenSSL ou sur GnuTLS me donne une bonne idée sur la sécurité future d'un produit. Plus qu'un "avis d'expert : le produit est conforme à la cible de sécurité" en tous cas …

  • Ne pas accepter les certifications en "boite noire".

Il faut arrêter de se retrancher derrière la propriété intellectuelle et autres arguments juridiques, donc fallacieux : tout ça c'est du pipo pour les attaquants. Tous les consultants en sécurité sérieux pratiquent le reverse engineering, y compris dans des pays où la législation applicable est pourtant contraignante. Quant aux attaquants, ils vont plus loin et n'hésitent pas à pirater les éditeurs s'ils ont besoin d'accéder au code source.

Toute évaluation doit être effectuée par démontage total du matériel et du logiciel, facilité par l'éditeur si besoin. Bienvenue dans la "vraie vie".

(Note : je ne sais pas comment se passe réellement le processus de certification, mais on a parfois l'impression que le test a été réalisé en pure boite noire. exec.php FTW !)

Personne ne lit les cibles de sécurité

C'est un fait : personne ne lit les cibles de sécurité. Heureusement d'ailleurs, car on y trouve des énormités du style "notre produit protège le système, mais seulement s'il n'est pas compromis". Seriously.

Il est totalement indispensable pour la crédibilité de la CSPN que les cibles de sécurité n'aient pas besoin d'être lues par les utilisateurs. Que le produit soit "raisonnablement sûr" dans le cas d'usage le plus courant (principe de moindre surprise), pas dans une configuration obscure potentiellement non supportée par l'éditeur.

Les cibles de sécurité ne devraient pas être rédigées par les éditeurs, mais par les utilisateurs. Pour aller plus loin, on pourrait même imaginer que les certifications ne puissent pas être réalisées à la demande d'un éditeur, mais nécessairement d'un client final (qui peut être l'ANSSI elle-même) …

De l'importance de l'écosystème

Un produit logiciel n'existe pas ex nihilo. Il vient avec tout un écosystème : matériel, système d'exploitation, mises à jour, télémaintenance, etc. Or les failles les plus triviales (ou les plus efficaces) à exploiter sont parfois à chercher dans les catégories suivantes :

  • Mises à jour : le produit supporte-t-il les mises à jour automatiques ? Sont-elles actives par défaut et/ou obligatoires ? Sont-elles sécurisées (ex. signature) ? Le serveur de mise à jour est-il chez OVH ? Le retour à une version antérieure (downgrade) notoirement boguée est-il possible ?
  • Télémaintenance : le produit a-t-il des fonctions de télécollecte (ex. statistiques d'utilisation), voire de prise en main à distance ? Le produit doit-il être connecté à un serveur de licences sur Internet ?
  • Secrets de l'éditeur : y a-t-il un seul mot de passe "root" pour accéder à tous les logiciels du même vendeur ? (Variante : un générateur de mots de passe reposant sur un algorithme trivial). Y a-t-il des "backdoors" - à des fins de support technique bien sûr ? Les clés cryptographiques servant à signer les mises à jour sont-elles bien protégées ?
  • Sécurité de l'éditeur : l'éditeur est-il en mesure d'assurer la sécurité de ses infrastructures de développement et de support ? Un éditeur de produit CSPN ne devient-il pas automatiquement OIV ? Faut-il révoquer la certification en cas de compromission de l'éditeur ?

Utiliser le crowdsourcing

Concevoir et implémenter des logiciels robustes est une tâche ardue dans laquelle presque tous ont échoué. Identifier de manière exhaustive les problèmes de sécurité dans un logiciel complexe en moins d'un mois est une tâche impossible.

C'est pourquoi il ne faut pas avoir la prétention d'y arriver seul, mais au contraire exploiter la horde grouillante et infatigable des auditeurs en sécurité, qui besognent à longueur de journée les mêmes produits chacun dans leur coin (mais pour des clients différents).

Aujourd'hui la meilleure tactique pour un consultant en sécurité qui empile les failles consiste à les vendre à des tiers (essentiellement américains) ou à les garder sous le coude pour réussir son prochain audit – du même produit mais chez un autre client.

Les auditeurs certifiés PASSI ont déjà l'obligation de remonter gracieusement les failles découvertes au CERTA – mais il est probable que le nombre de certifiés PASSI (qui est nul aujourd'hui, la phase expérimentale venant seulement de se conclure) ne va pas exploser pour des raisons que j'évoquerai à la rentrée dans un autre billet.

Il reste donc à affiner la deuxième approche : mettre en place un Bug Bounty au niveau de l'ANSSI Sourire

La solution ultime

Le lecteur qui a eu le courage et la patience d'arriver jusqu'ici découvrira enfin la solution ultime permettant de résoudre tous les maux évoqués ci-dessus : il s'agit tout simplement d'arrêter de délivrer des labels.

Il m'a été donné d'auditer un grand nombre de produits commerciaux, expérience qui s'est enrichie de la lecture des rapports de mes pairs. Et j'ai désormais acquis la certitude qu'il est impossible de réaliser une dichotomie manichéenne entre les "bons" et les "mauvais" produits.

Certes, il existe des produits que leurs tares congénitales vouent à la roche Tarpéienne. Il serait d'ailleurs d'utilité publique d'en informer le plus grand nombre.

Mais en ce qui concerne les autres, un bon rapport d'évaluation ne va pas dire : "ok, on a rien trouvé". Un bon rapport va identifier les forces du produits (par exemple un stockage sécurisé des mots de passe), énumérer des problèmes à remonter à l'éditeur (comme des failles d'implémentation à corriger), préciser les limites de mise en œuvre à l'intérieur desquelles le produit reste relativement sûr (en général : ne pas activer les options de rétrocompatibilité).

La seule valeur ajoutée que peut apporter l'ANSSI dans le processus, c'est de collecter tous les rapports d'audit rédigés en France, y ajouter ses travaux dans des domaines que je sais nombreux par les offres de stage qui apparaissent et qui disparaissent sur son site, et publier le tout sous licence ouverte. Ainsi le niveau de sécurité des produits serait en permanence réévalué par la communauté, qui profiterait des fichiers "IDB" et autres scripts Python de tous ceux qui ont travaillé sur le sujet auparavant.

Un exemple "neutre" auquel s'applique parfaitement cette réflexion est celui du logiciel TrueCrypt. Car la version certifiée par l'ANSSI est documentée comme étant vulnérable à l'extraction du mot de passe en mémoire, lorsque le logiciel est utilisé pour le chiffrement du volume de démarrage (ce qui limite la portée d'une assertion réductrice telle que : "TrueCrypt est CSPN"). Certaines failles ont été corrigées depuis, mais personne n'a pris soin de retravailler sur une version plus récente de TrueCrypt … qui n'apporte rien de moins que le support Windows 7 et Mac OS 10.6+, entre autres.

Conclusion

La sécurité informatique est le cancer de l'industrie logicielle. Il n'y a pas d'argent pour la prévention. Seuls les malades s'intéressent au sujet, mais il est en général trop tard. Et pourtant, tout le monde y sera confronté un jour ou l'autre.

Dans ces conditions, relever le niveau de l'édition logicielle peut sembler une gageure, même pour une administration aussi puissante que l'ANSSI.

Si la CSPN partait d'une bonne intention, la décrépitude des produits les plus anciennement certifiés, ainsi que la soudaine certification de produits hautement symboliques, fait courir un risque à tout le processus de création de confiance. Car le moindre pestiféré emportera tous les autres, surtout s'il existe des alternatives plus connues, plus sûres et pourtant non certifiées.

J'espère que la lecture de ce billet constructif aura été source d'inspiration pour les quelques personnes qui détiennent un réel pouvoir sur ce sujet, et source de divertissement pour les autres.

Sur ce, bonnes vacances et rendez-vous à la rentrée pour de nouvelles aventures !

10 commentaires:

Anonyme a dit…

Ca faisait longtemps qu'on avait pas vu un nouveau billet :)

Je le trouve un peu moins acerbe que les précédents et du coup sa pertinence n'en ressort que plus.

D'ailleurs si la prise de conscience commençait par mettre des vrais RSSI en place et pas des managers gestionnaire de budgets qui comprennent pas grand chose

Dnucna a dit…

Comme pour l'ARJEL et d'autres domaines, c'est l'éditeur qui paie son évaluateur Critères Communs et ce dernier qui présente ces résultats au Certificateur.
Editeur -> Evaluateur (CESTI) -> Certificateur (ANSSI)

Ce qui est "marrant" c'est que l'évaluateur trouve un grand nombre de problèmes qu'il faut forcément corriger pour avoir la certif, mais il ne faut pas travailler trop en équipe avec l'éditeur car l'évaluateur deviendrait juge et parti. L'éditeur a donc besoin d'avoir une assistance à l'évaluation CC, qui vient soit de l'interne (rare), soit d'un autre CESTI (fréquent)...

Bref l'évaluation est globalement vendue au forfait, mais s'il y a trop l'aller-retour pour faire des corrections, la marge du CESTI chute... Il vaut donc mieux parfois glisser des choses peu significatives sous le tapis ou directement prévenir l'éditeur sans passer par l'ANSSI.
(J'ai déjà un produit être évalué deux fois car il s'agissait d'une demande d'un client final qui ne voulait pas que les résultats soient publics, dans ce cas c'est lui qui payait.)

Quoiqu'il en soit on sait qu'un système ne sera pas exempt de failles (il faut chercher les plus évidentes quand même), il est donc important de faire une visite sur site et des interviews avec les dev pour comprendre les règles d'hygiènes et bonnes pratiques suivies. L'autre point d'attention est le processus de remontée des failles, de correction et d'information des clients.

Quand on trouve une fonction de sécurité qui n'apporte aucune sécurité (pire une illusion de sécurité), elle est simplement retirée de la cible et on conseille de mettre à jour le mode d'emploi pour la déconseiller...

En ce qui concerne les CSPN, celles-ci ont pour but de donner une idée du niveau de sécurité en un mois. La version évaluée peut correspondre à celle du marché. Pour une éval CC genre EAL4, il faut plusieurs mois (voire plus d'un an) pour obtenir la certification. La version certifiée est effectivement souvent obsolète et peu d'éditeurs (aucun ?) font des versions long terme façon Redhat et ses backports de patchs sécu.

Pour le pentest, il y a le côté visible du consultant. Il faut qu'on le "voit" faire les tests de pénétration. Les clients sont déjà étonnés du nombre de jours nécessaires à la rédaction du rapport. Mais je te rejoins sur l'idée que si on voulait faire les choses correctement, il faudrait passer deux fois plus de temps à faire des recommandations adaptées au client pour qu'elles soient applicables et globales. Quand on trouve une SQL injection, il ne faut pas corriger seulement cette faille, mais revoir tout le code et expliquer au dev comment coder une requête SQL correctement, soit avec une API spécialisée, soit au moins avec des prepared statements...
A contrario quand on audite un Windows pas mis à jour et qu'on conseille de mettre en place un patch management, on peut être sûr que ça ne sera pas mis en place car trop lourd.

Bonnes vacances !

Abi a dit…

Bug bounty de l'ANSSI: Un bug -> un bounty
(deux si c'est remote default)
Aller ils t'offrent un faptaf sous payé et un Kinder Bueno en 13eme mois.


Advertising 20% off! Due to recent news, ADMbgp now only costs 4 0days!

Anonyme a dit…

On peut faire le même avec PCI-DSS ?

Anonyme a dit…

Le fond du problème, c'est que les audits de sécurité ne servent à rien. D'ailleurs en ce qui me concerne, j'ai arrêté le pentest.

Et donc tu fais quoi maintenant ?

newsoft a dit…

@Anonyme1: désolé, je ne connais pas PCI-DSS ... mais j'accepte les billets invités :)

@Anonyme2: maintenant je fais le café. Surtout depuis que la machine est RFID :)

Anonyme3 a dit…

C'est un fait : personne ne lit les cibles de sécurité. Heureusement d'ailleurs, car on y trouve des énormités du style "notre produit protège le système, mais seulement s'il n'est pas compromis". Seriously.

Oui, seriously.
Qui oserait dire que son produit protège un système, alors qu'il est compromis? Mon AV est compromis, mais il protège. Mon système de chiffrement est compromis, mais il est solide. Mon firewall est compromis, mais il filtre. Qui est le plus sérieux des deux? Celui qui évalue le système dans un mode crédible, ou celui qui part battu d'avance?

Si tu renverses l'énoncé et que tu te places dans la position de l'évalué, il apparaît évident que c'est la seule chose à dire.

Sp3ctr0 a dit…

Il nous l'avait déjà dit, il fait des sacs à main maintenant ;-)

Il faudrait aller à la source du problème.
Mettre un flingue sur la tempe des patrons.
Sanctionner les OIV qui bafouent toutes les règles élémentaires en termes de sécurité.
1M d'€ d'amende par faille trouvée.
Rémunérer les personnes ayant trouvées des failles.
Créer un "permis d'utiliser un SI". Si tu as plus de points, tu as plus le droit de te connecter à Internet.

Je divague...

Anonyme a dit…

Bonjour Newsoft,
Ce billet est une très bonne analyse du business de l'évaluation/certification SSI.
Je rajouterais 2 éléments.
Le premièr c'est que tant que l'évaluation/certification sera payée par l'évalué, il est impossible d'avoir une réelle confiance dans ses résultats. Il fut un temps où les évaluations étaient payées par l'administration...
Le deuxième concerne les cibles de sécurité. Il a eu dans les années 2005-2007 une nouvelle version de la partie 2 des critères communs (la partie qui décrit les exigences fonctionnelles, et que à mon humble avis personne ne comprend...), cette nouvelle version visait justement à rendre compréhensible cette partie (et donc à rendre lisible les cibles de sécurité) a été soumise pour avis aux industriels et experts du secteur, et il y a eu une grande fronde contre cette nouvelle version (en particulier les éditeurs US) qui a donc été abandonnée. Et au final, cela arrange tout le monde : comme personne ne comprend la cible (les fonctions qui doivent être évaluées), cela laisse toute latitude pour faire ce que l'on veut et avoir les résultats que l'on veut.
J'exclu de cette analyse les évaluations/certifications de micro_circuits et cartes à puces qui applique une démarche particulière (les cibles ne sont pas plus compréhensibles dans ce domaine mais il y a une certaine homogénéité entre ces évaluations, et elles sont adaptées au domaine).
TplusK

Anonyme a dit…

Bien, bien.

Pour citer Mr Vauvenargues "Pour plaire il faut mentir". Cela s'applique a tout, et c'est particulièrement vrai lorsque le business et l'économie priment.

Les financiers des DG, devraient supprimer toute sécurité, mais ils s'approcheraient du fonctionnement de la société russe (bien que ceux-ci n'ont pas 110 millions de cartes bancaires volées!!

Nous n'avons pas fini de rire.

un ancien ing sys constructeur, puis ex KAM comptes Défense.