Application Security Resources

Sub Text of Application Security Resources

La sécurité des applications dans le cycle de vie du développement

November 8, 2013

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

Enjeux, Défis et Solutions

Les applications Web sont devenues la principale source de violation de données dans la plupart des organisations. En effet, les failles de sécurité des applications web constituent pour les hackers de véritables opportunités pour s’emparer des informations précieuses d’une entreprise, insérer du code malveillant dans son système, pénétrer plus profondément dans son réseau pour atteindre ses ressources internes.

Une enquête récente sur les failles de sécurité des Fortunes 500,  montre que les vulnérabilités pourraient entraîner des pertes financières pouvant aller jusqu’à 20 milliards d’euros. Cependant, 90% des grandes entreprises ont détecté une ou plusieurs failles dans la sécurité de leur système d’informations au cours des 12 derniers mois. Plus grave encore, 70% de ces vulnérabilités constatées sont considérées comme sévères, plusieurs d’entre elles pouvant avoir pour conséquence le vol d’informations confidentielles et la fraude financière.

Même les entreprises dotées des systèmes de sécurité web les plus sophistiqués sont exposées aux failles de sécurités. En réalité, les vulnérabilités dans les applications ne sont pas stoppées, même lorsque les entreprises ont mis en place les systèmes de défense très perfectionnés.

Dans ce livre blanc, seront développées les raisons pour lesquelles la sécurité des applications tout au long du cycle de vie du développement est nécessaire pour prévenir les failles de informations.

Introduction

Aujourd’hui, les applications web ont gagné en popularité pour devenir l’un des outils majeurs des organisations et des entreprises pour leur permettre de s’interconnecter avec leurs clients et prospects. Malheureusement les pirates peuvent faire usage des failles de sécurité dans ces applications web pour voler des informations clients, exposer les dossiers clients sensibles à des attaques, et finalement ruiner la réputation de l’entreprise.

Bien que de nombreuses sociétés trouvent que les pare-feu et le cryptage SSL (Security Socket Layer) soient utiles pour protéger l’accès à leurs applications, ces dispositifs ne sont pas suffisants.

Des études récentes montrent que trois sites web sur quatre sont vulnérables aux attaques et la majorité de ces attaques portent sur les applications elles-mêmes contre lesquelles les pare-feu et les SSL sont impuissants.

Toute entreprise peut être confrontée à une grande variété de problèmes de sécurité, et à un certain nombre de préoccupations techniques ou métier générées par les failles de sécurité. Quelles actions entreprendre pour sécuriser les applications et comment faire face à ces défis de façon à ce qu’ils contribuent à soutenir et à développer l’organisation ?

Tous  ces aspects seront abordés dans ce livre blanc.

Impact des failles de sécurité sur les métiers

Les failles de sécurité ont atteint des niveaux de coûts très élevés, représentant pour les entreprises des milliards de pertes financières chaque année. Chaque entreprise qui gère des informations confidentielles peut rencontrer des failles de sécurité à certains points de son fonctionnement quotidien.

L’idée que se font souvent les gens, selon laquelle les failles de sécurité ne se produisent généralement que lors de phénomènes uniques tels que le piratage de sites ou le vol d’informations, est inexacte. En réalité les failles de sécurité visent un champ beaucoup plus large et peuvent toucher l’ensemble des ressources informationnelles d’une entreprise. Lorsqu’on envisage la lutte contre les failles de sécurité des applications, trois lettres clés sont à retenir : CID pour Confidentialité, Intégrité et Disponibilité, à partir desquelles on peut se poser les questions suivantes:

  • Confidentialité : la confidentialité de nos informations est-elle assurée, ou bien ces dernières sont-elles susceptibles d’être compromises par des personnes non autorisées ?

 

  • Intégrité : l’intégrité de nos informations est-elle protégée de façon à toujours garantir la précision et la fiabilité sur lesquelles nous pouvons compter ?

 

  • Disponibilité : nos informations sont-elles en permanence disponibles pour ceux qui en ont besoin, au moment où ils en ont besoin ?

 

Les failles de sécurité peuvent affecter votre entreprise de plusieurs façons : réduction de chiffre d’affaires, augmentation des coûts, baisse de la clientèle et perte de la confiance des investisseurs.

L’indisponibilité d’un site web peut provoquer en deux jours une perte de revenus d’un milliard d’euros chez un revendeur, à laquelle s’ajoutent les frais de correction, les coûts découlant de la responsabilité, ainsi que les divers dommages et pertes d’informations.

