• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Rapport hp 2012 sur les cyber risques
 

Rapport hp 2012 sur les cyber risques

on

  • 3,860 views

Découvrez le « Rapport HP 2012 sur les Cyber-Risques ». Ce livre blanc donne un large aperçu des vulnérabilités actuelles et explique comment les maîtriser dans le but de minimiser les risques ...

Découvrez le « Rapport HP 2012 sur les Cyber-Risques ». Ce livre blanc donne un large aperçu des vulnérabilités actuelles et explique comment les maîtriser dans le but de minimiser les risques de sécurité

Statistics

Views

Total Views
3,860
Views on SlideShare
1,326
Embed Views
2,534

Actions

Likes
1
Downloads
56
Comments
0

13 Embeds 2,534

http://business.lesechos.fr 2330
http://albanjarry.wordpress.com 145
http://gestion-management.lesechos.fr 27
http://www-preprod.business.lesechos.fr 10
http://business-refonte.lesechos.fr 7
http://gestion-business.lesechos.fr 4
http://pigeindexeroff 3
http://pigeindexeroff2 2
http://gestion-business.refonte.lesechos.fr 2
http://pigeindexer2 1
http://pigeindexersv2 1
http://pigeindexer 1
http://gestion-preprod.business.lesechos.fr 1
More...

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Rapport hp 2012 sur les cyber risques Rapport hp 2012 sur les cyber risques Document Transcript

    • Livre blancRapportHP 2012sur les cyber-risques
    • Livre blanc | Rapport HP 2012 sur les cyber-risquesTable des matières3 Présentation Les vulnérabilités ou failles dites critiques sont en baisse mais constituent toujoursune menace importante. Les technologies arrivées à maturité posent toujours des risques Les plates-formes mobiles offrent un terrain très propice au développement denouvelles vulnérabilités Les applications Web demeurent une source importante de vulnérabilités Les attaques par scripts intersites restent une menace majeure pour lesorganisations et les utilisateurs La prévention des risques liés aux attaques par script sur plusieurs cadressemble nulle4 Tendances des vulnérabilités La chasse aux vulnérabilités : 19 % de vulnérabilités en plus en 2012 quen 2011 Des marchés qui ne cessent dévoluer et une complexité accrue qui nuit à ladétection et la signalisation des vulnérabilités Les applications Web posent toujours des risques importants pour les entreprises La maturité dune technologie ne définit pas son profil de vulnérabilité9 Vulnérabilités des applications Web Des attaques dévastatrices En-tête X-Frame-Options : échec de lancement17 Sécurité des applications mobiles Fuite de données sensibles sur des canaux non sécurisés Les accès non autorisés concernent quasiment la moitié des applications mobiles Les dix principales vulnérabilités des applications mobiles Recherche en technologie mobile : la communication en champ proche (NFC) pourles applications mobiles de paiement Recommandations21 Conclusions Militarisation des vulnérabilités Vulnérabilités des technologies mobiles Des technologies matures, toujours autant de risques Les applications Web restent vulnérables23 Contributeurs
    • 3PrésentationDans ce rapport HP 2012 sur les cyber-risques, HP Enterprise Security offre un large aperçu desvulnérabilités actuelles, allant des données sectorielles générales jusquà un examen attentif desdifférentes technologies, notamment dans le domaine du Web et des mobiles. Lobjectif de ce rapportest de déterminer des mesures de sécurité exploitables, indispensables aux organismes de collectedinformations pour dresser et maîtriser le panorama des vulnérabilités actuelles, mais également mieuxdéployer leurs ressources afin de minimiser les risques de sécurité.Pour évaluer ces vulnérabilités sous un angle large, le rapport se fonde sur les sources suivantes :• Données de la base de données OSVDB (Open Source Vulnerability Database)1• Données de vulnérabilité du programme Zero Day Initiative (ZDI)2mis en place par HP• Analyse HP DVLabs des vulnérabilités et des données dexploitation malveillante• Données des tests de sécurité statiques et dynamiques HP Fortify on Demand3• Résultats des recherches Web menées par le groupe HP Fortify Software Security Research en matière devulnérabilités• Données de Security Compass (partenaire HP) sur la vulnérabilité des mobilesA partir de ces données, le rapport fait ressortir les principaux constats suivants :Les vulnérabilités ou failles dites critiques sont en baisse maisconstituent toujours une menace importante.Les vulnérabilités les plus graves (note CVSS4entre 8 et 10) qui représentaient 23 % de lensemble desvulnérabilités évaluées et enregistrées dans la base de données OSVDB en 2011 ont connu une baissede 20 % en 2012. Si cette diminution est importante, les données montrent néanmoins que presque unevulnérabilité sur cinq permet toujours à des attaquants de prendre le contrôle total dune cible.Les technologies arrivées à maturité posent toujours des risquesComme le montre lannonce récente du département américain de la Sécurité intérieure qui préconisait dedésactiver la plate-forme Java Standard Edition (SE) dOracle dans tous les navigateurs Web concernés, lestechnologies matures en apparence sont toujours la cible de nouvelles formes dexploitation malveillante.Les données de 2012 montrent notamment que le nombre de vulnérabilités observées dans lessystèmes de contrôle et de collecte de données (SCADA) est passé de 22 en 2008 à 191 en 2012 (soit uneaugmentation de 768 %).Les plates-formes mobiles offrent un terrain très propice audéveloppement de nouvelles vulnérabilitésFace au boom des appareils mobiles et des applications installées dessus, on note une explosionéquivalente du nombre de failles pour les technologies mobiles. Les cinq dernières années affichent unehausse de 787 % du nombre de failles constatées dans le domaine des applications mobiles, haussenotamment due aux nouvelles technologies, comme la communication en champ proche (NFC), quigénèrent des failles de type inédit.Les applications Web demeurent une source importante devulnérabilitésLes données OSVDB recueillies entre 2000 et 2012 montrent que sur les six principaux types devulnérabilité soumis, quatre (linjection SQL, les scripts intersites, la falsification de requête intersites(CSRF) et les inclusions de fichiers à distance) concernent principalement ou exclusivement lesapplications Web.Les attaques par scripts intersites restent une menace majeure pourles organisations et les utilisateursLes scripts intersites (XSS) restent un problème très répandu puisque 44,5 % des applications dansnos jeux de données souffrent toujours de cette faille. Un cas précis, celui de lanalyse dune entreprisemultinationale, montre que presque la moitié (48,32 %) de ses applications Web se sont avéréesvulnérables face à une certaine forme dattaque XSS. De plus, à la lecture des recherches menéesspécifiquement pour les failles de type XSS dans le cadre du programme ZDI, on constate que de nouvellesméthodes dexploitation de cette vulnérabilité sont en permanence décelées.Livre blanc | Rapport HP 2012 sur les cyber-risques1Open Source Vulnerability Database :osvdb.org/2Programme HP Zero Day Initiative :zerodayinitiative.com/3HP Fortify on Demand :fortifymyapp.com4Common Vulnerability Scoring System (CVSS) :first.org/cvss/cvss-guide.html
    • 4La prévention des risques liés aux attaques par script sur plusieurscadres semble nulleLa première vulnérabilité de type XFS découverte, soit la cause racine des attaques de type "clickjacking"(détournement de clic), remonte à plus de dix ans. Depuis, le clickjacking sest banalisé et pourtant, moinsde un pour cent des 100 000 URL testées incluaient loutil de prévention le plus connu, à savoir len-têteX-Frame-Options.Tendances des vulnérabilitésPour comprendre les risques techniques en matière de sécurité, il faut dabord savoir où et comment lesvulnérabilités surviennent au sein dune organisation. Les vulnérabilités peuvent frapper à tous les niveauxde linfrastructure de lorganisation, du matériel jusquau réseau et aux logiciels (les nouveaux commeles anciens). Ces vulnérabilités sont la voie quempruntent des acteurs malveillants pour contourner lesmécanismes de sécurité et dérober ou endommager des données, refuser des accès et compromettre lesprocessus métier stratégiques de lorganisation.En se basant sur les données de la base de données OSVDB (Open Source Vulnerability Database) et duprogramme HP Zero Day Initiative (ZDI), cette section du rapport dégage les tendances globales suivantesen matière de vulnérabilités :• La chasse aux vulnérabilités : 19 % de vulnérabilités en plus en 2012 quen 2011. Le nombre total devulnérabilités relevé offre un aperçu global des vulnérabilités actuelles et dévoile un panorama de cyber-menaces en perpétuelle évolution.• Des marchés qui ne cessent dévoluer et une complexité accrue qui nuit à la détection et lasignalisation des failles. Les données de divulgation des vulnérabilités montrent limpact desévolutions du marché des vulnérabilités et de la complexité technique des systèmes sur le nombre et lagravité des vulnérabilités signalées.• Les applications Web posent encore aujourdhui des risques techniques importants pour lesorganisations. Une petite poignée dapplications Web stratégiques vulnérables représente toujours unelarge minorité des vulnérabilités totales découvertes en 2012.• La maturité dune technologie ne définit pas son profil de vulnérabilité. Les données recueilliesen 2012 montrent une augmentation de plus de 700 % du nombre de vulnérabilités découvertes ayantun impact à la fois sur les systèmes de contrôle et de collecte de données SCADA (principale technologieutilisée) et sur les appareils mobiles (la prochaine étape dans le développement des technologies delinformation).La chasse aux vulnérabilités : 19 % de vulnérabilités en plusen 2012 quen 2011Le nombre total de nouvelles vulnérabilités signalées au cours de lannée 2012 (8 137) montre uneaugmentation denviron 19 % par rapport au nombre enregistré en 2011 (6 844) mais il demeure inférieurà 19 % au nombre record de 2006. Ce réajustement constant du nombre de vulnérabilités signaléesmontrent bien que la guerre que se livrent les organisations et les attaquants fait rage, sans quunvainqueur ne se dégage clairement (voir la Figure 1).Figure 1. Vulnérabilités découvertes et enregistrées dans la base de données OSVDB entre 2000 et 201202 0004 0006 0008 00010 00012 0002000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012NombretotaldevulnérabilitésLivre blanc | Rapport HP 2012 sur les cyber-risques
    • 5Laffichage par année des données OSVDB montre clairement que les vulnérabilités découvertes nontcessé dosciller depuis le niveau record de 2006 et quaucune tendance à la hausse ou à la baisse ne sestdégagée dans les années qui ont suivi. Le nombre total de vulnérabilités apparues au cours dune annéeprécise ne mesure pas nécessairement la sécurité globale du secteur. Il indique plutôt comment leschangements dans la manière de détecter, divulguer et exploiter les vulnérabilités peuvent grandementvarier dune année sur lautre. La section suivante souligne comment ces changements du marché desvulnérabilités expliquent en partie ces variations.Des marchés qui ne cessent dévoluer et une complexité accrue quinuit à la détection et la signalisation des vulnérabilitésMême si le nombre des vulnérabilités signalées reste largement inférieur au niveau record observéen 2006, un examen des facteurs ayant une incidence sur la détection et la divulgation des failles estprimordial. Les informations de vulnérabilité peuvent être distribuées via différents canaux, notammentdes programmes communautaires comme la base de données OSVDB ou le programme HP ZDI, desconsultants privés en sécurité, les programmes Bug Bounty (recherche de vulnérabilités récompensée) desfabricants et le marché noir clandestin.Si la base de données OSVDB offre un excellent aperçu du paysage actuel des vulnérabilités, elle permetseulement de recenser les vulnérabilités qui sont publiquement divulguées ou directement transmises àlorganisation. De plus en plus, les agences de conseil spécialisées en sécurité découvrent et achètent desvulnérabilités qui sont ensuite directement divulguées à leurs groupes privés de clients. Cette pratiqueignore un grand nombre de vulnérabilités qui ne sont pas comptabilisés dans les résultats publics.Un autre élément qui complique le défi que posent les vulnérabilités est la complexité des logiciels actuels.La sécurité est devenue est une priorité croissante et pour lutter contre les attaques incessantes depersonnes malveillantes, les organisations ont doté leurs logiciels de mécanismes de sécurité et ajoutédes fonctionnalités pour contrecarrer les initiatives de découverte et dexploitation non autorisées de leursvulnérabilités. Ces mesures nont pas seulement contribué à combler des lacunes, elles ont égalementcompliqué davantage la détection des vulnérabilités qui demeuraient.Le changement dorientation des marchés publics et privés des vulnérabilités, associé à la complexitécroissante quimplique lidentification des vulnérabilités, a fait grimper la valeur des vulnérabilités àfort potentiel dexploitation (celles avec une note CVSS entre 8 et 10). Cette augmentation amène deuxconclusions :• Les chercheurs en sécurité doivent développer des compétences étendues dans des systèmesspécifiques pour rester efficaces.• Les chercheurs bénéficient dun meilleur retour sur investissement pour les vulnérabilités graves quiatteignent des prix plus élevés.Cependant, avec la hausse théorique du nombre total de vulnérabilités hautement exploitables signaléepar lOSVDB en 2012, le pourcentage du nombre total de vulnérabilités signalées avec une note CVSSélevée a diminué pour passer de 23 % en 2011 à 20 % en 2012 (voir la Figure 2). Notez que lOSVDB nexigepas de note CVSS pour signaler des vulnérabilités. Les vulnérabilités sans note CVSS ont la valeur Zérodans la figure.Figure 2. Panorama de la gravité des vulnérabilités daprès les données de lOSVDB (2000 à 2012)02 0004 0006 0008 00010 00012 0002000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012Zéro 1 2 3 4 5 6 7 8 9 10Livre blanc | Rapport HP 2012 sur les cyber-risques
    • 6Un élément qui contraste avec cette hausse modeste du nombre de vulnérabilités hautement exploitablessignalées en 2012 est la tendance globale des données de lOSVDB puisque ces dernières montrent que lepourcentage pour ce type de vulnérabilité a augmenté de manière considérable et homogène au cours desdix dernières années (voir la Figure 3).Figure 3. Gravité des vulnérabilités OSVDB sur dix ansGravité moyennement élevée (note CVSS 5 à 7) Gravité la plus élevée (note CVSS 8 à 10)Gravité la moins élevée (note CVSS 1 à 4)8 %2002 2007 201217 %75 %14 %22 %64 %20 %36 %44 %Entre 2002 et 2007, les vulnérabilités moyennement graves (note CVSS entre 5 et 7) formaient la majoritédes découvertes. Cette période comporte une hausse importante du nombre total de vulnérabilitésdéclarées à un moment où les outils de test à données aléatoires (fuzzing) devenaient la norme et leschercheurs commençaient à identifier les vulnérabilités les plus répandues et simples à détecter grâceà lautomatisation. Depuis, ce nombre a nettement baissé, notamment grâce aux organisations dedéveloppement qui, par le biais de lautomatisation, ont pu identifier et résoudre ces vulnérabilités avantque les chercheurs ne les trouvent.Par quoi sexplique alors le pourcentage en décrue des vulnérabilités à fort potentiel dexploitation observéen 2012 ? Les données commerciales laissent à penser que, du fait des compétences et du temps requispour dévoiler et démontrer le potentiel dexploitation des vulnérabilités les plus graves, un nombresans cesse croissant de ce type de vulnérabilité est vendu sur des marchés commerciaux privés (gris) ouclandestins (noirs), ce qui les exclut (du moins provisoirement) de tout recensement public comme celui delOSVDB.Les applications Web posent toujours des risques importants pourles entreprisesLa Figure 4 met en évidence les six vulnérabilités les plus répandues signalées dans lOSVDB :dépassement de mémoire tampon, déni de service, inclusion de fichier à distance, injection SQL, scriptsintersites et falsification de requête intersites (CSRF). Toutes sont potentiellement exploitables à distance.Figure 4. Les vulnérabilités les plus courantes dans lOSVDB, présentées par catégories (2000 à 2012)06001 2001 8002 4003 0002000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012Dépassement de mémoire tamponDéni de serviceInclusions de fichiers à distanceInjection SQLScripts intersitesFalsification de requêtes intersitesSur ces six catégories de vulnérabilité, quatre (linjection SQL, les scripts intersites, la falsification derequête intersites (CSRF) et les inclusions de fichiers à distance) ont principalement ou exclusivementun impact sur les applications Web et représentent 40 % du volume total de vulnérabilités découvertesen 2012 selon lOSVDB.Si le nombre de vulnérabilités Web a atteint un niveau record en 2006, il a évolué depuis et de manièresimilaire au nombre global de vulnérabilités (voir la Figure 5).Livre blanc | Rapport HP 2012 sur les cyber-risques
    • 7Figure 5. Vulnérabilités des applications Web et des applications non Web02 0004 0006 0008 00010 00012 0002000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012Vulnérabilités des applications Web Vulnérabilités des applications non WebOn peut en conclure que si les vulnérabilités des applications non connectées au Web représententtoujours la majorité des vulnérabilités divulguées, quelques catégories de vulnérabilités desapplications Web introduisent encore des risques techniques considérables pour les organisations.La maturité dune technologie ne définit pas son profil devulnérabilitéLun des changements majeurs de paradigme technique au cours de la dernière décennie a été ladoptionmassive dappareils mobiles capables dexécuter des applications personnalisées. Au cours des cinqdernières années seulement, les données OSVDB ont affiché une croissance de 787 % du nombre devulnérabilités découvertes dans le cas des technologies mobiles (voir la Figure 6). La dernière année à elleseule montre une augmentation de 68 % avec 158 vulnérabilités découvertes en 2011 et 266 en 2012.Figure 6. Vulnérabilités découvertes pour les technologies mobiles et évaluées par lOSVDB entre2008 et 20120501001502002503002008 2009 2010 2011 2012Par comparaison, les systèmes de contrôle et de collecte de données (SCADA) qui contrôlent les processusindustriels automatisés, notamment dans les domaines de la fabrication, la production délectricité, lesecteur minier et le traitement des eaux, sappuient sur des technologies beaucoup plus abouties. Cessystèmes qui opéraient historiquement sur des réseaux distincts avec des protocoles propriétaires ontensuite entamé une migration vers des réseaux standard et même Internet dans le but de simplifier lagestion des ressources, la facturation et les aspects opérationnels. A mesure que ces systèmes ont quittéleurs réseaux isolés distincts, des problèmes de sécurité autrefois masqués par une surface dattaqueréduite ont commencé à se manifester.Livre blanc | Rapport HP 2012 sur les cyber-risques
    • 8Daprès les données de lOSVDB, 76 vulnérabilités seulement ont été détectées dans les systèmes SCADAentre 2008 et 2010. En revanche, après la découverte en 2010 du ver Stuxnet dans une usinedenrichissement duranium iranienne, lattention sest focalisée sur la sécurité des systèmes SCADA.En 2011, 164 vulnérabilités ont été recensées dans les systèmes SCADA et ce nombre a atteint 191en 2012, soit une augmentation de 768 % par rapport aux chiffres de 2008 (voir la Figure 7).Figure 7. Vulnérabilités des systèmes SCADA découvertes et évaluées par lOSVDB entre 2008 et 20120501001502002502008 2009 2010 2011 2012Programme Zero Day Initiative : coup dœil sur 2012Grâce à la position de leader du ZDI en qualité de programme dacquisition des vulnérabilités, leschercheurs de léquipe ont maintes fois eu loccasion danalyser certaines des vulnérabilités les plusintéressantes et les plus débattues qui sont survenues au cours des douze derniers mois. Les cas dignesdintérêt suivants, observés en 2012, illustrent le croisement des marchés blanc et noir.Au début de lannée 2012, une vulnérabilité des services Bureau à distance Microsoft® (ZDI-12-044, MS12-020 et CVE-2012-0002) a fait lobjet de toutes les attentions :• Le ZDI a signalé cette faille spécifique à Microsoft en août 2011.• Aucune attaque extérieure connue ne fut signalée mais, consciente de son pouvoir dattraction auprèsdes attaquants, la société Microsoft sattendait déjà à des exploitations imminentes pour mars 2012.• Il était possible daccéder à cette faille sur le réseau avant toute authentification requise. Elle semanifestait déjà lors de la gestion des erreurs au moment du chargement des éléments dans un tableau.Un mois plus tard, Samba publia un correctif très attendu fondé sur une faille identifiée par un chercheurdu ZDI (TPTI-12-04, CVE-2012-1182) :• Le ZDI signala cette faille à Samba en septembre 2011.• Aucune attaque extérieure connue ne fut signalée mais la vulnérabilité incriminée comptait parmi lesvulnérabilités les plus graves pour un programme et Samba traita sans attendre le problème.• Cette faille nexigeait aucune connexion authentifiée et aboutissait à une mémoire corrompue quunattaquant pouvait librement exploiter pour exécuter du code à distance.La fin de lannée 2012 fut une période dactivité intense pour les attaques de type zero-day qui touchaautant Oracle (CVE-2012-0422, CVE-2012-3174) que Microsoft (MS13-008, CVE-2012-4792). Le ZDI étaitaux premières loges et signala une vulnérabilité importante de Java liée à une faille zero-day :• Le ZDI signala cette faille Java à Oracle en décembre 2012.• Cette faille était exploitée au grand jour.• Elle permettait à une applet malveillante dexécuter un code fourni par un attaquant et de le faire àdistance dans le contexte de lutilisateur actuel.Ces cas ne sont pas les seuls cas gérés par le ZDI en 2012 mais ils montrent bien le croisement desmarchés noir et blanc dans cette chasse aux vulnérabilités. Une chose est sûre : nos chercheurs sontengagés dans une course contre la montre visant à identifier et divulguer de manière responsable lesvulnérabilités des technologies logicielles les plus répandues.Livre blanc | Rapport HP 2012 sur les cyber-risques
    • 9Vulnérabilités des applications WebPour dresser un tableau plus complet des vulnérabilités actuelles, léquipe HP Fortify on Demandsest réunie et a analysé les résultats de milliers dévaluations pour savoir à quoi ressemble la sécuritédes applications Web de lintérieur. Pour cela, elle a procédé à des examens de code et des tests depénétration. Un examen minutieux des résultats des analyses statiques (recherche de vulnérabilités dansle code source sans exécution de ce dernier) et dynamiques (tests de fonctionnement du logiciel en qualitédattaquant, sans accès au code même) constitue une base solide pour établir un réel état des lieux enmatière de risques pour les applications Web.Les jeux déchantillons utilisés pour cette analyse comprenaient 200 applications choisies au hasard pourlanalyse dynamique et 800 applications pour lanalyse statique. La Figure 8 montre les cinq principalesvulnérabilités découvertes dans le cadre de lanalyse dynamique en 2012.Figure 8. Cinq principales vulnérabilités découvertes lors de lanalyse dynamique en 2012 via HP Fortify onDemand45 %26 % 25 %13 %9 %0 %5 %10 %15 %20 %25 %30 %35 %40 %45 %50 %Scripts intersites ProtectionTransportLayer insuffisanteMauvaiseconfigurationde sécuritéGestion delauthentificationet des sessiondéfaillanteFailles dinjectionLes résultats dynamiques obtenus à partir de ce jeu déchantillons, ainsi que dautres résultats consignésdans ce rapport, montrent que les attaques par script intersite constituent toujours une menaceimportante lors de toute tentative de sécurisation des applications Web. Si lon tient compte de la premièreplace quoccupent les attaques par script intersite parmi les types de vulnérabilité acquis par le ZDI lannéedernière, et de lampleur réelle de ces attaques confirmée par des tests répétés, les organisations peuventà juste titre les considérer comme une préoccupation majeure en matière de sécurité.La Figure 9 décrit le mode opératoire dune attaque par script intersite classique et comment lexploiterpour dérober des informations didentification dauthentification sur des sites stratégiques.Livre blanc | Rapport HP 2012 sur les cyber-risques
    • 10Figure 9. Anatomie dune attaque par script intersite réfléchieSite bancaireUtilisateur créduleAttaquantmalveillant1. Un attaquant découvreune faille XSS dansune application Web..3. Lattaquant distribuele lien XSS malveillantvia dingénierie socialeà des utilisateurs crédules.2. Lattaquant crée une URL dattaquepour voler des informations sensibleset la déguise afin quelle paraisse légitime.4. Lorsque la victime seconnecte, JavaScript, quiest intégré au lien XSSmalveillant, sexécute ettransmet les informationsde connexion de la victimeà lattaquant.La Figure 10 montre les cinq principales vulnérabilités découvertes dans le cadre de lanalyse statiqueen 2012 et inclut le pourcentage relatif dapplications touchées par chaque catégorie de vulnérabilité.Figure 10. Cinq principales vulnérabilités découvertes lors de lanalyse statique en 2012 via HP Fortify onDemand92 % 88 % 86 %75 %61 %0 %10 %20 %30 %40 %50 %60 %70 %80 %90 %100 %Fuites dinformationset gestion deserreurs inappropriéeStockagedes donnéescryptographiquesnon sécuriséFailles dinjection Référencedobjet directenon sécuriséeGestion delauthentification et dessession défaillanteLes résultats de lanalyse statique révèlent que les fuites dinformation, les problèmes de stockage desdonnées cryptographiques et les failles dinjection sont les vulnérabilités les plus fréquentes. Un élémentnon cité dans cette liste des cinq principales vulnérabilités est que, pour 51 % des applications; il étaitquestion dune attaque par script intersite réfléchie (voir la Figure 9 ci-avant). Sil ne figure pas dans la liste,il reste néanmoins un élément important si on lajoute aux autres résultats de ce rapport.Les résultats de ces jeux déchantillons confirment nettement que les applications Web souffrent encoreaujourdhui de nombreuses faiblesses, pourtant jugées critiques par les diverses normes industriellesen vigueur. Les cinq principales catégories de vulnérabilité qui dominent les résultats sont souvent cellesqui exposent les applications Web à des risques importants, notamment le vol dinformations, lescaladede privilèges, etc. Ces deux jeux déchantillons nous amènent à la conclusion que les organisationsne parviennent toujours pas à appliquer des mesures cohérentes pour faire face à des vulnérabilitésomniprésentes comme les scripts intersites et les fuites dinformation.Livre blanc | Rapport HP 2012 sur les cyber-risques
    • 11Un autre élément à retenir est que la vulnérabilité la plus employée par des attaquants en relationavec dautres vulnérabilités connues est la fuite dinformation. Un élément dinformation précis peutsembler sans intérêt mais peut pourtant être le composant clé qui permettra à un attaquant dimposerune technique pour mener une attaque plus dévastatrice encore. En somme, pour préparer et réussirune attaque, des techniques minutieuses de collecte des informations et de reconnaissance sontindispensables.Risques des applications Web : étude de casProfil de la sociétéGrande entreprise multinationale (plus de 100 000 employés) avec un chiffre daffaires de plus de82 milliards de dollars pour lexercice fiscal 2012Cette entreprise dispose dun programme de sécurité actif et opérationnel. Les résultats montrent lesefforts qui sont nécessaires pour gérer entièrement les risques liés à la sécurité des applications. Lesrésultats qui suivent proviennent de plus de 1 300 évaluations dynamiques uniques menées sur les diverssites de lentreprise. Dans lère de la sécurité des applications modernes, une vulnérabilité est souvent unede trop.Résultats :• 54,1 % des évaluations ont révélé des cookies persistants. LAgence européenne chargée de la sécuritédes réseaux et de linformation (ENISA) emploie le terme "cookies doux-amers" pour parler de cescookies. Les cookies persistants augmentent considérablement la probabilité dattaques par relectureen raison de la durée de validité prolongée des cookies. La divulgation dinformations sur des ordinateurspublics "partagés" peut également produire des cookies persistants. Parce que les cookies servent, entreautres, à observer le comportement des utilisateurs, il est probable que les "avantages" potentiels quilsprésentent pour lentreprise aient quelque peu relayé les questions de sécurité au second plan.• Un peu moins de la moitié (48,32 %) des sites étaient vulnérables face à une certaine forme dattaque parscript intersite.• Presque un cinquième (19,57 %) des sites contenaient un formulaire de connexion non crypté à "schémamixte" où les informations dune page HTTP étaient publiées dans une page HTTPS ou inversement.• 12,77 % des évaluations étaient vulnérables à une certaine forme dinjection SQL. Le plus intrigant, cestque 10,97 % des évaluations confirmaient les vulnérabilités dinjection SQL à laveugle. Si lon tient comptedu caractère particulièrement dangereux des injections SQL à laveugle et du fait que ces vulnérabilitéssont souvent employées pour compromettre un système, ce pourcentage pose de graves problèmes.• Un autre cinquième (19,7 %) des sites étaient vulnérables aux connexions transmises via une connexionnon cryptée, ce qui signifie que le formulaire nutilisait pas le protocole SSL.• 5,26 % des sites étaient exposés à une vulnérabilité de lecture/inclusion de fichier local. Sil était jugésensible, le contenu du fichier pouvait être utilisé pour prendre le contrôle du système.Des attaques dévastatricesOutre des statistiques, les organismes chargés de collecter des informations de sécurité ont égalementbesoin dobservations et didées. Dans cette optique, la section qui suit propose une liste sommaire desattaques dévastatrices que les responsables des tests de pénétration chez HP Fortify on Demand ontdécouvertes en 2012. Chaque compte a été découvert moyennant autorisation au cours dopérationsapprouvées menées à lencontre de sites de production, avec des difficultés techniques allant desplus simples aux plus complexes. Le dénominateur commun est que toutes les attaques avaient desconséquences extrêmement graves si elles étaient découvertes par un attaquant malveillant. Pour desraisons évidentes, les noms des clients nont pas été inclus mais les secteurs eux-mêmes sont insérésdans la liste pour illustrer le danger potentiel et la pertinence des attaques. Si ces exemples revêtent uncaractère anecdotique par définition, ils profitent de lexpérience et des avis de nos responsables de testsde pénétration dune manière que les simples statistiques ne permettent pas. Là encore, la sécurité estplus quune affaire de produits. Cest un processus.Attaques par injection et attaques par validation dentrée incorrecteSecteurs dactivité : pétrochimie, industrie alimentaire, énergie et logicielsTéléchargements de fichiers non sécurisés et configuration incorrecte de la sécurité : Un programmeclient lourd permettait à nimporte quel utilisateur de charger (au moyen de sa fonction de chargementintrinsèque) des programmes malveillants sur un serveur Web muni daucune protection contre ce type deprogramme. Environ 30 000 utilisateurs dans le monde entier se servaient de ce programme ; les risquesétaient donc particulièrement grands. Les fonctions de téléchargement de fichiers doivent impérativementfaire preuve de méfiance à légard des types de fichiers acceptables. La Figure 11 décrit les conséquencesde ce scénario.Livre blanc | Rapport HP 2012 sur les cyber-risques
    • 12Figure 11. Lautorisation de téléchargements de fichiers peut avoir des conséquences sévèresTéléchargementsde fichiersnon validésAucuneprotectionpar logicielanti-programmemalveillant30 000utilisateurssont infectés parle logicielmalveillantInjection SQL à laveugle : les fonctionnalités daide à la recherche (une série de cases à cocher conçuespour aider les utilisateurs à restreindre leurs critères de recherche) sans validation dentrée ont abouti àlaffichage de 35 bases de données, dID dutilisateur de système de base de données et de hachages demot de passe, y compris le compte dadministrateur système. Linjection SQL à laveugle peut être difficileà déceler parce quelle génère rarement des messages derreur et manifeste un comportement applicatifanormal. Les requêtes paramétrables, également appelées "instructions préparées", empêchent avecefficacité les attaques par injection SQL si elles ont correctement mises en place.5La Figure 12 décrit cetteséquence.Instructions SQL en texte clair : lors des tests effectués sur une application cliente lourde, il a étédécouvert que le client exécutait des instructions SQL directement sur le serveur SQL principal avec desautorisations de niveau administrateur sur HTTP. Une escalade des privilèges utilisateur et la modificationdes mots de passe furent possibles en soumettant le protocole à une ingénierie à rebours et en lemanipulant (voir la Figure 13).Inclusion de fichier local : des techniques de traversement de répertoires (Directory Traversal) etdinclusion de fichier local ont été employées pour afficher le contenu du fichier SAM (Gestionnaire decomptes de sécurité) de sauvegarde du serveur Web qui permettait de décoder les mots de passe.Au bout de dix minutes, il était possible pour un administrateur local daccéder au système et detout compromettre. Les routines de validation dentrée, quelles soient inhérentes à lapplication ouinterviennent au niveau de configuration du serveur Web, auraient éliminé ce vecteur.Attaques visant à exploiter une mauvaise configuration de sécuritéSecteurs dactivité : pétrochimie et secteur bancaire internationalImpossibilité de restreindre laccès aux répertoires sensibles : dans ce cas, le répertoire découvertétait “https://www.example.com/passwords/”. Naturellement, aucun dossier “passwords”, tout du moinspublic, ne devrait exister. Le dossier était accessible via des navigateurs Web sans aucune authentificationet comprenait une liste de répertoires avec des fichiers texte aux noms divers, tels que “passwords.project” ou même “passwords.systems”. Un simple clic sur un fichier provoquait louverture dun documenttexte muni dune liste dutilisateurs et de mots de passe au format suivant : user:password. Une des listescontenait même “sysadmin:{password} admin:{password} etc…” (voir la Figure 14). Ceci illustre la nécessitéet limportance de la validation danalyse post-automatique puisque cette vulnérabilité qui pose de faiblesrisques en apparence pouvait aisément passer inaperçu aux yeux du client. Qui plus est, le problème auraitpu être évité si laccès au répertoire avait été restreint comme il le fallait.Le protocole WebDAV activé autorisait les opérations décriture à distance : Le mode dactivation duprotocole WebDAV sur un serveur Web en particulier permettait à des utilisateurs dapplications distantsde communiquer avec lhôte et décrire des fichiers dans des répertoires arbitraires. Lexploitation de cettevulnérabilité permettait de télécharger une porte dérobée personnalisée, puis de lexécuter en parcourantle chemin daccès à lURL du fichier récemment transféré. Une fois exécutée, elle offrait la possibilité decontrôler entièrement le serveur Web. En prévoyant de plus amples tests, la personne chargée de cestests pouvait librement poursuivre une attaque contre dautres hôtes sur le réseau interne de lentreprise,processus appelé "glissement" (pivoting). La suppression de laccès WebDAV et de méthodes HTTPextérieures aurait pu éviter cette attaque.Injection SQL et commandes de validation dentrée faibles : Un filtre SQL filtrait tout, à lexceptionde lopérateur “OR”. Cela signifie essentiellement quaprès insertion de lopérateur “OR” dans uneinstruction SQL, chaque commande serait exécutée sur le système. Le paramétrage des requêtesempêchera les attaques par injection SQL. La Figure 15 décrit le déroulement séquentiel dune attaque parinjection SQL.Livre blanc | Rapport HP 2012 sur les cyber-risques5 https://www.owasp.org/index.php/SQL_Injection_Prevention_Cheat_SheetFigure 12. Injection SQL à laveugleInjection SQLà laveugleVoldinformationsutilisateurAccès àladministrationsystèmeFigure 13. Instructions SQL en texte clairProtocoledingénierie client/serveur à reboursExécution SQLRéinitialisation dumot de passe avecdes privilègesplus élevésFigure 14. Restriction daccès impossibleAccès au répertoire non restreintpasswrds.projectuser:password sysadmin:{mot de passe}passwords.systems {fichier}https://www.example.com/passwords/ {répertoire}
    • 13Figure 15. Anatomie dune attaque par injection SQLSite bancaireBase de donnéesde la banque1=1 ?Attaquant malveillant1. Lattaquant envoie desinformations supplémentairestelles quun guillemet ou"1=1" avec des informationsde connexion ou inclure desvariablespour modifierlinstruction SQL originale.3. Une fois que le schéma de basede données a été défini, lattaquantpeut extraire les données contenuesdans la base de données, notammentles noms dutilisateur, les mots de passes,les informations de carte de crédit, etc.2. Avec lapproche paressais et erreurs,lattaquant peut construiredes arguments SQL pouvantêtre utilisés pour récupérerdes données telles que desnoms de tableaux ou desnoms delignes, etc.Mauvaise configuration SAP : Lintégralité de la base de données des cartes de crédit était accessibleet était transférée dans un fichier. Les commandes configurées dans la structure SAP mise en placeétaient de qualité médiocre et permettaient à des représentants du service clientèle dexécuter destransactions à caractère sensible, y compris le navigateur de données HR (SE16). Cette fonction étaitexploitée pour parcourir et charger le contenu tout entier de la table des données des cartes de crédit desclients. Accessibles de cette manière, toutes les données pouvaient aisément être exportées à laide decomptes SAP avec des privilèges moindres.Attaques par authentification, par session, logique et autres attaquesSecteurs dactivité : compagnies aériennes, secteur bancaire international et énergieListe de billets davion via des services Web de création de codes QR mobiles : Les testeurs étaientcapables de reconstituer à rebours une partie de la fonction des services Web pour créer des numérosde billets. De faux codes QR de billets davion étaient ainsi générés pour des vols aériens. Il est tout estfait possible que lexploitation de cette fonction ait permis aux attaquants de voler gratuitement. Enlabsence de contrôles préventifs efficaces, ils pouvaient senregistrer librement par le biais de leursappareils mobiles. Le recours à une fonction de contrôle aléatoire standard des numéros de billets auraitpu également éviter ce problème.Figure 16. Création de mots de passe dynamiques à cryptage facilement réversibleAttaqueSQLServicedauthen-tificationWebCapturedu trafic chiffréDésactivationdu chiffrementdu mot depasseRandomisationdes mots depasseinsuffisanteAccèsadministrateurà la basede donnéesDésactivation du chiffrement -mot de passe devinableAccès complet à labase de données avec desautorisations dadministrateurLivre blanc | Rapport HP 2012 sur les cyber-risques
    • 14Création de mots de passe dynamiques à cryptage facilement réversible : lapplication cliente lourdetestée communiquait avec un service Web qui se chargeait dabord dauthentifier lutilisateur qui tentait dese connecter. Ensuite, lapplication demandait le mot de passe au serveur de base de données principal.Au départ, le mot de passe était crypté pour la transmission mais, simultanément lors dune autreattaque SQL, un indicateur de la base de données a été renversé, désactivant et annulant ainsi les effetsdu cryptage. Il sest avéré que le système mettait en place des mots de passe dynamiques qui changeaientfréquemment ; cependant, après regroupement des nombreux mots de passe, un schéma évident estapparu. Le mot de passe suivait une chronologie et était donc facile à deviner. Un accès direct à la base dedonnées avec des autorisations administratives fut confirmé et compromit entièrement le système (voir laFigure 16).Le service Web autorisait des requêtes SQL directes : une application autorisait des connexions à sabase de données principale via un interpréteur Web accessible sur Internet sans authentification. Avec desconnaissances limitées en SQL, un attaquant pouvait aisément extraire toutes les données enregistréesdans la base de données cliente, y compris les détails complets des comptes des utilisateurs : nomsdutilisateurs, mots de passe, adresses de messagerie et autres informations didentification personnelle.En partageant les résultats de ces tests de pénétration en conditions réelles, notre but est dattirerlattention sur la créativité sans bornes et la détermination sans fin des attaquants malveillants. Lestesteurs de pénétration cherchent à reproduire ces techniques pour tenter dévaluer avec efficacité chaquecommande de sécurité et sassurer que les données sensibles et les fonctions applicatives sont protégées.Comme le prouvent ces résultats, les tests de sécurité automatisés seuls ne mesurent pas intégralementla politique globale dun environnement en matière de sécurité et doivent être complétés par une analysemanuelle.Dans la section suivante, les chercheurs HP en sécurité de logiciels cherchent à mettre à jour unevulnérabilité cruciale souvent utilisée conjointement avec les nombreuses attaques et techniquesmentionnées plus haut et pour lesquelles une stratégie de prévention efficace reste globalement à mettreen place.En-tête X-Frame-Options : échec de lancementPour illustrer la nature toujours changeante de la sécurité des applications Web, les spécialistes du groupeHP Software Security Research ont examiné une vulnérabilité déjà reconnue et officiellement appelé "scriptsur plusieurs cadres" ou XFS. XFS est un outil indispensable pour tout attaquant qui tente délaborer uneattaque de hameçonnage (phishing) ou dingénierie sociale dans le but de charger un site Web vulnérabledans une balise iFrame HTML sur une page malveillante contrôlée par un attaquant. Ce dernier peut alorsextraire des événements (des séquences de touches, par exemple) appelés par un utilisateur quelconquesur le site Web ciblé.Les vulnérabilités XFS ouvrent également la voie aux attaques de type "clickjacking"6qui trompent lesutilisateurs en les incitant à cliquer sur des éléments précis sur le site Web ciblé chargé à lintérieur dunebalise iFrame invisible. Souvent, ces résultats aboutissent sur des actions non voulues, voire privilégiées.Depuis des années, les chercheurs mettent en garde contre linefficacité des protections par code "frame-busting" basé sur des scripts dans la prévention des menaces du XFS. Pourtant, les développeurs et lesadministrateurs de serveur qui les assistent ont toujours uniquement recours au mécanisme JavaScript(Figure 17) pour détecter des attaques XFS.Les diverses méthodes de prévention contre XFS se sont maintes fois montrées incomplètes ouinefficaces. Le plus répandu de ces modes de prévention est la logique de frame-busting (destruction) deJavaScript ou plus précisément un script côté client qui ressemble à celui présenté dans la Figure 17.5Figure 17. Logique classique de frame-busting JavaScript<script>if (top!=self) top.location.href = self.location.href;</script>Livre blanc | Rapport HP 2012 sur les cyber-risques6 cvedetails.com/cve/CVE-2002-1217/
    • 15Outre les nombreuses variantes de cette technique quil est facile de dénicher en ligne, des contre-mesures datténuation ont également été mises en place pour lutter aussi contre ces variantes, avec desrègles grosso modo équivalentes à celles du jeu de la taupe.Comme le montre la Figure 18, la première vulnérabilité XFS documentée a été découverte il y a plus de10 ans.7Depuis, le clickjacking est devenu une vulnérabilité répandue et, malgré cela, moins de un pourcent de nos échantillons incluait loutil de prévention le plus connu, à savoir len-tête X-Frame-Options.Figure 18. Bref historique des événements majeurs liés à la détection de failles de type XFS (script surplusieurs cadres)29/06/2002Bug iFrame Jesse Rudermana28/10/2002Premier CVE XFS connub16/11/2005Echec des techniquesde Framec21/05/2008Première mention publique de lattribut iFrame "sandbox"d12/09/2008Le terme "clickjacking" est inventée26/01/2009Premier navigateur prenanten charge des options X-Framef17/06/2010Busting Frame Busting:a Study of ClickjackingVulnerabilities on Popular Sitesg27/01/2012Facebook poursuit uneentreprise de "clickjacking"h11/07/2012Dernier conseilXFS connui2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013ahttps://bugzilla.mozilla.org/show_bug.cgi?id=154957bhttp://www.cvedetails.com/cve/CVE-2002-1217/chttp://crypto.stanford.edu/framebust/dhttp://html5.org/tools/web-apps-tracker?from=1642&to=1643ehttp://www.sectheory.com/clickjacking.htmfhttp://blogs.msdn.com/b/ie/archive/2009/01/26/internet-explorer-8-release-candidate-now-available.aspxghttp://cdn.ly.tl/publications/busting-frame-busting-a-study-of-clickjacking-vulnerabilities-on-popular-sites.pdfhhttp://www.guardian.co.uk/technology/2012/jan/27/facebook-sues-clickjacking-firm-adscendihttp://osvdb.org/show/osvdb/83762Lhistoire du XFS (Cross-Frame Scripting ou scripts sur plusieurs cadres) remonte à la publication dunrapport relativement banal sur un comportement observé par Jesse Ruderman en 20028et devenuaujourdhui un élément moteur dun autre phénomène communément appelé "clickjacking". Un élément cléde la régression identifiée en matière de sécurité était la décision dajouter lattribut sandbox à lébauche dela spécification HTML5 pour la balise iFrame au milieu de lannée 2008.Les chercheurs ont démontré que plusieurs contre-mesures datténuation étaient possibles avec des bugsdes navigateurs ou des astuces JavaScript. Le dernier élément ajouté à cette liste, comme le montre laFigure 19, est lutilisation dune fonction de sécurité introduite dans la spécification HTML5 sous la formedun attribut sandbox iFrame que les attaquants peuvent exploiter pour désactiver les protections deframe-busting de JavaScript.Figure 19. Attribut sandbox iFrame<iframe sandbox=”allow-scripts” src=”http://example.com/”></iframe>Lobjet de lattribut sandbox est daccorder lautorisation dexécuter des scripts (allow-scripts) dans lecontenu ciblé. A titre accessoire, toutes les logiques de frame-busting employées par example.comsont effectivement désactivées en lui refusant lautorisation allow-top-navigation dans sa spécificationsandbox.Grâce à lattribut sandbox, cette technique permet à un attaquant de déjouer de manière efficace toutesles tentatives de frame-busting que mènent les développeurs pour se protéger de tout encadrement desite et toute opération de clickjacking par des tiers. Les éditeurs de navigateurs ont introduit et validéune technique de prévention basée sur des stratégies bien plus forte grâce à len-tête X-Frame-Options.Les développeurs peuvent se servir de cet en-tête pour dicter au navigateur les actions adéquatesà entreprendre si leur site est inclus dans un iFrame. Malheureusement, ladoption de cette fonctionparmi les développeurs est très lente et offre aux attaquants un vaste terrain de sites potentiellementexploitables à mesure quils découvrent de nouvelles techniques pour contourner les scripts de frame-busting. Ceci rend plus indispensable encore ladoption et la mise en œuvre de len-tête X-Frame-Optionspuisque ce dernier constitue la solution de facto à ce problème et reste en vigueur même lorsque lenouvel attribut sandbox HTML5 est utilisé. Voilà donc ce qui motive notre projet de recherche et ce qui està lorigine de notre question de départ : "Combien de domaines incluent des en-têtes X-Frame-Options etcombien le font correctement ?"Livre blanc | Rapport HP 2012 sur les cyber-risques7 cvedetails.com/cve/CVE-2002-1217/8 https://bugzilla.mozilla.org/show_bug.cgi?id=154957
    • 16Collection de jeux déchantillonsDans le cadre de cette étude, le groupe HP Fortify Software Security Research a mené des recherches pourévaluer à quel point les faibles pratiques de prévention des attaques XFS restent aujourdhui adoptées etfont autorité. Nos résultats soulignent également la réticence et le rythme dadoption très lent dautresméthodes plus sécurisées recommandées par des spécialistes des navigateurs et des experts en sécurité.Alexa9fut utilisé pour renseigner une collection de 100 000 sites Web (les plus connus) et générer une listedistribuée dans de nombreux secteurs différents. Une fois la liste de départ créée avec ses 100 000 URL,les demandes de niveau supérieur furent assemblées en concaténant “http://” dans lURL obtenue. Parexemple :“http://” + exemple.com = http://exemple.comEnsuite, la nouvelle URL composée fut demandée et la réponse obtenue examinée de manière passive à larecherche des éléments suivants :• La présence dun en-tête X-Frame-Options et de ses valeurs respectives.• La présence dun champ de mot de passe dans la réponse de la demande de niveau supérieur. Un champde mot de passe est censé indiquer un niveau de sensibilité qui doit être protégé par lapplication.• Si la présence de len-tête nétait pas respectée, lURL cible était soumise à des tests supplémentairesafin de distinguer si une tentative de déjouer les attaques XFS avait eu lieu. Le recours à la prévention desrisques liés à JavaScript et aux feuilles de style en cascade a été enregistré pour une analyse ultérieure.Résultats90 % des échantillons analysés nont jamais rien tenté pour se protéger des attaques XFS. De tous lesdomaines dotés dune protection active contre les attaques XFS, 62 % ont recours à des mécanismes deprévention faibles fondés sur les scripts. Sur les 100 000 domaines testés, 19 848 disposaient de champsde mot de passe dans la demande de niveau supérieur, avec seulement 101 domaines précisant un en-têteX-Frame-Options. Cela signifie que 0,1 % des échantillons sont protégés. De plus, plus de 99 % deséchantillons oubliaient de spécifier un en-tête X-Frame-Options, tandis que 19 % dentre eux avaient uneraison dinclure len-tête mais ne lont pas fait.Les résultats montrent que soit les développeurs ne sont pas suffisamment informés des risques queposent les vulnérabilités XFS, soit ils ne souhaitent consacrer aucun effort à la protection de leurs visiteurs.Si 2 307 échantillons dévoilaient des protections contre les attaques XFS, seulement 38 % ont opté pourlutilisation de len-tête X-Frame-Options préconisé. 1 432 échantillons ont montré quils employaienttoujours des techniques de prévention et datténuation fondées sur JavaScript ou les feuilles de style encascade qui se sont avérées insuffisantes (voir la Figure 20).Les 875 domaines fondés sur len-tête X-Frame-Options affichaient la distribution de valeurs suivante :1. 702 des 875 domaines spécifiés avec un en-tête X-Frame-Options avaient la valeur "SAMEORIGIN".2. 151 des 875 domaines spécifiés avec un en-tête X-Frame-Options avaient la valeur "DENY".3. 13 des 875 domaines étaient définis avec lattribut "Allow-from".4. 8 des 875 valeurs fournies étaient conformes à lébauche de lIETF10.Aucun des 13 domaines utilisant lattribut Allow-from ne précisait un caractère générique (*) réduisant lesrisques liés à une politique de libre accès. La Figure 21 présente ces valeurs sous forme de pourcentages.Livre blanc | Rapport HP 2012 sur les cyber-risques9 https://bugzilla.mozilla.org/show_bug.cgi?id=15495710 http://tools.ietf.org/html/draft-ietf-websec-x-frame-options-01Figure 20. Prévention des risques liés aux scriptssur plusieurs cadresPrévention desrisques liés àJavaScript et auxfeuilles de styleen cascade62 %Prévention des risques liés àJavaScript et aux feuilles de styleen cascadeOptions X-Frame38 %Options X-FrameFigure 21. Répartition des valeurs den-têteX-Frame-Options fourniesREFUS17 % Allow-from2 %Autres(valeurs nonen conformité)1 %MÊME ORIGINE80 %
    • 17Encadrement intersites : conclusionIl est évident que toutes les ressources nont pas besoin dêtre protégées contre les attaques XFS.Cependant, il demeure des situations où la mise en place dune protection adéquate est justifiée etindispensable. Une mesure employée pour identifier ces cas au cours de cette étude était la présence dunchamp de saisie de mot de passe dans un formulaire. Les pages dauthentification sont les plus exposées àune attaque de type clickjacking. En se focalisant sur les pages munies de champs pour la saisie des motsde passe, lanalyse tente détablir un lien entre la sensibilité dune ressource et les efforts investis pour laprotéger. Une des statistiques les plus surprenantes dans lanalyse est que seulement 103 des 100 000domaines protégeaient comme il se doit les pages avec des champs de mots de passe confidentiels, soitun taux exorbitant de 0,10 % qui suggère que la puissance et lefficacité de len-tête ont fait lobjet dunemauvaise promotion, nont pas obtenu ladhésion des administrateurs des serveurs ou nont pas séduit lesdéveloppeurs.Il convient de souligner que si un peu plus de 80 % des réponses ne contenaient aucun champ de mot depasse, cela ne veut pas dire pour autant quil ne faut pas protéger le contenu. Autrement dit, léchantillonnincluait aucun champ de mot de passe dans la demande de niveau supérieur. Il est donc très probableque beaucoup dautres sites sexposent à des risques en avançant plus loin dans larborescence du site. Lamesure la plus importante à noter est le pourcentage remarquable de sites sans en-tête X-Frame-Options,soit 99 % !Après une analyse approfondie des résultats des recherches spécialisées consacrées aux attaques XFS,la section qui suit se concentre à nouveau sur ce qui semble être le sujet de conversation le plus populaireen 2012 en matière de sécurité : la sécurité des applications mobiles.Sécurité des applications mobilesDix secondes dans une file dattente nimporte où suffisent pour se rendre compte que lutilisationdappareils mobiles a littéralement explosé. En fait, pour la première fois, 2012 est lannée pendantlaquelle le nombre de smartphones vendus a dépassé le nombre dordinateurs portables et dordinateursde bureau à la fois.11Cette augmentation a été suivie aussi dune hausse proportionnelle des risques,surtout au moment où les entreprises essaient de mettre à profit les avantages quoffre la mobilité.Comme nous lavons vu plus haut, lOSVDB a signalé une hausse de 68 % du nombre de vulnérabilitéssignalées pour les technologies mobiles depuis 2011, soit une augmentation de 787 % sur les cinqdernières années. Lors de nos tests, nous sommes toujours revenus au même constat. Si vous possédezdes données, des attaquants chercheront à sen emparer.Pour évaluer létat actuel de la sécurité des applications mobiles, léquipe HP Fortify on Demand arassemblé les résultats de plus de 70 applications mobiles à la recherche de failles de sécurité. Ce jeudéchantillons concernait plus de 50 organisations uniques et de nombreux secteurs au niveau localet international. Il peut donc être considéré comme une représentation relativement précise duneapplication mobile moyenne. Les résultats montrent que les vulnérabilités qui compromettent lasécurité des applications mobiles sont les mêmes que pour les applications classiques. Ils montrentégalement quun problème surtout se distingue des autres. Dans le paysage informatique actuel, la fuitedinformation est un problème particulièrement répandu et néfaste. La demande croissante dinformationsdes travailleurs mobiles, alliée aux services de cloud de plus en plus omniprésents et à une haussedes appareils grand public non gérés sur le réseau dentreprise, représente un défi notable pour denombreuses organisations.Fuite de données sensibles sur des canaux non sécurisésLa fuite de données est un problème de longue date pour les applications Web. Si elle peut paraître unproblème dampleur modérée, elle implique souvent une information en apparence inoffensive qui permetà un attaquant de renforcer sa stratégie dattaque pour mener une attaque plus dangereuse encore. Lamême chose vaut pour les applications mobiles. Plus des trois quarts (77 %) des applications mobilesdans notre étude étaient vulnérables et en proie à des fuites dinformations. Nous avons découvertque les données personnelles dun utilisateur étaient souvent transmises via des protocoles réseaunon cryptés, comme le protocole HTTP. Il sagissait pour la plupart dinformations simples, comme desnoms, des adresses et des numéros de téléphone. Cependant, dans notre jeu déchantillons, ces donnéescomprenaient également lemplacement actuel de lutilisateur, ainsi que lidentifiant unique de lappareil(également appelé "UDID").Livre blanc | Rapport HP 2012 sur les cyber-risques11 voices.washingtonpost.com/posttech/2010/11/smartphone_sales_to_pass_compu.html
    • 18LUDID est primordial pour un appareil car il peut servir à des attaques extrêmement ciblées contre desutilisateurs en particulier. Si les données de géolocalisation, lidentifiant unique de lappareil et les donnéespersonnelles étaient interceptées sur une application vulnérable, ce que cela implique dans la réalité estétonnant. Un attaquant pourrait localiser une cible dans le monde réel et les possibilités qui souvriraientalors à lui seraient illimitées. Cest la porte ouverte à un scénario effroyable que la plupart des gens nesoupçonnent pas. Bien entendu, lexploitation dapplications simples et banales peut également avoir lieu.Imaginez le scénario suivant : Si lapplication transmet lUDID, le nom complet, ladresse et ainsi de suite,à un service Web vulnérable et que ce dernier est la cible potentielle dune attaque par injection SQL, onconçoit aisément que chaque bit de données sur cet appareil mobile soit accessible. Il est étonnant de voirjusquoù une fuite dinformation peut mener un attaquant si les circonstances jouent en sa faveur, et quetout alors est du domaine du probable, voire du possible.Les données transmises sur des canaux non sécurisés ne se limitaient pas aux données personnelles.Les données applicatives, elles non plus, nétaient pas protégées. Nous avons découvert que desinformations de connexion, des informations didentification utilisateur, des ID de session, des jetons etdes données dentreprise sensibles étaient transmises via des protocoles réseau non cryptés, à linstar duprotocole HTTP. Imaginez les conséquences pour une application bancaire vulnérable. Si des informationsdidentification, des identificateurs de session, des informations didentification personnelle ou dautresdonnées stratégiques sont transmises vers un serveur principal, la transmission se doit dêtre sécurisée,sans quoi les données peuvent être interceptées par un attaquant au moyen doutils ou dapplications decapture de paquets réseau courants (par exemple, DroidSheep).Les recherches ont montré que 37,5 % des applications pouvaient être la cible dune vulnérabilitéimpliquant une forme quelconque dautorisation, notamment des mots de passe en texte clair, des motsde passe codés en dur et des mots de passe intégrés à la réponse. Ce pourcentage bien plus élevé quepour les applications dites traditionnelles prouve également que les développeurs dapplications mobilesdoivent travailler davantage pour protéger leurs données.Dautres vulnérabilités détectées en nombres importants incluaient les attaques de type "stack-smashing".Plus de la moitié des vulnérabilités (55,45 %) noffraient aucune protection adéquate contre ce typedattaque. Si cet oubli nentraîne pas lexécution du code, il peut quand même générer une panne injustifiéede lapplication vulnérable.Qui plus est, 13,5 % des applications étaient vulnérables à des attaques XSS. Ceci fut une réelle surprisepuisque tous les autres ensembles dapplications que nous avons testés, mobiles et traditionnels,révélaient des nombres de vulnérabilités XSS plus élevés. Un examen plus attentif de ces nombres amontré que les applications vulnérables étaient des applications destinées autant à la gestion de la financeque des bases de données. En dautres termes, le faible pourcentage ne réduisait pas limpact potentiel.Les accès non autorisés concernent quasiment la moitié desapplications mobilesNous avons cherché dautres données en examinant les résultats obtenus par notre partenaireSecurity Compass lors de ses tests sur dautres applications. A de nombreux égards, ils confirment leschiffres évoqués précédemment.48 % des applications étaient la proie de vulnérabilités daccès non autorisé. Elles valident lesvulnérabilités dauthentification (37,5 %) que nous avons évoquées dans notre échantillon plus haut.Les chiffres montrent que les développeurs dapplications mobiles doivent autant se concentrer sur laprévention des accès non autorisés sur les applications mobiles que sur les moyens de faciliter laccès pourles utilisateurs légitimes.37 % des applications posaient des problèmes de divulgation dinformations sensibles, 26 % avaientrecours à des pratiques de connexion médiocres et 19 % affichaient des messages derreur de mauvaisequalité qui révélaient des informations susceptibles dêtre exploitées par des attaquants. Ceci corroborenos données précédentes car nous avons vu à quel point les fuites dinformations étaient importantes.Lors du codage des applications mobiles, les développeurs ne tiennent pas compte de ce quimplique lasécurité pour le stockage, la transmission et laccès des données.33 % des applications étaient vulnérables à des attaques XSS. Des tests répétitifs montrent que lesattaques par script intersite (XSS) sont autant une menace pour les applications mobiles que pour lesapplications "stationnaires". Ces résultats sont en phase avec ce que nous avons constaté lors des testsdes applications traditionnelles.Livre blanc | Rapport HP 2012 sur les cyber-risques
    • 1926 % des applications employaient une méthode de cryptage inadaptée. Le cryptage sur des ordinateursdentreprise est aujourdhui une pratique standard pour la plupart des entreprises du classementFortune 500. Il y a dix ans, la presse regorgeait dhistoires de données dérobées sur des ordinateursperdus. Les risques dans ce domaine se sont réduits, dune part grâce aux mesures législatives mises enplaces et dautre part parce que les entreprises ont eu loccasion de lapprendre à leurs dépens. Pourtant,ces mêmes pratiques standard ne sont pas appliquées aux appareils mobiles et, à lère du BYOD (Bringyour own device), cela peut savérer dangereux.Les dix principales vulnérabilités des applications mobilesLe partenaire dHP, Security Compass, a également analysé les vulnérabilités des applications mobileset les a étiquetées par type (voir la Figure 22). Ainsi donc, à quoi les applications moyennes sont-elles leplus vulnérables, par ordre de prévalence des vulnérabilités ? A quels types dattaques, par incident, lesapplications mobiles sont-elles le plus vulnérables ?Sur les dix principales vulnérabilités constatées en matière dapplications mobiles, XSS affichait ledeuxième taux le plus élevé et représentait 15 % de toutes les vulnérabilités découvertes dans cejeu déchantillons. Les chiffres confirment également que lorsquelles sont consignées par ordredoccurrence, les vulnérabilités de fuite dinformation et daccès non autorisé/authentification indiquentaux développeurs dapplications mobiles comment ils peuvent mieux sécuriser leurs applications enconcentrant davantage leurs efforts sur ces domaines.Recherche en technologie mobile : la communication en champproche (NFC) pour les applications mobiles de paiementNous avons constaté que les vulnérabilités liées aux applications mobiles étaient en hausse constantemais il est indispensable également danticiper et de connaître les nouvelles vulnérabilités qui verront lejour. Les nouvelles technologies introduisent en permanence des failles de sécurité possibles. La plate-forme mobile ne fait pas exception. Lune de ces nouvelles technologies est la communication en champproche (NFC). La communication en champ proche (NFC) désigne une méthode de communication dedonnées sans contact entre des appareils proches les uns des autres. Elle a déjà été adoptée en Europeet en Asie et fait depuis peu des adeptes en Amérique du Nord. Le Forum NFC (consortium regroupantplusieurs membres tels que Sony, Nokia et Philips) applique des normes strictes pour les fabricantsdappareils compatibles NFC. Les éditeurs dapplications disposent ainsi dune architecture sécurisée etdune infrastructure compatible qui leur permettent dexploiter cette technologie pour des applications depaiement mobiles et le partage de données (par exemple, léchange de devises entre homologues).Il existe actuellement plusieurs smartphones compatibles NFC. Cest le cas du Google™ Nexus 5, duSamsung Galaxy S II et des BlackBerry Bold 9900 et 9930. Plusieurs sociétés exploitent aujourdhui cettetechnologie :• Google Wallet : conteneur sécurisé pour les informations de carte de crédit qui facilite lestransactions NFC.• MasterCard PayPass : service de paiement sans contact (actuellement pris en charge dans Google Wallet).• Visa payWave : service de paiement sans contact.• PayPal : méthode "bump" (application Bump) pour le transfert dargent ou la réalisation de paiementsentre utilisateurs.• Apple iPhone : prise en charge de la NFC attendue dans une prochaine version (non confirmée)12.Problèmes de sécuritéPlusieurs scénarios dattaque sont à envisager lorsque des données confidentielles (données de cartede crédit ou numéros de comptes) sont transmises via un canal NFC sur un appareil mobile. Voici desexemples de cas réels constatés récemment dans le domaine de la sécurité :Cas 1La technologie NFC est employée dans le cadre de solutions de paiement grand public, avec deux modesde mise en œuvre distincts :• Puce NFC dans des cartes de crédit grand public, telles que MasterCard PayPass et Visa payWave.• NFC utilisée dans des solutions de portefeuille mobile.Livre blanc | Rapport HP 2012 sur les cyber-risques12 Il existe actuellement des éditeurs, à linstar deDeviceFidelity, qui proposent des composantstiers qui reproduisent la prise en charge de lacommunication en champ proche (NFC) pour lesappareils iPhone.Figure 22. Prévalence des dix principalesvulnérabilités (en pourcentage)Accès nonautorisé18 %Scriptsintersites15 %Divulgationdinformationssensibles12 %Traitementnon sécurisédes sessions11 %Vulnérabilitésdu traitementdes cookies9 %Méthodede cryptageinadaptée9 %Pratiquesde connexionmédiocres8 %Saisie semi-automatiquesur des formulairesà données sensibles6 %Informationsdidentificationen texte clair6 %Messages derreurde mauvaise qualité6 %
    • 20Le défi du premier mode de mise en œuvre est double : le premier est que, pour la plupart des émetteursde cartes de crédit, linstallation de la puce NFC est obligatoire ; le deuxième est que, par définition, lapuce NFC est toujours activée. Par exemple, si la carte de crédit dun utilisateur est dans le champ dunlecteur NFS actif, comme celui que lon rencontre dans un terminal de point de vente, la carte de crédittransmet automatiquement le numéro de carte de crédit de lutilisateur au lecteur NFS de réception.A présent, imaginez le scénario pour les appareils mobiles les plus modernes équipés de puces NFSintégrées. Dans le monde dAndroid, il existe des applications conçues pour activer la puce NFC de lappareilmobile pour reproduire le comportement du lecteur NFS dun terminal de point de vente. A laide dunappareil mobile ou dune application de ce genre, un attaquant peut potentiellement activer la puce NFCde son appareil Android, croiser des gens dans un endroit peuplé et tenter danalyser leurs cartes de créditpour recueillir leur numéro de compte permanent (PAN).Les solutions de portefeuille mobile NFC sont souvent vulnérables à ce même type dattaque si la solutionconcernée ne désactive pas ou ne retire pas la puce NFC une fois lexécution dune transaction terminée.Heureusement, cette vulnérabilité peut facilement être résolue par des développeurs de solutions deportefeuille mobile sils retirent la puce NFC après usage.Cas 2Plusieurs scénarios dattaque sont à envisager lorsque des données confidentielles (par exemple, desdonnées de carte de crédit ou des numéros de comptes) sont transmises via un canal NFC.• Ecoute : tentative dintercepter la communication des données de transmission NFC (par exemple,proxy NFC).• Manipulation des données : tentative de manipuler la communication des données de transmission NFC(par exemple, pour identifier des résultats erronés).• Attaques par interception : tentative dexploitation des modes actif/passif de lappareil pour envoyer etrecevoir la communication des données de transmission NFC.• Vol : tentative daccéder sans autorisation à lapplication de paiement mobile (comme si lappareil a étévolé ou perdu) et examen des fichiers stockés sur lappareil à la recherche dinformations sensibles.Cas 3Au cœur même de la fonction NFC se trouve un composant appelé élément sécurisé. Deux types de miseen œuvre de cet élément sont possibles : (1) les éléments incorporés dans lappareil et (2) les élémentschargés dans une carte SIM. Dans les cas où lélément sécurisé est chargé dans une carte SIM, il estpossible que la carte SIM soit retirée et échangée sous les yeux dun utilisateur crédule. Cette situationaboutit à des scénarios dattaque semblables aux suivants :• Echange de carte SIM avec un autre appareil (du même type) pour tenter daccéder au contenu delélément sécurisé. Dans certains cas, lutilisation dun appareil de type différent peut offrir un accèssupplémentaire aux informations de lélément sécurisé sil nest pas mis en œuvre de manière sécurisée.Par exemple, il existe un risque de contournement de lapplication de paiement, ou de la protection dumot de passe au niveau du téléphone, en cas déchange de carte SIM dans un téléphone équivalent aveclapplication de paiement et sans mot de passe.• Identification des données contenant des informations sensibles dans lélément sécurisé situé dans lacarte SIM après une opération de restauration sur un autre appareil. Il peut sagir aussi dattaques visant àcloner ou copier la carte SIM au moyen dun matériel externe.Notez que la difficulté daccès à lélément sécurisé offre une certaine garantie sur lenvironnement desécurité de lélément sécurisé sur lappareil cible.Cas 4Dans certains cas, il est possible que limplémentation de lapplet VMPA dans lélément sécurisé naitpas tenu compte de tous les éléments de sécurité. Il peut sagir, par exemple, dune signature et duncontrôle daccès insuffisants de lapplet VMPA qui permettent à une application quelconque de démarreret dy soumettre des requêtes. Cette situation peut offrir à une application non autorisée la possibilitédappeler lapplet VMPA via la commande APDU (JSR 177). Une requête bien formulée peut potentiellementpermettre dactiver la radio NFC et de transmettre des informations de carte de crédit.Livre blanc | Rapport HP 2012 sur les cyber-risques
    • 21Bien que des informations et une analyse exactes peuvent être obtenues à partir dun appareildinvestigation (si un accès à ce type de matériel est disponible), il nexiste pour lheure aucun outilautorisant laccès à des informations de lélément sécurisé. Lélément sécurisé, comme son nom lindique,fournit des mécanismes de sécurité précis (par exemple, contrôle daccès, cryptage et répartition) quiempêchent lextraction dinformations sensibles éventuelles. Cest pourquoi un accès dinvestigationexplicite à lélément sécurisé nest actuellement pas possible, même avec un outil dinvestigation distribuépar les leaders du marché.RecommandationsIl existe des mesures que les organisations peuvent prendre pour réduire les risques que posent les faillesde sécurité des applications mobiles. Avant tout, les applications doivent être manuellement contrôlées etévaluées avant le lancement des produits afin de déterminer la présence de vulnérabilités dinjection oude vulnérabilités de fuite dinformation. Le code doit être analysé via une analyse statique au moment dele développer pour y rechercher des failles. Comme pour toutes les applications, il est moins coûteux degérer des failles de sécurité lors de la phase de développement quau moment de leur diffusion.Les normes de transmission sécurisée des données doivent être incluses dans le cahier des charges detoutes les applications, surtout si ces dernières sont élaborées par des développeurs tiers. Il en va demême pour le stockage sécurisé des données et le journal des applications. Des exigences raisonnablesen matière daffichage des communications entre applications et dautorisations dans ces dernièresdoivent être rigoureusement définies. Tous ces aspects doivent être gérés lors de la phase de définitiondes exigences et testés lors du développement. Au moment dexécuter les tests de sécurité et lanalysesur les applications mobiles, les services Web côté serveur et les API avec lesquels les clients mobilescommuniquent doivent être pris dans leur contexte et analysés pour y déceler des vulnérabilités. Desfailles à haut risque peuvent passer à la trappe si ces deux éléments sont testés et comparés hors de leurcontexte.ConclusionsLobjectif de ce rapport est de fournir aux organisations toutes les informations de sécurité qui les aiderontà mieux comprendre comment déployer les ressources limitées dont elles disposent pour minimiser aumaximum leurs risques en matière de sécurité. A cet effet, les tendances et les enseignements à tirer delannée 2012 sont nombreux et doivent être pris en compte pour la ou même les années qui viennent.Militarisation des vulnérabilitésLes attaquants ne cesseront jamais de militariser les vulnérabilités pour mener à bien leurs activitésmalveillantes. Ceux qui élaborent les kits dexploitation continueront de se focaliser sur des vulnérabilitésdans les logiciels les plus répandus, ciblant le plus souvent des navigateurs et des plug-ins de navigateur,tels que Oracle Java et Adobe® Flash. De même, le nombre dattaques menées publiquement à lencontrede technologies et dentreprises spécifiques continuera daugmenter. Des organisations criminelles, desEtats-nations et des hacktivistes se serviront toujours des cyber-attaques comme moyen duniformiserles règles du jeu contre des adversaires riches ou puissants, même si les réelles motivations derrière cesattaques resteront souvent difficiles à déterminer.Vulnérabilités des technologies mobilesLadoption croissante des technologies mobiles et leur utilisation au sein de lentreprise engendreronttoujours des risques considérables. Nombre de gens lont déjà constaté : les programmes malveillantsdéployés sur les marchés qui opposent Android et Apple poursuivent leur croissance. Laggravation de ceproblème est essentiellement liée au fait que les entreprises ne disposent pas du même type de contrôlesur ces appareils que sur des PC. Au moment où le BYOD (Bring your own device) devient la norme et queladoption des appareils mobiles prend de lampleur, on peut sattendre à une hausse proportionnelledu nombre de failles chez les applications mobiles, tendance qui devrait se maintenir dans un avenirprévisible.Livre blanc | Rapport HP 2012 sur les cyber-risques
    • 22Des technologies matures, toujours autant de risquesLes nouvelles technologies ne sont pas les seules à introduire de nouvelles vulnérabilités. Les attaquantscontinuent dexploiter les technologies existantes, et en apparence matures, pour multiplier les risquesau sein de lentreprise. De la poussée des vulnérabilités dans les systèmes SCADA jusquà lannoncerécente du département américain de la Sécurité intérieure préconisant la désactivation de la plate-formeOracle Java Standard Edition (SE) dans tous les navigateurs Web, des nouveaux modes dattaque sonten permanence découverts dans les anciennes technologies. Lorsque ces événements saccompagnentdun manque de pratiques adéquates face aux vulnérabilités actuelles (comme labsence de préventionpour les attaques par script sur plusieurs cadres), on voit aisément que la sécurité de lentrepriseest encore plus difficile à assurer lorsque même des technologies matures demeurent obstinémentvulnérables.Les applications Web restent vulnérablesDe nombreux individus et entreprises partent du principe que leurs sites Web nont aucun intérêt pour lesattaquants. Mais cest loin dêtre le cas. En réalité, labsence de pratiques fiables et sécurisées en matièrede programmation et de sécurité informatique favorise la prolifération des programmes malveillants. Quiplus est, labsence dun nettoyage approprié des entrées utilisateur dans les applications Web, tout commeles informations que divulguent ces dernières, montrent que les développeurs ont encore du pain sur laplanche pour sécuriser comme il se doit leurs applications.Nombre des attaques recensées en 2012 (et avant), quelles soient lœuvre dhacktivistes ou dindividuscherchant à promouvoir des programmes malveillants, exploitent depuis longtemps certainesvulnérabilités comme linjection SQL. Le taux de divulgation élevé des vulnérabilités de type XSS, associé àleur présence fréquente dans les tests qui sont menés, laisse entendre que leur popularité nest pas prêtede décliner. A lavenir, on peut sattendre à des failles dinjection toujours plus fréquentes (notammentlinjection PHP) car les bénéfices à tirer dune exploitation menée dans les règles de lart peuvent êtreconsidérablesPour en savoir plus, consultez la page Webhp.com/go/SIRMLivre blanc | Rapport HP 2012 sur les cyber-risques
    • Evaluer ce documentPartager avec des collèguesAbonnez-vous surhp.com/go/getupdatedLivre blanc | Rapport HP 2012 sur les cyber-risquesContributeursLe rapport HP 2012 sur les cyber-risques est une collaboration annuelle de plusieurs groupes chargésdes produits au sein de HP Enterprise Security, notamment les suivants : HP Security Research(regroupant HP DVLabs, HP Fortify Software Security Research et le programme HP Zero Day Initiative),HP TippingPoint et HP Fortify on Demand. Nous tenons à remercier sincèrement lOSDVB (Open SourceVulnerability Database) pour avoir autorisé la reproduction de ses données dans ce rapport. Merci aussitout particulièrement à Sahba Kazerooni, Takeaki Chijiiwa, Subramanian Ramanathan et Jevonne Petersde Security Compass, partenaire HP, pour leur contribution en matière de contenu, de recherche et dedonnées.Contributeur TitreJason Haddix Directeur des tests de pénétration, HP Fortify on DemandBrian Hein Chercheur en sécurité, HP Security ResearchPatrick Hill Chef de produit senior, HP DVLabsAdam Hils Chef de produit senior, HP TippingPointPräjaktä Jagdälé Chercheur en sécurité des logiciels, HP Security ResearchJason Lancaster Chercheur en sécurité, HP Security ResearchMark Painter Directeur Marketing Produits, HP FortifyJohn Pirc Directeur, Sécurité, HP Security ResearchJoe Sechman Directeur, groupe HP Software Security Research,HP Security ResearchSasi Muthurajan Siddharth Chercheur en sécurité des logiciels, HP Security ResearchRyan Strecker Directeur Marketing Produits, HP TippingPointJewel Timpe Directeur, groupe Malware Research, HP Security Research© Copyright 2013 Hewlett-Packard Development Company, L.P. Les informations contenues dans ce document sont sujettes à modification sansnotification préalable. Les seules garanties relatives aux produits et services HP sont stipulées dans les énoncés de garantie expresse accompagnantces produits et services. Aucune déclaration contenue dans ce document ne doit être interprétée comme constituant une garantie supplémentaire. HP nepeut pas être tenu responsable des erreurs techniques ou de forme ou des omissions contenues dans ce document.Adobe est une marque commerciale de Adobe Systems Incorporated. Apple est une marque commerciale de Apple Computer,  Inc. aux Etats-Unis et dansdautres pays. Google est une marque commerciale de Google, Inc. Microsoft est une marque déposée de Microsoft Corporation aux Etats-Unis et dansdautres pays Oracle et Java sont des marques déposées dOracle et/ou de ses filiales.4AA4-5495FRE, février 2013