130 millions de cartes volées : la sécurité des applications en question

En août 2009, Alberto Gonzales et deux hackers russes non-identifiés ont été mis en accusation aux Etats Unis pour le vol informatique de 130 millions de numéros de cartes de paiement de plusieurs sociétés. La très grande majorité des cartes volées était gérée par Heartland Payment Systems, un grand spécialiste du traitement des paiements par cartes pour compte de tiers avec 11 millions de transactions par jour venant de plus de 250 000 sites clients. Gonzales et ses comparses se sont appuyés essentiellement sur la vieille technique "Injection SQL", bien connue des RSSI et de tout hacker même débutant. Pourtant, Heartland a été régulièrement certifié conforme à la norme PCI DSS, standard de référence en matière de sécurisation du traitement des cartes.

Si les grandes lignes de ce crime spectaculaire ont été rendues publiques, beaucoup de détails ne sont pas encore connus. Néanmoins, cette affaire appelle d'ores et déjà quelques observations.

D'abord, elle confirme avec éclat la montée en puissance de la cyber-criminalité organisée et l'importance des enjeux. (La même remarque vaut aussi pour la cyber-guerre étatique et non-étatique, mais c'est un autre sujet.) Avec l'interconnexion généralisée des ordinateurs et des équipements clients sur Internet (et sur les Intranets), Duquesne Research estime que cette tendance va continuer... en s'amplifiant. Dans le cas actuel, Gonzales revendait les données confidentielles des cartes à des bandes organisées, à un prix variant de $3 à $10 la carte. Il s'agissait donc d'une activité hautement lucrative. Les pertes directes pour Heartland sont chiffrées actuellement à plus de 20 millions de dollars mais l'addition finale risque d'être bien plus salée. Dans un cas précédent TJX, la perte finale s'est établie à environ $200 million, compte tenu des lois américaines de protection du consommateur. Ironie du sort, le coupable était ce même Gonzales ... qui s'était reconverti par la suite en consultant.

Mais au-delà des pertes directes, les vrais dégâts se situent au niveau de la réputation de l'entreprise. Le fond de commerce d'une société comme Heartland est la confiance de ses clients. En fait, pour toute entreprise ou organisation qui gère des données confidentielles de clients, le "risque réputationnel" constitue un enjeu énorme.

Notre deuxième observation concerne la confusion persistante - amplement mise en évidence par les discussions autour de cette affaire - entre la conformité à une norme de sécurité et une véritable sécurité effective. Conformité ne veut pas automatiquement dire sécurité. Ce point est très important et mérite l'attention. Des standards comme PCI DSS ou encore ISO2700x sont très utiles voire indispensables, car ils indiquent l'état de l'art des moyens organisationnels et techniques à mettre en oeuvre pour se protéger. Mais d'une part ils ne peuvent jamais tout prévoir, d'autant que les menaces peuvent évoluer plus rapidement que les mises à jour des normes, d'autre part ils s'apparentent à une obligation de moyens et non de résultat. Pour passer de l'une à l'autre, il faut une surveillance continue par la société. Pour illustrer simplement : si la bonne pratique standard me dit de fermer mes portes à clé je le fais et je le vérifie tous les jours ! L'audit qui passe tous les six mois ne peut tenir ce rôle de vérificateur de premier niveau. L'audit testera sur un échantillon le fait que mes portes sont fermées et que je le vérifie. L'absence de vérification par l'entreprise ne saurait être compensée par un audit !

Cet aspect est très important car Heartland était régulièrement certifié "conforme" à PCI DSS (ce qui exige d'ailleurs des mesures contre l'Injection SQL) et pourtant... Dans la polémique qui a suivi la découverte de la fraude, Visa a reproché à Heartland non pas tellement ces petits manquements au standard mais plutôt son manque de vigilance. Encore une fois, nous ne disposons pas de toutes les informations. Mais de toute façon, en matière de sécurité des informations, aucun audit ponctuel de conformité ne peut se substituer à une surveillance permanente, forcément sous la responsabilité du management.

Troisième observation : le terrain de bataille de la cyber-criminalité n'est plus principalement le réseau comme auparavant mais plutôt les applications. Un très grand nombre d'applications concernant des flux financiers ou d'autres données confidentielles sont maintenant accessibles de partout dans le monde sur Internet (ou bien au-travers des Intranets). Beaucoup comportent des vulnérabilités importantes et multiples, surtout lorsqu'elles sont anciennes. Ce qui est le plus choquant dans cette dernière affaire est l'utilisation de l'Injection SQL, une technique qui est presque aussi vieille que le langage SQL. L'injection des commandes SQL - soit dans des champs utilisateurs soit dans la fenêtre URL -, permet à celui qui attaque une application vulnérable de découvrir la structure des tables puis d'en extraire des données. Cette même technique était employée en 2005 dans l'attaque contre CardSystems, une attaque dont les coûts étaient tellement élevés que la société victime a manqué faire faillite.

Toutefois, la popularité de l'Injection SQL ne devrait pas nous faire oublier d'autres techniques comme, par exemple, l'Injection LDAP, les Attaques SOAP, l'Injection XPath etc. En tout état de cause, si l'affaire Gonzales était assez sophistiquée sur le plan organisationnel, elle semble avoir été assez basique sur le plan technique. il ne faut pas oublier non plus qu'avec le temps, les hackers peuvent trouver de nouvelles astuces, ce qui fait qu'une application jugée non vulnérable en 2008 peut le devenir en 2009.

Ceci nous amene à notre quatrième observation, à savoir, que la sécurisation des applications doit couvrir l'ensemble de leur cycle de vie, de la conception jusqu'à la production normale en passant par le codage et les différentes recettes. Trop souvent, les exigences de sécurité ne sont pas correctement prises en compte en amont, parce que les développeurs des applications ne sont pas familiers avec la sécurité et les experts en sécurité ne connaissent pas les applications. Dans la phase de conception par exemple, de nombreux aspects sont à traiter, notamment les validations obligatoires (pour bloquer des injections), l'encryption éventuelle des données, les fonctions DB à désactiver, l'interaction avec des applications existantes, etc. Ensuite, le coding devrait respecter des standards qui reflètent au moins une vision des vulnérabilités connues. Préalablement à la recette en production, la revue du code - soit de manière manuelle soit par analyse automatisée - s'impose. Enfin, les applications à risque déjà en production devraient être contrôlées régulièrement. Bien entendu, l'importance des efforts consentis devrait être modulée en fonction des enjeux par une analyse des risques régulière.

Cinquième et dernière observation : l'industrie IT peut apporter des outils pour gérer les vulnérabilités applicatives. Pour faciliter la revue du code, des outils automatisés sont disponbiles. Le marché de logiciel SVM ("Security and Vulnerability Management") est encore petit mais croît très vite. En France, parmi les fournisseurs on peut citer Fortify, qui fait figure de pionnier, et qui est spécialisé aujourd'hui sur l'analyse du code. Les constructeurs HP et IBM proposent des solutions intégrées portant sur l'ensemble du cycle de vie. HP par exemple dispose d’une plate-forme de sécurité comprenant un ensemble d’outils pour :
• L’analyse de code : les fonctionnalités de l’analyseur assurent que le code développé est sain et ne comporte pas de faille de sécurité,
• Les tests : le logiciel permet d'automatiser la détection des anomalies de sécurité dans les applications au cours de la phase d’assurance qualité
• La fourniture d’analyses de sécurité des applications et des environnements avant la mise en production et pendant l’exploitation, et la création de rapports personnalisés (validation de modèles, règles et conformité).

Une autre approche serait le recours à une protection dynamique externe à l'application. Dans cette catégorie se trouve les WAF ("Web Application Firewall") capable de filtrer dynamiquement le contenu des données pour identifier et bloquer des attaques. Le marché pour ce type de solution est encore en émergence, peut-être du fait d'une certaine complexité de mise en oeuvre. En effet, un WAF est bien moins "générique" qu'un pare-feu réseau classique. Son bon fonctionnement dépend du paramétrage, en quelque sorte de sa "connaissance" de l'application. Parmi les fournisseurs, on trouve les grands noms en matière de réseau mais aussi quelques "challengers" plus spécialisés.

Duquesne Research estime que les deux approches sont complémentaires et que - face à l'essor de la cyber-criminalité - les deux marchés se développeront rapidement sur les 24 mois à venir.

Il faut élever la barrière à un coût raisonnable pour l'entreprise face à son appréciation du risque ; de manière à ce que le hacker se trouve face à un mur trop haut à franchir par rapport à ses gains espérés. Dans ce contexte, Duquesne Research propose trois recommandations:

- D'abord, procéder à une analyse rapide des risques, prenant en compte les enjeux financiers et réputationnels pour l'entreprise, l'exposition des applications potentiellement à risque sur l'Internet (et sur les Intranets) et les mesures déja en place. Cette analyse sera à rafraîchir régulièrement.

- Ensuite, sur cette base, définir un plan d'actions pour les applications en production. Il s'agit d'identifier les vulnérabilités et de mettre en place des mesures de correction et/ou de protection, s'appuyant sur des outils de type SVM ou WAF ou les deux.

- Enfin, intégrer les exigences de sécurité à chaque étape du cycle de vie des applications, en capitalisant sur les faiblesses découvertes et sur les avancées des bonnes pratiques.

Pour les entreprises avec des applications vulnérables (autrement dit, beaucoup de monde), la révélation des attaques spectaculaires comme le cas Gonzales/Heartland devrait au moins servir - comme la guillotine - à "focaliser les esprits" ... et faire prendre conscience de la nécessité impérieuse de maîtriser ces risques.