Les frais de correction peuvent inclure :

 

  • Le Coût d’un employé – non spécialiste de la sécurité web – pour travailler uniquement à la correction de la faille, s’assurer qu’elle ne reproduise pas, et informer les clients des risques auxquels ils exposent leurs informations. Le salaire moyen avec ses charges de cette personne est d’environ 72 000 € par an, soit 6 000 € par mois.

 

  • Le Coût d’un consultant sécurité – de 8 000 € à 25 000 € par semaine pour une assistance sur place, sans mentionner tout autre coût possible si la faille est importante.

 

  • Le Coût d’une correction de faille pouvant atteindre 500 000 € si votre activité utilise le Paiement par Carte.

 

Au-delà des coûts de correction et la perte de revenus, les failles de sécurité se traduisent également par la perte de clients. Des études récentes indiquent que 10% des clients délaisseront une entreprise dont le site aura été attaqué.

 

Mais ce n’est pas tout : les failles de sécurité peuvent entraîner des répercussions profondes pour le développement de l’entreprise.

 

Qu’est-ce que la sécurité des applications ?

La sécurité des applications est un processus qui commence au début du cycle de vie du développement d’une application pour assurer la plus grande sécurité possible du développement (codage), du système, du dispositif sur lequel l’application s’exécute, ainsi que du réseau de connexion, d’authentification et d’autorisation des utilisateurs.

Définition de la sécurité des applications selon Wikipedia :

 

« La sécurité des applications englobe les mesures prises tout au long du cycle de vie de l’application pour empêcher des exceptions à la politique de sécurité d’une application ou des systèmes sous-jacents (vulnérabilités), à travers des failles dans la conception, le déploiement, la montée de niveau ou la maintenance de l’application. »

 

La sécurité des applications permet l’élimination des attaques potentielles sur les sites web et les applications lors de l’exécution en interne, ou publiquement sur Internet. Ce processus réduit les risques imprévus, la perte financière et renforce ainsi la confiance des clients.

 

  1. Pourquoi les pare-feu traditionnels et les SSL sont inefficaces contre les attaques applicatives ?

 

Les applications web sont hébergées sur des serveurs web. Pour que les utilisateurs puissent accéder aux applications, l’ouverture d’un port http est nécessaire pour accepter les requêtes des utilisateurs. Pour compromettre les applications web, les hackers utilisent aussi les requêtes http via les ports autorisés et ainsi accéder au système interne sans être rejetés par les pare-feu car les pare-feu traditionnels ne fonctionnent que dans la couche inférieure et ne peuvent pas détecter les attaques portées par le http.

 

Les attaques applicatives entrent dans l’application essentiellement via le flux http autorisé par le pare-feu, et lorsqu’elles sont interprétées par l’application, les données malveillantes des requêtes permettent l’accomplissement des opérations malveillantes.

 

Le SSL n’est pas plus efficace dans la protection contre les attaques applicatives. SSL est utilisé pour encrypter le flux entre l’utilisateur et l’application. Comme nous l’avons déjà constaté, les pirates mènent des attaques sur les applications web de la même manière que les utilisateurs accèdent à l’application. Cela signifie que la requête malveillante est enveloppée dans le SSL du  côté utilisateur, puis le SSL est décrypté pour que la requête soit traitée par l’application. C’est à ce moment que l’attaque a lieu.

 

Il est donc évident que ni les pare-feu ni le SSL ne peuvent protéger les utilisateurs contre les attaques applicatives, car ces attaques ciblent les vulnérabilités au niveau du code source de l’application. Elles détournent la façon dont le code source gère et traite les entrées utilisateur. Les failles de sécurité des applications sont essentiellement des bugs dans le code source de l’application. Ces bugs sont le facteur derrière lequel les vulnérabilités sont détectées dans les applications web.

 

Alors que les applications web exposent les organisations à des de menaces de sécurité et de violations de données, celles-ci peuvent encore limiter les risques, corriger les failles et réduire les coûts associés, au moyen de solutions de sécurités applicatives appropriées.

 

  1. Conseils visant à réduire les vulnérabilités dans la sécurité des applications

 

Bien que les vulnérabilités puissent avoir un impact important sur les organisations en termes de pertes financières et de données, certaines mesures stratégiques de sécurité pourraient être prises afin de réduire les risques, et aider les entreprises à fidéliser les clients et assurer leur chiffre d’affaires.

 

