Application Security Resources

Sub Text of Application Security Resources

Quand les applications ne garantissent pas la sécurité des données : Analyse d’une violation de données chez JP Morgan

December 9, 2013

Tiny Url for this post: http://tinyurl.com/qx7rrax

Jeudi dernier, JP Morgan a publié une alerte à l’attention de 465 000 titulaires de cartes de paiement prépayées, pour les informer que leurs données personnelles avaient été consultées par des pirates, après que ces derniers aient attaqué le réseau JP Morgan au mois de Juillet. JP Morgan n’a détecté cette violation de données que deux mois plus tard, à la mi-septembre.
A première vue, cette nouvelle n’est pas d’un intérêt exceptionnel. Il y a déjà quelques années que nous entendons parler de fuites de données. Derrière chacune de ces fuites, réside un échec fondamental à protéger les données des utilisateurs, en raison de l’ignorance des bonnes pratiques de sécurité de base. Cependant, ce n’était pas le cas ici. Selon les rapports fournis par JPMorgan, tout a avait été effectivement fait dans les règles. Toutes les données sensibles concernant les utilisateurs et stockées dans les bases de données avaient été cryptées, ainsi qu’avaient été prises toutes les mesures de protection standard. Mais alors, qu’est-ce-qui n’a pas fonctionné ?
L’origine du problème vient d’un développeur qui, suite à une erreur assez fréquente, a permis que cette violation se produise. L’un des composants de l’application a écrit certaines des informations qu’il utilisait, dans un fichier log (journal) , fichier qui ensuite a été violé. Cette pratique de développement est courante puisque les journaux permettent aux développeurs d’identifier les bogues dans leurs logiciels. Les problèmes commencent quand les développeurs ne sont pas suffisamment informés de ce qui devrait ou ne devrait pas rentrer dans les fichiers logs. Il est évident que le développeur de JPMorgan n’avait pour but que de fournir les informations nécessaires à la correction des bogues et aux dépannages futurs, mais en faisant cela, il a provoqué une faille sérieuse dans les données, et son entreprise a dû en supporter le coût subséquent.
Cet exemple souligne ce je que prêche sans relâche, depuis mes débuts en tant que consultant en sécurité des applications : la sécurité des applications et la sécurité des données sont indissociables. Vous ne pouvez pas mettre en place la sécurité des données sans vous occuper de la sécurité de l’application, car votre application gère vos données les plus sensibles de façon régulière. Le cas de JPMorgan est très courant : d’un point de vue purement politique, toutes les pratiques de sécurité des données ont été respectées, notamment la mise en place de contrôles de sécurité pour vérifier que les répertoires de données définies sont bien cryptés, ce qui constitue une piste d’audit appropriée. Cependant, les fichiers logs ponctuels qui sont internes à l’application, ont été négligés et n’ont jamais été vérifiés.

Des cas comme celui-ci mettent l’accent sur la nécessité de corréler la sécurité des données avec la sécurité des applications. Puisque JPMorgan a protégé ses données de manière appropriée, nous pouvons très vraisemblablement supposer que cette société avait consacré un certain nombre de ressources pour sécuriser l’application. Cependant, la plupart des solutions de sécurité des applications disponibles aujourd’hui, se concentrent uniquement sur le code, au lieu d’observer à la fois le code et les données, ce qui les rend incapables de détecter des situations semblables à celle présentée ici.

Un analyseur statique de code, ne serait pas non plus capable d’identifier un tel problème, à moins d’avoir été configuré manuellement pour le tester, et après le marquage manuel des noms de champs et des variables contenant des données sensibles. Demander aux développeurs d’affiner leurs analyseurs statiques de code afin que ces tâches puissent être réalisées, est tout aussi irréaliste. S’ils y avaient pensé, ils n’auraient pas provoqué cette faille.

Par conséquent, que nous apprend cet incident ? Qu’il faut toujours avoir à l’esprit cette réalité évidente : la sécurité des données et la sécurité de l’application font partie du même problème. Vos applications gèrent vos données les plus critiques, et, pour cette raison, la sécurité de l’application doit se concentrer sur la façon dont elle interagit et affecte vos données. Vous appuyer sur des solutions de sécurité des applications qui surveillent uniquement le code statique, n’est tout simplement pas suffisant.

Chez Quotium, nous croyons que la sécurité des données et la sécurité des applications sont inséparables. C’est pour cette raison que l’un des tests les plus importants, effectué par notre solution, Seeker, est le monitoring de toutes les données critiques tout au long de l’application, et l’identification de toute fuite potentielle des données, que ce soit par un fichier journal, comme dans le cas de JPMorgan, par des tiers non sécurisés, ou même par l’utilisateur. C’est pourquoi nous n’avons pas été surpris par l’incident JPMorgan. Nous rencontrons ce genre de problème tous les jours.

This post is also available in: Anglais

Learn more about Seeker

More Autres Ressources