6.1. La sécurité des applications depuis les premières phases de

conception

 

Un logiciel de conception robuste, soigneusement planifié et exécuté, conduit à un logiciel qui coûte moins cher à développer et à maintenir. Le même principe est valable pour la sécurité des applications. Planifier un logiciel en ayant à l’esprit la sécurité des applications dès le début de la conception, conduit à un logiciel avec moins de bugs relatifs à la sécurité applicative, et un potentiel moindre de vulnérabilités.

 

Cela ne signifie pas que la conception d’applications soucieuse de la sécurité garantit la sécurité du logiciel, mais qu’un nombre moindre de failles sera détecté au cours des phases de développement, de test et de production, et moins de failles affectant la totalité de l’application seront susceptibles d’être trouvées.

 

6.2 Intégrer la sécurité des applications dans le cycle de vie du

développement

 

La présentation et la mise en œuvre de la sécurité des applications dès le début du cycle de développement logiciel permettent aux entreprises de répondre aux exigences accrues des clients en matière de produits et services plus sécurisés.

 

Tout aussi importants sont les coûts de correction. Les failles de sécurité étant des bugs dans le code, les mêmes règles s’appliquent pour les bugs de sécurité que pour les autres bugs. – une détection précoce induit des coûts moindres. La détection tardive durant les phases de post-production peut multiplier par dix le coût des corrections des bugs détectés précocement.

 

La sécurité des applications est souvent  planifiée dans les phases clé du cycle de développement logiciel. Ces phases comprennent :

 

  • La formation des équipes de développement à la sécurité des applications, la politique et les capacités de l’organisation à s’assurer que ces équipes se tiennent informées des dernières mises à jour en matière de sécurité et de protection de la confidentialité des données.

 

  • La planification et la conception: considérer la sécurité et la confidentialité lors de la conception de nouvelles fonctionnalités des produits et intégrer la sécurité dans les applications, avec un minimum d’interruptions.

 

  • La mise en œuvre: éviter les erreurs de codage pouvant créer des vulnérabilités ainsi que l’utilisation d’outils de développement sophistiqués pour construire un code sécurisé.

 

  • Les phases de test et de vérification: appliquer les vérifications appropriées sur les applications logicielles et s’assurer qu’elles produisent la fonctionnalité adéquate, telle que définie dans la conception initiale.

 

  • Les versions et réponses: s’assurer d’avoir les bons plans ou protocoles d’intervention lorsque de nouvelles menaces apparaissent au fil du temps.

 

6.3. Impliquer tous les acteurs concernés

 

Les failles de sécurité des applications qui sont identifiées au cours des tests ou de la production, ne se sont pas uniquement le problème des équipes de sécurité. Une fois que les bogues dans le code qui affectent la sécurité de l’application ont été  identifiés, l’implication de toutes les parties prenantes concernées est nécessaire pour y remédier.

 

De la même manière, la responsabilité de la sécurité des applications doit être répartie entre les différentes parties prenantes de l’organisation du développement. Etant donné que la sécurité des applications concerne principalement l’écriture d’un code sécurisé, et les tests pour la recherche des failles de sécurité des applications, les équipes de développement et de test devraient avoir la responsabilité d’un développement et de tests sécurisés avec l’aide et sous le contrôle des équipes de sécurité.

 

6.4.  Evaluer les composants logiciels externes

 

Il y a une idée fausse très répandue qui consiste à penser que les composants logiciels externes n’ont pas besoin d’être testés au niveau de leur sécurité. Cela est communément considéré comme relevant de la responsabilité du vendeur, ou en tous cas ne pouvant pas être testés en interne.

 

–  Cependant, cette approche est erronée pour plusieurs raisons. Principalement parce les pirates ne se soucient pas de qui a écrit le code. Si des vulnérabilités existent, ils les détecteront et les exploiteront.

 

– Une fois que les composants externes ont été intégrés à l’application, ils deviennent une part inhérente de cette dernière. Toutes les failles de sécurité pouvant être contenues dans ces composants ou modules affectent directement l’application et les informations de l’entreprise qu’elle contient.

 

– Les modifications effectuées sur les composants tiers sont souvent vastes et contiennent des milliers de lignes de  code. Ce code est parfois négligé dans les processus de test, car il est considéré comme n’étant pas entièrement écrit en interne. Cependant, ce n’est pas du code externe non plus. Ces modifications devraient être considérées comme du nouveau code et minutieusement testées.

 

6.5. La sécurité ne s’arrête pas au déploiement

 

La sécurité des applications est un processus continu, et devrait être considéré dans toutes les phases du SDLC, y compris les phases post-déploiement.

 

Le code est constamment modifié, soit en raison de corrections de bugs, soit de modifications et d’ajouts de fonctionnalités supplémentaires. Ce code devrait être évalué au niveau des failles de sécurité de l’application. En réalité il est souvent négligé en raison des contraintes de temps ou de préjugés sur le fait que de petits ajouts de code ne sont pas susceptibles de conduire à des vulnérabilités.

 

En outre, de nouvelles attaques sont détectées régulièrement, et les applications existantes doivent être évaluées pour de nouveaux problèmes.

 

  1. Les évaluations externes par rapport à l’approche intégrée SDLC

 

Le choix des solutions appliquées lors des phases de développement, de vérification et de test du cycle de vie de développement logiciel, joue un rôle crucial dans la détection des failles de sécurité, l’atténuation des risques de d’attaques, et surtout dans la sécurisation des applications et des données critiques de l’entreprise.

 

Pour cette raison, lorsque les entreprises se tournent vers des fournisseurs tiers de solutions de sécurité dans les phases de test et de vérification, deux types de services sont à prendre en considération.

 

  • Evaluation externe de la sécurité – qu’il s’agisse de tests de pénétration ou de revues de code.

 

  • L’intégration d’une solution dans le SDLC – mise en œuvre d’une solution dans les phases de développement et de test.

 

Les solutions d’évaluation des vulnérabilités sont utilisées comme des solutions applicatives intégrées dans les phases de développement et de test des logiciels, alors que les tests de pénétration et les revues de code sont utilisés comme un service externe effectué périodiquement.

 

La différence entre la sécurité intégrée dans le SDLC, et l’évaluation externe est expliquée dans le tableau  suivant :

 

 

 

FONCTIONNALITES

 

SECURITE INTEGREE AU SDLC

 

 

 

EVALUATION EXTERNE

 

Fréquence d’exécution

 

 

– Continue

– A Chaque modification de code

 

 

A dates fixes

 

Rapports

 

Les vulnérabilités sont gérées comme des bugs

 

Rapports sur l’état de la sécurité à un moment M

 

 

Mesures

 

Liste des vulnérabilités de l’application

 

Liste des vulnérabilités de l’application

 

 

Intervenants

 

Internes

 

– Ressources externes

– Fournisseurs tiers

 

 

Coûts

 

 

Le coût de correction d’une vulnérabilité détectée en phase de production est 6.5 fois supérieur à celui d’une faille détectée au commencement du SDLC

 

 

– Coût supérieur pour  des consultants externes spécialistes de la sécurité

 

– Temps de traitement plus long et frais de gestion supérieurs

 

 

Bénéfices

 

– Augmentation de la sensibilisation à la sécurité des membres de l’équipe

 

– Amélioration de la qualité des applications

 

– Réduction de la pertinence et de l’impact des vulnérabilités exploitées

 

 

 

 

 

Contrôle préventif permettant de réduire les failles de sécurités et limiter les expositions aux risques

 

 

Conseil expert :

 

Le processus de développement sécurisé et l’évaluation de sécurité sont des outils puissants de contrôle et de détection des failles applicatives qui doivent être utilisés ensemble pour accroître le niveau de sécurité des applications métier.

 

 

  1. Une nouvelle approche de la sécurité des applications dans le SDLC

 

Les équipes de développement et de test sont tenues de livrer dans des délais stricts, des applications solides qui  fonctionnent correctement. Dans ces conditions d’exigence, et afin d’implémenter la sécurité des applications dans le SDLC,  nous suggérons une solution  qui devra être précise, claire dans ses résultats, et simple à utiliser.

 

Les tests de vulnérabilité dans le cadre du SDLC devront être intégrés à un programme plus large de gestion des vulnérabilités (également connu sous le nom de VMP – Vulnerability Management Program). Un VMP solide est composé de plusieurs éléments tels que le système de détection, la classification des actifs, les tests de vulnérabilités, la hiérarchisation, la correction, l’analyse de l’origine des failles, etc…

 

Une bonne solution de test des vulnérabilités doit permettre non seulement d’identifier avec succès les vulnérabilités qui constituent une menace réelle pour l’application, mais aussi d’afficher les corrections appropriées, et enfin fournir les moyens de hiérarchiser les mesures correctives. Dans l’idéal, elle devrait  pouvoir indiquer la section de code comportant des vulnérabilités, faire des recommandations de correction et également de  permettre de jouer la simulation d’exploits contre ces failles de sécurité. Elle devra bien sûr  s’intégrer aisément dans les process de développement déjà existants dans l’organisation.

 

Toutes ces fonctionnalités se retrouvent dans la solution Seeker développée par Quotium Technologies.

 

Seeker utilise une technologie unique qui met en corrélation le code applicatif au moment où il s’exécute ainsi que le flux des données avec des attaques simulées. On obtient ainsi un niveau de précision optimal, permettant la livraison de vulnérabilités réelles et l’élimination des faux positifs. Cette fonction est cruciale dans le cadre d’une sécurité applicative intégrée au SDLC car les temps de développement sont précieux, et ne peuvent être consacrés à l’analyse de bugs qui sont en fait des faux positifs. Seeker établit une corrélation entre les approches extérieur-vers-intérieur, et intérieur-vers-extérieur, offrant aussi bien une visibilité nette de l’intérieur du fonctionnement de l’application, que la vision extérieure d’un hacker virtuel en train d’attaquer l’application.

 

Les résultats fournis par Seeker sont clairs et contiennent toutes les informations nécessaires aux équipes de développement, de test, de gestion et de sécurité pour comprendre la vulnérabilité identifiée, facilement l’analyser et la corriger. De plus, en réalisant des exploits simulés contre l’application, Seeker fournit les vulnérabilités déjà classées par ordre de priorité selon leur impact potentiel.

 

Afin de s’adapter et faire partie du cycle de vie du développement des applications, Seeker est fourni avec plusieurs outils qui facilitent son intégration dans les process existants. Seeker s’interface avec tous les systèmes de gestion des bugs pour livrer des vulnérabilités identifiées comme des bugs de l’application. Il fonctionne avec des outils automatisés d’assurance qualité (tels que HP QTP, Selenium, etc…) pour cartographier et comprendre l’application et ses scénarios. Ces scénarios sont ensuite utilisés pour subir des tests de sécurités des applications.

 

De plus, Seeker peut être activé comme faisant partie d’un programme de test existant, par exemple pour effectuer des tests de sécurité des applications dans le cadre de tests de régression, de tests d’intégration continue, etc…

 

 

  1. Conclusion

 

La sécurité des applications étant devenue une exigence essentielle du développement logiciel, il est possible aujourd’hui de réduire le potentiel de préjudices nuisibles à l’entreprise, les atteintes à sa confidentialité ou des pertes financières éventuelles.

 

Les entreprises qui ont expérimenté une sécurité applicative intégrée au SDLC en ont tiré les bénéfices suivants : elles ont évité le gaspillage de temps et d’efforts à traiter les failles au commencement de la phase de lancement de produit,  et elles ont pu prévenir les complexités de répétition des phases de test plus tardives dans le cycle de développement, ou après que l’application ait été déployée.

 

Pour des projets contenant un million de lignes de code, la sécurité des applications permet d’économiser environ 8 000 € par an, grâce à la prévention des vulnérabilités, ainsi que 3 200 € d’économie supplémentaire, grâce à l’augmentation de l’efficacité et de la productivité des équipes de développement (réduction du temps passé à corriger les failles).

 

Bien qu’il ne soit pas toujours possible d’éviter totalement les failles de sécurité au cours du cycle de développement logiciel, surtout quand il s’agit d’un projet à grande échelle, des outils et des process existent qui peuvent malgré tout aider les entreprises à détecter et à corriger les failles de manière efficace. Plus important encore, les résultats de tests fournis par ces outils, présentés de manière pertinente et exploitable, peuvent également être intégrés au flux opérationnel métier.  Ainsi le process de détection et de correction en est accéléré et permet à l’entreprise de consacrer davantage de temps à d’autres activités.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

___________________________________________________________________________

 

 

QUOTIUM TECHNOLOGIES

 

Quotium Technologies est une société spécialisée dans le développement de solutions logicielles innovantes pour garantir la sécurité et la fonctionnalité des applications critiques de l’entreprise tout au long de leur cycle de vie.

 

Seeker est le leader de la nouvelle génération de logiciels de test de sécurité des applications. S’intégrant facilement aux processus de tests de logiciels existants, Seeker permet aux développeurs de développer efficacement des applications sécurisées.

 

___________________________________________________________________________

 

This post is also available in: Anglais

Learn more about Seeker

More Autres Ressources